"A Yum halott, éljen soká a DNF"

AlmaLinux, CentOS, Fedora, Red Hat, Rocky Linux

"Csodálkozol azon, hogy miért nincs tiszta Fedora 22 telepítés esetén yum csomagod telepítve és miért kapsz Yum használatát helytelenítő figyelmeztetéseket a /usr/bin/yum végrehajtható állomány illetve bármely yum-util plugin meghívásakor? Jól látod, a Yum eltűnt. Szó szerint. És a DNF az új alapértelmezett Fedora csomagkezelő."

Jan Šilhan nemrég kiadta a DNF 1.0-s verzióját, ami alapértelmezett csomagkezelő lesz a Fedora 22-től kezdve.

Részletek Jan blogbejegyzésében.

Azt nem tudom, hogy a dnf képes-e párhuzamosan telepíteni, nem próbáltam, de szerintem van értelme. Mondjuk fut update, addig lehet a még hiányzó alkalmazásokat telepíteni. A párhuzamos letöltést és a delta rpm-ből rpm több szálon történő előállítását viszont tudja.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Van... pl. időzített frissítés, PackageKit, CLI fut egyszerre. Erre persze lehet mondani, hogy jó, de ez desktop... szerveren CockPit (afaik PackageKit) és automatikus (repó)frissítés.

De amit fentebb emlegettek, a párhuzamosan megy az update és a telepítés se rossz ötlet [bár szvsz. az általános esetben megoldhatatlan, ha két csomag is tartalmaz egy fájlt, akkor az időzítéstől függ, hogy mi lesz...]

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Ez oké, de ha engeded a párhuzamos telepítést/update-t... ;) [A elkezdi update-lni a sendmail-t, B elkezdi telepíteni a postfix-et, amihez letörli a sendmail-t, A közben a sendmail új fájljait pakolássza fel, B pedig a postfix-et] Tehát ott lock-olni kell, de minden másra (repó adatok frissítése, csomag keresgélés stb.) jó az, ha párhuzamos.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Szerintem a teljes tranzakcióra lockolnia kell egyben, nem? Csak közben az ro műveletek mehetnének (igazából a yum-mal ilyen szinten nem vagyok tisztában, mindig egy parancssorból managelgetem a csomagokat, zypper-nél látszik, hogy néha túlzásba vitték a lock-okat, és pl. egy PackageKit a kelleténél tovább meg tudja fogni)

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Ezert kell elore tudni, mit fog csinalni, mert akkor lehet tervet kesziteni, es a megfelelo reszeket parhuzamositani. Peldaul a sendmailt tok felesleges updatelni, ha ugyis postfixet rakunk fel, igy egy threadbe bele lehet tenni a sendmail leszedest, majd a postfix feltelepitest.

De akar kulon threadbe is lehet tenni, csak akkor kell valami szinkronizacio, hogy mikor lett torolve mar a sendmail, hogy mehessen a postfix.

Pont az az egyik elonye - amennyire olvastam - a DNF-nek, hogy jobb a dependency solvere, tehat pont az ilyen szituaciokra jobb megoldast es tervet tud talalni, aminek kovetkezteben hatekonyabban tud parhuzamositani.

--
|8]

Ez oké, de csak tranzakción belül tud párhuzamosítani. Ha két külön tranzakcióban futnak ezek (pl. a Cockpit kiadta az update-et, a root meg konzolon a postfix install-t), akkor valamelyiket vissza kell dobni (logikusan amelyik később próbálná lockolni)

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Ez mondjuk egy érdekes felvetés. (sendmail vs postfix)

Nemtudom ki hogy van vele, de ha én feltelepítek egy szervert és tudom hogy postfix lesz rajta, akkor egy yum remove sendmail && yum install postfix
Általában amúgy is úgy kezdem a történetet, hogy felkerült a rendszer, utána átmazsolázom a csomaglistát és kiszedem kézzel első körben ami tuti nem kell. Utána jöhet az update/upgrade

kész. A továbbiakban nem befolyásolja az upgrade folyamatot.

