Distribuované verzovací systémy – úvod (2) (diskuse)

[Max]

Pěkný článek, maximální souhlas.
Zdar Max

[Marián Kyral]

K těm Git projektům bych přihodil KDE. Migrace právě probíhá.

[alblaho]

Mě fascinoval subversionový repozitář KDE - vše v jednom. Mám pocit, že to dotáhli snad na miliardu revizí.

Přínos distribuovaných verzovacích systémů je pochopitelně největší pro distribuované projekty. Hlavně jde o to, že není potřeba vymýšlet, kdo dostane právo zápisu a kdo ne. Linus přetahuje stromy od deseti lidí, kterým absolutně věří. A každý s těch deseti má zase svoji skupinu dodavatelů.

[Ladicek]

V ASF jsou na tom podobně. Teda nejsou u miliardy, jenom u miliónu

[Sten]

Kdepak, jenom na něco přes milion. Těžko říct, jestli by SVN miliardu revizí zvládlo. Jinak na git se sice migruje, ale naprostá většina práce se stále děje v SVN.

[Jakub Suchy]

+ Drupal.

Kompletni drupal.org s jadrem a ostatnimi 7500 projekty prechazi na Git.

[pet]

Díky a netrpělivě čekám na pokračování. Budeme přecházet z CVS a CrossVC na něco distribuovaného, předpokládal jsem Git, ale po dnešku je možné, že vyberu ze "svaté trojice" něco jiného s lepším gui

Ještě jednou díky

[Sten]

Přesně tak, mám repozitář v gitu, ale v tomto článku mě více zaujal Bazaar, tak třeba zmigruju.

[pavlix]

Bazaar chce hodně rychlý stroj i na středně velké projekty.

[vencas]

Nevím kdy jste to naposled zkoušel, ale mě funguje bez problémů na starších počítačích (je-li středně velký projekt 100k řádek a 3k revizí). Ve výkonu udělal bazaar hodně velký skok asi před rokem a teď mi přijde skvělý.

[pavlix]

Nevím kdy jste to naposled zkoušel, ale mě funguje bez problémů na starších počítačích (je-li středně velký projekt 100k řádek a 3k revizí). Ve výkonu udělal bazaar hodně velký skok asi před rokem a teď mi přijde skvělý.

Nezkoušel jsem ho několik let, protože už byl Git, takže asi tak. Každopádně díky za informaci.

[mimi.vx]

good clanek , ale jeste mi chybi info o DARCS

[polymorf]

Aky verzovaci system by ste doporucili na usb flash disk? Z dovodu ze nemam/nechcem tieto subory prenasat cez siet. Co som pozeral tak vacsina VCS robi strasne velke mnozstvo suborov, uz sa mi napr. stalo ze sa na usb flash disk nedalo do jedneho adresara dat viac ako 512 suborov. S tym ze by to malo byt multiplatformne (linux, windows).

[Josef Kufner]

Git si dává jen .git do kořene repositáře.

[Gilhad]

ale pod tím .git má spoustu podadresářů a souborů...

Nicméně pokud bych já dával verzování na USB disk, tak bych ho taky naformátoval na nějaký rozumný FS, třeba ext2, rozhodně ne na FAT.

[mirec]

Ak nevadí zahodenie nepoužívaných objektov tak celkom služne počet súborov zredukuje dvojica:

git prune --expire all
git gc --aggressive --prune

[mimi.vx]

git i mercurial jedou bez problemu i na widlich .... m ale na usb flash bych nedaval nic duleziteho ..., a pozor co to ma za verzi fat ... omezeni na 512 souboru odpovida tak fat16:)

[Foo Bar]

Stačilo ten USB přeformátovat alespoň na FAT32 a pak si vyberte takový verzovací systém, který bude lehký na IO operace, aby Vám ten disk vydržel.

[jos]

pokud de jen o přenášení rapository a ne o vývoj nad pracovní kopií na tý flašce, tak v mercurialu bych to řešil takhle:

hg bundle --all /mnt/flash

vyrobí to jeden soubor

věřim, že i git a bazar budou mít něco podobnýho

[pavlix]

Minimálně git bundle k dispozici je.

[polymorf]

USB kluc sluzi len na prenasanie, nakoniec to asi spravim tak ze budem working copy balit. Bud pomocou toho bundle alebo obycajny tar.gz + este to ccryptom zakodujem.

