Jednoduchá HA-proxy na Linuxu

9.12.2007 01:55 | Přečteno: 2412× | Linux | | poslední úprava: 9.12.2007 01:55

Zdravim všechny tučňáky.

Teď jsem v pátek udělal jednu srandičku, nic extra super, ale vypadá to, že by to snad i mohlo fungovat a zároveň je to trapně jednoduchý. Možná už někdo něco podobného řešil a vyřešil to líp, efektnějc, nebo možná i stejně, ale já prostě to řešení nenašel, tak jsem udělal vlastní. No a aby nezapadlo v zapomění a případně, abyste ho mohli taky použít, tak ho hodim sem do blogu. Zaměřením se sem hodí, licenci dávam GPL, takže to celé klidně kopírujte dál, třeba do blogu na root. A teď už hurá do toho, bude se jednat o jednoduchou HA-Proxy.

Máme v práci dva LDAP servery, který používáme na autentizaci uživatelů, a v některých případech i na autorizaci. Pokud by byl zájem, může hodit i jednoduchej návod na rozchození LDAP autentizace a autorizace pro přihlašování na Linux, sudo a ssh-ldap. Některý systémy umožňujou v konfiguraci zadat více LDAP serverů, takže by v případě výpadku jednoho měly použít druhý server, toto podporuje např. Apache2 autentizační a autorizační modul authnz_ldap, libnss_ldap a libpam_ldap a také sudo-ldap a SSHPublicKey patch pro openssh. Bohužel např.SSL-Explorer, JIRA nebo Sun Java Identity Manager neumožňují zadat více LDAP serverů pro jeden zdroj uživatelů (samozřejmě mě můžete v diskuzi opravit, pokud se pletu, ale já to opravdu nastavit nedokázal). No a co teď? Když padne jeden LDAP (nebo bude třeba dole z nějakého důvodu), tak je dobrý, aby i tyhle systémy měly přístup k LDAP datům. Co z toho plyne? Potřebuju HA (High-Availability) řešení. Nebo něco tomu podobný.

