Community-list

community-list@lists.vpsfree.cz

1077 discussions

CentOS 8 - stav
by filbar＠centrum.cz 24 Nov '19

24 Nov '19

Ahoj, jaký je stav CentOS 8, aby mohl běžet jako stabílní? Případně je nějaké TODO co by pro to bylo třeba udělat? Hledal jsem na VPSFree stránkách a nic se mi nepovedlo najít. Ahoj, Filip Bartmann

1 0

dotnet3 build nikdy nedoběhne
by Martin Urbanec 15 Nov '19

15 Nov '19

Ahoj, mám na VPS problém spočívající v tom, že se mi nedaří zbuildovat aplikace napsaná pro dotnet 3.0. Příkaz dotnet build nikdy nedoběhne. Zkoušel jsem to na testovacím stroji u jiného providera, kde vše funguje bez problémů. Vidím, že je u obou serverů poměrně zásadní rozdíl ve verzi kernelu, možná příčina? urbanecm@titanium ~ $ ssh root(a)77.93.202.76 uname -r Enter passphrase for key '/home/urbanecm/.ssh/id_rsa': 5.0.0-13-generic urbanecm@titanium ~ $ uname -r 3.16.6-042stab139.44 urbanecm@titanium ~ $ Na netu jsem reporty nenašel, ale třeba blbě hledám. Dík za pomoc, Martin

2 1

Xeon E3 do LGA1150
by Libor Boldan 04 Nov '19

04 Nov '19

Ahoj, omlouvam se za lehky offtopic, ale nevali se nam, nebo nekomu ze clenu na pracovisti starsi Xeon E3, ale do patice LGA1150 a take aby mel 8 Threadu? Ma to byt pokus o nahradu E3-1220 za neco vykonejsiho. Bezi na tom virtualy a je tam 32GB RAM. Dik Libor Boldan

2 1

mnoho spojení SYN_RECV - DDOS botnet?
by Petr Parolek 01 Nov '19

01 Nov '19

Ahoj, už několik dnů na mé VPS pozoruju mnoho spojení se stavem SYN_RECV viz: netstat -anp |grep 'SYN_RECV' | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -n 23 xxx.xxx.xxx.xxx 23 xxx.xxx.xxx.xxx ... okolo 20 IP adres. Mám se tím znepokojovat nebo je vše ok a vše by se mělo řešit na infrastruktuře? Díky moc za postřehy a rady Petr

10 14

Vývoj vpsAdminOS, NFS na stagingu, overlay2 driver pro Docker a další
by Jakub Skokan 29 Oct '19

29 Oct '19