[jos]

při takovýmhle použití:

hg bundle --base <changeset> /cesta/k/usb

se nabundlujou jen revize od <changeset> a AFAIK sou informace v bundlu k ničemu bez repository obsahujícího <changeset>, takže možná kryptování ani není nutný

[Petr Tomášek]

Subversion

[pavlix]

Jasně, jako na všechno :).

[Sten]

Na flash disk bych nedával verzovací systém, který by jej zvládl poměrně rychle oddělat, ale spíše verzovaný souborový systém, třeba LogFS nebo UDF s media-type WORM.

[Foo Bar]

Doporučuji na tom "svém" projektu vyzkoušet rychlost běžných operací. Má zkušenost z Debianího balíčkování je taková, že git je pekelně rychlý a hg ukrutně pomalé (konkrétně na google-go repozitářem).

Mercurial má problémy s většími soubory (a plusem je, že to oficiálně přiznává): http://mercurial.selenic.com/wiki/HandlingLargeFiles

[mimi.vx]

jak v cem ... gentoo jeste nepreslo z cvs na git protoze checkout portage pro 1 developera proste server nezvladl ... 16giga ram na 1 kompletni ceckout bylo proste malo ..

[alblaho]

To je docela zajímavé.

Git dle mých zkušeností je pekelně rychlý, aspoň oproti Bazaaru. Ale když jsem si checkoutnul Linux kernel, tak na mém noťasu s 1G RAM bylo třeba zobrazení kompletního logu dost pomalé. Zajímalo by mě, jak by to fungovalo s CVS, ale asi dobře, protože tam se verzuje každý soubor zvlášť + tagy.

[pavlix]

Zajímalo by mě, jak by to fungovalo s CVS, ale asi dobře, protože tam se verzuje každý soubor zvlášť + tagy.

Hádal bych, že log pak musí být zákonitě daleko pomalejší než v gitu, právě proto, že jsou commit objekty dost minimalistické. Z jiných důvodů možná, ale z tohoto bych řekl, že by měl vyjít opačný výsledek.

[Foo Bar]

Čistý checkout linusova stromu... $ time git log > /dev/null

real 0m5.937s user 0m5.670s sys 0m0.250s

Ale je pravda, že ten stroj má 8GB paměti a čtyři jádra.

[pavlix]

jak v cem ... gentoo jeste nepreslo z cvs na git protoze checkout portage pro 1 developera proste server nezvladl ... 16giga ram na 1 kompletni ceckout bylo proste malo ..

Otázka je, proč to ten vývojář checkoval do RAM :).

[Marián Kyral]

Těch 16GB nestačilo na serveru. To nemá s vývojářem nic společného.

[pavlix]

Těch 16GB nestačilo na serveru. To nemá s vývojářem nic společného.

Můj osobní odhad je, že 16GB RAM na serveru k tomu checkoutu zdaleka nebylo potřeba. A chyba bude někde jinde, ať už v dezinformaci nebo že těch 16GB RAM nestačilo úplně něčemu jinému.

Ono si to stačí představit, checkout od serverou vyžaduje pouze vydání všech packů, jednoho po druhém. Tzn pokud ten server zvládne ty packy nabídnout přes SCP/FTP/whatever, celkem logicky zvládnout i přes Git. Je to jen odesílání souborů přes buffer.

[Gilhad]

Mam ted git-server na uzasnem stroji - wifi-router od linksysu pod OpenWrt, 4MB disk, 16 MB RAM a s pridanou 4GB kartou jako diskem ovladana diodama - takze kazda vetsi aktivita je fakt videt. Kdyz si stahuju cokoli, tak se rozzari jak vanocni stromecek a vsechny ty veci nejdriv spocita, pak komprimuje a posila, nicmene zvlada. Ale u nejakeho mega projektu, kdyby si to chtel vsechno nejdriv nasyslit do pameti ... ale zase tak hloupy snad neni ...

[pavlix]

Zkus si to stáhnout v zápětí z jiného místa znovu :). Porovnávání a repacking nějakou tu ramku určitě zabere, detaily neznám.

[jos]

pomalost mercurialu je daň za to, že je to v Pythonu, třeba by se při použití Psyco nebo Cython poměr změnil

[pavlix]

Změnil ve smyslu zmírnil, víc bych od toho nečekal.

[jos]

