Schulze-EDV-Service Home - AIX Support - Neuigkeiten

Information zur SP2

Authentifizierung

spsetauth Nach ausführend es Kdos wird beim nächsten Neustart des Knotens wird auf dem Knoten eine .rhosts der SP Umgebung erstellt.
lsauthent Zeigt die verwendete Authentifizierungsmethode an.
chauthent Nur bei Auswahl std ist hinterher noch ein Telnet möglich.
chauthpar Setzt Authentifizierungsmethode auf der CWS/den Knoten und trägt sie in SDR ein.

<Top>

Hostname-Änderung eines sp-node ohne IP-Änderung

Im Gegensatz zu den zehnseitigen Anleitungen von IBM beim Änderung von Hostname UND IP-Adresse ist der reine Austausch des Hostname schnell und einfach zu bewerkstelligen. Man braucht auch nicht irgendwelche Krücken zu nutzen á la „Wir löschen Adapter xy in der SDR, ändern den hostname und nehmen den Adapter dann wieder mit additional adapters auf“ Man muß sich lediglich über die Unterschiede zwischen

im klaren sein. Bei einer Maschine mit nur einem Adapter ist das etwas müßig, bei zwei und mehr Adaptern macht es viel Sinn bzw. eröffnet viele Möglichkeiten. In der /etc/hosts steht das ip-label, der Befehl hostid setzt hostnamen (kann auch an anderen Adaptern als en0 festgemacht werden) und uname ist der Systemname. Diese Aufteilung wird z.B. bei HACMP genutzt, wenn Clients sich mit einem ip-label verbinden und nicht mit dem hostname. Bei Ausfall eines Adapters wird die IP-Adresse auf einen anderen Adapter verschoben und Clients verbinden sich wieder. Im HACMP Cluster geht das so schnell, daß z.B. eine Telnetverbindung nur kurz 'hustet' und anschließend weiter funktioniert. Man hat außerdem die Möglichkeit für verschiedene Zwecke verschiedene Bezeichner abzufragen um eine Maschine zu identifizieren, z.B. prüft Tivoli i.d.R. den Systemnamen mit uname während NetView den hostname abfragt.

Die Schritte für die hostname Änderung ohne IP-Adressenänderung, ausgeführt von root, im einzelnen:

1. Eintragen des neuen Hostname in /etc/hosts auf cws (und der betroffenen Maschine selbst), und zwar sollten dort sowohl die long als auch die short form des Namens eingetragen sein (aixhost.ibm.com aixhost). Wenn der Name nicht aufgelöst werden kann, funktioniert die ganze Aktion nicht.

2. sphostnam -a <bezogener Adapter> <frame-no> <slot-no in frame> <nodecount>, z.B. also

# sphostnam -a en1 3 13 1 -f short = lese Hostname für Interface en1 im Frame 3 Knoten 13 nur diesen einen Knoten in der Kurzform.

Das Ergebnis kann unmittelbar danach mit splstdata -n überprüft werden. Ohne spezielle Aufforderung setzt sphostnam die long form des hostname in der /etc/hosts voraus.

3. spbootins -r customize <frame-no> <slot-no in frame> <nodecount>, z.B. also

# spbootins -r customize 2 11 2 = setze Knoten 11 und den folgenden Knoten auf customize, lösche Kerberos Dateien und laß setup_server laufen. (Holla, der Knoten gehört zu einem HACMP-ES-Cluster? Gehe noch nicht über Los, sondern konfiguriere Kerberos per Skript neu!!)

4. Auf den Knoten hostname und ggf. Systemnamen (uname) ändern. Hostname am schnellsten mit smitty hostname, Systemnamen mit uname -S <neuer_uname>.

Dann reboot des/der Knoten, fertig. Achtung: smitty hostname setzt en0 als Adapter, wird ein anderer Adapter gemeint können die Befehle chdev -l inet$ -a hostname=$1; hostid 'hostname' und piodmgr -c >/dev/null 2>&1 manuell abgesetzt werden. Letzterer komprimiert die ODM neu, dieser Schritt wird von smitty ansonsten automatisch miterledigt.

Man kann die customize - Operation auch ohne reboot ausführen, indem man das Skript /spdata/sys1/install/pssp/pssp_script aufruft. Ein reboot schadet aber nicht, insbesondere wenn die Maschine schon ein paar (viele) Monate läuft. So oder so, danach sollte die boot-response des entsprechenden node wieder auf „disk“ stehen.

Top

Firmware upgrade SP node

Bei den SP Knoten gilt diese Beschreibung für System Firmware und für Service Processor. ACHTUNG: das Upgrade setzt einen reboot des Knoten zwingend voraus. Die Beschreibung gilt für Silver-Wide-Nodes.

Vor dem Upgrade stellt man zweckmäßiger Weise fest, welcher Level bereits installiert ist.

Interessant sind die jeweiligen ROM Level (alterable).

