- Community-list - lists.vpsfree.cz

RHEL na VPSfree?
by Filip Bartmann 06 Feb '21

06 Feb '21

Podle článku - https://www.root.cz/clanky/red-hat-nabidne-enterprise-linux-zdarma-pro-mens… bude RHEL pro omezený počet instalaci free. Půjde nainstalovat i na VPSFree?

18 75

Routing IPv4 do KVM
by Jan Vaněk 18 Jan '21

18 Jan '21

Ahoj, aktuálně se pokouším na vpsAdminOS v rámci playgroundu otestovat routování public IPv4 adresy do KVM guesta. Podle dokumentace se zdá, že by to jít mělo a opravdu to v případě, že na guestovi běží linux (otestováno na Ubuntu) funguje. Potřeboval bych to ale rozchodit na Mikrotik CHR a tam se mi to nedaří. Na Ubuntu stačí z rozhraní odebrat IP v administraci, hodit venet0 do bridge s KVM guestem, nastavit na guestovi správně síť, dle dokumentace vpsAdminOS: ip address add 1.2.3.4/32 dev eth0 ip route add 255.255.255.254/32 dev eth0 ip route add default via 255.255.255.254 dev eth0 a jede to. Na Mikrotiku, po ohnutí ip příkazů do RouterOS to nefunguje, pravděpodobně je problém s tím, že Mikrotik neakceptuje v rámci "nexthop-lookup" routu přes interface, výchozí routa se tedy neaktivuje protože to v rámci "nexthop-lookup" nevidí na 255.255.255.254. Z dokumentace RouterOS : Routes with interface name as the value of gateway are not used for nexthop lookup. If route has both interface nexthops and active IP address nexthops, then interface nexthops are ignored a protože je routovací IP 255.255.255.254/32 nedá se to obejít ani tak, že bych dal Mikrotiku řekněme 255.255.255.253/30 a on by viděl na 255.255.255.254 jako připojenou routu a tudíž by to nejspíš fungovalo. Už mi tak nějak k tomu došly nápady, a mám pocit, že to je tak nějak "by-design", tak prosím kdyby někoho k tomu něco napadlo, budu vděčný. Případně kdyby někdo z kluků zodpovědných za vývoj/chod vpsAdminOS mohl potvrdit, že to má/nemá řešení. Díky.

2 3

Problém se SMTP z MS serverů
by Stanislav Kocanda 14 Jan '21

14 Jan '21

Ahoj všem, rád bych se zeptal, zda jste někdo nenarazili na podobný problém jako já. O co jde: Na jedné VPS už dlouho provozuju mailserver (Exim). Minulý týden jsem se konečně dostal k tomu, abych na této VPS upgradoval Debian na 10. Po pár peripetiích vše podstatné normálně funguje. Nicméně dneska jsem zjistil zvláštní věc - nedaří se na náš server doručovat poštu (tj. příchozí pošta k nám) ze serverů Microsoftu (*.outlook.com). U jiných velkých poskytovatelů jsem problém nezaznamenal. Scénář je vždy podobný: 2020-09-29 15:13:36 TLS error on connection from mail-eopbgr140088.outbound.protection.outlook.com (EUR01-VE1-obe.outbound.protection.outlook.com) [40.107.14.88]:55106 I=[83.167.228.96]:25 (recv): Error in the pull function. 2020-09-29 15:13:36 unexpected disconnection while reading SMTP command from mail-eopbgr140088.outbound.protection.outlook.com (EUR01-VE1-obe.outbound.protection.outlook.com) [40.107.14.88]:55106 I=[83.167.228.96]:25 D=5m 2020-09-29 15:13:37 TLS error on connection from mail-oln040092073035.outbound.protection.outlook.com (EUR04-HE1-obe.outbound.protection.outlook.com) [40.92.73.35]:31272 I=[83.167.228.96]:25 (recv): Error in the pull function. 2020-09-29 15:13:37 unexpected disconnection while reading SMTP command from mail-oln040092073035.outbound.protection.outlook.com (EUR04-HE1-obe.outbound.protection.outlook.com) [40.92.73.35]:31272 I=[83.167.228.96]:25 D=5m 2020-09-29 15:19:32 SMTP command timeout on TLS connection from mail-vi1eur05on2108.outbound.protection.outlook.com (EUR05-VI1-obe.outbound.protection.outlook.com) [40.107.21.108]:4447 I=[83.167.228.96]:25 2020-09-29 15:20:00 SMTP command timeout on TLS connection from mail-db8eur05on2067.outbound.protection.outlook.com (EUR05-DB8-obe.outbound.protection.outlook.com) [40.107.20.67]:5601 I=[83.167.228.96]:2 Tahle chyba nastává prakticky výhradně od toho upgradu, takže něco bude špatně na mé straně, ale za nic nemůžu přijít na to, v čem ten problém spočívá. Po dlouhém pátrání jsem našel zde [1] popis mého problému, ale vyjma zakázání starttls pro MS servery tam žádné dlouhodobě použitelné řešení není. Takové řešení se mi upřímně moc nelíbí a hlavně by mě taky zajímalo nějaké vysvětlení, v čem problém spočívá, protože to nemusí být záležitost jen MS serverů. Díky moc za jakékoliv odpovědi. Standa Links: ------ [1] https://blog.krogloth.de/exim-mail-server-with-microsoft-office-365-and-tls…

16 25

Re: [vpsFree.cz: community-list] vpsAdminOS - moduly pro FTP spojení
by Kamil Kukura 23 Nov '20

23 Nov '20

Aha, tak já myslel, že v případě vpsAdminOS virtualizace (vps-ka dříve jela na openvz) nejsou moduly takhle přímo dostupné. Na svém systému vidím: # ls -l /sbin/modprobe lrwxrwxrwx 1 root root 9 May 18 2014 /sbin/modprobe -> /bin/true Ale když si pustím Debian 9 na playgroundu, tak ty moduly normálně fungují. Takže sorry za zmatek, rozchodím si přístup k modulům také na produkční VPS. -- Kamil tel.: +420 910 128 153 > Zdar, > > vim, ze tuhle odpoved asi nebudes mit rad, ale neni jednodussi to zkusit, nez se ptat mailem v konfere 548mi lidi? :) > > Priste to prosim radsi nejdriv zkus a ptej se, az kdyz neco konkretniho nepojede ;)

2 1

vpsAdminOS - moduly pro FTP spojení
by Kamil Kukura 19 Nov '20

19 Nov '20

Zdar, vím že FTP je archaický protokol, nicméně je/bude nějaká možnost v případě vpsadminos používat modul "nf_conntrack_ftp" ? -- Kamil tel.: +420 910 128 153

2 1

Re: [vpsFree.cz: community-list] logování TCP spojení se jménem procesu ??
by Stepan Liska 13 Nov '20

13 Nov '20

