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.