Debian Jessie + PHP 5.2.6 (diskuse)

[Josef Kufner]

Existuje daleko jednodušší cesta. Kontejner.

Namísto prasení systému si uděláš lehký kontejner a v něm provozuješ starší verzi systému s požadovanou aplikací.

Postup je celkem jednoduchý. Na Debianu asi takto:

1. Pomocí debootstrap získat základ systému zvolené verze. Ve vybraném adresáři (nejlépe něco ve /var/lib/container nebo /var/lib/machines) se objeví budoucí kořen systému.
2. V hostitelském systému se nainstaluje systemd-nspawn nebo lxc.
3. Vyrobí se kontejner na adresáři z 1. bodu. Pokud se používá systemd-nspawn, tak je potřeba v kontejneru nainstalovat dbus, aby fungoval machinectl shell, ale pokud je použit moc starý systemd, tak to nepomůže a musí se používat machinectl login.
4. Je vhodné nasměrovat logování do hostitelského systému a poštu předávat pomocí ssmtp.
5. Do kontejneru se nainstaluje požadovaná služba. Namísto přímého spouštění služby se spouští celý kontejner.
6. Na co nejvíce věcí se použijí unixové sockety, aby se to nepřetahovalo o porty (třeba MySQL).
7. Na službu v kontejneru se nasměruje hostitelský webserver, nejspíš jako reverzní proxy. Případně může stačit napojení na PHP-FPM nebo tak něco (podle služby/aplikace).

[snajpa]

+1 za kontejnery a +1337 za rozumny pristup (ie. *not* Docker).

[Acci]

Co je špatného na Dockeru?

[podlesh]

Doporučuji použít google existuje spousta hate page. Tedy, samozřejmě chci řici informačních stránek s varováním Ale je pravda že na systemd to nemá.

No a já osobně bych to shrnul do velmi krátké větičky: autoři dockeru se řídí příslovím "napřed řež, potom měř"

[Michal Kubeček]

6. Na co nejvíce věcí se použijí unixové sockety, aby se to nepřetahovalo o porty (třeba MySQL).

Na to máme už pár let takový vynález, říká se tomu network namespace.

[Josef Kufner]

To jo, ale pokud jde o jeden nebo dva sockety (služby), je jednodušší si tím nekomplikovat život.

[Michal Kubeček]

To je věc vkusu, já si pod "nekomplikovat život" naopak představím spíš to, že kontejner poběží ve vlastním netns.

[R]

To uz by som radsej aj ten cudzi PHP kod opravil ako robit taketo veci...

[Rezervní Polská Kotace]

To poslední číslo je patch verze, nikoli minor (major.minor.patch). Pokud to není kompatibilní při změně patch verze, tak je buď zprasené PHP nebo extrémně zprasená aplikace.

IMHO by bylo lepší opravit tu aplikaci než páchat takovéhle šílenosti. Prasit se nevyplácí skoro nikdy - to si člověk myslí, ze ušetří trochu času, ale nakonec to to trvá déle, než to udělat napoprvé pořádně. Vládní zkušenost.

[Heron]

je buď zprasené PHP nebo extrémně zprasená aplikace

Ano

[Max]

+1
Zdar Max

[Bedňa]

Tak deprecated funkcie z päťky sú známe roky, dokonca aj tie čo mali byť v "šestke" a môj kód bez jedinej úpravy chodí aj na sedmičke, hoci ide o pár tisíc riadkov, nemusel som spraviť jedinú úpravu.

Teda v najnovšom antiXe je už teraz by default sedmička, čo ma prekvapilo, ale som rád že som si to odskúšal.

Nejak ma zdvíha zo stoličky aj keď niekoho vidím napísať ifconfig, proste ľudia kašlú na sledovanie technólogií a aj teraz určite niekto píše nový kód ktorý neprejde cez PHP5.4+, pretože si to nezapne v ini.

Ja píšem tak, aby sa nezobrazovali ani upozornenia a logy sú čisté ako božie oko

To sa vlastne týka každého jazyka, keď niečo kompilujem a vidím tie desiatky warningov, tiež by som vývojára zabil

[hypvofxy]

Nejak ma zdvíha zo stoličky aj keď niekoho vidím napísať ifconfig, proste ľudia kašlú na sledovanie technólogií

Hm. Ja to spis vnimam tak, ze ifconfig pouzivam roky na par zakladnich veci, dela presne to, co chci, jsem na to zvykly a nemam zadnou motivaci pouzivat neco jineho (cti: ip). Az ten duvod/motivaci budu mit, tak proc ne, ale zas abych travil cas ctenim manpages ciste proto, ze se Bedna zvedne ze stolicky, az pred nim napisu ifconfig eth0 down, to taky ne.