FYI pro ty co zajímá jak to dopadlo: Tak jsem se zmýlil - ono to sice ve webové administraci WEDOSu vypadá že to je /64, ale ve skutečnosti jsou volitelné jenom poslední 2 byty, takže reálně mám /112, což jsem následně dohledal i v helpdesku. V nastavení je to síť /64, ale má jí víc zákazníků najednou, každý má ten /112 kousek. Tak proto jsem na spamlistu, opravdu to asi bude zlobivý soused. Ode mě opravdu dlouhodobě nic špatného neodchází, už kontroluju pomalu každé spojení. Nicméně protože evidentně nejsem první, tak WEDOS teď přiděluje nové rozsahy a ty už jsou /64 (tedy zase je to v nastavení /48 a jednotlivý server z toho má /64). Takže změním odesílací IP a je to. Díky moc všem za pomoc, Štěpán. Dne 11. 11. 20 v 17:23 Stepan Liska napsal(a): > WEDOS tvrdí, že mám celý /64. > > Dne 11. 11. 20 v 17:16 Václav Dušek napsal(a): >> CSS lists both IPv4 addresses (/32) and IPv6 addresses (/64) >> >> Máš celý rozsah /64 nebo jen jeho část? >> >> Že by zlobil "soused"? >> >> Dne 11.11.2020 v 17:04 Stepan Liska napsal(a): >>> Ahoj, >>> >>> prosím jestli by někdo nedokázal poradit. >>> >>> TL;DR: existuje nějaký způsob jak logovat odchozí spojení na >>> konkrétní porty i s PID či jménem procesu? A jakou máte zkušenost s >>> důvěryhodností dotazů na Spamhaus SBL ohledně IPv6 adres? >>> >>> >>> Long: >>> Řeším takovou hloupou věc - jeden server se mi dostává občas na >>> blacklist (Spamhaus SBLCSS), ale když se k tomu dostanu, tak už tam >>> zpravidla není (vypadá to, že tam visí vždy jen pár hodin, což i >>> podle popisu toho blacklistu asi je možné). Kromě toho je to server >>> kde je odchozího provozu naprosté minimum, takže jsem pomocí grepu v >>> podstatě schopen za poslední 3 dny projít všechny podezřelé adresy. >>> A nic. Začínám mít podezření, jestli tam není hacklé někde nějaké >>> PHP. Mám tam prakticky všude PHP-FPM a každý web tak má své UID a >>> PID a snad jsou i celkem stabilní (ty PIDy). Takže pokud bych byl >>> schopen ulovit spojení na porty 25,465,587, tak bych mohl vytrasovat >>> co se tam děje. Ale nějak netuším, zda je to vůbec v Linuxu možné? K >>> IPTables nic nemůžu najít a jediné co mě napadá je logovat každou >>> půlvteřinu ss -tlpn (zkouším to, ale moc to nefunguje, ta spojení >>> jsou zřejmě moc krátká). Ale ono to stejně vypadá, že případný objem >>> spamu je naprosto minimální, třeba jen 2x za den. Takže ideálně bych >>> potřeboval opravdu nějaké pravidlo do iptables co by mi to >>> zalogovalo včetně nějakého kontextu procesu. >>> >>> No a pak mě ještě napadá jedna možnost - a to že Spamhausu nějak >>> zlobí SBLCSS list na IPv6 adresy, protože to co se objevuje, je >>> jenom IPv6 adresa (IPv4 adresa toho stejného serveru tam snad nikdy >>> nebyla) a klidně se stane, že 30 minut poté co mi to zahlásilo že >>> tam jsme, tak tam zase nejsme. Prostě ty dotazy se občas chovají tak >>> nějak "náhodně". Dokonce se mi děje, že když to zkusím z commandline >>> pomocí dig, tak se tváří že nic, ale v tu samou chvíli přes web >>> (spamhaus.org) mi to vylistuje (a mám pocit že se to mi to už jednou >>> stalo i obráceně). Máte s tím někdo zkušenost (+, -)? >>> >>> Předem díky za každou radu, >>> Štěpán. >>> >>> >>> _______________________________________________ >>> Community-list mailing list >>> Community-list(a)lists.vpsfree.cz >>> http://lists.vpsfree.cz/listinfo/community-list >>> >> >

1 0

chyba v instalaci v ubuntu VM
by Richard Pinka 11 Nov '20

11 Nov '20

ahoj, snažím se updatovat virutální buntu, případně instalovat appku "tree" a dalšíl a háže to mně nepohcopitelnou hlášku .. má někdo prosím ponětí co a jak je nutno dělat a řešit ? hlasí to něco s zfsutils a zfs ..že bych já někdy používal zfs ? to si nevybavím teda.. Richard root@vps:~# sudo apt-get install tree Reading package lists... Done Building dependency tree Reading state information... Done tree is already the newest version (1.8.0-1). 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. 2 not fully installed or removed. After this operation, 0 B of additional disk space will be used. Do you want to continue? [Y/n] y Setting up zfsutils-linux (0.8.3-1ubuntu12.4) ... modprobe: FATAL: Module zfs not found in directory /lib/modules/5.9.0 zfs-import-scan.service is a disabled or a static unit, not starting it. zfs-import-scan.service is a disabled or a static unit, not starting it. Job for zfs-mount.service failed because the control process exited with error code. See "systemctl status zfs-mount.service" and "journalctl -xe" for details. invoke-rc.d: initscript zfs-mount, action "start" failed. ● zfs-mount.service - Mount ZFS filesystems Loaded: loaded (/lib/systemd/system/zfs-mount.service; enabled; vendor preset: enabled) Active: failed (Result: exit-code) since Mon 2020-11-09 21:38:55 UTC; 20ms ago Docs: man:zfs(8) Process: 4065169 ExecStart=/sbin/zfs mount -a (code=exited, status=1/FAILURE) Main PID: 4065169 (code=exited, status=1/FAILURE) Nov 09 21:38:55 vps systemd[1]: Starting Mount ZFS filesystems... Nov 09 21:38:55 vps zfs[4065169]: /dev/zfs and /proc/self/mounts are required. Nov 09 21:38:55 vps zfs[4065169]: Try running 'udevadm trigger' and 'mount -t proc proc /proc' as root. Nov 09 21:38:55 vps systemd[1]: zfs-mount.service: Main process exited, code=exited, status=1/FAILURE Nov 09 21:38:55 vps systemd[1]: zfs-mount.service: Failed with result 'exit-code'. Nov 09 21:38:55 vps systemd[1]: Failed to start Mount ZFS filesystems. dpkg: error processing package zfsutils-linux (--configure): installed zfsutils-linux package post-installation script subprocess returned error exit status 1 dpkg: dependency problems prevent configuration of zfs-zed: zfs-zed depends on zfsutils-linux (>= 0.8.3-1ubuntu12.4); however: Package zfsutils-linux is not configured yet. dpkg: error processing package zfs-zed (--configure): dependency problems - leaving unconfigured Errors were encountered while processing: zfsutils-linux zfs-zed E: Sub-process /usr/bin/dpkg returned an error code (1) root@vps:~# -- *Ing. Richard Pinka * *Projekční a inženýrská činnost,* *hodnocení nákladů životního cyklu budov a systémů TZB* *tel. +420 608 261 385 *

2 2

logování TCP spojení se jménem procesu ??
by Stepan Liska 11 Nov '20

11 Nov '20

