Hudební přehrávač Amarok byl vydán v nové major verzi 3.0 postavené na Qt5/KDE Frameworks 5. Předchozí verze 2.9.0 vyšla před 6 lety a byla postavená na Qt4. Portace Amaroku na Qt6/KDE Frameworks 6 by měla začít v následujících měsících.
Byla vydána nová verze 2.45.0 distribuovaného systému správy verzí Git. Přispělo 96 vývojářů, z toho 38 nových. Přehled novinek v příspěvku na blogu GitHubu a v poznámkách k vydání. Vypíchnout lze počáteční podporu repozitářů, ve kterých lze používat SHA-1 i SHA-256.
Před 25 lety, ve čtvrtek 29. dubna 1999, byla spuštěna služba "Úschovna".
Byla vydána nová verze 24.04.28 s kódovým názvem Time After Time svobodného multiplatformního video editoru Shotcut (Wikipedie) a nová verze 7.24.0 souvisejícího frameworku MLT Multimedia Framework. Nejnovější Shotcut je vedle zdrojových kódů k dispozici také ve formátech AppImage, Flatpak a Snap.
Byla vydána verze 5.30 dnes již open source operačního systému RISC OS (Wikipedie).
V aktuálním příspěvku na blogu počítačové hry Factorio (Wikipedie) se vývojář s přezývkou raiguard rozepsal o podpoře Linuxu. Rozebírá problémy a výzvy jako přechod linuxových distribucí z X11 na Wayland, dekorace oken na straně klienta a GNOME, změna velikosti okna ve správci oken Sway, …
Rakudo (Wikipedie), tj. překladač programovacího jazyka Raku (Wikipedie), byl vydán ve verzi #171 (2024.04). Programovací jazyk Raku byl dříve znám pod názvem Perl 6.
Společnost Epic Games vydala verzi 5.4 svého proprietárního multiplatformního herního enginu Unreal Engine (Wikipedie). Podrobný přehled novinek v poznámkách k vydání.
Byl vydán Nextcloud Hub 8. Představení novinek tohoto open source cloudového řešení také na YouTube. Vypíchnout lze Nextcloud AI Assistant 2.0.
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?
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.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.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.
JA RAD PORADM KDYZ VIM vic (hebmilo.cz)Uch, ale tohle je drsny!!!
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.
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.
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz/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á.
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.
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.
Tiskni
Sdílej:
