AIX - booby trap

Az ember azt hinné, hogy az AIX-el nem lehet vicces dolgokat csinálni, de olykor olykor kellemesen tud csalódni abban amit el lehet ténylegesen érni vele.
Múltkor például sikerült rájönnöm, hogy IPsec-el lehet olyan szabályt létrehozni, ami annyit csinál, hogy ha egy kliens megpróbál az adott portra csatlakozni, akkor kap egy X sec-es ban-t mindenféle hálózati forgalommal együtt..
Belegondolva ez egy standard támadó ellen teljesen jó kis csapda -> Csupán annyit kell csinálnunk, hogy egy meglehetősen alacsony portra kirakunk egy sérülékeny szolgáltatást (rsh, telnet, csak hogy finoman is nézzen ki), majd rádefiniálunk egy szabályt, hogy aki megpróbál bejönni, annak mondjuk 1 napig csend legyen.. Amennyiben a támadónk valamiféle scanneléssel próbálkozik (sima nmap is elég :)) már bele is esett a csapdába.. Csodálatos, mit ne mondjak :))

Hogy ez a valóságban hogy is néz ki? Nos van 1-2 alapfeltétel:
- clic.rte alatti csomagoknak fent kell legyenek a gépen
- Be kell legyen töltve az Ipsec modul (ipsec_v4, ha IPv4et akarunk védeni)
- A szabályokat nekünk kell beállítani.

Tehát a feladat szimplán ennyi:

server # installp -avXYgd /source clic.rte.lib clic.rte.kernext  
    # Alap csomagok telepítése
server # smitty ips4_start # Indítsuk el az Ipsec IPv4es támogatását
server # lsdev -l ipsec_v4 # Nézzük meg elérhetővé vált e az ipsec_v4 device
ipsec_v4 Available  IP Version 4 Security Extension

A szabály beállítás némileg macerásabb. Csinálhatjuk 'smitty ips4_add_filter'-el, vagy genfilt-en keresztül parancssorból is.

Smitty-ből így néz ki a konfigolás:
* Rule Action                                                                   [shunHost]            
* IP Source Address                                                         [0.0.0.0]
* IP Source Mask                                                             [0.0.0.0]
  IP Destination Address                                                   [10.1.0.100]
  IP Destination Mask                                                       []
* Apply to Source Routing? (PERMIT/inbound only)    [yes]                 
* Protocol                                                                         [all]                 
* Source Port / ICMP Type Operation                             [any]                 
* Source Port Number / ICMP Type                                [0]                   
* Destination Port / ICMP Code Operation                     [eq]                  
* Destination Port Number / ICMP Type                        [23]                  
* Routing                                                                         [both]                
* Direction                                                                       [inbound]             
* Log Control                                                                  [yes]                 
* Fragmentation Control                                                 [0]                   
* Interface                                                                       [all]                 
  Expiration Time (sec)                                                   [300]                 
  Pattern Type                                                                 [none]                
  Pattern / Pattern File                                                     []
  Description                                                                   [telnet_boobytrap]

Ugyan ez parancssorból:

server # genfilt -v 4 -a H -s '0.0.0.0' -m '0.0.0.0' -d 10.1.0.100 -g y -c all -o any -p 0 -O eq -P 23 -r B -w I -l Y -t 0 -i all -e 300 -D 'telnet_boobytrap'

Némi kis magyarázat a kapcsolókról:
-v 4 -> IP version 4
-a H -> ShunHost
-s 0.0.0.0 -> Source address (0.0.0.0 == bárhonnét)
-m 0.0.0.0 -> Source Mask (0.0.0.0 == mindenhonnan)
-d 10.1.0.100 -> Destination IP (nem kötelező, de a tapasztalatok alapján érdemes megadni, mert nélküle mintha nem menne (nem tudtam rájönni miért))
-g y -> Source packet átroute-olása
-c all -> Minden protokolon (udp/tcp/icmp/ospf/ipip/esp/ah)
-o any -> Source port (0 == bármelyik)
-p 0 -> Source port (0 == bármelyik)
-O eq -> Milyen tipusú operátort használjuk (eq == equal -> megyegező port)
-P 23 -> Port száma (23 == telnet)
-r B -> Routing-ot pontosan mely láncokra érvényesítsük (route forward, local routing, avagy mind2 (both)
-w I -> Direction. Jelen esetben csak a bejövő csomagokkal foglalkozunk
-l Y -> Loggolás.. Persze, hogy akarunk loggolni :) (For the record - a logok a local4:err, local4:info és local4:notice alá mennek)
-t 0 -> Fragmenation Control, avagy melyik ID-jű tunnelbe toljuk majd bele a csomagot ( a 0 default)
-i all -> Interface.. Mindenhol halgatózni akarunk természetesen :)
-e 300 -> Expiration time másodpercben (kíméletesek leszünk, most csak 5 perces bann jár :))
-D 'telnet_boobytrap' -> Description.. Hogy kb a leírás alapján tudjuk mit is akarhatott a költő amikor ezt a szabályt létrehozta..

Ennek az eredménye egy olyan rule lesz, ami bárhonnét jövő IPv4-es kapcsolatot kitilt 5 percre, ha én a 23-as portra próbálok csatlakozni.
Szerverről lekérve pedig láthatjuk is a kis szabályunkat:

server # lsfilt -v4 -O
1|permit|0.0.0.0|0.0.0.0|0.0.0.0|0.0.0.0|no|udp|eq|4001|eq|4001|both|both|no|all packets|0|all|0|||Default Rule
2|*** Dynamic filter placement rule for IKE tunnels ***|no
3|shunHost|0.0.0.0|0.0.0.0|0.0.0.0|255.255.255.255|yes|all|any|0|eq|23|both|inbound|yes|all packets|0|all|300|||telnet_boobytrap
0|permit|0.0.0.0|0.0.0.0|0.0.0.0|0.0.0.0|yes|all|any|0|any|0|both|both|no|all packets|0|all|0|||Default Rule

Na most azért van itt még 1-2 dolgot amire ki kell térni:
- A 0ás,1es,2es szabályok állandóak, ergo a legkisebb ID amit kaphatunk az 3as lesz 1 szabályhoz, illetve afölött
- Azzal, hogy a rule-t létrehoztuk még nem jelenti, hogy életbe is léptettük azonnal -> azt külön meg kell tenni :)
- Ráadásként a loggolást is hiába állítottuk be, ha nem engedélyezzük azt is :)

Mázlinkra ez összesen 2 új parancsot jelent:

server # mkfilt -v4 -g start  # Loggolás aktiválása
server # mkfilt -v4 -u    # A felvitt rule-ok aktiválása

Innentől fogva viszont életbe léptek a változtatásaink, és mindenféle bajkeverő ilyen következményekkel kell szembenézzen

Mit jelent ez a gyakorlatban?
"telnet_boobytrap" szabály nélkül az nmap ezt dobja vissza:

pentester # nmap -sS 10.1.0.100

Starting Nmap 5.51 ( http://nmap.org ) at 2012-07-25 22:15 Central Europe Daylight Time
Nmap scan report for 10.1.0.100
Host is up (0.061s latency).
Not shown: 994 closed ports
PORT     STATE SERVICE
23/tcp   open  telnet
111/tcp  open  rpcbind
514/tcp  open  shell
1334/tcp open  writesrv
2049/tcp open  nfs
9090/tcp open  zeus-admin
MAC Address: 00:00:00:41:47:4E (Xerox)

Nmap done: 1 IP address (1 host up) scanned in 1.72 seconds

"telnet_boobytrap"-al ugyan ez:

pentester # nmap -sS 10.1.0.100

Starting Nmap 5.51 ( http://nmap.org ) at 2012-07-25 21:46 Central Europe Dayliht Time
Nmap scan report for 10.1.0.100
Host is up (0.063s latency).
Not shown: 919 closed ports, 76 filtered ports
PORT     STATE SERVICE
111/tcp  open  rpcbind
514/tcp  open  shell
1334/tcp open  writesrv
2049/tcp open  nfs
9090/tcp open  zeus-admin
MAC Address: 00:00:00:41:47:4E (Xerox)

Nmap done: 1 IP address (1 host up) scanned in 1521.31 seconds

1.72 sec VS 1521.32 sec (több mint 25 perc :)) és csak egy 5 perces tiltást állítottunk be.. Képzeld el mi lesz ha "kicsit" emeljük a tétet, mondjuk 86400-ra (24 óra) :))