Ahoj, prosím jestli by někdo nedokázal poradit. TL;DR: existuje nějaký způsob jak logovat odchozí spojení na konkrétní porty i s PID či jménem procesu? A jakou máte zkušenost s důvěryhodností dotazů na Spamhaus SBL ohledně IPv6 adres? Long: Řeším takovou hloupou věc - jeden server se mi dostává občas na blacklist (Spamhaus SBLCSS), ale když se k tomu dostanu, tak už tam zpravidla není (vypadá to, že tam visí vždy jen pár hodin, což i podle popisu toho blacklistu asi je možné). Kromě toho je to server kde je odchozího provozu naprosté minimum, takže jsem pomocí grepu v podstatě schopen za poslední 3 dny projít všechny podezřelé adresy. A nic. Začínám mít podezření, jestli tam není hacklé někde nějaké PHP. Mám tam prakticky všude PHP-FPM a každý web tak má své UID a PID a snad jsou i celkem stabilní (ty PIDy). Takže pokud bych byl schopen ulovit spojení na porty 25,465,587, tak bych mohl vytrasovat co se tam děje. Ale nějak netuším, zda je to vůbec v Linuxu možné? K IPTables nic nemůžu najít a jediné co mě napadá je logovat každou půlvteřinu ss -tlpn (zkouším to, ale moc to nefunguje, ta spojení jsou zřejmě moc krátká). Ale ono to stejně vypadá, že případný objem spamu je naprosto minimální, třeba jen 2x za den. Takže ideálně bych potřeboval opravdu nějaké pravidlo do iptables co by mi to zalogovalo včetně nějakého kontextu procesu. No a pak mě ještě napadá jedna možnost - a to že Spamhausu nějak zlobí SBLCSS list na IPv6 adresy, protože to co se objevuje, je jenom IPv6 adresa (IPv4 adresa toho stejného serveru tam snad nikdy nebyla) a klidně se stane, že 30 minut poté co mi to zahlásilo že tam jsme, tak tam zase nejsme. Prostě ty dotazy se občas chovají tak nějak "náhodně". Dokonce se mi děje, že když to zkusím z commandline pomocí dig, tak se tváří že nic, ale v tu samou chvíli přes web (spamhaus.org) mi to vylistuje (a mám pocit že se to mi to už jednou stalo i obráceně). Máte s tím někdo zkušenost (+, -)? Předem díky za každou radu, Štěpán.

2 2

Migrace Jessie -> Buster
by Vladislav Straka 27 Oct '20

27 Oct '20

Ahoj, potreboval bych udelat migraci z: vps 2.6.32-042stab141.42 #1 SMP Sat Nov 23 20:38:57 CET 2019 x86_64 GNU/Linux Debian GNU/Linux 8.6 (jessie) na: 1-vpsAdminOS SMP Tue Oct 13 14:07:42 UTC 2020 x86_64 GNU/Linux Debian GNU/Linux 10 (buster) Je v prostredi vpsfree nejake jednoducha moznost jak to udelat? Nebo budu muset postupovat podle nejakeho obecneho navodu? Z hlavy me napada udelat export instalovanych packages a zalohu /etc Nebo existuje nejaka mene bolestna cesta? Diky, Vladislav Straka

4 3

Re: [vpsFree.cz: community-list] OOM kill s dostatkem paměti
by Kamil Kukura 22 Oct '20

22 Oct '20

Vyzkoušel jsem a dokonce jsem ani nemusel dávat "daemon-reload", nějak to chytil automaticky (Debian 9.13). -- KamK > 21. 10. 2020 v 12:00, community-list-request(a)lists.vpsfree.cz: > > Send Community-list mailing list submissions to > community-list(a)lists.vpsfree.cz > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.vpsfree.cz/listinfo/community-list > or, via email, send a message with subject or body 'help' to > community-list-request(a)lists.vpsfree.cz > > You can reach the person managing the list at > community-list-owner(a)lists.vpsfree.cz > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Community-list digest..." > Today's Topics: > > 1. Re: OOM kill s dostatkem paměti (vudiq(a)vudiq.sk) > > Od: vudiq(a)vudiq.sk > Předmět: Re: [vpsFree.cz: community-list] OOM kill s dostatkem paměti > Datum: 20. října 2020 14:51:10 SELČ > Komu: "vpsFree.cz Community list" <community-list(a)lists.vpsfree.cz> > > > Ahoj, > > ďakujem za tipy, funguje. > > Ešte dodám, že pôvodný `/run/log/journal` mal permissions `rwxr-sr-x`, > tak som okrem > `mkdir -p /var/log/journal` > spravil ešte > `chmod 2755 /var/log/journal` > a potom > `systemctl daemon-reload` > > Využitie pamäte reportované vo vpsAdmine kleslo o cca. 400 MB. > > Tomáš > > > On 19.10.2020 15:56, Matěj Koudelka wrote: >> IMHO neni třeba otáčet vps, stačí systemctl daemon-reload >> Matěj Koudelka >> +420 604 266 933 >> On Mon, 19 Oct 2020 at 15:39, Pavel Snajdr <snajpa(a)snajpa.net> wrote: >>> Ahoj, >>> podle toho reportu jsi mel cca 600 MB v tmpfs, to je taky v RAM a >>> bohuzel se pocita jako 'shmem', takze to vubec neni zrejme, ze je to >>> vlastne tim... >>> "Problem" prameni z toho, ze pokud neexistuje /var/log/journal, >>> uklada >>> systemd logy do tmpfs pod /run/log/journal - a na to se da docela >>> rychle >>> narazit. >>> Resenim je vyrobit adresar /var/log/journal a otocit tu VPSku, bude >>> po >>> problemu. >>> Proc jsme si toho do ted nevsimli s OpenVZ, zjistuju, ale vypada to, >>> ze >>> uz mame hlavniho vinika, proc nam "nevysvetlitelne" ubyva RAMka s >>> pribyvajicim uptime na tech OpenVZ strojich... >>> V novych sablonach uz to Aither opravil: >> https://github.com/vpsfreecz/vpsadminos-image-build-scripts/commit/2872ff1b… >>> Ve stavajicich VPS to doresime skriptem behem nasledujicich par >>> desitek >>> hodin. >>> Ale ty VPSky, kterych se to tyka, zacnou logovat na spravne misto az >>> od >>> restartu (chystame v nasledujicich dnech update vsech vpsadminos >>> nodes >>> na Linux 5.9, takze explicitni restart, pokud s tim zrovna >>> nebojujete, >>> asi potreba neni). >>> /snajpa >>> On 2020-10-19 15:18, Petr Gregor wrote: >>>> Zdar, >>>> rád bych poprosil o pomoc s debugováním OOM killů v mém VM. >>> Měl >>>> jsem za to, že mám spoustu volného místa a proto mě kill >>>> překvapil (díky za nové reportování z vpsadminu!). VM >>> monitoruji >>>> zabbixem a ten tvrdí, že dostupné paměti je dost (špička na >>>> konci je kill) >>>> výstup z free -m vypadá takto: >>>> root@hostingf:~# free -m >>>> total used free shared >>> buff/cache >>>> available >>>> Mem: 1000 238 100 621 >>> 661 >>>> 761 >>>> Swap: 0 0 0 >>>> /proc/meminfo MemoryAvailable sedí se zabbixem a free: >>> "MemAvailable: >>>> 777548 kB" >>>> Trošku zarážející je, že "volné" paměti je pouze 100M. >>>> Rozhodující pro OOM je ale "dostupná" paměť, že? >>>> V příloze posílám výstup z dmesg náležící k OOM killu. >>>> Není mi jasné, proč OOM kill vůbec nastal. Součet všech rss >>> v >>>> dmesg reportu ani zdaleka nedosahuje 1G. Předpokládám, že mi >>>> nějak uniká něco podstatného, ale nevím moc co hledat. Budu >>> rád >>>> za každé nakopnutí. >>>> Gregy >>>> _______________________________________________ >>>> Community-list mailing list >>>> Community-list(a)lists.vpsfree.cz >>>> http://lists.vpsfree.cz/listinfo/community-list >>> _______________________________________________ >>> Community-list mailing list >>> Community-list(a)lists.vpsfree.cz >>> http://lists.vpsfree.cz/listinfo/community-list >> _______________________________________________ >> Community-list mailing list >> Community-list(a)lists.vpsfree.cz >> http://lists.vpsfree.cz/listinfo/community-list > > > > _______________________________________________ > Community-list mailing list > Community-list(a)lists.vpsfree.cz > http://lists.vpsfree.cz/listinfo/community-list