takhle sem to myslel, dík za upřesnění

[Heron]

SVN repositář o velikosti 30GB už taký není zrovna rychlík. Tohle je dobrá informace (Mercurialu se musí soubor vejít do RAM+overhead). Díky.

[polymorf]

Dve otazky na grafickych klientov.

Bazar

- tam dole je biely zapisnicek s ceruzkou, proste edit polozky na ktorej stojim. Existuje na to nejaka klavesova skratka? Enter robi to ze to spusti, co napr. pri html otvori v prehliadaci. Ja to potrebujem editovat.

TortoiseHG

- jakym sposobom sa daju zobrazit adresare stromovou strukturou, teraz je vsetko v jednom, proste obrovsky list s asi 5000 subormi, absolutne sa v tom neda orientovat.

Vdaka.

[vulgární Nick]

... V některých týmech se CVS používá dodnes a jsou za něj rádi. ...

Vyznívá mi to, jako by CVS mělo být něco raritního. Přitom nemálo organizací CVS normálně používá a neberou to jako výrazný handicap (resp. to považují za nejlepší řešení). Ono to má několik důvodů.

Zaprvé to je konzervatismus (klidně můžeme říct zkostnatělost) - zejména u větších organizací spravujících mnoho projektů je strach z negativních dopadů změn velký. A oprávněný.

Zadruhé jsou to časové kapacity uživatelů. Projektů je hodně, často se nestíhá a zkrátka nebývá čas, aby se uživatelé učili něco nového (relativně nepotřebného), i kdyby to v konečném důsledku bylo zlepšení.

Zatřetí jsou zde pragmatické důvody - starší VCS jako CVS mají širokou podporu jiných nástrojů (IDE atd.), kterou poměrně mladé projekty typu Git prostě nemají (nebo mají, ale méně kvalitní).

Čtvrtým důvodem jsou problémy při spolupráci několika organizací. Obě organizace používají třeba CVS, protože ho používá i ta druhá. Aby jedna přešla na něco jiného, musela by se akceptovat rizika popsaná výše a navíc by to samé musela udělat i ta druhá, takže by se to celé muselo organizačně zastřešit, což opět vyžaduje finance... Do výpočtu pravděpodobnosti takové změny tedy vstupuje ochota jedné organizace, ochota druhé a ochota obou (nebo více) to koordinovat.

Vyjmenoval jsem několik důvodů, co mě hned napadly, ale ve skutečnosti je jich daleko víc. Na CVS mě s*re několik věcí (a to jsem jen uživatel, nikoli admin), ale rozumím důvodům, proč u něj zůstat.

Zavádět jiné VCS je snažší (nikoli snadné!) u vznikajících projektů než provádět změnu u starých - to bývá často cesta do p*dele.

[vulgární Nick]

On třeba ten Git vznikl v půlce roku 2005. Tak rok hrozilo nebezpečí závažných chyb v důsledku chabého testování v reálném provozu. Další rok se začal používat na menší (domácí, amatérské) projekty. To už máme 2007. Řekněme dva roky trvalo, než měl jakous-takous podporu integrace s jinými nástroji. To je rok 2009. Někdy v roce 2010 ho začaly občas nasazovat i větší organizace.

Tzn. od půlky roku 2010 se může začít uvažovat o nasazení v průměrné větší komerční organizaci; samotné uvažování může trvat půl roku, rok. Další půl roku nebo rok se to může v rámci organizace zkoušet. Až pak se mohou řešit body zmíněné v komentáři výše...

Samozřejmě mluvím o průměrné organizaci (nebo minimálně o takové, o níž si myslím, že je průměrná). Některá společnost může přejít rychle třeba proto, že má prachy, jiná proto, že výhody Gitu nutně potřebuje atd.

[Gilhad]

Mezi gitem a cvs je jeste mezikrok subversion. Ale jinak mi prijde, ze jsi tutez vetu opsal podstatne vice slovy.

cvs je zastarale, neohrabane a zavedene. Funguje porad stejne, kdyz je na nej naveseno milion veci a neni cas, tak prechod na neco novejsiho a ohrabanejsiho muze byt tak bolestivy, ze se u stavajicich projektu nevyplati. Takze jsou radi za to co maji i se vsema nevyhodama, protoze nemaji cas a prostredky prejit na neco jineho, co by jim mozna pomohlo vic, ale musel by to nekdo zaplatit a musel by se na to vyhradit cas ktery neni.