Zunächst werden die Firmwaredateien in das /tmp/fwupdate Verzeichnis gestellt, man kann sie aber auch direkt ins /var Verzeichnis kopieren. Aus dem /var Verzeichnis heraus wird das update durchgeführt. Das Kommando lautet:

# /usr/sbin/shutdown -Fu /var/<FIRMWARE.img>

Wenn System Firmware und Service Processor Firmware upgedatet werden müssen, dann ist zwingend zuerst die System Firmware zu aktualisieren! Der Knoten wird sich neu starten. Nach dem Upgrade sollten die .img Dateien aus dem /var Verzeichnis gelöscht werden.

Firmware Upgrade auf einer S80

<Top>

SP-Switch Probleme

Über den High Performance Switch wird die SP-interne Kommunikation abgewickelt. Die theoretische Maximalgeschwindigkeit ist 150MBit bidirektional, dies ist deutlich schneller als z.B. Fast-Ethernet mit 10MBit. Damit der Switch richtig funktioniert, muß er auf der cws konfiguriert sein und auf den zur SP gehörenden nodes muß der fault_service_worm_daemon laufen. Beides wird beim Booten aus der /usr/lpp/ssp/css/rc.switch erledigt, das aus der inittab aufgerufen wird. Danach taucht der css0 als konfiguriert auf, ist aber down (*) und der primary ist nicht am switch, die switch_responds steht auf 0.

spn03# netstat -in

Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll

en0 1500 <Link> 8.0.5a.1b.a4.cd 153498 0 187450 0 0

en0 1500 172.16 172.16.10.3 153498 0 187450 0 0

css0* 65520 <Link> 0 0 0 0 0

css0* 65520 192.168 192.168.1.3 0 0 0 0 0

spcws1# SDRGetObjects switch_responds

node_number switch_responds autojoin isolated adapter_config_status

1 0 0 1 css_ready

3 1 0 1 css_ready

5 1 0 1 css_ready

7 1 0 1 css_ready

9 1 0 1 css_ready

11 1 0 1 css_ready

13 1 0 1 css_ready

15 1 0 1 css_ready

spcws01#

Bei node 1 ist die switch_responds gleich 0, der node ist also nicht am switch. Man prüft nun zunächst ob der switch selbst läuft:

spcws01# Eprimary

Wenn der primary auf "none" steht, muß der switch erst gestartet werden:

spcws01# Estart

oder

spcws01# Estart -autounfence 0

Danach checkt man, ob auf dem/den betroffenen node(s) der fault_service_worm_daemon läuft und der switch-Adapter des node konfiguriert ist. Falls nein, muß auf der cws das Skript /usr/lpp/ssp/css/rc.switch gestartet werden. Wenn dann der switch läuft und der faul_service_worm_daemon auf der node läuft, kann sie unfenced werden. In diesem Beispiel also:

spcws01# Eunfence 1

Läßt sich der Knoten mit dem Eunfence Kommando nicht unfencen, kann man versuchen den Switch ohne die „-autounfence 0“option zu starten. Ein Estart mit autounfence macht offenbar noch etwas anderes als das Eunfence Kommando d.h. ist beim unfencen öfter auch dann noch erfolgreich, wenn ein Eunfence fehlschlägt.

Top

Fehlermeldung „No topology“ beim Start des switch

Wenn beim Start des switch von einem oder mehreren nodes die Rückmeldung kommt, daß sie ihre Topologie nicht (mehr) kennen, müssen die Subsysteme der SP-Partition neu initialisiert werden. Dies gelingt am schnellsten (im lfd. Betrieb) mit dem Befehl

spcws01# syspar_ctrl -R

Danach muß der switch auf der cws und der fault_service_worm_daemon auf den nodes neu gestartet werden:

spcws01# Estart -autounfence 0

spcws01# dsh /usr/lpp/ssp/css/rc.switch

Den Erfolg bzw. Mißerfolg prüft man, indem man die nodes abfragt ob sie unfenced bzw. fenced sind:

spcws01# SDRGetObjects switch_responds

Nodes, die „isolated“ sind müssen wieder an den switch gebracht werden.

spcws01# Eunfence <node_number>

Top

Der switch muß neu initialisiert werden

Diese Aktion wird mit Hilfe des topology file weitgehend automatisch durchgeführt. Man prüft zunächst, wie die aktuelle Version dieser Datei heißt und initialisiert den switch anschließend neu. Dabei wird die interne Kommunikation des switch für die gesamte Partition unterbrochen und neu aufgebaut, alle dazugehörenden Prozesse neu gestartet.

spcws01# SDRGetObjects Switch_partition topology_filename

topology_filename

annotated.2nsb.0isb.3

spcws01# Eannotator -F /etc/expected.top.2nsb.0isb.3 -f /etc/SP/annotated.top.2nsb.0isb.3 -O yes

Top

SP Knoten platt machen

Wer RS/6000 Hardware geleast hat, steht oft vor dem Problem, daß er die Systeme bei Rückgabe an den Leasinggeber von den Kundendaten befreit werden müssen. Bei SP Knoten geht das am schnellsten mit:

# spbootins -r maintenance <frame> <slot> <node count>

Eprimary darf auf diese Weise nicht „behandelt“ werden, falls das gewünscht ist, muß der Befehl auf Eprimary als letztes angewendet werden, da die Information für den Switch bis zuletzt vorhanden sein muß.

Top

SP-Ethernet MAC Adressen

Die MAC Adressen für en0 sollten in der /etc/bootptab.info stehen. Von dort werden sie von NIM gelesen, wenn setup_server läuft. (Der bootp eines Knoten schlägt fehl, wenn der NIM client die falsche MAC-Adresse hat.)

# dsh "lscfg -vl ent0"

# SDRGetObjects Node hdw_enet_addr

# pg /etc/bootptab.info

# lsnim -l  | grep if1

Top

Switch- und Host Responds in der SDR zurücksetzen

Manchmal läßt sich ein Knoten nicht zurück an den Switch bringen, so daß man gezwungen ist, mit der SDR zu arbeiten. In solchen Fällen helfen die folgenden Kommandos:

# SDRChangeAttrValues host_responds host_responds=0

# SDRChangeAttrValues switch_responds isolated=0

Überprüfen kann man den Erfolg mit

# spmon -d -G

oder

# SDRGetObjects switch_responds

Top

Statusabfragen
Befehl Einsatzmöglichkeit
spmon -d -G Prüft Frame und Knoten, zeigt switch und host responds, front panel lcd, Art des Knoten (thin, wide, high) etc.
spmon -L <frame> <node> Zeigt LED von Knoten <node> im Frame <frame>
spgetdesc -au Prozessorarchitektur der Knoten
splstdata -n Knoten Konfigurationsinformation: initial_hostname, reliable_hostname, default_route, processor_type, processors_installed etc.
splstdata -b Knoten Boot-/Installationsinformation: hostname, MAC-Addr., install_disk, last_install_image, last_install_time, lppsource_name, pssp_ver etc.
SDRGetObjects switch_responds Zeigt alle css Schnittstellen und ihren aktuellen Status. Zeigt, ob Knoten auf autojoin stehen.
CSS_test Switch Test, gute Ergänzung zu spmon -d -G

<Top>
Kontrolle
Befehl Einsatzmöglichkeit
spmon -p on/off nodeX Strom an/aus Knoten xx
spmon -r nodeX Reset. Wenn der Schlüssel auf service steht, wird damit ein Dump ausgelöst. Rückmeldungen sind dann:
  • 0c2 Dump läuft noch
  • 0c4 Dump fehlgeschlagen (Platzmangel im Dumpdevice)
  • 0c0 Dump fertig
spmon -k service/normal nodeX Schlüsselschalter auf Stellung service/normal
s1term -w <frame> <node> Konsolenverbindung (-w = schreiben möglich, sonst nur sehen) auf Knoten <node> im Frame <frame>
spbootins -r disk -l xx Zwingt den Knoten, von Platte zu booten. Diesen Befehl sollte man immer absetzen, wenn man im maintenance mode booten möchte, auch wenn der Knoten bereits auf booten von Platte steht.
spbootins -r maintenance -l xx Zwingt den Knoten, in den Wartungsmodus zu booten. Setze dann ein shutdown -Fr ab und warte bis LED c31 auftaucht. Dann öffne ein s1term um die Wartung durchzuführen.
Efence (-autojoin) xx Fenced den Knoten (und aktiviert die autojoin Option damit der Knoten automatisch wieder an den Switch kommt)
Eunfence xx Unfenced den Knoten und bringt ihn zurück an den Switch (meistens...:-))

<Top>
Kerberos Kommandos
k4list Zeigt existierende Kerberos Ticket-Granting-Tickets an, diese gelten i.d.R. einen Monat und müssen nach Ablauf erneuert werden. Vgl. lskp
k4init Erzeugt neue Kerberos Tickets, Aufruf mit „k4init root.admin“. Es ist das Kerberos Passwort einzugeben.
kdestroy Zerstört existierende Kerberos Tickets (des users, der das Kdo absetzt).
kstash Legt den Kerberos Master Key im /.k file ab. Ohne den Master Key Cache funktionieren der kerberos und kadmind Daemon nicht.
lskp Listet die Kerberos principals auf.
kadmind Daemon für die Authentifizierungs Datenbank. Wird mit SRC gestartet. Nicht zu verwechseln mit dem Kommando kadmin
kerberos Daemon für den Authentifizierung Ticket-Granting-Ticket service daemon.
ksrvutil list Zeigt lokale Services und Ihr service key number (aus der service key list) an.
k4list -srvtab Zeigt ebenfalls service key number aus der service key list an.
chkp Ändert Ticket Lebensdauer / Verfallsdatum
kadmin Kdo. zum erzeugen des Principals. (Eines von mehreren mögl. Kdos)
mkkp make kerberos principal
rmkkp remove kerberos principal
lskp list kerberos principal
kdb_edit Ändert Principal Attribute (z.B. Paßwort)

<Top>