Fórum Root.cz
Hlavní témata => Distribuce => Téma založeno: qwertz 11. 06. 2018, 18:44:21
-
V rámci jednoho firemního projektu provozujeme server na CentOS 7 jako DB server. Jediný externí repozitář je PostgreSQL, tzn. v systému prakticky nejsou externí balíky. Přesto se při pokusu o update po 2 měsících YUM zasekl v dependency hell s tím, že nemůže instalovat 90 balíků typu základní knihovny glib??? protože závislosti.
V porovnání se stejným typem repozitářů v Opensuse a zypper je yum naprosto tragický, místo návrhu variant co s tím 5 minut vypisuje telefonní seznam .so knihoven o na čem závisí, navrhne odstranit systemd a yum, odpoví si sám že jsou protected a nic seělat nebude :-).
To fakt existuje v roce 2018 u RedHat klonů dependency hell?
-
V rámci jednoho firemního projektu provozujeme server na CentOS 7 jako DB server. Jediný externí repozitář je PostgreSQL, tzn. v systému prakticky nejsou externí balíky. Přesto se při pokusu o update po 2 měsících YUM zasekl v dependency hell s tím, že nemůže instalovat 90 balíků typu základní knihovny glib??? protože závislosti.
V porovnání se stejným typem repozitářů v Opensuse a zypper je yum naprosto tragický, místo návrhu variant co s tím 5 minut vypisuje telefonní seznam .so knihoven o na čem závisí, navrhne odstranit systemd a yum, odpoví si sám že jsou protected a nic seělat nebude :-).
To fakt existuje v roce 2018 u RedHat klonů dependency hell?
Depndency hell budes mit vsude, kde definujes spatne dependence.
Doporucuju disablovat postgres repo -> provest update Centosu -> enablovat postgres repo -> updatovat znova.
IMHO maintaineri postgres repa neco zesrali.
-
disablovat postgres repo jsem samozřejmě zkoušel jako první. Vůbec k ničemu to není. I kdyby to byla chyba postgresu, pořád to ukazuje na to, jak hloupý ten YUM vlastně je. Žádnou pomoc typu varianta 1 - ponechat knihovnu nastávající verzi / varianta 2 - vyhodit závislý balíček pryč nenabízí.
Ten SW management je takový pomalý a bezzubý. Řešením beztak bude CentOS vyprat a nahradit něčím, kde se standardně počítá s poněkud aktuálním software.
-
Keby si radsej poslal chybny vypis z yumu ako tu nariekal....
-
disablovat postgres repo jsem samozřejmě zkoušel jako první. Vůbec k ničemu to není. I kdyby to byla chyba postgresu, pořád to ukazuje na to, jak hloupý ten YUM vlastně je. Žádnou pomoc typu varianta 1 - ponechat knihovnu nastávající verzi / varianta 2 - vyhodit závislý balíček pryč nenabízí.
RHEL (a tím pádem i CentOS) jsou založené na tom, že nemáte mít žádná externí repo. U RHEL jste v tu ránu bez podpory a instalace ztrácí svoji hodnotu. Je tedy poměrně logické, že žádnou alternativu k tomu nenabízejí.
Pokud potřebujete novější balíky a nejde Vám o podporu (případně klonovanou stabilitu), pak bych raději volil úplně jinou distribuci.
-
CentOS nebyla moje volba, a rozhodně si nemyslím, že to byla volba správná, tohle řešení jsem tak nějak převzal. Alespoň mám možnost to změnit.
-
disablovat postgres repo jsem samozřejmě zkoušel jako první. Vůbec k ničemu to není.
yum update --skip-broken
-
A co to vyřešit dockerem, a nebude žádný problém...
-
CentOS 7 s pridanym oficialnim repository postgresu (to historicky proslo od verze 9.3 az do soucasne 10 s preskocenim 9.4 a 9.6) mam v provozu uz od roku 2014 bez jedineho problemu, takze mi nezbyva nez si myslet ze nam tak trochu nerikas vsechno pripadne mas teda ale straslivou smulu ze ti zrovna tvuj system takhle osklive zasabotovali...
-
CentOS 7 s pridanym oficialnim repository postgresu (to historicky proslo od verze 9.3 az do soucasne 10 s preskocenim 9.4 a 9.6) mam v provozu uz od roku 2014 bez jedineho problemu, takze mi nezbyva nez si myslet ze nam tak trochu nerikas vsechno pripadne mas teda ale straslivou smulu ze ti zrovna tvuj system takhle osklive zasabotovali...
Vzhledem k tomu, že ten problém není na produkční mašině, ale v mém osobním testovacím prostředí, které jsem sám instaloval, nikdo jiný k němu nemá přístup, není problém potvrdit, jak to proběhlo. Instalace čistého CentOS, Instalace novějšího Postgres a PG Admin a cca 3 měsíce provozu (včetně updatů). Rozpadlo se to zcela nečekaně "samo". (ten systém je prakticky vanila a nic dalšího tam není)
To není nic proti CentOS, ale ten systém má relativně malé repo a přesto to yum není schopen dát do kozistentního stavu.
-
A co to vyřešit dockerem, a nebude žádný problém...
Tak prave postgresql je neco co chces bezet na plny koule a ne to mit brzdeny kontejnerem. Navic z vlastni zkusenosti vim, ze je dokonce vyhodnejsi stahnout srpm a buildnout si to sam. Vykon muze byt lepsi o 20-30% nez repozitarova binarka!
-
Co to reportovat tvurci repa PostgreSQL - CentOS je v tom nevine, ten je konzerva
-
srpms jsou snad v poradku - zkus to prelozit na serveru
-
RHEL (a tím pádem i CentOS) jsou založené na tom, že nemáte mít žádná externí repo. U RHEL jste v tu ránu bez podpory a instalace ztrácí svoji hodnotu. Je tedy poměrně logické, že žádnou alternativu k tomu nenabízejí.
Ehm, to není pravda.
K dotazu, tohle je problém postgreSQL a stejný problém jsou schopní udělat v každé distribuci. Yum a ani jiný balíčkovací systém moc neví o kontextu a pokud má balíček neplatnou závislost, moc s tím neudělá.
Kdyby jsi poslal chybovou hlášku a jen blbě nehejtoval, dá se to vyřešit snadno, takhle aby člověk používal věšteckou kouli :), zkus třeba
yum update --exclude=gdal
-
Já hlavně nechápu proč nepoužil SCL, když už tam má CentOS. V těch je zabalený oficiálně podporovaný Postgres i v o dost aktuálnějších verzích.
https://www.softwarecollections.org/en/scls/user/rhscl/?search=postgres&policy=&repo=&order_by=-create_date&per_page=10
-
Hlavně je třeba vzít na vědomí, že Redhat a CentOS je enterprise distribuce, která je záměrně zmražená.
Jde o to, že když používáte mnoho různých i proprietárních věci je třeba aby se nic neměnilo a jen probíhaly security aktualizace.
Jakýkoliv update na novější verze může znamenat změnu funkcionality a to je kritická věc, ke které vůbec nemá dojít (pokud to není záměr).
Výběr distribuce je prostě politická otázka jak se to má chovat. Takže nakonec dojdete k hybridním řešením s mikroservices :)
-
Hlavně je třeba vzít na vědomí, že Redhat a CentOS je enterprise distribuce, která je záměrně zmražená.
Jde o to, že když používáte mnoho různých i proprietárních věci je třeba aby se nic neměnilo a jen probíhaly security aktualizace.
Jakýkoliv update na novější verze může znamenat změnu funkcionality a to je kritická věc, ke které vůbec nemá dojít (pokud to není záměr).
A právě proto vznikly softwarové kolekce. Je to oficiální nástroj, který umožní ponechat systémovou verzi nějakého nástroje a zároveň pro vybranou aplikaci nainstalovat i verzi novější. Pak stačí jen:
scl enable rh-postgres10 mojeapp
-
Tak problém vyřešen. A ne, nebyl to externí PostgreSQL. To by to totiž bylo poměrně snadné (je to jen řádově 10 balíků).
Yum nebyl při řešení vůbec k ničemu, žádnou nápovědu, na čem ten dependency hell začíná, jsem nedostal, jen telefonní seznam chybějících závislostí. Takže hezky probrat ručně. Chyběl glib2 verze 2.52.4 přímo v hlavním repo. Respektivě chyběl na jednom nebo více mirrorech, protože zum má by default zapnutý fast mirror plugin a stahuje to pokaždé kdo ví odkud.
Takže:
/etc/yum/pluginconf.d/fastestmirror.conf nastavit enabled=0
dále
sudo yum clean all
sudo rm -rf /var/tmp/yum
sudo yum check-updates
sudo yum update
Takže CentOS má rozesranej hlavní repo (přesněji řečeno nějaký mirror) a v tu chvíli to celé spadne a YUM neřekne vůbec nic. Skvělý to systém. Za ten fastest mirror nakopat někoho do zadeke. Zlaté priority u repozitářů.
-
Softwarové kolekce.
Pokud mám více repozitářů, používám balíček yum-priorities.
Pro každý repozitář si nastavím prioritu (např. 1 pro základní repo a aktualizace, 2 pro "extra" atd.).
V "main" repu můžu vypnout aktualizace konkrétních balíčků dopsáním:
[main]
cachedir=/var/cache/yum
keepcache=0
debuglevel=2
logfile=/var/log/yum.log
distroverpkg=redhat-release
tolerant=1
exactarch=1
obsoletes=1
gpgcheck=1
plugins=1
exclude=php* kernel*
Tak se mi yum při update nesnaží nacpat "novější" software třetích repo-stran do "stable" updatů a nebude se z "main" repa povádět aktualizace php a kernelu.
Další možnost je yum update --exclude=postneco*.
Další možnost je použít yumex.
Takže variant je mnoho.
Ovšem tohle by měli mít ošetřené tvůrci repa PostgreSQL -> nahlásit bug.
-
asi čtete blbě. PostgreSQL repo je v pořádku!!!
Rozbitý je hlavní repozitář CentOS, respektivě některé jeho mirrory, ze kterých si YUM "náhodně" vybírá do dobz, než ho s defaultně zapnutým fast mirror pluginem pošlete do hajzlu.
-
asi čtete blbě. PostgreSQL repo je v pořádku!!!
Asi jseš debil. ::)
-
Asi jseš debil. ::)
Protože se rozbil CentOS repo, neobsahuje originální balík, na kterém závisí půlka systému? To jistě bude tím.... 8)
-
Ano, ano, to je casty problem spickovych adminu, ze "se jim neco samo rozbije" - centosy, windowsy a i jine osy...
-
No jasně. Admin serveru může za to, že mirror repozitáře neobsahuje tytéž balíky co originál repozitář, takže má ten mirror sám rozbité závislosti. Tady je to dneska samej génius ;D
-
popravdě vůbec netuším co provádíš. Je tvoje zodpovědnost si zkontrolovat, jestli je mirror up to date (jako admina). Oficiální mirror list je udržovaný, pokud máš nějaké problémy, hledal v mailing listu https://lists.centos.org/mailman/listinfo/CentOS-mirror
Dělat administrátora linuxu a tvářit se jako obyčejný uživatel, který netuší co dělá není naprosto dobrý nápad.
Vinu sice svádíš na problém s neaktuálním mirrorem, ale nedal jsi sem jedinou chybovou hlášku, která by to dokazovala, nedal jsi sem ani adresu toho mirroru, aby se dal případně jeho správce upozornit, jen tady hejtuješ a tváříš se jako velký guru.
-
Pro tazatele. V práci mám nasazeno <20 CentOS strojů. Jednou za čas se při update vše pokazilo a nešlo to ani tam ani nazpět. Byly to i mašiny bez dodatečných repozitaru- možná max. epel-release. Po x-ten problému jsem ho nachytal. Něco občas zavleklo závislost na i686, pak jsem měl spoustu balíků 2x, včetně glibc apod. To ještě prošlo, ale další update byl konec.
Čili jsem nasadil --exclude =*i686* a je pokoj.
Ale rozhodně si na CentOS update dávám pozor.
-
popravdě vůbec netuším co provádíš. Je tvoje zodpovědnost si zkontrolovat, jestli je mirror up to date (jako admina). Oficiální mirror list je udržovaný, pokud máš nějaké problémy, hledal v mailing listu https://lists.centos.org/mailman/listinfo/CentOS-mirror
OK. Zkusím dohledat, který mirror to je rozbitý, snad budete pak spokojen. :-)
Nejsem CentOS Admin a jedná se o R&D mašinu, nic produkčního nebo mission critical. Na druhou stranu osobně používám různé distribuce a nikdy jsem se neproupdatoval do rozbitého systému s tím, že by balíčkovací systém (v tomto případě yum) nebyl shopný jednoznačně říct, kde je problém. Závislosti jsem místo něj dořečil ručně, takže nejsem úplně blbej.
Dělat administrátora linuxu a tvářit se jako obyčejný uživatel, který netuší co dělá není naprosto dobrý nápad.
Jako admin CentOS se netvářím. Nepoužívm ani Fedoru, takže je to spíš povzdech na dím, jakým způsobem to funguje. Ne, že se stala chyba, ale jaké (ne)jsou možnosti řešení.
Vinu sice svádíš na problém s neaktuálním mirrorem, ale nedal jsi sem jedinou chybovou hlášku, která by to dokazovala, nedal jsi sem ani adresu toho mirroru, aby se dal případně jeho správce upozornit, jen tady hejtuješ a tváříš se jako velký guru.
Tak problém je zcela jasný, pokud systémové balíky určené k zpdatu závisí na glib2 verze 2.52.4 a tento v repozitáři není, přestože na webu CentOS je k nalezení. Prostě v tom konkrétním repu chyběl. Stačilo zakázat mirrory a všechno se vyřešilo. Řešení snadné, jen přijít na to v čem to je.