Ahoj, (ENGLISH: see https://kb.vpsfree.org/manuals/vps/vpsadminos/storage for the most important news) Přináším zase nějaké nové informace o přechodu na vpsAdminOS a čemu jsme od posledního reportu v červnu věnovali. Píšu po dlouhé době, takže je to jaksi... delší. To nejdůležitější je na začátku. Aktuální stav ============= Ke spuštění produkčního nodu s vpsAdminOS nyní zbývá dořešit přístup k NFS. Dlouho jsme hledali nějaký funkční model pro přístup k nasboxu z OpenVZ a vpsAdminOS a to se nám teď snad podařilo, podrobněji viz níže. S následným přechodem OpenVZ -> vpsAdminOS to aktuálně vidíme tak, že přidáme jeden další produkční node s vpsAdminOS, na který budeme VPS ze stagingu individuálně přesouvat. IP adresy měnit nebudeme. Nové členy budeme umisťovat na nový systém, stávající VPS poběží nadále na OpenVZ. Kdo chce se bude moct na nový systém přesunout, ale v dohledné době k tomu nikoho tlačit nebudeme. NFS v produkci a na stagingu ============================ V posledním reportu [1] jsem naznačoval, jakým způsobem budeme řešit exporty a mounty datasetů na vpsAdminOS. Ačkoli by to fungovalo, mělo to jednu zásádní nevýhodu: jeden NAS dataset by nešel připojit najednou do OpenVZ a vpsAdminOS VPS, resp. jeden z těch dvou systémů by neměl přistup k datům. Dalo by se s tím žít, ale byla by to pro nás všechny zbytečná zátěž při migraci VPS. Zmiňoval jsem taky, že do kernelu 5.2 byla do NFS klienta přidána podpora pro user namespaces. Zkusili jsme tedy ve VPS povolit mountování NFS a ono to funguje. Na NFS server chodí ID uživatelů a skupin tak jak je vidí VPS, resp. user namespace, takže není problém sdílet data s VPS na OpenVZ. Znamená to však zásadní změnu v přístupu k nasboxu. Na OpenVZ to funguje tak, že si mount naklikáte ve vpsAdminu a ten ho připojí, ani vás nemusí zajímat jakým způsobem to funguje. Na vpsAdminOS to takto být nemůže. Aby na NFS server chodily správné UID/GID, je potřeba mountovat zevnitř VPS. Kernel si totiž pamatuje, v jakém user namespace mount vytvořite a podle toho se chová. Pro staging/vpsAdminOS se ve vpsAdminu nebudou nastavovat mounty ve VPS, ale exporty na NFS serveru. Nastavíte si, jaké VPS mají mít k danému datasetu přístup a vpsAdmin vám zobrazí adresu a cestu k exportu, který si z VPS sami mountnete. Ve vpsAdminu najdete ukázkový příkaz pro mount, záznam v /etc/fstab, nebo i systemd mount unit. Ve VPS samozřejmě musíte mít nainstalovány utility pro práci s NFS. Nově tak máte pod kontrolou jednak více možností u nastavení exportu (ro/rw per host, root_squash, sync, atd.) a taky si můžete zvolit libovolné nastavení mountu. Akorát nepoužívejte -oproto=udp, nefunguje to spolehlivě a budeme to vypínat. Problém zůstává se sdílením (sub)datasetů VPS. To zatím nebude možné, žádné ideální zatím řešení nemáme. Předpokládám, že v budoucnu si budete moct sdílet data mezi VPS tak, že si uvnitř spustíte NFS server. To se ještě uvidí, jak moc to bude hořet. Jedno z use-case, které tímto zaniká, je možnost opravy nestartující VPS tak, že si jeho disk připojíte do jiné VPS. Místo toho plánuju do vpsAdminu přidat možnost nechat VPS nastartovat z čisté šablony distribuce, ze které se do rozbitého systému dostanete podobně jako když nabootujete live systém. Toť tedy aktuální plán zprovoznění nasboxu na stagingu. Všechno už máme nasazeno, můžete to začít používat. A prosím hlásit na podporu když na něco narazíte. Abych to shrnul: - do OpenVZ VPS se datasety a snapshoty připojují tak jako doposud - na vpsAdminOS místo mountu z vpsAdminu vytvoříte export datasetu/ snapshotu a ten si z VPS mountnete sami - jeden dataset/snapshot může být exportován jen jednou, připojen kdekoli (i na OpenVZ) Více viz KB: https://kb.vpsfree.cz/navody/vps/vpsadminos/storage Nějaký čas to takto necháme běžet. Pokud nenarazíme na nějakou komplikaci, můžeme vpsAdminOS spustit na ostro. Budeme čekat minimálně na Linux 5.4, protože to bude LTS, na kterém budeme moci zůstat delší dobu. Storage driver Dockeru ====================== Hlavní problém dockeru na vpsAdminOS byla nefunkčnost pořádného storage driveru [3]. Doposud u nás fungoval jen VFS driver a ten je značně neefektivní. Při vytváření každé vrtsvy kontejneru totiž kopíruje data na disku sem a tam. Proto u nás byl docker pomalejší než jinde. TL;DR je, že se nám podařilo zprovoznit overlay2 driver díky tomu, že snajpa do ZFS dodělal podporu pro overlayfs. Cesta ale byla trnitá. Výchozím driverem v dockeru je overlay2 založený na overlayfs. Ten bohužel stále nefunguje nad čistým ZFS [4], protože kernel vyžaduje implementaci určitých flagů v renameat2(). Další problém je, že se ZFS pro kernel tváří jako "remote filesystem" a vyžaduje revalidaci dentries, což overlayfs nedělá. Docker obsahuje taky ZFS driver, ale ten nejde uvnitř VPS použít, protože ZFS nepodporuje user namespace a není jasné, jak by to vůbec mělo fungovat. Tzn. nemáme jak bezpečně předat dataset z hostitele do VPS. Nakonec by to asi ani nebyl dobrý nápad, ZFS je sice super když zrovna nepanikaří, ale přináší to i různé komplikace, které stačí že musíme řešit na hostiteli. Dalším z možných driverů je AUFS. Jedná se o předchůdce overlayfs, který obsahuje více funkcí, ale nikdy se do Linuxu nedostal. Zkoušeli jsme ho přidat do kernelu na stagingu, i tak ho docker stejně sám o sobě nevyužije, protože si myslí, že AUFS v user namespace nefunguje a nevyzkouší to. Když se docker opatchuje, s AUFS funguje a je to mnohem svižnější. Bohužel by to vyžadovalo instalaci dockeru z našich repozitářů, o které bychom se museli starat. Navíc je AUFS v dockeru označený za překonaný a je možné, že ho odstraní. Pak bychom si jej museli udržovat sami. Nakonec se nám povedlo přizpůsobit si ZFS tak, aby nad ním fungoval overlayfs. Máme na to pull request [4], začleněn zatím nebyl. Pokud si myslíte, že pak docker sám od sebe použije overlay2 driver a všechno bude super, tak jste na omylu. Samozřejmě mají v kódu natvrdo zapsáno [5], že na ZFS to nefunguje. Takže dockeru z kernelu lžeme a říkáme mu, že na ZFS neběží... a pak teda funguje. Hurá. Nasazeno už to máme několik týdnů a podle ohlasů jsou buildy kontejnerů mnohem rychlejší. Jediný zádrhel byl bug v našem overlayfs patchi, který rozbil účtování zabraného místa při přesouvání/mazání souborů. Zabrané místo nešlo uvolnit a postupně se kvůli tomu zaplňovaly kvóty datasetů VPS. Bylo to způsobeno tím, že jedna důležitá funkce byla volána z ASSERT makra, které je implementováno jen v debug buildech, takže s vypnutým debugem to nic nedělalo. Docker-in-Docker ================ Další chuťovka je docker v dockeru, používá se to např. na nějaké CI v gitlabu. U nás to samo od sebe nefunguje, protože se to při startu pokouší o mount -t securityfs, což ve VPS s user namespace nejde. Zatím se nám nepodařilo kernel upravit tak, aby to prošlo, ale pokud na to někdo narazíte, má to jednoduchý workaround, stačí přidat volume: docker run -v /sys/kernel/security:/sys/kernel/security ... osctl-exportfs ============== Na nasboxu nám dlouhodobě chybí možnost zjistit kdo a jak ho využívá v případě, že disky přestávají stíhat. Kernel 5.3 přináší podporu NFS serveru v network namespace a to nám přináší zajímavé možnosti. osctl-exportfs [2] je nástroj z vpsAdminOS pro vytváření malých kontejnerů pro NFS servery, kde každý server má vlastní IP adresu a sadu exportů. Funguje to tak, že když si ve vpsAdminu nastavíte export, spustí se vám dedikovaný NFS server. vpsAdmin pak bude schopen počítat přenesené data či sledovat využití jednotlivých NFS serverů. syslog namespace ================ Během prázdnin jsme do kernelu přidali syslog namespace, tzn. z VPS je číst log z kernelu, ala dmesg. Můžete tam vidět zprávy od OOM killeru, logy z iptables a další. Nastavení oom_score_adj ======================= Přidali jsme do kernelu výjimku, aby bylo možné ve VPS libovolně nastavovat /proc/<pid>/oom_score_adj. Můžete tak chránit důležité procesy před OOM killerem, např. sshd. Minimálně distribuce se systemd to využijí automaticky. Restrikce /sys ============== Část /sys je sdílená mezi hostitelem a všemi VPS, část se přizpůsobuje např. network namespace. Změnili jsme oprávnění citlivých adresářů tak, aby se k nim z VPS nedalo přistupovat. Může se stát, že s tím nějaký program bude mít problém, např. museli jsme trochu ustoupit libvirtu. Pokud narazíte na něco dalšího, tak se ozvěte. vpsfree-cz-configuration a monitoring ===================================== Během prázdnin jsem z velké části předělal konfiguraci [6] našich vpsAdminOS nodů a NixOS serverů/VPS. Konfigurace systému se teď definuje na jednom místě pro různé výstupy, jako netboot server a aktualizace systému na živo. V konfiguraci serveru je možné se odkazovat na adresy, služby a porty ostatních systémů v clusteru, což se hodí třeba na propojování služeb, přesné nastavení firewallu, nebo generování DNS. Máme taky nový monitoring, který automaticky hlídá všechny systémy, které jsou součástí konfigurace. Nový monitoring je postavený nad prometheusem, alertmanagerem a používáme taky centralizované logování přes graylog. Sledujeme teď více parametrů, které nám způsobovaly problémy. Řešil jsem to hlavně kvůli častým výpadkům při ZFS panics, které nás trápily od začátku prázdnin. Původní monitoring úplně selhával a o tom, že node přestal ve 4 ráno provádět diskové operace, jsme se dozvěděli až když se někdo z nás probudil. Aktuálně logy ze všech nodů zpracovává graylog a pokud dojde k ZFS panic, pošle o tom alert přes alertmanager. Do minuty tak máme SMS. Je zde ještě hodně co ladit, zejména doručování SMS různým lidem v různých časech, abychom se z toho nezbláznili. Na to jsem bohužel existující řešení zatím nenašel. Do budoucna bych taky chtěl členům zpřístupnit grafanu s daty z prometheuse jako náhradu muninu, ale těch parametrů k zobrazení je tam strašně moc a je potřeba tomu věnovat více času, který teď nemáme. Buildbot pro vpsAdminOS ======================= Už mnoho let toužíme po nějaké formě CI a zajišťování QA pro kontrolu aktualizací či nové funkcionality. Trochu to sice komplikuje fakt, že nemáme naprosto žádné testy, ale nenašli jsme ani žádnou technologii, nad kterou bychom to chtěli postavit. Teď jsem s tím trochu pohnul, repozitář vpsAdminOS hlída Buildbot a při změně ho automaticky sestavuje. Vypadá to celkem použitelně a postupem času bychom toho chtěli více. Už teď je to užitečné zejména pro plnění binarní cache, ze které lze stahovat naše buildy kernelu, ZFS, atd. Na NixOS se dá použít takto: nix = { binaryCaches = [ "https://cache.vpsadminos.org" ]; binaryCachePublicKeys = [ "cache.vpsadminos.org:wpIJlNZQIhS+0gFf1U3MC9sLZdLW3sh5qakOWGDoDrE=" ]; }; Unmounty snapshotů ve vpsAdminu =============================== Kdo jste do VPS připojovali snapshot, asi jste si všimli, že často nešel odpojit. Snapshoty do OpenVZ VPS se připojují tak, že se na backuperu snapshot naklonuje přes zfs clone a vytvořený filesystem se exportuje přes NFS. Na nodu se pak mountne do VPS. Při odpojování se nejdříve provede unmount ve VPS a potom se vpsAdmin pokouší odstranit naklonovaný snapshot na backuperu. No a tady to vázne. Z nějakého důvodu je buď mountpoint nebo dataset busy, takže se toho nedá zbavit. To mělo za následek, že operace odpojení snapshotu ve vpsAdminu selhávala a mount se vracel do původního stavu -- opět se připojil. Na podpoře jsem všem doporučoval mount "vypnout" (disable), vpsAdmin se ho pak pravidelně snaží odpojovat, až jednou uspěje. Bohužel než se takhle "zaseklý" dataset umoudří mohlo trvat několik dní nebo i týdnů. Nově se klony snapshotů mažou na pozadí a na mounty ve VPS to nemá vliv. Problémy nám to bude dělat stále, ale aspoň už ty mounty ve vpsAdminu nejsou vidět. Zamyšlení na konec ================== První commit ve vpsAdminOS vznikl před dvěma lety, 3. listopadu 2017. Asi nikdo nečekal, že s tím bude tolik práce. Pohledem zpět to tehdy ani fungovat nemohlo, hlavně protože až v posledních verzích kernelu se objevují funkce, bez kterých se neobejdeme, ala NFS klient v user namespace. Ani s nejnovějším kernelem, LXC, atd., však bez vlastních úprav nejde dělat systémové kontejnery na úrovni OpenVZ před 10 lety. Menší a větší patche máme v kernelu, ZFS, LXC i LXCFS a nemohli bychom bez nich fungovat. Pro provoz OpenVZ jsme naopak dlouho žádné vlastní úpravy nepotřebovali, nebyl problém používat to co bylo k dispozici. Poslední cca 4 roky už se však OpenVZ (Legacy) nevyvíjí a rozjet tam aktuální distribuce je čím dál tím obtížnější. O dnes moderních aplikačních kontejnerech ala docker ani nemluvím. Aby vůbec fungovalo Ubuntu 18.04, museli jsme si připravit vlastní kernel s chybějícím syscallem. Cesta je stále trnitá, ale už se na vpsAdminOS v produkci těšíme. [1] https://lists.vpsfree.cz/pipermail/community-list/2019-June/010062.html [2] https://man.vpsadminos.org/osctl-exportfs/man8/osctl-exportfs.8.html [3] https://docs.docker.com/storage/storagedriver/select-storage-driver/ [4] https://github.com/zfsonlinux/zfs/pull/9414 [5] https://github.com/docker/docker-ce/blob/master/components/engine/daemon/gr… [6] https://github.com/vpsfreecz/vpsfree-cz-configuration Jakub

1 0

Nelze aktualizovat sudo a mount device or resource busy
by zd nex 19 Oct '19

19 Oct '19

Ahojte, na některých vps mi nyní nejde aktualizovat sudo a mount.. Dpkg hlásí např. /usr/bin/sudo device or resource busy. Podobné u mountu. Ostatní aktualizace jedou, ale tohle tam nějak zůstává. Zkoušel jsem pohledat a nic moc kloudného jsem nenašel (možná restart pomůže). Stalo se vám to také? -- S pozdravem, Zdeněk Web: www.pripravto.cz

1 0

Dropbox synchronizace (Syncing paused)
by Jan Pleva (TheERROR) 11 Oct '19

11 Oct '19

Nezkousel jste nekdo rozchodit na VPS Dropbox? (dropboxd + python script na jeho cli-management (https://www.dropbox.com/install-linux <https://www.dropbox.com/install-linux>)). Me to kdysi davno fungovalo, dneska jsem to chtel oprasit a porad mi to psalo Syncing paused. No netrvalo dlouho a nasel jsem relevantni clanek a zaroven vzpomel neco o ukonceni podpory ext3 (a dalsich) a byl jsem hned doma. Nevite jak s tim pohnout a jestli by to vubec bylo mozne? Dropbox ocividne neni jedinna moznost, ale nabizela se pro muj usecase jako nejjednodussi. Abych ho priblizil - rozchodil jsem si Jekyll a chtel jsem jej pak nechat bezet v build rezimu nad Dropbox synchronizovanou slozkou, kde bych si hazel nejake .md poznamky ktere by jekyll pri zmene hned prechroustal do statickych html stranek a apache by se postaral opak o zbytek. Tim, ze dropbox pouzivam na backup poznamek i z Joplinu (MD poznamky) chtel jsem si selektivne tam vhodit i nejake "poznamky online". A na synchronizaci pres Dropbox jsem ted zmrzl. Napada vas nejaky zpusob, jak Dropbox rozchodit, eventualne nejaky workaround? Mozna nejake cli pro synch s GDrive? Cestou nejakeho dalsiho klienta, nebo manualni synchronizace (scp/rsync) mi prijde takova moc omezena.... Diky za rady! S pozdravem Jan Pleva

5 5

ZFS boot pool - zmenseni
by Pavel Slama 04 Oct '19

04 Oct '19

Cau, treba bude mit nekdo zkusenost.. Experimentuju s freebsd, resp. freenas kterej defaultne spolkne celej systemovej disk at je sebevetsi a upravovat instalacni skript aby umel pouzivat partitiony (jako bsd) nechtej. Resim jestli a jak ten boot pool co to vytvori pres celej disk zmensit. Rady na netu zni: 1) ze to nejde 2) zazalohovat soubory a udelat novej mensi pool 3) udelat snapshot a poslat ho do novyho mensiho poolu Nikde ale nepisou, jestli to jde udelat s poolem ze kteryho se bootuje a na kterym je nainstalovanej system (samozrejme ne za behu) ) a nic to nerozbije. Jestli jde nejak sikovne udelat novej pool tak, aby prevzal vsechny parametry toho puvodniho, jen mensi.. Nez propalim dalsi hodiny a dny - zkousim to tady, diky. /p

