Debian 9.0 Stretch zmrazen. Debian Installer 9 Stretch RC 2 (diskuse)

[Max]

Čas nasazovat do produkce a nebát se problémů. Už mám dva kandidáty na upgrade.
Zdar Max

[Salamek]

9 v mym pripade :-P ale uz se celkem tesim hlavne na new nginx

[Max]

Mno, reálně jich mám také tak, ale první 3 tento týden (svn server, ftp server, web server) a další už tolik nehoří (2x ns+radius, redmine, nagios, x2go). A aktuálně mám již delší dobu v provozu stretch se strongswan 5.1 pro IKEv2 a L2TP tunely.
Celkem tedy asi také 9 serverů na Debianu :).
Zdar Max

[Max]

A v privátu pak 4ks. Ale tam to také nehrotím (nepotřebuji nutně novější verze sw).
Zdar Max

[aaa]

Nagios si budeš muset přeložit.

[Max]

To bych musel tak jako tak, protože budu migrovat z nagiosu na centreon engine (opatchovaný nagios by Centreon).
Zdar Max

[Beko]

Pre centreon existuje neoficiálny repozitar: http://mirror.sugarbug.web4me.fr/jessie/ I keď posledný update ma celkom sklamal, na web rozhraní zobrali kopec funkcií :(

[Max]

Teď jsi mně trochu vyděsil. Teda kromě toho nového otřesného designu, kvůli kterému váhám s upgrade.
Jaké fce ti tam chybí? Namátkou ...
Díky
Zdar Max

[Salamek]

Ja jedu na sensu a zatim ok... nagios se mi nejak nikdy nelibil

[beko]

- chýba mi úvodná obrazovka s prehľadom problémov (v starom rozhraní Home > Home). V novom si musíš definovať "view" a nepodarilo sa mi nadefinovať to čo bolo vo "view". Proste je to inak a zaberá to na môj vkus príliš veľa miesta

- v prehľadoch grafov sa neviem zorientovať. Keď som to testoval naposledy tak tam napr. vôbec nebola možnosť filtrovať grafy podľa host group, čo je pre mňa najbežnejší spôsob prehľadu grafov. Pozerám, že v poslednej verzii už túto možnosť pridali, i keď mám pocit, že to filtrovanie reálne nefunguje. Testoval som to na demo.centreon.com

[MP]

Heh, ja na tom budu stavet nove NFS servery rovnou...(a zatracena freeipa tam furt neni, az v 10)

[trekker.dk]

Tak jsem se do toho dal (na vývojovém stroji, nebudeme se pouštět do žádných větších akcí)

  The mechanism for providing stable network interface names changed.
  Previously they were kept in /etc/udev/rules.d/70-persistent-net.rules
  which mapped device MAC addresses to the (arbitrary) name they got when
  they first appeared (i. e. mostly at the time of installation). As this
  had several problems and is not supported any more, this is deprecated in
  favor of the "net.ifnames" mechanism. With this most of your network
  interfaces will get location-based names. If you have ifupdown, firewall,
  or other configuration that relies on the old names, you need to update
  these by Debian 10/Ubuntu 18.04 LTS, and then remove
  /etc/udev/rules.d/70-persistent-net.rules. Please see
  /usr/share/doc/udev/README.Debian.gz for details about this.

Toho blba, kdo tohle vymyslel,... no, tohle by zavánělo nabádáním k trestnýmu činu, takže radši nic. Doufal bych, že je s tímhle server admini (tj. lidi, kterým přizpůsobovat se systemd-kravinám přináší náklady navíc) během následujícího roku/dvou stihnou poslat do prdele, ale nedělám si iluze, že by to někoho v Debianu přesvědčilo. Uživatelům desktou to přece nevadí.

[sigma]

Ono když přehodíte disk do jiného/náhradního HW a dostanete rozhraní eth4-eth7, a v dalším kole eth8-eth11, tak to je taky k vzteku... Stává se nám to u různých embedded systémů zcela běžně, a pouhé vypnutí 70-persistent-net.rules vede na nespolehlivé pořadí, takže net.ifnames je pro nás celkem pokrok.

[GeorgeWH]

cize ked prehodim hdd so systemd do ineho hw, tak nazvy sietoviek ostanu rovnake?

[aaa]

Obecně samozřejmě ne. Ale když je ten hardware skoro stejný, tak mohou.

https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/

[GeorgeWH]

ok, spytam sa takto. v linuxe bez systemd mi pri presune hdd do ineho hw stacilo zmazat udev pravidlo v /etc/udev/rules a na 99% bol nazov sietovky opat eth0 a teda vsetko fungovalo dalej. v pripade systemd bude aka sanca, ze sa sietovke nezmeni nazov? resp. ako urcim nazov sietovky?

[Josef Kufner]

Systemd s tím nijak nesouvisí.

[GeorgeWH]

akoze systemd nema nic spolocne s nazvami sietoviek? hm...

[Josef Kufner]

Ono to je hlavně o pravidlech pro udev, ale jak tak na to koukám, tak systemd do těch pravidel kecá.

[Michal Kubeček]

