Blog

Veröffentlicht am

Das Kommando ‚who -r‘ liefert keinen Run-Level zurück

Auf einem unserer Systeme lieferte das Kommando „who -r“ keine Ausgabe und auch keinen Fehler:

$ who -r
$ echo $?
0
$

In Folge dessen kam es zu einem Fehler bei einem Installationsskript, welches den Run-Level nicht ermitteln konnte.

Das Kommando „who -r“ bekommt die Information über den Run-Level aus der binären Log-Datei /etc/utmp. Der Run-Level eines Systems wird im zweiten Record der Datei festgehalten. Die Vermutung war, das die /etc/utmp korrupte Einträge enthält.

Mit dem Kommando /usr/sbin/acct/fwtmp (bos.acct) können binäre utmp-Records nach ASCII konvertiert werden (und umgekehrt). Das Kommando erwartet die zu konvertierenden Einträge über die Standard-Eingabe. In unserem Fall ergab sich folgendes:

$ cat /etc/utmp | /usr/sbin/acct/fwtmp
                        system boot   2     0 0000 0000 1484666008                                  Tue Jan 17 16:13:28 CET 2017
root                                  0 804397248 0000 0000          0 \ufffd{\ufffd\ufffd                             Thu Jan  1 01:00:00 CET 1970
         naudio                       8 3473526 0000 0000 1484666008                                  Tue Jan 17 16:13:28 CET 2017
         naudio2                      8 3539068 0000 0000 1484666008                                  Tue Jan 17 16:13:28 CET 2017
...

Die Ausgabe bestätigt das der zweite Record korrupt ist, er sollte eigentlich den Run-Level enthalten. Ein Vergleich mit den Einträgen eines anderen Systems zeigt wie der korrekte Eintrag aussehen sollte:

                        system boot   2     0 0000 0000 1545044734                                  Mon Dec 17 12:05:34 2018
                        run-level 2   1     0 0062 0123 1545044734                                  Mon Dec 17 12:05:34 2018

Wir haben dann zunächst eine Kopie der korrupten /etc/utmp gemacht und anschließend eine ASCII-Version in einer Datei abgespeichert um dann den korrupten Eintrag mit einem Editor zu korrigieren:

# cp /etc/utmp /etc/utmp.orig
# cat /etc/utmp | /usr/sbin/acct/fwtmp -X -L >/etc/utmp.ascii
#

Die Optionen -X und -L sorgen dafür das User- und Host-Namen nicht verkürzt werden.

Nun wird die zweite Zeile korrigiert, indem wir diese durch den Eintrag oben von einem funktionierenden System ersetzen und dann noch die Zeit-Stempel vom ersten Datensatz übernehmen. Insgesamt ergibt sich dann der folgende Inhalt:

                        system boot   2     0 0000 0000 1484666008                                  Tue Jan 17 16:13:28 CET 2017
                        run-level 2   1     0 0062 0123 1484666008                                  Tue Jan 17 16:13:28 CET 2017
         naudio                       8 3473526 0000 0000 1484666008                                  Tue Jan 17 16:13:28 CET 2017
...

Abschließend konvertieren wir die korrigierte ASCII-Version wieder in das binäre Format und Speichern die korrigierte Version unter /etc/utmp ab:

# cat /etc/utmp.ascii | /usr/sbin/acct/fwtmp -ic > /etc/utmp
#

Das Kommando „who -r“ liefert nun wieder den Run-Level zurück:

$ who -r
   .        run-level 2 Jan 17 16:13       2    0    S
$

Das Problem ist damit behoben.

Veröffentlicht am

LPAR-Tool ist ab sofort verfügbar

Ab 05.11.2018 ist das LPAR-Tool nun offiziell verfügbar!

Im Download-Bereich kann eine Version für Linux heruntergeladen werden (Versionen für AIX und MacOS folgen in Kürze), außerdem steht das Benutzerhandbuch für das LPAR-Tool dort ebenfalls zum Download bereit.

Um das LPAR-Tool kostenfrei zu Testen ist folgendes notwendig:

  1. Download der aktuellen Version des LPAR-Tools aus dem Download-Bereich.
  2. Anfordern einer Trial-Lizenz.
  3. Installation des LPAR-Tools (Ist im Benutzerhandbuch beschrieben).

Viel Spaß beim Testen des LPAR-Tools!

Veröffentlicht am

/usr/sbin/rpm_share[440]: 36044986 Illegal instruction

Obige Fehlermeldung ist bei der Installation eines RPM-Pakets aufgetreten:

# rpm -U db4-4.7.25-2.aix5.1.ppc.rpm 
/usr/sbin/rpm_share[440]: 36044986 Illegal instruction
rpm_share: 0645-007 ATTENTION: get_rpm_inst_root_list() returned an unexpected result.
rpm_share: 0645-007 ATTENTION: update_inst_root() returned an unexpected result.

Das rpm-Kommando funktioniert nicht mehr, ein Rebuild der RPM-Datenbank ist damit auch nicht mehr möglich:

# rpm --rebuilddb
/usr/sbin/rpm_share[470]: 22478966 Illegal instruction

Abhilfe schafft hier das Fileset rpm.rte noch einmal zu installieren:

# installp -acFXYd . rpm.rte
+-----------------------------------------------------------------------------+
                    Pre-installation Verification...
+-----------------------------------------------------------------------------+

...

Installation Summary
--------------------
Name                        Level           Part        Event       Result
-------------------------------------------------------------------------------
rpm.rte                     4.13.0.3        USR         APPLY       SUCCESS    
rpm.rte                     4.13.0.3        ROOT        APPLY       SUCCESS

Im Anschluß funktioniert auch das rpm-Kommando wieder:

# rpm -qa
...
db4-4.7.25-2.ppc
...
AIX-rpm-7.1.5.15-7.ppc

 

 

Veröffentlicht am

sshd: fatal: permanently_set_uid: was able to restore old [e]gid

Beim Versuch sich auf einem System per ssh einzuloggen bekommt ein Benutzer die folgende Meldung:

$ ssh mars

Connection to mars closed by remote host.

Connection to mars closed.

$

Auf dem Server findet man die folgende Fehlermeldung:

Jul 16 19:57:24 mars auth|security:info sshd[51511616]: Accepted publickey for user5 from X.X.X.X port 57523 ssh2
Jul 16 19:57:24 mars auth|security:crit sshd[49414624]: fatal: permanently_set_uid: was able to restore old [e]gid

Die Ursache des Problems, ist in diesem Fall, das der betreffende User zum einen lokal angelegt ist:

$ lsuser -R files user5
user5 id=1005 pgrp=staff groups=staff home=/home/user5 shell=/usr/bin/ksh

Zum anderen aber auch über einen Namensdienst (hier LDAP) existiert, allerdings mit unterschiedlichen Gruppen:

$ lsuser -R LDAP user5
user5 id=1005 pgrp=develop groups=develop home=/home/user5 shell=/bin/bash gecos=XXXX

Der Benutzer soll eigentlich aus LDAP kommen, vor der Anbindung an LDAP gab es den Benutzer aber schon lokal. Nach der Anbindung an LDAP wurde vergessen den lokalen Benutzer-Account zu löschen.

Nachdem der lokale Benutzer-Account gelöscht wurde:

# rmuser -R files -p user5

funktioniert der SSH-Login auch wieder korrekt.

 

Veröffentlicht am

PVID / erster Block sichern

Manchmal kommt es vor, dass durch div. hdisk Operationen die PVID gelöscht wird und die Platte mit ihren Daten nicht mehr erkennbar ist für AIX. Da ist es gut wenn man eine Sicherung der PVID hat 😉
Das geht so:

dd if=/dev/hdiskXX of=hdiskXX.block1 bs=512 count=1

zurückschreiben:

dd if=hdsikXX.block1 of=/dev/hdiskXXbs=512 count=1
Veröffentlicht am

Welche HMC gehört zu einer LPAR

In der Regel weiß ein Administrator welche LPAR von welcher HMC verwaltet wird. In größeren Umgebungen, mit hunderten von LPARs und vielen HMCs, kann es aber trotzdem vorkommen, das man die Zugehörigkeit nicht mit Sicherheit kennt. Ist man auf einer LPAR eingeloggt, und hat diese eine aktive RMC-Verbindung zur HMC, dann kann man auf einfache Weise die HMC bzw HMCs herausfinden:

$ lsrsrc IBM.MCP
Resource Persistent Attributes for IBM.MCP
resource 1:
...
        KeyToken          = "hmc01"
        ...
        HMCName           = "7042CR6*XXXXXXX"
        HMCIPAddr         = "N.N.N.N"
...
resource 2:
...
        KeyToken          = "hmc02"
...
        HMCName           = "7042CR6*XXXXXXX"
        HMCIPAddr         = "N.N.N.N"
...

Die „resource 1“ stellt die erste HMC dar und, falls vorhanden, die „resource 2“ die zweite HMC. Das Attribute „KeyToken“ gibt den Namen der HMC an, das Attribute „HMCName“ ergibt das Model und die Seriennummer der HMC (hier durch XXXXXXX ersetzt). Das Attribut „HMCIPAddr“ liefert die IP-Adresse der HMC, hier durch N.N.N.N ersetzt.

Veröffentlicht am

ssh: PTY allocation request failed on channel 0

Manchmal kann es vorkommen, das ein SSH-Login auf ein System fehlschlägt, mit der obigen Meldung:

$ ssh aix09
PTY allocation request failed on channel 0

Es konnte kein Pseudo-Terminal mehr alloziert werden, d.h. alle verfügbaren Pseudo-Terminals sind schon in Benutzung. Dies hat in der Regel eine von 2 Ursachen:

  • Entweder sind tatsächlich schon alle Pseudo-Terminals in Verwendung, weil es z.B. extrem viele Logins auf das System gibt, oder
  • die Pseudo-Terminals sind vom Kernel nicht korrekt freigegeben worden.

Als erstes stellt sich die Frage wie man dennoch auf die Maschine kommt, ohne z.B. die Konsole benutzen zu müssen. Mit einer der beiden folgenden Varianten sollte man sich auf das System mit SSH einloggen können:

$ ssh aix09 bash -i
bash: cannot set terminal process group (-1): A specified file does not support the ioctl system call.
 bash: no job control in this shell
aix09 $
oder
$ ssh aix09 ksh -i
aix09 $

Ist man nun eingeloogt, kann man zunächst untersuchen, ob tatsächlich alle Pseudo-Terminals in Verwendung sind. Das geht am einfachsten mit Hilfe des Kommandos fuser:

aix09 $ cd /dev/pts
aix09 $ fuser *
0:66126088
1:60096860
...
254:  62062964
255:  59310558

Die Anzahl der verfügbaren Pseudo-Terminals ist durch das Attribut ATTnum des Geräts pty0 bestimmt:

aix09 $ lsattr -El pty0
ATTnum     256       Maximum number of Pseudo-Terminals     True
BSDnum     16        Maximum number of BSD Pseudo-Terminals True
autoconfig available STATE to be configured at boot time    True
csmap      sbcs      N/A                                    True

Die Anzahl lässt sich leicht mit dem chdev Kommando erhöhen:

aix09 # chdev -l pty0 -a ATTNum=368
pty0 changed

Es stehen sofort die zusätzlichen Pseudo-Terminals zur Verfügung, was man nach dem Einloggen mittels SSH auch mit dem Kommando tty überprüfen kann:

aix09 $ tty
/dev/pts/256
Veröffentlicht am

PVID manuell setzen

Manchmal kann man es brauchen, die eigene PVID auf einer hdisk 🙂

Es ist gar nicht so schwer. Die gewünschte hexadezimale PVID muss erst in oktal umgewandelt werden. Zum Beispiel:

PVID 00f78f7be1815e7d
hex  oktal
0    0
f6   367
8f   317
7b   173
e1   341
81   201
5e   136
7d   175

So einfach gehts:

# echo "\0000\0367\0317\0173\0341\0201\0136\0175\c" | \ 
> dd of=/dev/hdiskX bs=1 seek=128 
8+0 records in 
8+0 records out

Oder 🙂

# echo "\0000\0000\0000\0000\0000\0000\0000\0001\c" | \
> dd of=/dev/hdiskX bs=1 seek=128

Mehr dazu gibt es in diversen Videos im Bereich „Advanced Administration“