Nézzük mi van akkor ha valaki csak simán be akar telnetelni:

pentester  # telnet 10.1.0.100
Trying...
telnet: connect: A remote host did not respond within the timeout period.

Mindeközben a logban:

server  # tail -f /var/log/syslog.out |grep ipsec
Jul 25 20:29:42 server local4:info ipsec_logd: #:2 R:d  I:10.1.0.100 S:10.1.0.153 D:10.1.0.100 P:tcp/ack SP:53688 DP:23 R:l I:en1 F:n T:0 L:60
Jul 25 20:29:42 server local4:info ipsec_logd: #:1 R:d  O:995:46f4:995:46d2:995:46f4:600:d1b8 S:17:0:0:1::2 D:0:1::656e:3100:f100:500 P:(1) -:54272 -:61696 R:l I: F:n T:3935892 L:18472
Jul 25 20:29:43 server local4:info ipsec_logd: #:0 R:d  I:10.1.0.100 S:10.1.0.153 D:10.1.0.100 P:tcp/ack SP:53688 DP:23 R:l I:en1 F:n T:0 L:60
Jul 25 20:29:43 server local4:info ipsec_logd: #:-2010349502 R:d  O:995:46f4:995:46d2:995:46f4:600:d1b8 S:17:0:0:1:: D:0:1::656e:3100:f100:500 P:ip -:12288 -:61696 R:l I: F:n T:3935892 L:0
Jul 25 20:29:46 server local4:info ipsec_logd: #:0 R:d  I:10.1.0.100 S:10.1.0.153 D:10.1.0.100 P:tcp/ack SP:53688 DP:23 R:l I:en1 F:n T:0 L:60
Jul 25 20:29:46 server local4:info ipsec_logd: #:-2010349502 R:d  O:995:46f4:995:46d2:995:46f4:600:d1b8 S:17:0:0:1:: D:0:1::656e:3100:f100:500 P:ip -:12288 -:61696 R:l I: F:n T:3935892 L:0
Jul 25 20:29:52 server local4:info ipsec_logd: #:0 R:d  I:10.1.0.100 S:10.1.0.153 D:10.1.0.100 P:tcp/ack SP:53688 DP:23 R:l I:en1 F:n T:0 L:60
Jul 25 20:29:52 server local4:info ipsec_logd: #:0 R:d  O:995:46f4:995:46d2:995:46f4:600:d1b8 S:17:0:0:1:: D:0:1::656e:3100:f100:500 P:ip -:27136 -:61696 R:l I: F:n T:3935892 L:0
Jul 25 20:30:04 server local4:info ipsec_logd: #:0 R:d  I:10.1.0.100 S:10.1.0.153 D:10.1.0.100 P:tcp/ack SP:53688 DP:23 R:l I:en1 F:n T:0 L:60
Jul 25 20:30:04 server local4:info ipsec_logd: #:1 R:d  O:995:46f4:995:46d2:995:46f4:600:d1b8 S:17:0:0:1:: D:0:1::656e:3100:f100:500 P:(1) -:9216 -:61696 R:l I: F:n T:3935892 L:0
Jul 25 20:30:28 server local4:info ipsec_logd: #:0 R:d  I:10.1.0.100 S:10.1.0.153 D:10.1.0.100 P:tcp/ack SP:53688 DP:23 R:l I:en1 F:n T:0 L:60
Jul 25 20:30:28 server local4:info ipsec_logd: #:0 R:d  O:995:46f4:995:46d2:995:46f4:600:d1b8 S:17:0:0:1:: D:0:1::656e:3100:f100:500 P:ip -:27136 -:61696 R:l I: F:n T:3935892 L:0
Jul 25 20:30:57 server local4:info ipsec_logd: #:0 R:d  I:10.1.0.100 S:10.1.0.153 D:10.1.0.100 P:tcp/ack SP:53697 DP:23 R:l I:en1 F:n T:0 L:60
Jul 25 20:30:57 server local4:info ipsec_logd: #:-2010349502 R:d  O:995:46f4:995:46d2:995:46f4:600:d1c1 S:17:0:0:1:: D:0:1::656e:3100:f100:500 P:ip -:12288 -:61696 R:l I: F:n T:3935892 L:0
Jul 25 20:30:58 server local4:info ipsec_logd: #:0 R:d  I:10.1.0.100 S:10.1.0.153 D:10.1.0.100 P:tcp/ack SP:53697 DP:23 R:l I:en1 F:n T:0 L:60
Jul 25 20:30:58 server local4:info ipsec_logd: #:0 R:d  O:995:46f4:995:46d2:995:46f4:600:d1c1 S:17:0:0:1:: D:0:1::656e:3100:f100:500 P:ip -:27136 -:61696 R:l I: F:n T:3935892 L:0
Jul 25 20:31:01 server local4:info ipsec_logd: #:0 R:d  I:10.1.0.100 S:10.1.0.153 D:10.1.0.100 P:tcp/ack SP:53697 DP:23 R:l I:en1 F:n T:0 L:60
Jul 25 20:31:01 server local4:info ipsec_logd: #:-2010349502 R:d  O:995:46f4:995:46d2:995:46f4:600:d1c1 S:17:0:0:1:: D:0:1::656e:3100:f100:500 P:ip -:12288 -:61696 R:l I: F:n T:3935892 L:0
Jul 25 20:31:07 server local4:info ipsec_logd: #:0 R:d  I:10.1.0.100 S:10.1.0.153 D:10.1.0.100 P:tcp/ack SP:53697 DP:23 R:l I:en1 F:n T:0 L:60
Jul 25 20:31:07 server local4:info ipsec_logd: #:0 R:d  O:995:46f4:995:46d2:995:46f4:600:d1c1 S:17:0:0:1:: D:0:1::656e:3100:f100:500 P:ip -:27136 -:61696 R:l I: F:n T:3935892 L:0
Jul 25 20:31:19 server local4:info ipsec_logd: #:0 R:d  I:10.1.0.100 S:10.1.0.153 D:10.1.0.100 P:tcp/ack SP:53697 DP:23 R:l I:en1 F:n T:0 L:60
Jul 25 20:31:19 server local4:info ipsec_logd: #:1 R:d  O:995:46f4:995:46d2:995:46f4:600:d1c1 S:17:0:0:1:: D:0:1::656e:3100:f100:500 P:(1) -:9216 -:61696 R:l I: F:n T:3935892 L:0
Jul 25 20:31:43 server local4:info ipsec_logd: #:0 R:d  I:10.1.0.100 S:10.1.0.153 D:10.1.0.100 P:tcp/ack SP:53697 DP:23 R:l I:en1 F:n T:0 L:60
Jul 25 20:31:43 server local4:info ipsec_logd: #:0 R:d  O:995:46f4:995:46d2:995:46f4:600:d1c1 S:17:0:0:1:: D:0:1::656e:3100:f100:500 P:ip -:27136 -:61696 R:l I: F:n T:3935892 L:0

Amire tessék figyelni: Amint az egyik szabály érvényesül egy bejövő címre, az ipsec elkezdi logolni az összes próbálkozását a node-nak, miután ki lett tiltva (az nmap kellemes kis 2 MB-os logot generált nekem a ~25 perc alatt :)) de innentől már nem csak a megadott portra (23), hanem mindre amire a támadó gép bepróbálkozott

Hardening AIX - tűzfal

