Dotaz: Čo je zase toto ?

[Faceless man]

Příloha:

• co_je_zase_toto.jpg (63000 bytů)

Čo je zase toto ? Po inštalácii Ubuntu Server 19.10 + inštalácia XFCE desktop a odpojení LAN a pripojení cez WLAN mi bootuje stroj 5 minút miesto 15-20 sekúnd... Zase nejaká systemd/netplan super featura ? :-/ Už ma to vážne prestáva baviť... :-/ (viď príloha)

Odpovědi

[Peter Golis]

To je fičúra bežného network managera ktorý toto robil ešte pred migráciou na systemd. Že to vidíš pri štartovaní systemd služby je len tým, že tá služba využíva network manager. Nastav si primárnu (W)LANku, alebo že LANku nepotrebuje (ak nepotrebuješ iné služby ktoré závisia od siete, na serveri).

[alkoholik]

Do /etc/NetworkManager/NetworkManager.conf flakni:

[ifupdown]
managed=false

a LAN interface pridej teba jako inet manual do /etc/network/interfaces.

[k3dAR]

pokud se nepletu, tak timto jen reknes NM at si toho nevsima, ale *buntu pak pouziva netplan, aby se dala sit nastavit klasicky pres /etc/network/interfaces, je potreba jeste doinstalovat ifupdown balicek...

[alkoholik]

Cistou instalaci Ubuntu jsem nedelal ani nepamatuju. Fakt uz v ni ifupdown neni? Co nadelam..

[dustin]

V tomto případě jde o NM. U serveru bez NM (debian) s DHCP konfigurací sítě nemá systemd defaultně nastavený timeout pro nabíhání síťových rozhraní a při odpojeném kabelu se boot zastaví, protože rozhraní čeká konfiguraci od DHCP serveru. Taky pěkná vychytávka při přechodu ze starého na novější debian se systemd...

[Jendа]

Workaround (prasárna): v /lib/systemd/system/networking.service změnit TimeoutStartSec=10s. Hotfix, trošičku menší prasárna (nemění systémem spravovaný soubor): dát to do /etc/systemd/system/network-online.targets.wants/networking.service.

[Aleš Kapica]

Čím se liší "trošičku menší prasárna" od korektního řešení?

[Jendа]

Pouze to snižuje timeout, ale těch 10 (respektive z nějakého důvodu který nechápu to ve skutečnosti čeká dvakrát) sekund se bude čekat furt.

Myslel jsem, že výsledkem bude, že networking.service nepůjde masknout (na to už jsem se jednou skvěle napálil), ale vidím, že jsem si popletl názvy souborů a je to z tohoto hlediska OK.

[Faceless man]

a nebolo by to lepšie keby to bolo v Ubuntu by default a nemusel byt clovek frustrovany a hladat na internete vacsie alebo mensie prasarnicky ?

[Peter Golis]

A nebol by logickejšie mať server pripojený cez LAN a nie WLAN? A nebolo by lepšie inštalovať server s už zapnutými tými sieťami, ktoré budú preň esenciálne?

PS: Práve si vystihol detailný popis správcu Ubuntu Servera. Namiesto plánovania a logického uvažovabia len trolíš. Keby si aspoň nahlásil korektný bug, ale to by musel byť.

[GeorgeWH]

Citas po sebe a rozmyslas pri tom? System mi ma "prikazovat", co ma byt funkcne a co nie? Jemu to ma byt sumafuk. Ked nedokaze v priatelnom casovom useku nastavit siet, tak idem dalej. A sluzby na tom zavisle, nech si kludne nestartnu. Ale system nabehne a neostane visiet do nekonecna na nejakej veci, ktora nie je, ako pises, esencialna, pretoze v jeho pripade siet zrejme nie je nevyhnutna, inac by to asi neriesil. A ze ma server na wifi? Tak to je zrejme len tvoj problem.

[dustin]

Souhlas, defaulty by měly být smysluplné, a ne že se při vytaženém kabelu boot zasekne.

