CentOS dependency hell

Re:CentOS dependency hell
« Odpověď #15 kdy: 12. 06. 2018, 10:16:18 »
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 :)
„Řemeslo se naučí každý. Umění nikdo.“
„Jednoduchost je nejvyšší úroveň sofistikovanosti.“
- Leonardo Da Vinci


MarSik

Re:CentOS dependency hell
« Odpověď #16 kdy: 12. 06. 2018, 13:50:26 »
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

qwertz

Re:CentOS dependency hell
« Odpověď #17 kdy: 12. 06. 2018, 17:51:26 »
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ářů.

karlik

Re:CentOS dependency hell
« Odpověď #18 kdy: 12. 06. 2018, 18:02:09 »
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.

qwertz

Re:CentOS dependency hell
« Odpověď #19 kdy: 12. 06. 2018, 18:51:47 »
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.


Lol Phirae

Re:CentOS dependency hell
« Odpověď #20 kdy: 12. 06. 2018, 18:57:40 »
asi čtete blbě. PostgreSQL repo je v pořádku!!!

Asi jseš debil.  ::)

qwertz

Re:CentOS dependency hell
« Odpověď #21 kdy: 12. 06. 2018, 19:17:20 »
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)

naseptavac

Re:CentOS dependency hell
« Odpověď #22 kdy: 12. 06. 2018, 19:40:32 »
Ano, ano, to je casty problem spickovych adminu, ze "se jim neco samo rozbije" - centosy, windowsy a i jine osy...

qwertz

Re:CentOS dependency hell
« Odpověď #23 kdy: 12. 06. 2018, 20:20:12 »
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

Re:CentOS dependency hell
« Odpověď #24 kdy: 13. 06. 2018, 22:15:36 »
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.

Libor

Re:CentOS dependency hell
« Odpověď #25 kdy: 14. 06. 2018, 00:00:53 »
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.

qwertz

Re:CentOS dependency hell
« Odpověď #26 kdy: 14. 06. 2018, 06:17:49 »
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.

Citace
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í.

Citace
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.