Anno amikor megismerkedtem az AIX-el még úgy tanították, hogy az AIX egy nagyvállalati rendszer, és azért nincs alatta tűzfal, mert azért az infrastruktúrának kell felelnie (persze van IPsec, de az nem tűzfal megoldás). Némi kis Linuxos múlttal a hátam mögött ezt anno nagyon furcsának éreztem, de aztán csak megszoktam, hogy ha nagyvállalat, akkor tényleg lesz valahol egy CISCO eszköz is a közelben, az meg tényleg egész jó tűzfal lehetőségeket biztosít.
Viszont -mint kiderült- az AIX alatt még is van elérhető "támogatott" tűzfal és NAT (!) megoldás a híresztelésekkel ellentétben.. Igen, nem káprázik a szemetek - az AIX-ra ugyan is portolták a BSD rendszerek alatt is ismert ipfilter-t!
Csupán 2 szépséghibája van a dolognak:
- Nem része az alap rendszernek - csupán az Expansion Pack részeként lehet elérni
- A fejlesztés kicsit mintha megállt volna (vagy csak elérték a tökéletességet :)) és a csomag megragadt az 5.3.0.3 verziónál (mázlira ettől még 5.3/6.1/7.1 alatt is gond nélkül lehet használni)

Amennyiben valaki úgy érzi, hogy ez kell neki (és ismét át akarja élni a tűzfal piszkálás okozta izgalmakat :)), az az alábbi módon telepítheti/tesztelheti a tool-t

Szedjük ki az expansion pack-ből a 'ipfl' file-t, meg ha már ott járunk, akkor töltsük le a legfrissebb javítást is a csomaghoz
Töltsük fel a 2 file-unkat a szerverünk alá (nálam ez lesz a test_server)

scp ipfl* test_server:/tmp/ipfilter

Csináljuk meg a .toc file-unkat (avagy ha már csinálunk valamit, akkor csináljuk normálisan)

ssh test_server
test_server@root:/ # cd /tmp/ipfilter
test_server@root:/tmp/ipfilter # inutoc .

Rakjuk fel a csomagunkat

test_server@root:/tmp/ipfilter # installp -avXYgd /tmp/ipfilter ipfl.rte

A telepítés után inicializáljuk a telepített kernel modult

test_server@root:/tmp/ipfilter # /usr/lib/methods/cfg_ipf -l

Innen indul a jó rész: Csináljuk meg a saját szabályainkat :) Személy szerint úgy vagyok vele, hogy jobban szeretem a láncaimat file-ban látni, de persze lehetne nyomban gépelgetni is a láncokat. Én az egyszerűség kedvéért csak 1 magas portot engedélyeztem 2 gépről (és mint jó rendszergazda nyomban úgy indultam neki, hogy mindent tiltok, kivétel amit engedek )

test_server@root:/ # vi /etc/ipf.conf
block in proto tcp/udp all
pass in proto tcp/udp from 10.1.0.1 to port = 22222 keep state
pass in proto tcp/udp from 10.1.0.2 to port = 22222 keep state

Ha készen vagyunk a szabály láncainkkal, akkor adjuk is hozzá azokat a jelenleg üres láncokhoz

test_server@root:/ # ipf -f /etc/ipf.conf
# Megjegyzés - Amennyiben a konfig file-t többször piszkáljuk, akkor a '-Fa' (Flush All) kapcsolóval érdemes a file-t újraolvastatni, különben az ipfilter simán hozzáfűzi a szabályokat a már meglévő láncokhoz)
# Megjegyzés #2: Amennyiben olyan ügyesek voltunk, hogy valami írdatlan nagy hülyeséget csináltunk, akkor simán a '-Fa'-val flusholhatjuk a teljes szabályrendszert (Aki dolgozott már remote tűzfal konfigurálással, az tudja, hogy egy megfelelően megírt script mennyit tud segíteni egy ilyne flush-al, amennyiben valahogy sikerült magunk alól kifürészelni a fát)
test_server@root:/ # ipf -Fa -f /etc/ipf.conf

Ellenőrzés: Nézzük meg az incoming/outgoing láncainkat:

test_server@root:/ # ipfstat -in
@1 block in proto tcp/udp from any to any
@2 pass in proto tcp/udp from 10.1.0.1/32 to any port = 22222 keep state
@3 pass in proto tcp/udp from 10.1.0.2/32 to any port = 22222 keep state
test_server@root:/ # ipfstat -on
empty list for ipfilter(out)

Ha minden szép és jó, akkor kedvünk szerint lehet az indításról gondoskodni (rc script, inittab bejegyzés, vagy a /etc/rc.net szerkesztése), azt viszont ne felejtsük el, hogy ez után illik egy 'bosboot -ad'-t futtatni, hogy a következő bootoláskor ne kelljen a module-t manuálisan betöltenünk

További infók: http://www-304.ibm.com/support/docview.wss?uid=isg3T1011144

Sudo te drága.. De sokat kell érted fizetni időnként :)

A sudo nevű utility-t szerintem nem kell senkinek se bemutatnom.
Segítségével (minimum féldisznóért) root hozzáférést kaphatunk kedvenc adminisztrátorunktól az adott (természetesen teszt) rendszerünkhöz (NOPASSWD-s rule-al, mert jelszót beírni senki nem szeret :)), így szabadon garázdálkodhatunk és nézelődhetünk, hogy ha valami gáz van a kódban (avagy "De hisz ez még tegnap működött!").
Persze azt se szabad elfelejteni, hogy ezen eszköz révén némileg le tudjuk korlátozni az olyan usereket is, akiknek helyenként root jogosultság kéne, hogy elindítsanak valamit ("Hogy hogy nem képes a WAS support team elindítani a 80as portra bindelő WAS-t root hozzáférés nélkül? Felháborító!")

Lényeg ami lényeg: AIX/Linux alatt ez a progi több mint kötelező, hacsak némileg is törődünk a gép biztonságával. Persze ennek telepítése után se lesz kolbászból a kerítés, sőt, még plusz melót is vartunk a nyakunkba azzal, hogy a /etc/sudoers-t karban kell tartani, de hát istenem, ki mondta, hogy a security fenékig tejföl?

Az issue amivel jelen esetben sikerült szembetalálkoznom kb úgy kezdődött mint minden szokásos "ÚR ISTEN, SECURITY HOLE!!!!" jellegű felkiáltás:
Az IBM által hivatalosan elérhetővé tett sudo 1.6.9p23-as szinten van, viszont pár napja felütötte a fejét egy olyan hiba, ami ezt a verziót is érinti, a customer meg persze az ilyeneket olvasva sikoltozva kiabálja, hogy azonnal tedd fel a javítást. A probléma persze csak az, hogy a hivatalos IBM-es csomag nem elérhető, ergo hivatalos javítást nem tudsz feltenni, ha akarsz se. Customer-t ez persze nem hatja meg, a sudo amúgy sem IBM product, forgass egyet magadtól, az annyira amúgy se nehéz..

Így is lett. Az ember forgat magának 1.7.9es csomagot (hivatalos IBM support innentől sudo-t ne akarjon supportolni :)), customer örül, And so once again the day is saved. Murphy persze hogy erre az alkalomra vár és bedobja az "I don't think so" kártyáját, aztán az admin már meg se lepődik, amikor a customer ismét telefonál, hogy "Őőő.. ez most miért nem megy"? *sigh*

A történet kb az alábbi: Az 1.7.9es sudo óta bejött AIX alatt egy regresszió az alábbi change miatt:
- If none of the standard input, output or error are connected to a tty device, sudo will now check its parent's standard input, output or error for the tty name on systems with /proc and BSD systems that support the KERN_PROC_PID sysctl. This allows tty-based tickets to work properly even when, e.g. standard input, output and error are redirected to /dev/null.

Ez AIX alatt kb úgy néz ki, hogy amennyiben nincs tty device-od a sudo hívásakkor, úgy pityiszt kapsz az orrodra, nemhogy lefutott parancsot.. Persze az ember valami hibaüzenet féleséget várna minimum, de a sudo-val meghívott process ez helyett szimplán csak hang-el, és nem csinál semmit.. Ez persze kifejezetten kellemetlen amikor a customer által futtatott rendszer egy DB2 osztott cluster, ami rah parancsokat használva szeretne a node-okkal kommunikálni, ami persze hogy tty nélküli kulcs alapú ssh chanelleket használ(na), így nem csoda ha a rah parancs is beáll, mint a gerely.