1 0

OOM kill s dostatkem paměti
by Petr Gregor 20 Oct '20

20 Oct '20

Zdar, rád bych poprosil o pomoc s debugováním OOM killů v mém VM. Měl jsem za to, že mám spoustu volného místa a proto mě kill překvapil (díky za nové reportování z vpsadminu!). VM monitoruji zabbixem a ten tvrdí, že dostupné paměti je dost (špička na konci je kill) [image: image.png] výstup z free -m vypadá takto: root@hostingf:~# free -m total used free shared buff/cache available Mem: 1000 238 100 621 661 761 Swap: 0 0 0 /proc/meminfo MemoryAvailable sedí se zabbixem a free: "MemAvailable: 777548 kB" Trošku zarážející je, že "volné" paměti je pouze 100M. Rozhodující pro OOM je ale "dostupná" paměť, že? V příloze posílám výstup z dmesg náležící k OOM killu. Není mi jasné, proč OOM kill vůbec nastal. Součet všech rss v dmesg reportu ani zdaleka nedosahuje 1G. Předpokládám, že mi nějak uniká něco podstatného, ale nevím moc co hledat. Budu rád za každé nakopnutí. Gregy

4 4

nginx padá
by petr.bolf＠taborpolana.cz 15 Oct '20

15 Oct '20

