-=Kernel-Error=-

IT security, FreeBSD, Linux, mail server hardening, post-quantum crypto, DNS, retro computing & hands-on hardware hacks. Privater Tech-Blog seit 2003.

Schlagwort: Networking (Seite 10 von 12)

GPG-Schlüssel per PKA im DNS veröffentlichen

27. Mai 2012 / / Keine Kommentare

Hinweis: PKA (Public Key Association) wird von GnuPG seit Version 2.1 (2014) nicht mehr unterstützt. Der Nachfolger ist der OPENPGPKEY Resource Record, der den kompletten Schlüssel direkt im DNS speichert. Dieser Beitrag beschreibt das ältere PKA-Verfahren — historisch interessant, aber für neue Setups nicht mehr empfehlenswert.

Die Idee hinter PKA

GnuPG konnte über DNS nach GPG-Schlüsseln fragen. Der Vorteil: Ich muss meinen öffentlichen Schlüssel nicht auf Keyservern verteilen, sondern veröffentliche ihn über meinen eigenen DNS-Server. Ist die Zone per DNSSEC geschützt, kann der Schlüssel nicht gefälscht werden — deutlich vertrauenswürdiger als Keyserver, auf denen jeder beliebige Schlüssel hochladen kann.

PKA funktioniert mit einem TXT-Record, der den Fingerprint des Schlüssels und eine URL zum Download enthält. GnuPG prüft den Fingerprint gegen den heruntergeladenen Schlüssel — stimmt beides überein, wird der Schlüssel importiert.

Schlüssel exportieren

Zuerst den öffentlichen Schlüssel exportieren und auf dem Webserver ablegen:

gpg --list-keys --fingerprint kernel-error@kernel-error.com
gpg --export --armor 0F9874D8 > kernel-error.asc

Die exportierte Datei muss per HTTP erreichbar sein — HTTPS ist nicht zwingend nötig, da der Schlüssel am Ende gegen den Fingerprint aus dem DNS geprüft wird.

PKA-Record erstellen

Der PKA-Record ist ein TXT-Record unter localpart._pka.domain. Er enthält den Fingerprint und die URL zum Schlüssel:

kernel-error._pka.kernel-error.com. IN TXT "v=pka1;fpr=80CF90446B5867DA3A55854AF01C3E040F9874D8;uri=http://www.kernel-error.de/kernel-error.pubkey.txt"

Aufbau: Das @ in der E-Mail-Adresse wird durch ._pka. ersetzt. Der Record enthält die PKA-Version (v=pka1), den vollständigen Fingerprint (fpr=...) und die Download-URL (uri=...). Für jede E-Mail-Adresse, unter der man erreichbar ist, braucht man einen eigenen Record — auch über verschiedene Zonen hinweg.

Prüfen

Mit dig testen, ob der Record im DNS angekommen ist:

dig +short kernel-error._pka.kernel-error.com TXT
"v=pka1;fpr=80CF90446B5867DA3A55854AF01C3E040F9874D8;uri=http://www.kernel-error.de/kernel-error.pubkey.txt"

GnuPG (bis Version 2.0) konnte den Schlüssel dann automatisch finden und importieren:

echo "test" | gpg --auto-key-locate pka --keyring /tmp/test.gpg \
  --encrypt --armor -r kernel-error@kernel-error.com

GnuPG fragt den PKA-Record ab, lädt den Schlüssel von der angegebenen URL herunter, prüft den Fingerprint und importiert den Schlüssel in den Keyring.

Warum OPENPGPKEY besser ist

PKA hatte zwei Schwächen: Der Schlüssel lag nicht im DNS selbst, sondern musste per HTTP heruntergeladen werden — ein zusätzlicher Angriffsvektor. Und der TXT-Record war auf 255 Bytes pro String begrenzt, was bei langen URLs und Fingerprints knapp wurde.