Mondanom se kell, hogy az ember ilyenkor mennyire fel van dobva, és már a telefonálás pillanatában elönti az adrenalin, és a tettvágy, hogy egy ilyen kaliberű hibát kinyomozzon anélkül hogy tudná mit és hol keressen :)
Röviden: pár óra kellemes orális szerelmeskedés (értsd: szopás) után megvan, hogy valószínű az új sudo a hibás, visszarakod a régit, és láss csodát, minden megy ahogy kéne..
Csak a rendszered lett megint non-compliant, tehát amit nyertél a réven, azt veszted a vámon, mert valahogy csak meg kell nézni, hogy mi a fene okozza ezt a hibát..

Újabb kellemes órák, újabb kellemes tesztelgetés, sudo.c turkálás, és hasonló jóságok után az ember eljut oda, hogy a hiba tényleg az 1.7.9ben jött be ( 1.7.8p1en még minden szépen megy), és ha a tty kezelési részt kicsit visszapiszkálja, akkor megy is minden szépen:

devel_box@root:/ # diff /tmp/sudo-src/sudo-1.7.9.gabor/sudo.c /tmp/sudo-src/sudo-1.7.9/sudo.c
628,631c628,630
<
<     if ((p = ttyname(STDIN_FILENO)) || (p = ttyname(STDOUT_FILENO)) ||
<         (p = ttyname(STDERR_FILENO))) {
<         user_tty = user_ttypath = estrdup(p);
---
>
>     if ((p = get_process_ttyname()) != NULL) {
>       user_tty = user_ttypath = p;

Oks.. akkor most már bizonyított: software bug.. nyissunk rá ticketet, aztán a fejlesztő majd megszakérti mi is a probléma -> Bug #557 a sudo-s bugtrackerben, megidézlek!

S lőn fél napon belül megvilágosodás: Valóban regressziót találtunk, sőt régebben már más is jelentette ezt a problémát, csak nem az 1.7-es, hanem az 1.8as szériához. Külön öröm, hogy a következő 1.7.10es verzióban már ez is javítva lesz, sőt, már a béta el is érhető, úgy hogy akinek ilyen igényei vannak, az használhatja azt..

A customer meg döntse el, hogy mit és hogy is akar ezek után :) Aki meg hasonlóval szív, az tegye vissza a régit, vagy használjon béta release-t, amíg az új ki nem jön :)

NFS mount rejtelmek

Mai nap esett meg velem a következő: Mountolni akartam egy távoli NFS-en keresztül kiosztott FS-t, de Murphy épp nevetős kedvében volt és az alábbi üzenettel örvendeztetett meg:

client # mount server:/export /mnt
nfsmnthelp: 1831-019 9.149.40.8: System call error number -1.

mount: 1831-008 giving up on:
server:/export
System call error number -1.

Hát jó.. akkor induljunk neki a szokásos problem determinationnek:
- Az NFS mountolás során első körben az alábbi dolgok történnek (a teljesség igénye nélkül):
A kliens lekéri az NFS szerver IP címét (mivel ugye nem IP-vel akartunk csatlakozni) a géptől. Ennek pontos módja ugye a /etc/netsvc.conf-ban, illetve a /etc/resolv.conf-ban van tárolva.
Ha sikerül neki feloldani az IP címet, akkor megpróbál a távoli géppel egy standard RPC kommunikációt kiépíteni (port 111), majd az adott erőforráshoz (amit én hülye mountolni akarok) hozzáférni. Ezt persze vagy hagyja a szerver vagy sem. Ettől függetlenül azért ez nem egy lépéses játék -> csak az előbb felsorolt dolgokat 3 főbb pontra bontanám:
- IP feloldás
- RPC kommunikáció
- Resource hozzáférés (ide kapcsolnám az authentikációt is)

Persze ezek mellett még van jó pár dolog, de most így első körben azokkal nem törődök.. Nézzük át, hogy a fenti folyamatokhoz szükséges beállítások hogy is vannak:
- Nézzük meg, hogy a /etc/netsvc.conf hogy is próbálkozik a név feloldással:

client # grep -v ^# /etc/netsvc.conf
hosts = local,bind4
server # grep -v ^# /etc/netsvc.conf
hosts = local,bind4

Aham.. szóval ez jónak tűnik. Mind a szerver, mind a kliens a /etc/hosts-ot nézi első körben (local), majd megy a bind felé (IPv4en), ahogy az szerver esetén várható is.
Akkor nézzük tovább. van e bármiféle IP feloldás

client # host server
server is 192.168.1.10
server # host client
client is 10.1.0.20

A host szerint van (ne feledjük el, hogy a host parancs a /etc/netsvc.conf szabályain keresztül nézi ki az IP-t, ahogy azt általában az alkalmazások is teszik). Tekintve, hogy az alkalmazásoknak amúgy is a local felé kell fordulniuk 1x, így ezeket az IP-ket kénytelenek leszünk elfogadni (persze azért nem árt ellenőrizni, hogy a 2 IP valós e - ergo, hogy nincs e elszúrva a /etc/hosts-unk)

Akkor ezek után nézzük meg, hogy a standard hálózat él e mondjuk (sima ICMP, de a teszt erejéig jó lesz)

client # ping -c1 server
PING server (192.168.1.10) 56(84) bytes of data.
64 bytes from server (192.168.1.10): icmp_seq=1 ttl=243 time=75.6 ms

--- server ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 75.690/75.690/75.690/0.000 ms

server # ping -c1 client
PING client (10.1.0.20) 56(84) bytes of data.
64 bytes from client (10.1.0.20): icmp_seq=1 ttl=243 time=75.6 ms

--- client ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 75.690/75.690/75.690/0.000 ms

Az ICMP csomagok szépen átmennek, ergo a 2 gép eléri egymást.
# Note - jelen esetben a 2 gép 2 külön hálón van, viszont rálátnak egymás hálózataira, így ennek nem szabadna hibának lennie.

Persze lehet hogy van még tűzfal a 2 között, így nem árt ellenőrizni azt se, hogy a kliens rálát e a szerverre, és annak szolgáltatásaira:

client # showmount -e 192.168.1.10
Export list for 192.168.1.10:
/export (everyone)
client # rpcinfo -p 192.168.1.10
program vers proto port service
100000 4 udp 111 portmapper
100000 3 udp 111 portmapper
100000 2 udp 111 portmapper
100000 4 tcp 111 portmapper
100000 3 tcp 111 portmapper
100000 2 tcp 111 portmapper
100003 2 udp 2049 nfs
100003 3 udp 2049 nfs
100003 2 tcp 2049 nfs
100003 3 tcp 2049 nfs
100003 4 tcp 2049 nfs
200006 1 udp 2049
200006 4 udp 2049
200006 1 tcp 2049
200006 4 tcp 2049
100024 1 tcp 37470 status
100024 1 udp 50261 status
100133 1 tcp 37470
100133 1 udp 50261
200001 1 tcp 37470
200001 1 udp 50261
200001 2 tcp 37470
200001 2 udp 50261
100021 1 udp 50344 nlockmgr
100021 2 udp 50344 nlockmgr
100021 3 udp 50344 nlockmgr
100021 4 udp 50344 nlockmgr
100021 1 tcp 37472 nlockmgr
100021 2 tcp 37472 nlockmgr
100021 3 tcp 37472 nlockmgr
100021 4 tcp 37472 nlockmgr
100005 1 tcp 37711 mountd
100005 2 tcp 37711 mountd
100005 3 tcp 37711 mountd
100005 1 udp 50432 mountd
100005 2 udp 50432 mountd
100005 3 udp 50432 mountd
400005 1 udp 50433

Ez alapján én azt mondanám, hogy gyönyörűen látja a kliens amit kell. Ráadásul a showmount kimenetéből láthatjuk azt is, hogy az adott megosztás mindenki számára elérhetőnek kéne lennie.. Ezt azért ha lehet nem árt tényleg leellenőrizni is:

server # lsnfsexp
/export -rw

Ez alapján tényleg azt mondom, hogy ennek így jónak kéne lennie. (ha ezek közül valami nem megy, akkor nyomban gyanakodhatunk firewall/routing, vagy valami network típusú hibára )