[Peter Golis]

Správca systému nepotrebuje na serveri mať nainštalovaný desktop. A už dupľom ak by presne toto vedel vyklikať bez problémov v tých desktopových aplikáciách aj bežný užívateľ.

Prosím pokračuj, si zaujímavý. A tvoj postoj ťa naozaj reprezentuje.

[GeorgeWH]

Vysvetli mi, preco z ludi, ktori ti rozumne argumentuju (a teraz myslim vseobecne), robis debilov? Vsade v kazdej diskusii.

[Peter Golis]

Keď sa človek nazdáva že našiel bug, a namiesto vyplnenia bugreportu ide vyplakávať na fórum ktoré je mimo tvorcov danej distribúcie alebo daného produktu, tak sa do tej pozície pasuje sám.

V tomto prípade nevidím technický problém. Vidím len trola ktorý vyplakáva aby vzbudil pozornosť.

Tak isto som presvedčený, že mu na tú sieť čaká nejaká sieťová služba. A nechal vo východzom stave nakonfigurovanú LAN sieť namiesto WLAN siete ktorú chce používať. Jednoducho to neprepol, aj keď na to mal prostriedky.

A za tým názorom že správca nepotrebuje spravovať server v grafike si stojím. U bežného užívateľa by som pochopil správu desktopu v grafike.

[k3dAR]

[...] A za tým názorom že správca nepotrebuje spravovať server v grafike si stojím. U bežného užívateľa by som pochopil správu desktopu v grafike.

zalezi jednak na preferenci spravce, nebo take na tom co na tom serveru bezi, napr. spravuju par serveru ktere delaji PXE, ale zaroven pripravuju do nej upravene Windows instalacky, ktere samozrejme testuju pres virtual a kdyz bych nemel desktop musel bych se na kazdej virtual zvlast pripojovat nebo pouzit virt-manager vzdalene, coz je mnohem pomalejsi/nepohodlnejsi, nez mit VNC na plochu server a virt-manager poustet na te plose... dale na te server-Plose pustim firefox pro pristup do IP-zasuvky, KVM-over-IP, IPMI vedlejsiho serveru atd...

[Peter Golis]

V tom prípade sa ale jedná o desktop na ktorom bežia popritom aj nejaké serverové služby. Či už TFTP, KVM/VirtualBox, NFS/CIFS alebo X Server či hociaké iné.

Server ako taký zvykne mať inštalované minimum SW vybavenia ktoré je potrebné na jeho chod, aby sa eliminovala možnosť kompromitácie pomocou nejakej diery v hociktorom z inštalovaných balíčkov. A na desktop si človek naplácal čo mu srdce zráčilo, a správca z bezpečnostného hľadiska nezakázal.

[k3dAR]

ne, je to server kde bezi: DHCP, TFTP, NFS, SAMBA, WWW, KVM, SSH, VNC, RSYNC na ktorom bežia popritom aj nejaké desktop aplikace

[Peter Golis]

Niečo podobného mám aj ja, ale volám to z historických dôvodov "Desktop". Tá história sa viaže od dôb, keď bol X Window System deravý jak rešeto, a hociktorý proces to dokázal exploitnúť na roota. Z tej doby sa pochádza názor, že server nemá mať grafické rozhranie.

PS: Mám to veľmi podobne, až na služby zodpovedajúce NAS ktoré mám schované vo VM.

[GeorgeWH]

Správca systému nepotrebuje na serveri mať nainštalovaný desktop.

Aj toto je zrejme len tvoj problem.

[dustin]

Bez GUI bude spouštět networking.service, který má pro "auto eth0" v interfaces defaultní timeout 5 minut.

https://askubuntu.com/questions/837932/at-boot-networking-service-is-incredibly-slow-5-minutes-on-ubuntu-16-10

Možná už to překopali, u systemd by mě to nepřekvapovalo...

[Tyler]