Coz stejne nemeni nic na tom, ze cvs je zastarale a neohrabane a stejne tak to nemeni nic na tom, ze pro nekoho se prechod na lepsi nevyplati a tak je rad za to co ma.

[vulgární Nick]

Mezi gitem a cvs je jeste mezikrok subversion.

Jenže mezi CVS a třeba Gitem je prakticky stejný rozdíl jako mezi SVN a Gitem. Jinými slovy: rozdíl mezi CVS a SVN je velmi malý - z pohledu problémů popsaných výše, ale i obecně.

Co do běžného užívání je SVN skoro stejné jako CVS. SVN beru jako CVS, které pár věcí řeší lépe, ale pořád velmi, velmi podobně jako CVS. Nástroje DVCS by ideálně (chce-li člověk čerpat jejich výhody) měly být používány diametrálně odlišně. Jasně, i DVCS lze většinou používat úplně stejně jako CVS nebo SVN, ale pak je zde otázka, proč na ně vůbec přecházet...

Z důvodu podobnosti s CVS se SVN (vzniklé kolem r. 2000) uchytilo poměrně rychle. Ale i tak to nebyla otázka krátké doby, pořád se bavíme o jednotkách let.

Nechci jmenovat, ale např. jedna poměrně slušná česko-slovenská organizace (vývojářská firma, asi 300 lidí) používá v největší míře CVS a pomalinku teď začíná používat SVN - pro některé nové projekty... A jsou docela spokojeni.

Ale jinak mi prijde, ze jsi tutez vetu opsal podstatne vice slovy.

Vždyť i vy jste můj komentář jen přepsal do jiné formy. ;)

[jos]

jenže od dob CVS/SVN už má každej moula notebook, takže s DVCS můžu čerpat výhody i když budu vyvíjet projekt sám a dostanu se s notebookem kamsi do offlajnu

[vulgární Nick]

jenže od dob CVS/SVN už má každej moula notebook

Nevím, s mouly se příliš nestýkám... Ale ani obecně bych netvrdil, že všichni uživatelé VCS (nebo i jen jejich většina) je v tomto smyslu mobilní.

takže s DVCS můžu čerpat výhody i když budu vyvíjet projekt sám a dostanu se s notebookem kamsi do offlajnu

No jasně! Vždyť já taky preferuju DVCS... Nahoře jsem jen zmínil důvody, které brání jeho rychlému nasazení u určitého typu organizací. U projektů, které vyvíjím sám (a jsou nekomerční), můžu střídat VCS třeba každý měsíc.

[pavlix]

Nevím, s mouly se příliš nestýkám... Ale ani obecně bych netvrdil, že všichni uživatelé VCS (nebo i jen jejich většina) je v tomto smyslu mobilní.

Oni nemusí být mobilní, bohatě stačí, když si admin hraje se sítí :). Jinak homeworking je už dneska taky docela rozšířený. Takže výpadky domácí sítě, či jakýkoli problém s VPN, nebo třeba jen expirované heslo... těch případů, kdy se DVCS hodí i na centralizovanou práci je spousta.

[vulgární Nick]

Prosím vás, nic mi nevysvětlujte. Mě se týká homeworking, notebook a občas (velmi zřídka, ale přece) i ty problémy se sítí. Já moc dobře vím, proč volím DVCS.

[pavlix]

To bych si nedovolil, pouze doplňuju, že ta mobilita není potřeba :), aby se výhody projevily. Když ne pro vás, tak pro ostatní.

[vulgární Nick]

OK.

[jos]

tak vypada to ze si vsichni rozumime, tak prihodim jednu historku k dobru:

kolegove meli delat upravy na projektu do te doby nijak neverzovanem (rozumej verzovanem na filesystemu ... ehm); sve zmeny zacali verzovat v mercurialu, nacez prisel jeden jouda (vazeny dlouholety zamestnanec, pravdepodobne odkojeny na CVS/SVN), kteremu se myslenka DVCS nelibila, a nakonec historie kterou vytvorili skoncila konverzi na SVN (!!!)