2. lépésben szoktam nézni a rendszer (jelen esetben AIX) specifikus függőségeket.
Az egyik ilyen alap függőség, hogy az adott mappa (ahova mountolni akarunk) létezik e (tudom triviális, még is sokszor megszivatja az embert ,ha figyelmetlen):

server # ls -ld /mnt
drwxrwxrwx 229 root system 20480 07 Jun 13:05 /mnt

Persze általában ezt nem nézzük ennyire be, így a következő amire figyelni kell az az NFS beállítások mind a kliens, mind a szerver oldalon. Ezek közül is 2 van, ami az authentikációért felelhet (az NFS szabályokon felül) olyan módon, hogy kötötté teszik a standard portok használatát:

client # nfso -a |grep port
nfs_use_reserved_ports = 0
portcheck = 0
server # nfso -a |grep port
nfs_use_reserved_ports = 0
portcheck = 0

Általában illik a szerver és a kliens oldalnak ezen beállításokban egyezniük, mert ha nem az simán okozhat ilyesmi hibát. Sajna azonban itt nem ez a helyzet.
Ha ezek után se szokott menni, akkor szoktam azt a randa játékot játszani, hogy azt hiszem, hogy nem én, hanem az NFS szerver a hülye, így simán megpróbálom törölni, majd újra létrehozni az NFS megosztást ( tudom, Windows-os beütés, de néha működik)

server # smitty rmnfsexp
server # smitty mknfsexp

A probléma ott van, hogy nálam ezek után se működött a dolog, így végső kétségbeesésként megpróbálkoztam egy teljes NFS restartal :) - ki tudja, hátha beragadt valami:

server # stopsrc -g nfs
server # stopsrc -s portmap
server # rm -rf /etc/state /etc/rmtab /etc/xtab
server # startsrc -s portmap
server # startsrc -g nfs
server # exportfs -a

A gáz onnan indult, hogy még ezek után se ment a játék.. Más kliensek gond nélkül fel tudták csatolni a megosztást, de ez az 1 makacsul nem engedett.
Ekkor döntöttem el, hogy akkor nézzük meg mélyebbről is a játékost - tracelgessünk kicsit:

client # startsrc -s iptrace -a "-a -b /tmp/iptrace.bin"
client # mount 192.168.1.10:/export /mnt
client # stopsrc -s iptrace
client # ipreport -rnvs /tmp/iptrace.bin > /tmp/iptrace.bin.out

A problémám ott kezdődött, amikor konstatálnom kellett, hogy az egyetlen gyengécske nyom kb ennyiben nyilvánult meg:

Packet Number 260
ETH: ====( 86 bytes received on interface en0 )==== 13:12:00.036155006
ETH: [ 00:0f:90:aa:ea:ff -> 00:02:55:33:ec:e5 ] type 800 (IP)
IP: < SRC = 192.168.1.10 > (server)
IP: < DST = 10.1.0.20 > (client)
IP: ip_v=4, ip_hl=20, ip_tos=0, ip_len=72, ip_id=17465, ip_off=0
IP: ip_ttl=57, ip_sum=f220, ip_p = 6 (TCP)
TCP:
TCP: th_seq=3365614187, th_ack=44423836
TCP: th_off=5, flags
TCP: th_win=65535, th_sum=5ee7, th_urp=0
RPC: Record Marker: Size = 28, Last Fragment (0x8000001c)
RPC: **REPLY** XID=1310050721
RPC: 100005(MOUNTPROG) 1(MOUNTPROC3_MNT)
RPC: Reply Stat: MSG_ACCEPTED
RPC: Accepted Reply Stat: SUCCESS
MNT: Status=Protocol Error, Bad mnt_stats (-1)

Fejvakarás, töprengés... Wattafák... Vissza az alapokhoz..
Az stimt, hogy a kapcsolat kialakításához kell egy IP kapcsolat (ami megy is az előző lekérések alapján), viszont belegondolva van az NFS-nek egy olyan funkciója, hogy "reverse name lookup". Ez a funkció elvileg arra hivatott, hogy garantálja, hogy a kliens a szerverrel, illetve a szerver a kliensel beszél az által, hogy a kapcsolat felépítésekkor leelenőrzi azt, hogy a kiépülendő kapcsoalat valóban a 2 fél között jönne e létre.
Ezt valahogy úgy próbálja megcsinálni, hogy:
- A kliens valahogy feloldja a szerver IP címét, majd erre megpróbál csatalakozni
- A kapcsolat során elküldi azt, hogy ő kicsoda, illetve mi is az IP címe
- A szerver reigsztrálja a kérést, majd megnézi, hogy a kliens az ő névfeloldása alapján valóban az e, akinek állítja magát (ergo csinál vissza fele is egy névfeloldást)
- Amennyiben a feloldott IP egyezik azzal, ahonnét jött a kapcsolat akkor megy tovább a kapcsolat kiépítésével
- Természetesen a kliens is eljátsza ugyan ezt (hiszen RPC kommunikációról beszélünk), és ha már ott jár, akkor a szervertől kapott azonosítóval megnézni, hogy valóban jó géppel akar e autholni

Ez security oldalról tényleg értelmes dolog.. Hiába van egy világnak megosztott NFS megosztásom, attól még nem akarom, hogy ezt valaki kihasználva bármi csúnyaságot csináljon. Szerver esetében ugye átalában a netsvc.conf alatt a local az elsődleges rule, így ez miatt erősen ajánlott, hogy mind a kliens, mind a szerver tudjon a másik pontos címéről a /etc/hosts alatt.

A probléma az, hogy ugye ezt ellenőriztük fentebb.. Őőő.. vagyis nem teljesen.. Mint mondtam a vissza azonosítás oda vissza irányul -> Kell az is, hogy a gép önmagáról is "hiteles" adatot küldjön.. És itt volt a kutya elásva: A szerver oldalon a 'server' más IP címmel volt felvéve a /etc/hosts alatt (az ok egyszerű: A 'server' alapból egy másik alhálózatért felel, és azokat a kapcsolatokat meg csak ezen keresztül érheti el).

Ez miatt viszont az egész reverse name lookup meghiusul, mi meg nézhetjük a földön gyülekező hajtömegetet és a ráncokat a tükörbe..
A megoldás ezek után adná magát: Írjuk át a szervernél a /etc/hosts-ban a 'server' IP címét.. A probléma az, hogy ebben a környezetben, ahol a szerver másik alhálóért is felel (vagy inkább azt tekinti elsődlegesnek) ezt nem teheti meg az ember, mert a végén másik kliensel szúr ki.

Akkor viszont marad a másik útvonal: Ki kéne kapcsolni ezt a biztonsági funkciót.. A kérdés csak, hogy hogyan.

Nos.. a vicc a következő: A mountolás ezen fázisában ezért a funkcióért az rpc.mountd felel a szerver oldalon.. Ennek meg a vicc kedvéért van egy nem nagyon dokumentált kapcsolója, amit az ODM alá felvéve gyönyörűen lehet semlegesíteni ezt a működést. Az átállítás módja kb így néz ki:

server # stopsrc -s rpc.mountd
server # chssys -s rpc.mountd -a "-x"
server # startsrc -s rpc.mountd

Ez után, akkor próbálkozunk újra:

client # mount server:/export /mnt
client # mount |grep mnt
server /export /mnt nfs3 12 Jul 08:59

Öröm és bóduttá...

Linux - "Full" disk encryption

Úgy esett, hogy a hétvégémet rászántam, hogy a Thinkpadomon lévő Ubuntu alapú rendszert átpatkoljam, hogy a rajta lévő összes adat encrypted legyen (éljen a security).. Hát.. Valahogy nem úgy ment, ahogy vártam :)

A terv a következő volt:
- LiveUSB alól készítek egy backupot a futó rendszeremről
- Alternate install bebootol, majd az alól újrahúzom a rendszerem immár Encrypted LVM-el (LUKS), majd az LVM-en belül létrehozom az LV-ket, amiket meg aztán mountolgatok a megfelelő pontokra
- Backupból visszahozok minden fontosabb adatot, illetve az összes telepített programomat is, ha már ott tartok
- Profit..