[Michal Kubeček]

ifconfig … dela presne to, co chci

Tak to máte velké štěstí. Až ho jednou mít nebudete, budete se divit, stejně jako mnozí před vámi.

[hypvofxy]

To by byla ta motivace. Anyway, ted jsem si googlil nejake horror stories a nenasel jsem nic. Misto toho jsem se seznamil se syntaxi ip a asi neni problem prejit na to, prinejmensim to ma konzistentnejsi CLI. Jinak ani v aktualnim Debian Testing v manpages ifconfigu neni jedina zminka o tom, ze by to bylo obsolete nebo deprecated, a nejake technicke zduvodneni za tim by me docela dost zajimalo.

[hypvofxy]

(Pokud nepocitam to, ze ifconfig se uz v podstate nevyviji - coz se ovsem tyka vicero toolu a kdyz jsem se kdysi podival do zdrojaku ls, malem jsem se poblil. Presto jej za deprecated nikdo neoznacil.)

[Heron]

Problém je, že ani třeba na takovou MD5 příliš mnoho horror stories není. (Na používání md5 jsem pro změnu alergický já.) Přitom je to 10 let prolomené.

Man stránka ifcofig z debianu je z roku 2008 - prostě tam to deprecated nikdo ani nenapsal.

Technické zdůvodnění lépe popíše Michal, praktické zdůvodnění je například takové, že ve výpisu příkazu ifconfig neuvidíš všechny IP. A to už v praxi problém dělá. Dále tam jsou věci ohledně routovacích tabulek ve výpisu route vs. ip route apod.

Rychlé srovnání ifconfig a ip a show:

br0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 46.227.xxx.xxx  netmask 255.255.255.248  broadcast 46.227.xxx.xxx
        inet6 fe80::b81e:aaff:fe16:dea5  prefixlen 64  scopeid 0x20<link>
        ether ba:1e:aa:16:de:a5  txqueuelen 1000  (Ethernet)

vs

3: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether ba:1e:aa:16:de:a5 brd ff:ff:ff:ff:ff:ff
    inet 46.227.xxx.xxx/29 brd 46.227.xxx.xxx scope global br0
       valid_lft forever preferred_lft forever
    inet 192.168.42.17/24 brd 192.168.42.255 scope global br0
       valid_lft forever preferred_lft forever
    inet 10.0.0.1/24 scope global br0
       valid_lft forever preferred_lft forever
    inet6 fe80::b81e:aaff:fe16:dea5/64 scope link
       valid_lft forever preferred_lft forever

Ve výpisu ifconfig 3 ip prostě chybí. Mohli by tam být, kdyby měly přiřazený label, ale tím problémy zdaleka nekončí.

[hypvofxy]

Jo, diky. Ono to bude tim, ze ja se treba se situaci, ze by jeden interface mel vic IP adres, proste vubec nesetkavam. Stejne tak bezne nenastavuji routovani. Proto jsem psal, ze ifconfig pouzivam jen na par jednoduchych veci, a tam to (zatim vzdy) fungovalo dobre. Pak asi zalezi na tom, jestli Bedna vstava ze stolicky, kdyz to vidi pouzivat u sysadmina - pak bych to pochopil.

Kryptografie je trochu specificka oblast, protoze vsechny algoritmy tam maji omezenou zivotnost (s ohledem na aktualni poznatky a dostupny vypocetni vykon). Pouziti MD5 pro bezpecnostni ucely v soucasne dobe take povazuji za nestastne (uz jen kvuli dostupnosti rainbow tables).

[Michal Kubeček]

Oblíbená (a svého času celkem rozšířená) horror story je třeba to, když si admin odstřelí pod rukama SSH spojení na vzdálený server, protože se pokusil změnit parametry rozhraní eth0:0, které ve skutečnosti neexistuje, a ifconfig místo toho změnu provedl na eth0, čímž se server stal zcela nedostupným.

Jiná, méně hororová, ale přesto docela nepříjemná, věc, na kterou jsem narazil, je ta, že donedávna ifconfig ve výpisu tiše ořezával jména rozhraní na určitou délku (IIRC 9 znaků).

Stručně řečeno, ifconfig občas ukazuje věci, které ve skutečnosti neexistují, velmi často vám neukáže věci, které existují (ale mohou být zatraceně důležité) a občas udělá něco úplně jiného, než se zdá a než by od něj uživatel očekával.

Technicky jsou hlavní problémy v tom, že

• vychází z předpokladů, které už dávno nejsou pravda - přičemž "dávno" není nijak přehnané, jádro 2.2 vyšlo v lednu 1998
• používá staré ioctl rozhraní, které se už dlouho nerozšiřuje, takže historické nástroje nemohou konfigurovat nebo zobrazovat nové věci ani kdyby chtěly

V případě nástrojů jako ifconfig (route, arp) už aspoň je povědomí, že jsou zastaralé, i když řada uživatelů pořád setrvává na pozici "na to, co potřebuju, mi to funguje". Ale třeba o existenci ss většina uživatelů vůbec netuší, a to včetně těch, kteří zoufalou neefektivitu netstatu pociťují na vlastní kůži (nebo by ocenili rozšířené informace, které by jim ss poskytl).

[hypvofxy]

Diky za info.

[trekker.dk]

A tím končí dnešní díl seriálu Michala Kubečka "10 let nové věci, které máte dávno používat"

(<sotto voce>Na ten ss bych se měl už konečně podívat</sotto voce>)

[Max]

Jop, díky za připomínku, opravil jsem v blogu.
Zdar Max

[trekker.dk]

...a tak místo toho, aby jedna firma byla dokopána k tomu, že tu aplikaci je potřeba udržovat s ohledem na vývoj interpreteru, tak místo toho běží další zprasený server se zastaralým děravým PHP.

Slovy ZNC, tenhle příběh nemá, nemá dobrej konec.

[Acci]

Opravdu by nebylo jednodušší opravit tu PHP aplikaci? Nemohlo to totiž být něco složitého, PHP mezi verzemi nemívá žádná velké nekompatibility.

[Max]

Nejsem programátor, ale ten, co ten server jen spravuje. Majitel o problému ví. To je asi tak vše, co k tomu mohu dodat.
Zdar Max

[podlesh]

No, aby ses nedivil... já jsem letos musel zprovozňovat jednu aplikaci která se rozbila nekompatibilní změnou v http://php.net/manual/en/function.mail.php - přestalo fungovat posílání mailů. A rozhodně nebylo triviální provést reverse engineering ručního skládání MIME message a zjistit, že celý ten kód je postaven na tom že $message je prázdný a kompletně celá MIME message je v $additional_headers (což evidentně fungovalo než tam někdo přidal validaci). Sám bych na to nepřišel, už dávno dávno v PHP nedělám.

[R]

Byvaju tam obcas chutovky. Prerabal som weby s CMS z PHP 4 (Debian Sarge) na 5.6 (Jessie) a dalo to celkom dost prace... Najvacsi humus bol v tom, ze kod dost vyuzival register_globals.

[hypvofxy]

Ono je hlavne spekulativni, jestli je PHP vubec programovaci jazyk, resp. jestli jeho parser alespon ideove odpovida nejake formalni gramatice, nebo je to spis sada podminek a AST je pro autory, prinejmensim starsich verzi, nic nerikajici pojem.

[Bedňa]

Historia PHP bola búrlivá a adoptovalo skoro všetko čo niekto napísal, takže z počiatočnej kamarádskej partie sa až časom začali stávať vývojári ktorí začali riešiť bezpečnosť.

Tie omyli sú už ale známe roky a sú aj v dokumentácií vynačené červenou farbou, to že ich vývojári ignorujú by som jazyku nepričítal a dá sa na ne naraziť v každom jazyku.

[hypvofxy]

Mluvim o parseru. Bylo to napsane (prinejmensim driv) jako sada if-u.

[Josef Kufner]

Od té doby PHP urazilo velmi dlouhou cestu.

[pb.]

Mě cyp střeli.

DontBreakDebian

Představ si, že tě přejede autobus a někdo po tobě takový server převezme - skočí pod vlak.

Takhle nějak upravený server jsem upgradoval vloni (hw i sw). Maník si tam nainstaloval vlastní databázi, ale tak šikovně, že se nedal udělat dump (míchanina jeho vlastních binárek s binárkami distribuce). Bylo potřeba na jiném počítači ze zdrojáků nainstalovat onu verzi databáze, přenést binární data, udělat dump, a teprve potom přenést na nový server. V noci - přes den se s databází pracuje. Zákazník se prohnul. Řidiči autobusu jsem poslal děkovný dopis.

[Max]

1) převzal jsem server bez dokumentace, takže vím, jaké to je
2) já vždy dělám dokumentaci ke všemu, takže kdo to převezme, tak bude hned vědět, co tam běží a jak je to nastaveno + ke složitějším věcem nechácám jako součást dokumentace step2step postup instalace
3) naladěná spešl verze php bokem je běžná věc a není to nic, co by nějak zasahovalo do systému
Zdar Max

[pb.]

Mně hlavně debian nepřijde jako zrovna vhodná distribuce na takové kejkle. Do debianu dostanu nějakou sadu balíků, se kterou si musím poradit, a změnit balík na něco jiného bývá opruz. Výrazně lepší je v tomto ohledu Gentoo, ale udržovat to bývá opruz. Člověk si nevybere.

Narazit na server s různými vychytávkami není nikterak vzácné. Lepší je v tomto ohledu převzít server po někom, kdo tomu moc nerozuměl a u koho dosud nezvítězilo ego nad strachem, že něco pokazí. Zrovna teď postupně nahrazuju po komsi dva servery v malé síti. Je to jak chodit v minovém poli: 10 uživatelů, pošta, 3 windows NT domény na sambě (!?), zhruba 15 sítí (kamery, tiskárny, docházka, PC, wifi - vše má vlastní síť), ručně psaná pravidla do iptables (cca 300 řádků) a openvpn kam se podívám. Debian 4 a 6, tím klikátkem z Ubuntu doinstalované potřebné balíky odjinud. Normálně tam není udělané snad nic. Firma, která to spravovala dosud, už to dělat nechce. Jako debil pochopitelně vypadám já, protože jim to fungovalo a jen co jsem se toho ujal, přestalo fungovat tu tohle, tu onohle - prakticky cokoliv, na co sáhnu.

Máte maji pochvalu za dokumentaci.

[Max]

Mojí zásadou je dělat vše systémově přes oficiální repa. Když už něco dělat "ručně", tak zásadně jen koncový balík, na kterém nic nezávisí.
Další mou zásadou je virtualizovat a virtualizovat a co nejmíň se snažit provozovat víc věcí v jednom systému, protože pak je to složitější na údržbu (odstávky apod.).
Jinak 15 vlan, to není tak moc, já mám v naší hlavní pobočce toto a budu asi přidávat další (koppii produkce na testování + nějaké další vlan pro heartbeat pár dalších serverů/služeb):

  10             VLAN10       Port-based   No
  15             mgmt         Port-based   No
  16             NetAppCl     Port-based   No
  17             vMotion      Port-based   No
  18             vFT          Port-based   No
  20             VLAN20       Port-based   No
  25             MetRail      Port-based   No
  30             VLAN30       Port-based   No
  40             VLAN40       Port-based   No
  42             WAN          Port-based   No
  43             DMZ          Port-based   No
  44             FTP-DE       Port-based   No
  45             IP-Phone     Port-based   No
  46             VLAN46       Port-based   No
  48             CRANE        Port-based   No
  70             Printers     Port-based   No
  80             Mobile       Port-based   No
  82             FreeWifi     Port-based   No
  100            Camera       Port-based   No

Zdar Max

[pb.]

Na mě je těch sítí trochu moc. Jaký je důvod rozdělit třeba tiskárny, kamery a mobily? Zajímalo by mě, jaké pohnutky k tomu vedou.

Nečiní mi problém pochopit, proč zvolit /16 segment a do každého /24 podsegmentu naházet nějakou skupinu zařízaní a případně hostům přidělit samostatnou síť (tj. 10.10.1.0/16 servery, 10.10.2.0/16 PC, 10.10.3.0/16 tiskárny, 10.20.0.0/16 hosté). Ale nejde mi do hlavy, co někoho vede k tomu, aby si vyrobil v síti s deseti PC patnáct různých síti, které jsou mezi sebou přístupné pouze prostřednictvím routeru a spousty pravidel v iptables.

Ten výpis je výstup z čeho?

[snajpa]

Tak kdyz je ta moznost, proc ne? Stejne je to vicemene jednorazova prace. A pak kdyz je prusvih treba jenom na tiskarnach, da se to krasne resit a naopak to praci usetri.

[pb.]

Tak kdyz je ta moznost, proc ne?

Tohle je to ego, o kterém jsem mluvil. Proč to dělat jednoduše, když jsem borec (neberte si to nijak osobně).

[pb.]

...kdyz je prusvih treba jenom na tiskarnach...

To jako že ta síť přestane fungovat a všechny ostatní jedou? Nebo že všem najednou dojde toner a IT tam odmailuje nový?

[Max]

