Názory k článku Spacewalk - centralizovaná správa Linuxů

Jsem zvedavej, jestli vznikne nejaky projekt, ktery by umoznil pouzit misto .rpm .deb baliky. A soucasne doufam, ze vznikne, byt funkcnost asi bude proti rpm omezenejsi.

Nic neni nemozne :) Ovsem asi necekejte ze se toho chopi nekdo ze stavajicich vyvojaru RH, protoze k praci na deb nas nic netlaci/nelaka.

Jinak po technicke strance by to nemusel byt az tak velky problem. Spacewalk ma plugin (hledejte v client/solaris/smartpm v gitu) pro SmartPM a ten ma zase podporu pro deb. Veskera komunikace se Spacewalkem probiha pres XMLRPC, takze napsat klienta pro libovolny OS by nemel byt problem. Implementaci klienta dostanete tu evidenci HW a SW a vzdalene spusteni skriptu.

Horsi by to bylo s ukladanim deb balicku na spacewalku, tam by se asi nektere veci museli upravit.

Velkou brzdou asi bude prakticky obtizna pouzitelnost hromadneho update, protoze update RHELu je transakce, coz deb jeste neumi a mam pocit, ze se nikdo zvlast nezavyva tim, aby to zmenil.

Take je tezsi z deb baliku dolovat informace o tom, jakeho typu je dany update.

Ale jinak by to mohlo byt zajimave, my uz jednu kopii RHN pro debian mame, ale je dosti nehotova a mozna by byla portace elegantnejsi. Kdyby treba nekdo hledal brigadu na prazdniny, tak by se to dalo i zaplatit.

No tak treba ten SmartPM umi transakce i pro deb.
http://www.root.cz/clanky/nova-softwarova-sklizen-3-1-2007/#smartpm

Jestli na tom zacnete delat, tak mi urcite dejte vedet. Osobne bych to radeji videl jako novou vlastnost Spacewalku, nez novy forknuty projekt.

No budu o tom premyslet. V podstate vetsi pocty stroju se nedaji spravovat bez toho, aby clovek okamzite vedel, kde vsude je instalovany balik X, jake verze baliku jsou v obehu a tak podobne. My na to dneska mame vlastni scripty, vetsinou postavene nad volanim pres NRPE a ssh, ale mozna by bylo uzitecnejsi podilet se na nejakem vetsim otevrenem reseni.

google: rpm transaction
a hned prvni odkaz je dost popisny:
http://www.linuxjournal.com/article/7034

v podstate jde o to, ze kdyz mate gimp 1.2 a chcete si ho upgradovat na 1.4, tak udelate yum upgrade gimp. To vam upgraduje gimp a zrejme dotahne i nove knihovny.A kdyz se za 2 hodiny rozhodnete, ze to vlastne nechcete a ze stara verze byla mnohem lepsi, tak jste normalne v ... a ceka vas chvile manualni prace: vyhazovat ty nove knihovny, downgradovat ty povodni... S rpmkem staci udelat: rpm -Uvh --rollback '2 hours ago'

Apt-get umi resit jenom to, ze instalujete balik a pak ho odinstalujete, tak ty nepotrebne knihovny umi odstranit apt-get autoremove. Ale nevyresi vam to ty zminene downgrady.

Děkujeme za upozornění, chyba byla opravena.

Samozrejme zalezi jaky HW pouzijete. Ale vim o instalaci, kde na Satellitu maji povesene 20 tisic pocitacu. Zhruba na kazdych 5 tisici pocitacu doporucujeme predsadit jednu proxy, na odlechceni hlavniho Satellitu (Spacewalku).
V kazdem pripade ty limity asi budou nekde u radu desitek tisic pocitacu a mozna i vice. Na teoreticky limit jeste nikdo nenarazil (10^38 pocitacu). V kazdem pripade, pokud mate mene nez 5 tisic pocitacu, tak nemusite nic resit.