5 7

Upgrade Debianu Jessie 8 na Stretch 9 potřebuje ifconfig
by Jaroslav Týc 03 Oct '19

03 Oct '19

Ahoj, jen pro info, kdyby se na tom někdo zasekal jako já. Včera jsem se snažil upgradovat svůj vetchý Debian 8 Jessie na 9 Stretch (kvůli Dockeru, který při instalaci podle návodu <https://docs.docker.com/install/linux/docker-ce/debian/> suše oznámí, že nezná balíček docker-ce-cli, což je kódové označení pro "máš starej Debian, nahoď si aspoň Debian 9"). Upgrade šel podle plánu <https://linuxconfig.org/how-to-upgrade-debian-8-jessie-to-debian-9-stretch>, až na jednu drobnost a to že jsem se k virtuálu přes ssh už nepřipojil... Nejdřív jsem se točil v kolečku backup - try & crash - restore přes VPSAdmin <https://vpsadmin.vpsfree.cz/>, potom jsem si zprovoznil vpsfreectl <https://kb.vpsfree.cz/navody/vps/konzole> a tepve díky téhle konzoli, která přežije i problémy se sítí, jsem se ze screeny při bootování dozvěděl, že nenaběhl /networking/. Pak už stačilo dát /systemctl status networking.service/, což mi oznámilo, že nemám /ifconfig/. Google napráskal, že Debian 9 už /ifconfig/ v sobě v základu nemá <https://linuxconfig.org/how-to-install-missing-ifconfig-command-on-debian-l…>, protože je deprecated a místo něj mám používat utilitu /ip/, takže jsem ho ručně doinstaloval přes /apt-get install net-tools/ a otočil servisu /service networking restart/. Problem solved. Nevím, co přesně v mém Debianu vyžaduje ifconfig, asi to budu muset rozklíčovat, než se pustím do Debianu 10. Tož tak. Jarda

4 4

Pozor na upgrade libssl 1.1.1d na Debian 10
by Jakub Skokan 02 Oct '19

02 Oct '19

Ahoj, pokud aktualizujete libssl1.1 na OpenVZ VPS s Debian 10, bude potřeba restartovat VPS. Nějaká změna chování způsobila, že přestal fungovat RNG, což má vliv na služby, které openssl používají, např. openssh. Po restartu VPS se změní nafingovaná verze kernelu, podle které openssl pozná, že se má chovat jinak a RNG opět funguje... Jakub

2 2

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Community-list