Chris Kühl (CEO), Christian Brauner (CTO) a Lennart Poettering (Chief Engineer) představili svou společnost Amutable. Má přinést determinismus a ověřitelnou integritu do linuxových systémů.
Byla vydána (𝕏) nová verze 26.1 open source firewallové a routovací platformy OPNsense (Wikipedie). Jedná se o fork pfSense postavený na FreeBSD. Kódový název OPNsense 26.1 je Witty Woodpecker. Přehled novinek v příspěvku na fóru.
Deník TO spustil vlastní zpravodajský webový portál ToHledej.CZ s internetovým vyhledávačem a bezplatnou e-mailovou schránkou. Dle svého tvrzení nabízí 'Zprávy, komentáře, analýzy bez cenzury' a 'Mail bez šmírování a Velkého bratra'. Rozložením a vizuálním stylem se stránky nápadně podobají portálu Seznam.cz a nejspíše je cílem být jeho alternativou. Z podmínek platformy vyplývá, že portál využívá nespecifikovaný internetový vyhledávač třetí strany.
Computer History Museum (Muzeum historie počítačů) zpřístupnilo své sbírky veřejnosti formou online katalogu. Virtuálně si tak můžeme prohlédnout 'rozsáhlou sbírku archivních materiálů, předmětů a historek a seznámit se s vizionáři, inovacemi a neznámými příběhy, které revolučním způsobem změnily náš digitální svět'.
Ruský hacker VIK-on si sestavil vlastní 32GB DDR5 RAM modul z čipů získaných z notebookových 16GB SO-DIMM RAM pamětí. Modul běží na 6400 MT/s a celkové náklady byly přibližně 218 dolarů, což je zhruba třetina současné tržní ceny modulů srovnatelných parametrů.
Národní identitní autorita (NIA), která ovlivňuje přihlašování prostřednictvím NIA ID, MEP, eOP a externích identit (např. BankID), je částečně nedostupná.
Byla vydána nová verze 1.16.0 klienta a serveru VNC (Virtual Network Computing) s názvem TigerVNC (Wikipedie). Z novinek lze vypíchnout nový server w0vncserver pro sdílení Wayland desktopu. Zdrojové kódy jsou k dispozici na GitHubu. Binárky na SourceForge. TigerVNC je fork TightVNC.
Byla vydána nová verze 4.6 (𝕏, Bluesky, Mastodon) multiplatformního open source herního enginu Godot (Wikipedie, GitHub). Přehled novinek i s náhledy v příspěvku na blogu.
Rozsáhlá modernizace hardwarové infrastruktury Základních registrů měla zabránit výpadkům digitálních služeb státu. Dnešnímu výpadku nezabránila.
Čínský startup Kimi představil open-source model umělé inteligence Kimi K2.5. Nová verze pracuje s textem i obrázky a poskytuje 'paradigma samosměřovaného roje agentů' pro rychlejší vykonávání úkolů. Kimi zdůrazňuje vylepšenou schopnost modelu vytvářet zdrojové kódy přímo z přirozeného jazyka. Natrénovaný model je dostupný na Hugging Face, trénovací skripty však ne. Model má 1 T (bilion) parametrů, 32 B (miliard) aktivních.
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:
