Das Benutzerhandbuch für das LPAR-Tool ist nun auch in englischer Sprache im Download-Bereich verfügbar.
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:
- Download der aktuellen Version des LPAR-Tools aus dem Download-Bereich.
- Anfordern einer Trial-Lizenz.
- Installation des LPAR-Tools (Ist im Benutzerhandbuch beschrieben).
Viel Spaß beim Testen des LPAR-Tools!
/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
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.
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.
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
Wann wird ein cron-Job das nächste Mal gestartet
Der Dienst cron wird auf vielen Unix-Systemen ausgiebig verwendet. Die Möglichkeiten anzugeben, wann ein Kommando mittels cron gestartet werden soll, sind vielfältig. Hier erst mal einige Beispiel-Zeilen aus einer möglichen crontab eines Benutzers:
5 0 * * * /usr/local/bin/daily.job 15 14 1 * * /usr/local/bin/monthly.job 0 22 * * 1-5 /usr/local/bin/weekdays.job
Die Korn-Shell 93 (auf vielen Systemen als ksh93 verfügbar) bietet eine einfache Möglichkeit den nächsten Start eines cron-Jobs anzeigen zu lassen, und zwar mittels der eingebauten Funktion printf und der Format Angabe %T für Datumsausgaben:
ksh93 $ printf "%T\n" "5 0 * * *" Fr 19 Jan 00:05:00 2018
Man verwendet als erstes Argument im Format-String das %T für Datum und gibt im entsprechenden Argument (hier das zweite) die Intervall-Angabe aus dem crontab-Eintrag an. Das Resultat ist in diesem Fall der Zeitpunkt wann der Job daily.job aus dem Beispiel oben das nächste Mal gestartet wird.
Hier ein Beispiel für den zweiten Job monthly.job:
ksh93 $ printf "monthly.job: %T\n" "15 14 1 * *" monthly.job: Do 1 Feb 14:15:00 2018
Arbeitet man nicht in der ksh93 selbst, dann kann man die folgende Variante nutzen:
bash $ ksh93 -c 'printf "%T\n" "0 22 * * 1-5"' Do 18 Jan 22:00:00 2018
Hinweis: Auf einigen Systemen ist die Korn-Shell 93 als ksh verfügbar. Das kann man mit dem folgenden Kommando überprüfen:
$ ksh $ print ${.sh.version} Version AJM 93u+ 2012-08-01
Im AIX-Talk crontab & cron wird die Datumsausgabe für crontab-Einträge demonstriert.
Mounten eines ISO-Images
Natürlich lässt sich mit dem im letzten Beitrag vorgestellten Kommando /usr/sbin/loopmount auch ein ISO-Image mounten:
# loopmount -i /path/to/iso/image.iso -o „-o ro -V cdrfs“ -m /mnt
Unmounten und löschen des erzeugten loopback Devices geht dann mit /usr/sbin/loopumount:
# loopumount -l loopX -m /mnt
Erzeugen eines jfs2-Filesystems in einer Datei
In diesem Beitrag soll das Erzeugen eines jfs2-Filesystems in einer Datei beschrieben werden. Gelegentlich gibt es Situationen, in denen man ein Filesystem braucht, man aber nicht die Möglichkeit hat ein Filesystem in einem Logical Volume zu verwenden. Falls dies der Fall sein sollte, existiert eine Möglichkeit dennoch zu einem Filesystem zu kommen, indem das Filesystem in einer Datei erzeugt wird.
Zunächst muss man eine Datei anlegen, in welcher das jfs2-Filesystem angelegt werden soll. Wobei diese auch in einem per NFS gemounteten Filesystem liegen könnten:
# lmktemp /path/to/file 1000m
Hier kann man jedoch nicht g für GB angeben. Die Datei kann natürlich auch mit anderen Kommandos (z.B. dd) erzeugt werden. Damit man auf die Datei zugreifen kann, muss nun aber ein Gerät für diese Datei erzeugt werden. Unter AIX gibt es hierfür den Gerätetyp loopback. Standardmäßig werden diese Geräte mit loop und einer fortlaufenden Nummer benannt.
Mittels lsdev kann leicht überprüft werden, ob man schon ein solches Device hat:
# lsdev -l loop\*
Mit dem Kommando /usr/sbin/loopmount kann man dann ein solches Gerät erzeugen:
# loopmount -i /path/to/file
Jetzt sollte es damit auch ein neues loopback Device geben:
# lsdev -l loop\* loop0 Available Loopback Device # lsattr -El loop0 filename /tmp/bigfile Name of the image file to be associated with the device True temporary yes Determines if the device should be removed at boot time True
Nun kann auf dem loopback Device ein jfs2-Filesystem erzeugt werden:
# mkfs -V jfs2 -o log=INLINE /dev/loop0 mkfs: destroy /dev/loop0 (y)? y logform: Format inline log for <y>?y File system created successfully. 1015572 kilobytes total disk space. Device /dev/loop0: Standard empty file system Size: 2031144 512-byte (DEVBLKSIZE) blocks
Das erzeugte Filesystem kann nun gemountet werden. Das Kommando mfks darf nicht noch einmal ausgeführt werden, wenn die Datei schon ein jfs2-Filesystem beinhaltet. Zum Mounten eines Filesystems in einer Datei gibt es das spezielle Kommando loopmount:
# loopmount -l loop0 -o "-V jfs2 -o log=INLINE" -m /mnt
Alternativ kann das Filesystem auch mit dem Kommando mount gemountet werden:
# mount -V jfs2 -o log=INLINE /dev/loop0 /mnt
Das Filesystem kann nun normal benutzt werden.
# df -g /mnt Filesystem GB blocks Free %Used Iused %Iused Mounted on /dev/loop0 0.98 0.97 1% 4 1% /mnt
Das Filesystem kann ganz einfach wieder entfernt werden, wenn es nicht mehr benötigt wird:
# loopumount -l loop0 -m /mnt
Das Filesystem wird ausgehangen und das loopback Device wird gelöscht (falls das Attribut temporary auf yes gesetzt ist, das ist der Default für loopback Devices).
Die Datei muss aber manuell gelöscht werden, wenn diese nicht mehr benötigt wird:
# rm /path/to/file
Wir hoffen dieser Beitrag über das Erzeugen eines jfs2-Filesystems in einer Datei war sowohl informativ als auch hilfreich!
Sicherheitslücken bei Prozessoren
Seit einigen Tagen wird in den Medien ausführlich über aktuell bestehende Sicherheitslücken bei Prozessoren berichtet. Auch IBM Server Systeme sind betroffen.
Stetig aktualisierte Informationen und weitere wichtige Hinweise können Sie über den folgenden Link bekommen:
https://www.ibm.com/blogs/psirt/potential-cpu-security-issue/