U MySQL je to tak že záleží zda si vyberete starši verzi 5.5 která je v main (a má tedy podporu přímo od Canonicalu) nebo novější 5.6 která je v universe (a má tedy podporu jen od komunity). Na universe a multiverse jsem úplně zapomněl protože je na serverech vůbec nemám aktivované, ty by se vlastně daly považovat za ty "balíčky nižší kategorie".
A na Lucid, kterému končí podpora teprve teď na konci dubna a obsahuje MySQL 5.1 jste zapomněl účelově? Ubuntu je vůči produktům Oracle úplně ve stejně debilní pozici jako zbytek světa. Oracle celému open source světu ukázalo prostředníček a bohužel ani Vaše nadšení z Ubuntu s tím nic nezmění...
Jediným dlouhodobým řešením je udělat to samé a přejít na MariaDB a jiné ekvivalenty jejich produktů (LMDB místo BerkeleyDB atd...).
Prechod od debianu na ubuntu lts mi ušetril zdravý rozum. Nanešťastie, len asi tretina serverov pod mojou správou mohla prejsť na ubuntu. S panikou som čakal na skončenie podpory debian squeeze a keď bolo ohlásené LTS, všetkým vo firme nám vyšli slzy dojatia.
dnes mi už na všetkých fyzických serveroch beží ubuntu 12.04 a virtuály (LXC) pod ním sú debian squeeze LTS a ubuntu. pôvodne to bolo všetko debian a linux-vserver.
od verzie LXC 1.0 s kernelom 3.13+ mozes prevadzkovat unprivileged LXC kontajnery, co znacne znizi pocet moznych vektorov ovladnutia hostitela, vid https://www.stgraber.org/2014/01/17/lxc-1-0-unprivileged-containers/
Mimochodem, píšeš, že's přešel na Ubuntu 12.04 - tam ale není LXC dost nový na to, aby šel provozovat pod obyčejným uživatelem, takže myslím platí ta moje zmínka o nebezpečnosti LXC.
V precise-backports vidím verzi 1.0.0-alfa1, ale Stéphane v tebou odkazovaném článku píše, že je potřeba verze 1.0-beta2.
Vysvětlení jsem napsal o příspěvek výše - jde o to, že ve starém Ubuntu ještě není dost nový LXC, aby šlo přemapovat uživatele, takže LXC není bezpečné.
Dnes v 14.04 LTS už je to možná bezpečné a LXC mohlo za ty dva roky zas o kousek vyzrát. Ale když končil Squeeze, tak jsem opravdu neviděl kam z linux-vserver bezpečně odejít.
prejsť som mohol tak, že som inú možnosť nemal.
stable debian nepodporoval nový hardvér, debian testing som použiť nemohol, teda musel som prejsť na ubuntu. linux-vserver sa nám predražoval, za port na nové kernely sme vývojárom vservera platili 1000 euro za verziu (500 za kernel, 500 za tools) a boli sme jediní testeri, čo sa odzrkadľovalo v stabilite.
kvm a xen boli nepoužiteľné, keďže sme potrebovali real time clock source (pre SIP konferenčné hovory). teda jediná voľba bola LXC a tvrdé pravidlá vo firewalloch, aby sa nám na servery nedostal nikto kto tam nepatrí.
aj keď sa mne nepodarilo nikdy ovládnuť hosta z kontajneru, v starších verziách lxc sa pomerne ľahko dal host zamrznúť alebo rebootovať. to bolo myslím vo verzii 0.7.5 alebo tak nejak. dodnes mi LXC v porovnaní s vserverom pripadá trochu nedokončené, ale v mnohých oblastiach je už ďaleko pred ním.
Hm, používám pořád linux-vserver, protože prostě nevidím, kam dál jít. Na LXC jsem zkoušel už třikrát přejít a vždycky jsem si v půlce řekl, že mi to za to nestojí a vrátil se k linux-vserver, kde není potřeba nic nastavovat, nic mapovat, všechno prostě normálně funguje jak v plné virtualizaci.
Za linux-vserver ve wheezy neplatím vývojářům nic, existuje nějaký dobrák, který to dělá zadarmo.
Přál bych si, aby LXC někdy dozrál do stavu, že bude fungovat bez nějakých čachrů.
Ten dobrák (dvaja dobráci) nežije z lásky, ale z peňazí. Preto sme im za porty platili.
Myslím že tvrdiť, že v linux-vserver všetko funguje a nič netreba nastavovať/mapovať, je dosť odvážne. vid great flower page http://www.nongnu.org/util-vserver/doc/conf/configuration.html
Faktom je, že polovica vecí v ich dokumentácii je už neplatná.
Aj keď mi v LXC chýbajú niektoré veci z util-vserver, celkovo som s LXC spokojnejší než som kedykoľvek bol s vserverom.
Už som aj pomaly zabudol na problémy s nefunkčnými rlimits, ulimits, max open file descriptors, atd.. tieto veci fungovali a nefungovali podľa zázračnej kombinácie verzií kernelu, util-vserver a vserver kernel modulu. Zmiznuté IP adresy z hosta ked vypnem vserver? Reverznuté barrier atribúty v stabilnom debiane pri 2.6.18 kerneli? Vserver mal počas rokov čo sme ho používali neuveriteľne veľa problémov. NIČ z takýchto amatérskych problémov som v LXC nezažil. Podpora v ubuntu je špičková, oveľa lepšia než v iných distribúciách.
Nikde nevidim zminku o OpenVZ, proc jste, kdo jste potreboval alternativu k vserveru, nezvazili to? OpenVZ je defakto 'upstream' projekt kontejnerove virtualizace pod Linuxem, spousta jeho vyvojaru pracuje na LXC technologiich druhoprioritne, protoze jsou zamestnani za praci na OpenVZ. OpenVZ tim padem bude jako projekt smysl davat do doby, nez bude veskera jeho funkcionalita mit adekvatni upstream nahrady. Zatim nema a tak OpenVZ bude jeste nejakou dobu existovat a mit podporu, ztrati ji v momente, kdy OpenVZ projekt prestane davat smysl.
OpenVZ jadro umi z principu rozchodit jakoukoliv soucasnou distribuci v CT0, protoze je potreba, aby zrovna tak chodila dobre v samotnych kontejnerech.
Je to RHEL6 jadro. To je neco o dost jineho, nez vanilla 2.6.32. Jak rikam, jede pod tim userspace ze vsech soucasnych distribuci, vcetne veci se systemd. Sice je obcas potreba synchronizovat aktualizace systemd v distrech jako Arch s pockanim na nejnovejsi vydani OpenVZ jadra, ale to mi prijde jako minimalni dan za funkcni a pouzitelne kontejnery. Dokud nebudou upstream.
kedysi dávno sme robili s virtuozzo, takže openvz som chvíľku zvažoval, ale nie je to vhodná alternatíva.
potreboval som, aby virtualizačná technológia podporovala kernely ktoré som ja potreboval a nie aby som ja musel používať kernely, ktoré podporuje virtualizačná technológia. pri linux-vserver som vzal štandardne podporovaný ubuntu kernel a len som ho opatchoval s linux-vserver patchom.
pri openvz, by som bol vždy nútený používať starší a/alebo vanilla kernel. navyše s vserver ľuďmi sme sa dohodli na normálnej cene za port na novší kernel. s openvz rusákmi sa to nedalo.
navyše, so starším kernelom som jednoducho nerozchodil nové servery. typický prípad: high density supermicro atom servery, kde sú IPMI + grafika + sieťovky v jednom SoC. alebo najnovšie intel sieťovky, kde sme museli ísť na bleeding edge kernel verzie len aby sme nemali packet loss pri NIC bondingu (failover, nie 802.3ad)
Doportovat drivery na vetsinu serveroveho HW neni do RHEL6 kernelu tezke. Uznavam, ze vanilla kernel je uz nekde jinde, hlavne co se tyce RCU v kernel core, ale serverovou funkcionalitu, aspon podle mych potreb, pokryva 100%. Doportovat jeden, dva, tri drivery a dopsat PCI IDs je to nejmensi :) Vyhodou je potom funkcni a hotova kontejnerova virtualizace.
99%, ne-li 100% problemu bylo zpusobene ZFS. Holt jsme uz ve velikosti, kdy musime nutne zacit resit svoje QA, protoze prirozene QA open source projektu jde jenom po urcitou hranici a dal si funkcnost musi uzivatel overit sam. Je to dan za to, ze si cele prostredi skladame sami a vytvarime nad tim svoje dalsi koncepty.
Zadny uceny z nebe nespadl a i u nas je videt ucici se proces. Co se tyce stability uz muze byt jenom lip, uz mame dostatecne znalosti se podobnym problemum v budoucnu vyhnout. Odladit to trvalo dyl, nez by se mi libilo a chapu, ze to mohlo na nekom nechat pachut, ze jsme snad totalni matlalove a hracickove, ale neni to tak. Jenom se to cele ucime za chodu bez velkeho tymu vyvojaru za zadkem ;)
Kontejnery jsme si vybrali jako smer, v oterem vidime vetsi budoucnost pro to, co hostujeme, nez v plne virtualizaci a ta predikce, se ted ukazuje, ze krasne vychazi.
Chtěl jsem jen říct, když už jsem v článku citován, že přechod prvního serveru z Debianu na Ubuntu 12.04 LTS mi způsobil šok, když po pár dnech provozu jsem přivolal bezpečnostní záplaty a přestala fungovat Samba (coredump). Na tohle jsem opravdu z Debianu nebyl zvyklý a trvalo mi nějakou dobu, než jsem si na tu "stabilitu" Ubuntu zvykl. A proto se za to stydím, nebyl to správný krok. Ale zas těch 5 let, kdy na to nemusím sahat, to je fakt výhra...
Na fyzicke servery davame vzdy Arch Linux. Dobre se spravuje, vydani se neresi, staci jen udrzovat politiku aktualizaci a jednou za dva az tri mesice restartovat. Pod nim pak bezi virtualizace, kde je nejcasteji Debian. Prechod na jinou verzi Debianu resime postupnym odmigrovavanim aplikaci na novy virtual s novym Debianem. Posledni servery mame jen s Dockerem, kde tenhle problem skoro neni. Odladime image a postupne ho nasazujeme. Je s tim nejaka prace, ale neni to skok do tmy jako pri prechodu mezi vydanimi.
Normální kernel. LTS dělá občas problémy, když zastará za zbytkem systému. Ne na všech hardwarových konfiguracích, ale objeví se to. Samozřejmě to nelze použít všude. Na serverech, kde běží nějaký kód, o který se nikdo nestará (web servery, kde někdo něco naprogramuje a to funguje bez zásahu až do umření), je to absolutně nevhodný. Stejně tak na databázi. Na virtualizaci nebo na Docker to je ale super. Systém je pořád aktuální, používá jen core repositář + pár balíčků z extra a community. V ignore je pouze kernel, který ale aktualizujeme ručně jednou za 2 až 3 měsíce, kdy také provádíme restart. Jedeme takhle tři roky a zatím jsme neměli žádný problém.