OpenIndiana: NIS-Slave konfigurieren

Ich zeige hier, wie man auf einem Rechner namens onyx (OpenIndiana 151a3) den NIS-Slave-Dienst für die NIS-Domain babar eines NIS-Servers names rubin installiert. Es wird vorausgesetzt, dass der NIS-Service auf rubin bereits konfiguriert ist und das beide Rechner in /var/yp/ypservers vermerkt sind und beide Rechner müssen sich gegenseitig in /etc/hosts zu enthalten. So könnte das aussehen:

#/etc/hosts
[...]
192.168.0.11 onyx.local onyx
192.168.0.12 rubin.local rubin
[...]

Alle folgenden Befehle werden auf dem Slave-Server onyx ausgeführt.

NIS-Service installieren:

# pkg install service/network/nis

Domainname setzen

# domainname babar
# domainname > /etc/defaultdomain

NIS-Client konfigurieren. WICHTIG: Zuerst den Slave- und dann den Master-Server eintragen, also im Beispiel, erst onyx dann rubin.

# ypinit -c
In order for NIS to operate sucessfully, we have to construct a list of the
NIS servers. Please continue to add the names for YP servers in order of
preference, one per line. When you are done with the list, type a
 or a return on a line by itself.
 next host to add: onyx
 next host to add: rubin
 next host to add:
The current list of yp servers looks like this:
onyx

 rubin

Is this correct? [y/n: y] y

NIS-Client starten:

# svcadm enable -r nis/client

NIS-Slave konfigurieren:

# ypinit -s rubin
 Installing the YP database will require that you answer a few questions.
 Questions will all be asked at the beginning of the procedure.
Do you want this procedure to quit on non-fatal errors? [y/n: n]
 OK, please remember to go back and redo manually whatever fails. If you
 don't, some part of the system (perhaps the yp itself) won't work.
 The yp domain directory is /var/yp/babar
 Can we destroy the existing /var/yp/babar and its contents? [y/n: n] y
 There will be no further questions. The remainder of the procedure should take
 a few minutes, to copy the data bases from rubin.
 Transferring group.bygid...
 Transferring netgroup.byhost...
 Transferring auto.master...
 Transferring hosts.byname...
 Transferring hosts.byaddr...
 Transferring passwd.byuid...
 Transferring auto.direct...
 Transferring auto.nfs...
 Transferring passwd.byname...
 Transferring netgroup...
 Transferring ypservers...
 Transferring netgroup.byuser...
 Transferring auto.home...
 Transferring group.byname...

onyx's nis data base has been set up

without any errors.

Das war’s.

OpenIndiana: Statische Netzwerkkonfiguration

Nach der Installation bezieht OpenIndiana 151a (Illumos) seine Netzwerkkonfiguration per default von einem DHCP-Server. Ich zeige hier kurz, wie man dieses Verhalten abschalten kann und eine statische IP-Konfiguration erreicht. Zuerst NWAM deaktivieren und die statische Konfiguration aktivieren:

# svcadm disable network/physical:nwam
# svcadm enable -r network/physical:default

Folgende statische Konfiguration soll erreicht werden:

  • IPv4: 192.168.0.11
  • Netmask: 255.255.255.0
  • Hostname: cartman.mydom.local
  • Gateway: 192.168.0.1
  • Nameserver: 192.168.0.1, 8.8.8.8

Name des Interfaces ermitteln (hier: e1000g0)

# dladm show-phys
LINK    MEDIA    STATE   SPEED DUPLEX  DEVICE
rge0    Ethernet unknown 0     unknown rge0
e1000g0 Ethernet up      1000  full    e1000g0

IP-Adresse setzen:

# echo "192.168.0.11/24" > /etc/hostname.e1000g0

Hostname setzen:

# echo "192.168.0.11 cartman.mydom.local cartman" >> /etc/hosts

Gateway setzen:

# echo "192.168.0.1" > /etc/defaultrouter

Nameserver setzen:

# echo "nameserver 192.168.0.1" > /etc/resolv.conf
# echo "nameserver 8.8.8.8" >> /etc/resolv.conf
# echo "domain mydom.local" >> /etc/resolv.conf
# echo "search mydom.local" >> /etc/resolv.conf

Netzwerk „neustarten“:

# svcadm restart network/physical:default

OpenIndiana: localhost-only sendmail-Konfiguration