zdravím, nevěděl by někdo s čím může být problém - asi někde v konfiguraci serverů pro nginx. sudo nginx -t nginx: the configuration file /etc/nginx/nginx.conf syntax is ok nginx: configuration file /etc/nginx/nginx.conf test is successful sudo systemctl start nginx.service sudo systemctl status nginx.service ● nginx.service - A high performance web server and a reverse proxy server Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: en Active: active (running) since Tue 2020-10-13 14:49:08 CEST; 6min ago Docs: man:nginx(8) Process: 16277 ExecStartPre=/usr/sbin/nginx -t -q -g daemon on; master_process Process: 16278 ExecStart=/usr/sbin/nginx -g daemon on; master_process on; (cod Main PID: 16279 (nginx) Memory: 21.0M CGroup: /system.slice/nginx.service ├─16279 nginx: master process /usr/sbin/nginx -g daemon on; master_pr ├─16280 nginx: worker process ├─16281 nginx: worker process ├─16282 nginx: worker process ├─16283 nginx: worker process ├─16284 nginx: worker process ├─16285 nginx: worker process ├─16286 nginx: worker process └─16287 nginx: worker process jenže po nějakém čase server spadne. sudo tail -f /var/log/nginx/error.log 2020/10/13 02:39:01 [emerg] 7506#7506: bind() to [::]:443 failed (98: Address already in use) 2020/10/13 02:39:01 [emerg] 7506#7506: bind() to 0.0.0.0:443 failed (98: Address already in use) 2020/10/13 02:39:01 [emerg] 7506#7506: bind() to 0.0.0.0:80 failed (98: Address already in use) 2020/10/13 02:39:01 [emerg] 7506#7506: bind() to [::]:80 failed (98: Address already in use) 2020/10/13 02:39:01 [emerg] 7506#7506: bind() to [::]:443 failed (98: Address already in use) 2020/10/13 02:39:01 [emerg] 7506#7506: bind() to 0.0.0.0:443 failed (98: Address already in use) 2020/10/13 02:39:01 [emerg] 7506#7506: bind() to 0.0.0.0:80 failed (98: Address already in use) 2020/10/13 02:39:01 [emerg] 7506#7506: bind() to [::]:80 failed (98: Address already in use) 2020/10/13 02:39:01 [emerg] 7506#7506: still could not bind() 2020/10/13 02:39:04 [alert] 7357#7357: unlink() "/run/nginx.pid" failed (2: No such file or directory) a když je spadlý tak sudo systemctl status nginx.service [sudo] password for pruga: ● nginx.service - A high performance web server and a reverse proxy server Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: en Active: failed (Result: exit-code) since Tue 2020-10-13 02:39:04 CEST; 11h ag Docs: man:nginx(8) Process: 7501 ExecStartPre=/usr/sbin/nginx -t -q -g daemon on; master_process Process: 7506 ExecStart=/usr/sbin/nginx -g daemon on; master_process on; (code Oct 13 02:39:03 domogled nginx[7506]: nginx: [emerg] bind() to 0.0.0.0:80 failed Oct 13 02:39:03 domogled nginx[7506]: nginx: [emerg] bind() to [::]:80 failed (9 Oct 13 02:39:03 domogled nginx[7506]: nginx: [emerg] bind() to [::]:443 failed ( Oct 13 02:39:03 domogled nginx[7506]: nginx: [emerg] bind() to 0.0.0.0:443 faile Oct 13 02:39:03 domogled nginx[7506]: nginx: [emerg] bind() to 0.0.0.0:80 failed Oct 13 02:39:03 domogled nginx[7506]: nginx: [emerg] bind() to [::]:80 failed (9 Oct 13 02:39:04 domogled nginx[7506]: nginx: [emerg] still could not bind() Oct 13 02:39:04 domogled systemd[1]: nginx.service: Control process exited, code Oct 13 02:39:04 domogled systemd[1]: nginx.service: Failed with result 'exit-cod Oct 13 02:39:04 domogled systemd[1]: Failed to start A high performance web serv přičemž sudo systemctl start nginx.service ho zase nastartuje a zase chvilu běží. díky Petr Bolf

6 9

Novinky ve vpsAdminu: výchozí VPS features a OOM reporty / News in vpsAdmin: default VPS features and OOM reports
by Jakub Skokan 13 Oct '20

13 Oct '20

Ahoj, (English below) z vpsAdminu byla odstraněna VPS feature pro Docker. Zpočátku to nastavovalo speciální seccomp profil, který umožňoval běh Dockeru, ale už dlouho to není potřeba a VPS feature tam tak zbyl jen pro "dobrý pocit" a kdyby náhodou. Pro instalaci Dockeru není potřeba dělat nic navíc, viz https://kb.vpsfree.cz/navody/vps/vpsadminos/docker Dále jsem se snažil trochu omezit specifika našeho prostředí a usnadnit konfiguraci novým členům. V nově vytvořených VPS se aktivují features pro běh FUSE, KVM a TUN/TAP. Na OpenVZ pak iptables a bridge. Features pro PPP a LXC nesting zůstavají vypnuty. Do šablony pro Ubuntu a Debian jsem přidal balíčky fuse a squashfuse, takže třeba instalace snap-u už taky funguje sama od sebe. Na nodech s vpsAdminOS nás občas trápí VPS s nedostatkem paměti. Některé takové VPS jsou schopny ovlivnit výkon celého nodu, i když je jinak volné paměti dostatek. Rozhodli jsme se sledovat aktivitu OOM killeru a upozorňovat členy na to, že jim dochází paměť. Většina o tom totiž vůbec neví a tak s tím nikdy ani nic neudělá. Pro zajímavost, aktuálně máme 8 nodů s vpsAdminOS a od čtvrtka jsme zaznamenali ~4756 OOM killů z 38 VPS. Kdo používáte vlastní DNS resolvery -- ve vpsAdminu bylo na výběr z našich DNS resolverů, popř. DNS resolver na localhostu. S nastavenou volbou se při každém startu VPS přepsal /etc/resolv.conf a nebylo možné si to jednoduše udělat po svém. Nyní si můžete ve vpsAdminu vypnout správu /etc/resolv.conf, podobně jako funguje manuální správá hostname. Ve vpsAdminu jsou nově vidět instrukce pro zaplacení členského přispěvku -- odkaz "Payment instructions" v profilu člena. Jsou tam i QR kódy, tak jako v emailových upomínkách. Doteď se muselo čekat právě na upomínku, nebo hledat platební údaje v KB. Pro začátečníky v detailu VPS přibyl formulář s pokyny pro připojení na SSH. Konfigurace sítě se u VPS na vpsAdminOS kvůli novým možnostem trochu zkomplikovala a chtěl jsem tak nováčkům pomoci se připojit. Pokud vás napadá, co dalšího je u nás zbytečně složité, napište nebo založte issue: https://github.com/vpsfreecz/vpsadmin/issues ENGLISH: VPS features for Docker was removed from vpsAdmin. Originally it was needed to set a custom seccomp profile in order to run Docker inside a VPS, but for a long time now it is not needed and toggling it had no effect. Docker can be run without any further configuration, see https://kb.vpsfree.cz/navody/vps/vpsadminos/docker I was trying to reduce the particularities of our infrastructure and simplify configuration for new members. Thus, new VPS are created with features for FUSE, KVM and TUN/TAP enabled by default. iptables and bridge features are enabled on OpenVZ nodes. Features for PPP and LXC nesting remain disabled by default. VPS template for Ubuntu and Debian now contains packages fuse and squashfuse, which makes it possible to install snap without any extra steps. Nodes with vpsAdminOS sometimes suffer from VPS that are running out of memory. In some circumstances such VPS can have an impact on the performance of the whole node, even if there's enough of free memory left. Many people don't even know that the OOM killer is killing processes inside their VPS, so we decided to monitor its activity and notify members. At this moment, we have 8 vpsAdminOS nodes and since Thursday we've detected ~4756 OOM kills from 38 VPS. To those who use or want to use their own DNS resolvers, until now vpsAdmin offered a choice between DNS resolvers hosted by us and localhost. On each VPS start, /etc/resolv.conf was overwritten with this setting. This made it hard to have custom nameservers set. It's now possible to disable DNS resolver management in vpsAdmin, just like it works for hostnames. Payment instructions are now available in vpsAdmin in member profile, including QR codes just like in the mail notification. Until now it was necessary to either wait for the mail notification to arrive or search for payment info in KB. There's a new form in VPS details describing how to connect to SSH for beginners. vpsAdminOS brought us new possibilities in network configuration and it made it less obvious as to which address you could connect to with SSH, so hopefully it will now be clearer for newcomers. If you can think of other things that are overly complicated and could be simplified, feel free to write us or file an issue at: https://github.com/vpsfreecz/vpsadmin/issues Jakub

4 5

Tip na dobrou SaaS smlouvu?
by Ladislav Nesnera 07 Oct '20

07 Oct '20

Ahoj V rámci spolku Otevřených měst začínáme provozovat/nabízet některé věci jako SaaS. Měl byste někdo tip na dobrou smlouvu? (Myslím jako nepřepísknuté závazky, minimalizmu délkou textu, bez zbytečných právních divočin, ..) Předem dík ;?

1 0

Webhosting panel
by Martin Koutecký 01 Oct '20

01 Oct '20

Ahoj, chci se zeptat na vaše zkušenosti, než do něčeho sám skočím. Mám VPS, kde hostuju pár webů (Apache+MySQL+FTP), pár emailů, mám tam svůj nextcloud a pár dalších věcí. Na konfiguraci toho www+sql+ftp+imap+smtp jsem používal panel, který se mezitím stal neudržovaným a neupgradeovatelným. Věci kolem emailu mi přijdou jako černá magie a nestíhám sledovat novinky. Chci založit nový server a postupně převést všechny služby na něj. Ale zároveň bych pořád stál o panel se srozumitelným rozhraním a s dobrou podporou. Pro mail se mi líbí mailcow, pár lidí ho tady doporučovalo - jaké máte zkušenosti, kladné či záporné? Pro weby je to složitější, chtěl bych: * aby panel automaticky podporoval letsencrypt. Ale bude to spolupracovat s mailcow, který také získává certifikáty přes letsencrypt? * myslím, že pořád chci Apache, protože mám nějaké weby, co používají .htaccess. * nevím, jestli chci apache + php-fpm nebo apache + mod_php nebo .. ? Je apache + php-fpm současný state of the art? To mě vede k pár kandidátům: * hestiacp (https://hestiacp.com/) * froxlor (https://froxlor.org/) * ispconfig (https://www.ispconfig.org/) HestiaCP podle všeho podporuje vše, co chci, navíc weby, které nepotřebují htaccess nebo jiným způsobem apache, můžou běžet pod nginx (rychleji?). Když nepotřebuju email a DNS, tak by mělo stačit vypnout služby, které je poskytují (bind, exim, postfix, clamav, ...). Froxlor je asi OK, ale vypadá, že ho aktivně vyvíjí hlavně jeden člověk... ISPConfig vypadá, jako že ho používá hodně lidí, ale vlastně nevím, jestli/jak vypnout email, jestli podporuje letsencrypt, atd. Jaké máte zkušenosti s webhosting panely? S kombinováním jednoho panelu pro weby (www+ftp+mysql) a druhého pro email (smtp+imap+antispam)? Nebo se mám vykašlat na mailcow a spravovat email pomocí hestiacp / ispconfig / ...? Atd. Díky, Martin Koutecký

7 6

Peering Master Internet<->ČD-Telematika
by Radek Zajíc 11 Sep '20

11 Sep '20

Ahoj, Zdá se, že kluci z Master Internetu ženou provoz do sítě ČD-Telematiky přes Brno (Cejl) a Bratislavu (NIX.sk): # mtr -w -b -c5 -4 78.156.46.14 Start: 2020-09-11T12:06:37+0000 HOST: free Loss% Snt Last Avg Best Wrst StDev 1.|-- 172.16.251.2 0.0% 5 0.1 0.1 0.1 0.2 0.0 2.|-- 172.16.250.1 0.0% 5 0.3 0.5 0.3 1.0 0.3 3.|-- ??? 100.0 5 0.0 0.0 0.0 0.0 0.0 4.|-- vl129.cr2.c16.127.cecolo.prg.masterinter.net (81.31.40.101) 0.0% 5 69.7 14.2 0.2 69.7 31.0 5.|-- vl1385.cr3.r3-1-4.dc3.cejl.brq.masterinter.net (83.167.254.155) 0.0% 5 3.6 3.7 3.6 3.9 0.1 6.|-- nixsk2.cdt.cz (194.30.187.100) 0.0% 5 7.7 7.6 7.6 7.7 0.0 7.|-- 81.19.33.29 0.0% 5 7.7 7.7 7.7 7.8 0.0 8.|-- 89.203.220.126 0.0% 5 8.4 9.6 8.4 14.2 2.6 9.|-- ??? 100.0 5 0.0 0.0 0.0 0.0 0.0 10.|-- 78.156.46.14 0.0% 5 9.8 9.5 8.9 10.2 0.5 Ze sítě ČD-T do Masteru to teče správně přes uzel NIX.cz v Praze: # mtr -w -b -c5 -4 free.v.pytli.cz Start: 2020-09-11T14:06:04+0200 HOST: turris Loss% Snt Last Avg Best Wrst StDev 1.|-- 78.156.46.1 (78.156.46.1) 0.0% 5 0.9 0.8 0.5 1.0 0.2 2.|-- 192.168.0.1 (192.168.0.1) 0.0% 5 11.7 3.6 1.4 11.7 4.5 3.|-- 89.203.220.125 (89.203.220.125) 0.0% 5 2.3 2.0 1.6 2.4 0.4 4.|-- ons2.cd-t.cz (81.19.33.34) 0.0% 5 2.0 2.2 1.6 2.8 0.5 5.|-- praha-gts-nix2-85.masterinter.net (91.210.16.85) 0.0% 5 9.3 9.6 9.3 10.0 0.3 6.|-- vl1388.cr2.c16.127.cecolo.prg.masterinter.net (83.167.254.148) 0.0% 5 9.5 9.8 9.4 10.8 0.6 7.|-- vpsfree-vl129.cr2.c16.127.cecolo.prg.masterinter.net (81.31.40.102) 0.0% 5 9.7 9.6 8.9 10.0 0.4 8.|-- 83.167.228.132 (83.167.228.132) 0.0% 5 9.9 9.5 9.0 9.9 0.4 9.|-- ??? 100.0 5 0.0 0.0 0.0 0.0 0.0 10.|-- free.v.pytli.cz (83.167.228.95) 0.0% 5 9.3 9.8 9.3 10.6 0.6 Dá se s tím něco udělat? Komu problém nahlásit? Současný routing je, řekněme, suboptimální. :-) Díky Radek

2 1

Sprava pameti na vpsAdminOS
by Pavel Snajdr 24 Aug '20

24 Aug '20

Ahojte, sliboval jsem (vetsinou off-list), ze shnu pak resenici s pameti na vpsAdminOS, tak tady to je :) Kdyz chce programator dneska z aplikace pracovat s velkym souborem, je docela rozsirenym pristupem, si takovy soubor namapovat do pameti pomoci mmap(2) syscallu. To zpusobi, ze se soubor ocitne ve virtualnim pametovem prostoru procesu, tj. ten program si pak muze sahat do toho souboru prostym pristupovanim do pameti (nabizi se teda snadny ukladani napr. Cckovych structu do souboru, pristup pres pointerovou aritmetiku, atd.). Linux cachuje takovy napamovany soubor po strankach, protoze samotnou pamet spravuje po strankach (1 stranka pameti je na x64 velka 4 kB, huge pages jsou potom dalsi extra story na jindy...). Jakmile aplikace chce precist nejaka data, Linux na pozadi, pokud uz to neudelal, pro ta data alokuje stranku fyzicke pameti, aby ta data mela realne, kde sedet, precte je do te stranky z disku (nebo kde ten soubor je) a pak tu stranku namapuje do prislusneho mista virtualniho pametoveho prostoru naseho procesu, ktery ta data cte. Jadro vede mapovane stranky v evidenci pomoci LRU listu, coz je datova struktura, seznam, ktery se vyznacuje tim, ze vede v evidenci, ktera polozka byla pouzita naposled (tak, ze se meni pri jejim pouziti jeji poradi na zacatek seznamu). Kdyz vsechno funguje jak ma, v realne fyzicke pameti jsou pouzivana ctena data a jeste nezapsane "pospinene" (dirty) stranky, do kterych se psalo, tj. je u nich naplanovano, aby se co nejrychleji dostaly na disk (pokud teda cely soubor nebyl otevreny s flagem O_SYNC, nebo podobne, co by vynutilo kazdou zmenu zapsat na disk ihned, nez Linux vrati kontrolu aplikaci pri tom zapisu do mapovaneho souboru; to neni tak caste a to je nam ted "jedno"). Zapis je nastesti vyreseny dobre, Linux ma na to mechanismus, kteremu rika "writeback throttle"; kdyz detekuje, ze se zacina RAM plnit vic, nez je zdravo, zacne aplikaci ty zapisujici pristupy adekvatne zpomalovat. Tohle "impedancni prizpusobeni" funguje vcelku dobre, navic funguje dostatecne dobre i pod memory cgroup. Memory cgroup je mechanismus, kterym omezujeme pridelenou pamet kontejnerum pod Linuxem - je to volitelna sada dalsich pocitadel vyuziti pameti, nad zakladni systemove, plus vydeleni ukazatelu na LRU, writeback a dalsi cache, aby se dalo pekne vest takovehle seznamy stranek v oddelene, mimojine aby bylo jasne, co komu patri, kdyz dojde cas tu pamet jednou odklidit. Ale taky, aby se dalo hlidat maximalni vyuziti pameti na ruzne caches - zdaleka nejen - kvuli prave mapovanym souborum. Potud vsechno dobre. To nam tak system nabehne, pospousti se na nem stovka VPSek, vsechny aplikace se krasne rozbehnou, nektere si namapujou soubory, nektere do nich vesele zapisuji data... System muze bezet klidne mesice bez problemu, vsechno stiha, v pohode. Ty seznamy jsou bezne docela kratke, takze sbirka jadernych threadu "kswapd" je na pozadi pekne stiha prochazet a odklizet, jak se postupne nektere memory cgroupy dostavaji s pameti do uzkych. Koneckoncu, 4 GB RAM (na jeden kontejner) prelozeno na 4 kB stranky znamena teoretickou maximalni delku jednoho seznamu 1M polozek. To se na 2+ gigahertzovych CPU preci stihne projit rychle, ze. No a pak se stane, ze po treba dvou mesicich behu systemu najednou zoufaly clen pise, ze mu v kontejneru dochazi pamet, pritom at pocita, jak pocita, nemuze se dopocitat, ze by to zabiraly aplikace - je videt, ze je to tim, ze caches nechteji odcouvavat. Hm, docela spatenka, jak to mame opravit, kdyz to trva tak dlouho, nez se problem projevi? :-D Tady nekde bych mel podotknout, ze abych byl schopny to takhle pekne vysvetlit, musel jsem doprojit celou cestu do vyresena, takze ted se to jevi zpetne jako trivka, ale nez jsem prisel na to, z ktere strany ten problem pujde aspon nejak resit... Kdyz se clovek na takovy trpici system prihlasi, vidi tam zpravidla kswapd0 na 100% a kdyz ma ta masina dva fyzicke CPU, tak tam vidi vetsinou i kswapd1 v tom samem stavu. V dmesgu jsou videt out of memory hlasky z jednotlivych kontejneru, jak narazeji na neodkliditelne caches a jadro zoufale zabiji stare procesy, aby udelalo misto pro dalsi. V tech OOM hlaskach je videt pokazde i stack trace, odkud ta OOM udalost z jadra prisla - vetsina z nich byla vyvolana kvuli cteni do mmaped souboru, coz se pozna tak, ze v tom stacku jsou videt funkce pridavajici LRU stranky na seznam te memory cgroupe. Tak si rikam, hm, to ma preci snadne reseni, nebudeme uctovat mapovanou pamet do memory cgroup clenu, ale nechame ji v root memory cgroup... Okay, to by mohlo fungovat, ze? ..a zase, kswapd0/1 na 100%... To uz jsem se zacal seriozneji zajimat, co se to vlastne deje, co delaji tak dlouho a jak to cele funguje, kdyz to neslo smaznout "izy hackem". Napad to byl dobry, fungoval by, nebyt mensi drobnosti: kswapd, kdyz odklizeji caches na pozadi, prohledavaji memory cgroupy stylem "dej mi takovou, ktera zere nejvic a tu odklidime, kdyz to nebude stacit, pujdem na dalsi". Tj. pokud se objevi jedna cgroup, ktera je vetsi a ma toho vzdycky vic k odklizeni, muze se vzdycky kswapd zahojit na ni a k dalsim se ani nedostat. Jedine, kdy se odklizi pamet uplne primo z te memory cgroupy, je tzv. "direct reclaim", cesta kodu primo v momente, kdy je potreba alokovat - ale v tu chvili neni tolik casu na uklizeni, tak se jadro zas tak nesnazi a nekdy to muze vzdat predcasne a rict, ze pamet nenaslo a vyvola OOM situaci v postizene memory cgroupe. Hmm... okay, takhle by to neslo, tak zkusme mmaped pamet neuctovat cgroupam vubec a nechme ji v zakladnich systemovych seznamech... A po trochu zapaseni, bo se v jadre s memory cgroup nepocita, ze by nahodou mmaped pamet nebyla uctovana zadne memory cgroupe, je vyreseno, odchod na parek! ...do chvile, nez tim posleme celou masinu out-of-memory a OOM chyby zacnou prichazet odkudkoliv, ne jen z mmaped readu odzpod z mem-cgroup... Totiz kdyz byly mmaped soubory uctovany na jeden seznam, ktery neni v memory cgroupe, myslelo si jadro, ze ma hodne volnou ruku v tom, co si muze dovolit nechat nacachovane - ale v tom je potom mensi caveat se ZFS... postupny nahodny random access pattern k datum mmaped souboru nadela z ARC slab caches fragmentovane reseto, jeste kdyz se drzi ty kousky z tech puvodne nactenych dat pri zivote "pripinovanim" na jeden velky seznam, ktery nema duvod couvat, protoze host ma preci vsechnu pamet k dispozici bez limitu :D No pak a chudaci kswapd, kdyz si s tim bordelem maji nejak poradit a odklidit to, *obzvlast* kdyz jsou jen dva a kdyz pod nima mame (konecne spravne nastavene se spravnym ashiftem) NVMe pole... na te staging node (nyni node1.stg) se tak darilo zaplnit RAM az skoro do mrtva. Takze co s tim? :) Snadna reseni dosla, bude potreba odklizet ty seznamy per-limitovana-memory-cgroup. Na nekolik iteraci jsem nakonec dospel k patchi, ktery spusti per-NUMA-node "ksoftlimd" thready, pro kazdou memory cgroupu, ktera ma nastaveny soft_limit. Ksoftlimd pak dela presne toto - prochazi seznamy svoji memory cgroupy a drzi si je okolo soft_limitu. Kswapd maji o praci s memory cgroupama min, pokud je jadro nastavene v rezimu, ze ma ksoftlimd poustet automaticky (da se tez spoustet jen rucne). My jsme zatim defaultne zvolili soft_limit jako watermark, nad ktery se ma ksoftlimd snazit vic odklizet, nastavujeme ho na 80% pameti kontejneru - ale do budoucna mozna tohle jeste predelam na nejakou vetsi automatiku, podle toho, jak kde se ukazou pripadne nedostatky. Tedy, vysledna situace je, ze pokud aplikace zerou min, jak 80% pameti, ale je co drzet v RAM jako cache, bude mit kontejner vyuzito okolo tech 80% - bude to videt normalne jako aplikacni pamet a zbytek jako caches. Uz by se nemelo stat, ze vyuziti stoupne az ke 100% kvuli caches a ze dojde k OOM a zabijeni procesu. Zaverem bych jeste zminil ty patche: Pokus mmaped soubory nauctovat root mem cgroupe: https://github.com/vpsfreecz/linux/commit/d42232f89795 Pokus mmaped soubory mem cgroupam neuctovat vubec (popis commitu je blbe a celkove je nedocisteny, nebyl jsem s tim spokojeny a nechtel jsem tim travit vic casu, radsi jsem koumal, co dal, at the time...) -> https://github.com/vpsfreecz/linux/commit/c10ae4a7ef95 A finalne, aktualne nasazena verze ksoftlimd patche: https://github.com/vpsfreecz/linux/commit/e04b3f9cda1d A uplne-uplne zaverem: linux kernel neni advanced black magic. Je to jen strasne velka a nekdy dost neforemna kupa C kodu, ktery potrebuje schopne a ochotne instalatery. V koncinach memory cgroup + memory managementu je teda hodne, co zlepsovat, a vubec to neni raketova veda... Teda obecne, na kontejnerizace v Linuxu je dost co resit. Takze kdybyste s tim jadernym vyvojem nekdo chtel pomoct, stavte se na IRC, nebo v Base48 v Brne pokecat, neco vymyslime, bude to zabava, trust me ;) /snajpa