co si pamatuju, tak jedine jeho argumenty byly "vetsi narcnost pro adminy kvuli zalohovani" - AFAIK zalohujeme cele filesystemy inkrementalne - a "kdo s tim bude chtit delat se to musi naucit, coz je strasny problem" - jednak kazdy druhy clovek ktereho do firmy bereme nevi o VCS ani prd (i ja mezi ne patril), druhak programator ktery nejde/nechce jit dopredu je bezcenny

a to ten clovek jeste pry tvrdil, ze kdyby dopredu vedel o konverzi repository projektu na kterym makam, tak by to prej zarazil, pricemz sme outsourceovany jinam, firemni adminy to nema sanci zatezovat a s prechodem na hg v teamu nikdo nemel problem

prechodu na lepsi technologie obvykle brani:

zkorumpovani lide (to asi neni pripad verzovacich systemu)

IT aware zpatecnicti idioti (jako ten z me historky)

IT nevzdelani manageri

ostatni idioti

[vulgární Nick]

prechodu na lepsi technologie obvykle brani: ... idioti

Nasazení tzv. lepších technologií je investice jako každá jiná. Může z ní plynout zisk, ale taky nese rizika, která mohou způsobit ztrátu. Někdy rizika hrozí víc, jindy míň a někdy se riskuje pořádný balík a jindy zase pakatel.

Je na každém manažerovi, jak se k investici postaví. Někdo je opatrný investor, jiný riskuje.

Pokud se někdo v určitou chvíli brání těm tzv. lepším technologiím, nutně to neznamená, že je dotyčný debil.

Ano, byly doby, kdy jsem to viděl tak, že teď se prostě všichni sebereme a, hurá, nasadíme něco lepšího než to starobylé CVS. Když jsem byl odmítnut ("Bude se o tom jednat - někdy."), bral jsem to jako velkou hloupost "těch nahoře". Jenže jak jsem začal řešit i jiné problémy než čistě technické (např. organizační apod.), zjistil jsem, že opatrný postoj těch, co mě tehdy odmítli, je rozumný a daný zkušenostmi.

[jos]

de hlavně o to jak to prodat, což bez zkušeností odjinud je dost tězký

ty idioti co sem o nich psal ale neslyší na sebelepší poměr +/- a vymejšlejí co nejvíc lživých výmluv (evergreen na kterej tu a tam narazim je, že s DVCS nic nenutí vývojáře pushovat změny často, což a) je nesmysl b) s DVCS to nijak nesouvisí)

v našem teamu sme nemuseli jít proti větru, prostě se jeden člen zaúkoloval že nám předvede mercurial; všem se to líbilo a dokonce to některý lidi (třeba mě) naučilo používat commandlajnu místo nějakejch pomalejch TortoiseWhatever GUI

[pavlix]

jenže od dob CVS/SVN už má každej moula notebook, takže s DVCS můžu čerpat výhody i když budu vyvíjet projekt sám a dostanu se s notebookem kamsi do offlajnu

My, co jezdíme hodně vlakem na pracovní cesty, to oceníme nejvíc :).

[jos]

jeden muj dojizdejici kolega za casu kdy sme jeste pouzivali svn resil cesty vlakem tim, ze mel <ksakru-ted-si-nevzpomenu::proste-nejakou-VCSnaprd(nedistribuovaneVCS).to.SVN-uchylarnu> a taky si chvili povystacil

pak se zacal rozhlizet jak to udelat bez uchylaren, GIT na widlich tou dobou nejel, o bazaru prohlasil, ze to ma vic prikazu na restore rozbityho repository nez na opravdovou praci, takze s mercurialem stastne zijem doted

[jos]

tak sem se ho zeptal a bylo to SVK

[Bilbo]

Tak např. s gitem lze tohle provádět i nad SVN:

git-svn clone vytvoří v gitu kopii SVN repozitáře (včetně logu a historie)

git-svn fetch dotahá z SVN nové revize (asi jako GIT pull)

Nad tím můžu pak pracovat offline jako s gitem (rebase, vytvářet branche, atd ...)

git-svn dcommit pak docpe moje commity jeden po druhém do SVN

Něco podobného má git i pro CVS.

[----]

no, co se týče různých neduhů, tak jsou si CVS a SVN podobné, nicméně SVN má o dost jednodušší a komfortnější interface; na menší projekty se hodí perfektně; tam, kde je ale potřeba pokročilejší branching apod, tak je Git daleko lepší volba.

[pavlix]

A může být v době Gitu vůbec nějaký důvod použít SVN v novém projektu, kde není použití SVN dané historicky?

