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

7.2.2009 13:21 | Přečteno: 1999× | Linux | | poslední úprava: 7.2.2009 13:48

Jako správce počítačové sítě jedné menší katedry na UP v Olomouci jsem asi před měsícem migroval ze starého na nový server. Při volbě operačního systému jsem se rozhodnul pro GNU/Linux. Přidal jsem si tím určité množství práce, které bych si ušetřil, pokud bych zůstal věrný platformě MS Windows. Svého rozhodnutí však nelituji a jsem přesvědčen, že se z dlouhodobého pohledu vyplatí. Proč?

Na mé katedře fungoval několik let starý server s MS Windows 2000 Server, který zajišťoval všechny serverové služby: Active Directory na ověření uživatelů, HTTP server, poštovní server (SMTP, POP3, IMAP), sdílení dat pomocí SMB, FTP server a DNS server. Všechny tyto služby bylo třeba zachovat a to nejlépe tak, aby uživatelé nepoznali žádný rozdíl.

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. Při instalaci jsem zápasil s registrací u firmy Novell, abych mohl využívat online aktualizace balíčků. Rozhodl jsem se pro následující konfiguraci, které evidentně není zcela podporována, proto bylo třeba konfiguraci provádět ručně a ne na úrovni jinak velice zdařilého nástroje YAST2: jako úložiště hesel jsem zvolil Kerberos (to kvůli potenciálnímu využití SSO), data uživatelů jsou obsažena v LDAP databázi. Po několika hodinách pokusů a hledání řešení na různých fórech se mi podařilo přimět PAM, aby skutečně uživatele ověřilo, umožnilo mu změnit heslo a také aby se při přihlášení načetla data z LDAP. V openSUSE 11 je takového nastavení otázka několika kliknutí v YASTU. Bohužel SLES 10 je malinko zapeklitější. Alespoň jsem se lépe seználil se strukturou PAM modulů.

Dalším trošku oříškem byla SAMBA. Chvíli trvalo, než se mi podařilo vyladit zařazení pracovních stanic do domény SMABA a také možnost, aby si uživatelé mohli své Kerberos heslo měnit na pracovních stanicích prostřednictvím SAMBY. I když se mi to nakonec povedlo rozchodit, naprogramoval jsem webové rozhraní, které změnu hesla provede přímo voláním příkazu passwd z PHP skriptu.

Zbylé serverové služby byly naprosto bez problému. Pouze pro Apache jsem musel kompilovat modul pro ověření pomocí Kerberos, ale to šla také hladce a z repozitáře openSUSE jsem použil Dovecot jako IMAP server (naprosto bez problémů). Jistě jsem strávil více času konfigurací tohoto serveru, než bych strávil při pouhé migraci řekněme na MS Windows 2003 Server. Kde jsou ty slibované výhody Linuxového řešení?

1. Cena licencí je jistě jednou z výhod zvoleného řešení. Řešení na platformě MS by vyžadovalo nákup licence na operační systém, další licence pro klientské pracovní stanice (neplést s licencí na operační systém pro klienty, MS vyžaduje ještě další licenci, pokud se klient připojuje k serveru neanonymně). Dále by bylo třeba zakoupit emailový server (např. MS Exchange nebo Kerio Mail Server). Emailový server na starém serveru totiž nepodporovat kontrolu na spam. Další peníze by byly utraceny za antivirové řešení s podporou výrobce.

2. Podporované komponenty jako se server Apache nebo pro Linux nativní SSH server nelze na MS Windows nalézt. Jistě lze provozovat Apache i na Windows, ale bez podpory. Existují i komerční implementace SSH, ale to zase navýší cenu licencí. IIS mi oproti Apache nevyhovuje protože nepodporuje například ověření uživatelů proti prostému souboru s hesly. Všechny balíčky, které jsou součástí SLES 10 jsou Novellem přímo podporovány. Open source instalovaný do Windows takovouto podporu nemá (pokud si ji někde nezaplatím).

3. Elegatní správa systému pomocí SSH a příkazové řádky je snad tou největší výhodou Linuxu. Ano, i ve Windows je možné konfigurovat systém pomocí příkazů, ale osobně třeba netuším, jak editovat registry pomocí příkazové řádky. Také si nejsem jist tím, že pomocí příkazové řádky budu schopen konfigurovat emailový server, webový server, DNS server a další doplňující služby. Příkazová řádka je nástrojem velice mocným, který umožňuje snadnou a rychlou konfiguraci a sledování serveru a všech jeho součástí. Starý Windows server bylo třeba konfigurovat připojením ke vzdálené ploše a klikat. Tato operace zabrala obyčejně daleko více času, než prosté přihlášení přes SSH a zadání příkazu na příkazové řádce.

4. Stabilita systému je možná docela subjektivní záležitostí, ale z mých zkušeností plyne, že Linuxové systémy jsou bez údržby schopny běžet daleko déle než systémy s MS Windows. Starý server bylo nutné pravidelně restartovat, jinak se prostě zaseknul. U Linuxových systémů jsou zatím na tuto potřebu nenarazil. Vím, že vysoký uptime je jen pro malé děti, protože kvalifikovaný správce serveru aktualizuje i patche do jádra, aby měl stále bezpečný a co nejlépe vyladěný systém. I tak je ale rozdíl, jestli server vyžaduje neustálou pozornost nebo jestli vám vydrží bez restartu běžet třeba půl roku.

Závěrem bych chtěl shrnout, že migrace z MS Windows na SLES 10 byla časově náročná a vyžadovala hledání informací, kde se dalo. Výše zmíněné výhody Linuxu jsou však ovocem, které za tuto práci nyní sklízím a doufám, že i do budoucna sklízet budu.

       

Komentáře

[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.