ale tam ma no limit... mne to pride hrozne frustrujuce ze boot proces moze mat NO LIMIT casovy interval ...

[dustin]

Jo, když jsem s tím bojoval, byl tam no limit. Měl jsem přeházené síťové kabely a rozhraní nedostalo DHCP odpověď, tak se to celé zaseklo... a čekání nejde přerušit, jak si tu již kolegové stěžovali. Geniální řešení...

[Peter Golis]

Keď mal človek poprehadzované káble, tak bol vo fyzickom dosahu toho stroja.

Mňa skôr zaráža že človeku vadí no/limit čakania na sieť pri serveri ktorý hosťuje sieťové služby. Keď som si nahodil na desktop CIFS a len tak zo srandy nastavil role na AD, a štartoval ten desktop bez siete, tak mi po 1.5 min AD zlyhalo a desktop bez problémov nabehol do degradovaného módu. Ale inštaloval som desktop, a doň serverové služby.

PS: Tu to je:

$ systemctl list-units --state=failed
  UNIT                               LOAD   ACTIVE SUB    DESCRIPTION                
● NetworkManager-wait-online.service loaded failed failed Network Manager Wait Online
● nmbd.service                       loaded failed failed Samba NMB Daemon           
● samba-ad-dc.service                loaded failed failed Samba AD Daemon            

LOAD   = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB    = The low-level unit activation state, values depend on unit type.

3 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'.

Čo ovšem robí problém zadávateľovi plamennej diskusie nevie nik, zatajil to.

[dustin]

Když má ten server 3 rozhraní a jednomu (servisnímu) nenajede IP adresa, tak o nic zásadního nejde, i když přes ostatní poskytuje služby. Jenže tady stačí, aby DHCP server neběžel, a server vůbec nenajede.

[GeorgeWH]

Nie nie, server poskytuje sietove sluzby a pokial nema dostupnu akukolvek siet, tak je v podstate na nic a teda ani nema zmysel bootovat. To da rozum, nie?

[Jendа]

Možná. Podle mě myšlenka byla, že máš služby, které vyžadují nakonfigurovanou síť, a spustit je bez toho je rozbije. Takže v tom případě dává smysl čekat.

Mnohem horší podle mě je, že 10 let nedokázali implementovat, že když se na konzoli zmáčkne Ctrl+C/Escape/něco, tak se aktuálně probíhající čekání přeruší. Takže člověk něco napíše blbě do fstab, konfigurace sítě, whatever, a místo toho, aby se jednoduše přihlásil a opravil to, tak jak debil čeká (v jednom případě 90/180 sekund, v druhém 5 minut).

[Max]

Pokud chci nějakou unitu upravovat, tak jedině přes "systemctl edit networking.service"
Zdar Max

[honk]

Toto je druhý najhorší spôsob úpravy konfigurácie, horší už je len cez GUI klikátko. Keď si na to zvykneš a niečo sa pokazí, tak systémovú konfiguráciu neopravíš napríklad z liveCD, lebo nebudeš ani tušiť, ktorý súbor máš vôbec otvoriť.

[lertimir]

To je nesmysl. To že vím, kde soubor je, nesouvisí s tím, jak ho upravuji. Nastavení sudoers také se velmi doporučuje upravovat přes visudo (také ti tak přímo nepíše, co upravuješ). Nástroj významně snižuje možnosti nezamýšlených chyb.

[dustin]

Samozřejmě to bylo myšleno tak, že z live CD bude tím příkazem upravovat úplně jiný soubor, než ve skutečnosti potřebuje. Ledaže by udělal kompletní chroot, což je kvůli editaci jednoho souboru docela zbytečné.

[k3dAR]

honk psal "lebo nebudeš ani tušiť, ktorý súbor máš vôbec otvoriť." pritom jednou "upravenej" service soubor pres edit bude vzdy v (rootfs_disku)/etc/systemd/ takze pokud by rucnim prvotni editaci nenaprasil svoji zmenu do /lib/systemd, tak by to v obou pripadech nasel na stejnem miste...