To je výpis ze switche.
Oddělená vlan pro všechno má význam v tom, že můžeš řídit přístupy, jak je libo.
Třeba tiskárny, chceš řídit tiskárny jen pomocí serveru, pak není moc žádoucí, aby k nim měli uživatelé přístup napřímo, nebo aby je windows discoverovaly (smo, jde to zakázat ve windows, ale zase, pokud máš nějaký counter na počet výtisků apod., tak je vhodné celou síť s tiskárnama oddělit).
Kamery, opět není moc žádoucí, aby měli uživatelé přímý přístup na kamery (kdo má řešit různé vendory a řešit, jaký model jakého výrobce umožňuje unauth přístup na jakém portu a url, řešit bezpečnostní chyby ve fw apod.). Tohled člověk elegantně vyřeší vlanou a nemusí nic řešit, jen na fw povolí komunikaci pro cam server + nagios + případně mgmt a hotovo (cam se na net nedostanou a nikdo k nim také ne, tak je mi putna, jestli jsou děravý, nebo ne, o starost míň).
To samé mobily, když je strčím do vlan, nad kterou nahodím ACL, tak mohu jednoduše řídit přístup na vybrané služby.
VLANama prostě člověk velmi jednoduše řídí přístup ke skupině zařízení. A celý přístup lze řídit buď na routeru přes iptables, nebo na L3 switchi přes ACL.
Spravuji síť v jednom penzionu a tam jedu i wifi 2x. Jedna vlan pro uživatele a zákazníky penzionu, druhá vlan pro kamery a třetí pro obsluhu (pda, kasy apod.). Opět nechci řešit zabezpečení kamer před obsluhou PDA a nechci řešit zabezpečení nějakých PDA a pofiderních kas před zákazníky a náhodnými návštěvníky.
Osobně v tom tedy nevidím žádný problém, jen samé výhody.
Ale přiznávám, že na malých pobočkách to zas tak moc neřeším (hlavně kvůli tomu, že je máme připojeny přes MPLS a všechny požadavky bychom nemohli vyřizovat sami a hned), jen na těch větších. Nicméně v plánuje to mít odděleno i na těch menších pobočkách (běžně 5-20 uživatelů).
Zdar Max
PS: tvé konkrétní prostředí s 15vlanama neznám, takže nevím, jaké a zda vůbec to má výhody

[pb.]

Aha, rozumím. Tady mi to dává smysl, včetně toho rozdělení přímo na switchi. Nedává mi to smysl ve výrobní firmě s deseti počítači. Přijde mi to tam trošku... overkill.

[pb.]

A zapomenul jsem zmínit ty tři Windows domény. Ty mi hlava doteď nepobrala

[Jendа]

Na mě je těch sítí trochu moc. Jaký je důvod rozdělit třeba tiskárny, kamery a mobily?

Tiskárny a kamery mívají výrobcem sto let nepodporovaný děravý firmware, ale k tiskárnám typicky přistupují skoro všichni, ke kamerám jenom nějaký bezpečák a šéf. Asi nechtějí, aby jim to někdo vyownoval. Docházkové zařízení, pokud je to třeba nějaká hrůza s desetiletými XP Embedded, na tom bude podobně.

Mobily jsou zase backdoornutý Android se Stagefrightem, do kterého si zaměstnanci nainstalují kdovíco.

[Jendа]

DontBreakDebian

No dobře, a myslíš, že přepsat kdovíjakou PHP aplikaci by bylo jednodušší?

Představ si, že tě přejede autobus a někdo po tobě takový server převezme - skočí pod vlak.

Hele, je dobrý, že to dal do /usr/local a že používá checkinstall. Alespoň to není takový ten můj postup „nasymlinkujte nějaké binárky z ~ do /usr/bin“.

[hypvofxy]

Dlouhou dobu mam v planu zridit si vlastni repo a nejak si naskriptovat trivialni vyrobu baliku (i.e. jediny Python skript => *.deb).

[podlesh]

Asi nejjednodušší způsob je fpm, s velkou přidanou hodnotou že dokáže dělat různé druhy balíčku.

Pokud chceš vyrábět balíček bez ruby, tak pozor na debuild - to je sice pěkná věc, ale pro maintanery distribučních balíčků. Úplně stačí dpkg-deb (a dokonce i kombinace tar + ar, ale pozor na pořadí souborů). To takové rpm, to je porod... zvlášť v případě pythonu, kerý je v rom světě považován za architecture-specific (kvůli .pyc).

[hypvofxy]

Pridano do bookmarku. Diky, zkouknu. Vypada to, ze by to mohlo resit presne, to co chci. Jeste jsem uvazoval nad necim na Java services, ale to si kdyztak udelam sam.

[hypvofxy]

*presne to, co chci

(spatne umistena carka)