Csak hát Murphy (plusz az én felkészületlenségem is részben) nem így gondolta.. nézzük mi is történt a valóságban.

- Backup:
A kiszemelt 40 GB-os USB-s vinyó (amit a backup céljára kiszemeltem) sajna csak 1 USB csatlakozóval rendelkezett, a hozzá illő tápcsatalakozót nem mellékelték. Ettől függetlenül persze a gép szépen látta az eszközt, sőt írni is hajlandó volt rá.. A probléma onnan indult, amikor random időközönként leszakadozott, így téve lehetetlenné, hogy backupot csinálhassak rá. Ez azért is volt problémás, mert hogy a közelben már csak egy gép volt, az is Windows.. Sebaj mondom, csinálok egy SMB megosztást, oda meg áttolok mindent.. Persze ahhoz, hogy a file attribútumokat megtartsam ezt úgy tudtam csak levezényelni, hogy mindent egy tar-ba toltam bele.. Így lett a végén egy közel 37 GB-os tar file-om.. De legalább volt backup.. De persze úgy voltam vele, hogy 1 backup nem backup (főleg nem ha tar), így biztosra mentem, és csináltam egy teljes dd mentést is a diszkről, ami szintén a Win-es gépen foglalt helyet a művelet végeztével. Így már úgy éreztem, hogy bármi történjék, nem lehet baj (max visszahúzok mindent bitre pontosan ahogy volt a dd backupból)

- Telepítés
Mivel a rendszer ubuntu alapú, így az elképzelésem a következő volt: leszedem az alternate install-t (a grafikus telepítő nem támogat se LUKS-ot, se LVM-et), majd azzal megcsinálom. Tekintve, hogy a művelet végén amúgy is vissza akarok pakolni minden applikációt ami eredetileg fent volt, így lényegében csak az alapok érdekeltek. Így hát fogtam magam, leszedtem az alternate telepítőt, majd unetbootin-al felpakoltam USB-re (optikai lemezt már jó ideje nem szeretek ilyenre használni). Az első probléma ott volt, amikor a rendszer jelezte, hogy nem találja a CD meghajtót.. Néztem is nagyokat, hogy akkor most wattafák..
A problémára az első talált megoldás az lett, hogy a pendrive-on lévő Lucid mappát át kell nevezni stable-re (ami amúgy egy symlink lenne, csak persze FAT32-őn ez így nem megy), az majd megoldja a problémát. Szóval át TTY2-re, átnevez, "CD" újrainicializálás, és ment tovább.. Éljen..
A következő dilemma ott jött amikor particionálni kellett a rendszert.. A régi partíciós kiosztásom a régebbi migrálások miatt amúgy is elég kusza volt, így úgy gondoltam, hogy most már kicsit rendszerezünk is. Először viszont el kellett döntsem milyen filerendszert használjak az LVM miatt..

Szivem szerint Reiser4-et raktam volna majdnem mindenhova, de az sajna nem része a telepítőnek (ahogy a Brtfs és a ZFS se), így az alábbi lehetőségeim maradtak
- A 10.4es Lucid alatt támogatott modern filerendszerek, amelyeket növelni is lehet az alábbiak:
- ext4 - ezt személy szerint kerülöm, mint a rossz pénzt - az egyetlen filerendszer, amely fsck-ja képes a teljes FS-t a lost+found alá száműzni
- XFS - Ezt sajna csak növelni lehet (azt legalább online), csökkenteni nem
- ReiserFS - Lehet növelni, és csökkenteni is (ezt sajna csak offline), viszont a tapasztalatok alapján XFS jobban teljesít notebook-on.

Mivel az XFS-el vagyok a legjobban megelégedve, így úgy gondoltam, hogy ahol lehet (és nem számítok FS csökkentésre) úgy ott azt használom, máshol marad a Reiser.. Ergo az az alábbi stratégiával álltam elő:
/dev/sda1 - /boot (ext2) - 120 MB ( Ugye a GRUB 2 se tud encryptált kötetről bootolni, szal a /boot kénytelen a LUKS-on kívül lenni)
/dev/sda2 - Encrypted Volume (LUKS)
Az encrypted Volume-on belül pedig fogtam magam, és létrehoztam egy LVM-et, azon belül egy rootvg nevű VG-t, alatta pedig az alábbi LV-ket:
- datalv - /data (ReiserFS) - 20 GB
- homelv - /home (XFS) - 20 GB
- rootlv - / (ReiserFS) - 12 GB
- swaplv - SWAP (2 GB)

A biztonság kedvéért azért még hagytam 5 GB-ot a VG-ben kiosztatlanul, hogy ha kell akkor ne adj isten valakinek oda tudjam majd adni.
Miután ezt megcsináltam a telepítő közölte, hogy márpedig neki ezeket az adatokat fel kell írnia a diszk-re, és tuti biztos vagyok e abban, hogy én ezt komolyan akarom.. Magamban még1x átgondoltam a helyzetet, megbizonyosodtam, hogy minden szükséges óvintézkedést megtettem (backup!!!), majd úgy éreztem, hogy üsse kavics, a Vasárnap 13 óra pont alkalmas arra, hogy szeretett gépem OS-ét végérvényesen kibelezzem...
Ubuntu fel is írta az adatokat, majd váratlanul egy olyat szólt, hogy:
"Couldn't detect codename for release."
Ahogy nézem azért nem csak nekem kedveskedett már ez az üzenet..
Innen pedig a telepítő úgy gondolta, hogy nem is érdemes továbbmenni.

Na akkor vissza a kályhához... Újabb keresés, miközben az öröm a plafonon, hogy a partíciós tábláim is a levesben vannak már.. Aztán a megoldás is szembejött: A 'cdrom-detect/try-usb=true' bejegyzést is be kell szúrni az unetbootin által létrehozott menü entry-k közé.

