Proč jsem si dal tu práci s migrací na Linuxový server (diskuse)

[Heron]

Dobrý zápisek, jen pár poznámek:

Pouze pro Apache jsem musel kompilovat modul pro ověření pomocí Kerberos

Za toto bych každého admina zastřelil. Kompilovat něco na serveru je první schod vedoucí do pekla v podobě zabordelizovaného serveru. Je to často neupdatovatelné (nevím jak v tomto konkrétním případě) - při každém update z balíčků je třeba rekompilovat to co šlo mimo balíček. Často to končí tak, že se neupdatuje vůbec.

Zakoupili jsme server od firmy Dell s předinstalovaným SLES 10. Zde musím bohužel konstatovat, že jsem očekával o něco lépe odladěný produkt.

V týdnu jsem instaloval nějaké servery od HP, zákazník si na jeden nechal nainstalovat Windows Server 2003. Dodavatel serverů (nikoliv přímo HP) tam tedy dal W 2003. Bez driverů, bez updatů. Prostě čistou instalaci. Také jsem očekával o něco lepší výsledek.

[Platonix]

Teď mi poraď, co jsem měl dělat, když jsem potřeboval ten modul pro autentizace via Kerberos a nebyl součástí systému. Taky se snažím používat balíčky, co nejvíc to jde, ale když to nejde, tak jsem to nějak řešit musel. Jaký postup bys navrhnul ty? Trochu mi to přijde, že kritizuješ druhé a sám jsi nic takového neřešil.

[alblaho]

No to by mě taky zajímalo. Je to takové nepříjemné, člověk si platí tohnencto ENTERPRISE distribuci a skončí to tím, že tam něco kompiluje.

Udělat si vlastní balíček a ten si udržovat?-)

[Luk]

Udělat si vlastní balíček a ten si udržovat?-)

Někdy skutečně není jiná možnost (pokud to člověk nechce přímo kompilovat ze zdrojáků). Enterprise distribuce jsou typické tím, že jsou tam osvědčené a odladěné věci, čili něco novějšího tam opravdu nemusí být.

[Luk]

Čisté řešení je vyrobit si balíček a ten nainstalovat. I když se přiznám, že to také nedělám a některé věci mám přímo ze zdrojáků, protože je to pro mě pohodlnější a jednodušší.

[Platonix]

Tím vlastním balíčkem nevyřeším jeho aktializace.

[Luk]

To záleží na distribuci. Pokud je to openSUSE nebo nějaká kompatibilní, lze využít openSUSE Build Service a aktualizovat obvyklým způsobem (možná mají něco podobného i další distribuce, nevím...). Jedinou věcí je, že je potřeba při nové verzi natlačit zdrojáky do služby a spustit generování balíčku. To lze buď udělat ručně (poté, co přijde informace o nové verzi), anebo se dohodnout s tvůrcem programu nebo někým dalším, aby to zajistil.

[Radek Hladik]

Pokud jde o modul do Apache, je mozna mozny postup stahnout adekvatni SRPM a upravit ho tak, aby to prelozilo i ten modul a zaroven zmenit spec file tak, aby se to samo neupdatovalo. Je to sice problematicke a pracne, ale zase system alespon o danem souboru vi, co je zac...

[Platonix]

Není k dispozici ani SRPM balíček.

[Luk]

Pro Apache? To asi těžko, ne?

[Platonix]

Já myslel pro ten konkrétní modul. Apache jsem nekompiloval.

[Radek Hladik]

Pokud se jedna o standardni modul z distribuce apache, tzn. neco, co se zapne pomoci nejake volby pro configure, pak je potreba SRPM balicek pro apache a v jeho SPEC souboru je potreba danou volbu pridat a (bohuzel) pripadne dalsi veci.

Pokud je to ve forme patchu oproti zdrojakum apache, pak je i ten patch mozne pridat do SPEC souboru, ale je to pomerne pracne a muze byt potreba patch upravit tak, aby nekolidoval s distribucnimi patchi.

A finalne, pokud se jedna o modul, ktery se preklada jen oproti apachovi, tak je mozne mu SPEC soubor napsat a udelat si balicek vlastni. Nekdy je SPEC soubor obsazen i v tar.gz verzi zdrojaku, coz docela pomuze, pak je mozno primo z takoveho tar.gz vyrobit RPMko.

Ovsem ve vetsine pripadu se jedna o docela slozitou vec, SPEC soubory nejsou zrovna jednoduchy atd... Docela se mi osvedcilo pouziti checkinstall, ktery se spousti misto make install a udela z toho RPM. Navic misto make install mu muze clovek predhodit cokoliv jinyho, videl jsem uz lidi vyrabet balicky kopirovanim v MC. Vyhoda je, ze z toho vznikne balicek, ktery se da nainstalovat a system alespon soubory z balicku ma ve sve RPM databazi. A pokud je na vice serverech stejny system, pak je mozne balicky pouzit vsude atd... Nejedna se zdaleka o idealni reseni, ale oproti kompilaci ze zdrojaku je to maly rozdil a rozumny prinos