Samozřejmě tady zmínim řešení za použití Heartbeat (http://www.linux-ha.org/) a jedné IP adresy sdílené mezi oběma servery. Ale máme pro oba servery jména ldap01 a ldap02, podle toho taky certifikáty a jak jsem psal, některé služby si umí sami najít běžící server. LDAP servery jsou navíc Sun Directory a když jsme certifikáty generovali, tak je systém generoval sám. Nejsem si teď jistej, jestli Sun DS umožňuje vložit vlastní klíč a certifikát, takže nebudu trvat na tom, že to nejde.

Takže jsem přemýšlel, co vlastně potřebuju. Chtělo by to jeden server s obecným jménem, třeba ldap.domena, na který by se klient připojil jako na standardní službu. Tam by ale běžel nějaký démon, který by dotazy předával dál, po nalezení běžícího serveru.

Nejde teda použít jednoduše iptables a DNAT+SNAT, protože ty se neumějí rozhodovat a neumějí testovat, jestli běží nějaká služba na jiném serveru (nebo o tom aspoň nevim). Asi by se to dalo řešit skriptem v cronu, kterej by kontroloval běžící službu na zadaných serverech a podle stavu by upravoval netfilter pravidla. Ale cron se spouští každou minutu, což může být pro někoho dlouhá doba. Chce to tedy skript, který při žádosti o spojení zkontroluje servery a spojí klienta s běžící službou. Další nevýhoda obyčejnýho DNAT+SNAT se skrývá při použítí SSL spojení - pokud by se na klientovi ověřoval certifikát serveru, bude pro host ldap.domena hlásit buď ldap01.domena nebo ldap02.domena (jak jsem psal, certifikáty jsou různé). Takže pro SSL spojení by se mělo spojení ukončovat na proxy serveru a navazovat nové z proxy serveru na cílový server. Bohužel pro TLS spojení bude klient pořád hlásit nesrovnalosti se jménem, protože TLS se bude dešifrovat až na cílovým serveru, takže by na proxy serveru musela bežet skutečná aplikační proxy. Naštěstí všechny služby s jedním LDAP serverem v konfiguraci podporují volbu SSL na portu 636, takže tenhle nedostatek zatím nevadí. Až to bude akutní, začnu to řešit, ale pokud má nějaká služba TLS, tak má většinou i SSL.

A teď už k řešení. V pátek ráno, když jsem šel z koupelny, mě napadlo, že by řešení takovýhle proxy mohlo spočívat ve správné kombinaci programů xinetd, stunnel, nc (netcat), openssl (s_client) a nějakého programu. Myšlenka je následující:

V případě nešifrovaného spojení klient-proxy-server je postup:

• klient se připojí na xinetd (za domácí úkol si z manu nastudujte, k čemu xinetd je, pokud to ještě nevíte)
• xinetd spustí NĚJAKÝ SKRIPT/C PROGRAM/(dosaď oblíbený), který najde aktivní server a službu a spustí nc (netcat) na vybranou adresu a port (opět nastudujte z manu, k čemu je nc)

V případě šifrovaného spojení klient-proxy-server je postup o jeden krok složitější:

• klient se připojí na stunnel (domácí úkol man stunnel), který dekóduje komunikaci a předá jí na xinetd
• xinetd opět spustí NĚJAKÝ SKRIPT/C PROGRAM/(dosaď oblíbený), který najde aktivní server a službu a spustí openssl s_client na vybranou adresu a port (opět nastudujte z manu, jak funguje openssl s_client)

Oba způsoby jsem graficky popsal v přiloženém obrázku. Jak je vidět, je možné udělat kromě kompletně šifrovaných spojení i spojení šifrované jenom z půlky, buď klient-proxy-SSL a proxy-server-PLAIN, nebo klient-proxy-PLAIN a proxy-server-SSL. Záleží na skutečných potřebách.

Nastevení xinetd a stunnel je celkem v pohodě, takže zbývá ten skriptík na vyhledání běžící služby. Zneužil jsem Nagios Pluginy, který obsahujou taky prográmeček check_tcp - jednoduchej, ale účinej. Pokud neznáte, tak krátký popis.

Program check_tcp se pokusí navázat komunikaci na zadaný host a port a když se spojení podaří, tak vrátí exit 0 (což v bashi znamená TRUE). V opačném případě vrací nenulovou hodnotu, podle typu chyby (není to teď důležité, ale pro úplnost-Nagiosovský testovací skriptíky rozlišujou návratové hodnoty 0=OK, 1=WARNING, 2=CRITICAL a 3=UNKNOWN). Pro mě je teď důležitý pouze 0=OK, ne0=ERR.

Skriptík teda otestuje zadaný služby na zadaných serverech a první funkční použije. Tady je vidět, že skriptík může dělat i jinou činnost, např. nějaký specifický výběr, třeba podle času, nebo nějaký load-balancer.

Tak teorii máme za sebou a teď hurá do praxe. V práci používáme Debian stable, takže návod bude pro něj. Pokud se vám tohle řešení líbí a jste linux admini, tak pro vás nebude problém si to přiohnout pro svojí distribuci, nehledě na to, že tohle řešení využívá pouze standardní balíky a tyhle programy existujou snad ve všech distribucích.

Na Debianu Etch budete potřebovat následujicí programy:

• xinetd
• stunnel4
• netcat (na jiných distrech to může být pouze nc)
• openssl
• nagios-plugins-basic (stačí check_tcp; případně jiné, pokud byste chtěli testovací skriptík vylepšit)

Jako příklad uvedu konfiguraci pro LDAP a LDAPS, který jsem potřeboval.

Pro LDAPS jsem připravil klíč a certifikát pouze self-signed, ale nahradíme samozřejmě nějakým podepsaným autoritou, aby to nebuzerovalo s neplatným certifikátem.

openssl req -nodes -new -subj /commonName=ldap.domena -keyout /etc/stunnel/ldap.domena.key -x509 -out /etc/stunnel/ldap.domena.cert -days 3650

Dále nakonfiguruju stunnel4, aby poslouchal na portu 636 (ldaps) a předával komunikaci na 127.0.0.1:390, kde bude poslouchat xinetd.

Soubor /etc/stunnel/stunnel-ldaps.conf bude tedy obsahovat (je to pouze základní konfigurace, takže můžete případně "vylepšovat"):

cert = /etc/stunnel/ldap-server.cert
key = /etc/stunnel/ldap-server.key
sslVersion = all
chroot = /var/lib/stunnel4/
setuid = stunnel4
setgid = stunnel4
pid = /stunnel4-ldaps.pid
socket = l:TCP_NODELAY=1
socket = r:TCP_NODELAY=1
verify = 0
debug = 1
client = no
[ldaps]
accept  = 636
connect = 127.0.0.1:390

Xinetd bude poslouchat jednak na nešifrovaném portu 389, a také na portu 390 pouze na adrese 127.0.0.1, na který půjde rozšifrovaný provoz stunnelem z původního portu 636. Oba dva budou spouštět jako server skript ha-proxy s příslušnýma parametrama.

Do souboru /etc/xinetd.d/ldap jsem uložil:

service ldap
{
  server = /usr/local/bin/ha-proxy
  server_args = ldap ldap-server-01.dom 389 ldap-server-02.dom 389 ldap-server-03.dom 389
  port = 389
  log_type = SYSLOG daemon
  log_on_success = HOST DURATION
  log_on_failure = HOST ATTEMPT
  disable = no
  socket_type = stream
  wait = no
  protocol = tcp
  user = nobody
  group = nogroup
}

service ldapsclient
{
  type = UNLISTED
  server = /usr/local/bin/ha-proxy
  server_args = ldaps ldap-server-01.dom 636 ldap-server-02.dom 636 ldap-server-03.dom 636
  only_from = 127.0.0.1
  bind = 127.0.0.1
  port = 390
  log_type = SYSLOG daemon
  log_on_success = HOST DURATION
  log_on_failure = HOST ATTEMPT
  disable = no
  socket_type = stream
  wait = no
  protocol = tcp
  user = nobody
  group = nogroup
}

No a poslední věc je skriptík ha-proxy. Já jsem ho napsal v bashi, neni to určitě super výkonej program, takže nasazení na opravdu HA serverech bych rozhodně nedoporučoval. V mém případě potřebuju zajistit pouze živé spojení na jeden ze dvou serverů, když nějaký systém neumožňuje zadat dva LDAP servery, takže reakce 1-3 sekundy mě netrápí.

Soubor /usr/local/bin/ha-proxy teda obsahuje:

#!/bin/bash
exec 2>/dev/null
if [ $# -gt 0 ];then
  service="$1"
  shift
  host=""
  port=""
  while [ $# -gt 1 ];do
    host="$1"
    port="$2"
    shift 2
    if /usr/lib/nagios/plugins/check_tcp -H "$host" -p "$port" -t 2 >/dev/null ;then break;fi
    /usr/bin/logger "Service $host:$port dead" >/dev/null
    host=""
    port=""
  done
  if [ -n "$service" ] && [ -n "$host" ] && [ -n "$port" ];then
    /usr/bin/logger "Using service $service at $host:$port" >/dev/null
    case "$service" in
      "ldap" ) exec /bin/nc -w 10 "$host" "$port" ;;
      "ldaps" ) exec /usr/bin/openssl s_client -quiet -connect "$host":"$port" 2>/dev/null ;;
    esac
	else
		/usr/bin/logger "No service specified or no active service on all hosts" >/dev/null
  fi
else
	/usr/bin/logger "No parameters" >/dev/null
fi

Kdo umí bash, tak asi všechno chápe, ale pro jistotu a pro ostatní, aby z toho taky něco měli, trošku to důležité ve skriptíku popíšu v bodech:

přesměruje se STDERR do /dev/null, jinak to xinetdu vadí
pokud nejsou parametry, nic se nedělá, pouze hláška do logu
první parametr se očekává název služby, prakticky ale v mém skriptu stačí označit PLAIN a SSL komunikaci, ale třeba se hodí mít tam název služby, ale je to na vás
dále se očekávají parametry HOST a PORT
nalezený HOST a PORT se otestuje pomocí check_tcp pluginu. Můžete si samozřejmě napsat vlastní testovač, případne můžete IP a PORT aktivního serveru nastavit cronem nebo jiným procesem do nějakýho souboru a pak ho tady jenom načítat
pokud byla nalezena aktivní služba na testovaném serveru, tak se cyklus hledání přeruší a v proměnných zůstanou správné hodnoty. Pokud se aktivní služba nenajde, nastaví se prázdné hodnoty.
když cyklus hledání skončí a nenajde se žadná aktivní služba, skript zaloguje chybu a skončí
jestli se ale najde nějaká běžící služba, skript spustí příslušný program, netcat pro nešifrované spojení a openssl s_client pro šifrované spojení, a předá mu řízení včetně STDIN a STDOUT, přes který pak komunikuje s xinetd

Pro každou službu můžete použít vlastní "ha-proxy skript" zadáním příslužného programu do xinetd.d souboru (parameter server).

Teď už by mělo stačit případně upravit parametry v xinetd.d konfiguráku v server_args (služby, server hosty a porty), upravit ha-proxy skript (servery), nastartovat stunnel a xinetd a proxy by měla fungovat.

Tuhle konfiguraci jsem ověřil a pro PLAIN a SSL spojení funguje naprosto perfektně (no, možná ne v nějakých specifických situacích), pro TLS spojení v PLAIN spojení mi klient hlasí různé jméno serveru a jméno serveru v certifikátu, což se sice dá ignorovat, ale nevypadá to dobře, stejně jako self-signed certifikát. Možná na něco přijdu, jak by se dalo takhle provozovat i TLS spojení, možná na něco přijdete sami, tak to sem dyžtak hoďte.

Předem vám děkuju, že mě nebudete chytat za slova, když jsem se někdy vyjádřil třeba trochu nepřesně, špatné informace samozřejmě opravte. Pokud něco nechápete nebo by bylo potřeba dovysvětlit, tak napište a já to doupravím, ale snad je to dostatečně rozebraný.

       

Obrázky

Komentáře

[e]

A co když Ti padne ta proxy? Podle mne budeš ještě víc v háji než když Ti padne jeden z těch LDAPů, protože část služeb umožňuje zadat oba LDAPy. Nebo i tohle máš nějak vyřešené?

[RoboShim]

A co když Ti padne ta proxy?

Ano, i to je mozne, ale tahle proxy bezi jako virtualizovanej stroj, takze kdyz padne celej server, tak se proxy spusti na zaloznim. Ale nahodit IPcko a tyhle dve sluzby pomoci heartbeat nebo spustit tenhle virtualni stroj na jinym serveru pomoci heartbeat, uz zas takovej problem nebude. Prepinat IPcka a spoustet pomoci heartbeat Sun DS bych moc nechtel.

Podle mne budeš ještě víc v háji než když Ti padne jeden z těch LDAPů, protože část služeb umožňuje zadat oba LDAPy. Nebo i tohle máš nějak vyřešené?

Ted nechapu, na co se presne ptas.

Je to tak, ze nektery sluzby umoznujou zadat dva nebo vice LDAP serveru. Jak jsem psal treba apache2 authnz_ldap, libnss-ldap, libpam-ldap. Predpokladam, a u libnss-ldap a libpam-ldap jsem to uz i zkousel, ze kdyz se v zadanym case nepodari spojeni na jeden LDAP server, tak se vyzkousi ten druhy.

Pokud myslis, ze budu u tohohle reseni v haji, kdyz mi padne jeden LDAP server, tak to si ja nemyslim. Aspon jsem zkousel zadat jako prvni parametry nejake servery, ktere LDAP nemaji (simulace nefunkcni sluzby), a presto se muj ldapsearch na tu proxy dockal vysledku. Takze kdyz jeden server vypadne, tak se ta proxyna spoji na jinej server.

Nebo jsi mel na mysli jeste jinej pripad?

[e]

Podle mne budeš ještě víc v háji než když Ti padne jeden z těch LDAPů, protože část služeb umožňuje zadat oba LDAPy. Nebo i tohle máš nějak vyřešené?

Ted nechapu, na co se presne ptas.

Tady jsem jen chtěl napsat, že když Ti u té proxy spadne ta proxy, tak je to horší než když Ti u řešení bez proxy spadne jeden z těch LDAPů, protože aspoň nějaké služby Ti pojedou.

[RoboShim]

Tady jsem jen chtěl napsat, že když Ti u té proxy spadne ta proxy, tak je to horší než když Ti u řešení bez proxy spadne jeden z těch LDAPů, protože aspoň nějaké služby Ti pojedou.

No, tak snad jsem spravne pochopil, co mas mysli. Myslis, ze pojedu vsechny sluzby pres tu proxy? Ale tak ja to samozrejme nemyslim. Systemy, ktere umoznujou konfiguraci s vice LDAP serverama, samozrejme budou mit oba LDAP servery zadany, cili takovy systemy pojedou primo na oba servery bez proxy a predpokladam, ze si pripadny vypadek jednoho (hlavniho) LDAP serveru vyresi sami. Cili, cinnost proxy neovlivnuje funkci systemu s konfiguraci obou LDAP serveru.

Tuhle proxy protrebuju jenom pro ty systemy, ktery umoznujou zadani pouze jednoho jedineho LDAP serveru. Pokud bych zadal jenom jeden server a ten pak lehnul, budu muset prekonfigurovat X systemu, coz muze jednak trvat a pak nektery sluzby se musi po rekonfiguraci restartovat, a SSL-Explorer se dokonce musi zastavit, spustit install mod a pak zase nastartovat. A protoze je SSL-Explorer tomcat aplikace, tak zastaveni a startovani bere asi tak 30 sekund az minutu a je to docela neprijemna zalezitost.

Takhle budu mit jednu adresu na proxy. Pokud padne hlavni server, mela by proxy zacit prepojovat na zalozni server. A pokud padne proxy, muzu ji zatim rucne nahodit na zaloznim XEN serveru (pripadne bude i jednoduche tu proxy pripadne rozchodit kdekoliv jinde, diky tomu, ze je tak jednoducha a navod mam uz ve wiki) a pozdeji muzu zaprahnout heartbeat na X serveru a pri vypadku hlavni proxy se muze jakykoliv jiny server (diky jednoduchosti) stat nahradnim proxy serverem. A je urcite jednodussi resit konfiguraci na jednom serveru, nez resit zmeny konfiguraci na nekolika ruznych serverech s ruznyma typama konfiguraci.

Ted me napadla jeste dalsi myslenka: tech proxyn by mohlo byt vic a nejaky skriptik (nebo primo heartbeat) by mohl monitorovat jejich stav a pri vypadku hlavni proxy by zmenil pouze DNS zaznam na druhou proxy nebo by na prislusne dalsi zalozni proxy aktivoval to IPcko. Tech reseni je samozrejme vic, vzdycky bude nejake misto k vypadku, ale timhle minimalizuju pocet tech mist a tim zkracuju dobu pro opravu a snizuju slozitost opravy.

[RoboShim]

JA RAD PORADM KDYZ VIM vic (hebmilo.cz)

Uch, ale tohle je drsny!!!

[cenda]

JJ, taky jsem se smál jako blázen

[Jakub Suchy]

A pritom stacilo nainstalovat Piranha

[RoboShim]

Urcite mi stacilo nainstalovat program ABC nebo XYZ

BTW: napis URL, google na "piranha" zacina od ryb, nasel jsem sice neco na redhatu, pak taky odkaz http://sourceware.org/piranha/, ale netusim, jestli myslis tohle. Jak jsem psal, nechtel jsem nic slozite konfigurovat ani instalovat, tohle bylo otazkou par minut+otestovani a je to univerzalni.

[Jan Kurik]

Spise byla na mysli cast, ktere se rika IPVS. Nyni je to jiz standardni soucasti kernelu, takze podobne veci se daji resit pouze konfiguraci NetFilteru (IP Tables).

[RoboShim]

A vida, IPVS. Urcite si to budu pamatovat a pokud budu potrebovat, tak pouziju.

Pokud jsem ale dobre cetl, tak se dela pouze redirect. To by v pripade LDAP stacilo, ale LDAPS by mel problem, protoze oba LDAP servery maji pro SSL komunikaci ruzne certifikaty, takze by to hlasilo problemy a ja potreboval neco spis mit v zaloze (zatim mam sluzby na jeden z hlavnich serveru, ale prekonfiguruju to).

Ale diky za info, bude se to hodit.

[zde]

A proc jednoduse neudelas na kazdem hostu RO repliku? Pak muze popadat vsechno, a loginy budou behat furt...

A stejne, k cemu je ten Ldap jako je? Rsync v cronu je jednodussi, efektivnejsi, a hlavne mnohem robustnejsi- nemusis se starat o bootstrap, synchronizaci, rejecty a podobne zhuverilosti.

[RoboShim]

A proc jednoduse neudelas na kazdem hostu RO repliku? Pak muze popadat vsechno, a loginy budou behat furt...

Jo, tohle je taky mozny reseni, ale chtelo by se ti to spravovat? Me moc ne - staci dva servery v interni siti a dva v DMZ. Navic instalovat dasli Sun-DS jenom kvuli RO replice se mi nechce, a nevim, jak by se Sun-DS romluvil s openldapem na tej replice (mozna by to chodilo). Ale proste instalovat na kazdej takovej server dalsi RO repliku se mi nechce, nehlede na to, ze uz to takhle mame na Jabber serveru a obcas replikace neprobehne a musi se to opravit - a neustale kontrolovat, jestli na vsech tech serverech probehla spravne replikace, to se mi taky fakt nechce.

A stejne, k cemu je ten Ldap jako je? Rsync v cronu je jednodussi, efektivnejsi, a hlavne mnohem robustnejsi- nemusis se starat o bootstrap, synchronizaci, rejecty a podobne zhuverilosti.

No, mame LDAP server s uzivatelema a vetsina sluzeb podporuje LDAP autentizaci a nektery i LDAP autorizaci. Takze na LDAP stromu zadam uzivatele, zadam skupiny a pak jednoduse spravuju vsechno v LDAPu.

Nechapu, co bys delal tim rsyncem, dyztak se rozepis, protoze nechapu ani na sprave uzivatelu a skupin a autentizaci nic s bootstrapem, rejectama a nejakyma zhuverilostma.

[zde]

nevim, jak by se Sun-DS romluvil s openldapem na tej replice (mozna by to chodilo)

Domluvili by se- o tom přece LDAP je, že protokol a syntaxe každého bajtu na drátě je striktně specifikovaná. Jiná věc je že openldap je zavšivenej feature bloatem, nestabilní, a dosti padavej.

Nechapu, co bys delal tim rsyncem, dyztak se rozepis, protoze

No podle toho k čemu ten LDAP používáte. Jestli je to pro místní loginy, tak nevím proč by nemohlo stačit synchronizování /etc/{passwd,group,shadow,gshadow}, buď po každé změně, nebo v pravidelných intervalech. Pokud je to něco většího, tak jde na straně zdroje dat (nějaký DBMS) pravidelně generovat nějakou file-based databázi (GDBM, BDB, CDB..), tu rsync-nout kam je potřeba, a daemonu poslat SIGHUP, aby si otevřel nový soubor.

nechapu ani na sprave uzivatelu a skupin a autentizaci nic s bootstrapem, rejectama a nejakyma zhuverilostma.

Možná že Sun-DS je na správu lepší než openldap a tyhle problémy odpadají, ale s openldapem bylo vždycky moc a moc problémů. Třeba přidání repliky je dost problém. Shodit master, udělat slapcat, zkopírovat LDIF na repliku, tam slapadd-em naplnit databázi, a znovu všechno spustit může pro větší DB trvat klidně několik hodin, a tak dlouhý výpadek si nemůžeš dovolit, takže inicializaci repliky je třeba dělat za provozu, takže updaty se na ně mohou dostat víckrát (naštěstí jsou v LDAPu modifikace nezávislé na počtu jejich přehrání), a na masteru se objeví rejecty, které je třeba ručně zkontrolovat jestli je to důsledek duplikace, nebo známka poškození databáze.. tohle jsem měl na mysli. Tohle všechno při rsyncu odpadá.

[RoboShim]

nevim, jak by se Sun-DS romluvil s openldapem na tej replice (mozna by to chodilo)

Domluvili by se- o tom přece LDAP je, že protokol a syntaxe každého bajtu na drátě je striktně specifikovaná. Jiná věc je že openldap je zavšivenej feature bloatem, nestabilní, a dosti padavej.

Jo, taky doufam. Nicmene se podivej na schema SunDS a OpenLDAPu. Trosku jsem tam koukal a nejaky rozdily tam jsou. Ono by to melo fungovat stejne, ale prece jenom drobny rozdily tam bohuzel jsou.

Nechapu, co bys delal tim rsyncem, dyztak se rozepis, protoze

No podle toho k čemu ten LDAP používáte. Jestli je to pro místní loginy, tak nevím proč by nemohlo stačit synchronizování /etc/{passwd,group,shadow,gshadow}, buď po každé změně, nebo v pravidelných intervalech. Pokud je to něco většího, tak jde na straně zdroje dat (nějaký DBMS) pravidelně generovat nějakou file-based databázi (GDBM, BDB, CDB..), tu rsync-nout kam je potřeba, a daemonu poslat SIGHUP, aby si otevřel nový soubor.

Ano, mam to pro loginy, dale pro SSH klice uzivatelu a sudoers. Nekteri uzivatele jsou pouze inetOrgPerson, protoze nepotrebuji posixAccount. Dale mame skupiny - nektere systemy jsou radsi pro groupOfUniqueNames, nektere (PAM pam_access) mam jako posixGroup. Limituju tim pristup na ssh, sudo, cron, vmware-server-console.

Sice tvuj navrh reseni by taky mozna schudny byl, mozna by bylo lepsi pouzit radsi NIS, ale zda se mi to zbytecne komplikovane. Nahlaseni na jednu masinu, zmena /etc/passwd, group atd OK. Potom spustit nejakej rsync, kterej to bude muset rozkopirovat na 20-30 serveru, netusim, jak bych to kopiroval do systemu, ktery nepodporuje lokalni /etc/passwd, group, napr. JIRA tusim ma bud vlastni DB nebo LDAP. Navic, pokud se na nejakem serveru synchronizace nepodari, mam zadelano na problemy. A pak jeste pripadne delat nejaky restarty, aby ten system vubec zjistil, ze doslo ke zmene uzivatelu. V LDAPu udelam uzivatele a je videt ve vsech systemech, kde ma byt videt. Mam rsync taky rad, ale zrovna v tomhle pripade se mi to zda moc krkolomny.

nechapu ani na sprave uzivatelu a skupin a autentizaci nic s bootstrapem, rejectama a nejakyma zhuverilostma.

Možná že Sun-DS je na správu lepší než openldap a tyhle problémy odpadají, ale s openldapem bylo vždycky moc a moc problémů. Třeba přidání repliky je dost problém. Shodit master, udělat slapcat, zkopírovat LDIF na repliku, tam slapadd-em naplnit databázi, a znovu všechno spustit může pro větší DB trvat klidně několik hodin, a tak dlouhý výpadek si nemůžeš dovolit, takže inicializaci repliky je třeba dělat za provozu, takže updaty se na ně mohou dostat víckrát (naštěstí jsou v LDAPu modifikace nezávislé na počtu jejich přehrání), a na masteru se objeví rejecty, které je třeba ručně zkontrolovat jestli je to důsledek duplikace, nebo známka poškození databáze.. tohle jsem měl na mysli. Tohle všechno při rsyncu odpadá.

Aha. No, mame na Sun-DS master-master replikaci mezi 4 serverama a tam se to nastavuje fakt jednoduse. A snad to i beha stabilne. Druha moznost by samozrejme bylo udelat jenom jeden server master a ostatni pouze read-only kopie (coz by bylo vlastne to reseni s rsyncem), a pri padu master LDAPu prepnout nejakej RO do RW a udelat z nej master s replikaci na dalsi. Ona replikace je obecne dost choulostiva na spravny postup, delal jsem uz replikaci master-master na MySQL a to bylo taky o hubu, kdyz clovek neco spusti ve spatnym poradi. Vyhoda Sun-DS a inicializace replikace je v tom, ze tu inicializaci udelas za provozu, takze zadna odstavka.

Rsyncem resime konfigurace ruznych systemu (squid, bind, dhcp) - po uprave kodu se spusti skript, kterej zkonroluje spravnost configu (napr. squid - k parse) a kdyz je to OK, tak syncne na dalsi servery a reloaduje. Pro squid jsem to udelal oboje master, takze je jedno, kde se cfg zmeni, skript to posle na spravny druhy server.

Jinak jsem uz videl konfigurace DHCP i DNS v LDAPu - nebylo to spatny, akorat pri zmene udaju v LDAPu se musel daemon restartovat - u PowerDNS to byla tusim jenom data, takze tam se reload nedelal, ale u DHCP se musel reload delat.

[RoboShim]

takze jak jsem se obaval, pro LDAP existuje samozrejme uplne to nejjednodussi reseni v podobe slapd-ldap, coz je "LDAP backend to slapd". Funguje to presne tak, jak jsem potreboval:

The LDAP backend to slapd(8) is not an actual database; instead it acts as a proxy to forward incoming requests to another LDAP server.

A samozrejme openldap podporuje vice cilovych serveru, jak je napsano v manu

Multiple URIs can be set in in a single ldapurl argument, resulting in the underlying library automatically call the first server of the list that responds...

Ikdyz ted premyslim, jak to asi bude s autentizaci - zatimco moje reseni predava kompletni komunikaci, tak se bude mozna bind provadet na openldap-proxy a pokud nebude uzivatel, tak selze. Ale to musim jeste otestovat, jak to vlastne funguje.

Nicmene, moje proxy ma vyuziti pro dalsi plain a SSL komunikace (pozor, asi ne TLS!).

A mozna taky slapd-meta pujde na to pouzit, minimalne to ted zneuziju na donuceni Groupwise, aby se autentizoval na LDAP serveru.