[Emalf]

WebDAV (automatické verzování bez další práce a bastlení), zamykání souborů, řízení práv (a ověření autorů commitů), podpora v IDE a dalších programech…

(což tedy neznamená, že by Subversion byl obecně lepší než dnešní DVCS, ale fakt, že v některých případech může mít smysl si ho vybrat – i dnes)

[pavlix]

WebDAV (automatické verzování bez další práce a bastlení), zamykání souborů, řízení práv (a ověření autorů commitů), podpora v IDE a dalších programech…

(což tedy neznamená, že by Subversion byl obecně lepší než dnešní DVCS, ale fakt, že v některých případech může mít smysl si ho vybrat – i dnes)

Jestli ty důvody byly před dvěma lety významné před rokem aktuální a dnes ještě jakž takž... tak pokud budu pro nový projet vybírat něco, co se má používat příštích 10 let... SVN to nebude.

Spojení WebDAV a VCS mi obecně nezní jako dobrý nápad.

Ale za uvedení důvodů každopádně děkuju, zajímá mě to.

[YYY]

Osobne si vystacim se svym centralizovanym verzovacim systemem, ktery je tak jednoduchy, jak jen verzovaci system muze byt - bash only.

[pavlix]

A co je na něm tak centralizovaného (pokud máš nainstalováno SCP či rsync)? :)

[YYY]

Libi se mi na nem to, ze verzuje tak, jak si to predstavuji ja. Samozrejme kdybych pouzil treba svn, tak by to take slo, ale nebyla by to pro mne takova zabava. :)

[pavlix]

Libi se mi na nem to, ze verzuje tak, jak si to predstavuji ja.

Zeptám se tedy ještě jednou :).

A co je na něm tak centralizovaného (pokud máš nainstalováno SCP či rsync)?

Nebo jinak... z čeho usuzuješ, že tvé řešení je centralizované?

[Josef Kufner]

Problém je, že (minimální) složitosti se nezbavíš, jen ji můžeš přesunout. Takže oč je tvůj verzovací systém jednodužší, o to víc se nadřeš.

[YYY]

To mate pravdu. Ale je to na celkem unosne mire.

[pavlix]

Já si pamatuju, že verzovací systém v bashi byl jednou z běžných zkouškových úloh na nějaké 3-4 hodiny :). Měl mít nějaké základný tři příkazy, tuším.

[----]

osobně používám Git na Githubu pro správu vlastního kódu; je to dobrý, kromě těch případů, kdy se chce zapojit nějaký developer a je na Windows. Potom nastavování klíčů a propojení s githubem je pro většinu těžší, klasický linuxový kommandlajnový klient funguje perfektně.

[pavlix]

Potom nastavování klíčů a propojení s githubem je pro většinu těžší, klasický linuxový kommandlajnový klient funguje perfektně.

Nastavování klíčů kvůli mě už zvládl i nějaký ten neprogramátor (než aby poslouchal vysvětlování, proč nechci FTP ani SFTP s hesly).

Programátor by s tím neměl mít (s návodem) jediný problém.

Jinak s klíči mívají lidé problém i na Linuxu, ale z toho bych spíše vinil chybějící UI a to nejlépe alespoň CLI a GUI, zatím jsem neviděl ve slušné kvalitě ani jedno.

[----]

no, co jsem to pomáhal nastavit některým lidem, tak s tím měli problém. Osobně nevím, protože nejsem vůbec na Windows, ale ..

[xkucf03]

Na použití SSH klíčů pod Windows jsem kdysi psal návod, ale stejně to nikdy nebude tak pohodlné jako v Linuxu/Unixu.

[pavlix]

Já doufám, že to jednou bude pohodlné aspoň na Linuxu/Unixu. Ale popravdě není žádný technický důvod, aby to bylo ve Windows méně pohodlné.

[pavlix]

Já zjišťuju, hlavně na linuxových školeních, že SSH má na Linuxu tak blbé (nebo spíše skoro žádné) uživatelské nástroje, že na školení práce s klíči pro SSH zabírá neúměrně mnoho času... a velkou část toho času trávím vysvětlováním, proč to nefunguje tak, jak by lidi očekávali.

Nicméně, abych jenom nenadával, už dlouho uvažuju, že zkusím napsat pár nástrojů, které to budou řešit. Ale těžko říct kdy, a pokud mě někdo předběhne (či odkáže na někoho, kdo už mě dávno předběhl), budu jenom rád.