Der OPENPGPKEY Resource Record (RFC 7929) löst beides: Der komplette Schlüssel steckt direkt im DNS, kein HTTP-Download nötig. Mit DNSSEC ist die gesamte Kette vom DNS-Lookup bis zum Schlüssel kryptographisch abgesichert.

Siehe auch: OPENPGPKEY im DNS, GPG: E-Mails signieren und verschlüsseln mit GnuPG, Der sichere GPG-Schlüssel

Fragen? Einfach melden.

DNS konfigurieren um die XMPP Information zu verteilen

19. Mai 2012 / / Keine Kommentare

Warum vergessen nur immer alle die DNS Informationen zu ihrem neuen Jabber-Server zu setzten? Ich bin heute sicher zum 12 mal nach einem Problem gefragt worden welches damit zusammen hing. Die Info fehlt aber auch in _fast_ jedem Howto. Kopieren denn wirklich alle nur noch Zeile für Zeile? Als Wikipedia mal einen Tag ausgesetzt hat, konnten tausende keine Hausaufgaben abgeben. Irgendwie habe ich dass Gefühl, wenn Google mal einen Tag aussetzten würde könnten tausende „Admins“ nichts installieren oder Probleme lösen ;-P

Also um es noch mal in Google zu werfen:

Damit die Kommunikation zwischen den Jabber-Server sauber läuft müssen die nötigen DNS Records vorhanden sein. Für meinen Bind schaut es so aus wie im folgenden Beispiel:

_jabber._tcp.jabber.kernel-error.de.       IN SRV   0 0 5269   jabber.kernel-error.de.
_xmpp-server._tcp.jabber.kernel-error.de.  IN SRV   0 0 5269   jabber.kernel-error.de.
_xmpp-client._tcp.jabber.kernel-error.de.  IN SRV   0 0 5222   jabber.kernel-error.de.

Testen lässt sich dieses am Ende natürlich mit dig:

$ dig SRV _xmpp-server._tcp.jabber.kernel-error.de +short
0 0 5269 jabber.kernel-error.de.

$ dig SRV _xmpp-client._tcp.jabber.kernel-error.de +short
0 0 5222 jabber.kernel-error.de.

Fragen? Einfach melden.

Ejabberd Dualstack IPv4 und IPv6

7. Mai 2012 / / Keine Kommentare

Wie so oft führen viele Wege nach Rom. Damit Ejabberd auf der IPv4 und den IPv6 Adressen gleichzeitig lauscht hat sich für mich folgender als gut erwiesen:

In der Konfigurationsdatei: /etc/ejabberd/ejabberd.cfg

Im Abschnitt Listening Ports einfach in die Portkonfiguration inet4 sowie inet6 aufnehmen:

{5222, ejabberd_c2s, [
                        inet4,
                        inet6,
                        {access, c2s},
                        {shaper, c2s_shaper},
                        {max_stanza_size, 65536},
                        %%zlib,
                        starttls, {certfile, "/etc/ejabberd/ejabberd.pem"}
                       ]},

Schon arbeitet Ejabberd mit beiden:

# netstat -an|grep 5222
tcp6       0      0 :::5222                 :::*                    LISTEN     
tcp6       0      0 *:5222                 *:*                    LISTEN    


Ach ja, Ejabberd Version ist gerade: 2.1.5

Fragen? Einfach melden.

Wechsel von Openfire zu Ejabberd

7. Mai 2012 / / Keine Kommentare

Ich betreibe nun schon seit…. Oha…. Seit langem 🙂 einen eigenen Jabber-Server.

Jetzt ist das Teil alles andere als ein großes System mit mehreren tausend Usern. Er wird genutzt von der Familie, ein paar Freunden und Bekannten. Mehr sollte und soll es auch nie werden. Vor knapp zwei Jahren habe ich auf Openfire gesetzt. Openfire bietet eine recht ausgereifte klickibunti Oberfläche. Leider kamen in der letzten Zeit immer mal wieder nervige Bugs hinzu.  

Zum einen ist kein Paket für meine Umgebung dabei. Also muss ich das Ding immer von Hand reinwursten. Dann hat es mich einiges an Überzeugungsarbeit gekostet das Openfire nicht als root laufen will, wer will schon Software als root ausführen? Dann waren da noch ein paar Bugs bezüglich SSL in der Server zu Server Kommunikation und diesen nervigen Dialback errors…..  Nun scheint die aktuelle Version: 3.7.1 sowie auch das nightly build 2011-12-21 ein Problem mit IPv6 und DNS zu haben. So genau bin ich auch jetzt nicht dahinter gekommen.  

Wie auch immer!
Das Kraken – IM Gateway scheint leicht eingeschlafen zu sein, Openfire selbst ist in seiner Weiterentwicklung auch etwas seltsam. Vielleicht hat das Projekt geforkt und ich habe es verpasst? Ist ja auch schon vorgekommen, zuletzt verpasste ich StarOffice zu OpenOffice (peinlich peinlich). Da mir nun drei mal ein Bug bei Openfire so vor das Scheinbein getreten hat, dass keine nutzbare Funktion von Jabber übergeblieben ist (zumindest so wie ich sie mir vorstellen, also mit IPv6 und Verschlüsselung. Habe ich mich dazu entschieden zu Ejabberd zu wechseln.

Ejabberd hat fertige Pakete für meine Umgebung im Repository. Somit kann ich auch auf einfache Sicherheitsupdates hoffen. Transporter für ICQ / MSN… sind selbstverständlich überhaupt kein Problem und da Facebook (Familie ihr wisst schon….) direkt per Jabber erreichbar ist, ist alles gut 🙂

Meine paar Konten habe ich recht schnell aus Openfire und in Ejabberd bekommen. Nun läuft mein Messanger also über Ejabberd.

2012.05.03 13:40:26 org.jivesoftware.openfire.session.LocalOutgoingServerSession - Error authenticating domain with remote server: domain.org
java.lang.NumberFormatException: For input string: "4860:4860::8888"
    at java.lang.NumberFormatException.forInputString(NumberFormatException.java:48)
    at java.lang.Integer.parseInt(Integer.java:458)
    at java.lang.Integer.parseInt(Integer.java:499)
    at com.sun.jndi.dns.DnsClient.<init>(DnsClient.java:105)
    at com.sun.jndi.dns.Resolver.<init>(Resolver.java:44)
    at com.sun.jndi.dns.DnsContext.getResolver(DnsContext.java:553)
    at com.sun.jndi.dns.DnsContext.c_getAttributes(DnsContext.java:413)
    at com.sun.jndi.toolkit.ctx.ComponentDirContext.p_getAttributes(ComponentDirContext.java:213)
    at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.getAttributes(PartialCompositeDirContext.java:121)
    at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.getAttributes(PartialCompositeDirContext.java:109)
    at javax.naming.directory.InitialDirContext.getAttributes(InitialDirContext.java:123)
    at org.jivesoftware.openfire.net.DNSUtil.srvLookup(DNSUtil.java:199)
    at org.jivesoftware.openfire.net.DNSUtil.resolveXMPPDomain(DNSUtil.java:131)
    at org.jivesoftware.openfire.session.LocalOutgoingServerSession.createOutgoingSession(LocalOutgoingServerSession.java:269)
    at org.jivesoftware.openfire.session.LocalOutgoingServerSession.authenticateDomain(LocalOutgoingServerSession.java:167)
    at org.jivesoftware.openfire.server.OutgoingSessionPromise$PacketsProcessor.sendPacket(OutgoingSessionPromise.java:261)
    at org.jivesoftware.openfire.server.OutgoingSessionPromise$PacketsProcessor.run(OutgoingSessionPromise.java:238)
    at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
    at java.lang.Thread.run(Thread.java:662)

Fragen? Einfach melden.

Evolution merkt sich die Einstellungen der Zertifizierungsstellen nicht

21. April 2012 / / Keine Kommentare

Ich nutze Evolution als E-Mail Client. In den Zertifikatseinstellungen habe ich unter Zertifizierungsstellen auch eine ganze Latte von CAs. Ich kann auch welche hinzufügen und entfernen alles kein Problem.

Will ich aber deren Einstellung bearbeiten, sprich für welche Dinge ich dieser CA vertrauen möchte bleiben diese Einstellungen nur immer für die aktuelle Sitzung gespeichert. Schließe und Starte ich Evolution wieder sind die Einstellungen alles wieder weg 🙁 Das ist doof!

Wer sucht, der findet einen Workaround……..

Das Problem ist wohl dass Evolution aus irgendwelchen Gründen die cert9.db / key4.db unter ~/.pki/nssdb nicht updatet.

So kann ich mir anschauen was bei mir eingetragen ist:

$ certutil -L -d sql:/home/kernel/.pki/nssdb/

Certificate Nickname                                         Trust Attributes
                                                             SSL,S/MIME,JAR/XPI

StartCom Ltd. ID von Sebastian Van De Meer                   u,u,u
StartCom Class 2 Primary Intermediate Client CA - StartCom Ltd. ,,   
CA Cert Signing Authority - Root CA                          ,,   
CAcert Class 3 Root - Root CA                                ,,   
StartCom Class 1 Primary Intermediate Client CA - StartCom Ltd. ,,   
StartCom Certification Authority - StartCom Ltd.             ,,   
StartCom Ltd.                                                ,,   
StartCom Certification Authority                             ,,   
......

Und so verpasse ich den einzelnen Zertifikaten die passenden „Verwendungsmöglichkeiten“:

$ certutil -M  -n "CA Cert Signing Authority - Root CA"  -t "TCu,Cu,TCuw" -d sql:/home/kernel/.pki/nssdb/

Am Ende schaut es nun so aus (ich mache mir dann noch mal nen Kopf ob es so auch sinnig ist):

$ certutil -L -d sql:/home/kernel/.pki/nssdb/

Certificate Nickname                                         Trust Attributes
                                                             SSL,S/MIME,JAR/XPI

StartCom Ltd. ID von Sebastian Van De Meer                   u,u,u
StartCom Class 2 Primary Intermediate Client CA - StartCom Ltd. CT,C,C
CA Cert Signing Authority - Root CA                          CT,C,C
CAcert Class 3 Root - Root CA                                CT,C,C
StartCom Class 1 Primary Intermediate Client CA - StartCom Ltd. CT,C,C
StartCom Certification Authority - StartCom Ltd.             C,C,C
StartCom Ltd.                                                C,C, 
StartCom Certification Authority                             C,C,C
......

Auf meine Openindiana Kiste musste ich dafür noch folgendes Paket installieren:

system/mozilla-nss

Und wegen des Bugs #1739 certutil with incomplete runpath musste ich noch folgenden Workaround dafür einwerfen:

$ elfedit -e 'dyn:runpath $ORIGIN/../lib:/usr/lib/mps' /usr/sfw/bin/certutil

Jetzt macht zwar Evolution nicht die Arbeit aber mein Wunsch ist erfüllt. Ob ich da mal nen Bug bei den Jungs aufmache?

So long…

Siehe auch: S/MIME per DNS mit SMIMEA

Fragen? Einfach melden.

ZFS iSCSI-Target mit COMSTAR auf OpenIndiana einrichten

22. März 2012 / / Keine Kommentare

COMSTAR (Common Multiprotocol SCSI Target) ist das Framework in Solaris/OpenIndiana, das iSCSI, FC und FCoE unter einem Dach vereint. Es ersetzt den alten iSCSI Target Daemon aus Solaris 10. Hier die Einrichtung eines iSCSI-Targets auf Basis eines ZFS-Volumes für einen Windows-Initiator.

ZFS-Volume anlegen

Zuerst einen eigenen Pool und darin ein ZFS-Volume mit fester Größe erstellen — das Volume wird später die LUN:

zpool create iscsi-target-pool c4t2d0

zfs create -V 10g iscsi-target-pool/iscsi_10gb-lun01
zfs list iscsi-target-pool/iscsi_10gb-lun01
NAME                                   USED  AVAIL  REFER  MOUNTPOINT
iscsi-target-pool/iscsi_10gb-lun01    10,3G  19,6G    16K  -

Die feste Größe (-V 10g) ist wichtig — sonst würde die Poolgröße das Target begrenzen, und bei mehreren Targets im selben Pool wird es unübersichtlich.

COMSTAR-Dienste starten

Das SCSI Target Mode Framework (STMF) aktivieren:

svcadm enable stmf
svcs stmf
STATE   STIME    FMRI
online  13:02:50 svc:/system/stmf:default

stmfadm list-state
Operational Status: online
Config Status     : initialized

Das iSCSI-Target-Paket installieren und den Dienst starten:

pkg install /network/iscsi/target

svcs iscsi/target
STATE   STIME    FMRI
online  13:23:56 svc:/network/iscsi/target:default

Logical Unit erstellen

Eine LUN auf Basis des ZFS-Volumes anlegen:

sbdadm create-lu /dev/zvol/rdsk/iscsi-target-pool/iscsi_10gb-lun01
Created the following LU:

GUID                             DATA SIZE     SOURCE
-------------------------------- ------------- ----------------
600144f051c247000000523ed0050001 10737418240   /dev/zvol/rdsk/iscsi-target-pool/iscsi_10gb-lun01

Prüfen ob die LUN online ist:

stmfadm list-lu -v
LU Name            : 600144F051C247000000523ED0050001
Operational Status : Online
Provider Name      : sbd
Alias              : /dev/zvol/rdsk/iscsi-target-pool/iscsi_10gb-lun01
Data File          : /dev/zvol/rdsk/iscsi-target-pool/iscsi_10gb-lun01
Size               : 10737418240
Block Size         : 512

Damit der Initiator die LUN sehen kann, einen View erstellen:

stmfadm add-view 600144F051C247000000523ED0050001
stmfadm list-view -l 600144F051C247000000523ED0050001
View Entry: 0
  Host group   : All
  Target group : All
  LUN          : 0

iSCSI-Target anlegen

Zwischenstand:

  • STMF und iSCSI-Target-Dienst laufen
  • 10 GB ZFS-Volume als LUN angelegt
  • View erstellt, damit Initiatoren die LUN sehen

Fehlt noch das Target selbst:

itadm create-target
Target iqn.2010-09.org.openindiana:02:6c3939bf-f5e5-4f28-a8d0-d0f0bbb2e1c4 successfully created

itadm list-target -v
TARGET NAME                                                          STATE   SESSIONS
iqn.2010-09.org.openindiana:02:6c3939bf-f5e5-4f28-a8d0-d0f0bbb2e1c4 online  0
  alias:             -
  auth:              none (defaults)
  targetchapuser:    -
  targetchapsecret:  unset
  tpg-tags:          default

Zum Schluss sicherstellen, dass das Target im Discovery auftaucht:

devfsadm -i iscsi

Windows-Initiator verbinden

Auf der Windows-Seite den eingebauten Microsoft iSCSI-Initiator öffnen (ab Windows 7 vorinstalliert):

  • Portal über die IP-Adresse des OpenIndiana-Hosts ermitteln lassen
  • Das Ziel suchen und verbinden
  • Die neue Festplatte in der Datenträgerverwaltung initialisieren und ein Volume erstellen
Screenshot der Windows Fehlermeldung: You do not have permission to update Windows.Screenshot der Windows Fehlermeldung: Setup could not find the update.inf file.Screenshot des Windows iSCSI-Initiators mit der Zielportal-Einstellung.Screenshot des Windows iSCSI-Initiators mit dem erkannten Ziel.
Screenshot des Windows iSCSI-Initiators beim Verbinden mit dem Ziel.Screenshot des Windows iSCSI-Initiators mit der Volumeliste.Screenshot der Windows Datenträgerinitialisierung mit dem erkannten iSCSI-Datenträger.Screenshot der Windows Datenträgerverwaltung mit dem fertig konfigurierten COMSTAR SCSI Device.

Mehr zu ZFS: ZFS Compression und Deduplication. Fragen? Einfach melden.

ZFS SMB-Freigaben unter Solaris/OpenIndiana mit sharesmb einrichten

22. März 2012 / / Keine Kommentare

Hinweis: Dieser Artikel beschreibt SMB-Freigaben mit dem eingebauten SMB-Server von Solaris/OpenIndiana. Unter FreeBSD und Linux nutzt man stattdessen Samba — dort wird sharesmb nicht unterstützt.

SMB-Server einrichten

Die SMB Server Kernel-Komponenten installieren:

pkg install SUNWsmbskr

Damit lokale Benutzer sich per Benutzername und Passwort authentifizieren können, das PAM-Modul in /etc/pam.conf eintragen:

other password required pam_smb_passwd.so.1 nowarn

SMB-Server starten und prüfen:

svcadm enable -r smb/server

svcs smb/server
STATE   STIME    FMRI
online  20:11:41 svc:/network/smb/server:default

In die gewünschte Workgroup eintreten:

smbadm join -w WORKGROUP
After joining WORKGROUP the smb service will be restarted automatically.
Would you like to continue? [no]: yes
Successfully joined WORKGROUP

ZFS-Freigabe erstellen

Ein neues ZFS-Dataset anlegen und direkt per SMB freigeben — ein einziges Property reicht:

zfs create rpool/daten-freigabe

zfs set sharesmb=on rpool/daten-freigabe

zfs get sharesmb rpool/daten-freigabe
NAME                 PROPERTY  VALUE  SOURCE
rpool/daten-freigabe sharesmb  on     local

Das war es. Das Dataset ist jetzt als SMB-Share im Netzwerk sichtbar. Kein Samba, keine smb.conf — der Kernel-SMB-Server von Solaris arbeitet direkt mit ZFS zusammen. Alle ZFS-Features (Snapshots, Compression, Quotas) gelten für die Freigabe genauso wie für jedes andere Dataset.

Zugriff

Von einem Windows-Client aus die Freigabe über \\hostname\daten-freigabe erreichen. Die Authentifizierung läuft über die lokalen Unix-Benutzer — das PAM-Modul synchronisiert die Passwörter automatisch.

Mehr zu ZFS: ZFS Compression und Deduplication. Fragen? Einfach melden.

ZFS NFS-Freigaben unter Solaris/OpenIndiana mit sharenfs einrichten

22. März 2012 / / Keine Kommentare

ZFS bringt NFS-Freigaben als eingebaute Funktion mit — kein separater NFS-Server nötig, ein einziges Property reicht. Das funktioniert unter Solaris, OpenIndiana und teilweise auch unter FreeBSD.

NFS-Freigabe erstellen

Dataset anlegen und per NFS freigeben:

zfs create rpool/daten

zfs set sharenfs=on rpool/daten

zfs get sharenfs rpool/daten
NAME        PROPERTY  VALUE  SOURCE
rpool/daten sharenfs  on     local

Das war es. Das Dataset ist jetzt per NFS im Netzwerk verfügbar — für alle Clients, ohne Einschränkung.

NFS-Optionen

Statt on lassen sich die üblichen NFS-Optionen direkt im Property angeben — zum Beispiel Zugriff nur für ein bestimmtes Subnetz:

# Nur Lesen/Schreiben für ein Subnetz
zfs set sharenfs="rw=@192.168.1.0/24" rpool/daten

# Nur Lesen für alle, Schreiben für ein Subnetz
zfs set sharenfs="ro,rw=@10.0.0.0/8" rpool/daten

# Freigabe prüfen
share -F nfs

Auf dem Client mounten:

mount -t nfs server:/rpool/daten /mnt/daten

Portabilität

Ein netter Nebeneffekt: ZFS-Properties wandern mit dem Pool. Exportiert man den Pool und importiert ihn auf einem anderen System, ist die NFS-Freigabe sofort wieder aktiv:

# Pool exportieren (z.B. vor dem Umstecken einer USB-Platte)
zpool export nfs-share

# Auf einem anderen System importieren — Share ist sofort da
zpool import nfs-share

Alle ZFS-Einstellungen — Compression, Quotas, Snapshots, Freigaben — bleiben erhalten. Für SMB-Freigaben statt NFS siehe ZFS SMB-Freigaben mit sharesmb. Mehr zu ZFS: ZFS Compression und Deduplication. Fragen? Einfach melden.

Solaris ipadm

2. März 2012 / / Keine Kommentare

Veraltet: OpenIndiana und Solaris werden kaum noch eingesetzt. Wer heute einen Unix-ähnlichen Server betreiben will, ist mit FreeBSD oder Linux besser bedient.

Der OpenSolaris fork Openindiana und die feste IP-Adresse (static IP-Adress)

Solaris war auf den ersten Blick noch nie so richtig einfach in Sachen IP-Adressen. Auf den zweiten Blick finde ich es aber logischer als bei allen anderen! Wie auch immer, die Meinungen gehen hier wohl auseinander.

Ab OpenSolaris dem SolarisExpress 11 also grob dem aktellen Solaris 11 hat sich etwas hinsichtlich des Netzwerkes geändert. Openindiana ist nun daraus hervorgegangen also muss man dieses hier auch beachten 🙂

So wie der Befehl ifconfig unter Linux von ip abgelöst wird, sieht es wohl unter Solaris mit ipadm aus!

Ich mache es einfach mal ganz kurz und schmerzlos:

Als erstes muss nwam (Network Auto-Magic) deaktiviert werden:

$ svcadm disable svc:/network/physical:nwam
$ svcadm enable svc:/network/physical:default

Dann listen wir uns mal kurz alle Netzwerkinterfaces auf:

$ ipadm show-if -o all
IFNAME     CLASS    STATE    ACTIVE CURRENT       PERSISTENT OVER
lo0        loopback ok       yes    -m46-v------  46--       --
net0       ip       ok       yes    bm46--------  ----       --

Schon können wir die feste IP 192.168.1.10 mit der Netmask 255.255.255.0 dem Interface net0 zuteilen:

$ ipadm create-addr -T static -a 192.168.1.10/24 net0/v4

Damit unsere IP-Pakete später den Weg ins „Internet“ finden benötigen wir noch die Defaultroute zum Router:

$ route -p add default 192.168.1.254

Jetzt noch schnell den System mitteilen wie es mit DNS Auflösungen umzugehen hat:

$ cp /etc/nsswitch.dns /etc/nsswitch.conf

Fehlen nur noch die zu fragenden Nameserver:

$ echo "nameserver 192.168.1.254" > /etc/resolve.conf
$ echo "nameserver 8.8.8.8" >> /etc/resolve.conf

Achtung, 8.8.8.8 ist google. Aber wem schreibe ich dieses und wer macht schon ungeprüftes Copy & Past?

Damit hat unsere Kiste also nun die IP Adresse: 192.168.1.10/24 fragt erst den DNS Server 192.168.1.254 und dann den DNS Server 8.8.8.8. Den Weg aus seinem eigenen Subnetz findet die Kiste über den Router 192.168.1.254

Noch Fragen?

« Ältere Beiträge Neuere Beiträge »

© 2026 -=Kernel-Error=- — RSS

Theme von Anders Norén — Hoch ↑