Miután ez megvan irány vissza a telepítő, majd ismét a particionálás , majd vártam, hogy most már azért tovább is menjen.. Mázlimra tovább is ment, és a rendszer nagyja fel is ment.. Aztán valamiért ismét elhasalt, de itt már nem nagyon érdekelt ez az apró részlet - felraktam a GRUB2-t is az MBR-re (illetve a /boot alá), és restartoltam..
És lőn csoda- működik.. Igaz nincs se grafikus környezet, se wifi, se hasonlók, de legalább az alap rendszer működött, és ez volt ami nekem számított.. Innen már azt hittem sima dolog lesz minden: Nagy erőkkel neki is szaladtam a restore-nak a backupból.. Pontosabban szaladtam volna, mert a CIFS-et a mount itt még nem ismerte (nem voltak fent a szükséges csomagok).. És itt ütött (nagyon) vissza a 37 GB-os tar file.. Win alól tudtam olvasni, de úgy nem tudtam használni, hogy az attribútumokat is megtartsa a file..
Ergo ismét vissza a tervező asztalhoz...
A dolog vége az lett, hogy a Win-es gépen létrehoztam egy Virtuális gépet (Virtualbox), azt a rendszert felbootoltam egy Live USB image-el (ott már volt SM támogatás), bemountoltam a Win-en kiosztott SMB megosztást, kicsomagoltam a /etc-t (mc), majd ismét összetaroltam, visszaraktam a másik tar file mellé, azt átvittem pendrive-on, és figyelve, hogy az fstab-ot véletlenül se írjam felül visszaállítottam a /etc tartalmát.. Innentől már megvoltak a régi repository-jaim, ergo simán ment az apt-get update is, és fel tudtam rakni a szükséges csomagokat. Ez után már be tudtam mountolni a távoli SMB megosztásom, és láttam is a backupom..
Újult erővel indultam neki a restore-nak, ám ismét utamat álta egy  rendkívül idegesítő dolog: az mc nem volt képes lekezelni ekkora tar file-t (folyamatosan I/O error-ra panaszkodott), én meg nem akartam a teljes tar-t kibontani a filerendszerekre 2 oknál fogva:
- Nem akartam felülírni semmiféle olyan file-t ami esetleg a kernelhez köthető, vagy a grubhoz, esetleg bármi máshoz ami az új rendszer részeként fontos lehet..
- Mint előbb is mondtam a mountokat kicsit átalakítottam, így most már 1-2 FS nem is volt elérhető ott ahol régen voltak, az újak alatt meg nem volt ennyi szabad hely..
180 fok, vissza a fő géphez, és a Virtualbox-ban futó linuxhoz: Hozzácsaptam ehhez a géphez egy 60 GB-os kötetet, majd a teljes backupomat kicsomagoltattam ide.
Amint ez kész lett kiszedtem azokat a mappákat/file-okat amiket nem szeretnék felülírni véletlenül se, majd (immár kissebb méretben) újabb tar file-okat hoztam létre, amit immár az mc is képes volt megenni.. Pontosabban nem egészen.. Az mc a jelek szerint allergiás a speciális karakterekre (főként a @-ra, amire váltig állítja, hogy hardlink akar lenni), így maradt a puritán 'tar -xv' megoldás, amit így már rá is mertem engedni a gépre, tekintve, hogy már kigyomláltam a problémásabb részeket.
A művelet végére sikerült mindent visszaállítani, a gépem be is bootolt szépen, felállt a rendszerem is, bár volt még 1-2 problémásabb dolog..
Ami nekem első körben probléma volt: a rendszer által felrakott kernel-lel már voltak régen inkompatibilitási problémáim, így ez volt az a pont amit még mindenképp meg akartam csinálni. Ekkor már kb éjfél volt, de úgy voltam vele, hogy ezt még befejezem, aztán holnap már tudok is dolgozni a géppel, max munkaidőben a többi kisebb dolgot megcsinálom.. Ergo nekiálltam egy frissebb kernelt telepíteni.. Ez volt a hiba... A friss kernel olyan gyönyörűen felülvágta az initrd-met, hogy öröm volt nézni.. A következő indulással pedig már a crypt be se töltődött, és bámultam a fekete busybox-ot 2 asztal fejelés között..
Itt voltam úgy, hogy ezt már nincs mese, valahogy meg kell csináljam, holnap ezzel a géppel dolgozni kell. Próbálgattam a grub paraméterekkel játszani, de gyorsan be kellett lássam, hogy ha az initrd-ben nincs benne az ami nekem kell, akkor itt semmiféle grubos fekete mágia nem segít. Így hát liveUSB ismét elő, gép bebootol, kómás fej felébreszt, és lelki szemeimmel bámulom a szakadék túloldalán lévő partot, amihez most ismét nekem kell felépítenem a hidat.. Ami kb így nézett ki:

Feloldottam a titkosítást:
# cryptsetup luksOpen /dev/sda2 rootvg
Aktiváltam a VG-t:
# vgchange -a y rootvg
Megnéztem, hogy minden megvan e:
# lvm vgs
VG #PV #LV #SN Attr VSize VFree
rootvg 1 4 0 wz--n- 55.77g 5.49g
# lvm lvs
LV VG Attr LSize Origin Snap% Move Log Copy% Convert
datalv rootvg -wi-ao 18.62g
homelv rootvg -wi-ao 18.62g
rootlv rootvg -wi-ao 11.18g
swaplv rootvg -wi-ao 1.86g
Bemountoltam a megfelelő FS-eket a /mnt/chroot alá:
# mount /dev/mapper/rootvg-rootlv /mnt/chroot
# mount /dev/sda1 /mnt/chroot/boot
# chroot /mnt/chroot
# mount -t proc proc /proc
# mount -t sysfs sys /sys
# mount -t devpts devpts /dev/pts
Ez után megnéztem hol is baxtam el.. Hát persze.. Én barom felülírtam a /etc/crypttab-ot, illetve a /etc/initramfs-tools/modules alatt se vettem fel az új dolgokat.. Erre bizony figyelni kellett volna.. Na mind1.. Pótoljuk akkor be..

# grep -v ^# /etc/crypptab
rootvg /dev/sda2 none luks,retry=1
# egrep -v "^#|^$" /etc/initramfs-tools/modules
aes-256
dm-crypt
dm-mod
sha256

Majd akkor ismét generáljuk újra az initrd-inket:
# update-initramfs -k all -c

Aztán restart, és ima...
Mákom volt.. Ez megoldotta a problémák nagyját.. A rendszer felállt, bár jó pár dolog nem ment (wifi, aku kijelzés,hang, network manager).. Ekkor már kb hajnali 2 volt, így úgy gondoltam, hogy nem érdekel, ebből már "holnap" tudok valamit kezdeni munkaidőben is.. dhclient megy, IP-t tudok kérni a kábelen keresztül, a fontosabb appok mennek, ezeket a hülyeségeket meg majd megoldom alvás után.
"Másnap" aztán kicsit kipihentebb fejjel átgondoltam mi a fészkesért is mehetett szét így minden, hisz az initrd piszkálás előtt ezek még mentek.. Első körben azt hittem elfelejtettem valami modult még belepakolni, de visszanézve a régi modulok listáját nem nagyon találtam különbséget, így ezt kénytelen voltam elvetni.. Majd fejbe csapott az isteni szikra: Mindezt a sok hülyeséget a dbus irányítja most már (hald sajna már nincs), így azt kéne helyrecsapni.. Mázlimra az első próba megtette a hatását:
# dpkg-reconfigure dbus
Ez után minden ment ahogy annak kellett.. Öröm és bóduttá.. Ismét tudtam dolgozni..

De persze ez a sztori nem lenne teljes, ha itt befejezném.. Akárhogy is nézem, azért volt jó pár dolog amiket ki szeretnék emelni:
- A tar nem backup solution.. Hiába használható annak, attól még lehet egy rsync-el jobban jártam volna, vagy más megoldással
- Este, fáradtan ne kezdjem el a rendszer alapkövét (kernel) piszkálni, mert nem biztos, hogy kifizetődő
- Legközelebb inkább telepítsem újra az egész gépet 0ról, és úgy húzzam vissza a dolgokat. Igaz, hogy ez a megoldás működőnek látszik, viszont nem tudom hány problémás részt hagytam a gépben, ami később visszaüthet. Egy clean install lehet problémamentesebb lett volna.
- Mielőtt nekiállok valami hasonlónak, 1x csináljam azt meg egy virtuális rendszeren! Csak én lehettem akkora marha, hogy a tényleges rendszernek mentem neki tényleges "szimuláció" nélkül, ami sok kellemetlenségtől megkímélt volna, plusz alapból olyan tapasztalatokat szolgáltatott volna, amik révén a tényleges migrálás valóban probléma mentesebb lett volna ( bár az is igaz, hogy ha ott egy ilyen issue-ba belebotlok, akkor ott valószínű nem kezdek el ilyen keményen dolgozni, hogy mindent helyrehozzak amilyen gyorsan csak lehet, és valószínű  ez a project jó pár hetet késett volna)

AIX Security Expert

Mai napi érdekesség: Találkozott már bármelyikőtök valaha is az 'AIX Security Expert' nevü kis tool-al? Én személy szerint még csak most ismerkedek vele, viszont ránézésre elég kellemes kis tool (megfelelően használva persze), amelyel - az amúgy default egyáltalán nem biztonságos default AIX telepítés - elég jól biztonságossá tehető (hardening)
A tool alapjáraton a bos.aixpert file-set-el érkezik, ami után egy command line tool-t (aixpert), egy smitty alá beépülő menüt, illetve ha van System Director ( a jelenlegi tendencia szerint előbb utóbb úgy is lesz :)) akkor egy az alá beépülő modult kapunk, plusz a standard WebSM-es módon is (már ha van fent WebSM-ünk) elérhetővé válik a cucc. Viszont mivel mint tudjuk a console-os parancsok a menők, így maradjunk is annál :)
A tool amúgy egy xml file alapján képes a dolgokat beállítani (ergo ha a konzolos aixpert paranccsal akarunk dolgozni, akkor ezt kell állítgassuk - grafikus klikkelgetősnél persze ez nem így néz ki), és ami még fontosabb -némi korlátokkal ugyan, de- visszaállítani az esetlegesen elszúrt konfigurációt.
A tool-ról amúgy részleges leírást az alábbi oldalakon lehet találni, érdemes átolvasgatni őket:
http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=/com.ibm.aix.cmds/doc/aixcmds1/aixpert.htm
http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=/com.ibm.aix.security/doc/security/aix_sec_expert.htm
http://www.ibm.com/developerworks/wikis/display/WikiPtype/aixpert

