Případová studie: Adresářové řešení pro webhosting pomocí ApacheDS Lukáš Jelínek
AIKEN Webhosting primárně pro provoz zakázkových projektů klasická platforma Linux+Apache+PHP+MySQL (LAMP) + databáze SQLite a PostgreSQL + specifické moduly a knihovny (Haru, GnuTLS) e-mail : Postfix + Dovecot + Roundcube
Jaké informace se využívají uživatelé (standardní systémoví) domény (hierarchicky) e-mailová data (schránky, aliasy, seznamy) databáze (aktuálně MySQL, v budoucnu i PostgreSQL) limity (na místo, velikost a počet schránek...) blacklisty a whitelisty (web, pošta, greylisting...)
Adresářové řešení Původní : obyčejné soubory Aktuální : MySQL (dříve s replikací, nyní 2 DB) Na MySQL jsou navázány : Postfix Dovecot NSS generátory konfigurací
Problémy dosavadního řešení replikace MySQL : nespolehlivá, nutné ruční zásahy obtížná škálovatelnost (přidávání serverů) problematická redundance budoucnost MySQL? MariaDB?
Co s tím? Nějak vylepšit MySQL? MySQL Cluster?
Co s tím? Nějak vylepšit MySQL? MySQL Cluster? Něco jiného? Vlastní řešení?
Co s tím? Nějak vylepšit MySQL? MySQL Cluster? Něco jiného? Vlastní řešení? LDAP!!!
Požadavky na LDAP server výkon, robustnost, spolehlivost škálovatelnost snadné zprovoznění a konfigurace multimaster replikace pokud možno nezávislost na distribuci, optimálně na OS
Volba LDAP serveru OpenLDAP přirozený kandidát, dostupnost, obtížné zprovoznění a konfigurace 389 Directory Server kvalitní, chybí distribuční balíčky ApacheDS kvalitní, vyžaduje Javu
ApacheDS klíčové vlastnosti podpora LDAP v3 (certifikace Open Group) vestavěný Kerberos Server, HTTP server podpora password policy multimaster replikace multiplatformní (Java) výkon, robustnost, škálovatelnost součást projektu Apache Directory Apache Directory Studio, Apache LDAP API back-end = JDBM, v budoucnu Mavibot
Architektura řešení s ApacheDS na každém serveru lokální instance multimaster replikace mezi všemi klient se může připojit kamkoli, vždy nejdřív na lokální instanci IMAP replikace LDAP admin LDAP replikace replikace LDAP
Řešení s ApacheDS transformace DB do LDAP využití standardních objektových tříd (organizationalunit, inetorgperson, dnsdomain...) pro různé kategorie informací vytvořeny podstromy dále podrobnější větvení domény hierarchicky, ale dc je celý doménový název
Řešení s ApacheDS administrace GUI prakticky stejné jako dříve založena nově na Nette (dříve holé PHP) pro přístup k LDAP objektová knihovna phpldapobj přístup k DB nahrazen přístupem ke LDAP úskalí : změny stejného objektu na více uzlech před replikací
Řešení s ApacheDS systémoví uživatelé systémový uživatel : použití pro administraci, (S)FTP, běh HTTP serveru (mpm_itk), Subversion over SSH dosud : NSS-MySQL, konfigurace NSS nyní : NSS-LDAP, konfigurace NSS nové schéma hesel : SSHA512, původní hesla nedotčena lze ještě zvýšit výkon : NSCD
Řešení s ApacheDS Postfix, Dovecot využití pro veškerá data související s poštou (schránky, aliasy, blacklisty a whitelisty...) konfigurační soubory jednotlivých aplikací zvýšení výkonu : proxymap (Postfix), prefetch (Dovecot) využívány již u MySQL
Řešení s ApacheDS Apache HTTP server přístup ke chráněným oblastem (HTTP Auth) zcela nové dosud řešeno exportem z MySQL do souboru se jmény a hesly (špatná podpora MySQL) moduly mod_authnz_ldap (autentizace+autorizace), mod_ldap (cachování), mod_alias (více LDAP serverů)
Řešení s ApacheDS generátory konfigurací řada generátorů různých konfigurací (Apache, awstats...) pro případy, kdy nejde pracovat s daty přímo všechno jsou PHP skripty přepsání z přístupu k MySQL na přístup ke LDAP (s využitím phpldapobj) v budoucnu : FUSE implementace (generování až při přístupu přímo ze LDAP)?
Řešení s ApacheDS konverzní skripty data je nutno převést z MySQL do ApacheDS realizováno konverzními skripty v PHP + dibi + phpldapobj lze provádět za provozu, ale nutno zabránit změnám stačí udělat z každé DB do lokálního ApacheDS (replikace vyřeší distribuci všude)
Zkušenosti z implementace a testovacího provozu vlastní implementace bez problémů problémy s porty root nebo běh na neprivilegovaných (úvaha : CAP_NET_BIND_SERVICE jak?) ale nestandardní porty (10389, 10636) plně vyhovují změny v uložení dat mezi verzemi (nutný export/import) spotřeba času CPU i naprázdno celkově v zásadě splňuje očekávání
Aktuální stav a plány běží testovací provoz (virtuální servery) pro přenos na ostré servery vše připraveno migrace bude vyžadovat výluku v řádu hodin po spuštění ostrého provozu : vylepšování ve smyslu zmíněných úvah případný přechod na jiný LDAP server by byl snadný
Odkazy http://directory.apache.org/ http://ldap.zdenda.com/ http://wiki2.dovecot.org/authdatabase/ldap http://www.postfix.org/ldap_readme.html http://httpd.apache.org/docs/2.2/mod/mod_authnz_ldap.html http://php.net/manual/en/book.ldap.php
To je vše! Děkuji za pozornost! Dotazy?