yum -al amúgy én meg vagyok elégedve, nem hinném hogy a párhuzamos telepítés/frissítés (a letöltés az rendben van) olyannyira sok plusz időt takarítana meg, főleg egy szerver esetén. Amennyiben rendesen karban van tartva és frissítve, adott 10+ / 20+ csomagos frissítések pillanatok alatt megtörténnek.

A yum esetén a függőséges témával kapcsolatban, olyankor találkoztam (nem túl sok esetben és csak pár programnál) amikor volt 3rd party repository berakva. Esetleg több is. Na ott pont a két 3rd party repo akadt össze. Bár nem hiszem hogy ez a yum hibája lett volna.

+ megint csak egy extra hibalehetőség jön be a párhuzamos "használattal/telepítéssel/frissítéssel". Milyen jó lehet, amikor a packager, vagy maga a DNF valami hibára fut és mondjuk egy párhuzamos frissítés közben egy *sql frissítés nem megy fel, szolgáltatás nem indul el, stb. Az egy kicsit nagyobb időveszteséggel fog járni utána, mint ha kivárná az ember a "normál" módját a dolgoknak.

Blama... 

root@marv:~# dpkg -l postfix
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Név                       Verzió            Architecture       Leírás
+++-==========================-==================-==================-=========================================================
ii  postfix                    2.9.3-2ubuntu2     amd64              High-performance mail transport agent

root@marv:~# apt-get install sendmail
Csomaglisták olvasása… Kész0%
Függőségi fa építése       
Állapotinformációk olvasása… Kész
Az alábbi extra csomagok kerülnek telepítésre:
  m4 procmail sendmail-base sendmail-bin sendmail-cf sensible-mda
Javasolt csomagok:
  sendmail-doc rmail logcheck sasl2-bin
Az alábbi csomagok el lesznek TÁVOLÍTVA:
  postfix
Az alábbi ÚJ csomagok lesznek telepítve:
  m4 procmail sendmail sendmail-base sendmail-bin sendmail-cf sensible-mda
0 frissített, 7 újonnan telepített, 1 eltávolítandó és 202 nem frissített.
Letöltendő adatmennyiség: 1.418 kB.
A művelet után 1.337 kB lemezterület kerül felhasználásra.
Folytatni akarja [I/n]? n
Megszakítva.

Többek között az ilyenek miatt is kerülöm messzire az rpm alapú csomagkezelőt használó rendszereket :)

--
PtY - www.onlinedemo.hu, www.westeros.hu

Valóban, gyorsba átfutva http://www.rpm.org/max-rpm/s1-rpm-inside-tags.html ezt. Ahogy nézem az RPM spec nem is ad igazán "replacement" -re megfelelő eszközöket.

Azért még együtt tudok élni ezzel. Régebben debian csomagokkal dolgozgattam, mostanság áttértem RPM alapokra (centos/redhat), azóta hozzászoktam ezekhez. A lényegi rész a hozzászólásom többi részében lett kifejtve inkább, yum -> dnf vonalon.

Tudom, nem is a hozzászólásoddal volt bajom, hanem az rpm-mel, hogy még mindig nem jó ez, hiába találnaik ki yum/zypper/dnf/stb neveket neki, ha alapjaiban szar az egész :(
De ez hitvita, belemenni nem akarok egy pmwar-ba, mert semmi értelme, csupán a személyes véleményemet jeleztem :)
--
PtY - www.onlinedemo.hu, www.westeros.hu

SuSE vs. Packman repo.
i586-os install.
Nem emlékszem már, hogy mi volt a csomag, amit packmanról telepítettem, de a készítője i686-ként jelölte az architektúrát, ami miatt is nem voltak neki jók a rendszeren lévő, bár azonos verziójú i586-os csomagok, feltette hát függőségből a packmanon lévő i686-os csomagokat - mondván: megváltozott az architektúra.
Ám egy telepített alkalmazás függőségében (amit használtam volna) meg épp az i586-os csomagok voltak, az adott alkalmazáshoz viszont nem volt i686-os csomag, így azt a rendszer eltávolításra javasolta.
Ez azért kicsit LOL. Arról nem is szólva, hogy abban az időben a repo-k tele voltak i368, i486, i586, i686 jelzésű csomagokkal attól függően, épp milyen színűt pisilt reggel a maintainer...
--
PtY - www.onlinedemo.hu, www.westeros.hu

