Angeregt durch den Heldenfeed, hier meine Liste der Software-Werkzeuge mit denen ich meinen Job meistere:
Editor: Emacs 23
Schnell&Einfach Editor: vi oder ed (letzteren gerne auch verscripted)
Shell: ksh93 - Davids Shell im vi Mode ist einfach super smart
Browser: Firefox
Mail-Client: gnus.el in Emacs, Outlook im Citrix (leider)
Aufgaben-Verwaltung: org-mode...im Emacs ;)
Allzweck-Waffe: Emacs ,) (mit tramp-mode in Verbindung mit ediff-directories ergeben sich irre Möglichkeiten - recursive diff von Property-Files auf verschiedenen Systemen...)
Versionsverwaltung: subversion, mercurial
Compiler: Sun Studio 11/12, selten gcc
Datenbank: PostgreSQL
OS: Solaris
Performance-Datensammlung: Home-grown psql+sar+ksh+CGI -> LoadDB
Bei mir zuhause sieht es nicht viel anders aus - ausser das es noch einen Mac gibt mit dem das ein oder andere Urlaubsvideo geschnitten wird.
Und auf meinem Server läuft ein
OS: OpenIndiana
WebServer: Apache 2.2
CMS: Magnolia
Mail: Dovecot/sendmail
Posts mit dem Label Solaris werden angezeigt. Alle Posts anzeigen
Posts mit dem Label Solaris werden angezeigt. Alle Posts anzeigen
Montag, 30. Januar 2012
Mittwoch, 10. August 2011
exec() umbiegen mit dtrace
Um unliebsame Programmaufrufe zu verhindern, ohne an den Programmen selber Modifikationen vornehmen zu müssen eignet sich auch dtrace.
(607) oldn90700:/home/olbohlen$ cat foobar.ksh
#!/bin/ksh
echo true
(608) oldn90700:/home/olbohlen$ ./foobar.ksh
August 10, 2011 03:02:18 PM CEST
Wie geht das?
Man schaltet für DTrace den destructive mode ein und fängt mittels syscall provider die exec* syscalls ab zum entry Zeitpunkt. Dann modifiziert man arg0 für den exec() und das wars dann auch schon:
Sehr spannend was DTrace alles kann :)
(607) oldn90700:/home/olbohlen$ cat foobar.ksh
#!/bin/ksh
echo true
(608) oldn90700:/home/olbohlen$ ./foobar.ksh
August 10, 2011 03:02:18 PM CEST
Wie geht das?
Man schaltet für DTrace den destructive mode ein und fängt mittels syscall provider die exec* syscalls ab zum entry Zeitpunkt. Dann modifiziert man arg0 für den exec() und das wars dann auch schon:
(717) oldn90700:/root# cat preve*
#!/usr/sbin/dtrace -s
#pragma D option destructive
syscall::exec*:entry
/copyinstr(arg0) == "./foobar.ksh" /
{
printf("exec arg0: %s\n", copyinstr(arg0));
copyout("/usr/bin/date", arg0, 14);
}
#!/usr/sbin/dtrace -s
#pragma D option destructive
syscall::exec*:entry
/copyinstr(arg0) == "./foobar.ksh" /
{
printf("exec arg0: %s\n", copyinstr(arg0));
copyout("/usr/bin/date", arg0, 14);
}
Sehr spannend was DTrace alles kann :)
Freitag, 1. April 2011
OpenIndiana NWAM
Beim Versuch unter JDS in OpenIndiana dem NWAM eine statische IPv6 Adresse zu konfigurieren, musste ich erleben das der Eintrag offenbar nicht zieht, sprich das Feld leer ist und auch nicht in die Config übernommen wird.
Work-Around:
cd /etc/nwam
vi ncp-.conf
und dann in der Config-Zeile fürs korrekte Interface (bei mir e1000g0) ein
"ipv6-addr=string,2001:dead:beef:feed:face::50/80 eintragen.
Danach einmal die Location wechseln und schon zieht NWAM.
Work-Around:
cd /etc/nwam
vi ncp-
und dann in der Config-Zeile fürs korrekte Interface (bei mir e1000g0) ein
"ipv6-addr=string,2001:dead:beef:feed:face::50/80 eintragen.
Danach einmal die Location wechseln und schon zieht NWAM.
Freitag, 25. März 2011
ps -ef hängt?
Wenn ps -ef "hängt" wirds ersteinmal nicht ganz einfach herauszufinden, welcher Prozess dafür verantwortlich ist. Meisstens hängt ein bestimmter Prozess, was es ps unmöglich macht unter /proc/PID/ die Prozessstruktur zu lesen. ps printed dann leider nicht mehr die Zeile mit de entsprechenden PID.
Es gibt aber einen schönen Hack:
cd /proc
(for pid in *; do echo $pid; file $pid/auxv >/dev/null 2>&1; done) &
Die letzte ausgegebene PID ist unser Kandidat. An dieser Stelle verweise ich auf meinen letzten Blog Eintrag, wie man per mdb weitere Schlüsse ziehen kann.
Es gibt aber einen schönen Hack:
cd /proc
(for pid in *; do echo $pid; file $pid/auxv >/dev/null 2>&1; done) &
Die letzte ausgegebene PID ist unser Kandidat. An dieser Stelle verweise ich auf meinen letzten Blog Eintrag, wie man per mdb weitere Schlüsse ziehen kann.
Mittwoch, 23. Februar 2011
hanging process on solaris
Got a hanging process on Solaris 10 today.
It was a netbackup process writing to a tape-device with the PID 19177.
So I fired up mdb -k:
> 0t19177::pid2proc |::walk thread |::findstack -v
stack pointer for thread 30007a49800: 2a1053acb41
[ 000002a1053acb41 sema_p+0x138() ]
000002a1053acbf1 biowait+0x6c(3007eeae0c0, 0, 183fc00, 30005620000, 45c,
3007eeae0c0)
000002a1053acca1 st_cmd+0x2ec(210000045c, 11, 0, 44, 60049bd1dc0, 3007eeae0c0
)
000002a1053acd91 st_space_fmks+0xc4(210000045c, 0, 60049bd1dc0, 1e3, 45c, fc00
)
000002a1053ace41 st_mtioctop+0xb88(60049bd1dc0, 1e3, 0, 100003, 0, 0)
000002a1053acf11 st_ioctl+0xbc8(210000045c, 60049bd1dc0, ffbfa4d0, 100003,
6005a9704d8, 6d01)
000002a1053ad0e1 fop_ioctl+0x20(6003623d580, 6d01, ffbfa4d0, 100003,
6005a9704d8, 1282a58)
000002a1053ad191 ioctl+0x184(b, 3007927e7a8, ffbfa4d0, 563000, 563000, 6d01)
000002a1053ad2e1 syscall_trap32+0xcc(b, 6d01, ffbfa4d0, 563000, 563000, 0)
The first argument to st_ioctl is an dev_t, so we use ::devt to figure out major and minor:
> ::devt 210000045c
MAJOR MINOR
33 1116
So, 33 is the st driver as assumed, and 1116 is device /dev/rmt/164*.
After calling the backup guys, they found out that the tape in this drive broke and caused the hanging IO. After resetting the drive and removing the tape, the process terminated as expected.
It was a netbackup process writing to a tape-device with the PID 19177.
So I fired up mdb -k:
> 0t19177::pid2proc |::walk thread |::findstack -v
stack pointer for thread 30007a49800: 2a1053acb41
[ 000002a1053acb41 sema_p+0x138() ]
000002a1053acbf1 biowait+0x6c(3007eeae0c0, 0, 183fc00, 30005620000, 45c,
3007eeae0c0)
000002a1053acca1 st_cmd+0x2ec(210000045c, 11, 0, 44, 60049bd1dc0, 3007eeae0c0
)
000002a1053acd91 st_space_fmks+0xc4(210000045c, 0, 60049bd1dc0, 1e3, 45c, fc00
)
000002a1053ace41 st_mtioctop+0xb88(60049bd1dc0, 1e3, 0, 100003, 0, 0)
000002a1053acf11 st_ioctl+0xbc8(210000045c, 60049bd1dc0, ffbfa4d0, 100003,
6005a9704d8, 6d01)
000002a1053ad0e1 fop_ioctl+0x20(6003623d580, 6d01, ffbfa4d0, 100003,
6005a9704d8, 1282a58)
000002a1053ad191 ioctl+0x184(b, 3007927e7a8, ffbfa4d0, 563000, 563000, 6d01)
000002a1053ad2e1 syscall_trap32+0xcc(b, 6d01, ffbfa4d0, 563000, 563000, 0)
The first argument to st_ioctl is an dev_t, so we use ::devt to figure out major and minor:
> ::devt 210000045c
MAJOR MINOR
33 1116
So, 33 is the st driver as assumed, and 1116 is device /dev/rmt/164*.
After calling the backup guys, they found out that the tape in this drive broke and caused the hanging IO. After resetting the drive and removing the tape, the process terminated as expected.
Freitag, 5. Februar 2010
www.sun.gone
Ich mag es vielleicht spät bemerkt haben, aber es ist ein merkwürdiges Gefühl das "sun" jetzt nur noch eine Brand von Oracle ist. Nunja, vielleicht sollte man das einfach so nüchtern betrachten wie ein Webserver:
hugin:~ olafbohlen$ telnet www.sun.com 80
Trying 72.5.124.61...
Connected to www.sun.com.
Escape character is '^]'.
GET / HTTP/1.1
Host: www.sun.com
HTTP/1.1 301 Moved Permanently
Server: Sun-Java-System-Web-Server/7.0
Date: Fri, 05 Feb 2010 10:10:03 GMT
P3p: policyref="http://www.sun.com/p3p/Sun_P3P_Policy.xml", CP="CAO DSP COR CUR ADMa DEVa TAIa PSAa PSDa CONi TELi OUR SAMi PUBi IND PHY ONL PUR COM NAV INT DEM CNT STA POL PRE GOV"
Location: http://www.oracle.com
Content-length: 0
Montag, 7. Dezember 2009
OpenSolaris Package-Manager (pm-launch)
Ich hab mich lang genug geärgert das der Package-Manager sich aus der Menue-Leiste heraus verweigert hat meinen Proxy zu benutzen. Heute habe ich gemerkt warum.
Der Package-Manager wird per /usr/lib/pm-launch aufgerufen, und dieser setzt die http_proxy Umgebungsvariable anhand der gconf settings. Leider vergisst er etwaige Login-Daten zu übernehmen. Hier mein dirty bugfix:
Wenn ich gleich "spontan" ne e-Mail Adresse von nem Entwickler finde, dann bekommt der den patch auch noch...
Der Package-Manager wird per /usr/lib/pm-launch aufgerufen, und dieser setzt die http_proxy Umgebungsvariable anhand der gconf settings. Leider vergisst er etwaige Login-Daten zu übernehmen. Hier mein dirty bugfix:
root@oldn9621-e:/usr/lib# diff pm-launch.orig pm-launch
27a28,29
> HTTP_PROXY_USER = '/system/http_proxy/authentication_user'
> HTTP_PROXY_PASS = '/system/http_proxy/authentication_password'
28a31
> HTTP_PROXY_AUTH = '/system/http_proxy/use_authentication'
40c43,48
< return 'http://' + host + ':' + str(port) + '/'
---
> puser = client.get_string(HTTP_PROXY_USER)
> ppass = client.get_string(HTTP_PROXY_PASS)
> pauth = client.get_bool(HTTP_PROXY_AUTH)
> if pauth:
> authstring = puser + ':' + ppass + "@"
> return 'http://' + authstring + host + ':' + str(port) + '/'
Wenn ich gleich "spontan" ne e-Mail Adresse von nem Entwickler finde, dann bekommt der den patch auch noch...
Mittwoch, 25. November 2009
VxVM defekte Private-Region (2)
Wie schon früher geschrieben neigt der Veritas Volume Manager ab und an unter Gedächtnisschwund.
Leider hatte ich heute die Chance herauszufinden wie obriges Verfahren bei CDSDisks funktioniert.
Zum Glück waren die Platten "online", d.h. er hat die PrivateRegion gefunden - aber nix mehr (gültiges) in ihnen. Danach kann man einfach wie im alten Post beschrieben vorgehen.
Es empfiehlt sich also einen täglichen explorer laufen zu lassen um ggf. später eine vxprint-ht.out zu haben die einem die Datenrücksicherung ersparen kann...
Leider hatte ich heute die Chance herauszufinden wie obriges Verfahren bei CDSDisks funktioniert.
Zum Glück waren die Platten "online", d.h. er hat die PrivateRegion gefunden - aber nix mehr (gültiges) in ihnen. Danach kann man einfach wie im alten Post beschrieben vorgehen.
Es empfiehlt sich also einen täglichen explorer laufen zu lassen um ggf. später eine vxprint-ht.out zu haben die einem die Datenrücksicherung ersparen kann...
Dienstag, 14. Juli 2009
Haengender ps -ef
Sollte der ps -ef einmal haengenbleiben und damit mit hoher Wahrscheinlichkeit auch kein Zugriff mehr auf alle files in /proc/ moeglich sein, gibt es folgende Moeglichkeit den betreffenden Prozess dennoch zu identifizieren:
cd /proc
for pid in *; do ls -ld $pid; done &
Das ampersand ist wichtig, sonst haengt die for-Schleife und blockiert die shell!
Die letzte ausgegebene PID merken, dann ein
echo *
und die darauf folgende PID suchen. Das ist der Kandidat.
Eigendlich waer es jetzt nett zu wissen welcher Prozess das ist. Doch leider wird ps -ef nicht funktionieren, daher muessen wir mdb benutzen:
# mdb -k
Loading modules: [ unix genunix specfs dtrace mac cpu.generic uppc pcplusmp scsi_vhci zfs sockfs ip hook neti sctp arp usba uhci s1394 stmf nca fctl lofs idm md cpc random crypto nfs fcip ptm nsctl ufs audiosup sd ipc ]
> ::ps ! grep 1563
R 1563 1 1453 1453 4100 0x4a004000 ffffff01dad47590 gvfs-hal-volume-
> ::quit
Dies funktioniert, da mdb nicht /proc/1563 oeffnet, sondern direkt in die (unter /proc liegenden) Kernel-Strukturen sieht.
Wir haben jetzt also den Prozess unserer Wahl und wissen jetzt vielleicht was zu tun ist.
Im konkreten Fall hatte ich einen haengenden ps aufgrund eines cputst Prozesses der die CPU4 testen wollte. Diese CPU war aber bereits zu 100% im sys aufgrund eines bugs im ICMP Treiber.
Es half dann wirklich den Prozess mit einem freundlichen kill -9 zu beenden, danach reagierte das System auf den ps -ef wieder normal.
cd /proc
for pid in *; do ls -ld $pid; done &
Das ampersand ist wichtig, sonst haengt die for-Schleife und blockiert die shell!
Die letzte ausgegebene PID merken, dann ein
echo *
und die darauf folgende PID suchen. Das ist der Kandidat.
Eigendlich waer es jetzt nett zu wissen welcher Prozess das ist. Doch leider wird ps -ef nicht funktionieren, daher muessen wir mdb benutzen:
# mdb -k
Loading modules: [ unix genunix specfs dtrace mac cpu.generic uppc pcplusmp scsi_vhci zfs sockfs ip hook neti sctp arp usba uhci s1394 stmf nca fctl lofs idm md cpc random crypto nfs fcip ptm nsctl ufs audiosup sd ipc ]
> ::ps ! grep 1563
R 1563 1 1453 1453 4100 0x4a004000 ffffff01dad47590 gvfs-hal-volume-
> ::quit
Dies funktioniert, da mdb nicht /proc/1563 oeffnet, sondern direkt in die (unter /proc liegenden) Kernel-Strukturen sieht.
Wir haben jetzt also den Prozess unserer Wahl und wissen jetzt vielleicht was zu tun ist.
Im konkreten Fall hatte ich einen haengenden ps aufgrund eines cputst Prozesses der die CPU4 testen wollte. Diese CPU war aber bereits zu 100% im sys aufgrund eines bugs im ICMP Treiber.
Es half dann wirklich den Prozess mit einem freundlichen kill -9 zu beenden, danach reagierte das System auf den ps -ef wieder normal.
Freitag, 10. Juli 2009
Unix heute...
Unglaublich, wir haben es 2009 und ich quäl mich mit UUCP via 19200 direct serial connection zwischen ner Sun und ner Siemens RM400 (Reliant 5.nochwas) ab...
dabei gemerkt: verdammt lange her das ich UUCP gemacht habe...
Desweiteren heute wieder gemerkt:
M4000 + Solaris10 Update6 == ++ungut;
Nunja, um ehrlich zu sein: man muss eben rechtzeitig nach der initialen Installation den cpudiag ausschalten, bevor dieser alle CPUs ausschaltet. So richtig klar kommt der mit der SPARC64 VII nicht.
Ausserdem faszinierend: Eigendlich sollten es 4 QuadCore SPARC64 VII 2.4GHz CPUs sein - prtdiag beharrt aber drauf das es 2 HexCore CPUs sind. Ich tippe mal drauf das er irgendwie Probleme hat mit der Domain-Fähigkeit der Box: er hat ja "zwei" Systemboards bekommen...
Egal, jetzt werd ich mal von Hardware-Flowcontrol und Stopbits träumen...
Mittwoch, 18. März 2009
VxVM defekte Private-Region
Mein "Lieblings"-VolumeManager VxVM wollte spontan 3 Diskgroups nicht importieren, obwohl die Platten da waren und sogar der vxdisk -o alldgs list anzeigt das die Platten zu der zu importierenden DG hoeren. Raetsels Loesung: vxprivutil beschwert sich das die Private Region kaputt ist.
Zum Glueck haben wir einen Sun Explorer Output von letzter Woche, dort gibts ein vxprint-th.out indem die Config des VxVM steht.
Also nachsehen wie die Platte aufgesetzt war. Format=sliced, d.h. kein Gewusel mit CDS.
Slice 3 war 1.88MB gross und hatte eine 1MB grosse PrivateRegion (VxVM 4.1 default). Nun gabs ein Upgrade auf VxVM 5 und der hat als default 32MB.
Ich moechte also die Volume Manager Config wieder herstellen, ohne Datenverlust im Filesystem.
Zuerst also ein freundliches:
/etc/vx/bin/vxdisksetup -f -i cXtXdX format=sliced privslice=3 privlen=1M
Damit ist eine leere Private Region auf der Platte und wir kommen nicht mehr an die Daten ran. Das heisst aber nicht das sie weg sind - vxdisksetup aendert im sliced layout nichts an der public region in der unsere volumes liegen.
Nun recovern wir die "foodg", welche eine Disk-Media namens foodg01 hatte:
vxdg init foodg foodg01=cXtXdXs2
Jetzt muessen wir uns im vxprint-th.out ansehen wie unsere subdisks ausgesehen haben (Zeile sd) und entsprechen neu anlegen:
vxmake -g foodg sd foodg01-01 disk=foodg01 offset=0 len=16777216
vxmake -g foodg sd foodg01-02 disk=foodg01 offset=16777216 len=16777216
Dazu bauen wir jetzt unsere zwei Plexes:
vxmake -g foodg plex foo01-01 sd=foodg01-01
vxmake -g foodg plex foo02-01 sd=foodg01-02
Und darueber je ein Volume, so wie es vorher war:
vxmake -g foodg -U fsgen vol foo01 plex=foo01-01
vxmake -g foodg -U fsgen vol foo02 plex=foo02-01
Jetzt sollte ein vxprint -g foodg -th genauso aussehen wie in unseren vxprint-th.out - allerdings sind die Volumes "DISABLED EMPTY" und vxvol mag sie nicht starten. Daher muessen wir sie mit einem speziellen vxvol Kommando starten:
vxvol -g foodg init active foo01
vxvol -g foodg init active foo02
Jetzt sollten wir zur Sicherheit einen fsck absetzen (in unserem Falle ein vxfs):
fsck -Fvxfs /dev/vx/rdsk/foodg/foo01
fsck -Fvxfs /dev/vx/rdsk/foodg/foo02
Und koennen sie wieder mounten - und haben unser altes Filesystem nicht ueberschrieben.
Zum Glueck haben wir einen Sun Explorer Output von letzter Woche, dort gibts ein vxprint-th.out indem die Config des VxVM steht.
Also nachsehen wie die Platte aufgesetzt war. Format=sliced, d.h. kein Gewusel mit CDS.
Slice 3 war 1.88MB gross und hatte eine 1MB grosse PrivateRegion (VxVM 4.1 default). Nun gabs ein Upgrade auf VxVM 5 und der hat als default 32MB.
Ich moechte also die Volume Manager Config wieder herstellen, ohne Datenverlust im Filesystem.
Zuerst also ein freundliches:
/etc/vx/bin/vxdisksetup -f -i cXtXdX format=sliced privslice=3 privlen=1M
Damit ist eine leere Private Region auf der Platte und wir kommen nicht mehr an die Daten ran. Das heisst aber nicht das sie weg sind - vxdisksetup aendert im sliced layout nichts an der public region in der unsere volumes liegen.
Nun recovern wir die "foodg", welche eine Disk-Media namens foodg01 hatte:
vxdg init foodg foodg01=cXtXdXs2
Jetzt muessen wir uns im vxprint-th.out ansehen wie unsere subdisks ausgesehen haben (Zeile sd) und entsprechen neu anlegen:
vxmake -g foodg sd foodg01-01 disk=foodg01 offset=0 len=16777216
vxmake -g foodg sd foodg01-02 disk=foodg01 offset=16777216 len=16777216
Dazu bauen wir jetzt unsere zwei Plexes:
vxmake -g foodg plex foo01-01 sd=foodg01-01
vxmake -g foodg plex foo02-01 sd=foodg01-02
Und darueber je ein Volume, so wie es vorher war:
vxmake -g foodg -U fsgen vol foo01 plex=foo01-01
vxmake -g foodg -U fsgen vol foo02 plex=foo02-01
Jetzt sollte ein vxprint -g foodg -th genauso aussehen wie in unseren vxprint-th.out - allerdings sind die Volumes "DISABLED EMPTY" und vxvol mag sie nicht starten. Daher muessen wir sie mit einem speziellen vxvol Kommando starten:
vxvol -g foodg init active foo01
vxvol -g foodg init active foo02
Jetzt sollten wir zur Sicherheit einen fsck absetzen (in unserem Falle ein vxfs):
fsck -Fvxfs /dev/vx/rdsk/foodg/foo01
fsck -Fvxfs /dev/vx/rdsk/foodg/foo02
Und koennen sie wieder mounten - und haben unser altes Filesystem nicht ueberschrieben.
Dienstag, 17. März 2009
Sun Connection...
Ich hasse die SCS GUI...
(262) olga5096:/export/home/olbohlen$ uce_console
(263) olga5096:/export/home/olbohlen$ X Error of failed request: BadAlloc (insufficient resources for operation)
Major opcode of failed request: 147 (XKEYBOARD)
Minor opcode of failed request: 16 (XkbSetNamedIndicator)
Serial number of failed request: 1302
Current serial number in output stream: 1305
Und das nur als ich mit dem Mouse Pointer im Login-Dialog ins Username-Feld geklickt habe und meinen Namen tippen wollte...
Passiert mir nur wenn ich se per X-Forwarding auf mein Notebook im JDS anzeigen lasse. Per X-Forwarding im CDE im eXceed auf der Wintendo-Schuessel lueppts. Sehr spannend.
(262) olga5096:/export/home/olbohlen$ uce_console
(263) olga5096:/export/home/olbohlen$ X Error of failed request: BadAlloc (insufficient resources for operation)
Major opcode of failed request: 147 (XKEYBOARD)
Minor opcode of failed request: 16 (XkbSetNamedIndicator)
Serial number of failed request: 1302
Current serial number in output stream: 1305
Und das nur als ich mit dem Mouse Pointer im Login-Dialog ins Username-Feld geklickt habe und meinen Namen tippen wollte...
Passiert mir nur wenn ich se per X-Forwarding auf mein Notebook im JDS anzeigen lasse. Per X-Forwarding im CDE im eXceed auf der Wintendo-Schuessel lueppts. Sehr spannend.
Citrix Client Solaris x86
Seit der Citrix Client 8.50 fuer Solaris x86 released wurde habe ich immer wieder versucht den zu benutzen, aber er ist immer auf die Bretter gegangen mit einem Segmentation fault. Heute habe ich durch Zufall auf den Citrix Foren die Loesung gefunden: der Citrix Client (namentlich der wfica) kommt mit der libXm.so.4 nicht klar. Daher hilft es in /usr/lib/ICAClient das binary wfica umzubenennen und einen shell-wrapper zu erzeugen:
(142) oldn9621-e:/usr/lib/ICAClient# cat wfica
#!/bin/ksh
# small hack for preventing segfaulting wfica in libXm.so.4
# olbohlen, 2009-03-17
LD_PRELOAD=/usr/dt/lib/libXm.so.3 /usr/lib/ICAClient/wfica.bin $@
(143) oldn9621-e:/usr/lib/ICAClient# ls -l wfica.bin
-r-xr-xr-x 1 root sys 1309280 Sep 14 2007 wfica.bin
Jetzt klappts auch mit dem Citrix :)
(142) oldn9621-e:/usr/lib/ICAClient# cat wfica
#!/bin/ksh
# small hack for preventing segfaulting wfica in libXm.so.4
# olbohlen, 2009-03-17
LD_PRELOAD=/usr/dt/lib/libXm.so.3 /usr/lib/ICAClient/wfica.bin $@
(143) oldn9621-e:/usr/lib/ICAClient# ls -l wfica.bin
-r-xr-xr-x 1 root sys 1309280 Sep 14 2007 wfica.bin
Jetzt klappts auch mit dem Citrix :)
Mittwoch, 24. Dezember 2008
Sun Cluster 3.2 und iSCSI
So, ich habe jetzt einen SunCluster 3.2 gebaut (low cost, eine Netra20, eine Blade1000 und ein Multipack mit 4 146G Disks), davon 3 Disks in einem RaidZ Diskpool.
Auf dem ZPool gibts 3 Volumes: eines fuer ein Zoneroot, eines fuer Oracle Binaries und eines fuer Datafiles. (Im echten Leben wuerde man natuerlich noch Redo/Arch-Logs, etc in eigene Volumes tun)
Diese drei Volumes sind per iSCSI freigegeben.
Im SunCluster gibts eine normale HAStoragePlus RG für den ZPool sowie einen LogicalHostname "strongbow".
Soviel zur ZFS Config.
Hier noch die Konfiguration der Resourcen im Cluster:
Anschliessend muss die Disk auf "flunder" bekannt gemacht werden:
(zu setzen mit iscsiadm add discovery-address 172.20.23.1)
"Strongbow" ist wie oben zu sehen der LogicalHostname des Clusters.
Dies ist das target gefolgt von der Host-IP. Das target haben wir aus dem Output von iscsitadm des Clusters.
Jetzt muss die Disk OS-Seitig noch bekannt werden:
Legt jetzt die entsprechenden Device-Eintraege an und wir koennen die Disk per format sehen:
Jetzt kann mit newfs ein UFS auf das slice0 gelegt werden. Die Details dazu duerften bekannt sein. Ebenfalls das installieren einer Zone sollte klar sein.
Jetzt haben wir uns eine Zone auf ein redundantes Storage gelegt das Failovered.
Ein Failover wird vom Host System mit messages in Form von SCSI errors/retransmits quittiert, aber die Zone läuft weiter.
Jetzt werde ich die Oracle-DB in die Zone installieren und sehen ob die genauso stressfrei den Failover ueberlebt. Beim Versuch mit NFS als grundliegende Resource ist die DB ziemlich auf die Bretter gegangen...
Auf dem ZPool gibts 3 Volumes: eines fuer ein Zoneroot, eines fuer Oracle Binaries und eines fuer Datafiles. (Im echten Leben wuerde man natuerlich noch Redo/Arch-Logs, etc in eigene Volumes tun)
Diese drei Volumes sind per iSCSI freigegeben.
Im SunCluster gibts eine normale HAStoragePlus RG für den ZPool sowie einen LogicalHostname "strongbow".
(6645120) bow:/# zfs list
NAME USED AVAIL REFER MOUNTPOINT
sharedpool 28.0G 239G 28.0K /sharedpool
sharedpool/oracle 20.0G 239G 24.0K /sharedpool/oracle
sharedpool/oracle/data1 8G 247G 21.3K -
sharedpool/oracle/orabin 12G 251G 21.3K -
sharedpool/zones 8.00G 239G 24.0K /sharedpool/zones
sharedpool/zones/testzone 8G 243G 4.41G -
(6645144) bow:/# zfs get all sharedpool/zones/testzone
NAME PROPERTY VALUE SOURCE
sharedpool/zones/testzone type volume -
sharedpool/zones/testzone creation Tue Dec 23 17:20 2008 -
sharedpool/zones/testzone used 8G -
sharedpool/zones/testzone available 243G -
sharedpool/zones/testzone referenced 4.41G -
sharedpool/zones/testzone compressratio 1.00x -
sharedpool/zones/testzone reservation none default
sharedpool/zones/testzone volsize 8G -
sharedpool/zones/testzone volblocksize 8K -
sharedpool/zones/testzone checksum on default
sharedpool/zones/testzone compression off default
sharedpool/zones/testzone readonly off default
sharedpool/zones/testzone shareiscsi on local
sharedpool/zones/testzone copies 1 default
sharedpool/zones/testzone refreservation 8G local
Soviel zur ZFS Config.
Hier noch die Konfiguration der Resourcen im Cluster:
Ein dritter Server "flunder" soll eine Zone bekommen mit dem Namen "scholle", welche sich dann bitte auf dem testzone Volume befinden soll. Zuerst also die iSCSI config auf dem Cluster ansehen. Achtung, das ist eine Failovergroup - daher funktioniert das natuerlich nur auf dem Node der die RG aktiv hat:
(6645145) bow:/# scstat -g
-- Resource Groups and Resources --
Group Name Resources
---------- ---------
Resources: space-rg space-zfs-stor strongbow
-- Resource Groups --
Group Name Node Name State Suspended
---------- --------- ----- ---------
Group: space-rg bow Online No
Group: space-rg saint Offline No
-- Resources --
Resource Name Node Name State Status Message
------------- --------- ----- --------------
Resource: space-zfs-stor bow Online Online
Resource: space-zfs-stor saint Offline Offline
Resource: strongbow bow Online Online - LogicalHostname online.
Resource: strongbow saint Offline Offline - LogicalHostname offline.
(6645147) bow:/# scrgadm -pv
Res Type name: SUNW.LogicalHostname:2
(SUNW.LogicalHostname:2) Res Type description: Logical Hostname Resource Type
(SUNW.LogicalHostname:2) Res Type base directory: /usr/cluster/lib/rgm/rt/hafoip
(SUNW.LogicalHostname:2) Res Type single instance: False
(SUNW.LogicalHostname:2) Res Type init nodes: All potential masters
(SUNW.LogicalHostname:2) Res Type failover: True
(SUNW.LogicalHostname:2) Res Type proxy: False
(SUNW.LogicalHostname:2) Res Type version: 2
(SUNW.LogicalHostname:2) Res Type API version: 2
(SUNW.LogicalHostname:2) Res Type installed on nodes:
(SUNW.LogicalHostname:2) Res Type packages: SUNWscu
(SUNW.LogicalHostname:2) Res Type system: True
Res Type name: SUNW.SharedAddress:2
(SUNW.SharedAddress:2) Res Type description: HA Shared Address Resource Type
(SUNW.SharedAddress:2) Res Type base directory: /usr/cluster/lib/rgm/rt/hascip
(SUNW.SharedAddress:2) Res Type single instance: False
(SUNW.SharedAddress:2) Res Type init nodes: All nodes
(SUNW.SharedAddress:2) Res Type failover: True
(SUNW.SharedAddress:2) Res Type proxy: False
(SUNW.SharedAddress:2) Res Type version: 2
(SUNW.SharedAddress:2) Res Type API version: 2
(SUNW.SharedAddress:2) Res Type installed on nodes:
(SUNW.SharedAddress:2) Res Type packages: SUNWscu
(SUNW.SharedAddress:2) Res Type system: True
Res Type name: SUNW.HAStoragePlus:6
(SUNW.HAStoragePlus:6) Res Type description: HA Storage Plus
(SUNW.HAStoragePlus:6) Res Type base directory: /usr/cluster/lib/rgm/rt/hastorageplus
(SUNW.HAStoragePlus:6) Res Type single instance: False
(SUNW.HAStoragePlus:6) Res Type init nodes: All potential masters
(SUNW.HAStoragePlus:6) Res Type failover: False
(SUNW.HAStoragePlus:6) Res Type proxy: False
(SUNW.HAStoragePlus:6) Res Type version: 6
(SUNW.HAStoragePlus:6) Res Type API version: 2
(SUNW.HAStoragePlus:6) Res Type installed on nodes:
(SUNW.HAStoragePlus:6) Res Type packages: SUNWscu
(SUNW.HAStoragePlus:6) Res Type system: False
Res Group name: space-rg
(space-rg) Res Group RG_description:
(space-rg) Res Group mode: Failover
(space-rg) Res Group management state: Managed
(space-rg) Res Group RG_project_name: default
(space-rg) Res Group RG_SLM_type: manual
(space-rg) Res Group RG_affinities:
(space-rg) Res Group Auto_start_on_new_cluster: True
(space-rg) Res Group Failback: False
(space-rg) Res Group Nodelist: bow saint
(space-rg) Res Group Maximum_primaries: 1
(space-rg) Res Group Desired_primaries: 1
(space-rg) Res Group RG_dependencies:
(space-rg) Res Group network dependencies: True
(space-rg) Res Group Global_resources_used:
(space-rg) Res Group Pingpong_interval: 3600
(space-rg) Res Group Pathprefix:
(space-rg) Res Group system: False
(space-rg) Res Group Suspend_automatic_recovery: False
(space-rg) Res name: space-zfs-stor
(space-rg:space-zfs-stor) Res R_description:
(space-rg:space-zfs-stor) Res resource type: SUNW.HAStoragePlus:6
(space-rg:space-zfs-stor) Res type version: 6
(space-rg:space-zfs-stor) Res resource group name: space-rg
(space-rg:space-zfs-stor) Res resource project name: default
(space-rg:space-zfs-stor{bow}) Res enabled: True
(space-rg:space-zfs-stor{saint}) Res enabled: True
(space-rg:space-zfs-stor{bow}) Res monitor enabled: True
(space-rg:space-zfs-stor{saint}) Res monitor enabled: True
(space-rg) Res name: strongbow
(space-rg:strongbow) Res R_description:
(space-rg:strongbow) Res resource type: SUNW.LogicalHostname:2
(space-rg:strongbow) Res type version: 2
(space-rg:strongbow) Res resource group name: space-rg
(space-rg:strongbow) Res resource project name: default
(space-rg:strongbow{bow}) Res enabled: True
(space-rg:strongbow{saint}) Res enabled: True
(space-rg:strongbow{bow}) Res monitor enabled: True
(space-rg:strongbow{saint}) Res monitor enabled: True
(6645163) bow:/# iscsitadm list target
Target: sharedpool/zones/testzone
iSCSI Name: iqn.1986-03.com.sun:02:2abc5e6f-1535-6403-ca9f-d3d2f2e652a4
Connections: 1
Target: sharedpool/oracle/orabin
iSCSI Name: iqn.1986-03.com.sun:02:d5078ccd-ed73-cf83-d77a-df383470df86
Connections: 0
Target: sharedpool/oracle/data1
iSCSI Name: iqn.1986-03.com.sun:02:b63b6a43-31f5-cdac-e62d-918cd4b83851
Connections: 0
Anschliessend muss die Disk auf "flunder" bekannt gemacht werden:
(50) flunder:/# iscsiadm list discovery-address
Discovery Address: 172.20.23.1:3260
(zu setzen mit iscsiadm add discovery-address 172.20.23.1)
(51) flunder:/# getent hosts 172.20.23.1
172.20.23.1 strongbow
"Strongbow" ist wie oben zu sehen der LogicalHostname des Clusters.
(52) flunder:/# iscsiadm modify discovery --static enable
(53) flunder:/# iscsiadm add static-config iqn.1986-03.com.sun:02:2abc5e6f-1535-6403-ca9f-d3d2f2e652a4,172.20.23.1
Dies ist das target gefolgt von der Host-IP. Das target haben wir aus dem Output von iscsitadm des Clusters.
Jetzt muss die Disk OS-Seitig noch bekannt werden:
(54) flunder:/# devfsadm -i iscsi
Legt jetzt die entsprechenden Device-Eintraege an und wir koennen die Disk per format sehen:
(89) flunder:/# format
Searching for disks...done
AVAILABLE DISK SELECTIONS:
0. c0t0d0
/pci@1c,600000/scsi@2/sd@0,0
1. c4t0d0
/iscsi/disk@0000iqn.1986-03.com.sun%3A02%3A2abc5e6f-1535-6403-ca9f-d3d2f2e652a4FFFF,0
2. c4t1d0
/iscsi/disk@0000iqn.1986-03.com.sun%3A02%3Ad5078ccd-ed73-cf83-d77a-df383470df86FFFF,0
3. c4t2d0
/iscsi/disk@0000iqn.1986-03.com.sun%3A02%3Ab63b6a43-31f5-cdac-e62d-918cd4b83851FFFF,0
Specify disk (enter its number): 1
selecting c4t0d0
[disk formatted]
FORMAT MENU:
disk - select a disk
type - select (define) a disk type
partition - select (define) a partition table
current - describe the current disk
format - format and analyze the disk
repair - repair a defective sector
label - write label to the disk
analyze - surface analysis
defect - defect list management
backup - search for backup labels
verify - read and display labels
save - save new disk/partition definitions
inquiry - show vendor, product and revision
volname - set 8-character volume name
!- execute , then return
quit
format> p
PARTITION MENU:
0 - change `0' partition
1 - change `1' partition
2 - change `2' partition
3 - change `3' partition
4 - change `4' partition
5 - change `5' partition
6 - change `6' partition
7 - change `7' partition
select - select a predefined table
modify - modify a predefined partition table
name - name the current table
print - display the current table
label - write partition map and label to the disk
!- execute , then return
quit
partition> p
Current partition table (original):
Total disk cylinders available: 32766 + 2 (reserved cylinders)
Part Tag Flag Cylinders Size Blocks
0 root wm 0 - 32765 8.00GB (32766/0/0) 16776192
1 unassigned wu 0 0 (0/0/0) 0
2 backup wu 0 - 32765 8.00GB (32766/0/0) 16776192
3 unassigned wm 0 0 (0/0/0) 0
4 unassigned wm 0 0 (0/0/0) 0
5 unassigned wm 0 0 (0/0/0) 0
6 unassigned wm 0 0 (0/0/0) 0
7 unassigned wm 0 0 (0/0/0) 0
partition> ^D
(90) flunder:/#
Jetzt kann mit newfs ein UFS auf das slice0 gelegt werden. Die Details dazu duerften bekannt sein. Ebenfalls das installieren einer Zone sollte klar sein.
Jetzt haben wir uns eine Zone auf ein redundantes Storage gelegt das Failovered.
Ein Failover wird vom Host System mit messages in Form von SCSI errors/retransmits quittiert, aber die Zone läuft weiter.
Jetzt werde ich die Oracle-DB in die Zone installieren und sehen ob die genauso stressfrei den Failover ueberlebt. Beim Versuch mit NFS als grundliegende Resource ist die DB ziemlich auf die Bretter gegangen...
Abonnieren
Posts (Atom)