[Michal Kubeček]

Dřív jsem byl také líný dělat si balíčky na věci, které z nějakých důvodů doinstalovávám do distribuce. Ale pak jsem tu lenost jednou překonal a ověřil si správnost svého podezření, že když člověk provede tu vstupní investici (času potřebného k vytvoření balíčku), tak potom už tento postup naopak dost práce ušetří.

[Grunt]

Jak říkám stále dokola. Zdrojáky by se měli stát běžnou součástí balíčkovacích systému tak jako je tomu třeba u Gentoo. Tím by se vše vyřešilo.

[YYY]

+1

[Heron]

Co by se tím vyřešilo?

[Grunt]

Bo min. problémy s aktualizací.

[Heron]

Administrátor serveru si přece nemůže kompilovat software a nějakou dobu jej pořádně testovat. Na to nemá čas. Navíc ten balíček potřebuje hned a než až jej otestuje. Od toho si kupuje distribuci.

[Grunt]

Zkompilovat a pořádně otestovat všechen možný software ve všech možných kombinacích prostě není možné. A kompilace není zas tak strašná. A podle mého názoru by dobrý Administrátor měl mít alespoň základní skilly debugingu, aby byl schopen dobře lokalizovat chybu a korektně ji nahlásit, aby mohla být co nejdříve opravená tím komu zaplatil.

[Grunt]

Teď mi to trklo. Asi si každý představujeme něco jiného pod pojmem zdrojáky by měly být součástí balíčkovacího systému.

[Heron]

Já nevím jak z toho ven. Sám to řešívám také. Někdy se to dá obejít jinak (například instalací z balíčku mimo repositář - což je též automaticky neupdatovatelné), někdy ta funkce není potřeba. Ale já, jako administrátor, vůbec nemám řešit kompilaci software pro server. Od toho tu přece jsou ty enterprise distribuce, aby to tam bylo.

[Luk]

Ale já, jako administrátor, vůbec nemám řešit kompilaci software pro server. Od toho tu přece jsou ty enterprise distribuce, aby to tam bylo.

Někdo to řeší cestou nejmenšího odporu, tedy migrací na Windows, pokud tam ta příslušná funkce je.

[VSi]

Pěkné. Zajímalo by mě, jestli jsou hesla skutečně jenom v Kerberovi (tj. v LDAPu se nepoužívá UserPassword a SambaNTPassowrd)? Předpokládám, že stroje s Windows jsou v Samba doméně, a že uživatel při přihlášení dostane Kerberos ticket, který se dá využít třeba pro ověření dalších služeb (ssh, firefox) - kdyby to takhle fungovalo, tak je to perfektní. Mohl byste se o tom trochu rozepsat? Třeba jak se to nastavuje ve Windows - normální zařazení do domény asi nestačí.

O tomhle se toho dá najít dost málo. Něco vyšlo v seriálu tady na abclinuxu, ale bez návaznosti na Windows v doméně, to mi jako jediná věc chybí.

 

[Platonix]

Bohužel samba verze 3 nepodporuje Kerberos. Druhá verze hesla je uložena v LDAP pro účely SAMBY. Jinak od verze 4 už by to mělo být plně Kerberizované.

[VSi]

Samba 4 - kdo ví, kdy bude stabilní pro takovéhle nasazení...

Neví tedy někdo, jestli jde Windows nastavit tak, aby při přihlášení do Samba3 domény použily to samé heslo pro získání Kerberos ticketu?

Právě tady v seriálu o Kerberu byla funkční konfigurace, kdy lokální účty Windows se ověřovaly proti Kerberos serveru na Linuxu a získaný ticket pak šel použít pro připojení na Sambu v. 3, která Kerberos tedy nějak částečně umí - jak oproti Windows tak s Linux CIFS klientem.

[Platonix]

Samba umí být Kerberizovaná, ale ne v režimu PDC. Windows lze nakonfigurovat, aby ověřovaly uživatele přes Kerberos, ale vždy mapují uživatele na nějakého lokálního. Není možné tedy používat pro kadého uživatele jeho vlastní cestovní profil, který se při přihlášení natahuje ze serveru. Tahle překážka mě od toho docela teda odradila.

[kub.]

Novell teď vydal Open Enterprise server 2 SP1 - což je nadstavba nad SLES 10, obsahuje navíc eDirectory, další novellí služby pro síť a administrační nástroje. Dělá se s tím o něco jednodušeji, než s čistým SLESem. Ale proč o tom píšu - nový service pack obsahuje Domain services for Windows, velmi jednoduše tak může hrát roli Active directory serveru. Možná to někoho kdo také migruje z Windows na Linux bude zajímat...

[Platonix]

YAST ve SLES se taky tvářil, že roli PDC lze zapnout jedním kliknutím. Buhužel to samo o sobě tak hladce nefungovalo.

[kub.]

Čistě ve SLES jsem to nedělal. Jenom v OES.