Hivatalos repoban nem volt olyan csomag. És az opensuse oldalán is (a hivataloson) nagyon sokszor hivatkoznak a packmanra, mint community repora.
Az azonban, hogy az rpm szerint az i386 != i486 != i586 != i686, vagy, hogy egyáltalán ilyen agyament arch megjelelöléseket egyáltalán elfogad, a csomagkezelő átgondolatlan működésére utal.
--
PtY - www.onlinedemo.hu, www.westeros.hu

Nem a csomagkezelő, hanem a csomagoló hibája, hogy nem tudja, milyen CPU-ra optimálva fordította a binárist. Lehet, hogy adott program esetben mindegy, és az adott bájtsorozat helyesen fog futni 386 és fölötte mindenen, de simán lehet olyan, hogy ezeket meg kell külöböztetni egymástól, mert utasításkészletben vannak különbségek közöttük.

Ha jól értem, azt akarod sugallni, hogy egy i686-ra fordított alkalmazás i386-ra fordított függőségekkel (akár libek, akár más, meghívott binárisok) nem fog működni megfelelően, ezért _le_kell_cserélni_ az összes függőséget i686-ra? Mert az rpm ezt teszi...
És szerinted ez így helyén való?
--
PtY - www.onlinedemo.hu, www.westeros.hu

Az rpm nem csinál ilyet. Az rpm függőségi hibánál kilép hibakóddal. A yum, dnf csinálhat effélét, de interaktív alapértelmezetten. Viszont az a dolga, hogy kezelje a függőségeket, az infót ehhez a csomagból nyeri. Ha a csomagoló ostoba volt, akkor ennek megfelelően rossz információra tesz szert a csomagkezelő program.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Ha az alkalmazás -march=i686 paraméterrel fordult, akkor Pentium Pro utasításkészletet használ(hat), tehát i386 CPU-n nem garantált a működése. Működ_het_ i386-os libekkel, i386 binárisokkal, de ez sem garantált.
Az általad citált esetben a csomag készítője nem gondolta végig, hogy ez a lépés (-march=i686, és a spec-ben i686 szerepeltetése) mit okoz (mivel nincs mindenből i686 csomag). Ez nem a csomagkezelés, hanem a csomag készítőjének a hibája.
Nincs mindenből minden processzorcsaládra build, de még az x86-világban is annyian vannak, hogy nem is lehet cél az összest elkészíteni:
gcc http://gcc.gnu.org/onlinedocs/gcc-4.4.2/gcc/i386-and-x86_002d64-Options…
érdemes egy telepítés során egy architektúrán belül maradni - és ha valami "kilóg" belőle (elsősorban fölfelé), akkor azt bizony óvatosan illik telepíteni (nem automatikusan!), illetve saját csomagot építeni - vagy a csomag karbantartójának jelezni, hogy az x. disztróban az i586 a default arch, és problémát okoz az általa készített csomag a telepítés során.

Működ_het_ -> Működik.
Mivel az i368 utasításkészlet teljes egészében része az i686-nak, és mindkettő 32 bites platform, biztosan működik. Külső binárisok hívása esetén garantáltan, de libeknél is, mert a memóriakezelésben pl. semmi különbség, és függvényhívásoknál az a lényeg.
--
PtY - www.onlinedemo.hu, www.westeros.hu

Nem. a feltételes mód nem véletlen. Amit Pentium Pro-ra fordítanak, az nem kell, hogy 386-os CPU-n is működjön, hiszen az utasításkészlet, amit használhat az épp, hogy bővebb, mint 386-os CPU-n. És abban sem lehetsz biztos, hogy egy i386-ra illetve i686-ra fordított lib ugyanazt, ugyanúgy tartalmazza(!)