udev byl už před nějakým časem pohlcen systemd. Proto se ten démon taky v současné době jmenuje systemd-udevd.

[Sten]

Udev je akorát ve stejném repozitáři a používá stejné verzování, ale na systemd nezávisí (systemd závisí na udev). Eudev jako alternativa udev vznikl kvůli podpoře starších jader a ne-GNU libc.

[roumen]

urcim nazov sietovky

Teoreticky je odvozen z topologie PCI zarizeni na vasem PC. Prakticky jsem zazil, ze sitovka byla na 05.0 a po pridani dalsi PCI karty za stejny PCI bridge jsem mel najednou dve karty na 04.0 a 06.0.... Takze slovicka "persistent" a "predictable" bych bral s rezervou jak prase, soudruzi ze Systemd asi zapomneli vzit v uvahu ze vyrobci HW jsou.. vyrobci HW.

[GeorgeWH]

ved prave to. podobne je to aj napr. vo virtualboxe. ako tam urcim nazov sietovky?

mali sme pripad, ked deploynuty vagrant box s ubuntu 16 lts dostal na 2 roznych hostoch v jednom pripade ethX, v druhom ensY.

dalsi priklad je debian preseed, kde sa odvolava na eth0 (ano, da sa to nastavit na auto, ale ide o princip)...

[trekker.dk]

Takže vlastně žádné velké zlepšení a řeší se problém, který neexistuje, způsobem, který nefunguje.

[sigma]

Problémy s náhodným pořadím detekce síťovek jsme dříve pravidelně řešili, to odstraňují persistentní pravidla. A pak jsme pravidelně řešili problémy s přečíslováním po výměně HW se zachováním disků. Výměna HW je zpravidla na totožný typ, případně s minimálními změnami konfigurace, která na označení síťovek na bázi predictable names nemá vliv. Linux už dávno nejsou jen desktopy a servery, dost možná už jsou servery v menšině i když nebudeme počítat Android.

Pro nás tedy problém rozhodně existoval, a tento způsob ho uspokojivě řeší.

[aaa]

Ono to celkem funguje. Například když ti na vzdáleném zařízení odejde síťovka, tak tam stačí poslat někoho, kdo to umí rozšroubovat a tu síťovku vyměnit. A po rebootu má nová síťovka stejné jméno, jako měla ta předchozí.

[Michal Kubeček]

Když máte štěstí. Při troše smůly ho po rebootu nebude mít stejné ani když se nic nevymění. Realita je taková, že "predictable names" nejsou spolehlivě ani predictable ani persistent.

[aaa]

Ono je to tak, že se o predictable names stará udev. Takže je to v zásadě to samé, jako předtím. Pokud je udev špatně napsané, mohou být špatně i predictable names. Je to všechno jenom software, který píšou lidi.

[Michal Kubeček]

Některé věci lze určitě zahrnout pod "špatně napsané", třeba to, když instalátor použije jedno schéma a po rebootu do nainstalovaného systému se použije druhé. I když se tohle vyřeší, pořád zůstává principiální problém, že "predictable" names spoléhají na věci, na které se obecně spolehnout nejde; to je ovšem jen důsledek obecného vývojového modelu "když je to dost dobré pro Lennartův notebook, je to dost dobré pro všechny".

Typickou chybou je třeba sama idea použití číslování podle BIOS/UEFI. Takže pak třeba skončíte se jménem "en16777217", protože nějaký mudrc usoudil, že neví, jestli OS tu hodnotu bude interpretovat jako little endian nebo big endian, tak pro jistotu místo jedničky posílá 0x01000001. A co hůř, na některých systémech se pořadí podle BIOSu po rebootu nemusí zachovat ani v případě, že se žádný hardware neměnil.

[aaa]

O názvy síťovek à la /etc/udev/rules.d/70-persistent-net.rules se stará udev už pěkně dlouho. Takže to budou pořád stejní mudrcové.

[Michal Kubeček]

Jenže tohle je něco úplně jiného než persistent names - a jsou za tím i jiní lidé.

[aaa]

Tak dobře. Já to zase tak nesleduji. Nicméně se i systemd dá nastavit tak, aby síťovka s konkrétní MAC adresou měla název podle přání admina, třeba eth1. Dělá se to bohužel jinak, než dřív a člověk se tím musí prokousat. Mám pocit, že v současnosti se dá dosáhnout stavu, že udev pojmenuje interface podle svého nastavení a pak přijde systemd-networkd a interface přejmenuje podle jiného nastavení. Ruku do ohně za to nedám, ale myslím, že jsem to viděl, naštěstí jen na mém notebooku a ještě nejsíš ve virtuálu.

[Michal Kubeček]

Toho blba, kdo tohle vymyslel,...

Kay Sievers

Doufal bych, že je s tímhle server admini (tj. lidi, kterým přizpůsobovat se systemd-kravinám přináší náklady navíc) během následujícího roku/dvou stihnou poslat do prdele

Ono snad vývojáře systemd někdy zajímalo, co uživatelé chtějí nebo potřebují?

[trekker.dk]

Ono snad vývojáře systemd někdy zajímalo, co uživatelé chtějí nebo potřebují?

