Ma a saját rendszeremet kellett feltörnöm. Izgalmas munka volt. 🙂
Tapasztalat: a vld nem működik ha van zend encode.
szerver
vserver kernel patch gutsyhoz
Elkészítettem a Gutsy server kernelhez igazított VServer kernel foltot. Azért ehhez mert a hardy-ban található kernelhez még nem adtak ki stabil foltot.
Közben sikerült forgatnom az előzőből egy deb csomagot, amit ha lesz időm tesztelek, és ha használható felteszem (igaz feisty, de ki tudja kinek jön még jól :)). Ugyan így készül deb csomag a most készített foltból is.
magyar postfix feketelisták
A hup-on található spammer szégyenfal adta az ötletet, egy magyar feketelistához, mely ip alapú. Kicsi ország kicsi tartomány. 🙂
http://workshop.connor.hu/hipbl.php
http://workshop.connor.hu/hispbl_dump.php?type=postfix
Ez kétféle lista, előbbi egy ip alapú feketelista, utóbbi a magyar dialup tartományokat hivatott összegyűjteni (kaptam már vodás mobilnetről spamet).
Csak olyan IP-ket hagyok jóvá amik a hup topic-ba felkerülnek a bizonyító erejű spam szövegével együtt. Tartományokat viszont szívesen veszem ha küldötök (hiszen nem férek hozzá minden szolgáltató minden hálózatához, hogy tudjam pl az upc-nek mi).
Adott kliens ip netmaskja whois alapján:
IP=$(wget myip.connor.hu -O – -q); netmask $(whois $IP | grep ^inet | sed ‘s/\ \-\ /:/’ | awk ‘{ print $2 }’)
frissítési tapasztalatok
Befejeződött egy kiszolgáló és egy “élesben” (értsd: mindennapi irodai felhasználásban) használt Ubuntu frissítése.
Az kiszolgáló gutsy volt és a fejlesztői szerverem. A munkáim és az erre-arra kicsapongások során sok minden felkerült a gépre így elég sok lom volt már teljesen fölöslegesen. Ez meg is bosszulta magát mert a frissítéskor a postconf scriptek által futtatott ldconfig futtatásakor teljesen véletlenszerűen elhalt. Mivel már egyébként is újra akartam telepíteni ezért a gép sorsa egy teljes újratelepítés lett. Legalább megnéztem milyen manapság egy kiszolgálót újratelepíteni. Gyorsan ment.
Az irodai gép viszont érdekesebb téma. Itt nem Gutsyról (feisty) egy lépésben frissítettem. Ez szintúgy tartogatott meglepetéseket, de nem is vártam mást, így inkább a tapasztalatokat osztanám meg.
Frissítéskor néha rákérdezett, hogy a módosult beállító fájlokkal mit kezdjen. Ezen tapasztalt debianos nem lepődik meg, hanem okosan eljár.
Néha ki kellett adni a dist-upgrade és install -f kapcsolókkal az apt-get-et. Hal Dbus párossal volt egy kis gond. De azt is meg lehet oldani.
Teljesen távoli frissítés után nem jött vissza a gép így kénytelen voltam lemenni az irodába megnézni, hogy mi történt, ahol is egy ehhez merőben hasonló sor sormintázta a képernyőt:
localhost kernel: [ 163.056000] device-mapper: table: 254:0: linear: dm-linear: Device lookup failed
Kis google után arra jutottam hogy az evms eltávolítása a megfelelő megoldás. A kernelbe gutsy alkalmával egy folt került amit az evms nem szeret. Feltehetőleg a feisty => gutsy frissítéskor ezt a programot leszedi a frissítés, viszont a feisty => hardy során nem. Rebootkor ez meg is bosszulta magát. Megoldás ilyenkor hogy frissítés után kézzel leszedjük vagy, ha elfelejtettük megtenni ezt, akkor helyreállító módban a gyökér kötet fölött készített chroot-on belül leszedjük az evms csomagot utólag.
Következő meglepetés az indítás után ért. Egyrészt lefutott az fsck ami ezúttal már szépen beleépült az uspash-ba, másrészt elindult a failsafe. Előbbinek örültem, utóbbinak már kevésbé, öröm az ürömben hibátlanul működik a failsafe elképzelés. Rögtön feltűnt, hogy nincs zárt eszközmeghajtó telepítve. Synaptics meg is mondta, hogy miért: Valami miatt a régi kernel-hez való restricted csomag volt csak feltéve. Feltettem, észlelte az nvidia drivert, telepítette a megfelelő csomagot, és újraindítás után már a rendes felbontás fogadott.
Thunderbird binárisa változott gutsy-ban, így a panelra kitett ikont cserélni kellett.
Más probléma nem volt, de holnap azért nyúzom kicsit a rendszert.
Tetszenek a grafikai változások, tetszik hogy lényegében pöccre megy a VPS (ki van kapcsolva de azért mégis, megnézem má’) és teljesen szolíd, tetszik a fsck amit fentebb említettem.
Igaz nem volt elvárás, hogy a két verzió között pöccre menjen minden de azért kíváncsi vagyok, hogy két LTS közötti frissítés hogyan zajlik. Főleg egy nagyon használt rendszeren.
Folyt. köv. Következik a feisty => hardy kiszolgáló frissítés: vserverben és sima rendszeren éles környezetben. Remélem szolidabb lesz az élménybeszámoló.
A laptopom frissítésén meg még dolgozni kell mert jelenleg 300 mega üres hely van pedig 1 giga kéne… 😮
ftpd tls/ssl
Ha az ftp kiszolgálón beállítjuk, hogy tls/ssl-t szeretnénk használni titkosítás gyanánt a kapcsolat viselkedése megváltozik, olyan mintha passzív lenne. Két passzív kapcsolat meg nem tud egymással kommunikálni. Ezért ilyenkor mindenképpen be kell állítani a passzív porttartományt a kiszolgálónál (passive portrange). Persze ne felejtsük el a kiszolgáló tűzfalán engedélyezni a tartományt.
vserver kernel patch
Feltöltötem egy korábban készített vserver kernel patch-et amit a feisty kernelhez igazítottam. Debet nem sikerült készíteni belőle (kernel deb készítés kicsit magas nekem).
Samba mint tartományvezérlő
Elkezdtem az ígért dokumentum összeállítását. A dokumentum itt olvasható [draft]. Még nem befejezett, folytatása/bővítése várható.
Samba PDC
Több hetes szívás után végre sikerült teszt környezetben samba alapú elsődleges tartományvezérlőt felállítani. A helyzetet nehezítette, hogy annak előtte soha nem használtam LDAP-ot és az jelszóadatbázisnak vagy ldap vagy mysql alapúnak kellett lennie, és neten fellelhető 4-5 dokumentációból kellett összevadászni az informácót. Hogy a feltörekvő nemzedéknek ne legyen ezzel a jövőben gondja hamarosan publikálok egy részletes telepítési és beállítási útmutatást (viszont kimondhatatlan mámoros érzés több hetes szívás után hogy bejelentkezik a tartományba… :D).
Most jöhet a Novell NetWare migrálása.
Hírek az ubuntu háza tájáról
Néhány dolog ami mostantában történt:
- Másfél nap hackolás után sikerült magyar nyelvű dokumentációt készíteni. Ez a rész mindig is problémás pont volt az ubuntu-doksi csapat számára hiszen a nagy erőfeszítéssel lefordított dapper dokumentáció is valamikor fél évvel utána készült csak el… Ráadásul a lp robotnak hála a doksi buildet kiegészítettem egy rosettából exportálással is, így mindig az aktuális állapotot fogom tudni elkészíteni (gyorsabb hibajavítás, mindig aktuális doksi stb). Hamarosan átvariálom a template-t (xsl) és igazítom az ubuntu arculatához.*
- Ma frissítettem a robotot a 0.02a verzióra. Változások: get_packages metódust felváltotta a get_translations metódus. Utóbbi kezeli a lapozót és valamivel szebb a kódja mint az előzőek (getelementsbytagname-re épít, így hibatűrőbb), implementáltam a mailbox figyelést, így most már szabadon lehet exportálni bármit a rosettából, get_new_uploads metódus a csomag feltöltéseket hivatott leszedni és megjeleníteni**. A friss változat letölthető az előző linkről.
- Ez ugyan, nem szervesen ubuntu téma de azért megemlítem: újra lesz szoftverhonosító hétvége, melynek programja a gnome user guide fordítása lesz. Ez két dologban érint engem: 1, megyek 2, valahogy ötvözni kell a régi, András által lefordított doksit a jelenlegivel és csomagot kell tudni készíteni belőle. Gábor kapcsolódó bejelentései első és végleges.
- Gábor utánajárása és rugdosása hatására végre magyar a magyar mirror (http://hu.archive.ubuntu.com) . Köszönet érte az fsn-nek!
- Lesz ubuntu póló, amit a polo kukac ubuntu pont hu címen lehet rendelni! Részletek: http://ubuntu.hu/polo
Egyenlőre ennyi.
* a következő amiben meg fogom kerülni az eredeti ubuntu kiadást az a ddtp lesz. Ott is valami elképesztő nagy töketlenkedés van. Aztán a deb csomagok majd a világuralom következik 🙂
** ezt egy következő elég izgalmas munkámhoz kellett elkészíteni. Részletek hamarosan!
Deb alapú disztribúció telepítése menet közben
Korábban okozott hatalmas fejtörést, hogy hogyan lehetne migrálni egy szervert sarge-ről edgy-re úgy, hogy a kiesés időtartama a lehető legkevesebb legyen. Soha nem gondoltam volna, hogy egy olyan programot kell erre használni aminek a neve eddig is ismert volt számomra, csak eddig nem használtam. A program neve debootstrap, és nagyjából ez a telepítés folyamata:
- új merevlemez be a gépbe
- szükséges, partíciók és fájlrendszer kialakítása, majd azok mountolás /target mappába
- debootstrap edgy /target http://archive.ubuntu.com/ubuntu/ –include=egyénileg szükséges csomagok listája (apache, php, mysql, bind…)
- sikeres telepítés, kézi finomhangolás elvégzése után betöltési sorrend megváltoztatásával újraindítás
S kész is az új rendszer. Ha ügyesek voltunk akkor a szolgáltatás kiesés 2 újraindulásnyi idő volt.
amavis testreszabás
Az új amavissal mostanában elég sokat szívok, ezért egy két dolgot leírok, elkerülendő másoknak a meglepetéseket. Continue reading
apache 1.3 és 2, php 4 és 5 egy szerveren
Adott a feladat: egy szerveren belül szeretnénk futtatni olyan oldalakat, amik php4-et és php5-t használnak. A feladat már korábban sem jelentett gondot, abban az esetben, ha az egyiket modulként, a másikat cgi-ként telepítettük. Ez esetben, akár egy vhost-on belül más kiterjesztéssel is működhetett a megoldás (.php és .php5). Ha nem igény az, hogy egy vhoston belül használnánk mind a kettő verziót, akkor egy másik megoldást is használhatunk, ami az oldalak proxyzásán alapul. Ezzel a megoldással fájdalommentesen migrálhatnuk -a szolgáltatás szüneteltetése nélkül is akár- apache 1.3 php4-ről apache2 php5-re. Az elv a következő:
Tegyük fel, hogy régi jól beállított rendszerünk apache 1.3 és php4. E mellé szeretnénk beüzemelni az apache2 és php5-ös párost. Az libapache2-mod-php5 és az apache2 csomagok telepítésével, feltesszük az apache2-t és a php5-t. Telepítés után az apache2 nem fog elindulni és az /etc/init.d/apache2 start parancs se fogja indítani. Ez azért van mert az /etc/default/apache2 fájlban egy az indítást gátoló opció van. Miután áttettük az apache2-t a például a 8080-as portra, már elindíthatjuk nyugodt szívvel az opció megváltoztatásával és az /etc/init.d/apache2 start parancs kiadásával.
Ezek után az apache-ban arra a hosztra, amin szeretnénk php5-t látni, beállítjuk az apache-ot, hogy proxy-zza tovább a beérkező kéréseket a 8080-as portra. Az apache2-ben pediglen beállítjuk, hogy szolgálja ki a 8080-as porton az kért oldalt. Ha nem szeretnénk, hogy közvetlenül meghívják a 8080-as porton lévő oldalakat akkor a kívülről érkező kéréseket a tűzfal beállításban blokkolhatjuk (alapból tíltó tűzfal esetén ez nem jelent gondot ha korábban nem engedélyeztük). A megoldás ezzel készen is van, és az apache-ok újratöltésével beizzítottuk a rendszert.
Hátránya annyi csupán, hogy egy hoszton belül nem lehet futtatni a két féle php verziót (talán rewrite-al meg lehetne oldani?!). És persze a proxy-zás miatt lassulás is bekövetkezhet, a kiszolgálás sebességében. Persze mérni még nem mértem a megoldást így nem tudom hogy mennyivel lassabb a kiszolgálás sebessége.
Következő érdekes migrációs kérdés lehet még a mysql 4.0-ról mysql 5.0-re és windowsról linuxra :). Ez utóbbival hamarosan részletesen is fogok foglalkozni, hiszen most éppen egy irodai gép migrációjával foglalkozom.
Ubuntu dapper => edgy frissítés szerveren
Épp az imént frissítettem egy dapper szervert edgy-re.
A frissítés minden probléma nélkül zajlott úgy ahogy az ubuntu nagykönyvben meg van írva. Miután átírtam a /etc/apt/sources.list -et, következő parancsokat kiadva:
apt-get update
apt-get dist-upgrade
apt-get dist-upgrade
… már kész is volt a friss edgy rendszer. A dist-upgrade-t azért kellett kiadni kétszer, mert csak a másodikra telepítette fel az upstart -ot.
Szóval fájdalommentesen elvégezhető a frissítés. Most már csak azt kéne valahogy kitalálni hogy hogyan lehet on-the-fly éles debiant frissíteni ubuntu-ra… 🙂
Ez lesz a következő probléma. Egy-két ötletem van, de azokról majd akkor, ha odajutottam!