Jelen kontextusban ez persze igaz, csak azt felejted el, hogy pl. a notebookomin az OS architektura jelenleg is i386, és nem egy SX33 van benne.
Szóval ettől még a XXI században vagyunk a problémával, és nem múzeumi vason fut az app.
Így értve meg irreleváns, hogy i[3456]86-ról beszélünk.
--
PtY - www.onlinedemo.hu, www.westeros.hu

Ja, persze, ez működik pl. java esetén is, mert lehet olyan app, aminek X.Y java _kell_, meg olyan is, aminek meg X.Z - ugyanazon a gépen.
Azt viszont nehezen tudom elképzelni, hogy X appnak az A sendmail bináris kell, Y appnak meg a B, holott MTA tekintetében hulla mindegy, melyik fut.
Innentől az egyik csomag teljesen feleslegesen van a rendszerre telepítve.
--
PtY - www.onlinedemo.hu, www.westeros.hu

Nem győztél meg :)
Az ilyen jellegű átállásokat éles rendszeren (függetlenül attól, hogy van-e ilyen feature) előbb tesztkörnyezetben végzik, ha olyan nagyon kritikus, hogy esetleg vissza kell állni.
Pl. egy mysql, php vagy apache verzióváltás ezerszer kritikusabb egy sendmail-posfix cserénél. Főleg annak fényében, hogy ha egyszerűen leállítjuk a szolgáltatást, a levelek a queue-ban szépen tudnak várni - akár egy másik gépen is.
Lehet, hogy más daemonoknál egy ilyen 'váltás' esetén hasznos tud lenni az ilyen feature, de jelen példánál nem tudom ennek a feltétlen szükségességét megideologizálni.
--
PtY - www.onlinedemo.hu, www.westeros.hu

man 8 alternatives 


[root@makaroni ~]# rpm -qa | grep postfix
postfix-2.6.6-6.el6_5.x86_64
[root@makaroni ~]# file $(which sendmail)
/usr/sbin/sendmail: symbolic link to `/etc/alternatives/mta'
[root@makaroni ~]# file /etc/alternatives/mta
/etc/alternatives/mta: symbolic link to `/usr/sbin/sendmail.postfix'
[root@makaroni ~]#

A sendmail csomag egy /usr/sbin/sendmail.sendmail binárist rak fel, és _ha_ átbillented, akkor lesz a sendmail.sendmail a sendmail :-P

A folyamat a következő:
-fent van egy bekonfigurált MTA, amit le szeretnél cserélni (legyen ez pl. a sendmail)
-felrakod az újat, de még nem élesíted (yum install postfix)
-megcsinálod a postfix beállításait (közben a sendmail, mint MTA működik, fogad/küld)
-service sendmail stop
-update-alternatives ...
-service postfix start

A szolgáltatás kiesése gyakorlatilag elhanyagolható.

Mi van akkor, ha a postfix telepítés leszedi a sendmail-t a telepítés elején? Ha felmegy a postfix, és gyorsan be tudod konfigurálni, akkor is jóval hosszabb lesz a kiesés, illetve probléma esetén visszaállni sem lesz olyan pikk-pakk egyszerű.

Szóval nem buta, hogy nem szedi le a másuk MTA-t, hanem kifejezetten okos. Szerintem...

Egyrészt az, hogy szerinted az MTA nem kritikus, az nem jelenti, hogy más szerint sem az.

Másrészt meg kb a következő beszélgetés zajlott:

- ez hülye ez az rpm
- nem, direkt van így
- de minek
- azért, mert ez a technika segít a downtime leszorításában technológia váltásoknáé, és ha már van, akkor az mtanal is miért ne legyen így
- de az fölösleges mtanal, szar az rpm

meghajlok érveid nagysága előtt.