8 28

Kompilace v nixops spouští desítky procesů, na které nemá zdroje
by Tomáš Kuča 11 Aug '20

11 Aug '20

Ahoj, mám na jedné VPS nixops a zkouším přes to deploynout nixos na jinou VPS. Opakovaně jsem narazil na problém, že se začne kompilovat nějaká derivace, a po chvíli to sestřelí OOM killer. Typicky se těsně předtím naspawnuje spoustu (desítky) procesů. Všiml jsem si toho u ripgrepu (rustc), tam to ještě prošlo. Teď mi spadne GitLab resp. webpack při kompilaci assetů: /tmp/nix-build-gitlab-assets-13.0.9.drv-1/source/node_modules/.bin/webpack --config /tmp/nix-build-gitlab-assets-13.0.9.drv-1/source/config/webpack.config.js --bail Deploy spouštím na node256 takto: nixops deploy -d simple --max-jobs 1 --cores 1 VPS má 4 GB, běží na node15.prg. V dmesg vidím, že tam při spuštění OOM killeru bylo 32 procesů node15 32 je podezřelé kulaté číslo. Myslím si, že buildovací tooly odněkud přečtou informaci, že mají pustit 32 instancí, nastartují podle toho a vzápětí je systém po setkání s realitou sestřelí. Chystám se zreprodukovat build webpacku ručně a zjistit, podle čeho to spawnuje. Nemá už to někdo projité? Zní to jako něco, na co už mohl narazit někdo jiný. zdravím Tomáš Kuča

3 3

Obsazenost RAM
by Filip Bartmann 10 Aug '20

10 Aug '20

Ahoj, u VPSky co mám ve správě - caara.cz, vidím divně obsazenou RAM. Graf ukazuje 2,3 TB obsazené RAM, ale hlavní žrouti jsou mysql - 158 GB a journald - 142 GB a pak už tam jsou jenom malé procesy. Odkud se teda bere těch 2.3 TB, které postupně narůstají? Ahoj, Filip Bartmann

4 8

Problem s upgrade Arch a systemd 249-1
by Petr Kutalek 09 Aug '20

09 Aug '20

Ahoj, pokud někdo používáte Arch, doporučuji na vpsfree _NEprovádět_ upgrade systemd na 249-1. netctl, co je použit, zapisuje při bootu pro konfiguraci sítě systemd unitu netctl(a)venet0.service: > .include /usr/lib/systemd/system/netctl@.service > > [Unit] > Description=osctl network configuration for venet0 Po rebootu již nenastartujete, protože je to pro systemd unita s "bad syntax", pomůže restore přes admina. Těžko k tomu něco říci; já osobně se zbavím oné šílenosti netctl/osctld a přejdu na čisté řešení se systemd-networkd, ale nechci si tím nyní kazit víkend. Petr

3 3

