Portál AbcLinuxu, 14. května 2025 00:34
Byl vydán CentOS Linux 7 (1511) pro x86_64. Nejnovější CentOS vychází z Red Hat Enterprise Linuxu 7.2 vydaného 19. listopadu (Wikipedie). Podrobnosti v poznámkách k vydání.
Tiskni
Sdílej:
Latest release 7.2-1511
tenhle zapis X.Y (YYMM) se navic pouziva jenom na webu CentOSJe to ještě horší. Toto je zápis
x (YYMM)
a do závorky jsem chtěl napsat, že je y
vynechané, ale nějaký inteligent už závorku použil na zmatení části čísla verze, takže nechci přidávat druhou závorku.
Používat závorky jako součást čísla verze a ještě s předřazenou mezerou, to je taková volovina, že si nepamatuju, že bych to už někdy viděl. Samozřejmě nepočítám doplnění verze o codename. To skoro vypadá, že to zadali někomu mimo tech komunitu, ten se podíval na stránky Fedory a zápis codename, nepochopil ho, a tak nasypal část verze před závorku a část do závorky. Vypuštění .2
(ačkoli se v druhém zápisu používá) je jen taková korunka toho celého.
Major rebases for the following: Gnome from 3.8 to 3.14, KDE from 4.3 to 4.14, Xorg-X11-Server from 1.15 to 1.17, libreoffice from 4.2.8 to 4.3.7. openldap from 2.4.39 to 2.4.40 and more.Tohle je IMHO to nejuzitecnejsi: update Gnome, KDE a libreoffice.
network.target
namísto network-online.target
a přitom vyžaduje plně nakonfigurovanou síť, tak je potřeba nahlásit chybu především na tu službu. Lennart se jasně vyjádřil ohledně významu network.target
a network-online.target
a vývojáři NetworkManageru, systemd-networkd a /etc/init.d/network
(ale především konvertoru sysvinit->systemd) se tomu přizpůsobili.
Bohužel je potřeba tomu přizpůsobit i ty služby, které nejsou schopny startovat kdykoli během bootu, ale vyžadují už hotovou nakonfigurovanou síť. A to není tak úplně jednoduché hned odhalit z toho důvodu, že závislost služby na plně nakonfigurované síti může záviset na konfiguraci služby.
Další důvod, proč chyby hlásit je ten, že je ve většině případů k dispozici lepší řešení než přidání závislosti na network-online.target
, protože kernel taky není úplně hloupý a dokáže například bindovat adresy dříve než jsou nakonfigurovány.
Zial tato chyba je podla mna ale chybou Centos7 vyvojarov a mozno za tym je aj prebratie configov od RH 7.2 co nikto asi neskontroloval.Nemůžu obecně říct, jestli je chyba zanesená změnou v CentOS (to bude asi málokdy), v RHELu (no comment) nebo ve Fedoře, která se navíc dál samostatně vyvíjí. Za mě je potřeba se zbavovat chyb jedné po druhé. Proto taky preferuju, když jsou systemd unity už součástí upstreamu, ale ne každý upstream se mnou ten názor sdílí, obvykle s odůvodněním, že initskript taky nedistribuují.
Ja potrebujem funkcny server a ked spravim update tak ma vsetko fachat.K tomu ti nemůžu než popřát hodně štěstí.
Ale ked pri velkom update system nevypise ani hlasku zmeny tak to je smutne. Debian toto aspon pri velkej zmene vypise.Obecně chápu. Ale v tomto konkrétním případě co přesně za změnu máš namysli a jak se s tím vypořádal Debian?
Ked som nainstaloval servre centos7 odstranil som netvorkmanager a ine blbosti co tam nemali hladat a vsetko do teraz fungovalo na jednotku.Mně po instalaci co si pamatuju fungoval bez odstraňování čehokoli. Ale to podle mě nemá žádnou váhu.
Je ale zaujimave ze po tomto novom update na tuto verziu v systemd nie je ani systemd-networkPokud mi něco neuniklo (mohlo se stát), systemd-networkd součástí výchozí instalace Fedory a odvozených distribucí není a nikdy nebyl.
do /lib/systmed/system/ sa vytvoril neplatny odkaz dbus-org.freedesktop.network1.service odkazujuci sa na systemd-network.serviceVytvořil? A jakému balíčku patří?
Tak neviem ci je chyba v httpd, named.... alebo v systemd scr. Niekde sa v metrixe stala chyba.Podle popisu to mohlo, ale taky vůbec nemuselo být v CentOS, ale třeba i v lokálně provedených změnách (aka neodborných zásazích do systému).
Podla release tejto verzie by to malo automaticky hlasit chyby.To bych taky obecně netvrdil, to ani nejde.
Rad by som pridal bug ale nemam tam ucet.Tak to je to úplně nejmenší, co může člověk pro komunitní projekt udělat. Sice zrovna u CentOS může být řešení trochu zdlouhavější, ale aspoň se zdokumentuje příslušný workaround a člověk se má na co odkazovat. Jednodušší je to u Fedory, která se dá tak nějak opravovat zaživa.
rpm -qf F
.
ABRT automaticky hlásí pouze crashe (segfaulty, aborty, tracebacky). Je nemožné, aby obecně detekoval chování systému odchylující se od očekávání.
Napisal som to jasne odkaz je vytvoreny ako dbus-org.freedesktop.network1.service odkazujuci sa na systemd-network.service. Vzniklo to po update systemd-lib tejto verzie.Pokud to správně chápu, jedná se o zbytečný leč neškodný symlink na neexistující unitu, který nijak neovlivní práci
network.target
a network-online.target
.
Tu zial centos nic.Stále nevím, co by v tomto případě měl hlásit, takže nemá cenu se k tomu vůbec nijak vyjadřovat.
nerozumiem preco spominas fedoru. toto nema nic spolocne s fedorou.Že by Fedora a CentOS neměly nic společného, to bych se tvrdit neodvážil. Fedoru jsem zmínil především proto, že vzhledem ke své povaze dostává častější a rychlejší aktualizace, než z ní vycházející stabilní distribuce a že z trojice Fedora/RHEL/CentOS bývá první, kde se aktualizace objeví, přičemž zbylé dva ji získají buď vydáním nové verze nebo backportem.
automaticke hlasneie chyb som mal na mysli Abrt (Automatic Bug Reporting Tool) malo by to podla noveho hlasit do bugs.centos.orgPokud mi něco neuniklo, tak ABRT stále hlásí chyby do bugzilly jménem uživatele a na požádání, tedy nikoliv zcela automaticky a nikoliv u uživatelů, kteří si nezřídili přístup do bugzilly. Trochu jiná věc je retrace server, kde se sbírají hlášení o pádech.
Skratka zistil som ze sluzby v systemd ktore maju uvedene v configu na zaciatku network.target mali problem zo spustenim.To nerozporuju, jen jsem k tomu dodal další informace, proč se tak může dít.
Ale sorry spustat network manazer na serveri bez X to snad nie...NetworkManager na X11 nijak nezávisí ani s nimi nijak neinteraguje, je to systémová služba. Další věc je, že je to výchozí služba pro konfigurace sítě na systému, který používáš. Jsou lidé, kteří mají rozumné důvody NetworkManager nespouštět, ale X11 mezi ně rozhodně nepatří. Další více či méně podporovanou možností je
/etc/init.d/network
, který stírá rozdíly mezi network.target
a network-online.target
a tím zakrývá chyby .service
souborech a proto může někdy fungovat lépe.
Zial Centos7 u mna momentalne nevedel spustit podla konfig systemd-network ktora ma byt funkcna od verzie 210 , Centos 7 ma 219.x.Popravdě jsem na CentOS 7 systemd-networkd nezkoušel a mimo CentOS jsem to možná jednou zkusil spustit, na svých strojích používám buď NetworkManager nebo dhcpcd (který na CentOS zatím není, ale snad bude brzo v EPEL) podle situace.
[root@localhost ~]# systemctl show -p Before NetworkManager-wait-online.service Before=network.target network-online.target shutdown.target network.service [root@localhost ~]# systemctl show -p Before network.service Before=network.target shutdown.target network-online.target graphical.target multi-user.targetPokud to tu někdo může reprodukovat, hodil by se log.
Podle mě prostě nemá zapnutý NetworkManager-wait-online.target a ani žádná jiná služba NM-w-o nežádala. V takovém případě řazení k network.target nestačí.+1 Až na to, že při použití NetworkManageru podle mě řazení za
network.target
nestačí obecně. Je potřeba vyžádat network-online.target
a řadit až za něj.
V defaultní konfiguraci httpd to není problém, ale pokud si člověk v httpd.conf nastaví Listen=IP:port, tak httpd při svém startu tu IP musí vidět (nepoužívá IP_FREEBIND). Pak je potřeba si zapnout NM-w-o.+1 Otázkou zůstává, proč nepoužívá
IP_FREEBIND
, který řeší přesně tuto situaci a to daleko lepším způsobem než čekáním na síť při bootu.
Až na to, že při použití NetworkManageru podle mě řazení zaMáš pravdu, obecně to tak bude lepší, i když v tomto případě je to jedno (NM-w-o má taky Before=network.target, takže stačí, aby NM-w-o byl v boot transakci a tím se okamžik aktivace network.target dostatečně opozdí).network.target
nestačí obecně. Je potřeba vyžádatnetwork-online.target
a řadit až za něj.
Otázkou zůstává, proč nepoužívá IP_FREEBIND
, který řeší přesně tuto situaci a to daleko lepším způsobem než čekáním na síť při bootu.
Joe Orton mi k tomu jednou napsal :
No, we can't enable FREEBIND for all listening sockets, it would be a change of semantics for the Listen directive and undesirable. In any case, Listen is only one way in which httpd can be configured to fail if started w/o a network at boot time.
Máš pravdu, obecně to tak bude lepší, i když v tomto případě je to jedno (NM-w-o má taky Before=network.target, takže stačí, aby NM-w-o byl v boot transakci a tím se okamžik aktivace network.target dostatečně opozdí).Aha pravda, tam je ještě tahle berlička aby to šlo postaru pomocí vtažení
network-online.target
, sice super trik, ale na druhou stranu zase schovává chyby.
Joe Orton mi k tomu jednou napsal: No, we can't enable FREEBIND for all listening sockets, it would be a change of semantics for the Listen directive and undesirable.To ten člověk neměl po ruce nic lepšího než argumentaci kruhem? Někdy opravdu nechápu, co se těm lidem honí hlavou, když ze sebe vysypou takovéto zkratkovité nicneříkající vyjádření.
In any case, Listen is only one way in which httpd can be configured to fail if started w/o a network at boot time.Proč by někdo chtěl konfigurovat httpd, aby selhal, to nedává smysl. A jestli nějaká konfigurace vede omylem k selhání z jiného důvodu, tak ano, je to další věc k řešení. Zvlášť, pokud se jedná o tak všudypřítomnou službu jako je httpd. Většina systému je velice flexibilní a je bez problému schopná se smířit se změnami jako je uspávání/probouzení a odpojování/připojování ke stejné síti nebo dokonce k různým sítím. Já sice chápu, že 99% instalací httpd je na strojích, které se připojí k síti a drží a ve výjimečných případech se služba nebo celý stroj prostě restartuje. Na druhou stranu si nemyslím, že by ten zbytek, tedy například developer laptop byl zanedbatelný a tedy si nemyslím, že by jakákoli změna měla vést na pád nebo neschopnost nastartovat. Na tom Apache může běžet několik nesouvisejích služeb, z nichž jen některá potřebuje konkrétní IP a není důvod složit i ty ostatní. Nehledě na to, že byly doby, kdy 99% počítačů Linux v životě nevidělo.
net.ipv4.ip_nonlocal_bind = 1
fragmentem v /etc/sysctl.d/
. Pro IPv6 nevím.
Jinak možný workaround pro IPv4 je zapnout sinet.ipv4.ip_nonlocal_bind = 1
fragmentem v/etc/sysctl.d/
. Pro IPv6 nevím.
35a256fee52c ("ipv6: Nonlocal bind"), v mainline od 4.3-rc1.
network.target
, nikoliv dokončení konfigurace sítě, tudíž to problém neřeší.
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.