Standardmäßig arbeitet sendmail auf OpenIndinana 151a (Illumos) nur auf dem localhost-Interface. Wenn versucht wird eine Mail zu senden findet man im Clientlog eine Meldung, dass die Verbindung abgewiesen wurde:

Apr 25 10:17:17 client postfix/qmgr[3076]: D87EB62F38: from=, size=688, nrcpt=1 (queue active)
Apr 25 10:17:17 client postfix/smtp[22293]: connect to server[xxx.xxx.xxx.xxx]:25: Connection refused
Apr 25 10:17:17 client postfix/smtp[22293]: D87EB62F38: to=, relay=none, delay=490, delays=490/0.04/0/0, dsn=4.4.1, status=deferred (connect to server[xxx.xxx.xxx.xxx]:25: Connection refused)

 

Die Ursache hierfür ist, dass in der Konfiguration des Servers config/local_only=true gesetzt. Mit folgenden Zeilen bindet man sendmail auch an alle weiteren Netzwerkgeräte:

# svccfg -v -s sendmail
svc:/network/smtp:sendmail>setprop config/local_only=false
svc:/network/smtp:sendmail> exit
# svcadm refresh sendmail
# svcadm restart sendmail

Postfix und zusätzliche Domains

Immer wenn ein Mailserver ausfällt und ein anderer dessen Aufgaben mit übernehmen soll, sitze ich vor dieser doofen Posftfix-Konfigurationsdatei und frage mich, an welchen Stellen ich den zusätzlichen Hostnamen noch eintragen soll. Jetzt schreib‘ ich es einmal auf:  ($IP ist die Adresse des ausgefallenen Servers, $NAME ist sein fully qualified domain name (fqdn). Ich habe es mir zu Angewohnheit gemacht, die IP-Adresse des aufgefallenen Servers auf den Backup-Server zu übertragen, bis dieser wieder einsatzbereit ist.)

  1. IP an Interface anhängen
    # ip addr add $IP dev eth0
  2. /etc/postfix/main.cf editieren
    [...]
    inet_interfaces = $myhostname, localhost, $NAME
    [...]
    mydestination = $myhostname, localhost.$mydomain, localhost, $NAME
    [...]
  3. /etc/init.d/postfix stop
  4. /etc/init.d/postfix start

Das stopstart-Prozedere ist wichtig. Ein einfaches reload reicht nicht aus, restart sollte aber auch gehen.

Snow Leopard: ssh-Login-Problem

Nach einem Update von Mac OS X 10.5 (Leopard) nach 10.6 (Snow Leopard) war ein ssh-Login auf diesem Rechner nicht mehr möglich. Beim Versuch meldete der ssh-Client

$ ssh -vlroot 192.168.2.2
OpenSSH_5.2p1, OpenSSL 0.9.7l 28 Sep 2006
debug1: Reading configuration data /etc/ssh_config
debug1: Connecting to 192.168.2.2 [192.168.2.2] port 22.
debug1: Connection established.
debug1: identity file /Users/[...]/.ssh/identity type -1
debug1: identity file /Users/[...]/.ssh/id_rsa type -1
debug1: identity file /Users/[...]/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.2
debug1: match: OpenSSH_5.2 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.2
debug1: SSH2_MSG_KEXINIT sent
Connection closed by 192.168.2.2

Hier sind beim Update offensichtlich die Zugriffsrechte der globalen ssh_host Files durcheinander geraten:

# ls -l /etc/ssh*
-rw-r--r-- 1 root wheel 1545 Feb 11 2010 /etc/ssh_config
-rw-rw-rw- 1 root admin 668 Sep 23 2011 /etc/ssh_host_dsa_key
-rw-rw-rw- 1 root admin 590 Sep 23 2011 /etc/ssh_host_dsa_key.pub
-rw-rw-rw- 1 root admin 963 Sep 23 2011 /etc/ssh_host_key
-rw-rw-rw- 1 root admin 627 Sep 23 2011 /etc/ssh_host_key.pub
-rw-rw-rw- 1 root admin 1671 Sep 23 2011 /etc/ssh_host_rsa_key
-rw-rw-rw- 1 root admin 382 Sep 23 2011 /etc/ssh_host_rsa_key.pub
-rw-r--r-- 1 root wheel 3723 Feb 11 2010 /etc/sshd_config

Diese müssen nach 0600 geändert werden, dann sollte es wieder laufen:

$ sudo chmod 600 /etc/ssh_host_*
$ ls -l /etc/ssh_host_*
-rw------- 1 root admin 668 Sep 23 2011 /etc/ssh_host_dsa_key
-rw------- 1 root admin 590 Sep 23 2011 /etc/ssh_host_dsa_key.pub
-rw------- 1 root admin 963 Sep 23 2011 /etc/ssh_host_key
-rw------- 1 root admin 627 Sep 23 2011 /etc/ssh_host_key.pub
-rw------- 1 root admin 1671 Sep 23 2011 /etc/ssh_host_rsa_key
-rw------- 1 root admin 382 Sep 23 2011 /etc/ssh_host_rsa_key.pub

In jedem Fall sollte man sicherstellen, dass sshd (unter SystemeinstellungenFreigabenEntfernte Anmeldung) aktiviert ist ;).

OpenIndiana: Panic beim Import eines ZFS-Pools

Eine OpenIndiana 151a2 Installation stellte plötzlich den Dienst ein. Beim Import des Root-Pools (rpool) gibt es eine System-Panic und das System steckt in einem Reboot-Cycle. Dummerweise befinden sich auch Daten im rpool, die es zu retten gilt. Hierzu muss ein USB-Bootmedium erzeugt werden (Wer will kann auch eine DVD dieses ISO-Files brennen.) um wieder Zugriff auf den Rechner zu bekommen: Zuerst das Live-USB-Image herunterladen. Unter Solaris/OpenIndiana kann das Image einfach mit usbcopy auf den Stick übertragen werden. Unter Linux und Mac OS X muss zusätzlich dieser Header heruntergeladen werden. Mit cat und dd werden dann beide Files auf den USB-Key übertragen:

cat 1G.header oi-dev-151a-x86.usb | dd bs=1024k of=/dev/USBDEVICE

/dev/USBDEVICE ist das raw-Device des USB-Sticks. Unter Linux so etwas wie /dev/sdg bzw. unter Mac OS X /dev/rdisk2. Das korrekte Device findet man leicht heraus, indem man die Ausgabe von dmesg betrachtet, nachdem man den USB-Stick mit dem Linux/Mac-Rechner verbunden hat. Weiterhin setzt die Codezeile voraus, dass sich Header- und Image-File im aktuellen Verzeichnis befinden.

Jetzt das Live-System booten. Vor dem Import des rpools folgende Zeilen ausführen

# sudo mdb -kw
> aok/W 0x1
> zfs_recover/E 0x1

Jetzt kann der rpool mittels

# sudo zpool import -f -o readonly=on -R /a rpool

im Nur-Lese-Zugriff unter der alternativen Root /a gemountet werden. Da das Filesystem read-only ist, kann zfs send nicht benutzen werden, um die Daten auf einen anderen Pool zu übertragen. Stattdessen habe ich sie stumpf mit rsync über das Netzwerk weggeschafft.

Shadow-Passwords erzeugen

Verschlüsselte Passwörter, wie sie in /etc/shadow gespeichert werden, kann man mit der folgenden Zeile für das Passwort password erzeugen:

# echo "password" | openssl passwd -1 -stdin $1$YFi.APLv$VZiopcJ9udPYifg/4E7vo/ 

Die Option -1 steht für den zu benutzenden MD5-Algorithmus. Die Ausgabe kann via Copy-Paste für den Benutzer USERNAME in die /etc/shadow eingefügt werden.

USERNAME:$1$YFi.APLv$VZiopcJ9udPYifg/4E7vo/:15132::::::

Diese Vorgehensweise ist dann nützlich, wenn man nicht auf Tools wie adduser oder useradd zurückgreifen kann oder will, weil beispielsweise separate passwd/shadow files für einen NIS-Server gepflegt werden. Zum Anlegen eines neuen Benutzers USERNAME muss noch eine Zeile wie die folgende zu /etc/passwd hinzugefügt werden:

USERNAME:x:541:100:Vorname Nachname (Kommentar):/home/USERNAME:/bin/bash

wobei 514 die userID und 100 die groupID des Benutzer sind.

Emacs: Sitzung sichern

Den Zustand des Emacs kann man durch den Aufruf

M-x desktop-save

einfrieren. Hierbei werden alle Buffer, deren Dateinamen, major modes und Positionen gesichert (M-x heißt meistens Altx bzw. x auf dem Mac). Wenn man nach dem Verzeichnis gefragt wird, gibt man am besten sein Home (~/) an. Hier wird eine Datei namens .emacs.desktop.lock angelegt.

Nach einem Neustart des Emacs kann man nun mit

M-x desktop-revert

den vorher gespeicherten Zustand wiederherstellen. Sollte Emacs kein Desktopfile finden kann, muss man mit

M-x desktop-change-dir

das korrekte Verzeichnis angeben. Wer dieses Verhalten grundsätzlich wünscht (also speichern der Sitzung beim beenden und automatisches Laden der letzten Sitzung beim Start von Emacs) trägt ins Initfile (~/.emacs) folgende Zeile ein:

 (desktop-save-mode 1)
Wenn kein Desktop wiederhergestellt werden soll, kann man Emacs mit der Option --no-desktop starten.

Emacs twittering-mode Benachrichtigungen

Wer sich gern von der Arbeit abhalten lässt oder einfach nichts besseres zu tun hat (wie ich), wird sich über die folgenden Zeilen freuen: Der Emacs twittering-mode (den ich hier und hier bereits vorgestellt habe) kann jetzt maximale Aufmerksamkeit fordern. Ich will kurz zwei Wege vorstellen, mit denen man sich über neue Tweets informieren lassen kann.

Emacs Minibuffer

Diese Variante ist eher unaufdringlich: Bei Eingang eines neuen Tweets, wird dieser mit dem Namen der :Timeline und des [Absender] im Minibuffer am unteren Ende des Emacsfensters angezeigt. Folgende Zeilen müssen hierzu in ~/.emacs eingefügt werden,

(add-hook 'twittering-new-tweets-hook (lambda ()
  (dolist (el twittering-new-tweets-statuses)
    (message
      (concat (twittering-timeline-spec-to-string twittering-new-tweets-spec) " ["
        (cdr (assoc 'user-screen-name el)) "] "
	(cdr (assoc 'text el)))))
    ))

was einen, sogenannten hook erzeugt, der beim eintreffen neuer Tweets ausgeführt wird. Das Ergebnis ist im Bild oben zu sehen.

Update: Emacs Modeline  (Danke an @cvmat)

Noch unaufdringlicher ist es, die Anzahl ungelesener Tweets in der Modeline anzeigen zu lassen (siehe Bild oben, tw(46)). Hierzu nach (require 'twittering-mode) folgende Zeile in ~/.emacs einfügen:

(twittering-enable-unread-status-notifier)

Desktop notification

Für echte Desktop notification benötigt man ein Hilfsprogramm. Unter Linux liegt den meisten Distributionen notify-send bei. Ich benutze hier Scientific Linux 6.2, wo man das Paket libnotify aus dem Standardrepository installieren muss. Folgender Code muss ~/.emacs hinzugefügt werden

(add-hook 'twittering-new-tweets-hook (lambda ()
  (let ((n twittering-new-tweets-count))
    (if (> n 10)
	(start-process "twittering-notify" nil "notify-send"
		       "-i" "/home/%USER%/.emacs.d/twittering-mode/misc/twitter-icon.svg"
	  (twittering-timeline-spec-to-string twittering-new-tweets-spec)
	  (format "You have %d new tweets" n ))
      (dolist (el twittering-new-tweets-statuses)
	(start-process "twittering-notify" nil "notify-send"
		       "-i" "/home/%USER%/.emacs.d/twittering-mode/misc/twitter-icon.svg"
	  (concat
	   (twittering-timeline-spec-to-string twittering-new-tweets-spec)
	   "\n"
	   (cdr (assoc 'user-screen-name el)))
	  (cdr (assoc 'text el))))
      ))))

%USER% muss durch den eigenen Benutzernamen ersetzt werden. Die Pfade im Codesnippet setzen voraus, dass die Installation von twittering-Mode nach dieser Anleitung vorgenommen wurde. Für jeden neuen Tweet (in jeder geöffneten Timeline) wird jetzt eine Sprechblase 5s lang auf dem Bildschirm erscheinen. Man kann selbstverständlich auch beide hooks nacheinander ausführen lassen. Wer offengelassene (Lisp-) Klammern findet, kann sie behalten. Und jetzt, frohes Ablenken-lassen.