Tak naivní nejsem, ale chvíli jsem doufal, že správci distribuce, která je považována za serverovou a konzervativní, budou vůči těm hurázměnám trochu víc rezervovaní. Z toho už jsem se ovšem taky vyléčil.

[lnykryn]

Ono nove pojmenovani bylo potreba. Pokud mate server s jednou dvema sitovkama, tak eth jmena byly v pohode, ale jakmile ma stoj 10 sitovek a naskakuji nahodne pri bootu, tak se objevovali racy mezi udevem a kernel co se bude jak jmenovat. Udev pouzival docasna jmena, aby mohl eth nazvy poprehazovat a byl to opakovany zdroj bugu. Persistent naming tohle resi.

[Michal Kubeček]

Tohle byla častá výmluva, ale ten problém nebyl neřešitelný. Koneckonců ve SLE12 jsou defaultní persistent names a nevím o tom, že by s tím někdo měl problém.

[k3dAR]

nepomuze jen tohle?
Q: I don't like this, how do I disable this?
A: You pass the net.ifnames=0 on the kernel command line

[aaa]

V Debianu to dokonce upravili a bylo to tak, že jsi musel zadat net.ifnames=1, aby to fungovalo podle systemd. A myslím, že to tak ještě je. Takže kdo to kernelu nazadá, má pořád eth0...

[Sten]

AFAIK to je teď tak, že s UEFI to používá predictable names a bez UEFI klasické ethX. (Nemám už žádný stroj bez UEFI, možná to bylo změněno.)

[Conscript89]

Whoah, to je velice odvazne tvrzeni. Co jsme resili predictible names (Fedora/RHEL) tak jsem nikde nenarazil na to, ze by melo mit UEFI/BIOS nejaky vliv. Jedine co vim je, ze biosdevname (vec kterou tlaci Dell) vyzaduje SMBIOS 2.5 (tusim) a vyssi, ale to nema se systemd predictible names nic spolecneho.

[Michal Kubeček]

Částečně. Problém je, že oni mezitím odstranili ten generátor a teď mi nějaká nová verze v Tumbleweedu dokonce ignoruje i ručně dopsaná pravidla (ještě jsem nezkoumal, co přesně tam zase zmršili). Samotné použití "net.ifnames=0" bez dalších opatření způsobí, že se budou rozhraní pojmenovávat pseudonáhodně podle pořadí inicializace.

[Michal Kubeček]

teď mi nějaká nová verze v Tumbleweedu dokonce ignoruje i ručně dopsaná pravidla

Tak to byl naštěstí jen planý poplach: měl jsem tam zkopírovaná stará pravidla vygenerovaná starým generátorem, který v podmínkách používal "=" místo "==" a zdá se, že nová verze to přestala tolerovat.

[Lenin]

Chcelo by to Stretch a kernel 4.8 alebo 4.9 aj pre Raspberry pi

[Andy]

Neříkali, že počkaj na kernel 4.10 jako lts?

[Erbureth]

Ne, měla to být 4.9 LTS

[Lubos Kopecky]

tusi nekdo, proc nemuzu mezi balicky najit amavis? dik

[trekker.dk]

lmgtfo našlo https://lists.debian.org/debian-devel/2016/12/msg00133.html

Asi bych ani moc neplakal, kdybych se s amavisem měl rozloučit, ale co si tak vzpomínám, tak když jsem hledal, nic jiného, co by se dalo rozumně propojit s Postfixem, jsem nenašel.

[Lubos Kopecky]

to teda nic moc informace, diky

jsem zvedav, co se mi podari jako nahrada najit

[hermelin]

No urcite by to slo udelat lepe - ale bohuzel v soucasne dobe nic lepsiho nez amavis neni takze mi prijde uplny nesmysl z takove distribuce tohle odstranit - zvlast pokud neni adekvatni nahrada jinym sw balickem. Podle me je to jeden z pomerne dost pouzivanych balicku v ramci serveru.

Cely problem je pravdepodobne zpusoben timto bugem https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=847311 a to cele spustilo odstraneni z distra.

Muzou to pak dat do backports ale myslim si ze tohle by v soucasne dobe melo byt standartnim obsahem kazde slusne distro pro servery.

[trekker.dk]

Nesmysl to není - je to nepříjemné, ale správce balíku holt řekl, že už správcovat nebude. Nikdo jiný se nepřihlásil, proto to vyhodili. Blbé je, že to bylo takhle těsně před freeze, takže než si lidi stihli všimnout, tak přišel freeze a ten balík tam není a nebude. I když možná to vyřeší backports jako u pacemaker/corosync.

Jinak ten správce taky psal, že podle popcon ta věc má 60 instalací... zdá se, že je nás víc, co popcon vypínají (možná bych to mohl zapnout, těch 1500 non-systemd instalací by mohlo zahýbat statistikou )

[aaa]

Backports u pacemaker/corosync/libvirt v jessie nebyly tedy nic moc. Ve stretchi je to daleko lepší.

[H0ax]

Mailscanner + clamav + SA

[Lenin]

systemd je rakovina ...