(egyébként én debianon szocializálódtam eredetileg, egy csomó mindenre wtf fejet vágtam először rpm/yum/zipper alapokon nyugvó disztróknál, ellenben olyanok is benne voltak már akkor az rpmben, amiről akkor a dpkg még baromira nem tudott.

Azt, hogy milyen szolgáltatás számít kritikusnak azt általánosságban nem lehet eldönteni. Van, ahol a ping is kritikus, van, ahol a komplett szerver működése sem az.
A másik lényeges kérdés, ami felett elsiklott a figyelmed, hogy a "rakd fel az újat, és ha jó, akkor szedd le a régit" hozzáállás a rollback-et is eléggé egyszerűvé teszi. Pláne akkor, ha a kiváltásra ítéltetett szoftver már nem áll rendelkezésre csomagként.

Az elmélet vs. gyakorlat nem igaz az éles vs. teszt viszonylatban.
Persze, ha a teszt környezet úgy van kitalálva, hogy semmi köze se legyen az éleshez, akkor igazad van, csak az én kontextusomban az nem tesztkörnyezet, hanem homokozó, ami ovisoknak van.
--
PtY - www.onlinedemo.hu, www.westeros.hu

Alkalmazásrétegig.
Adatszinten csak adatstruktúra egyezés van.
/ha már belekötünk/
És igen, a logokat is áttöltik egyik rendszerből a másikba, és a /tmp is szinkronizálva van, sőt, ha valaki belogol a tesztre, az ugyanabban az időpillanatban az élesre is.
Tudod nagyon jól, hogy miről írok, ne menj el olyan irányba, ami nem a Te stílusod.
--
PtY - www.onlinedemo.hu, www.westeros.hu

Nem, nem tudom miről írsz :) Illetve azt sem, hogy milyen irányba indultam el?

Az igazság az, hogy a gyakorlatban a productionnal jól egyező környezetet nagyon nehéz csinálni, még akkor is, mikor az a szerencsés helyzet van, hogy csak szériaszámban különböző vason lehet tesztrendszert építeni. Az még sajnos édeskevés. Egyrészt még mindig ott lesz egy csomó járulékos, a valósággal azt összekötő dolog mondjuk a network környékén, ahol maradnak banánhéjak, másrészt meg bőven van olyan, hogy egyszerűen az éles adatbázison, vagy az éles useage pattern alatt fog kijönni valami, amire nem sikerült felkészülni a tesztrendszeren. Pl ha az adott rendszeredben nincsenek éles adatok, akkor simán rá lehet futni cumira. Én már jártam így, pedig igen komolyan készültünk elő, többek között volt éles, csak anonimizált dumppal is tesztelve. Aztán kiderült, hogy pont az anonimizálás során olyan alakult át, ami szopó volt. (Az ejnyebejnye meg arra vonatkozott, hogy rendes éles adatot meg sokszor egyéb megfontolások miatt nem lehet tesztelésre használni)

És akkor a gyakorlatban sokszor az van, hogy egyszerűen nem lehet productionnal megegyezővé tenni a rendszert, mert az annyira komplex (sok sikert mondjuk egy nagy elosztott vpn hálózathoz), vagy mert egyszerűen interfacel olyan külső dolgokkal, amire nincs ráhatásod.

Szóval az van, hogy a gyakorlatban én még nem láttam olyan tesztrendszert, amire azt merném mondani, hogy fallback plan nélkül, hogy jó szívvel vállalom be élesben. És tapasztalt ismerőseim mind ugyanezen a véleményen vannak.

Térjünk vissza. Szerinted hülyeség az, hogy lehet fent egyszerre két MTA (illetve gyakorlatilag tetszőleges, azonos funkciójú szoftverből több), amelyik között szög egyszerű oda-vissza váltani, ha szükséges, az rpm, illetve az rpm-alapon működő rendszerekben elérhető alternatives megoldás kitalálói szerint meg nem.

Szerinted fölösleges egy szerszámos ládába két különböző kalapács, mások szerint meg jó, ha van...

( locsemege v | 2015. 05. 23., szo – 00:58 )

Szétoffolom a topicot. :) Noha a csütörtöki go/no-go meetingen olybá tűnt, hogy nem jelenik meg kedden a Fedora 22, adtak neki még egy esélyt. Pénteken újra megvizsgálták a kérdést, és egy nap alatt a kritikus hibák megoldódtak, így május 26-án, kedden megjelenik a Fedora 22.

Én már használom vagy egy hónapja, nem hoz lázba, ezért nem is írtam önálló témaként, csak úgy eszembe jutott. :)

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE