Nur mal nebenbei…
www.kernel-error.de (2001:7d8:8001:100:0:0:dead:beef) doesn’t have #IPv6 Path MTU Discovery problem. http://hide.dnsalias.net/aaaa/pmtucheck.cgi/www.kernel-error.de/
Fragen? Einfach melden.
IT security, FreeBSD, Linux, mail server hardening, post-quantum crypto, DNS, retro computing & hands-on hardware hacks. Privater Tech-Blog seit 2003.
Nur mal nebenbei…
www.kernel-error.de (2001:7d8:8001:100:0:0:dead:beef) doesn’t have #IPv6 Path MTU Discovery problem. http://hide.dnsalias.net/aaaa/pmtucheck.cgi/www.kernel-error.de/
Fragen? Einfach melden.
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.
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.
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.
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.
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.
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.
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
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
Zwischenstand:
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
Auf der Windows-Seite den eingebauten Microsoft iSCSI-Initiator öffnen (ab Windows 7 vorinstalliert):
Mehr zu ZFS: ZFS Compression und Deduplication. Fragen? Einfach melden.
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.
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
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.
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 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.
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.
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
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.
Veraltet: OpenIndiana und Solaris werden kaum noch eingesetzt. Wer heute einen Unix-ähnlichen Server betreiben will, ist mit FreeBSD oder Linux besser bedient.
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?
Veraltet: OpenIndiana als Solaris-Fork wird kaum noch produktiv eingesetzt. Wer ein robustes Unix-System mit ZFS sucht, ist mit FreeBSD besser bedient.
ZFS ist nun schon ein paar Jahre alt, denn noch habe ich bisher noch kein Dateisystem gefunden welches im wirklich das Wasser reichen kann. Hier und da in Detailvergleichen, keine Frage aber
alles in allem „no way“. Bei seiner Einführung hat SUN etwas von unkaputtbar erzählt. Titanic lässt grüßen? Auf keinen Fall… Ich habe es noch nicht geschafft ein ZFS zu zerlegen. Egal wie oft der Strom ausfällt oder der Rechner einen Reset bekommt. Ohne Hammer bzw. echten Hardwaredef. läuft das System einfach weiter.
Wie auch immer…. Vor ein paar Tagen ist nun die Entwicklerversion oi_151a erschienen. Die Version 148 war schon viel versprechend. Diese Version lief auch immer im Dualboot neben meinem Gentoo. Da sie denn noch viel Schleifarbeit an vielen Stellen braucht hatte sie eher ein passives leben 🙁
Dieses hat sich jetzt nach einem kurzen Test geändert. Gentoo verschwindet in eine Virtualbox VM auf dem Solarissystem und dann geht es los.
Ich liste in laufe der Zeit mal in einem Untermenü auf was mir so aufgefallen ist bzw. was anderen vielleicht weiterhelfen könnte.
OpenIndiana der fork von OpenSolaris und Solaris? Ja und nein, denn Sun hat sein Verspechen, die OpenSolaris-Entwicklung für die Gemeinschaft zu öffnen, nicht eingehalten hat und da Oracle nach der Übernahme von Sun zunehmend Teilprojekte einstellte, haben Mitglieder der OpenSolaris-Entwickler-Gemeinschaft am 3. August 2010 die Gründung des Projektes Illumos zur Entwicklung eines wirklich freien Open-Source-Solaris bekanntgegeben. OpenIndiana hat nun diese Basis.
Ich hatte auf einer meiner Maschinen ein kleines Problem mit der LiveCD. Diese bliebt beim booten einfach hängen und dieses ohne erkennbaren Grund. Zumindest konnte ich auf den Konsolen nichts erkennen und einen Logfile gibt es so ja erstmal nicht :-/ Bei einem Linux Live System würde man ja nun erstmal Kernel Optionen wie: noacpi / noapic / acpi=off oder so ein Geschlönz probieren, aber hier????
Ich habe im Zusammenhang mit der OpenIndiana LiveDVD ein paar Bugs und Probleme im Zusammenhang mit USB gelesen. Hier scheint das System noch etwas „anfällig“ zu sein 🙁 Wie auch immer nach einigen Tests viel mit nichts besseres mehr ein als einfach den USB-Kontroller im BIOS zu deaktivieren. Nur um das USB-System auszuschließen versteht sich… Tja, was soll ich sagen? USB im BIOS ausschalten und LiveDVD (der OpenIndiana Live USB-Stick ist dann natürlich nutzlos) einlegen. Schon versagen ordnungsgemäß USB-Tastatur und USB-Maus ihren Dienst, OpenIndiana Bootet aber sauber hoch. Spannenderweise erkennt das gebootete System den USB-Kontroller wieder und somit auch Maus, Tastatur oder sonstige USB-Sticks. Dieses Verhalten führte zwar bei mir zu etwas Stirnrunzeln, bringt mir denn noch ein funktionierendes System.
© 2026 -=Kernel-Error=- — RSS
Theme von Anders Norén — Hoch ↑