[Kit]

Co je zase toto?

[Faceless man]

Ak sa dobre zadivate tak je to notebook Thinkpad T520. Inštaloval som na neho Ubuntu Server 19.10 z dôvodu rozbehania RAIDu0 (mám na ňom 2 x SSD jeden v SATA šachte a druhý v UltraBay). Nasledovalo nainštalovanie xubuntu-desktop + lightdm + všetok potrebný software. Príde mi to ako správne a legitímne riešenie inštalácie desktopu touto cestou nad softwarovym RAIDom. A že po odpojení kábla mi bude robiť takéto psie kusy ma vôbec nenapadlo.

[k3dAR]

nevim jestli spravne, ale urcite naprosto zbytecne komplikovane dela se to tak, ze pustis XubuntuLiveUSB, pomoci mdadm vytvoris pres oba disky pole, na tom LVM, v tom pripravis LV pro rootfs (pripadne zvlast LV pro /boot, /home, /var), pusti se instalator a pri otazce co s diskem se vybere "Neco jineho" a na ty predtim pripravene LV se priradi mountpoint(y)...

[Faceless man]

... a vsimol si si cryptsetup nad raidom ?

[k3dAR]

ne, ale meni to jen to, ze mezi mdadm a pvcreate pustis cryptsetup neco jako:

mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sdX /dev/sdY

cryptsetup --cipher aes-xts-plain64 --key-size 512 --hash sha512 --use-random luksFormat /dev/md0
cryptsetup luksOpen /dev/md0 md0_open

pvcreate /dev/mapper/md0_open
vgcreate md0vg /dev/mapper/md0_open
lvcreate -L 10G -n rootfs md0vg
lvcreate -L 5G -n var md0vg
lvcreate -L 20G -n home md0vg

[R]

Presne kvoli takymto veciam systemd na produkcnych serveroch nemam. Linux bol vzdy postaveny tak, ze spravcu podrzal - nabootoval, ak to bolo co len trochu mozne. Takze aj pri roznych problemoch sa spustilo ssh a dali sa na dialku vyriesit.

Systemd je ale zakerna svina. Pri najmensom probleme cloveku podrazi nohy. Skuste si odpojit disk, ktory je zapisany vo fstab. Alebo len upravit paricie na disku.

[GeorgeWH]

Neboj sa, Golis ti hned vysvetli, ze blbec si ty, lebo si nechtiac urobil vo fstab-e preklep a ze mas nedostupnu siet, lebo ti vyhorel switch. V ani jednom pripade teda systemd nemoze nastartovat, lebo neboli splnene vsetky, citujem, "ESENCIALNE" podmienky.

[a1bert]

tak tak, navic by to ohrozilo casoprostorove kontinuum...

[Pavel 'TIGER' Růžička]

Pořád lepší, než polévka gazpacho.

[Peter Golis]

Skuste si odpojit disk, ktory je zapisany vo fstab. Alebo len upravit paricie na disku.

Myslím že je to pekne popísané v dokumentácii:

SYSTEMD-FSTAB-GENERATOR(8) systemd-fstab-generatorSYSTEMD-FSTAB-GENERATOR(8)

NAME

       systemd-fstab-generator - Unit generator for /etc/fstab

A už pekne dávno.

[k3dAR]

[...]Skuste si odpojit disk, ktory je zapisany vo fstab [...]

po tom co sem takto ztratil pristup k vzdalenemu serveru, radeji pro vse (krome rootfs) pridavam do fstab option "nofail,x-systemd.device-timeout=1"
jednou sem se znazil aby v emergency bylo nahazovane ssh, ale i kdyz sem krome ssh pridal i nahozeni site pri emergency, tak se stejne nedarilo, nechapu ze kdyz uz je hloupe pri nedostupnosti non-rootfs oddilu stopnuto do emergency, proc neni ssh aktivni automaticky, nebo alespon po snadnem pridani nejake option "run_ssh_in_emergency_mode"