[Jendа]

Co je na tom z uživatelského hlediska tak nepříjemného? Většinou stačí ssh-keygen (haló, BSA, používám keygen!!!), dvakrát entr a pak zkopírovat výsledek z ~/.ssh/id_*.pub.

Jinak nějakou správu (i) SSH klíčů umí Seahorse.

[xkucf03]

+1 taky mi přijde, že na tom není nic těžkého. A se Seahorsem zvládne generování klíčů i opravdová lama (a je to přímočařejší než s tím Putty ve Windows).

Ad patička: gratuluji

[pavlix]

aky mi přijde, že na tom není nic těžkého. A se Seahorsem zvládne generování klíčů i opravdová lama (a je to přímočařejší než s tím Putty ve Windows).

Z čeho tedy usuzuješ, že Seahorse nebo ekvivalent nepůjde nikdy používat na Windows?

[Jakub Lucký]

gratuluješ k zveřejnění studijních výsledků jiných studentů? :-P

[xkucf03]

Počítám, že to visí někde na nástěnce, takže je to celkem jedno. Např. u nás ve škole jsme dávali nějaký souhlas, že chceme být případně uvedeni na žebříčku nejlepších studentů (když někdo nechtěl, tak tam pak u výsledku chybělo jméno). Ale jinak ta gratulace byla k 1.

[Jakub Lucký]

Já to pochopil... Jen mě ty další výsledky zarazili...

[Jendа]

Zarazily. Visí to na veřejně přístupné nástěnce, tak co. Spíš mě zarazilo, že v TOP 30 (ze 118, z toho 30 sportovců (A) a 30 polosportovců (B)) bylo i 2,25. Jde to doprčic.

[Jendа]

Zamazáno. Už po mně jde ÚOOÚ?

[pavlix]

Co je na tom z uživatelského hlediska tak nepříjemného? Většinou stačí ssh-keygen (haló, BSA, používám keygen!!!), dvakrát entr a pak zkopírovat výsledek z ~/.ssh/id_*.pub.

Vidíš, že se umíš nejen hezky zeptat, ale i si sám odpovědět. A aby toho nebylo málo, tak to ještě často nestačí (např. oprávnění).

Ani to kopírování není pro začátečníka (ani začínajícího admina) zrovna jednoduchý.

[Jendа]

např. oprávnění

To mají snad všechny distribuce defaultně dobře a člověk to musí ručně rozbít, aby to nefungovalo.

A jak by sis to představoval ty?

[pavlix]

1) Aby uživatel použij jednoduchý nástroj k exportování klíče.

2) Aby administrátor použil jednoduchý nástroj k importování klíče.

3) Aby administrátor použil jednoduchý nástroj k přiřazení klíčů uživatelům.

4) Aby uživatel mohl své klíče nadále spravovat nástrojem, který ho od přihlášení neodřízne.

To vše ideálně v provedení CLI a GUI, za dodržení dalších běžných podmínek, dobré úrovně bezpečnosti a decentralizace.

Vím, že je to hodně požadavků, ale splnitelné jsou všechny.

[pavlix]

Pozor, ještě ještě jedna důležitá věc, aby to vše fungovalo za všech okolností, které dávají smysl. Tedy mimo jiné nezávisle na tom, jestli byl nebo nebyl spuštěn SSH agent, jestli se používá nebo nepoužívá passphrase, atd.

[pavlix]

A ještě jedna drobnost, mělo by tam jít spravovat veškeré klientské nastavení SSH, tedy minimálně authorized_keys včetně omezení pro jednotlivé klíče, known_hosts a config.

[xkucf03]

Ani to kopírování není pro začátečníka (ani začínajícího admina) zrovna jednoduchý.

Na to je příkaz ssh-copy-id.

[pavlix]

Na to je příkaz ssh-copy-id.

Který nefunguje (až na některé speciální případy).

[xkucf03]

Můžeš být konkrétnější? Mně zatím vždycky fungoval.

[pavlix]

Protože jsi ho používal jen na to, co umí :) podívej se o vlákno výš a budeš mít jasno.

[pavlix]

Nehledě na to, že učit to začátečníky přes soubory je snad ještě míň bezpečný, než jim privátní klíče generovat centrálně :D.