OpenVPN na Ubuntu 18
by mochour＠email.cz 26 Jul '20

26 Jul '20

Ahoj, pokouším se spustit OpenVPN na Ubuntu 18.04: Distributor ID: Ubuntu Description: Ubuntu 18.04.4 LTS Release: 18.04 Codename: bionic TUN/TAP mám povolený. Konfigurační soubor, je mírně upravený podle (hlavní změna jsou certifikáty): https://kb.vpsfree.cz/navody/server/openvpn (https://kb.vpsfree.cz/navody/server/openvpn) Přesto mi OpenVPN neustále padá: Sat Jul 25 22:02:16 2020 OpenVPN 2.4.4 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on May 14 2019 Sat Jul 25 22:02:16 2020 library versions: OpenSSL 1.1.1 11 Sep 2018, LZO 2.08 Sat Jul 25 22:02:16 2020 Diffie-Hellman initialized with 2048 bit key Sat Jul 25 22:02:16 2020 TUN/TAP device tap0 opened Sat Jul 25 22:02:16 2020 Note: Cannot set tx queue length on tap0: Operation not permitted (errno=1) Sat Jul 25 22:02:16 2020 do_ifconfig, tt->did_ifconfig_ipv6_setup=0 Sat Jul 25 22:02:16 2020 /sbin/ip link set dev tap0 up mtu 1500 Sat Jul 25 22:02:16 2020 openvpn_execve: unable to fork: Resource temporarily unavailable (errno=11) Sat Jul 25 22:02:16 2020 Exiting due to fatal error Nevíte někdo jak to vyřešit? H

1 1

Nevysvětlitelné nefungování sítě
by Matěj Strnad 22 Jul '20

22 Jul '20

Ahojte, mám VPS, ale z ničeho nic se mi k němu nijak nedaří připojit. Ani přes HTTP(S), ani přes SSH, přes web-konzoli jsem se díval, porty 443,80,22 jsou normálně povolené. Zkoušel jsem to i přes více sítí z více zařízení. VPS běží na node1.prg, Ubuntu 20.04. Co mám zkontrolovat případně opravit? Nebo je to chyba někde jinde? Ještě dodám, v tu dobu jsem neprovedl na VPS žádné změny, jednoduše jeden HTTPS požadavek fungoval, další už byl timed out, SSH poté stejná chyba. Zkoušel jsem i restart, nepomohlo. Server má vytížení normální, síťová aktivita je také v pohodě (resp. žádná není, jako většinu času :)), takže DDoS/DOS to být nemůže. Děkuji za pomoc :)

4 4

Divné chování htop - RAM
by Filip Bartmann 20 Jul '20

20 Jul '20

Ahoj, zjistil jsem, že se mi na VPSce s CentOS 8 divně chová htop, konkrétně jak zobrazuje využitou ram. Když dám v konzoli free -m tak mám: ---------------------------------------------------------------- total used free shared buff/cache available Mem: 4096 140 93 3838 3861 3955 ---------------------------------------------------------------- V htopu mi ale ukazuje RAM skoro celou použitou RAM - viz přiložený obrázek, konkrétně mi jde o hodnotu buff/cache, v htopu se mi nezobrazuje žlutě jako jinde, tak nevím jestli RAM je plná, bo ne.

3 7

Podman (Docker) na VPS
by Petr Kutalek 17 Jul '20

17 Jul '20

Ahoj, tuším, že Pavel Šnajdr na poslední schůzi v Praze říkal (volně převyprávěno), že je rád, když se lidi ozvou, protože to pak připomíná více komunitu, nikoli jen podporu á la firma. Tak já tedy jeden dotaz mám – týká se to Dockeru, resp. Podmana. :) - Připravil jsem si lokálně na svém _lab_ desktopu image pro kontejnery a pody, které chci nasadit na VPSce. Vše OK, žádné extra vylomeniny. - Pročetl jsem https://kb.vpsfree.cz/navody/vps/vpsadminos/docker - Podíval jsem se na https://kb.vpsfree.cz/navody/vps/vpsadminos - Používám Arch, Podman v rootless režimu (z mnoha důvodů). - Povolil jsem ve features podporu FUSE (pro overlayfs) a TUN/TAP. - Nevím, co přesně dělá "Docker" feature, ale reálně nic nemění, výsledek je stejný. Když se ale snažím spustit byť jen demo `podman run --rm hello-world`, nedaří se mi: > Error: > container_linux.go:367: starting container process caused: > process_linux.go:459: container init caused: > process_linux.go:382: setting rlimits for ready process caused: > error setting rlimit type 7: invalid argument: OCI runtime error Narazil jste někdo při zprovoznění Dockeru na něco podobného? Můžete mne nasměrovat k cíli? Resp. proč/v čem je nastavení Dockeru v našem virtualizačním řešení nějak specifické? Díky, Petr

10 19

LTO - zalohovani na pasky - blogpost
by Radek Zajíc 26 Jun '20

26 Jun '20

Ahoj, V kontextu clenske schuze dnes padlo tema zalohovani na pasky. Nedavno jsem k tomu cetl super clanek (v cestine), ve kterem autor popisuje fungovani technologie zalohovani na pasky LTO, rozdily mezi verzemi a pod. Pokud o zalohovani na pasky uvazujete, je to super zdroj informaci. Zapisek najdete na https://www.fangfactory.net/2020/01/05/linear-tape-open-lto/ Radek Zajic

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Community-list