Mellékesen egy egész jó kis "mit ne szúrjunk el" eset tanulmány született az alábbi oldalon is a toolról:
http://www.ibm.com/developerworks/aix/library/au-aixsecexpert/index.html

5.8p1 OpenSSH forgatása AIX-re (gcc)+ csomag készítés (bff)

Sikerült belefutni egy elég idegesítő bugba..
Az AIX-hoz jelenleg elérhető legfrissebb OpenSSH (5.4p1) sajna egy elég pofátlan buggal érkezett - a csomagban lévő sftp-ből kiszedték az mput parancsot, amit 1-2 team nem fogadott őszínte mosollyal.
Az OpenSSH Changelogját elnézegetve látszik is, hogy ez tényleg nem azért történt, mert a funkció bugos lett volna, vagy hasonló, hanem szimplán "elveszett", ám az 5.6os verzióba már vissza került.. Ám mivel hivatalosan csak 5.4 állt rendelkezésre, így gondoltam nem szöszölök, nyomban forgatok egy latest-et (5.8p1)
Hozzávalók:
A forrás: http://ftp.fsn.hu/pub/OpenBSD/OpenSSH/portable/openssh-5.8p1.tar.gz
Némi kis dokumentáció: ftp://ftp.ca.openbsd.org/pub/OpenBSD/OpenSSH/portable/INSTALL
Zlib (A forgatáshoz): http://zlib.net/zlib-1.2.5.tar.gz
Illetve OpenSSL >=0.9.6
#Note - A forgatáshoz gcc-t választottam (ezt szoktam meg :)), de persze ha igazi IBM-es akarnék lenni, akkor XlC-t használnék.. Én úgy éreztem, hogy már így is kékebb a vérem mint kéne, így inkább nem teszek még rá még1 lapáttal :)
Mivel az 5.4-el szállított OpenSSL alapból is 0.9.8-al jött, így hála az égnek azzal nem kellett szöszöljek. A zlib viszont sajna ilyen állatfaj, úgy hogy a forrás leszedése után az a standard ./configure, make, make install triumvirátussal fel is kerül a helyére.
Az OpenSSH viszont érdekesebb állatfaj..
Az első problémája, hogy ha csak simán felrakja az ember a zlibet, akkor nem akaródzik megtalálni.. Nem baj, van --with-zlib kapcsolója a configure-nak.
Ami viszont már nagyobb fejfájást okozott az az alábbi jelenség volt:

ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 1136) in object clientloop.o:
The symbol refers to a csect with symbol number 0, which was not
found. The new symbol cannot be associated with a csect and
is being ignored.

Némi kis nyomozás után kiderül mi a ludas: Hőn "szeretett" gcc-m: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46072
Ez a bug eddig még így nálam nem jött elő, de akkor innentől megjegyzem magamnak, hogy ezek után minden gcc-vel AIX-ra forgatott parancsnál ezt kötelezően használni illik:

--with-cflags=-g0

/* Az mondjuk külön vicc, hogy így a forgatás kb az alábbi módon fog kinézni:

gcc -g -O2 -Wall -Wpointer-arith -Wuninitialized -Wsign-compare -Wformat-security -Wno-pointer-sign -fno-strict-aliasing -fno-builtin-memset -g0 -I. -I.. -I. -I./.. -I/usr/local/include/ -DHAVE_CONFIG_H -c bsd-arc4random.c

Láthatólag a -g0 simán felülbírálja a -g-t a gcc-nél,de ha neki megfelel, akkor ki vagyok én, hogy ellenkezzek.. */
Így már hőn szeretett OpenSSH-nk is simán lefordul
[/i]/* A teljesség igénye nélkül: Az alábbi forgatási funkciókat használtam:

./configure --prefix=/usr --sysconfdir=/etc/ssh --with-cflags=-fno-builtin-memset --with-cflags=-DBROKEN_GETADDRINFO --with-cflags=-g0 --with-zlib=/usr/local/include/

*/[/i]
Amint készen vagyunk ezzel, nyomban make install-t is nyomhatunk, vagy ha lusták vagyunk, akkor nyomban a csomagban lévő script-el telepíthető bff csomagot készíthetünk az alábbi módon:

AIX_SRC=yes contrib/aix/buildbff.sh

Viszont én kicsit többre vágytam, így úgy gondoltam, hogy kicsit ragaszkodjunk is az eddigi csomagoknál használt naming convention-höz is, meg had legyen ez már tényleg olyan, amilyennek én szeretném :)
A választott célezközöm pedig az mkinstallp alkalmazás volt (bos.adt.insttools csomag része)
Első kör:
A make install-ból, vagy a forgatott file-jainkból állítsuk össze a szükséges mappa struktúrát (file jogosultságokra figyeljünk! )

# [/tmp/openssh/5.8p1/package:] find . -type f
./usr/openssh/README
./usr/openssh/license_ssh.txt
./usr/openssh/ChangeLog
./usr/sbin/ssh-rand-helper
./usr/sbin/ssh-keysign
./usr/sbin/sftp-server
./usr/sbin/sshd
./usr/bin/ssh-add
./usr/bin/ssh-keygen
./usr/bin/ssh-agent
./usr/bin/ssh-keyscan
./usr/bin/scp
./usr/bin/sftp
./usr/bin/ssh
./etc/ssh/moduli
./etc/ssh/ssh_prng_cmds
./etc/ssh/ssh_config
./etc/ssh/sshd_config
./etc/ssh/ssh_config.default
./etc/ssh/sshd_config.default
./etc/rc.d/rc2.d/Ssshd
./etc/rc.d/rc2.d/Ksshd

Második kör:
Hozzuk létre a szükséges pre/post install/uninstall scripteket (kicsit szöszölős meló). Én személy szerint úgy voltam vele, hogy szeretem elszeparálni a különböző taszkokat, így az alábbi file-okat dobtam össze:

# [/tmp/openssh/scripts:] find . -type f -ls
18780 1 -rw------- 1 root system 786 Mar 4 15:30 ./openssh.base.client.unpost_i
18775 4 -rw------- 1 root system 3221 Mar 7 17:47 ./openssh.base.server.post_i
18778 1 -rw------- 1 root system 803 Mar 4 15:30 ./openssh.base.server.pre_i
18777 1 -rw------- 1 root system 871 Mar 4 15:30 ./openssh.base.server.unpost
18779 1 -rw------- 1 root system 537 Mar 4 15:30 ./openssh.base.server.unpre_i

Harmadik kör:
A végére pedig dobjuk össze a template file-t ami alapján az mkinstallp majd dolgozni is tud:

# [/tmp/openssh/5.8p1/.info:] cat openssh.template*

*Katt az openssh.template alatt elérhető pastebin.com-os linkre
/* Személy szerint nem nagyon vagyok oda a licensz file-okért, de azért adjuk már meg a módját, ha nem kerül sok erőfeszítésbe */
Ha minden kész, akkor a célmappánkból indítva az alábbi parancsot kedves kis bff csomag vár majd minket a tmp/ alatt:

mkinstallp -d /tmp/openssh/5.8p1/package/ -T /tmp/openssh/5.8p1/.info/openssh.template

/* Ami a lustaságom miatt hiányzik: Nincs dependency check - azért azt az OpenSSL-t tényleg nézni kéne */
Ami előny ebből kijött:
- Saját csomag
- Ha nem is hivatalosan, de ismét helyreállt az mput funkció az sftp-n belül (legalább is amíg hivatalos csomag nem lesz helyette)
- A debug flag kikapcsolása miatt (-g0) az elkészült binárisok közel fele akkor lettek, mint a hivatalos csomagban elérhetőek (debugolni meg nem nagyon óhajtom ezt amúgy se)
- Ez kis howto a közösségnek :)