Začnu stručně: máme Discourse! Najdete ho na
https://discourse.vpsfree.cz.
V roce 2009 jsme původně začínali s fórem, které mělo sloužit jako
poradna a místo pro diskuzi obecně, ale v podstatě nikdo ho nepoužíval.
Možná tam byly tři posty, které nebyly ode mě. Pak jsme přešli na
mailing listy, které mají tu výhodu, že příchozího mailu si všimne
mnohem víc lidí. To zafungovalo, ale zhruba, když jsme míjeli velikost
1000 členů, se přesně tenhle faktor otočil zas proti nám. Až příliš
často uvažujeme nad tím, zda se svojí prkotinou spamovat tolik lidí.
Za sebe musím říct, že mám pokaždé obrovskou radost, když se na
community-listu povede něco vyřešit. Chtěl bych toho vidět víc, mnohem
víc, nemyslím, že by nebylo, co řešit, o čem se bavit, jen ten formát
mailing listu se nám už asi trochu přežil.
Discourse vypadá, že by pro nás mohl spojit to nejlepší z obou světů –
je možné ho použít mailem, ale organizací má spíš jako fórum.
Když se nám povede, že nám to na Discourse začne víc žít, můžeme taky
zvážit přechod z IRC na Discourse Chat. V IRC místnosti teď už taky visí
už jen okolo 50 lidí ze špičkových cca 100, v souladu s tím, jak
relevance IRC upadá.
Mimo jiné, na #vpsfree teď visí bot vpsfbr0, je to instance
matterbridge, přes kterou by nakonec mělo jít přemostit aspoň základním
způsobem všechny podstatnější IM, zatím je nastavený jako most s
Matrixem - https://view.matrix.org/room/!vOrcaItWgYDyYypqCI:matrix.org/
Do vpsFree Discourse se přihlašuje buďto přihlašovacími údaji vpsAdminu
(pro členy) nebo se dá vytvořit běžný účet (pro nečleny). Aby byla
trochu přidaná motivace se tam přijít podívat, napadlo nás, že bychom
mohli tuhle příležitost využít k nabídnutí všeho toho hardware, který je
už rok vypnutý a nebudeme ho určitě potřebovat.
Co bude dál s mailing listy:
news-list ještě chvíli podržíme v podobě, jak fungoval, ale po nějaké
době (půl roku až rok) se přesune na kombinaci Discourse (kde se dá o
těch věcech potom diskutovat) a blog (jako nástěnka pro věřejnost).
outage-list – vpsAdmin už dlouho umí reportovat výpadky dotčeným členům
rovnou a celá historie je dostupná bez přihlášení – tam tedy můžeme
přestat posílat rovnou
community-list – tam na konci roku vypneme možnost posílat do něj nové
příspěvky s automatickou odpovědí, že už dál diskutujeme jen na
Discourse
No a tím se rozloučíme s mailing listy :).
Díky všem, kdo jste na nich byli aktivní, přijměte prosím pozvání na
novou platformu – pojďme to zkusit pojmout jako novou příležitost k
výměně zkušeností. Doufám, že snad s menším třením oproti mailing
listům.
/snajpa
Ahoj všem,
začínám si hrát se svým novým VPS.
Hledám někoho, kdo by mi pomohl nastavit firewall. Po prvních pokusech se
mi zdá, že na to sám nestačím. Za pomoc rád zaplatím.
Můj cíl:
- Mám VPS s ubuntu 22.04.
- Budu používat docker pro deployment jednotlivých aplikací (služeb).
- Chci používat ZeroTier jako VPN.
- Chci nastavit firewall tak, aby do internetu byly otevřené jen porty 22
(SSH), a 443. Případně 80, který by přesměrovával na 443.
- Dále chci, aby skrz ZeroTier VPN fungovaly všechny služby, tj firewall by
měl propouštět skrz ZeroTier veškerou komunikaci.
Moje první kroky vedly k ufw. Bohužel jsem ale zjistil, že ufw v kombinaci
s dockerem nefunguje správně
<https://docs.docker.com/network/packet-filtering-firewalls/#docker-and-ufw>.
Nevím, jakou alternativu k ufw zvolit. Manuální editace iptables i
firewalld jsou pro mě komplikované.
Díky za nabídku pomoci nebo třeba i za odkaz na nějaký dobrý tutorial.
S pozdravem
Vašek
Ahoj,
mám na VM nixos-unstable, po poslední aktualizaci mi nenaběhne
nix-serve (VM 16201). V žurnálu je chyba:
nix-serve.service: Failed to set up credentials: Protocol error
nix-serve.service: Failed at step CREDENTIALS spawning /nix/store/g5jgqgf01gsiya5im563952qlbk21028-unit-script-nix-serve-start/bin/nix-serve-start: Protocol error
Neřešil jste to někdo?
---
V konfiguraci nic zvláštního nemám, secrets nahrávám pomocí `sops-nix`:
services.nix-serve = {
enable = true;
secretKeyFile = config.sops.secrets.cache-sig-key.path;
};
V `nix-serve.service` je
DynamicUser=true
LoadCredential=NIX_SECRET_KEY_FILE:/run/secrets/cache-sig-key
Problém je zřejmě s právy, pokud příkaz v `ExecStart` spustím jako root,
nix-serve naběhne. Vlastníkem klíče je root:
-r-------- 1 root root 102 1. lis 11.25 /run/secrets/cache-sig-key
Předpokládám, že to rozbila aktualizace systemd, ve verzi 253
to projde, ve verzi 254 (254.3) už ne. V měsíc staré, ještě
neaktualizované VM to běží, se stejnou konfigurací a právy. Našel jsem
https://github.com/NixOS/nixpkgs/issues/157449 a Zkoušel jsem nastavit
`rshared` pro `/run`, beze změny.
Zkouším, jestli už na to někdo nenarazil, než začnu zkoumat, jak to celé
funguje pod pokličkou.
—
Tomáš Kuča
Ahoj,
co je tohle za procesya jak to vypnout?
nmap
111/tcp open rpcbind
32769/tcp open filenet-rpc
systemctl stop rpcbind.socket
ukončí rpcbind na portu 111, ale
32769/tcp open filenet-rpc
tohle běží dál a nevím jaký program to spouští a jak to vypnout. Nemůžu
mít server i napadený? Mám tam nějak hacknutý wordpress, možná to s tím
souvisí.
díky
Živoslav
no právě, zjistit proces. Na portu 32769 není ani PID ani jméno
programu. To je divné, ne?
Dne 22. 09. 23 v 8:17 Tomáš Antecký napsal(a):
> Zkus *netstat -ntplu *jako root aby si našel ten proces.
> Měj se
> Tomáš
>
>
> On 21.09.2023 13:12, Živoslav wrote:
>>
>> Ahoj,
>>
>>
>> co je tohle za procesya jak to vypnout?
>>
>> nmap
>> 111/tcp open rpcbind
>> 32769/tcp open filenet-rpc
>>
>> systemctl stop rpcbind.socket
>>
>> ukončí rpcbind na portu 111, ale
>>
>>
>> 32769/tcp open filenet-rpc
>>
>>
>> tohle běží dál a nevím jaký program to spouští a jak to vypnout.
>> Nemůžu mít server i napadený? Mám tam nějak hacknutý wordpress, možná
>> to s tím souvisí.
>>
>>
>> díky
>>
>>
>> Živoslav
>>
>>
>> _______________________________________________
>> Community-list mailing list --community-list(a)lists.vpsfree.cz
>> To unsubscribe send an email tocommunity-list-leave(a)lists.vpsfree.cz
>
Ahoj,
(English below)
Pokud vám po restartu VPS nestartuje LXD, je to pravděpodobně způsobeno
změnou ve snapd. Ve verzi 2.60 dělali nějaké změny s AppArmorem a aspoň
v našem prostředí pak LXD nestartuje.
Chyba při instalaci např. vypadá takto:
# snap install lxd
error: cannot perform the following tasks:
- Start snap "lxd" (25505) services (systemctl command [start
snap.lxd.activate.service] failed with exit status 1: Job for
snap.lxd.activate.service failed because the control process exited with
error code.
See "systemctl status snap.lxd.activate.service" and "journalctl -xeu
snap.lxd.activate.service" for details.
)
Jednoduchý workaround je v detailu VPS ve vpsAdminu zrušit feature
"AppArmor control directories" (aby to nebylo zaškrtnuto). snapd ani LXD
se potom nebudou snažit AppArmor použít a bude to fungovat.
ENGLISH:
If you're having an issue with LXD installed as snap not starting, it is
most likely caused by a change in snapd. Version 2.60 contained some
AppArmor-related changes which do not work correctly, at least not in
our environment.
For example, this is the error when trying to install lxd:
# snap install lxd
error: cannot perform the following tasks:
- Start snap "lxd" (25505) services (systemctl command [start
snap.lxd.activate.service] failed with exit status 1: Job for
snap.lxd.activate.service failed because the control process exited with
error code.
See "systemctl status snap.lxd.activate.service" and "journalctl -xeu
snap.lxd.activate.service" for details.
)
A simple workaround is to disable feature "AppArmor control directories"
in VPS details in vpsAdmin -- uncheck it. snapd and LXD will no longer
try to use AppArmor and will work again.
Jakub
Ahoj,
mám 2 VPSky a když si zkouším k ním založit 2 staging VPS, tak mi to tu druhou nepovolí, protože nemám pro druhou staging VPS dost zdrojů. Ke každému účtu je tedy jenom jedna staging VPS bez ohledu na to, kolik je k účtu přirazeno VPS?
Děkuji,
Filip Bartmann
Tam mají ovladače jenom na Nvidii.
Asi vědí proč :-(
--
s pozdravem Tomáš Spisar
+420 702 937 602, Praha 11
tomas.spisar(a)seznam.cz, www.pdstudios.cz
(https://pdstudios.cz?utm_source=signature&utm_medium=email&utm_campaign=bra…)
(https://navzdorydobe.cz?utm_source=signature&utm_medium=email&utm_campaign=…)
Dezinfekční prostředky pro vaši ochranu www.navzdorydobe.cz/
(https://navzdorydobe.cz?utm_source=signature&utm_medium=email&utm_campaign=…)
---------- Původní e-mail ----------
Od: Aleš Bobek <boban(a)boban.cz>
Komu: Tomáš Spisar <tomas.spisar(a)seznam.cz>
Datum: 31. 8. 2023 10:29:14
Předmět: Re: [vpsFree.cz: community-list] HP Zbook 15 G2 - Ovladače grafické
karty AMD Radeon R9 M270X
" Ahoj,
co přímo HP support - download?
Aleš
Dne čt 31.08.2023 v 9:58:57 Tomáš Spisar napsal(a):
"
Ahoj, nemám dotaz k vpsfree, ale už nevím kde se sehnat informace :-(
Systém Windows 10, při instalaci se jakýkoliv ovladač začne instalovat, ale
vždycky se instalace kousne a je to na jenom na vypnutí.
Zkoušel jsem tři ovladače od AMD. Máte někdo zkušenost jak to rozchodit?
Výpis z HW Info: https://gcdnb.pbrd.co/images/IWkXS4CBT0Xf.jpg
(https://gcdnb.pbrd.co/images/IWkXS4CBT0Xf.jpg)
--
s pozdravem Tomáš Spisar
_______________________________________________
Community-list mailing list -- <a href='mailto:community-list@lists.vpsfree.cz' class='-wm-moz-txt-link-abbreviated'>community-list(a)lists.vpsfree.cz</a>
To unsubscribe send an email to <a href='mailto:community-list-leave@lists.vpsfree.cz' class='-wm-moz-txt-link-abbreviated'>community-list-leave(a)lists.vpsfree.cz</a>
"
"
Ahoj,
(English below)
TL;DR ve VPS lze nově používat distribuci Guix.
GNU Guix System [1] je linuxová distribuce založená na správci balíčků
Guix. Funguje to velice podobně jako NixOS [2] a Nix, až na to, že Guix
a celý systém se konfiguruje pomocí Guile Scheme. Ve Scheme jsou opravdu
veškeré součásti systému, včetně init systému Shepherd [3].
Na rozdíl od klasických distribucí se Guix a NixOS konfigurují
deklarativně: v konfiguračním souboru nadefinujeme kompletní podobu
výsledného systému, tj. jaké má obsahovat uživatele/skupiny, služby a
jejich nastavení. Ať už se jedná o aktualizaci nebo rollback, mezi
různými verzemi systému se lze snadno přepínat buď za běhu, nebo při
bootu v zavaděči, resp. u nás ve Start Menu [4]. Guix oproti NixOS
obsahuje jen Free Software.
Protože ve vpsFree používáme NixOS [5] skoro na všechno, zajímalo mě
taky, jak je na tom Guix. Bohužel Scheme pořádně neznám a ani mě to moc
neláká -- je tam příliš mnoho závorek :) Před rokem se jeden člen snažil
[6] šablonu pro Guix vytvořit, ale sám jsem neviděl cestu, jak na to. Až
před pár dny jsem narazil na blog [7], který obsahoval potřebné
informace. Hlavní problém byl, že ve VPS nemáme zavaděč a taky se
nepřipojuje kořenový souborový systém -- je připojen už před spuštěním
/sbin/init ve VPS. V konfiguraci však zavaděč i kořenový systém být
musí, jinak se systém nesestaví.
Nakonec to není žádná věda: jako zařízení pro zavaděč stačí /dev/null
[8] a volba --no-bootloader, s kořenovým systémem je to podobné [9].
Pokud by někdo měl zájem to vyzkoušet, VPS s Guixem si můžete vytvořit
na node1.stg (staging). Jinde zatím nebude fungovat integrace pro
nastavení sítě. Více informací viz KB:
https://kb.vpsfree.org/manuals/distributions/guix
Jsou tam ještě nějaké nedostatky, které už nejspíš řešit nebudu, aspoň
ne teď. Základ včetně integrace do vpsAdminu a Start Menu je zdá se
funkční. Sami pro Guix využití nemáme, dělal jsem to spíš ze
zajímavosti. Jestli Guix někdo použijete, budeme rádi za zpětnou vazbu.
ENGLISH:
TL;DR VPS can now use Guix distribution.
GNU Guix System [1] is a linux distribution based on Guix package
manager. It is very similar to NixOS [2] and Nix, except that Guix is
configured using Guile Scheme. Indeed, most of the system components
including the init system Shepherd [3] are written in Scheme.
Unlike other well-known linux distributions, Guix and NixOS are
configured declaratively: users/groups and all services with their
settings that should a part of the target system are defined in a config
file. It is possible to switch between different system configurations,
be it an upgrade or downgrade. System versions can be switched at
runtime or from the bootloader -- in our case, from the Start Menu [10].
Unlike NixOS, Guix contains only Free Software, as it is a part of the
GNU project.
At vpsFree.cz, we use NixOS [5] almost everywhere. I was thus interested
to see the state Guix is in. Unfortunately, I'm not familiar with
Scheme, there are far too many parentheses! A year ago, one of our
members tried to create [6] template for Guix, but we haven't been able
to make it work. A few days ago, I've discovered a blogpost [7] that
helped me understand the missing pieces. Our main issue was that inside
the VPS, there's no bootloader and no need to mount the root file
system, as it is mounted even before its /sbin/init is started. Guix
configuration however requires them to be configured.
In the end it's pretty straightforward. /dev/null is used [8] as a
device for the bootloader together with option --no-bootloader. Mounting
of the root file system can be bypassed in a similar way [9].
If someone would like to give it a go, you can create VPS with Guix on
node1.stg (staging). For more information, see KB:
https://kb.vpsfree.org/manuals/distributions/guix
There are several known issues, but the base system appears to be
operational. Network configuration is integrated with vpsAdmin and the
Start Menu can be used to run older system generations. As we do not
have any actual use for Guix ourselves, I'm going to leave it as it is
for now. We'll be glad for any feedback if you'll run anything on Guix.
[1] https://guix.gnu.org
[2] https://nixos.org
[3] https://kb.vpsfree.cz/navody/vps/start_menu
[4] https://www.gnu.org/software/shepherd/
[5] https://github.com/vpsfreecz/vpsfree-cz-configuration
[6] https://github.com/vpsfreecz/vpsadminos-image-build-scripts/pull/47
[7] https://www.thedroneely.com/posts/guix-in-a-linux-container/
[8]
https://github.com/vpsfreecz/vpsadminos/blob/14ac41e78566cdddc28fa40e2d7975…
[9]
https://github.com/vpsfreecz/vpsadminos/blob/14ac41e78566cdddc28fa40e2d7975…
[10] https://kb.vpsfree.org/manuals/vps/start_menu
Jakub
Ahoj, nemám dotaz k vpsfree, ale už nevím kde se sehnat informace :-(
Systém Windows 10, při instalaci se jakýkoliv ovladač začne instalovat, ale
vždycky se instalace kousne a je to na jenom na vypnutí.
Zkoušel jsem tři ovladače od AMD. Máte někdo zkušenost jak to rozchodit?
Výpis z HW Info: https://gcdnb.pbrd.co/images/IWkXS4CBT0Xf.jpg
--
s pozdravem Tomáš Spisar
Ahoj,
kdysi jsem pohorel s UFW na OpenVZ kvuli nejakym modulum, ale na
novejsim VPSAdminOS je uz hodne veci precejen jinak ale porad jsem trochu
zahorel
root@vps1:~# ufw enable
ERROR: problem running ufw-init
modprobe: FATAL: Module nf_conntrack_ftp not found in directory
/lib/modules/
6.1.44
modprobe: FATAL: Module nf_nat_ftp not found in directory
/lib/modules/6.1.44
modprobe: FATAL: Module nf_conntrack_netbios_ns not found in directory
/lib/m
odules/6.1.44
Bad argument `nat'
Error occurred at line: 18
Try `iptables-restore -h' or 'iptables-restore --help' for more
information.
Problem running '/etc/ufw/before.rules'
tak se chci zeptat, jestli je nejaka moznost ty moduly eventualne nejak tam
dostat / zapnout ci jen nejak upravit konfiguraci UFW, aby to jelo. Neni
nekdo uz je trochu dal, ze by mi poradil nebo mi rekl rovnou, ze to je
problem, blbne to a nema cenu se s tim ani otravovat. :)
Pokud by nekoho zajimal duvod tak ten nejvetsi je ten, ze to umi ipv6 a
ipv4 najednou a nemam bolehlav z toho generovani tech silenosti, navic
dvakrat pro 6 a 4 :)
S pozdravem
Jan Pleva
Ahoj,
snažím se provést SWAP dvou (mých) PS. Jedna je produkční, druhá je na
playgroundu. V podstatě vlastně jen potřebuji tu z Playgroundu překlopit
do produkce, stávající produkční potom zruším.
Postupuji takto:
Ve vpsadminu kliknu na VPS a zvolím si (produkční) VPS. Pak v pravo v
Manage VPS kliknu na Swap VPS.
Následně zvolím (playground) VPS kterou chci nahradit tu produkční a
zaškrtnu swap hostname.
Kliku na Preview, tam na Go a zkončím s chybou:
*Error message: unable to migrate VPS with existing snapshot clones*
Bohužel asi nechápu co je tím myšleno.
Nemáte někdo nějaký nápad? VPS na Playgroundu mi zítra expiruje.
Předem díky
--
S pozdravem
David Toman
https://www.idkfa.cz
Tel: 777 477 955
Tento email neobsahuje viry,
protože nepoužívám Windows.
Ahoj,
(English below)
Pravidelně se stává, že někomu ve VPS dojde místo na disku. vpsAdmin
sice posílá upozornění od 90 % zaplnění, ani to ale ve všech případech
nepomůže tomu předejít. S plným diskem přestávají fungovat vaše
aplikace, které s diskem pracují, a také to může znemožnit login do VPS
a uvolnění místa.
Každou jednotlivou VPS řešíme i my jako administrátoři vpsFree.cz,
protože ZFS s prací nad plnými datasety (disky VPS) aspoň historicky
mívalo problémy. Souvisí to s tím, že ZFS kvůli dynamické velikosti
bloku a kompresi dopředu neví, kolik místa budou data na disku zabírat.
Aby nebyla překročena nastavená kvóta datasetu, dochází k předčasnému
uzavírání txgs -- transakční skupiny, v rámci kterých se data v
pravidelných intervalech zapisují na disk. Vyšší frekvence txgs potom
zpomaluje chod všech VPS.
Další faktor je, že jsme v těchto situacích naráželi na chyby souběhu,
které mohou vést k zastavení IO na nodu a nutnosti resetu. Naše ZFS je
upravené tak, aby se txgs neuzavíraly předčasně a naopak umožňujeme v
jedné txg nastavenou kvótu překročit. I tak ale nechceme riskovat
výpadek a při zaplnění datasetu VPS nám monitoring posílá SMS. Když se
takových VPS najde víc a členové nereagují, je to pro nás dost
vyčerpávající.
vpsAdmin proto nyní bude automaticky zvětšovat datasety ve VPS, kde
dochází místo. Ke zvětšení dojde, když bude zbývat méně než 512 MiB,
popř. méně než 1 % celkové kapacity. Disk navyšujeme o 20 GiB nebo o 10
% kapacity podle toho, co je větší. K rozšíření může dojít až 3x a k
řešení máte 30 dní od prvního rozšíření. Po uplynutí této doby se bude
VPS vypínat, dokud se využití datasetu nevrátí do mezí původní
velikosti, nebo se nedomluvíme na trvalém rozšíření kapacity.
Ke zmenšení na původní velikost dojde automaticky, když bude k dispozici
alespoň 1 GiB a 5 % volného místa. Velikost můžete taky upravit kdykoli
ve vpsAdminu v detailu VPS.
ENGLISH:
It happens fairy regularly that VPS run out of disk space. vpsAdmin is
sending notifications when disk usage is 90 % or more, but that still
won't prevent it. When the disk is full, your applications are likely to
stop working and it may not be possible to login to the VPS and free
some space.
We as vpsFree.cz administrators are also involved with every VPS which
completely runs out of disk space. It is because ZFS at least
historically wasn't so good at operating on datasets (VPS disks) nearing
or at their quota. Due to dynamic block size and compression, ZFS does
not know how much space on disk the data will actually take. In order to
not exceed the dataset's quota, it tends to prematurely close txgs --
transaction groups in which data is written to disk in regular
intervals. Higher txgs frequency is then negatively impacting IO
performance of all VPS.
Another factor is that on multiple occasions, we've encountered rare
race conditions which led to ZFS deadlock, i.e. no writes were being
made at all and we've had to reset the node. While our ZFS is patched to
allow datasets exceeding their quota within one txg, we don't want to
risk an unnecessary outage because of this, so our monitoring system is
sending us SMS. When it happens often and members are not responding to
us, it's rather tiring for us.
From now on, vpsAdmin will automatically expand VPS datasets which are
nearing their quota. Datasets are expanded when there's less than 512
MiB or 1 % of free space. We add either 20 GiB or 10 % of original size,
whichever is higher. Datasets can be expanded three times and you'll
have 30 days since the first expansion to resolve the issue. After that,
the VPS will be stopped until the used space will fit within the
original quota or the dataset is expanded permanently.
Expanded datasets are shrunk back when there is at least 1 GiB and 5 %
of free space with respect to the original size. You can also change the
dataset size in VPS details in vpsAdmin at any time.
Jakub
Ahoj,
kacířská myšlenka: nefungoval by na komunikaci lépe nástroj jako discord? Přiznám se, že mail listy, nebo IRC mi k srdci nějak nepřirostly, ačkoliv si rád spravuju linux server. :-) Ani to moc nevypadá, že by tu ta diskuse nějak plynula.
Hezký víkend všem,
Fanda
Ahoj,
v poslední zprávě jsem psal o plánovaném přechodu na cgroups v2. Pomalu
na tom pracujeme už od počátku roku 2022. Vyžaduje to úpravy jednak v
našem kernelu, to je stále v řešení, a taky integraci v user space:
nutnost delegace controllerů, rozdílný způsob konfigurace a čtení
parametrů, až nakonec propojení s vpsAdminem. Pro mě asi největší oříšek
zatím byl devices controller. Pro zajímavost popíšu k čemu to je a jak
to funguje.
devices controller je pro nás stěžejní komponenta, bez které nemůžeme
fungovat. Řídí totiž přístup ke všem zařízením -- blokové jako disky
/dev/sda, atd. a znakové jako /dev/tty, /dev/null, /dev/zero, apod.
Protože ve VPS můžete udělat mknod libovolného zařízení, devices cgroup
je nezbytná pro řízení přístupu.
Ve výchozím stavu umožnujeme přístup k /dev/{console, full, kmsg, null,
ptmx, random, urandom, tty*}. Podle VPS features pak i /dev/{net/tun,
kvm, ppp}. Pro nás je nejdůležitější neumožnit přístup k diskovým
zařízením, nad kterými běží ZFS.
devices controller u cgroups v1 je krásně jednoduchý. Povolené zařízení
vidíme v devices.list:
cat /sys/fs/cgroup/devices/devices.list
c 1:3 rwm
c 1:5 rwm
c 1:7 rwm
c 1:8 rwm
c 1:9 rwm
c 1:11 rwm
c 5:0 rwm
c 5:1 rwm
c 5:2 rwm
c 136:* rwm
b *:* m
c *:* m
Tedy read-write-mknod (rwm) k vybraným zařízením a mknod (m) pro všechno
ostatní. Na Linuxu v user namespace normálně mknod není možný, ale na
vpsAdminOS ano. Hodí se to třeba když rozbalujete nějaký archiv, který
obsahuje soubory zařízení.
Tohoto nastavení devices.list docílíme tak, že nejprve zakážeme přístup
ke všemu:
echo a > devices.deny
A potom povolíme vybrané zařízení:
echo c 1:3 rwm > devices.allow
echo c 1:5 rwm > devices.allow
[...]
Je to krásně jednoduché jednak na přehled a taky na konfiguraci. Jediný
zádrhel je zde v tom, že echo a > devices.deny funguje jen pokud daná
cgroup nemá potomky. Protože se s cgroups pracuje z různých míst, řešil
jsem to tak, že se devices cgroup nastavovala jako první při spuštění
systému nebo vytvoření VPS.
cgroups v2 dlouho devices controller neměly vůbec... a když přišel, byl
implementován přes BPF. Funguje to tak, že napíšete BPF program,
zkompilujete, nahrajete do kernelu a potom ho připojíte k dané cgroup.
Při přístupu k zařízení se daný BPF program vykoná a buď přístup umožní,
nebo zakáže.
Ukázkový program je součástí kernelu:
https://github.com/torvalds/linux/blob/v5.10/tools/testing/selftests/bpf/pr…
Můj největší problém byl, že jsem to ani za nic nebyl schopen
zkompilovat. Detaily už samozřejmě nevím, ale byl jsem z toho absolutně
zoufalý. Kompilovat programy tímto způsobem by sice nebylo ideální,
protože k tomu potřebujete LLVM, což nafukuje velikost rootfs... ale
aspoň by se tím dalo začít.
Když se podíváme na projekty jako systemd nebo LXC, tam s devices cgroup
pracují taky. Nekompilují programy přes LLVM, ale vytvoří program rovnou
z BPF instrukcí. Pěkně je to vidět v LXC:
https://github.com/lxc/lxc/blob/lxc-5.0.2/src/lxc/cgroups/cgroup2_devices.c…
Tahle cesta se mi líbila mnohem víc, ale taky jsem nikam nepokročil.
Použít přímo tuto funkci LXC nemůžeme, protože LXC spouštíme pod
neprivilegovaným uživatelem a devices cgroup může nastavovat jen root.
Ani vykopírovat ten kód není jednoduché, potřebuje to spousty vaty okolo
a zřejmě jsem na to neměl nervy :-) Zkoušel jsem použít i libbpf, taky
bezúspěšně.
Vzdal jsem to a vrátil se k tomu cca o rok později... situace byla úplně
stejná x) Našel jsem ale knihovnu v Golangu, pomocí které si můžu
poskládat program z instrukcí, nahrát ho do kernelu a dokonce připojit k
cgroup! Nejlepší je, že k tomu není potřeba mít LLVM, zdrojové soubory
kernelu, libbpf, nic. Stačí Golang.
https://github.com/cilium/ebpf
Další nutný článek je virtuální souborový systém bpffs. BPF program
totiž zůstane v kernelu jen po dobu, kdy běží proces, který ho tam
nahrál. My takový proces prakticky nemáme, všechno se může při
aktualizaci restartovat... to by znamenalo, že se najednou ztratí
všechny programy hlídající přístup k zařízením.
Pokud na daný BPF program ale uděláme referenci v bpffs, program zůstane
v kernelu i po ukončení procesu, který ho vytvořil. Program pak uvolníme
smazáním souboru (jeho reference) v bpffs. Podobně můžeme dělat
reference na připojení programu (attach/link) k cgroup.
Celý náš stack je v Ruby, takže jsem na nastavovaní devices cgroup
udělal oddělený program v Golangu -- vznikl devcgprog. Ten z Ruby voláme
s cestou k cgroup a seznamem zařízení, které mají být povolené.
devcgprog vytvoří BPF program, nahraje ho do kernelu, uloží do bpffs a
připojí k cgroup. Kdyby se to někomu náhodou taky hodilo, devcgprog
najdete na githubu:
https://github.com/vpsfreecz/devcgprog
Použití je jednoduché:
devcgprog set /sys/fs/bpf/my-program \
/sys/fs/cgroup/my-cgroup \
/sys/fs/bpf/my-program-on-my-cgroup \
allow \
c:1:3:rwm c:1:5:rwm [...]
Parametry jsou: vytvořená reference v bpffs, cesta k cgroup, reference k
linku na cgroup, typ seznamu (allow pro allowlist a deny pro denylist) a
seznam zařízení.
Jeden BPF program můžete nahrát jednou a použít u vícero cgroup, k tomu
slouží devcgprog new/attach. U nás je kombinace možných programů omezená
podle VPS features. Jako název programu používáme hash všech zařízení,
existují tak programy pro různé kombinace TUN/TAP, KVM a PPP. Pokud už
program s daným hash existuje, uděláme jen attach na další VPS cgroup.
Oproti cgroups v1 je to stále méně přehledné, BPF program je v porovnání
s devices.list neprůhledný. Může taky dojít k tomu, že cgroup se smaže a
vytvoří znovu se stejným názvem, link soubor v bpffs zůstane, ale přitom
program tam už připojen není. Existence reference v bpffs tedy ještě
neznamená, že je vše v pořádku. Pravidelně tak voláme bpftool a
kontrolujeme, zda jsou programy správně nastaveny. To je jen pro
jistotu, nastavované cgroupy má pod kontrolou pouze root na nodu, tedy
by tato situace neměla nastat.
Neříkám, že BPF není super, naopak na trasování, flamegraphy, apod. je
to paráda. Akorát někdy není úplně snadné to použít :-)
Jakub
Ahoj,
(English below)
# Otisky SSH klíčů
V detailu VPS ve vpsAdminu nově najdete otisky SSH host klíčů
(fingerprints). Při prvním přihlášení přes SSH tak můžete zkontrolovat
identitu serveru. Otisky klíčů se vyčítají ze souborů
/etc/ssh/ssh_host_*.pub ve VPS. Klíče se čtou po každém startu VPS a pak
jednou za hodinu.
# Úpravy VPS adminy vpsFree
Šablony distribucí, ze kterých se vytváří nové VPS, mohou mít nastavení
specifické pro naše prostředí. Může se stát, že bug nebo nová vlastnost
aplikací či našeho prostředí bude vyžadovat změnu konfigurace systému.
Týká se to prakticky jen základního systému, tj. nastavení, které jsou
součástí šablon. Ve vpsAdminu máte možnost si nastavit, jestli o takové
úpravy máte zájem. Ve výchozím stavu je to povoleno. Pokud bychom ve VPS
něco měnili, budeme o tom informovat emailem.
Pro představu, nedávno jsme z kernelu odstranili cglimit cgroupu -- náš
vlastní controller, který se ukázal jako zbytečný. Distribuce se systemd
si s tím poradily samy, ale třeba Alpine/Devuan/Void mají seznam cgroups
zapsaný v init skriptu, takže jsme jej v existujících VPS museli upravit.
# cgroups v2
Tento rok bychom rádi započali přechod na cgroups v2. cgroups v Linuxu
se používají na účtování a limitaci skupin procesů. V našem prostředí je
to jeden ze základních prostředků pro izolaci VPS, používáme to primárně
na nastavení limitu paměti a času CPU. Na cgroups samozřejmě staví
všechny kontejnerové řešení jako docker, apod.
V současné době používáme cgroups v1 v hybridní hierarchii a právě
protože VPS jsou kontejnery, verze cgroups je daná hostitelem. systemd v
roce 2024 nejspíše přestane cgroups v1 podporovat, takže na to chceme
být připraveni. Aktuální distribuce už v2 podporují, ty starší jako
CentOS 7 budeme nadále provozovat na nodech s v1.
Ve vpsAdminu lze u VPS nastavit, jakou verzi cgroups VPS vyžaduje. Ve
výchozím stavu se to řídí šablonou distribuce. Pokud mají aplikace ve
VPS speciální požadavky, můžete si vynutit cgroups v1 a zabránit tak
budoucí migraci na v2. Naším cílem bude přesunout všechno co jde na
cgroups v2. Více info a seznam distribucí podporujících cgroups v2
najdete v KB:
https://kb.vpsfree.cz/navody/vps/cgroups
Žádnou akci z vaší strany to nevyžaduje, o případném přesunu VPS na
cgroups v2 budeme informovat individuálně v následujících měsících.
ENGLISH:
# SSH host key fingerprints
You can now see SSH host key fingerprints in VPS details in vpsAdmin.
You can check that the fingerprints match on your first SSH login,
making sure that you're connecting to your server. Key fingerprints are
read from /etc/ssh/ssh_host_*.pub files found inside the VPS. The files
are read on every VPS start and then once an hour.
# VPS modifications by vpsFree admins
New VPS are created from distribution templates and those can have
settings specific for our environment. It can happen that a bug or a new
feature in applications or our platform will require or benefit from
configuration change. You can configure whether you wish to have your
VPS updated by vpsFree admins should the need arise in VPS details in
vpsAdmin. It is enabled by default. We modify only the base system
configuration files and we will notify you by email when any changes are
made.
For example, we have recently removed the cglimit cgroup controller from
our kernel. It was our own creation and we've discovered it was only a
source of bugs. VPS using systemd handled this removal without any
problem, but distributions such as Alpine/Devuan/Void have the list of
cgroup controllers hardcoded in their init script. We've thus updated
the init script to not emit warning about cglimit mount failure on boot.
# cgroups v2
This year, we would like to begin transition to cgroups v2. cgroups in
Linux are used to account and limit groups of processes. On vpsAdminOS,
it is a fundamental component used to create a VPS. We use it primarily
to limit memory and CPU usage. cgroups are of course used by all other
container systems, such as docker, etc.
At this time, we're using cgroups v1 in a hybrid layout. Since VPS are
containers, the cgroup version is determined by the host. As systemd
will possibly remove support for cgroups v1 in 2024, we'd like to be
ready. Current distributions already support cgroups v2, the older ones
like CentOS 7 will be kept on nodes with cgroups v1.
Our goal will be to move as many VPS as possible to cgroups v2 nodes. By
default, we look at the distribution used inside the VPS to see if it
supports cgroups v2. If you wish, you can configure your cgroups version
preference in VPS details in vpsAdmin and pin it to cgroups v1 to
prevent future migration. More information about cgroups v2 and a list
of supported distributions can be found in KB:
https://kb.vpsfree.org/manuals/vps/cgroups
No action from you is needed at this time. We'll keep you updated about
the upcoming migration in the months to follow.
Jakub
Ahoj,
na VPS mám pomalý login. Trvá to cca 30 sekund, než proběhne ověření a
dojde k přihlášení. Když si dám u ssh podrobnější výpis, zjistím, že to
visí mezi těmito dvěma hláškami:
debug1: pledge: filesystem
debug1: client_input_global_request: rtype hostkeys-00(a)openssh.com
want_reply 0
Doteď mi to nevadilo, protože se k serveru nepřipojuju tak často, aby
mně těch 30 sekund vadilo, ale teď zkouším rozjet Cockpit a ten mi na
tom timeoutuje.
Našel jsem, že se to děje lidem s LXC, tak jsem se chtěl zeptat, jestli
jste taky na to u VPSfree nenarazili a jestli neexistuje nějaké
nastavení ssh nebo pam, které by to vyřešilo.
Jirka
Ahoj,
ladim spatny vykon zapisu do sqlite databaze v produkci (jak je to
dobre rozhodnuti nechme na jinou debatu :-D ); zapisy se deji v jednom
threadu. Problem je v tom, ze transakce v produkci jsou 10-20krat
pomalejsi nez u me na localhostu. Snazim se zjistit cim to je (driv
nez budu muset migrovat na jinou db).
Nesetkal jste se nekdo s necim podobnym? Nejake napady?
Zkousel jsem zreplikovat chovani pomoci jednoducheho (serioveho)
skriptu s 500 commity:
https://pastebin.com/huhhVGw2
vysledky: Journal (write ahead log) x synchronous mode (off
nejrychlejsi, normal bezpecnejsi & pomalejsi), cisla jsou mean +- std
vteriny.
localhost (ssd v notebooku)
journal= sync=OFF 1.051 +- 0.042
journal= sync=NORMAL 2.502 +- 0.237
journal=WAL sync=OFF 1.042 +- 0.022
journal=WAL sync=NORMAL 1.135 +- 0.065
produkcni stroj @ node21.prg
journal= sync=OFF 2.778 +- 1.415
journal= sync=NORMAL 2.876 +- 0.627
journal=WAL sync=OFF 2.382 +- 0.404
journal=WAL sync=NORMAL 2.475 +- 0.494
Prijde mi zvlastni maly rozdil mezi jednotlivymi rezimy ve vps & to ze
vse je o hodne pomalejsi nez nevirtualizovany stroj, myslite, ze to
vznika nejakou vps abstrakci nad ssd?
Nejake napady co s tim?
Diky,
JM
Ahoj,
přeinstaloval jsem si VPS z Debian 10 na Debian 11 a narazil jsem na jeden
problém.
Server občas použiju jako VPN server do internetu a proto jsem na něm
příslušný VPN provoz NAToval pomocí 'iptables' ven. Na Debianu 11 již
iptables nejsou, takže jsem použil ekvivalentní posloupnost 'nft'
pravidel.
Problém dělá konkrétně následující pravidlo:
/etc/firewall/ruleset.nft:13:60-63: Error: Could not process rule: No such
file or directory
add rule nat postrouting ip saddr 192.168.0.0/16 oif venet0 snat to
VPS.IP.ad.dr
^^^^
Poznamenávám, že na jiných strojích mi obdobné pravidlo funguje, jen na
VPS ne. Přijde mi to jako nějaké omezení vpsAdminOS.
Máte prosím někdo nějakou radu?
- Jirka
Na VPSce, kterou spravuju mám jeden takový problém s Amavisem, kdy po
restartu(nejblbější je to při těch nočních restartech) se zasekne a odmítá
spojení
--------------------------------------------------------------
Oct 18 23:32:16 slevmejih postfix/smtp[877]: connect to
127.0.0.1[127.0.0.1]:10024: Connection refused
Oct 18 23:32:16 slevmejih postfix/smtp[877]: 26F23D0D14: to=<xxx(a)gmail.com>,
orig_to=<xxx(a)yyy.cz>, relay=none, delay=0.31, delays=0.29/0.02/0/0,
dsn=4.4.1, status=deferred (connect to 127.0.0.1[127.0.0.1]:10024:
Connection refused)
Oct 18 23:32:16 slevmejih postfix/smtp[877]: 26F23D0D14: to=<xxx(a)yyy.cz>,
relay=none, delay=0.31, delays=0.29/0.02/0/0, dsn=4.4.1, status=deferred
(connect to 127.0.0.1[127.0.0.1]:10024: Connection refused)
--------------------------------------------------------------
Nevíte někdo co s tím, klient pro kterého VPSku spravuju už ne mně začíná
být naštvaný.
Filip Bartmann
Ahojte,
(TLDR: prechazime na silnejsi hardware, do konce roku vypiname stare
OpenVZ stroje)
puvodne to mel byt delsi mail sem, na community-list, ale nakonec z toho
vylezl blogpost:
https://blog.vpsfree.cz/inovujeme-skoro-vsechen-hardware-chceme-byt-energet…
Se spoustou z Vas uz jsme si o tom psali, tady je shrnuti pro ty, co
nestihaji tolik sledovat aktualni deni - kdo byste ho sledovat chteli,
jen nevite kde, to spravne misto je nase IRC, tam to vzdycky probirame,
jak to prichazi :)
Pro ty, co by byli na pochybach, jestli to ten HW bude stihat, doplnim,
ze ve vpsAdminu pribyly na front page odkazy na Munin, po prihlaseni
jsou rozkliknutelne ty nejdulezitejsi, bez prihlaseni ten procentualni
udaj vytizeni CPU je ted odkaz, ktery vede na celou Munin page daneho
stroje. Stiha to v pohode, pokud se stane, ze neco drhne, je to v
podstate garantovane softwarem a je to tim padem resitelne. Prosim,
pokud pocitujete nejaka zpomaleni, i kdyz si budete myslet, ze je to jen
drobnost, piste radeji driv, nez pozdeji.
Uprimne myslim, ze uz mame vetsinu vyladovani za sebou a tak uz ted, po
pristi varce rebootu do 5.10.147, vsechno pobezi hladce - nicmene, jak
rikam, pri sebemensim zavahani radeji piste (idealne na podporu).
Diky vsem za spolupraci :)
/snajpa
Cau,
kluci by chteli videt na OpenAltu nejakou prednasku na tema NixOS.
Pokud byste prijeli do Brna a naucili byste nas pouzivat/vyvijet NixOS,
tak by to bylo super.
Prednasku pripadne prihlasit sem:
https://www.openalt.cz/2022/ (jestli ste prosvihli deadline, tak to
neni problem, je to jenom orientacni informace, ze zaciname davat
dohromady program)
--
Jozef Mlich <jozef.mlich(a)openalt.org>
Ahoj,
na VPS 20533 o kterou se pro jednoho člověka starám byl včera objeven
proces xmrig což je podle všeho program na těžbu měn.
VPSku jsem prohledával, ale nikde tam ani ve webech ani na filesystému
nemůžu najít stopu po tomto programu.
Na VPSce běží běžné weby. Kterým směrem bych se měl zaměřit?
Ahoj,
Filip
Ahoj,
chcípe nám v jedné firmě UPSka v racku. Už je jí snad 20 let, za život
jedna výměna baterek, ale teď to začalo dělat divné věci, tak už asi
nastal čas na výměnu.
Ale za tu dobu jsem ztratil přehled. Máme tam APC RT3000 (sine wave,
double conversion) navíc s jedním externím battery packem a potřeboval
bych prakticky to samé. Koukal jsem co tak je na webshopech a vidím buď
zase APC nebo Eaton, ale je dost problém se někde doklikat i k tomu
battery packu, stránky Eatonu jsou takové zoufalství, že trvá než něco o
konkrétním modelu zjistím.
Měl by někdo radu? Značku UPSky, dodavatele, kde by to člověk poskládal?
Děkuji,
Štěpán.
ahoj
v punctum pouzivame slack, ten od 1.9. zavadi limit historie na 90 dnu
:o(
nemate nekdo tip, cim by se dal nahradit, resp. co jineho pouzivate na
tymovou spolupraci?
diky za odpovedi
tyctor
Situace na trhu s energiemi je nepředvídatelná, na jaře se nás dotklo
první výraznější zdražení, které jsme zvládli ještě pojmout díky rezervě
v rozpočtu. Otázkou je, jak moc dlouhodobě udržitelné to bude bez
zvyšování členských příspěvků.
Než sáhneme ke zvyšování příspěvků, chtěli bychom vyzkoušet jiné
možnosti. Zejména využít některých rezerv ve stávajícím hardware a
přestavba či nákup nových serverů s výkonnější konfigurací.
Více v blogu:
https://blog.vpsfree.cz/vykonnejsi-servery-jako-lek-na-zvysovani-cen-energi…
--
Petr Krčmář
vpsFree.cz
Ahoj,
(English below)
Při výpadku napájení minulý týden v Praze [1] jsme přišli o standardní
prostředky, které používáme pro komunikaci s členy, tj. zejména o
hlášení výpadků z vpsAdminu a o naši podporu. Zachránil nás akorát účet
na Twitteru [2] a kanál na IRC [3], kde jsme mohli členy informovat o
tom, co se děje. Chtěl jsem tuto situaci trochu zlepšit, když by se něco
podobného stalo znovu.
Představuji tedy https://status.vpsf.cz. Jedná se o aplikaci, která
průběžně kontroluje stav naší infrastruktury a vybraných služeb.
Kontroly jsou automatické, tj. když něco aktuálně nepojede, hned to
půjde vidět.
status.vpsf.cz běží na APU [4] s LTE v racku v Praze, tj. nezávisle na
síti od MasterDC. Připojen je na vlastní malou UPS, takže nějakou dobu
vydrží běžet i při výpadku napájení v DC.
Zobrazují se tam i nahlášené výpadky/odstávky z vpsAdminu a pokud zrovna
vpsAdmin nebude fungovat, informace o situaci napíšeme rovnou na
status.vpsf.cz.
ENGLISH:
During the power outage in Prague last week [5], we've lost our usual
means of communication with our members, mainly the outage reports from
vpsAdmin and our email support. We've been left with out Twitter account
[2] and the IRC channel [6] to let you know about the issue. I've been
trying to improve this situation.
I would like to introduce https://status.vpsf.cz. It is an application
that continuously monitors the state of our infrastructure and selected
services. The checks are automated, i.e. when something won't work as
expected, it will be immediately visible.
status.vpsf.cz runs on APU [4] with LTE in our rack in Prague. It's
independent on MasterDC's network. It also has its own little UPS, so it
should continue to work even after a power outage in the DC.
status.vpsf.cz shows reported outages and maintenances from vpsAdmin and
should vpsAdmin not be available, we will write information about the
situation directly on the status page.
[1] https://blog.vpsfree.cz/post-mortem-par-slov-k-vypadku/
[2] https://twitter.com/vpsfree_cz
[3] https://kb.vpsfree.cz/informace/chat#irc
[4] https://www.pcengines.ch/apu2.htm
[5] https://vpsadmin.vpsfree.cz/?page=outage&action=show&id=904
[6] https://kb.vpsfree.org/information/chat#irc
Jakub
Ahoj,
mám na VPSce problém se zahazováním mailu v Google.
Na každý mail odeslaný z VPSky dostávám odpověď:
-----------------------------------------------------------
Apr 26 19:21:34 slevmejih dovecot[2237987]:
imap(test(a)domena.cz)<2406100><2wOv7JHdmr4AAAAAAAAAAAAAAAAAAAAB>:
Logged out in=292 out=6306 deleted=0 expunged=0 trashed=0 hdr_count=12
hdr_bytes=2539 body_count=0 body_bytes=0
Apr 26 19:21:34 slevmejih postfix/smtp[2406098]: E8D2593153: to=<
filip.bartmann(a)gmail.com>, relay=gmail-smtp-in.l.google.com[142.250.102.27]:25,
delay=0.69, delays=0/0.03/0.36/0.3, dsn=5.7.1, status=bounced (host
gmail-smtp-in.l.google.com[142.250.102.27] said: 550-5.7.1 [37.205.13.80
12] Our system has detected that this message is 550-5.7.1 likely
unsolicited mail. To reduce the amount of spam sent to Gmail, 550-5.7.1
this message has been blocked. Please visit 550-5.7.1
https://support.google.com/mail/?p=UnsolicitedMessageError 550 5.7.1 for
more information. f25-20020a1709064dd900b006f396dc0ad3si4976888ejw.266 -
gsmtp (in reply to end of DATA command))
-----------------------------------------------------------
Přitom třeba od mail-tester.com dostávám skóre 8/10. Co mám další instalace
postfixu, se stejnou konfiguirací tak mi tento problém nemám. Na
blacklistech jsem IP VPSky adresu prověřoval a negativní. Už mi docházejí
nápady co mám dělat?
Co bych měl ještě přenastavit?
Děkuji,
Filip Bartmann
Ahoj,
používáte někdo Debian 9 na vpsAdminOS nebo 10+ na OpenVZ (ideálně
,,bez'' systemd)? Plánuju přechod z OpenVZ (aktuálně Debian 9) na
vpsAdminOS a kladné ohlasy tohoto typu by mě uklidnily. :-)
S pozdravem,
Opty
Hi
My main ssh key uses ed25519. As a newcomer I tried to add it via the
vpsAdmin menu Members "Add public key", but only got the error
> Failed to save public key
>
> Error message: create failed
>
> key: invalid public key
Adding an ssh-rsa key worked fine.
Or are there good reasons to forbit ed25519 keys?
Best regards
Niklaus
Na stránce IP adresy <https://kb.vpsfree.cz/navody/vps/ip_adresy> je uvedeno, že každý má k dispozici "až 32 IPv6 /64 adres (na OpenVZ jen /128 adresy)".
Jak je to u vpsAdminOS, tam také pouze /128 adresy?
--
Kamil
tel.: +420 910 128 153
Zdravím,
z nějakého důvodu mi kompletně přestal fungovat wireguard, žádná chyba
jenom se prostě nic neděje.
Jediné co jsem zjistil, je že modprobe odpoví tímto:
modprobe: FATAL: Module wireguard not found in directory
/lib/modules/5.10.98.16-livepatched
Ale jak systemd unita tak wg příkaz se tváří ok.
Netuší někdo kde by mohl být problém?
Děkuji,
Tomáš Svoboda
Ahoj,
Zkoumám možnosti přechodu na vpsAdminOS, a narazil jsem na takový … nepěkná věc.
Vypadá to že ne všechny funkcionality toho kouzelného rockeru fungují. Tohle konkrétně se mi projevuje na node1.pgnd na čisté testovací VPS s
> root@rancher-test:~# docker pull rancher/rke-tools:v0.1.72
> v0.1.72: Pulling from rancher/rke-tools
> e95f33c60a64: Pull complete
> 6b9066ff94f0: Pull complete
> d00048cae6c8: Pull complete
> 673a80f76512: Pull complete
> 5265c6a8bcaa: Pull complete
> bd5a2b7ec0a7: Pull complete
> 0119010d361b: Pull complete
> 04670b023a98: Pull complete
> 96787bdffc36: Pull complete
> 11b333b25e38: Pull complete
> edec598acdb7: Extracting [==================================================>] 5.101MB/5.101MB
> c66bbb7a280c: Download complete
> 199d7f942076: Download complete
> f6eba55964bb: Download complete
> e868bdb5d818: Download complete
> cbec9cc5bcb9: Download complete
> failed to register layer: Error processing tar file(exit status 1): lchown /usr/local/bin/etcdctl: invalid argument
Postup pro zreplikování:
- čistá VPS na node1.pgnd s Ubuntu 18.04 nebo 20.04
- apt-get update && apt-get -y upgrade
- instalace dockeru podle návodu https://kb.vpsfree.cz/navody/vps/vpsadminos/docker#instalace <https://kb.vpsfree.cz/navody/vps/vpsadminos/docker#instalace>
- pokus o pull image
Možná to je jen stejný projev něčeho jiného, ale trochu googlení naznačuje, že na to možná Snajpa už narazil (https://www.gitmemory.com/issue/moby/moby/41803/761551544 <https://www.gitmemory.com/issue/moby/moby/41803/761551544>)
Nějaké nápady/tipy co s tím?
Díky
Michal H.
Ahoj,
(English below)
Připravujeme nové menu, které se zobrazí v konzoli [1] při startu VPS.
Kromě normálního startu VPS umožňuje spustit shell nebo upravit
parametry init procesu. Je to taková alternativa např. GRUB menu v našem
prostředí. Naše VPS jsou kontejnery a klasický zavaděč tak neobsahují.
Uživatelé NixOS v menu najdou také možnost nastartovat systém ze starší
verze. Každá úprava konfigurace či aktualizace NixOS vytváří novou
generaci systému a standardně si v zavaděči můžete vybrat, kterou chcete
použít, např. když nové nastavení nefunguje správně. Nyní je to možné i
ve VPS pomocí start menu.
Spuštění shellu může často posloužit místo nouzového režimu [2] na
rychlou opravu systému, který třeba nestartuje. Jako shell se použije
/bin/sh z disku VPS a po jeho ukončení se opět objeví start menu.
Start menu je možné vypnout/zapnout ve vpsAdminu. Podporuje pouze VPS na
vpsAdminOS. Nastavovat lze také dobu, po kterou start menu čeká na
uživatele, než samo nastartuje systém VPS. Přednastaveno je 5 sekund.
Ukázka viz KB:
https://kb.vpsfree.cz/navody/vps/start_menu
Aktuálně je menu zapnuto na node1.stg (Staging). Na produkčních VPS si
ho můžete individuálně zapnout v detailu VPS nastavením timeoutu, třeba
na 5 sekund. Během tohoto nebo příštího týdne ho pak zapneme na všech VPS.
ENGLISH:
We're preparing a new menu that can be seen in the remote console [3],
when a VPS is being started. It allows you to run a shell or customize
the init command and parameters. It's an alternative for example to the
GRUB menu in our environment. Since our VPS are containers, they do not
have a standard bootloader.
NixOS users will also be able to start the system from an older
generation. On NixOS, every configuration change or update creates a new
system version. Usually you can use the bootloader to select which
version to boot from, e.g. when the newest version is not functioning
properly. Now this can be achieved using the start menu.
The shell can be used to quickly fix something in a VPS which is not
starting, as an alternative to the rescue mode [4]. The menu starts
/bin/sh from the VPS and after the shell exits, the menu reappears.
The start menu can be enabled/disabled in vpsAdmin. It is supported only
on vpsAdminOS. You can also configure the time for which the menu waits
for the user, before starting the VPS. We've set this to 5 seconds.
For preview, see KB:
https://kb.vpsfree.org/manuals/vps/start_menu
Currently, the menu is enabled on node1.stg (Staging). You can enable it
on production VPS in VPS details by setting the timeout, e.g. to 5
seconds. We will be enabling it on all VPS in the coming days.
[1] https://kb.vpsfree.cz/navody/vps/konzole
[2] https://kb.vpsfree.cz/navody/vps/vpsadminos/oprava#nouzovy_rezim
[3] https://kb.vpsfree.org/manuals/vps/console
[4] https://kb.vpsfree.org/manuals/vps/vpsadminos/recovery#rescue_mode
Jakub
Ahoj,
v mailu s upomínkou k platbě členského příspěvku je odkaz do vpsAdminu,
kde si můžete vypnout zasílání dalších upozornění. Najdete ho také ve
vpsAdminu, Edit profile -> Configure payment reminder. Je možné to
ztlumit na určitou dobu a nebo do zaplacení. Po přijetí platby se
nastavení resetuje a upomínku k další platbě opět dostanete. Stejně tak
se dají tlumit i maily o expiraci playground/staging VPS.
Dále jsme změnili frekvenci zasílání upomínek. Už to nebude jednou denně
(sorry!), ale v pondělí, středu a pátek. Den před pozastavením členství
/ VPS pošleme upozornění i přes ztlumení. Tak snad to teď bude lepší :)
Jakub
Ahoj,
(English below)
Terraform [1] je nástroj pro správu infrastruktury pomocí konfiguračních
souborů. Náš vpsAdmin provider plugin [2] se dočkal značných změn, zejména:
- je možné vytvářet datasety na NASu a subdatasety VPS,
- datasety NASu se dají exportovat přes NFS a přes Terraform získat
informace pottřebné k mountu,
- subdatasety VPS je možné připojit přes vpsAdmin,
- u VPS jde nastavovat jednotlivé features, DNS resolver
(/etc/resolv.conf) a taky měnit informaci o distribuci po
aktualizaci uvnitř VPS.
Ukázka konfigurace zde:
https://github.com/vpsfreecz/terraform-provider-vpsadmin/tree/master/exampl…
ENGLISH:
Terraform [1] is a tool for infrastructure administration using
configuration files. Our provider plugin for vpsAdmin [2] was upgraded,
the changes include:
- it is now possible to create datasets on NAS and VPS subdatasets,
- NAS datasets can be exported over NFS and mount information can be
read from terraform,
- VPS subdatasets can be mounted using vpsAdmin,
- VPS have configurable features, DNS resolver (/etc/resolv.conf) and
you can also change the distribution info after the VPS was
upgraded.
Example configuration can be seen here:
https://github.com/vpsfreecz/terraform-provider-vpsadmin/tree/master/exampl…
[1] https://terraform.io
[2] https://registry.terraform.io/providers/vpsfreecz/vpsadmin/latest/docs
Jakub
Ahoj,
řeším problém s nastavením IPv6, narážím zřejmě na svůj nedostatek znalostí o
IPv6 / routování. Mám ve vpsadminu nastavených spoustu /128 addres, chci si
místo toho nastavit /64 blok. Cíl je, abych mohl používat (třeba na
webserveru) libovolnou adresu z bloku a nemusel ji pokaždé routovat přes
vpsadmin.
Ve vpsadminu jsem si naklikal přidělení /64 bloku, potvrdil pomocí "Add route
and an address to interface venet0". Ve výpisu ji vidím:
6: venet0@if384: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 7e:20:84:0e:bb:58 brd ff:ff:ff:ff:ff:ff link-netnsid 0
...
inet6 2a03:3b40:101:42::1/64 scope global
valid_lft forever preferred_lft forever
První adresa z bloku funguje dle očekávání:
$ ping 2a03:3b40:101:42::1
PING 2a03:3b40:101:42::1(2a03:3b40:101:42::1) 56 data bytes
64 bytes from 2a03:3b40:101:42::1: icmp_seq=1 ttl=64 time=0.036 ms
Další dresy už ne:
$ ping 2a03:3b40:101:42::2
PING 2a03:3b40:101:42::2(2a03:3b40:101:42::2) 56 data bytes
From 2a03:3b40:101:42::1 icmp_seq=1 Destination unreachable: Address unreachable
Podobně nginx hlásí chybu, pokud ho nechám poslouchat na 2a03:3b40:101:42::2
nginx: [emerg] bind() to [2a03:3b40:101:42::2]:80 failed (99: Cannot assign requested address)
* Je správná idea, že ty to takhle mohlo fungovat?
* Co dalšího musím udělat, abych mohl používat 2a03:3b40:101:42::2 a další adresy z bloku?
Server je Debian stretch, VPS 6414 na vpsadminosu v Brně.
Dík za radu
Tomáš
Hezký den,
proces migrace na platformu vpsAdminOS a aktuální linuxové jádro u
nás zdárně pokračuje. V Praze máme 13 strojů přeinstalovaných, zbývají
VPS na 8 serverech. Od vás to vyžaduje drobnou akci: napsat na podporu,
abychom vás přesunuli. Pokud používáte NAS, budete ještě muset upravit
jeho připojení. Všechno je podrobně popsáno v článku u nás na webu [1].
To podstatné je, že data i IP adresy vám zůstanou, jen vám váš stroj
nastartuje s novým jádrem (v tuto chvíli 5.10) a svět bude mnohem lepší.
Celé to trvá pár minut, jen je potřeba to pak překontrolovat, ale
všechno by mělo normálně fungovat dál. Pokud máte chvíli, mrkněte se na
to. Díky
[1]:
https://blog.vpsfree.cz/migrujte-na-vpsadminos-uz-je-cas-na-aktualni-virtua…
--
Petr Krčmář
vpsFree.cz
Pokiaľ tam pridám ešte prepínače -debug -msg tak vidím, že pri ServerHello prejde 1297/4035 bajtov a ďalej je ticho. Asi by som pátral po nejakom probléme s fragmentáciou paketov po ceste (MTU, PMTUD, atd.)
--
Kamil
tel.: +420 910 128 153
> Mam taku mensiu zahadu…
>
> na prikaz [1] zadany cez ssh na mojej vps:
>
> openssl s_client -connect www.sczsk.sk:443 -tls1_2
>
> …dostavam len ciastocnu odpoved:
>
> CONNECTED(00000003)
>
> …a nic viac.
>
> Na ten isty prikaz na iny server - (napriklad) nabezky.sk - dostanem komplet odpoved.
>
> Z mojho pocitaca doma, prikaz [1] tiez vrati ocakavane data.
Mam taku mensiu zahadu…
na prikaz [1] zadany cez ssh na mojej vps:
openssl s_client -connect www.sczsk.sk:443 -tls1_2
…dostavam len ciastocnu odpoved:
CONNECTED(00000003)
…a nic viac.
Na ten isty prikaz na iny server - (napriklad) nabezky.sk - dostanem komplet odpoved.
Z mojho pocitaca doma, prikaz [1] tiez vrati ocakavane data.
Skusal som si nakratko urobit aj sandbox vps s najnovsou verziou Ubuntu, ale tam ten problem vidim tiez.
Ma niekto ideu ako to riesit?
Ahoj!
Tohle téma mne také velmi zajímá, neboť řešíme něco podobného. Tři
fyzické stroje o podobném výkonu, stejné konfiguraci OS a SW. Každý stroj v jiném DC s rozdílnou konektivitou.
Jak efektivně zajistit load balancing, případně HA v případně výpadku jednoho z nich… přičemž obsah webu má relativně malou proměnlivost (1 až 2 za den), ale jde tu o synchro datových souborů o velkém objemu v řádu stovek MB plus data v pgsql.
Přeji hezký den!
Sueneé
From: Community-list [mailto:community-list-bounces@lists.vpsfree.cz] On Behalf Of me
Sent: Monday, September 20, 2021 10:22 PM
To: vpsFree.cz Community list
Subject: Re: [vpsFree.cz: community-list] Jak vyřešit high availability na VPS
Ahoj,
problem vysoke dostupnosti ma nekolik rovin:
- HA v ramci jednoho poskytovatele
- HA v ramci ruznych dataventer
- Synchronizace dat
Prvni rovina je snadna - staci pouzit prepinanou IP adresu a dve VPS v rezimu active-passive. Pokud dojde k vypadku primarni, prepinana adresa se prehodi na zalohu a jede se dal. Resitelne je to napr. pres VRRP a Keepalived. Samozrejme je potreba tu IP adresu prehazovat na entry pointech a vsechno smerovat na ni.
HA napric datacentry je vyrazme komplikovanejsi. Realne je potreba byt schopen prehodit IP adresu mezi sitemi a rict Internetu, ze ted se na ni dostane jinudy. Resenim je BGP protokol, akorat na jeho pouziti uz je potreba vlastni HW a ASN (standartne toto poskytovatele neumi). V omezene mire lze na to pouzit i ruzne LB od providera (napr. NLB Amazonu) ale maji sva omezeni - standartne podporuji pouze http(s) a balancuji pouze v ramci regionu.
Synchronizace dat je problem sam o sobe. V ramci jednoho DC lze pouzit synchronni replikaci (u mysql rezim master-master nebo galeru, u storage napr. gluster nebo ceph). Se synchronizaci dat musi take pocitat aplikace (uploady) a jeji deployment. V pripade synchronizace pres vic DC je potreba pouzit async replikaci a rozume nastavit synchronizacni okno, aby replikace nezabila vykon a zaroven jsme neprisli o velke mnozstvi nezreplikovanych dat.
Ondra Flidr
Odesláno z mého zařízení Galaxy
-------- Původní zpráva --------
Od: Martin Mohler <martin(a)mohler.it <mailto:martin@mohler.it> >
Datum: 20.09.21 21:40 (GMT+01:00)
Komu: community-list(a)lists.vpsfree.cz <mailto:community-list@lists.vpsfree.cz>
Předmět: [vpsFree.cz: community-list] Jak vyřešit high availability na VPS
Ahoj,
dneska se mi stala zajímavá věc. Spravuji VPS pro klienta u jedné nejmenované společnosti. Jsem s nimi velmi a dlouhodobě spokojen. Mám u nich více VPS s různými projekty klientů a až na pár maličkostí jsem maximálně spokojen. Zejména oproti zkušenostem s jinými společnostmi, kde projekty původně běželi.
Dnes u nich ale došlo k HW problému a měli výpadek, který ale do hodinky vyřešili migrací VPS na jiný node. Dle zákonů schválnosti se tak stane, když klientovi společnost doporučíte.
Začal jsem uvažovat jak tomu předcházet. Řešením by byl load balancer, ale pokud budu mít VPSky ve dvou servrovnách, tak balancer na úrovni DNS neudělám, nebo nevím jak či u jakého poskytovatele bych to mohl nastavit. Další možnost je přidat VPS s nginx, ale pokud tato z jakéhokoliv důvodu vypadne, tak je to úplně jedno, že jsou VPS zrcadlené. Nemáte nějaký nápad, který momentálně nevidím jak vyřešit aby v případě problému s jedním poskytovatelem VPS přepnout v co nejkratším čase na jinou VPS v případě závažného problému? Další věcí je synchronizace MySQL databáze, ale ta může být ze zálohy.
Mockrát díky za tipy a postřehy.
Díky, Š.
**
Dne 22. 09. 21 v 19:49 Ondra Flidr napsal(a):
> Knot v popredi kvuli vykonu a nenarocnosti, powerdns v pozadi protoze
> je spravovatelny ansiblem a mysql backend. Jediny drawback je, ze pri
> vytvareni novy zony ji musim udelat i na knotech. Kdybych mel vsude
> powerdns, zvladlo by to zakladat i domeny automaticky pres notify.
>
>
>
> Odesláno z mého zařízení Galaxy
>
>
> -------- Původní zpráva --------
> Od: Stepan Liska <stepan(a)comlinks.cz>
> Datum: 22.09.21 16:05 (GMT+01:00)
> Komu: "vpsFree.cz Community list" <community-list(a)lists.vpsfree.cz>
> Předmět: [vpsFree.cz: community-list] jaký DNS server (Bylo: Jak
> vyřešit high availability na VPS)
>
> Ahoj,
>
> Ondro, mohl bys, prosím, napsat argumenty proč jsi zvolil v pozadí
> powerdns a proč v popředí knot? (Já ještě konzervativně používám bind
> i pro dynamické updaty, master i slave v popředí a jiné servery
> vlastně neznám - tak proč se je učit).
>
> Děkuji,
> Štěpán.
>
>
> Dne 22. 09. 21 v 10:46 Ondra Flidr napsal(a):
>> DNS je distribuovane by design. Sance, ze selze cela root domena nebo
>> cely rozumny tld je minimalni, to je riziko, co prijimam. Pak uz je
>> to na provozu vlastni DNS infrastruktury, mit minimalne 2 nody ve 2
>> ruznych sitich a za nimi hidden master node. Tim je docela slusna
>> sance, ze to bude fungovat. Pouzivam powerdns jako hidden mastera a
>> knot na zbytku. Samozrejme to nechrani pred uzivatelskou chybou, ale
>> to zadna replikace.
>>
>>
>> Ondra Flidr
>>
>> Odesláno z mého zařízení Galaxy
>>
>>
>
>
> _______________________________________________
> Community-list mailing list
> Community-list(a)lists.vpsfree.cz
> http://lists.vpsfree.cz/listinfo/community-list
Ahoj,
Ondro, mohl bys, prosím, napsat argumenty proč jsi zvolil v pozadí
powerdns a proč v popředí knot? (Já ještě konzervativně používám bind i
pro dynamické updaty, master i slave v popředí a jiné servery vlastně
neznám - tak proč se je učit).
Děkuji,
Štěpán.
Dne 22. 09. 21 v 10:46 Ondra Flidr napsal(a):
> DNS je distribuovane by design. Sance, ze selze cela root domena nebo
> cely rozumny tld je minimalni, to je riziko, co prijimam. Pak uz je to
> na provozu vlastni DNS infrastruktury, mit minimalne 2 nody ve 2
> ruznych sitich a za nimi hidden master node. Tim je docela slusna
> sance, ze to bude fungovat. Pouzivam powerdns jako hidden mastera a
> knot na zbytku. Samozrejme to nechrani pred uzivatelskou chybou, ale
> to zadna replikace.
>
>
> Ondra Flidr
>
> Odesláno z mého zařízení Galaxy
>
>
Priznam se ze nevim tolik co umi haproxy/nginx, ale co se rychle divam, tak prave ten GSLB nebo mozna vice algoritmu pro LB, ale nerikam, ze to nejde udelat jinak. Kazdy problem ma vice moznych reseni a cest. Tohle se proste jednoduse nastavuje v webovem UI.
kapi
From: Ondra Flidr
Sent: Wednesday, September 22, 2021 9:37 AM
To: vpsFree.cz Community list
Subject: Re: [vpsFree.cz: community-list] Jak vyřešit high availability na VPS
Na rovinu - co ta vec umi navic pred haproxy nebo nginxem? Samotny balancer musi byt taky v HA a jsme tam, kde jsme byli - bud prepinana IP v ramci jednoho DC nebo anycast a tedy vlastni AS.
Ondra Flidr
Odesláno z mého zařízení Galaxy
-------- Původní zpráva --------
Od: Jirka Knapek <jirka(a)kapi.cz>
Datum: 22.09.21 6:46 (GMT+01:00)
Komu: "vpsFree.cz Community list" <community-list(a)lists.vpsfree.cz>
Předmět: Re: [vpsFree.cz: community-list] Jak vyřešit high availability na VPS
Ahoj Martine,
jde to udělat i pomocí load balanceru, používám na to v práci Kemp LoadMaster, který dokáže směrovat DNS kam je potřeba. Máme to nasazené v Brně a US jen to je celá VM, pak dokážeš směrovat uživatele na základě dotazu DNS.
Mají i řešení pro malé projekty, které je zadarmo - https://freeloadbalancer.com/ který by GSLB měl také dokázat. Jen s tím časem tam může být trošku problém podle nastavení TTL u DNS. Já to musel nastavit na hodinu, když to bylo moc krátké tak ve scenáriu, kdy já používám obě DC jako aktivní a uživatelé jdou do bližšího, tak docházelo k problémům, protože jim to dávalo různé cílové adresy. Pro záložní případ by to asi nedělalo neplechu.
kapi
From: Martin Mohler
Sent: Monday, September 20, 2021 9:40 PM
To: community-list(a)lists.vpsfree.cz
Subject: [vpsFree.cz: community-list] Jak vyřešit high availability na VPS
Ahoj,
dneska se mi stala zajímavá věc. Spravuji VPS pro klienta u jedné nejmenované společnosti. Jsem s nimi velmi a dlouhodobě spokojen. Mám u nich více VPS s různými projekty klientů a až na pár maličkostí jsem maximálně spokojen. Zejména oproti zkušenostem s jinými společnostmi, kde projekty původně běželi.
Dnes u nich ale došlo k HW problému a měli výpadek, který ale do hodinky vyřešili migrací VPS na jiný node. Dle zákonů schválnosti se tak stane, když klientovi společnost doporučíte.
Začal jsem uvažovat jak tomu předcházet. Řešením by byl load balancer, ale pokud budu mít VPSky ve dvou servrovnách, tak balancer na úrovni DNS neudělám, nebo nevím jak či u jakého poskytovatele bych to mohl nastavit. Další možnost je přidat VPS s nginx, ale pokud tato z jakéhokoliv důvodu vypadne, tak je to úplně jedno, že jsou VPS zrcadlené. Nemáte nějaký nápad, který momentálně nevidím jak vyřešit aby v případě problému s jedním poskytovatelem VPS přepnout v co nejkratším čase na jinou VPS v případě závažného problému? Další věcí je synchronizace MySQL databáze, ale ta může být ze zálohy.
Mockrát díky za tipy a postřehy.
Zkouším se na to podívat jinak. Problém může nastat kdekoliv. V datacentru
(např. OVH), na úrovni domény a DNS záznamů (např.: Subreg/Gransy) a nebo
prostě selžou klíčové uzly jak se to stalo Google. Máte nějaké best
practice jak být na to připraven nebo jak postupovat? Máte nějaký
disaster plan pro tyto situace?
On Wed, Sep 22, 2021 at 9:37 AM Ondra Flidr <me(a)ondrejflidr.cz> wrote:
> Na rovinu - co ta vec umi navic pred haproxy nebo nginxem? Samotny
> balancer musi byt taky v HA a jsme tam, kde jsme byli - bud prepinana IP v
> ramci jednoho DC nebo anycast a tedy vlastni AS.
>
> Ondra Flidr
>
>
>
> Odesláno z mého zařízení Galaxy
>
>
> -------- Původní zpráva --------
> Od: Jirka Knapek <jirka(a)kapi.cz>
> Datum: 22.09.21 6:46 (GMT+01:00)
> Komu: "vpsFree.cz Community list" <community-list(a)lists.vpsfree.cz>
> Předmět: Re: [vpsFree.cz: community-list] Jak vyřešit high availability na
> VPS
>
> Ahoj Martine,
>
>
>
> jde to udělat i pomocí load balanceru, používám na to v práci Kemp
> LoadMaster, který dokáže směrovat DNS kam je potřeba. Máme to nasazené
> v Brně a US jen to je celá VM, pak dokážeš směrovat uživatele na základě
> dotazu DNS.
>
> Mají i řešení pro malé projekty, které je zadarmo -
> https://freeloadbalancer.com/ který by GSLB měl také dokázat. Jen s tím
> časem tam může být trošku problém podle nastavení TTL u DNS. Já to musel
> nastavit na hodinu, když to bylo moc krátké tak ve scenáriu, kdy já
> používám obě DC jako aktivní a uživatelé jdou do bližšího, tak docházelo
> k problémům, protože jim to dávalo různé cílové adresy. Pro záložní případ
> by to asi nedělalo neplechu.
>
>
>
> kapi
>
>
>
> *From: *Martin Mohler <martin(a)mohler.it>
> *Sent: *Monday, September 20, 2021 9:40 PM
> *To: *community-list(a)lists.vpsfree.cz
> *Subject: *[vpsFree.cz: community-list] Jak vyřešit high availability na
> VPS
>
>
>
> Ahoj,
>
> dneska se mi stala zajímavá věc. Spravuji VPS pro klienta u jedné
> nejmenované společnosti. Jsem s nimi velmi a dlouhodobě spokojen. Mám u
> nich více VPS s různými projekty klientů a až na pár maličkostí jsem
> maximálně spokojen. Zejména oproti zkušenostem s jinými společnostmi, kde
> projekty původně běželi.
>
>
>
> Dnes u nich ale došlo k HW problému a měli výpadek, který ale do hodinky
> vyřešili migrací VPS na jiný node. Dle zákonů schválnosti se tak stane,
> když klientovi společnost doporučíte.
>
>
>
> Začal jsem uvažovat jak tomu předcházet. Řešením by byl load balancer, ale
> pokud budu mít VPSky ve dvou servrovnách, tak balancer na úrovni DNS
> neudělám, nebo nevím jak či u jakého poskytovatele bych to mohl nastavit.
> Další možnost je přidat VPS s nginx, ale pokud tato z jakéhokoliv důvodu
> vypadne, tak je to úplně jedno, že jsou VPS zrcadlené. Nemáte nějaký nápad,
> který momentálně nevidím jak vyřešit aby v případě problému s jedním
> poskytovatelem VPS přepnout v co nejkratším čase na jinou VPS v
> případě závažného problému? Další věcí je synchronizace MySQL databáze, ale
> ta může být ze zálohy.
>
>
>
> Mockrát díky za tipy a postřehy.
>
>
> _______________________________________________
> Community-list mailing list
> Community-list(a)lists.vpsfree.cz
> http://lists.vpsfree.cz/listinfo/community-list
>
Na rovinu - co ta vec umi navic pred haproxy nebo nginxem? Samotny balancer musi byt taky v HA a jsme tam, kde jsme byli - bud prepinana IP v ramci jednoho DC nebo anycast a tedy vlastni AS.Ondra FlidrOdesláno z mého zařízení Galaxy
-------- Původní zpráva --------Od: Jirka Knapek <jirka(a)kapi.cz> Datum: 22.09.21 6:46 (GMT+01:00) Komu: "vpsFree.cz Community list" <community-list(a)lists.vpsfree.cz> Předmět: Re: [vpsFree.cz: community-list] Jak vyřešit high availability na VPS Ahoj Martine, jde to udělat i pomocí load balanceru, používám na to v práci Kemp LoadMaster, který dokáže směrovat DNS kam je potřeba. Máme to nasazené v Brně a US jen to je celá VM, pak dokážeš směrovat uživatele na základě dotazu DNS.Mají i řešení pro malé projekty, které je zadarmo - https://freeloadbalancer.com/ který by GSLB měl také dokázat. Jen s tím časem tam může být trošku problém podle nastavení TTL u DNS. Já to musel nastavit na hodinu, když to bylo moc krátké tak ve scenáriu, kdy já používám obě DC jako aktivní a uživatelé jdou do bližšího, tak docházelo k problémům, protože jim to dávalo různé cílové adresy. Pro záložní případ by to asi nedělalo neplechu. kapi From: Martin MohlerSent: Monday, September 20, 2021 9:40 PMTo: community-list(a)lists.vpsfree.czSubject: [vpsFree.cz: community-list] Jak vyřešit high availability na VPS Ahoj,dneska se mi stala zajímavá věc. Spravuji VPS pro klienta u jedné nejmenované společnosti. Jsem s nimi velmi a dlouhodobě spokojen. Mám u nich více VPS s různými projekty klientů a až na pár maličkostí jsem maximálně spokojen. Zejména oproti zkušenostem s jinými společnostmi, kde projekty původně běželi. Dnes u nich ale došlo k HW problému a měli výpadek, který ale do hodinky vyřešili migrací VPS na jiný node. Dle zákonů schválnosti se tak stane, když klientovi společnost doporučíte. Začal jsem uvažovat jak tomu předcházet. Řešením by byl load balancer, ale pokud budu mít VPSky ve dvou servrovnách, tak balancer na úrovni DNS neudělám, nebo nevím jak či u jakého poskytovatele bych to mohl nastavit. Další možnost je přidat VPS s nginx, ale pokud tato z jakéhokoliv důvodu vypadne, tak je to úplně jedno, že jsou VPS zrcadlené. Nemáte nějaký nápad, který momentálně nevidím jak vyřešit aby v případě problému s jedním poskytovatelem VPS přepnout v co nejkratším čase na jinou VPS v případě závažného problému? Další věcí je synchronizace MySQL databáze, ale ta může být ze zálohy. Mockrát díky za tipy a postřehy.
Ahoj,
dneska se mi stala zajímavá věc. Spravuji VPS pro klienta u jedné
nejmenované společnosti. Jsem s nimi velmi a dlouhodobě spokojen. Mám u
nich více VPS s různými projekty klientů a až na pár maličkostí jsem
maximálně spokojen. Zejména oproti zkušenostem s jinými společnostmi, kde
projekty původně běželi.
Dnes u nich ale došlo k HW problému a měli výpadek, který ale do hodinky
vyřešili migrací VPS na jiný node. Dle zákonů schválnosti se tak stane,
když klientovi společnost doporučíte.
Začal jsem uvažovat jak tomu předcházet. Řešením by byl load balancer, ale
pokud budu mít VPSky ve dvou servrovnách, tak balancer na úrovni DNS
neudělám, nebo nevím jak či u jakého poskytovatele bych to mohl nastavit.
Další možnost je přidat VPS s nginx, ale pokud tato z jakéhokoliv důvodu
vypadne, tak je to úplně jedno, že jsou VPS zrcadlené. Nemáte nějaký nápad,
který momentálně nevidím jak vyřešit aby v případě problému s jedním
poskytovatelem VPS přepnout v co nejkratším čase na jinou VPS v
případě závažného problému? Další věcí je synchronizace MySQL databáze, ale
ta může být ze zálohy.
Mockrát díky za tipy a postřehy.
Ahoj,
dnes jsme zprovoznili node5.brq, první node s vpsAdminOS v Brně.
Kdo máte zájem o přesun z OpenVZ, můžete napsat na podporu. Na
vpsAdminOS přidělujeme také /64 IPv6 adresy, můžete si je vyměnit i sami
přes vpsAdmin za ty /128 z OpenVZ, viz
https://blog.vpsfree.cz/umime-pridelit-kazdemu-serveru-vlastni-blok-64-adre…
Prozatím to bude složitější s přístupem na NAS. Z vpsAdminOS v Brně se
teď na NAS dostanete, jen když máte jako první na síťovém rozhraní
privátní adresu. To ale znamená, že provoz do internetu půjde přes NAT,
tj. jako zdrojová adresa se nepoužije ta veřejná, protože není první.
Je to kvůli tomu, že na vpsAdminOS se exporty NASu připojují zevnitř
VPS. Na OpenVZ mounty připojoval vpsAdmin z hostitele a na síti uvnitř
VPS tak nezáleželo.
Časem bychom to chtěli vyřešit tak, že na privátní adresy/NAS uděláme
druhé síťové rozhraní. To by ale zase trvalo dlouho a už jsme nechtěli
nasazení vpsAdminOS v Brně odkládat.
Jakub
Ahoj,
pokud se nemýlím, tak jdou dvě možnosti. Můžeš vytvořit dva node, mezi které
rozdělis přiděleny prostor, disk a rám.
Kdyby to bylo málo, můžeš k účtu dokoupit další kapacitu.
P. B.
"---------- Původní zpráva ----------
Od: Filip Bartmann <filip.bartmann(a)gmail.com>
Datum: 13.09.2021 14:09:10
Předmět: [vpsFree.cz: community-list] Provoz více VPS na jeden účet
Ahoj,
je možné využívat více VPS na jednom účtu? Mám jednu svou VPS a druhou bych
potřeboval pro zákazníka, který chce mít VPS přeze mně.
Děkuji,
Filip Bartmann
"
Ahoj,
je možné využívat více VPS na jednom účtu? Mám jednu svou VPS a druhou bych
potřeboval pro zákazníka, který chce mít VPS přeze mně.
Děkuji,
Filip Bartmann
-------- Přeposlaná zpráva --------
Předmět: debian upgrade
Datum: Wed, 18 Aug 2021 15:35:53 +0200
Od: Petr Bolf <petr.bolf(a)taborpolana.cz>
Komu: podpora(a)vpsfree.cz
zdravím,
obgraduji na Debian 11 a po spuštění apt upgrade mám tuto chybu. Co to
může být. dík
Pokud používáte docker, nebo něco jiného co staví na cgroups, a jste na
vpsAdminOS, je důležité po přechodu na Debian 11 aktualizovat info o
distribuci ve vpsAdminu v detailu VPS.
Bullseye totiž používá ve výchozím stavu cgroupv2 a vpsAdminOS zatím
staví na cgroupv1. VPS jsou kontejnery a dědí cgroup v1 controllery,
takže controllery ve v2 nejsou k dispozici. Přenastavením distribuce ve
vpsAdminu se u VPS nastaví parametr systemd, který vynutí použití v1.
Podpora cgroupv2 bude teď asi moje priorita, o tom více někdy později až
to bude. Pokud se bez toho nějaké aplikace už neobejdou, tak prosím
urgovat. Co vím, tak se zatím vždy dá nějakým způsobem nastavit použití
cgroupv1.
Jakub
Ahojte,
puvodne jsem tohle tema nechtel otevirat, protoze jsem doufal, ze se
cela situace okolo Freenode nejak rozumne uklidni, az dohori emoce,
protoze jsem si myslel, ze je skoro jedno, kdo tu IRC sit spravuje, bo
snad vsude maji zajem na tom, aby jim lidi neodchazeli... ale evidentne
na Freenodu se to rozhodli dopohrbit uplne.
Ted se rozhodli zabanovat IRCCloud, tj. nikdo se z te site uz na
Freenode nepripoji. Oficialni vyjadreni na #freenode, proc byl IRCCloud
zabanovan: "because fuck irccloud".
To je trochu moc uz, rekl bych...
Vzhledem k tomu, jak se to s IRC semlelo a ze spousta IRC-related
vyvojaru se na IRC diky explozi okolo Freenodu vykaslala uplne, bych se
klonil spis tedy k odchodu z IRC uplne. Nemyslim, ze by cely ten
protokol mel pred sebou nejakou zarnou budoucnost, to uz bude, myslim
si, jenom pomalu umirat.
Otazka je, kam se tedy presunout...
Osobne je mym favoritem Matrix, ne tedy kvuli dnesnimu stavu, ktery je
takovy mirne neuteseny, ale spis kvuli potencialu do budoucna. Ted je
Matrix tvoreny hlavne Element klienty a Synapse self-hosted server
instancemi, coz neni uplne vyhra, protoze web klient a Python-based
server implikuji s IRC neporovnatelne naroky na server i klienty.
Ale zase Dendrite (prepis server side do Golangu, s planovanou podporou
HA, atd...) a Fractal-next (klient, GTK-based) vypadaji dost slibne...
Myslim, ze to ma docela budoucnost.
Co si o tom myslite?
Prejdeme na Matrix, nebo zustaneme na IRC a presuneme se jen na jinou
sit?
/snajpa
Ahoj,
sorry za spam, jsem tu v komunitě novej, ale potřeboval bych vytrhnout trn
z paty, jedna z našich vpsek (kde máme zejména weby cca do 10ks) je
nakažena malwarem (běží tam schovaný pseudo cron.d což je kamuflovaný XMRig
na mining monera).
Co bych potřeboval:
- kompletní reinstalaci serveru z Debian8 na 10, respektive komplet install
- instalaci Webminu
- znovumigraci a spuštění webů ve Wordpressu včetně SSL certifikátů
- základní nastavení bezpečnosti
asi bych to dokázal i sám, ale raději bych to svěřil nějakému zkušenému
linuxáři, co zároveň umí pracovat i s vpsadminem (běží to ještě na legacy
VZ, což bychom rovnou mohli přehodit taky).
Docela to hoří vzhledem k tomu běžícímu malware, přesun by bylo ideální
udělat o víkendu v noci.
Koho by to zajímalo, prosím private mail přímo na mě, díky moc!
dan
--
<https://www.fragile.cz/?utm_source=email&utm_medium=podpis>
Daniel Kafka / Founder
M: daniel.kafka(a)fragile.cz T: +420 777 177 570 <+420777177570>
Fragile / agentura pro digitální marketing
Jankovcova 1037/49, 170 00 Praha 7
<https://www.fragile.cz/?utm_source=email&utm_medium=podpis>
<https://www.linkedin.com/company/fragile-agency/>
<https://www.facebook.com/fragile.agency/>
<https://www.instagram.com/fragile.agency/> <https://fragile.cz/mail-link>
Ahoj,
pokouším se naistalovat GNOME rozhraní na Ubuntu 20.04 s VNC serverem ale
vyhodí mě to error po zavolání *sudo apt install ubuntu-gnome-desktop*.
Postupuji podle tohoto návodu:
https://www.teknotut.com/en/install-vnc-server-with-gnome-display-on-ubuntu…
(vím
o tom, že návod je na 18.04)
Errors were encountered while processing:
libfprint-2-2:amd64
fprintd
libpam-fprintd:amd64
udisks2
gvfs-daemons
gvfs-backends
gnome-disk-utility
usb-creator-common
gvfs:amd64
usb-creator-gtk
gvfs-fuse
nautilus
ubuntu-desktop
gnome-shell-extension-desktop-icons
ubuntu-desktop-minimal
nautilus-share
ubuntu-gnome-desktop
E: Sub-process /usr/bin/dpkg returned an error code (1)
Díky všem za jakoukoliv pomoc.
Honza
Ahoj,
píšu takhle večer a jsem unavený, tak se nezlobte zda jsem přehlédl
nějkou blbost, ale při upgradu systému (Arch Linux) na svojí VPS jsem
narazil na problém, že mi přestal chodit docker. Oprava je na konci
emailu, tak třeba to někomu ušetří trochu práce a stresu.
Update prošel podle následujícího logu:
[2021-04-15T22:20:10+0200] [ALPM] transaction started
[2021-04-15T22:20:10+0200] [ALPM] upgraded borg (1.1.16-1 -> 1.1.16-2)
[2021-04-15T22:20:10+0200] [ALPM] upgraded run-parts (4.8.6.1-2 -> 4.11.2-1)
[2021-04-15T22:20:10+0200] [ALPM] upgraded libxcrypt (4.4.18-1 -> 4.4.19-1)
[2021-04-15T22:20:10+0200] [ALPM] upgraded cronie (1.5.6-1 -> 1.5.7-2)
[2021-04-15T22:20:10+0200] [ALPM] upgraded systemd-libs (247.4-2 -> 248-4)
[2021-04-15T22:20:10+0200] [ALPM] upgraded cryptsetup (2.3.5-1 -> 2.3.5-4)
[2021-04-15T22:20:11+0200] [ALPM] upgraded curl (7.75.0-1 -> 7.76.1-1)
[2021-04-15T22:20:11+0200] [ALPM] upgraded sqlite (3.35.3-1 -> 3.35.4-1)
[2021-04-15T22:20:13+0200] [ALPM] upgraded expat (2.2.10-2 -> 2.3.0-1)
[2021-04-15T22:20:15+0200] [ALPM] upgraded docker (1:20.10.5-1 -> 1:20.10.6-1)
[2021-04-15T22:20:15+0200] [ALPM] upgraded libnsl (1.3.0-1 -> 1.3.0-2)
[2021-04-15T22:20:17+0200] [ALPM] upgraded python (3.9.2-1 -> 3.9.3-1)
[2021-04-15T22:20:17+0200] [ALPM] upgraded python-docker (4.4.4-1 -> 5.0.0-1)
[2021-04-15T22:20:17+0200] [ALPM] upgraded python-dotenv (0.16.0-1 -> 0.17.0-1)
[2021-04-15T22:20:17+0200] [ALPM] upgraded docker-compose (1.28.6-1 -> 1.29.1-1)
[2021-04-15T22:20:17+0200] [ALPM] upgraded file (5.39-1 -> 5.40-2)
[2021-04-15T22:20:18+0200] [ALPM] upgraded glib2 (2.68.0-5 -> 2.68.1-1)
[2021-04-15T22:20:18+0200] [ALPM] warning: /etc/pacman.d/mirrorlist installed as /etc/pacman.d/mirrorlist.pacnew
[2021-04-15T22:20:18+0200] [ALPM] upgraded pacman-mirrorlist (20210302-1 -> 20210405-1)
[2021-04-15T22:20:19+0200] [ALPM] warning: /etc/systemd/system.conf installed as /etc/systemd/system.conf.pacnew
[2021-04-15T22:20:19+0200] [ALPM] upgraded systemd (247.4-2 -> 248-4)
[2021-04-15T22:20:19+0200] [ALPM-SCRIPTLET] Creating group sgx with gid 973.
[2021-04-15T22:20:19+0200] [ALPM-SCRIPTLET] Creating group systemd-oom with gid 972.
[2021-04-15T22:20:19+0200] [ALPM-SCRIPTLET] Creating user systemd-oom (systemd Userspace OOM Killer) with uid 972 and gid 972.
[2021-04-15T22:20:20+0200] [ALPM] upgraded systemd-sysvcompat (247.4-2 -> 248-4)
[2021-04-15T22:20:20+0200] [ALPM] transaction completed
Potom začal ale docker při spouštění triviálních věcí (docker run hello-world) nechávat tyto věci na terminálu i v journálu:
Apr 15 22:55:26 mouflon dockerd[2006]: time="2021-04-15T22:55:26.728977443+02:00" level=error msg="Handler for POST /v1.41/containers/fc72a2108933f3f8fd557151a9b46c79aec1fa3acb71f0e30af4ca9e40b7b29f/start returned error: OCI runtime create failed: container_linux.go:367: starting container process caused: process_linux.go:495: container init caused: process_linux.go:458: setting cgroup config for procHooks process caused: can't load program: operation not permitted: unknown"
... Říkal jsem si, že to otestuju na staging a ověřím, co je přesně
problém, ale na stagingu (čerstvě vytvořená vps 19335) mi nefunguje
šablona Arch Linuxu:
# pacman -Syy docker
[...]
error: libxcrypt: signature from "Christian Hesse <eworm(a)archlinux.org>" is unknown trust
:: File /var/cache/pacman/pkg/libxcrypt-4.4.19-1-x86_64.pkg.tar.zst is corrupted (invalid or corrupted package (PGP signature)).
... Nakonec jsem downgradoval docker na 1:20.10.5-1, to ale nestačilo.
Downgradoval jsem tedy také systemd* na 247.4-2 (systemd, systemd-libs,
systemd-sysvcompat), to taky nepomohlo, ale po restartu vps už to celé
zabralo.
V tuhle hodinu už to debugovat nechci, zítra se podívám jestli to nějak
umím doklepnout v té staging vpsce.
Kdyby náhodou někdo věděl co se děje, rád si ušetřím práci.
Zdar a dobrou noc,
s pozdravem Ladislav Láska
Pretoze ak riesis abuse, mozes tam mat link/mail a registrator to vie stejne,
koho to je, ale neviem preco to davat do whois. Viem, lebo jeden cas som v
CZ.NIC robil a i ked je tam vyplnene hocico, tak staznost na domenu staci (ze
porusuje take a take pravidlo), ani nepotrebujes vediet koho bola, len nejaky dokaz.
OM
On 2021-04-06 17:45, me wrote:
> mojeID skryje kontaktni udaje typu email a telefon, nikoliv jmeno/nazev
> drzitele, ktery navic dost pravdepodobne nebude osobnim udajem v tomhle scopu a
> urcite nevede k identifikaci konkretni osoby dle GDPR.
>
> Proc vlastne schovavat udaje ve whois? Akorat to znemoznuje abuse reporty.
>
> Ondra
>
>
>
> Odesláno z mého zařízení Galaxy
>
>
> -------- Původní zpráva --------
> Od: Jirka Bourek <vpsfree-list(a)keroub.cz>
> Datum: 06.04.21 17:25 (GMT+01:00)
> Komu: community-list(a)lists.vpsfree.cz
> Předmět: Re: [vpsFree.cz: community-list] Doporučení registrátora domény
>
> V registru je jedna věc, ale whois je věc jiná. A řekl bych, že kdyby to
> "nešlo" (mám za to, že podmínkou skrytí údajů bylo mít MojeID), tak by
> stačilo, aby se našel někdo dostatečně aktivní a začal poukazovat na GDPR.
>
> On 06. 04. 21 15:11, me(a)ondrejflidr.cz wrote:
>> Anonymizovat .cz domeny nelze, v registru musi byt uveden skutecny
>> vlastnik. Nesouhlas/nesmyslna data ve whois mohou vest ke zruseni domeny.
>>
>> Ondra
>>
>> On 2021-04-06 14:58, Ondrej Mikle wrote:
>>> Umi subreg anonymizovat data i u .cz domeny?
>>>
>>> Protoze snad podle pravidel CZ.NIC se musi uvadet vlastnik, kvuli tomu
>>> jsem
>>> resil mojeid, ale stejne je tam jmeno.
>>>
>>> Lze teda nejak anonymizovat u subregu whois pro .cz domeny?
>>>
>>> (vynecham rant o mojeid, kolik se do toho sype rocne, kolik mrtvych
>>> dusi tam
>>> maji, uzitecnosti, absurdity kolem U2F/FIDO certifikace kdyz dovoluji
>>> softwarovy
>>> windows token)
>>>
>>> OM
>>>
>>> On 2021-04-06 11:46, Josef Rudolf wrote:
>>>> Zdarec.
>>>> Já používám SubReg. https://subreg.cz/
>>>> Poskytuje i možnost anonymizovat whois data.
>>>>
>>>> ---------- Původní e-mail ----------
>>>> Od: Lukáš Hrázký <lukkash(a)email.cz>
>>>> Komu: vpsFree.cz Community list <community-list(a)lists.vpsfree.cz>
>>>> Datum: 6. 4. 2021 11:33:59
>>>> Předmět: [vpsFree.cz: community-list] Doporučení registrátora domény
>>>>
>>>>
>>>> Čaute,
>>>>
>>>> sháním kvalitního registrátora domény, požadavky:
>>>>
>>>> - sídlo v EU
>>>> - nějaký whois privacy guard
>>>>
>>>> Případné tipy co si ještě hlídat uvítám.
>>>>
>>>> Co používáte vy?
>>>>
>>>> Díky,
>>>> Lukáš
>>>>
>>>> _______________________________________________
>>>> 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
> _______________________________________________
> 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
>
Pokud se jmenujete Josef Novák, tak ano, jméno nevede k identifikaci
konkrétní osoby. Jenže ne všichni se jmenujeme, Josef Novák, že...
Abuse reporty se posílají na e-mail, takže skrytí jména je neznemožňuje...?
On 06. 04. 21 17:45, me wrote:
> mojeID skryje kontaktni udaje typu email a telefon, nikoliv jmeno/nazev drzitele, ktery navic dost pravdepodobne nebude osobnim udajem v tomhle scopu a urcite nevede k identifikaci konkretni osoby dle GDPR.Proc vlastne schovavat udaje ve whois? Akorat to znemoznuje abuse reporty.
Čaute,
sháním kvalitního registrátora domény, požadavky:
- sídlo v EU
- nějaký whois privacy guard
Případné tipy co si ještě hlídat uvítám.
Co používáte vy?
Díky,
Lukáš
Zdravím, jsem na vpsFree nově, chtěl jsem si nastavit nftables, ale stále
mi hlásí chybu, když chci vytvořit novou tabulku, případně cokliv jiného
Při startu hlásí obdobnou chybu.
/etc/nftables.conf:12:15-20: Error: Could not process rule: Invalid argument
Nemáte, prosím, někdo zkušenosti s nfttables na vpsFree, případně nějaký
odkaz, kde něco zjistit? Zkoušel jsem knowledge base, ale tam jsou pouze
stránky o IPTables.
Z toho, co jsem dohledal, mi přijde, že se nenačítá modul nftables, ale
nevím proč.
Díky za jakoukliv radu,
Honza Mrázek
Ahoj,
FirewallD se mi na Debian 10 odmita spustit. VPSka je na NIXOS. Poradite mi prosim jak to rozjet? :]
Diky
● firewalld.service - firewalld - dynamic firewall daemon
Loaded: loaded (/lib/systemd/system/firewalld.service; enabled; vendor preset: enabled)
Active: inactive (dead) since Sun 2021-02-28 08:32:18 UTC; 10min ago
Docs: man:firewalld(1)
Process: 83 ExecStart=/usr/sbin/firewalld --nofork --nopid (code=exited, status=0/SUCCESS)
Main PID: 83 (code=exited, status=0/SUCCESS)
Feb 28 08:32:18 polaris systemd[1]: Starting firewalld - dynamic firewall daemon...
Feb 28 08:32:18 polaris systemd[1]: Started firewalld - dynamic firewall daemon.
Feb 28 08:32:18 polaris firewalld[83]: ERROR: Failed to load nf_conntrack module: modprobe: ERROR: ../libkmod/libkmod.c:586 kmod_search_moddep() could not open moddep file '/lib/modules/5.10.12/modules.dep.bin'
modprobe: FATAL: Module nf_conntrack not found in directory /lib/modules/5.10.12
Feb 28 08:32:18 polaris firewalld[83]: ERROR: Raising SystemExit in run_server
Feb 28 08:32:18 polaris systemd[1]: firewalld.service: Succeeded.
slozka /lib/modules je prazdna.
Dobrý den,
snažím se připojit SMB sdílení na VPS, ale píče mi to:
-------------------------------------------------------------------------
[root@vps ~]# mount -vvv -t cifs //4799.disk.zonercloud.net/4799 /backup/
-o user=4799 -o password=heslonejake
mount.cifs kernel mount options: ip=2a00:19a0:3:72:0:d9c6:72bf:1,unc=\\
4799.disk.zonercloud.net\4799,user=4799,pass=********
mount error(1): Operation not permitted
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs) and kernel log
messages (dmesg)
-------------------------------------------------------------------------
Přitom když si zkusím sdílení připojit na PC, tak to projde bez problémů.
Co dělám špatně?
Děkuji,
Filip Bartmann
Ahoj,
(English version below)
Ve vpsAdminu přibyla možnost nastartovat VPS z čistého systému ze
šablony a obejít tak systém na disku VPS. Je to něco jako boot live CD.
Můžete se tak zvenku dostat k disku VPS. Bude se to hodit např. když VPS
nestartuje a je potřeba opravit nějaký config, balíčkovací systém nebo
cokoliv jiného. Taky je to možnost jak do VPS dostat jakýkoliv systém
mimo šablony distribucí, které jsou k dispozici ve vpsAdminu.
VPS nastartovaná v nouzovém režimu má úplně stejnou konfiguraci: IP
adresy, hostname, DNS resolvery, features, atp. Pokud máte ve vpsAdminu
nastavené SSH klíče, taky se tam nahrají.
VPS můžete do nouzového režimu nastartovat buď z detailu VPS, formulář
"Boot VPS from template", nebo přímo ze stránky se vzdálenou konzolí
VPS. Původní disk VPS je ve výchozím stavu připojen do adresáře
`/mnt/vps`. Jakkoli vyvolaným restartem VPS nouzový režim opustíte a VPS
nastartuje zase ze svého disku. Systém použitý pro nouzový režim je
dočasný a po restartu se smaže.
Nouzový režim je pouze pro VPS na vpsAdminOS [1]. Na OpenVZ Legacy [2]
podporujeme jiný přístup: dataset jedné VPS je možné připojit do jiné
VPS, takže třeba produkční VPS se dá opravit z playgroundu. Na
vpsAdminOS jsme o tuto možnost přišli a tak se teď vrací v jiné podobě.
Osobně se mi tenhle způsob líbí mnohem víc.
V budoucnu bych chtěl do vpsfreectl [3] dodělat možnost přes nouzový
režim obnovit VPS ze stažené zálohy, včetně zachování nastavení
vpsAdminu. Jinak můžete nouzový režim na obnovu ze stažené zálohy
používat už teď -- stačí systém ze zálohy nahrát do `/mnt/vps`.
Více info jak opravit rozbitou VPS a screenshoty viz KB:
https://kb.vpsfree.cz/navody/vps/vpsadminos/oprava
ENGLISH:
There's a new option in vpsAdmin to start VPS from a clean system using
one of our templates and thus bypass the VPS's own system. You can think
of it as booting a live CD. It can be used to access data on the VPS's
root filesystem from the outside. This is useful e.g. when the VPS is
not starting and you need to fix some configuration inside, fix the
packaging system, etc. It's also a way to install whatever system inside
the VPS outside of the templates available in vpsAdmin.
VPS started in the rescue mode has the same configuration: IP addresses,
hostname, DNS resolvers, features, etc. If you have configured SSH keys
in vpsAdmin, they'll be deployed as well.
To start the VPS in the rescue mode, head to VPS details in vpsAdmin,
it's a form labeled "Boot VPS from template". You can also access the
rescue mode from the page with VPS remote console. The original VPS disk
is by default mounted to the rescue system at `/mnt/vps`. To leave the
rescue mode, simply restart the VPS. Any action that will cause the VPS
to restart will exit the rescue mode and the VPS will start from its own
disk again. The system used for the rescue mode is temporary and is
immediately deleted when the VPS is restarted.
This new rescue mode is available only for VPS running on vpsAdminOS
[4]. On OpenVZ Legacy [5], we support a different way: datasets of one
VPS can be mounted in another, so for example you can access a broken
production VPS from a playground VPS. Since we've lost this capability
with vpsAdminOS, it comes back now in another form. Personally I find
this rescue mode to be a better approach.
In the future I'd like to use the rescue mode in vpsfreectl [6] to
restore VPS from downloaded backups, including vpsAdmin configuration.
You could do this on your own even now, simply upload the system from
your backup to `/mnt/vps` within the rescue system.
For more information on how to access a broken VPS, see the KB:
https://kb.vpsfree.org/manuals/vps/vpsadminos/recovery
[1] https://kb.vpsfree.cz/navody/vps/vpsadminos
[2] https://kb.vpsfree.cz/informace/openvz
[3] https://kb.vpsfree.cz/navody/vps/api#cli
[4] https://kb.vpsfree.org/manuals/vps/vpsadminos
[5] https://kb.vpsfree.org/information/openvz
[6] https://kb.vpsfree.org/manuals/vps/api#cli
Jakub
zdar lidi,
řeším útok. Je to web, kde dělám údržbu databáze CMS. Nejsem síťař. Uměl
by někdo pomoci, odrazit to? Je to celkem akutní, takže za práci raději
zaplatíme, než se to nějak pokoušet sám spravit.
Attack detail : 9Kpps/4Mbps
dateTime srcIp:srcPort dstIp:dstPort protocol flags bytes reason
2021.02.09 03:14:16 CET 94.23.211.61:33782 39.26.27.117:23 TCP SYN 60
ATTACK:TCP_SYN
2021.02.09 03:14:16 CET 94.23.211.61:37242 118.20.135.83:2323 TCP SYN 60
ATTACK:TCP_SYN
2021.02.09 03:14:16 CET 94.23.211.61:33634
díky
Petr Bolf
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.
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 ;)
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
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
>>>
>>
>
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 *
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.
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
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
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
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
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
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 ;?
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ý
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
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
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
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
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
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 :)
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.
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
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
Ahojte vazeni clenove,
mame novy termin clenske schuze shrnujici rok 2019,
a sice 26. 6., od 18:30 v restauraci U Balbinu v Praze.
(Jungmannova 22, Praha 1, https://www.ubalbinu.cz/)
Program schuze:
1. Shrnuti roku 2019
- financni + organizacni + technicke shrnuti roku 2019
2. Plany na rok 2020 a dal
- orientace spolku v ekonomicke krizi
- vpsAdminOS, fakturace, web UI
3. Diskuze: socialni rozmer vpsFree, spoluprace ve spolku
- Navrh:
Pravidelne "office hours"
- tj. moznost se pravidelne potkat (mimo pivo)
- spolecne debugovani problemu
- postupne zapojeni dalsich lidi do fungovani spolku (neni-li to
naivni predstava)
- K zamysleni do schuze:
Co muze svym clenum vpsFree nabidnout nad zakladni myslenku sdileni
HW prostredku?
Co muzeme jako spolek nabidnout siroke verejnosti, je-li neco
takoveho?
Jak muzeme zapojit dalsi nadsence do toho, co delame?
Ktere formy propagace spolku jsou pro nas vhodne (a moralne
prijatelne)?
- napr. je OK reklama na FB? Je OK pouzit Google Analytics?
Jak to bude s konferencemi a vpsFree?
4. Volna zabava, rezervaci mame az do pulnoci.
Tesim se na vsechny, co si najdou cas a obzvlast na ty, kdo maji chut
prispet svymi napady do 3tiho bodu :)
Na miste budeme uz od 18:00, takze prijdte klidne driv (obzvlast, pokud
do Prahy prijedete driv).
Na videnou na schuzi! ;)
/snajpa
Ahoj,
přes týden jsem se snažil nastudovat nasazení Nginx jako proxy a vrtá mi
hlavou několik věcí. Chtěl jsem proto poprosit o radu zkušenější, abych
něco "nezkonil" hned na začátku :-)
1) Spojení mezi proxy a backendem
V jiném vlákně tady proběhla diskuze ohledně "vnitřních" IP adres. Na KB
jsem se dočetl, že se o ně musí žádat a můžou se měnit. Mají pro spojení
mezi proxy a backendem vnitřní adresy nějaký význam, například z
hlediska bezpečnosti nebo rychlosti? Můj plán byl dělat spojení mezi
stroji pomocí přidělených IPv6 adres.
2) Šifrování mezi proxy a backendem
Myslím, že v tom samém vlákně Snajpa psal něco ve smyslu, že na síti
mezi VPS je těžké odposlechnout provoz (myslím, že se tam řešili
privátní vlany nebo tak něco). Úplně se v tomhle neorientuji a proto
jsem se chtěl zeptat, zda byste v našem prostředí považovali za
bezpečné, kdybych SSL spojení ukončoval na proxy a mezi proxy a
backendem posílal jen klasické HTTP? Na webu Nginxu jsem našel, že je
možné mezi proxy a backendem rozjet také SSL spojení, ale nevím, zda to
není overkill.
3) SSH tunel na proxy
Aktuálně mám na serveru jednu stránku, pro kterou Nginx poslouchá na
127.0.0.1 a klienti se k ní propojují pomocí SSH tunelu a port
forwardingu. V případě nasazení jako "proxy - backend" bych na proxy
opět udělal server poslouchající na 127.0.0.1 a předávající požadavky na
proxy. Bude stačit, když na backendu pro tuto stránku nastavím omezení
přístupu jen z IP adresy proxy? Nebo bych to měl ošetřit ještě nějak dál?
Předem díky za pomoc!
Všechny zdraví
Honza
--
Jan B. Kolář
Zažeň nudu
Hodolanská 17, 779 00 Olomouc
tel: +420 605 800 859
e-mail: janbivoj.kolar(a)zazen-nudu.cz
www.zazen-nudu.cz
Zdravím,
posledních pár dní hodně čtu o IPv6 a v rámci shánění informací jsem našel mnoho článků, které adorují Nginx proti Apache2. Co jsem se díval, tak nastavit Nginx je stejně snadné jako Apache2 a navíc je na některé údajně rychlejší. Hlavně rychlost je co neustále řeším u klientů a tak bych ho rád vyzkoušel.
Tak se chci zeptat, lze na jednom serveru (Ubuntu 18) k Apache2 doinstalovat i Nginx, a ten nastavit, aby fungoval pouze pro IPv6 volání a do současného stavu se nepletl? Tedy aby se neprali o port 80, ale Nginx bych si pokusně hodil jen na IPv6 volání (a přidal HTTPS). Případně, aby Nginx obsluhoval HTTPS a Apache2 HTTP? Nikde tuto informaci nemohu najít a nechci si poškodit fungující server. Všechny návody co jsem našel řeší migraci z Apache2 na Nginx, ale když řeší souběh, tak jen jako reverzní proxy (nebo reverzní proxy potřebuji taky?).
Díky za radu či případný odkaz, Standa
VPS ID: 16705
Ahoj,
prosím o info (radu), zda je možné instalovat systém Android-x86 na VPS
a mít k dispozici grafickou konzoli (jako např. u VMware).
Díky, BH.
Ahoj,
> On 08.06.2020 10:55, Jaroslav Skrivan wrote:
> Zas tak zle to neni. Nam ze serveru tece 20% ipv6 provozu k uzivatelum
> (prevazne cz/sk provoz). Google hlasi 30%.
> Dlouhodoby rust je ale velmi pomaly.
tak to se přiznám, že mi _na ČR_ připadá docela pěkné. Mohu navázat na
předchozí – naše trojka je takový smutný operátorský Klondike. A to
nemyslím vůbec cenovou politiku apod. Jediný, kdo se tady snažil něco
razantněji dělat, pokud si pamatuji, je Radek Zajíc u TMCZ, ale těžko
říct, zda to nebyl marný boj.
1) O2 – dělá na fixu i mobile DPI (Host u HTTP, SNI u HTTPS) pro mkt
účely; zkušenost ex-zaměstnance 2019
Takže tady bych tuneloval, co se dá, ostatně nedělám si iluze u jiných
operátorů, tedy díky za DNS-over-TLS/HTTPS, ESNI apod.
2) Vodafone – cca v lednu 2019 začal po mnoha letech blokovat na VDSL
příchozí provoz, od té doby účtuje 175 CZK za "veřejnou a statickou
IPv4", ačkoli statická by nebyla vůbec potřeba; IPv6 je utopie
3) TMCZ – jsem v Praze na "fixním" LTE, protože nemám jinou možnost;
IPv4 za CGN, IPv6 v říši snů
Myslím si, že pokud se naši operátoři nepohnou, situace s IPv6 se nějak
nezlomí. Ondřej Caletka ukazoval na poslední prezentaci IPv6 u Orange v
Polsku, prostě paráda.
IPv6 tunel vpsFree je prima počin, ovšem škoda, že Mikrotik umí u
OpenVPN jen TCP/AES256-CBC+(MD5/SHA1) s certifikáty. Dalo by se to
naklikat i zde, se současným (a chápu, rozumným) nastavením bych
potřeboval další stroj na routing. Ale IPv6 laboratorní síť Radka Zajíce
se mi líbila.
Suma sumárum: ačkoli aktivity kolem IPv6 naprosto vítám a podporuji,
mohu jej využívat tak akorát na koncové stanici po wireguard tunelu ke
Cloudflare (WARP).
A tip: pokud používáte nginx jako proxy (líbí se mi to), doporučuji
zadefinovat si nejprve upstream a ten použít v proxy_pass, bude vám pak
fungovat keep-alive a agregace spojení směrem k upstreamu (s trošku
dalších parametrů), jinak nikoli, je to někde v dokumentaci popsáno.
Petr
Ahojte vespolek,
nekdy to prijit muselo, k prilezitosti 4. 6. roku cisla vysokeho, a sice
2020 - je na case zacit mavat kapesnickem, vstupujeme do prvni faze
pohrbu IPv4...
IPv4 je mrtvy protokol.
Jsme davno za bodem si to priznat, ted uz nam nezbyva, nez se s tim
hlavne nejak vyrovnat.
V ramci Rady vpsFree.cz jsme se k tomuhle kroku chystali uz dlouho, pak
se ale nakonec povedlo ziskat jeste posledni /22 IPv4 blok, takze jsme
to mohli trochu odlozit, ale uz je to tu:
Od ted uz nedavame zadne dalsi verejne IPv4 adresy per-clen, kazdy clen
ma narok na jednu a tim to konci.
Vsechny sluzby, ktere ve vpsFree provozujeme (a ze jich je), mame za
jednou verejnou IPv4 adresou, za VPS, ktere rikame proxy.vpsfree.cz.
Svoje dalsi v4 adresy maji jen nameservery (a zprasene legacy instalace,
ktere ceka prevod za proxy, vc. mailu, tam je to kvuli ticketingu pres
RT docela bordylek, ale to se vyresi nekdy pri pristim upgradovani).
Ted nastal cas pro vsechny, aby se tak zaridili. IPv4 adresy nejsou a
dalsi nebudou, nezbyva nam nic jineho.
V tehle fazi prestavame pridelovat dalsi verejne IPv4 adresy clenum (ani
za libovolny uplatek :D).
Pointou je, abychom umoznili dalsim, novym, mladsim, vstoupit na ten nas
zpraseny legacy Internet, dokud bude ten legacy protokol tak moc
potreba.
Kdyz jsme ho kolektivne dostali do bodu, kdy uz neni samo o sobe misto
pro nove, je nesmysl, abychom sami razili kurz, "jako by se nic nedelo".
Deje se - IPv4 adresy dosly; a nedeje tolik - IPv6 se porad zasekava u
koncovych ISP.
To neni stav, ve kterem bychom mohli pridelovat dalsi IP adresy tem,
kteri jsou lini nastavit si svoji proxy VPS ;)
Musime se snazit vsichni spolecne.
Petr Krcmar to sepsal na blog trochu libiveji:
https://blog.vpsfree.cz/prejdeme-na-ipv6-spolecne-potrebujeme-to/
Ale ja jsem si rikal, ze na mailing list bude lepsi napsat primo, jak to
vidime, jak to je.
Zaverem bych jenom uklidnil ty, co uz vic IPv4 adres maji, ze se
nechystame do toho stavajiciho stavu nijak brzo sahat (nejdriv, az kdyz
budeme muset, tj. tak za rok-dva od ted) - sice tak zas trochu pomahame
pravidlu, ktere v4 dostalo, kde je - "prvni prijde, prvni mele", ale zas
takovou urgentni adresni krizi netrpime.
To prijde, az (kdyz) bude potreba brat nekde dalsi IPv4 adresy pro nove
cleny a uz nebude odkud (pokud v4 nebude tou dobou minoritnim
protokolem).
Diky vsem za pochopeni,
/snajpa
Ahoj všichni,
včera jsem reagoval na diskuzi ohledně přechodu na IPv6 a omylem jsem to
poslal jenom Snajpovi. Chtěl bych mu poděkovat za jeho přístup a nabídku
dočasné IP adresy, abych se nedostal do problémů. Rozhodl jsem se, že
raději přenos serveru z playgroundu o týden odložím a zkusím to rovnou
udělat "načisto" s využitím proxy.
Chtěl jsem Vás poprosit o radu ohledně proxy pro mailserver (klasika
Postfix + Dovecot na Debianu). Chtěl bych si to tento víkend nastudovat
a potřeboval bych nasměrovat na nějaké vhodné řešení. V podstatě mám teď
jeden starý VPS s IP4, kde mi běží klasický "hosting" (Nginx, MariaDB,
Postfix a Dovecot na Debian 9). Na playgroundu mám druhý VPS s Debian
10, na kterém mám nainstalovaný jen Postfix a Dovecot. Chtěl bych z
"hostingového" VPS přesunout mailové služby na ten nový a mít tak dva
stroje, jeden na mail a jeden na web.
Je podle Vás lepší řešení udělat na "hostingovém" VPS proxy pro ten
mailserver nebo to obrátit a udělat mailserver s IP4 a přidat tam proxy
pro webové služby?
Co byste případně použili jako proxy software před ten mail server? Já
se včera díval na Nginx, který umí proxy imap a smtp, ale nebylo mi
úplně jasné použití "http auth". Jestli jsem to pochopil správně, musel
bych mít databázi uživatelů na tom proxy, což mi přišlo nešikovné. Ten
přesun jsem plánoval hlavně kvůli tomu, abych si ty služby oddělil a měl
v tom "pořádek" - tzn. ocenil bych mít vše k e-mailům na jednom stroji.
Všechny zdraví
Honza
--
Jan B. Kolář
Zažeň nudu
Hodolanská 17, 779 00 Olomouc
tel: +420 605 800 859
e-mail: janbivoj.kolar(a)zazen-nudu.cz
www.zazen-nudu.cz
Ahoj,
díky moc za rady. Zatím se mi jako nejschůdnější řešení jeví to, že
udělám mailserver s IPv4 a nginxem jako proxy pro weby běžící na druhém,
IPv6 only stroji. Včera jsem to trochu studoval, ale zatím mi některé
věci nejsou úplně jasné. Zkusím to začít testovat a uvidíme, kam se pohnu.
Honza
--
Jan B. Kolář
Zažeň nudu
Hodolanská 17, 779 00 Olomouc
tel: +420 605 800 859
e-mail: janbivoj.kolar(a)zazen-nudu.cz
www.zazen-nudu.cz
Ahoj,
netýká se to přímo vpsFree, ale je to z oboru :-) Chtěl bych si postavit VM
server a osadit ho 2TB NVMe úložištěm. Otázka je, jak to zálohovat. Obecně
se nedoporučuje NVMe dávat do RAIDu, to ani nechci, ale jak to nejlépe
zálohovat např na plotnový disk. Napadá mě jen kopírovat VM jednou za čas
na HDD, ale určitě existuje i něco chytřejšího. Původně jsem chtěl SATA SSD
do RAIDu, ale kvůli výkonu bych raději NVMe.
Teď mám ESXi a v tom HW RAID 1 z 15k disků a zálohy nedělám. Na Zabbix by
to chtělo ale něco rychlejšího. Netrvám na ESXi, ale mělo by to být free a
rozjet tam vše, co na tom ESXi (Linux i Windows stroje).
Předem dík za tipy.
Mirek
Ahojte, je nejaka hranice poctu lidi v jednom meetingu? Mam pozadavek na
pripravu meetingu pro cca 10 lidi, tak jestli je to v pohode (verim ze ano)
a pripadne jake jsou technicke limity...???
Diky,
P.
Ahoj všem,
jak jste již možná zaregistrovali - kvůli aktuální situaci kdy se je třeba snažit vyhýbat kontaktu s lidmi, jsme rozjeli pro tyto účely videokonferenční jitsi instanci u nás.
Jde o čistý jitsi server s vypnutou jakoukoliv možností špehování (Googlí servery, nahrávání serverside..), se zapnutým šifrováním a rebrandingem.
Doufám že bude k užitku a kdybyste narazili na nevhodný či něco nevysvětlující překlad, dejte mi prosím vědět :-)
https://meet.vpsfree.cz/
Martin Myška
martyet
Ahoj,
máme na node1.stg VPS ve které běží libvirtd kde se nám v guestech jednou za čas stane:
kernel: sd 0:0:0:0: [sda] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_TIMEOUT
kernel: sd 0:0:0:0: [sda] tag#0 CDB: Write(10) 2a 00 00 8d 9a 30 00 00 28 00
kernel: print_req_error: I/O error, dev sda, sector 9280048
kernel: Aborting journal on device sda2-8.
kernel: EXT4-fs error (device sda2): ext4_journal_check_start:61: Detected aborted journal
kernel: EXT4-fs (sda2): Remounting filesystem read-only
Viděli jste někdy něco podobného? Dělají ty VMka prostě příliš mnoho I/O takže driver v guestu vytimeoutuje nebo může být problém jinde? Storage volumes jsou qcow2.
Díky,
Martin Milata
Ahojte,
... tak uz ...
... konecne ...
switchujeme ASICem (Broadcom Tomahawk v S4048-ON),
full-kotel-full-on-full-speed.
Min prijemna zprava je, ze porad jedeme a jeste nejakou dobu pojedeme na
jedne vetvi (ted je to pro zmenu ta druha, co je predelana) a zmeny
jeste budou prichazet, hlavne v adresach NATu.
Pro ted je verejna adresa NATu 83.168.228.130, v budoucnu se to asi
jeste zmeni, nejspis dvakrat - jak predelame primarni vetev, tak poskoci
o par cisel nahoru - a jakmile predelame NAT na linux/x86/conntrackd+HA,
zmeni se finalne na jednu IP adresu, na ktere uz v Praze zustane.
/snajpa
Ahoj,
prosím aspoň stručně: jak moc velký problém bylo zprovoznit
meet.vpsfree.cz?Vím že jsem se asi před 2ma roky o Jitsi zajímal, ale
vzdal jsem to vzhledem k nepřehlednosti stránek a nemožnosti najít
informace nějak rozumně po kupě.
(Máme trochu víc dětí a nároky učitelů na offline vyučování a zároveň
snaha pracovat začíná být celkem neřešitelný problém. Takže pokud by to
bylo jednoduché na zprovoznění, tak bych to zkusil aspoň pro jednu třídu
experimentálně spustit. Ale nemám šanci to udělat pokud by to bylo na
dlouhotrvající kompilování, laborování a testování. Předpokládám, že by
nebylo moudré pustit někoho na Meet.vpsFree, zejména ne 20 puberťáků z
jedné třídy.)
Díky moc aspoň za stručnou opověď.
Štěpán.
Zdravím,
nedaří se mi rozhodnout jak vyřešit backup "store".
Jádrem projektu je MS SQL, nic se nesmí ztratit nebo z toho budou pokuty.
(accounting)
Momentálně mám na stole dvě řešení:
- self-hosted na NASce (synology?)
- urBackup server na low-spec VPS s větším "file space" (1-2TB) - tahle
možnost mě přišla docela praktická, pokrývá to mnoho risků které má
jakékoliv jiné self-hosted solution, jenže po rychlém projití googlu se mi
nedaří něco v tomhle smyslu najít nebo se to cenově nevyplatí. Že bych se
blbě koukal?
Díky, a pěkný den
--
Tomáš Svoboda
*Freelancer | Fullstack Python | 730 694 169*
Ahojte,
mám dotaz na python. Už delší dobu přecházíme na Python3 (je to složitý a
problematický a nemáme žádnou významnou funkci co by to opodstatnila).
Během té doby jsme našli 2 chyby (pickle/shelve) v novém Pythonu a nyní
jsme našel nový hodně velký problém.Je to nová funkce PEP515 podtržítka v
číslech. Tato funkcionalita zní možná naprosto skvěle pro některé lidi, ale
nám nyní dělá značnou neplechu.
Jde o to, že nyní všechny interní funkce jako je int/float/literal_eval při
předání "1_1" a podobně vytvoří číslo 11 a ne SyntaxError. Chápal bych, že
tato funkce bude ve zdrojovém kódu možná užitečná. Jenže pokud nyní
uživatel předá "1_1", tak systém pokračuje dál s novým číslem.
Moje otázka zní, znáte nějaký postup jak toto chování vypnout? Ono se to
nezdá ale int/float a literal_eval používáme opravdu hodně a všude řešit
nějakou takovou kontrolu je těžce proveditelné. V minulosti se podobně blbě
chovala nula na začátku a to naštěstí odstranili, ale nyní přidali tuto
vlastnost.
Zkouším hledat na googlu, ale zatím jsem nenašel nic co by to umožnilo
nějak změnit, ideálně globálně.
--
Zdenek
Web: www.pripravto.cz
Ahojte vazeni clenove,
rad bych Vas pozval na clenskou schuzi naseho spolku za rok 2019,
ktera se kona 28. 3. 2020 od 18:30 v restauraci U Balbinu v Praze.
(Jungmannova 22, Praha 1, https://www.ubalbinu.cz/)
Body programu, ktere budeme probirat:
1. Shrnuti roku 2019 + plan na rok 2020
- financni + organizacni + technicke shrnuti minuleho roku
-
2. Plan na rok 2020
- vpsAdminOS, web, nove UI
3. Diskuze: socialni rozmer vpsFree, spoluprace ve spolku
- Navrh:
Pravidelne "office hours"
- tj. moznost se fyzicky potkat, pravidelne, rekneme 2x do mesice,
Praha/Brno
- spolecne debugovani problemu
- postupne zapojeni dalsich lidi do fungovani spolku (neni-li to
naivni predstava)
- K zamysleni do schuze:
Co muze svym clenum vpsFree nabidnout nad zakladni myslenku sdileni
HW prostredku?
Co muzeme jako spolek nabidnout siroke verejnosti, je-li neco
takoveho?
Jak muzeme zapojit dalsi nadsence do toho, co delame?
Ktere formy propagace spolku jsou pro nas vhodne (a moralne
prijatelne)?
- napr. je OK reklama na FB? Je OK pouzit Google Analytics?
Asi bych celou diskuzni cast shrnul jako: co muzeme delat lepe, abychom
byli zajimavejsi pro vice lidi, aniz bychom tim jakkoliv narusili
integritu toho, co jsme do ted vybudovali? Velke cloudy rostou a my,
pokud budeme na nekterych vecech (mozna prilis) zbytecne dupat, tim
ztracime na relevantnosti.
Co, tedy, muzeme delat jinak, lepe?
Ma - napriklad - smysl se ucastnit konferenci v CZ/SK, pokud se ta ucast
vicemene uz nijak nepreklada na nove cleny?
4. Volna zabava, rezervaci mame az do pulnoci.
Tesim se na vsechny, co si najdou cas a obzvlast na ty, kdo maji chut
prispet svymi napady do 3tiho bodu :)
Na miste budeme uz od 18:00, takze prijdte klidne driv (obzvlast, pokud
do Prahy prijedete driv).
Na videnou na schuzi! ;)
/snajpa
(Pavel Snajdr)
(Predseda spolku vpsFree.cz)
Ahoj,
mám ostrý server a playground. Na playgroundu jsem si vytvořil takovou
konfiguraci, kterou chci mít a teď bych to rád přesunul PG na ostrý
server. Jak by se to dalo udělat?
Pokud jde o administraci serveru jsem na naprostém začátku. Budu vděčný za
odkaz na dobré HOWTO, či srozumitelnou radu. Bude li třeba, rád poskytnu
další informace.
S pozdravem a poděkováním
Petr
Ahojte,
TLDR: jelikoz je v seznamu dost domen clenu vpsFree, zkontrolujte si,
prosim, svoje Let's Encrypt certifikaty, pokud LE pouzivate.
Petr sepsal detaily pekne prehledne na blog:
https://blog.vpsfree.cz/lets-encrypt-revokuje-tri-miliony-certifikatu-zkont…
Diky za pozornost a konec hlaseni ;)
/snajpa
Ahoj,
doporucite mi nejakou VPN, jejiz jeden konec by byl na zdejsim VPS a
druhy na Mikrotiku?
Puvodne jsem chtel pouzit IPIP + IPsec, ale ukazalo se, ze to asi
nepujde. A OpenVPN v TCP rezimu (to kvuli Mikrotiku, ktery UDP neumi)
bych se rad vyhnul.
V.
Ahoj,
připravil jsem si skript pro python napojení na vpsadmin pro qnap NAS.
Primárně pro stahování záloh přímo na NAS. Dělal jsem to podle toho ruby
skriptu co je na webu. Ale mám dva dotazy ohledně tokenů. Jde o to, že nyní
jsou ve vpsadminu viditelné (je tam dokonce tlačítko edit asi nefunguje?
mazání zřejmě funguje, chybí přidat?). Nerad bych však dal na NAS přímo
token na všechno a ještě k tomu s možností obnovení. Tak jsem se chtěl
zeptat, zda jde vygenerovat token pouze např. na přístup ke stahování
snapshotů a s délkou např. na rok a zamezit ostatnímu?
--
S pozdravem,
Zdeněk Dlauhý
Web: www.pripravto.cz
Ahojte, chci se zeptat ze zajímavost a taky neznalosti... Všiml jsem si, že
Docker by měl běžet pod vpsAdminOS už celkem v pohodě. Zkoušel jsem v jiném
prostředí RancherOS, což je linuxová distribuce postavená právě kolem
Dockeru a pro Docker. Je reálné, aby RancherOS bylo možné rozjet pod
vpsAdminOS, aby byl k dispozici jako šablona?
Někde jsem četl, že se v produkci nedoporučuje rozjíždět RancherOS (resp.
Docker) pod LXC, kvůli vnoření kontejnerů, nicméně pokud jde rozjet samotný
Docker, asi by mohl jít rozjet i celý RancherOS, který je v podstatě celý
postaven na Dockeru.
Omlouvám se, pokud jsem napsal něco špatně, zatím všechno okolo Dockeru
atp. teprve objevuji...
Pavel
Ahoj,
pravděpodobně v březnu uskutečníme výroční setkání členů, kde
probereme události posledního roku a představíme novinky a plány pro rok
letošní. Potřebujeme tip na nějaký podnik v Praze, kde bychom měli k
dispozici salónek pro dvacet až třicet lidí, kteří obvykle dorazí.
Máte nějaký tip? Díky
--
Petr Krčmář
vpsFree.cz
Ahoj všem,
aktuálně potřebuji koupit HPE Server (ideálně řadu ML350) a rád bych se
zeptal zda někdo nemáte doporučení na ověřeného prodejce s dobrým servisem.
Díky Jirka
--
-------------------------------------------------
Reklalink s.r.o. | A. Jiráska 260 | Příbram | 261 01
Telefon: +420 724 330 493 | Web: http://www.reklalink.cz
Ahoj,
(English version below)
V Praze máme první produkční node s vpsAdminOS: node1.prg. Je to myšleno
hlavně pro nové členy a nové VPS. Migrace pražských produkčních OpenVZ
VPS můžeme provést na požádání, zatím jen individuálně domluvou přes
podporu. Do Brna se vpsAdminOS dostane až později, nadále tam je k
dispozici jen OpenVZ.
Co se týče stagingu, ten poběží tak jak doposud. VPS ze stagingu na
node1.prg přesouvat aktuálně nebudeme a to ani na žádost. Dostaneme se k
tomu až v následujících týdnech, budeme o tom informovat všechny,
kterých se to týká.
Od této chvíle tedy máme v produkci v Praze dvě virtualizační platformy.
Je potřeba na to myslet při práci s NASem a playgroundem. Playground je
nyní jen pro OpenVZ VPS, pro vpsAdminOS tuto funkci bude plnit Staging.
Více informací o rozdílech viz KB:
https://kb.vpsfree.cz/navody/vps/vpsadminos
ENGLISH:
The first production node with vpsAdminOS is now available in Prague:
node1.prg. It's mainly for new members and new VPSes. We can migrate
OpenVZ VPS from Prague on demand, but only individually, contact our
support if you're interested. vpsAdminOS is not available in Brno yet,
OpenVZ remains the only supported platform in this location.
As to staging, nothing changes. We will not migrate VPS from staging to
node1.prg at this time, not even on request. We'll get to it in the
following weeks, we'll contact everyone concerned when the time comes.
From now on, there are two virtualization platforms in Prague. Please
bear in mind the differences as to accessing NAS and playground.
Playground is for OpenVZ VPS only, staging will fullfill this role for
vpsAdminOS for now. See the knowledge base for more information:
https://kb.vpsfree.org/manuals/vps/vpsadminos
Jakub
Hello,
I have an small issue when stopping Alpine (3.11) vps on staging.
It currently takes long time (multiple minutes, I assume before some
timeout happens and it is killed).
When I have remote console opened when stopping, I see this output:
* Stopping sshd ... [ ok ]
* Shutting down ssh connections ... * sshd: caught SIGTERM, aborting
[ ok ]
* Stopping busybox syslog ... [ ok ]
* Unmounting cgroups ... [ ok ]
The system is going down NOW!
Sent SIGTERM to all processes
and it is stuck like this. Did anyone else notice this and is there
some known workaround (it is annoying...)?
Thanks,
W.
--
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.
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
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
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
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
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
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
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
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
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
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
Zdravím,
rád bych se zeptal, jestli je možné na vpsFree použít některý z DNS pluginů
pro Certbot (viz: https://certbot.eff.org/docs/using.html#dns-plugins) pro
automatic certificate renewal, abych to nemusel každé tři měsíce dělat
manuálně. Na KB jsem o Let's Encrypt nic nenašel. Certifikáty řeším prvně,
tak pokud funguje jiný způsob, než pomocí certbota, nechám se navést.
Díky,
Jakub
Ahoj. No mam na vpsfree server s Debianem a certbot si aktualizuje
certifikáty sám. Akorát sem si musel opravit v nginxu přesměrování z http na
https aby to fungovalo, přesměrovávat location well-done.
Taky sem to dělal poprvé, loni a od té doby ti jede.
Petr Bolf
---------- Původní zpráva ----------
Od: Jakub Podlaha
Datum: 2. 10. 2019 v 10:59:44
Předmět: [vpsFree.cz: community-list] certbot renewal
Zdravím,
rád bych se zeptal, jestli je možné na vpsFree použít některý z DNS pluginů
pro Certbot (viz: https://certbot.eff.org/docs/using.html#dns-plugins
(https://certbot.eff.org/docs/using.html#dns-plugins)) pro automatic
certificate renewal, abych to nemusel každé tři měsíce dělat manuálně. Na KB
jsem o Let's Encrypt nic nenašel. Certifikáty řeším prvně, tak pokud funguje
jiný způsob, než pomocí certbota, nechám se navést.
Díky,
Jakub
hoj,
snažim se rozjet na *Staging* VPSce nixos-containers (v podstatě wrapper nad systemd-nspawn) a kontejnery mi nestartujou:
```
-- Unit container(a)test.service has begun starting up.
Aug 28 23:31:01 nhost systemd[1]: Requested transaction contradicts existing jobs: Transaction for container(a)test.service/stop is destructive (container(a)test.service has 'start' job queued, >
Aug 28 23:31:01 nhost systemd-machined[428]: Failed to stop machine scope: Transaction for container(a)test.service/stop is destructive (container(a)test.service has 'start' job queued, but 'sto>
Aug 28 23:31:01 nhost systemd-machined[428]: Failed to drop reference to machine scope, ignoring: Unit has not been referenced yet.
Aug 28 23:31:01 nhost nscd[433]: 433 monitoring file `/etc/passwd` (1)
Aug 28 23:31:01 nhost nscd[433]: 433 monitoring directory `/etc` (2)
Aug 28 23:31:01 nhost nscd[433]: 433 monitoring file `/etc/group` (3)
Aug 28 23:31:01 nhost nscd[433]: 433 monitoring directory `/etc` (2)
Aug 28 23:31:01 nhost nscd[433]: 433 monitoring file `/etc/resolv.conf` (5)
Aug 28 23:31:01 nhost nscd[433]: 433 monitoring directory `/etc` (2)
Aug 28 23:31:01 nhost container test[21148]: Spawning container test on /var/lib/containers/test.
Aug 28 23:31:01 nhost container test[21148]: Press ^] three times within 1s to kill container.
Aug 28 23:31:01 nhost container test[21148]: /etc/localtime does not point into /usr/share/zoneinfo/, not updating container timezone.
Aug 28 23:31:01 nhost container test[21148]: Failed to mount sysfs (type sysfs) on /sys/full (MS_RDONLY|MS_NOSUID|MS_NODEV|MS_NOEXEC ""): No such file or directory
Aug 28 23:31:01 nhost container test[21148]: Failed to add new veth interfaces (ve-test:host0): No such process
Aug 28 23:31:01 nhost systemd[1]: container(a)test.service: Main process exited, code=exited, status=1/FAILURE
Aug 28 23:31:01 nhost systemd[1]: container(a)test.service: Failed with result 'exit-code'.
Aug 28 23:31:01 nhost systemd[1]: Failed to start Container 'test'.
-- Subject: Unit container(a)test.service has failed
-- Defined-By: systemd
-- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit container(a)test.service has failed.
--
-- The result is RESULT.
```
Z toho mi připadají relevantní řádky
```
Failed to mount sysfs (type sysfs) on /sys/full (MS_RDONLY|MS_NOSUID|MS_NODEV|MS_NOEXEC ""): No such file or directory
Failed to add new veth interfaces (ve-test:host0): No such process
```
ale nejsem z toho nijak zvlášť chytrej.
Dovolil bych si z patra odhadnout, že to bude nějakej problém s nested containerama, ale do tohohle moc nevidim.
Zkoušel jste někdo rozjet něco podobnýho?
-miky.
--
Jakub Fišer
Linux | DevOps | Security
+420-603 797 487
Ahoj,
dneska sem po nejake dobe updatnul ubnutu na vpsce a po rebootu me nenabehla ani jedna VPNka, bylo treba "potunit" systemd aka:
https://askubuntu.com/questions/747023/systemd-fails-to-start-openvpn-in-lx…
tzn
- systemctl edit openvpn@
- vlozit
[Service]
LimitNPROC=infinity
- ulozit / zavrit editor
- systemctl daemon-reload
... a jedeme ...
Treba to nekomu pomuze... Pekny den. JD
Pěkný den,
úplně to nesouvisí s vpsFree, ale tato komunita je asi nejvíc provázaná
s Linuxem co jsem schopen oslovit.
Hledám kolegu.
Nejsem personalista, ale Linux admin v interním IT. Jsme centrála ve
větší firmě a provozujeme spoustu vlastních i OS systémů. Snažíme se
optimalizovat. Vidět do toho, jak věci fungují a firma to podporuje. Je
to hodně kreativní práce ve fázi investigace technologie, nastavení,
pochopení a tato fáze směřuje k tomu, aby jsme danou technologii mohli
standardizovaně používat. Takže procesy jako change management,
dev-test-prod prostředí atd. ano, to nám dává smysl. Jedeme spíš na
zodpovědnost, než mít ticket na každé pohnutí na infrastruktuře.
Ty by ses "hrabal" v nasazených Linuxech a zkoumal možnosti, jak bychom
mohli dělat věci jednodušeji, bezpečněji, jaké postupy a nástroje používat.
Je to u nás technologicky opravdu zajímavé. Jestli jsem vzbudil Tvou
zvědavost, velmi rád ti prozradím detaily a podrobnosti.
Budu rád za zkušeného admina, ale i junior, který doposud dělal s
Linuxem jako hobby a chtěl by se stát profíkem, je dobrá volba.
Předávání zkušeností je základ našeho fungování.
A buď prosím někde z Brna a okolí.
Díky. A omluva těm, co vás to nezajímá.
Petr Baláži
Email: petr.balazi(a)rws.com
Dobrý den, ahoj všem,
v principu pokračuju ve vláknu "Sirka pasma" (původně začlo v
https://lists.vpsfree.cz/pipermail/community-list/2019-July/010081.html)
a pokračovalo legálností a tak.
Mám otázku: vidím na své vpsce nějaké neslušné aktivity, scany, asi
hádání hesel a tak. Máte zájem to řešit nějak společně? Případně se
můžete vyjádřit, že vás to zrovna nezajímá :-)
Teoreticky bych mohl někomu posílat seznam třeba zajímavých událostí s
četností více než 10 výskytů za den. Pokud by to bylo třeba u třetiny
členů, mělo by to větší vypovídající hodnotu.
Překvapilo mne, že mam cca 19.000 výskytů v přístupu na ssh za den,
fail2ban nic, v iptables cca v řádu vteřin, ale nejsem si jistý, co to
bylo za aplikační provoz. Čili jestli to není něco nového, 25. 7. cca v
8:27 SELČ to skončilo.
Pokud už něco takového je, můžete dát vědět.
S pozdravem
Vencour
Hello fellow VPSers,
after recent upgrade to Debian Buster, pihole stopped working and from the
output of diagnostics `pihole -d` I can see the error:
*** [ DIAGNOSING ]: contents of /dev/shm
/dev/shm does not exist.
ls: cannot access '/dev/shm': Too many levels of symbolic links
Which is because of that:
trendy@vps:[~]$ls -la /dev/shm
lrwxrwxrwx 1 root root 8 Ιουν 29 04:49 /dev/shm -> /run/shm
trendy@vps:[~]$ls -la /run/shm
lrwxrwxrwx 1 root root 8 Ιουλ 21 11:18 /run/shm -> /dev/shm
I believe this is not normal; does anyone know where they should point to?
Thank you,
--
-p
Ahoj,
tady https://lists.vpsfree.cz/pipermail/news-list/2014-August/000064.html <https://lists.vpsfree.cz/pipermail/news-list/2014-August/000064.html> (2014) se mluvi o tom, ze se zavadi omezeni sirky pasma pro jednotlive VPS a ze v budoucnu se se zvysenim kapacity linky ven ten bandwidth zvysi. Ubehlo vic nez 5 let a porad je to na 300 Mbps, je v planu zmena? :) Vlastne vubec nevim, jake linky a kam ted vpsFree ma, mozna jen spatne hledam (a ne, ze by to bylo dulezite pro me jako uzivatele VPS, tam budu verit tomu, ze krome nejakych edge-casu se budu moct dostat na tech 300 Mbps, spis me to zajima jako clena).
A proc to resim? Tech 5 let zpatky melo UPC nejdrazsi tarif 240/20, dneska neni pro koncaka problem sehnat na optice Gbit. Se svym 500/50 doma vytizim linku jedny vps s prstem v nose a jeste mi zbyde bandwidth na dve tretiny dalsi vpsky.
Doufam, ze community-list je spravne misto pro tohle :D
Michal
Ahoj,
chtěl jsem vyzkoušet terraform a nemůžu najít seznam templates, které
vpsadmin akceptuje. V příkladu [1] je nastavené ubuntu:
# OS template name, see vpsfreectl os_template list -o name
os_template = "ubuntu-18.04-x86_64-vpsfree"
snažil jsem se to změnit na nixos, něco jako
nixos-unstable-x86_64-vpsfree, ale netrefil jsem správný název. Příkaz
`os_template list -o name` vrátí chybu `parameter 'name' does not
exist`, dostupné atributy jsou jen id a label. Dá se ten seznam někde
získat i se jménem šablony?
zdravím
Tomáš Kuča
[1] https://github.com/vpsfreecz/terraform-provider-vpsadmin/blob/master/exampl…
Ahoj,
mám playground se Slackwarem, zkoušel jsem si zkompilovat vlastní verzi
emacsu. Pro ten sice existuje balíček, ale má hodně závislostí,
pravděpodobně proto, protože je zkompilovaný z podporou GUI.
Samozřejmě, jsem narazil na problém s chybějícími balíčky, ale s tím jsem
počítal, část stačilo doinstalovat, ale nakonec jsem skončil u tohoto:
http://www.abclinuxu.cz/poradna/linux/show/447232
Že prý v systému chybí hlavíčové soubory jádra. Jenže jádro je upravené a
balíčky s hlavičkovými soubory jsou pouze pro to distribuční. Jak by se to
dalo řešit? Trochu jsem hledal a pomocí KVM
https://kb.vpsfree.cz/navody/vps/kvm můžu mít vlastní jádro, ale přiznávám,
že se toho trochu bojím.
Budu vděčný za radu, či dobře mířené RTFM
Děkuju
Ahoj,
nejdřív to nejdůležitější: na stagingu je nyní podporováno openSUSE Leap
15.1 a Tumbleweed, Slackware 14.2 a Void Linux (glibc, musl).
Poslední dva týdny jsem se snažil vylepšit situaci ohledně sestavování
šablon distribucí, ze kterých se vytvářejí nové VPS. Od roku 2014 [1]
používáme k sestavování šablon skripty build-vpsfree-templates [2]. Už
tehdy bylo cílem šablony sestavovat pravidelně a automatizovaně, jenže
se to nikdy nedotáhlo do konce. Šablony nestačí jen tak sestavit a hned
je používat, protože distribuce se mění a skripty nemusí fungovat
spolehlivě. Každá šablona se před použitím musí otestovat, a to se
muselo vždy dělat manuálně.
Pokud chtěl někdo přispět, musel řešit kde a jak šablony sestavovat a
testovat. Bylo nutné manuálně nainstalovat potřebné závislosti jako
debootstrap, yum/dnf, zypper, atp. Na opravdové ověření funkčnosti bylo
potřeba si nainstalovat OpenVZ.
Aktualizace šablony jedné distribuce spočívala ve zprovoznění skriptu
samotného, výsledek si nakopírovat na nějaký systém s OpenVZ, pak z toho
vytvořit VPS, zjistit že něco nefunguje (start, ssh, konzole, heslo,
...) a zase na začátek. S uvedením vpsAdminOS se všechno muselo dělat
2x, protože se šablony samozřejmě liší [3].
Ve výsledku se šablony aktualizovaly jen když to bylo nezbytně nutné. U
stabilních distribucí jako Debian to nevadí, s aktualizací systému po
vytvoření VPS není problém. Rolling-release distribuce jako Arch nebo
Gentoo jsou na tom hůře a po delší době dá aktualizace více práce.
Proto jsem se snažil to aspoň na vpsAdminOS udělat lépe: zajistit stejné
prostředí pro sestavování šablon a automatizovat testování. Nix a
vpsAdminOS jednotné prostředí zajistit umí. Toho jsem využil a program
pro sestavování šablon jsem přidal přímo do OS. K sestavení šablon tedy
stačí nabootovat vpsAdminOS, třeba v QEMU [4]. Poté naklonovat skripty
pro šablony na vpsAdminOS [3]:
git clone -b vpsadminos
https://github.com/vpsfreecz/build-vpsfree-templates.git
cd build-vpsfree-templates
Program, kterým se šablony sestavují, se jmenuje osctl-image [5]. Sám o
sobě žádnou šablonu sestavit neumí, funguje ve spolupráci se skripty
výše, a očekává je v pracovním adresáři. Seznam šablon dostupných k
sestavení zjistíme takto:
osctl-image ls
Pro sestavení šablony je potřeba libovolný ZFS dataset. V konfiguraci
pro QEMU je automaticky k dispozici zpool tank, takže můžeme použít
např. tank/image-builds. Sestavení vybrané šablony pak vypadá takto:
osctl-image build --build-dataset tank/image-builds ubuntu-18.04
Sestavené šablony se ve výchozím stavu ukládají do ./output. Sestavenou
šablonu můžeme jednoduše otestovat:
osctl-image test --build-dataset tank/image-builds ubuntu-18.04
Aktuálně se testuje: start/stop VPS, síť, nastavení hesla roota,
hostname a připojení přes SSH. Chtělo by to ještě testovat i funkční
konzoli a přihlášení.
Pokud něco nefunguje, můžeme si snadno ze šablony vytvořit VPS:
osctl-image instantiate --build-dataset tank/image-builds ubuntu-18.04
Příkaz výše vypíše ID VPS, na kterou se můžeme podívat:
osctl ct start -F instance-abcdefgh
osctl ct attach instance-abcdefgh
Když je vše v pořádku, je čas na pull request. My šablonu přídáváme do
repozitáře, ze kterého si ji vpsAdminOS stáhne při vytváření nové VPS:
osctl-image deploy --build-dataset tank/image-builds ubuntu-18.04
/kde/je/repozitar
Takto se staráme o výchozí repozitář na adrese
https://images.vpsadminos.org.
Celý postup se dá shrnout do toho posledního příkazu, protože
`osctl-image deploy` šablonu když je potřeba automaticky sestaví,
otestuje, a až pokud je vše v pořádku, přidá ji do repozitáře. Podobně
fungují i příkazy `test` a `instantiate`, proto je všude použito
`--build-dataset`, aby se šablona mohla případně sestavit. osctl-image
na pozadí spravuje VPS pro sestavovaní i testování šablon, jak to přesně
funguje je popsáno v manuálu [5, 3].
Abychom s tím měli dlouhodobě co nejméně práce, připravil jsem Nix modul
[6], pomocí kterého lze deklarativně nastavit pravidelné sestavování
repozitářů a jejich obsahu. Výsledek si můžete prohlédnout ve
vpsfree-cz-configuration [7].
Máme to nastaveno tak, aby se šablony sestavovaly jednou týdně v sobotu
ráno. Ty, které se podaří správně sestavit a otestovat budou ihned
přidány do repozitáře. Pokud něco selže, pošle se nám mail s cestou k
logu, ve kterém zjistíme co a proč se stalo. Uvidíme na co ještě
narazíme, ale zatím to vypadá, že by to mohlo fungovat.
[1] https://lists.vpsfree.cz/pipermail/community-list/2014-June/006697.html
[2] https://github.com/vpsfreecz/build-vpsfree-templates
[3] https://github.com/vpsfreecz/build-vpsfree-templates/tree/vpsadminos
[4] https://vpsadminos.org/user-guide/setup/
[5] https://man.vpsadminos.org/osctl-image/man8/osctl-image.8.html
[6]
https://github.com/vpsfreecz/vpsadminos/blob/master/os/modules/services/osc…
[7]
https://github.com/vpsfreecz/vpsfree-cz-configuration/blob/master/configs/i…
Jakub
ahojte,
snazim sa nakonfigurovat iptables ale po zadani jednoducheho pravidla dostavam hlasku iptables: No chain/target/match by that name.
Podla niektorych topicov to moze byt sposobene konfiguraciou kernelu a to parameter CONFIG_NETFILTER_XT_MATCH_STATE.
Neviem sa vsak dostat do konfiguraku kernela.
Nekonfiguroval nahodou niekto iptables a nestretol sa s podobnym problemom pripadne ako sa vam ho podarilo vyriesit?
Vdaka.
Prajem Vam prijemny den.
S pozdravom
Stefan Stefanov
C.C.C. spol. s r.o.
Námestie Biely kríž 1
831 02 Bratislava
SLOVAKIA
mob: +421 902 572 848
tel: +421 2 44459955, 43411450
mail: stefan(a)ccc.sk <mailto:stefan@ccc.sk>
servisný mail : servis(a)ccc.sk <mailto:servis@ccc.sk>
www.ccc.sk <http://www.ccc.sk/>
Facebook - www.facebook.com/www.ccc.sk/ <http://www.facebook.com/www.ccc.sk/>
Ahoj,
po delší odmlce přináším zase nějaké informace o vývoji vpsAdminOS. Je
to už půl roku, bude to delší.
TL;DR je, že migrace produkčních VPS je stále daleko, ale spuštění
produkčního node jsme blíže. Postupně vylepšujeme staging, odstávky už
nejsou tak často a poctivě je hlásíme dopředu. Kdo chce nebo potřebuje,
VPS už tam může provozovat. Produkce to ale stále není.
Padající vpsAdmin
=================
Na únorové schůzi jsem zmiňoval, že nám na vpsAdminOS nehorázně často
padá vpsAdmin. A to na segfault v ruby, nic z čeho by se dalo zotavit.
Bohužel to padalo vždy při ukládání výsledku vykonaných operací, což pak
vedlo k tomu, že se vykonávaly vícekrát a vznikaly tak nesmysly na disku
i v databázi. Nakonec se mi to podařilo vyřešit aktualizací všech
komponent, zejména mysql connector byl v nixpkgs v nějaké zapomenuté
verzi. Teď to... sice taky občas padá, ale ne tak často a ne v tu
nejhorší chvíli.
NFS na stagingu
===============
Další nekonečný příběh je zpřístupnění nasboxu, nebo obecně NFS. V čem
je problém: VPS používají user namespace, tzn. váš root z VPS nemá na
nodu uid 0, ale nějaké jiné číslo. Z pohledu nodu je to neprivilegovaný
uživatel a jako superuživatel se tváří jen ve VPS. To taky znamená, že
pokud připojíte NFS export, na NFS server chodí UID/GID z VPS tak jak je
vidí node, čili jako neprivilegovaní uživatelé. Proto i na NFS serveru
mapujeme UID/GID na vašich datasetech, aby to sedělo s user namespace ve
VPS.
V březnu jsem ve vpsAdminu dokončil implementaci správy user namespace,
nastavování map u datasetů a mounty. Hned jsem to chtěl vyzkoušet a šel
datasety na nasboxu exportovat i na adresu node1.stg... No a byl z toho
několikahodinový výpadek [1]. Exporty na NFS serveru se mění jeden po
druhém, takže každý bude mít krátký výpadek a jede se dál, že? Bohužel
ani náhodou. Nevím čím to je, ale když takhle hromadně měníte exporty,
NFS server přestane obsluhovat klienty. Všechny klienty. Ani po
zastavení operace server nezačal klienty obsluhovat, takže panika,
restarty NFSD a znovu všechno exportovat... Ponaučení: více trpělivosti
a nesahat na exporty bez nahlášené odstávky někdy v noci. Jinak by
stačilo chvíli počkat a server by začal pracovat, prostě to jen dlouho
trvalo.
Po téhle bitvě to nakonec na stagingu stejně nefungovalo správně.
Protože root z VPS byl na NFS serveru co? Neprivilegovaný uživatel. Jako
neprivilegovaný uživatel neměl oprávnění pracovat se soubory jiných
uživatelů, atd. Prakticky nepoužitelné. Zde se nabízejí dvě řešení: NFS
klient musí posílat UID/GID tak jak je vidí VPS, na NFS serveru by tak
root byl privilegovaný uživatel. Druhá možnost by byla nastavit NFS
server tak, aby určité neprivilegované UID bral jako privilegované.
Protože jsem v tu dobu nenašel žádnou aktivitu vývojářů NFS v tomhle
ohledu, rozhodl jsem se implementovat tu druhou variantu, neboť mi
přišla jednodušší. Výsledkem je nový parametr u exportu root_uid, což by
se nastavilo podle mapování roota v jednotlivých VPS:
zfs set sharenfs="root_uid=666000" storage/vpsfree.cz/nas/...
Potíž je, že to vyžaduje patch kernelu [2] i patch nfs-utils [3] v
userspace. Funguje to pěkně, jenže na nasboxu není vpsAdminOS. Sice by
to šlo napasovat i na OpenVZ, ale rozhodli jsme se rovnou přejít na
vpsAdminOS. Protože nasbox používá kolem 700 VPS, nejdříve jsme si
vpsAdminOS vyzkoušeli na backuperu, který v tomto ohledu není tak důležitý.
Jeden problém s NFS při startu systému jsme skutečně odhalili a snad i
opravili. Jinak to funguje velice pěkně. nasbox je další na řadě.
Bohužel se to teď zase komplikuje, protože do Linuxu 5.2 přistály patche
[4], které implementují tu první možnost: UID/GID překládá už klient a
na server chodí tak jak je vidí VPS. To je pro nás velká komplikace a
než se k něčemu rozhodneme, musíme to vyzkoušet. Z NFS na stagingu tedy
ještě nějaký měsíc nic nebude.
br_netfilter
============
Někdo se na IRC ptal na br_netfilter, který v Linuxu nepodporuje
namespace a ve VPS tak nejde používat. Existuje ale patchset, který to
implementuje. Do našeho kernelu jsme tento patchset přidali, nicméně...
nevím k čemu se to používá, vím akorát že to používají nějaké aplikace v
dockeru. Pokud to někdo potřebujete, řekněte nám prosím na co a jak je
to důležité. Jinak není vyloučeno, že to budeme muset pustit, pokud se
to nedostane do upstreamu.
Linux 5.0, 5.1, ZFS
===================
Na stagingu průběžně přecházíme na nové verze kernelu. V produkci pak
počítám že na delší dobu zakotvíme na nějakém LTS kernelu.
Pro naše patche kernelu jsme vytvořili repozitář na githubu:
https://github.com/vpsfreecz/linux/branches/all
Mohli jste zaznamenat, že Linux 5.0 omezil export funkcí [5] pro práci s
FPU na GPL-only a odstřihl tak ZFS on Linux. Tímhle si nehodláme
komplikovat život, ani snižovat výkon. Ten export jsme si v kernelu
patchnuli, stejně jako to pak udělal i NixOS [6].
V pátek jsme přešli na Linux 5.1 a ZFS on Linux 0.8.0. ZoL 0.8 je
opravdu parádní vydání, doporučuju se podívat na novinky [7].
/sys/devices/system/cpu/online
==============================
... používají některé aplikace na detekci počtu procesorů, aby věděly
kolik mají používat vláken, workerů, apod. Tyto údaje v Linuxu nejsou
nijak virtualizované a řeší se to v userspace pomocí LXCFS. Co všechno
máte ve VPS "virtualizováno" přes LXCFS zjístite s:
grep lxcfs /proc/mounts
V pátek jsme nasadili verzi LXCFS, která řeší i
/sys/devices/system/cpu/online. Používá to např. Python když zavoláte
multiprocessing.cpu_count().
pty-wrapper
===========
Aby měly všechny VPS otevřenou konzoli, pouštíme je ve wrapperu, který
přichystá pseudoterminál a pak zprostředkovává komunikaci mezi osctld ve
vpsAdminOS a vzdálenou konzolí ve vpsAdminu. Původně jsme tento program
měli napsán v Ruby, jenže to na každou VPS zabíralo cca 15 MB paměti,
které se účtovaly k zabrané paměti VPS. sorki to přepsal [8] do Haskellu
a jsme teď na 5 MB na VPS.
Deklarativní konfigurace ZFS datasetů
=====================================
Při instalaci nodu je potřeba nastavit ZFS properties, jako např.
zapnutí komprese, nebo vytvořit nějaké datasety na zpoolu. Vše je teď
možné deklarativně nastavit v konfiguračních souborech [9], abychom na
nic nezapomněli.
Parametry kernelu
=================
Kernel má spoustu hejblátek, které omezují určité prostředky, jako
velikost ARP tabulky, inotify, kernel keyring a počty procesů. Právě na
maximální počet procesů jsme na node1.stg nedávno narazili. Pokusil jsem
se s tím udělat pořádek a vpsAdminOS nyní obsahuje doporučené nastavení
[10] těchto voleb.
Zjednodušení vytváření kontejnerů
=================================
vpsAdminOS původně vyžadoval manuální správu mapování UID/GID v user
namespace. Na stagingu to za vás řeší vpsAdmin, ale v OS samotném to
bylo zbytečně komplikované. Aby šel vytvořit kontejner, muselo nejdřív
existovat ono mapování:
osctl user new --map 0:666000:65536 myuser
osctl ct new --user myuser --distribution ubuntu myct
Nově je nastavení UID/GID map volitelné. Ve výchozím stavu se pro každý
kontejner alokuje unikátní blok UID/GID z definovaného rozsahu. --user
se tak vůbec nemusí používat a stačí:
osctl ct new --distribution ubuntu myct
Díky tomu jsou od sebe kontejnery automaticky odděleny a zároveň to není
žádná práce pro uživatele navíc.
nixos-modules
=============
Máme už celkem dost konfigurace a modulů v Nixu. Aby se daly některé
moduly použít na více místech, vytvořili jsme repozitář nixos-modules
[11]. Zatím obsahuje modul na použití libvirtu, který funguje i ve VPS.
build.vpsfree.cz
================
Máme nový (resp. je to nějaký starší HW) stroj na sestavování OS a
bootovacích obrazů pro nody. I zde je vpsAdminOS, ale nainstalovaný na
disku a bootuje ze ZFS. I takto se dá použít.
Chystám se zde taky automatizovat build šablon distribucí pro VPS. Nyní
se šablony musí sestavovat a testovat manuálně, což se nikomu nechce
dělat a zejména rolling-release distribuce zaostávají. O tom zase někdy
příště.
IPv6 na stagingu
================
Kdo máte VPS na stagingu, určitě jste si všimli problémů s IPv6. Bylo to
tím, že neseděly BGP timeouty mezi Dell switchi a birdem na node1.stg.
Už nějakou dobu to funguje stabilně.
Co dál
======
Ke spuštění produkčního node chybí: NFS (viz výše) a syslog namespace.
Monitoring už tak nějak funguje -- při výpadku nám chodí SMS, ale ještě
je co vylepšovat co se týče sledování zdrojů.
syslog namespace je důležitý k tomu, abyste dostávali informaci o tom,
že vaši VPS navštívil OOM killer. Teď vám mohou mizet procesy a nevíte o
tom. Patchset už máme [12], musí se to přidat do kernelu a vyzkoušet.
[1] https://vpsadmin.vpsfree.cz/?page=outage&action=show&id=511
[2]
https://github.com/vpsfreecz/linux/commit/ab987ee27f0a57f0dae3f0847db2ce4da…
[3]
https://github.com/vpsfreecz/vpsadminos/blob/master/os/packages/nfs-utils/p…
[4] https://lwn.net/Articles/788292/
[5]
https://www.root.cz/zpravicky/zfs-on-linux-ma-mensi-zadrhel-s-kernelem-5-0/
[6]
https://www.phoronix.com/scan.php?page=news_item&px=NixOS-Linux-5.0-ZFS-FPU…
[7] https://github.com/zfsonlinux/zfs/releases/tag/zfs-0.8.0
[8] https://github.com/vpsfreecz/pty-wrapper
[9] https://vpsadminos.org/os/pools/#declarative-pool-structure
[10]
https://github.com/vpsfreecz/vpsadminos/blob/master/os/configs/tunables.nix
[11] https://github.com/vpsfreecz/nixos-modules
[12]
https://github.com/torvalds/linux/compare/master...vpsfreecz:syslogns-5.1
Jakub
Ahoj,
chystám se po dlouhé době (*vlastně od výpadků s glibc*) přeinstalovat svoji VPSku a půjdu na to novou instalací do playgroundu a kopírováním toho, co chci přenést - ne migrací.
Funguje již vše tak nějak normálně (*původní vps jsem si nainstaloval*) nebo jsou potřeba nějaké úpravy, aby to běhalo spolehlivě?
Díky,
Jindra
Ahoj,
doteď se ve VPS s Fedorou a CentOSem nastavovala síť pomocí init skriptu
/etc/init.d/network. Ten je už nějakou dobu označen za zastaralý a v
nových verzích se musí doinstalovávat. Místo init skriptu se má používat
NetworkManager (NM), takže od Fedory 30 to tak na vpsAdminOS budeme
dělat. Stejně by to mělo fungovat v CentOS 8, až ho vydají.
Pokud budete aktualizovat z Fedory 29, můžete na nový způsob konfigurace
přejít. Dokud bude ve vpsAdminu nastaveno, že ve VPS je Fedora 29,
všechno bude fungovat jako doposud. Když to přenastavíte na Fedoru 30,
bude potřeba nejdříve několik změn ve VPS.
NM sice umí číst konfigurační soubory v /etc/sysconfig/network-scripts
tak jako init skript, ale není to pořádně kompatibilní a jsou tam
rozdíly, takže NM nefunguje správně s konfigurací pro init skript a naopak.
Pro přechod na NM nejprve ve VPS proveďte:
dnf remove network-scripts
systemctl unmask NetworkManager.service
systemctl unmask NetworkManager-wait-online.service
systemctl unmask NetworkManager-dispatcher.service
cat <<EOT > /etc/NetworkManager/conf.d/vpsadminos.conf
[main]
plugins+=ifcfg-rh
rc-manager=file
configure-and-quit=true
EOT
Pak ve vpsAdminu přenastavte distribuci na Fedoru 30 a restartujte.
Jakub
(Posílám tu samou zprávu podruhé, protože to některým lidem nebylo
doručeno kvůli špatnému spamfilteru.)
Ahoj,
(English version below)
Ve vpsAdminu si nyní můžete nastavit dvoufaktorovu autentizaci (2FA)
pomocí TOTP [1]. Pro autentizaci můžete používat např. mobil s aplikací
Google Authenticator [2], FreeOTP [3], nebo libovolný program
implementující TOTP. Pro nastavení stačí do aplikace naskenovat QR kód,
popř. opsat tajný klíč. Aplikace je pak kdykoli schopna zobrazit
aktuální heslo pro přihlášení, které se mění každých 30 sekund.
Do vpsAdminu si takto můžete přidat více autentizačních zařízení a k
přihlášení půjde využít kterékoli z nich, co máte zrovna po ruce.
Dvoufaktorová autentizace je vynucena máte-li nastaveno a povoleno
alespoň jedno zařízení. Bez tohoto zařízení se do vpsAdminu
nepřihlásíte: ani do webového rozhraní [4], ani u API [5].
Pokud náhodou o svoje autentizační zařízení přijdete, můžete použít
obnovovací kód, který vám vpsAdmin při nastavení zařízení jednorázově
zobrazí.
Postup nastavení i se screenshoty je popsán v KB:
https://kb.vpsfree.cz/navody/vps/uzivatele#dvoufaktorove_prihlasovani_2fa
Zavedení 2FA si vyžádalo zpětně nekompatibilní změnu v protokolu HaveAPI
[6], takže pokud používáte vpsfreectl [7] nebo jinou knihovnu pro
přístup k API [8], musíte aktualizovat.
ENGLISH:
TOTP [1] based two-factor authentication (2FA) can now be configured in
vpsAdmin. You can use it e.g. with smartphone applications like Google
Authenticator [2], FreeOTP [3], or really any program implementing TOTP.
It is very easy to configure, vpsAdmin will show you a QR code which you
then scan into the application. Alternatively, you can enter the secret
key manually. The application is then able to show you the current
one-time password to log in. The password changes every 30 seconds.
It is possible to configure multiple authentication devices like this.
Any one of the configured devices can be used to log in. 2FA is enforced
when there is at least one authentication device enabled. Without this
device, you will not be able to log into vpsAdmin. Both the web
interface [4] and the API [5] support and enforce 2FA.
Should you lose your only authentication device, you can use a recovery
code which vpsAdmin will show you after the device has been configured.
See our KB for more information:
https://kb.vpsfree.org/manuals/vps/users#two-factor_authentication_2fa
The introduction of 2FA forced us to make a backward-incompatible change
in the HaveAPI protocol [6], which powers our API. If you're using
vpsfreectl [9] or any other client library [10], you will have to upgrade.
[1] https://en.wikipedia.org/wiki/Time-based_One-time_Password_algorithm
[2]
https://play.google.com/store/apps/details?id=com.google.android.apps.authe…
[3] https://freeotp.github.io/
[4] https://vpsadmin.vpsfree.cz
[5] https://api.vpsfree.cz
[6] https://github.com/vpsfreecz/haveapi
[7] https://kb.vpsfree.cz/navody/vps/api#cli
[8] https://kb.vpsfree.cz/navody/vps/api#prace_s_api
[9] https://kb.vpsfree.org/manuals/vps/api#cli
[10] https://kb.vpsfree.org/manuals/vps/api#working_with_the_api
Jakub
Ahoj,
(English version below)
Ve vpsAdminu si nyní můžete nastavit dvoufaktorovu autentizaci (2FA)
pomocí TOTP [1]. Pro autentizaci můžete používat např. mobil s aplikací
Google Authenticator [2], FreeOTP [3], nebo libovolný program
implementující TOTP. Pro nastavení stačí do aplikace naskenovat QR kód,
popř. opsat tajný klíč. Aplikace je pak kdykoli schopna zobrazit
aktuální heslo pro přihlášení, které se mění každých 30 sekund.
Do vpsAdminu si takto můžete přidat více autentizačních zařízení a k
přihlášení půjde využít kterékoli z nich, co máte zrovna po ruce.
Dvoufaktorová autentizace je vynucena máte-li nastaveno a povoleno
alespoň jedno zařízení. Bez tohoto zařízení se do vpsAdminu
nepřihlásíte: ani do webového rozhraní [4], ani u API [5].
Pokud náhodou o svoje autentizační zařízení přijdete, můžete použít
obnovovací kód, který vám vpsAdmin při nastavení zařízení jednorázově
zobrazí.
Postup nastavení i se screenshoty je popsán v KB:
https://kb.vpsfree.cz/navody/vps/uzivatele#dvoufaktorove_prihlasovani_2fa
Zavedení 2FA si vyžádalo zpětně nekompatibilní změnu v protokolu HaveAPI
[6], takže pokud používáte vpsfreectl [7] nebo jinou knihovnu pro
přístup k API [8], musíte aktualizovat.
ENGLISH:
TOTP [1] based two-factor authentication (2FA) can now be configured in
vpsAdmin. You can use it e.g. with smartphone applications like Google
Authenticator [2], FreeOTP [3], or really any program implementing TOTP.
It is very easy to configure, vpsAdmin will show you a QR code which you
then scan into the application. Alternatively, you can enter the secret
key manually. The application is then able to show you the current
one-time password to log in. The password changes every 30 seconds.
It is possible to configure multiple authentication devices like this.
Any one of the configured devices can be used to log in. 2FA is enforced
when there is at least one authentication device enabled. Without this
device, you will not be able to log into vpsAdmin. Both the web
interface [4] and the API [5] support and enforce 2FA.
Should you lose your only authentication device, you can use a recovery
code which vpsAdmin will show you after the device has been configured.
See our KB for more information:
https://kb.vpsfree.org/manuals/vps/users#two-factor_authentication_2fa
The introduction of 2FA forced us to make a backward-incompatible change
in the HaveAPI protocol [6], which powers our API. If you're using
vpsfreectl [9] or any other client library [10], you will have to upgrade.
[1] https://en.wikipedia.org/wiki/Time-based_One-time_Password_algorithm
[2]
https://play.google.com/store/apps/details?id=com.google.android.apps.authe…
[3] https://freeotp.github.io/
[4] https://vpsadmin.vpsfree.cz
[5] https://api.vpsfree.cz
[6] https://github.com/vpsfreecz/haveapi
[7] https://kb.vpsfree.cz/navody/vps/api#cli
[8] https://kb.vpsfree.cz/navody/vps/api#prace_s_api
[9] https://kb.vpsfree.org/manuals/vps/api#cli
[10] https://kb.vpsfree.org/manuals/vps/api#working_with_the_api
Jakub
Ahoj,
snazim se rozbehat Collabora Online - CODE version na CentOS7.6.
Narazim, ale na problem se startem sluzby loolwsd. Dostavam tuto chybu:
May 19 18:56:36 <fqdn> loolwsd[18845]: kit-18850-18847 2019-05-19
16:56:36.047871 [ loolkit ] ERR Failed to install seccomp syscall
filter| common/Seccomp.cpp:204
May 19 18:56:36 <fqdn> loolwsd[18845]: kit-18850-18847 2019-05-19
16:56:36.047958 [ loolkit ] FTL LibreOfficeKit seccomp security
lockdown failed. Exiting.| kit/Kit.cpp:2468
Jak jsem pochopil, tak v OpenVZ zrejme nei seccomp podporovan.
Ale Docker, lze na OpenVZ spustit, ale jen do verze 1.10 (to me napadlo,
ze do teto verze Docker seccomp nevyzaduje, pak jiz ano?).
Nasel jsem moznost, jak pro CODE vypnout podporu seccomp, aby ji
nevyzadoval, ale zase se mi to zda, ze to neni bezpecne.
Dalsi moznost je zkusit rozjet CODE v dockeru, ale nic v dockeru v tuo
chvili neprovozuji a je otazka jak je na tom s bezpecnosti starsi verze
dockeru orpoti provozu aplikace bez dockeru bez seccomp filtru - ok,
jasne odpovedel jsem si sam, docker vede.
Resil toto nekdo na OpenVZ "virtualizaci"?
Co byste mi doporucili, jako bezpecnejsi reseni?
Bude seccomp dostupny na vpsAdminOS (resp. na VPSkach bezicich ve
vpsAdminOS)?
Predem diky za napady.
Johnny
Ahoj, potrebuji zvysit lokalne rozsah portu
echo 1024 65535 > /proc/sys/net/ipv4/ip_local_port_range
-su: /proc/sys/net/ipv4/ip_local_port_range: Permission denied
A docetl jsem se toto:
This server is a VPS and it is running in a OpenVZ container and I'm not allowed to modify any kernel parameter of that container.
Jak toho muzu docilit? Diky Dan
Ahojte,
potřeboval bych poradit, resp. ujistit, že je to možné a nedělám nějakou
hloupost. Vzhledem k nedostatku public IPv4 chci mít druhou VPSku pouze s
privátní IP a chci si na ní směrovat určitý provoz (tcp porty) z venku z
public IPv4, kterou má první VPSka. Na začátek si chci zřídit SSH přístup,
tedy například z veku x.x.x.x:222 -> y.y.y.y:22. Běžně NAT dělám přes
iptables.
Tohle jsem zkoušel:
iptables -t nat -A PREROUTING -d x.x.x.x -p tcp -m tcp --match multiport
--dports 222 -j DNAT --to-destination y.y.y.y:22
iptables -A FORWARD -i venet0:0 -o venet0:1 -p tcp -m tcp --match
multiport --dports 222 -m conntrack --ctstate NEW -j ACCEPT (tady přesně
nevím, jestli cílový port je 222 nebo 22, ale zkoušel jsem oboje)
Plus toto:
iptables -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
sysctl net.ipv4.ip_forward
(vrací net.ipv4.ip_forward = 1)
Něco mi říká, že bych na té druhé VPSce měl mít bránu zpět na tu první
VPSku, ať se pakety můžou vracet, nicméně pokud dělám traceroute, tak mi
jde provoz přes nějakou pro mě neznámou bránu, ačkoliv route vidím takový:
Kernel IP routing
table
Destination Gateway Genmask Flags Metric Ref Use
Iface
default 0.0.0.0 0.0.0.0 U 0 0 0
venet0
traceroute to seznam.cz (77.75.74.172), 30 hops max, 60 byte
packets
1 172.16.0.27 (172.16.0.27) 0.050 ms 0.017 ms 0.014
ms
2 vl128.cr3.r1-8.dc1.4d.prg.masterinter.net (81.31.40.97) 0.389 ms
0.629 ms 0.60
...
Nevím, jestli dělám něco úplně špatně, nevím jak do toho zasahuje OpenVZ,
atd... Budu rád za každou radu, díky.
P.
Ahoj,
(English version below)
Terraform [1] je nástroj pro správu infrastruktury pomocí konfiguračních
souborů. Podporuje spoustu různých poskytovatelů hostingu, cloudů a
podobných služeb. Nyní je možné pomocí něj konfigurovat i naše VPS. Náš
plugin pro Terraform aktuálně umí vytvářet a upravovat VPS, nahrávat
veřejné SSH klíče a spouštět příkazy přes SSH.
Plugin, pokyny k instalaci a ukázku použití najdete zde:
https://github.com/vpsfreecz/terraform-provider-vpsadmin
Případné chyby prosím hlaste u repozitáře na githubu. Samozřejmě se
můžete také zapojit do vývoje, chtělo by to ještě dodělat podporu pro
správu datasetů, mountů a určitě se toho najde více.
Terraform pluginy se nejsnadněji píšou v Golangu, takže jsme v Golangu
potřebovali taky klienta k našemu API. Díky tomu, že se naše API umí
samo pěkne zdokumentovat [2], klient pro Golang je kompletně automaticky
vygenerovaný. Výsledkem je tedy generátor klientských Golang knihoven
pro HaveAPI [3] a samotný klient k našemu API [4], který je možné použít
nezávisle na Terraformu.
ENGLISH:
Terraform [1] is a tool for infrastructure administration using
configuration files. It supports many cloud and hosting providers and
now it is possible to use it to manage VPS at vpsFree.cz as well. Our
provider plugin for Terraform allows you to create and manage VPS,
deploy SSH keys and use SSH provisioner.
The provider, install instructions and examples can be found at:
https://github.com/vpsfreecz/terraform-provider-vpsadmin
Please report bugs and issues at our github repository. You're also
welcome to join the development. The provider is still missing dataset
and mount management.
Since Terraform plugins are best written in Golang, we needed a client
to our API in Golang as well. Because our API is self-descriptive, the
Golang client library can be autogenerated. The result is a Golang
client generator [3] and the generated client [4] for our API. The
Golang client library can be used independently from Terraform.
[1] https://www.terraform.io
[2] https://github.com/vpsfreecz/haveapi
[3] https://github.com/vpsfreecz/haveapi/tree/master/clients/go
[4] https://github.com/vpsfreecz/vpsadmin-go-client
Jakub
Zdravím všechny,
nainstaloval jsem si Alpine na VPSko a chystal jsem se si spustit GitLab Runner, ale ukázalo se mi nejede docker.
Dodám že VPS mám na node1.stg a docker mám ve vpsAdmin povolený. Mám povolit i LXC nesting ?
Konkrétně mi u všech docker run <cokoliv> (a i u docker service create apod.) hází chybu:
docker: Error response from daemon: cgroups: cannot find cgroup mount destination: unknown.
Po nějakém googlení jsem našel pár issues na GitHubu, ale nikde řešení. Podle toho co to říká je že to nenašlo cgroup mount dest. při bližším “ohledání” jsem přes web. konzoli vypozoroval kde je asi problém - při spouštění VPS: https://gist.github.com/vojtamares/d217e620eb6342729572a6fcf4526ede (ať to má trochu formátování a ten email není dlouhý jak týden).
Tady se dostávám do míst kde už si sám neporadím a rozbít si to se mi nechce :D
Díky všem, kteří poradí.
S pozdravem,
Vojtěch Mareš
Ahoj,
najde se tady někdo, kdo taky testuje docker service na Staging serveru,
tedy na VpsAdminOS?
Mám problém s vystavením portu u služby. Pokud to zkusím klasicky přes
docker: "docker run -p 8088:80 --name web nginxdemos/hello", je kontejiner
z venku normálně dostupný.
Pokud použíju docker service: "docker service create -p 8088:80 --name web
nginxdemos/hello", port se nevystaví a z venku se do kontejineru nedostanu.
Podle "docker ps" však v obou případech konteiner běží.
Nesetkal jste se, prosím, někdo při testování s podobným problémem?
Server: node1.stg
Docker version 18.09.5, build e8ff056dbc
OS: Debian 9
Díky za případnou nápovědu
S pozdravem
*Pavel Sieder*
Ahojte vsichni,
ze schuze jeste bude zaznam (o vikendu), ale na Tomsovo prezentaci
nebyly bohuzel moc dobre videt fotky (to jsem sam zvedavy, jestli ze
zaznamu uvidime, cim se to opravilo...).
Takze jsem nahral vsechny slajdy sem:
https://vpsfree.cz/download/vpsf-10y-slides.tar.bz2
Tam je pekne videt, co jsme si nalozili za TODO; nejvetsi bod k skoro
okamzitemu reseni je pridani online hlasovani do stanov.
Podle aktualnich stanov, ktere jsou v rejstriku, jsme usnasenischopni
byli, ale jelikoz jsme nemeli pripravenou zadnou dobrou formulaci a uz
vubec nic lepsiho nas nenapadlo na miste, pojdme pripravit nad
stavajicim znenim novou verzi, kde online hlasovani bude zpracovane - a
dalsi zmeny, pokud nejake vlastne vubec jsou potreba, pojdme resit
online.
Ve stanovach aktualne mame usnasenischopnost schuze clenu vzdy - ale
videli jste sami ucast, organizaci hostujici spoustu lidi, nadeji, snu a
planu, potom muze par lidi podle aktualni nalady na jednom miste, behem
par hodin, i treba nedopatrenim, muze nepromyslena zmena stanov sita
horkou jehlou velmi rychle poslat do existencialnich problemu - to
nechceme, pojdme to tedy udelat relativne v klidu.
K reseni je jenom prevod hlasovani a zasedani Schuze a Mimoradne schuze
na takovy format, aby se mohla udit v case vice rozprostrene, s
projednanim vetsiny veci online;
moje predstava je nasledujici:
1. pozvanka k mimoradne i pravidelne radne svolane Schuzi bude muset
obsahovat sice predbezne, ale srozumitelne formulovane body k pripadnemu
hlasovani
2. probehne fyzicke setkani, na kterem se odprezentuji vsechny
informace, ktere clenove potrebuji ke kvalifikovanemu rozhodnuti, aspon
slajdy, idealne zaznamy se dostanou ke vsem clenum, i tem, kteri nebyli
fyzicky
3. cas pro diskuzi na mailing listech
4. hlasovani o konkretnim zneni konkretnich bodu pres vpsAdmin (zadny
novy bod nesmi v procesu pribyt, do hlasovani pujde jen to, co bylo na
uvodni pozvance, jinak to potrebuje novou Schuzi)
5. konec Schuze
Otazkou je - jak Oskar (Ondra Caletka) spravne resil promptne hned na
miste - jakym zpusobem se dobrat k vysledku, kdyz uz budeme mit nejaka
vstupni data. Co povazovat za spravny vysledek, jakou metodiku zvolit
pri scitani hlasu. To bychom se meli dost rychle rozhodnout a dohodnout
;)
Ve stanovach mame aktualne zakotvenou BDFL Radu i Kontrolni komisi
(benevolent dictator for life, tj. s neomezenym volebnim obdobim za
podminky, ze to delaji dobre) - tedy pokud bude celoclenska Schuze o
necem hlasovat, pujde vzdy relativne o vyznamnou udalost, protoze kdyz
se ma menit tym, se kterym se pocitalo, ze bude stabilni, asi to nebude
jen tak.
Je teda potreba mit proces odolny vuci vyvolavani emoci z jakekoliv
strany, jak to jen jde. Vyhrat musi vzdy technicky vyborne a s ohledem
na cile organizace vzdy nejlepsi mozne reseni, od toho vpsFree mame, aby
nam neco spolecneho pekne fungovalo, ne abychom meli o cem se dohadovat
;)
Pojdme tedy vymyslet co nejjednodussi, nejmensi zasah do Stanov, abychom
umoznili ^ priblizne aspon takhle dobry prubeh Schuze, a tim i budouci
fungovani.
Dostal jsem v sobotu od 25ti z Vas mandat hlasovat o zmene stanov,
pisemne, s ustnim porozumenim, ze pujde o zmenu stanov s ohledem na
umozneni online hlasovani.
Na 9.3. bude take zaznam a nejspis i live stream, Adam z AVC se nechal
hecnout a dojede do Brna ;)
Potreboval bych vedet, kdo vsechno prijdete - base48 neni velky,
vzhledem k ucasti v sobotu v Praze jsem tipoval, ze se zase sejdeme
komorne tak v 5 lidech, kdyztak prosim zakliknete svoji ucast v Doodle,
at pripravime aspon trochu mista ;)
https://doodle.com/poll/mn8gwux7eh8hqzer
Diky moc vsem, co jste prisli v sobotu - a diky vsem, kteri mi verite
natolik, ze jste se hecnuli tak, ze mi davate bianco sek na meneni
stanov - tahle duvera pro mne osobne hodne znamena, s takovouhle
podporou vim, ze ma smysl to delat dal, ve vetsim - a jeste lip.
Diky jeste jednou.
A za tyden a kousek v sobotu v Brne ;)
Nebo kdo chcete, i driv, v Base48 jsem skoro kazdy den...
A komu se zalibilo v Brmlabu, kdo mate chut si obcas pohrat s nejakou
elektronikou a podobne, nevahejte tam chodit - jeste se teprv napric
ceskoslovenskymi hackerspacy zacnou dit veci, stoji za to, byt u toho...
vic info casem ;)
/snajpa
Caute,
Pokusam sa vytvorit na mojej vpske swap:
sudo dd if=/dev/zero of=/swapfile bs=1G count=4
.... ale narazam na problem pri aktivacii:
swapon: /swapfile: skipping - it appears to have holes.
fallocate nie je na mojej instalacii podporovany, takze tu metodu nemozem pouzit (neviem ci by subor tak vytvoreny tiez nemal problem s dierami)
Google mi velmi nepomohol, tak snad mi poradi niekto z vas co s tym mozem urobit?
Ahoj všem,
ve dnech 28. a 29. května se v Brně koná druhá konference CSNOG [1].
CSNOG (Czech and Slovak Network Operators Group) [2] je po vzoru
zahraničních NOGů komunitou poskytovatelů přístupu k internetu,
provozovatelů telekomunikačních sítí, registrátorů domén a provozovatelů
počítačových sítí a technických nadšenců.
Právě probíhá call for abstracts [3], takže pokud máte co říct,
můžete přispět svým tématem. Pokud jste z okolí, mrkněte na to, je to
velmi zajímavá lokální akce, kde se sejde spousta chytrých lidí s mnoha
zkušenostmi z provozu sítí a služeb.
[1]: https://indico.csnog.eu/event/6/
[2]: https://www.csnog.eu/
[3]: https://indico.csnog.eu/event/6/abstracts/
--
Petr Krčmář
vpsFree.cz
Ahoj,
mám testovací server na Slackware 14.2 a zjistil jsem že v šabloně chybějí
některé balíčky. Problém se týká apache
Když jsem ho po instalaci spustil, dostal jsem tuto chybovou hlášku:
root@Slackware:/etc/rc.d# httpd
httpd: error while loading shared libraries: libaprutil-1.so.0: cannot
open shared object file: No such file or directory
Po nějakém tom hledání jsem zjistil, že chybějí tyto balíčky:
libsqlite3.so.0 => not found
libicui18n.so.56 => not found
libicuuc.so.56 => not found
libicudata.so.56 => not found
libsasl2.so.3 => not found
libapr-1.so.0 => not found
libsqlite3.so.0 => not found
libicui18n.so.56 => not found
libicuuc.so.56 => not found
libicudata.so.56 => not found
libsasl2.so.3 => not found
libapr-1.so.0 => not found
libsasl2.so.3 => not found
Rád bych je tam zkusil doplnit, ale umím zacházet s GitHubem. Mohl by mi
někdo poradit jak to udělat? Dovolím si odhadnout, že se musím
zaregistrovat, potom stáhnout na lokál kopii toho skriptu a doplnit do něj
ty balíčky, je to tak?
Děkuji
Petr
Ahoj,
chtel jsem dneska po schuzi zkusit vpsadminos kdyz mame tedy staging,
chtel jsem udelat novy alpine 3.9 container, ale bohuzel je supported
jenom alpine 3.6 .. 3.8. Chtel jsem na to nekde udelat pull request,
protoze predpokladam, ze by to nemelo byt slozite, ale nenasel jsem kde.
Podle https://kb.vpsfree.cz/navody/vps/vpsadminos jsem nasel
https://github.com/vpsfreecz/build-vpsfree-templates/tree/vpsadminos/templa…
ale tam je jenom alpine 3.8, 3.6 a 3.7 chybi, takze jsem asi nasel
spatne.
Mohl by mne nekdo popostrcit?
Diky,
W.
PS: Ja vim, muzu nainstalovat 3.8 a upgradnout, tak jsem to taky udelal
ale bylo by fajn tam mi i 3.9 kdyz uz je venku.
--
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.
Ahojte,
chtěl jsem se optat zda na Brno
2019-02-21 18:32:39.584 UCT
a např. také Brno, kdy zřejmě není celá konektivita v Brně dostupná.
2019-02-18 17:05:00.715 UTC
Mám primárně otázku, zda se jedná o nějaký reset switche/routru či o
překlonění na jinou konektivitu?
A také jsem se chtěl zeptat, zda bude 'schůze' tedy také v Brně, jak bylo
zmíněno na záznamu z Pražské?:)
--
S pozdravem,
Zdeněk Dlauhý
Web: www.pripravto.cz
Ahoj,
o víkendu je InstallFest, doufám, že všichni dorazíte. Budeme tam mít
stánek, povídat si s lidma a vařit dobrou kávu. Potřebujeme ale nějaké
pomocníky, aby bylo víc legrace a víc lidí na stánku. Tričko, oběd,
párty a věčná sláva jsou samozřejmostí pro toho, kdo se přidá.
Pokud rádi pomůžete alespoň kousek dne, bude to fajn. Prosím ohlaste se
Martinovi, který stánek koordinuje. martin.myska(a)vpsfree.cz
Díky
--
Petr Krčmář
vpsFree.cz
Ahoj všem,
připomínám, že zítra (23. února 2019) od 16:30 proběhne v pražském
Brmlabu výroční schůze a párty k 10. výročí vpsFree.cz. Pokud se ještě
dodatečně rozhodněte přijít, nezapomeňte potvrdit učast:
https://doodle.com/poll/axqy2afvi65dzfw5
Nejprve proběhne klasická členská schůze, shrneme historii a hlavně se
podíváme na
budoucnost, která je rozhodně zajímavá. Čeká nás změna platformy, úprava
stanov,
přebudování síťové infrastruktury, vstup do NIX.CZ a další novinky. To
vše se dozvíte
na výroční schůzi a pak hlavně na párty.
Pro více informací si přečtěte článek na blogu:
https://blog.vpsfree.cz/prvnich-10-let-je-za-nami-chystame-spoustu-novinek/
Díky, těšíme se na vás všechny!
--
Petr Krčmář
vpsFree.cz
Ahoj,
Snažím se rozjet openvpn jako internet gateway na vpsce. Jel jsem podle návodu na wiki vpsfree ale zdá se zastaralý. Už jsem ve stavu kdy se v pohodě připojím na vps vpn, ale net nefunguje-asi bude špatně ip adresa pro nat v návodu wiki? (https://kb.vpsfree.cz/navody/server/openvpn)
Našel jsem ještě maily z 2017 z tohoto listu ale nevím jestli ta konfigurace bude platit.
Poradíte? Btw configy mám stejné jako v návodu-jel jsem krok za krokem.
Díky,
Lukáš
Ahoj,
strejda Google mi tvrdošíjně nechce odpovědět, tak kdybyste měl někdo
čas a chuť poradit:
Už delší dobu mám v KDE Plasma asociovaný Okular snad úplně ke každému
MIME typu co je v systému. Nevím teda jestli to je bug nebo feature, ale
je to pěkně otravné. (Debian Buster, balíčky okular,
okular-extra-backends, okular-backend-odp, okular-backend-odt).
Zajímalo by mě, jestli to je standard - má to ještě někdo nebo jenom já?
A pak jestli někdo neví nějaký postup, jak to udělat aby se ta potvora
asociovala jenom s těmi typy na které má opravdu rozumný backend. Chtěl
jsem zkusit balíček odebrat a zase přidat, ale okular je závislost
kde-standard a ten zase task-kde-desktop a nerad bych si odebral celý
desktop co používám. A měnit závislosti task-* na manuální je stejná
pakárna jako rušit ty asociace ručně.
Díky,
Štěpán.
Ahoj,
nevěděl byste prosím někdo, proč se Postfix chová tak jak se chová, tj. už 2 týdny se snaží doručovat poštu na server, který je zřejmě offline a navíc je v pořadí MX priorit na druhém místě?
Nevím jak to měl příjemce nastavené v lednu a jestli si postfix nedrží nějakou connection cache (googlim), ale 2 týdny mi přijdou moc.
Feb 5 10:36:17 fra postfix/smtp[30200]: 9E15B40210: to=<xxx(a)fos-sro.cz>, relay=none, delay=435408, delays=435348/0/60/0, dsn=4.4.1, status=deferred (connect to mgate1-backup.fos-sro.cz[146.255.31.26]:25: Connection timed out)
mail_version = 3.1.8
Debian 9.7
Díky předem za radu, s pozdravem
Nikos
Ahoj,
neřešili jste někdo gitlab runner na nixosu?
Když použiju nasledujici config, systemctl služba se sic zapne, ale do toml
souboru (/etc/gitlab-runner/config.toml) se nezapíše a nezaregistruje se
samotny runner (jak to například děla ten baliček po naklonovani https://
gitlab.com/arianvp/nixos-gitlab-runner/ )
```
{
services.gitlab-runner = {
enable = true;
configOptions = {
runners = [
{
name = "nixos";
url = "https://gitlab.com/";
token = "tady_token";
executor = "shell";
}];
};
};
}
```
Ahoj,
nějak jsem nikde nedohledal informace k rozdělování prostředků k
jednotlivým VPS. Prosím, mohl by mi někdo napsat buď link kde to je
napsané nebo nějak aspoň stručně co lze a jak přerozdělovat mezi VPS?
Aktuálně mám 2 VPS a jednu bych potřeboval "vytunit" a druhou trochu
"přiškrtit".
Ve VPSAdminu vidím, že asi půjde přehodit kus paměti a nějaké to jádro
(předpokládám, že jednomu uberu a to mohu druhému přidat ??), mohu za běhu?
Ale zdá se mi, že asi nebudu moci takto hýbat s datasety, ne? Ty mají ID
datasetu shodné s ID VPSky, když dám create dataset, tak dělám jen
subdataset. I když v editaci datasetu se skoro zdá, že velikost editovat
mohu a že bych tedy mohl jednomu zmenšit. Tak když jeden dataset
zmenším, mohu potom u druhé VPSky dataset zvětšit?
A doplňující otázka - mám VPSky v různých lokalitách (prg, brq) - je to
možné i tak?
Předem díky za trochu světla,
Š.
Ahoj,
snažil jsem se marně poskládat aktualní stav vpsadminos, ale nějak jsem z
toho zmaten, proto se hloupě zeptám konkrétně:
Je už možné přesunout se se svou vps na vpsadminos, včetně své ipv4,
případně výměnou za jinou veřejnou ipv4? Svou vps používám povětsinou jako
glorifikovanou ssh proxy a občas si tam něco pustím, takže nepotřebuju
úplně produkční spolehlivost, i když je samozřejmě vítaná.
Zároveň nevím zda jsem použil správný komunikační kanál, tak mě případně
prosím přesměrujte, kam to patří.
Díky,
Petr
Ahoj,
zkousel sem rozchodit na VPSfree (Ubuntu 16.04) nextcloud, coz se podarilo, nicmene chtel sem do nej mountnout dalsi data z disku, ktery je fyzicky u me doma v PC ktere bezi Ubntu 18.04 a tady sem narazil na problem s kompletnim vytizenim linky (50/50mbit) mezi temito stroji v pripade, ze vylistuju data z druheho disku v nextcloudu.
Popisu to trosku detailneji:
- na vpsfree ubuntu 16.04, posledni verze nextloudu, php 7.2, mariadb
- datova slozka nextcoudu je v /srv/nextcloud
- user slozka je tim padem /srv/nextcloud/user
- do /srv/nextcloud/user/files/music/rec-dread je mountnuty pres sshfs folder z toho druheho PC beziciho ubuntu 18.04 pomoci nasledujiciho fstab zaznamu (jsou tam vymenene ssh klice a mezi masinama je openvpnka proto 172 IP):
sshfs#mountrecvps@172.23.0.8:/mnt/music/audio2/REC/ /srv/nextcloud/user/files/music/rec-dread/ fuse defaults,delay_connect,idmap=user,ro,reconnect,allow_other 0 0
- do nextcloudu sem tyhle fajly naimportoval podle manualu pres:
sudo -u www-data ./occ files:scan --path="/user/files"
- data dou pres nextclouc stahovat, prehravat mp3ky, nejdou mazat / prejmenovavat protoze read only (naschval), potud vse OK
- bohuzel jakmile user v nextcloudu jen vylistuje (otevre) tu rec-dread slozku, zacne vpsfree tahat plnou rychlosti (tj 50mbit) nekolik (co si pamatuju tak 5 nebo 6) souboru z toho druheho PCka, toto trva dokud nerestartuju apache na VPSfree (ty fajly tam maji stovky mega kazdy, nechal sem to bezet asi 10-15minut a furt to tahalo, za tu dobu potahal tak 3GB+)
ALE...
Pokud nextcloud dam primo na ten druhy stroj kde je fyzicky ten disk, je vse OK, postup:
- vyinstalil sem nextcloud posledni verze, mariadb, stejne jako na vpsce
- do user slozky do slozky music bindnul ten samy folder rec-dread (akorat tentokrate ne pres sshfs protoze to je lokalni disk) a okriplil to linux pravama na read only
- import pres
sudo -u www-data ./occ files:scan --path="/user/files"
- vysledek - vse funguje jak ma, zadne besneni s datovym diskem se v pripade vylistovani rec-dread nekonna (v iotop sem ani nepostrehl ze by na nej sahl)
Netusi nekdo v cem by mohl byt problem / kam kouknout / co zkusit / co delam blbe? Aktualne nevim jestli ten problem dela nextcloud, vpsfree, sshfs nebo kombinace techto veci dohromady (openvpn sem vyloucil coby pricinu, ta s tim nema imho moc co delat, i kdyz data pres ni tecou, nicmene ten sshfs mount funguje spolehlive, nepada, takze openvpn sem neuvazoval).
Ten druhy PC je stary a ten nexcloud na nem sice jede, ale odezva neni tak rychla jako kdyz bezi na VPSce.
Diky - Buger
Ahoj,
vyzná se někdo v konfiguraci RSpamd prosím? Na několikátý pokus se ho
pokouším nasadit, protože mě vytáčí spam, který leze pouze na jednu
mou emailovou adresu, na ostatní neleze žádný spam.
Vše už mi zřejmě šlape, jak má. Akorát když pošlu GTUBE
https://spamassassin.apache.org/gtube/ , tak se mi mail vrátí, jako
nedoručený, ale já chci, aby se email hodil do spamu a ne, aby se mi
vrátil jako nedoručený.
Instaloval jsem podle návodu
https://thomas-leister.de/en/mailserver-debian-stretch/ .
Díky za pomoc.
Petr
Ahoj,
od vypadku viz subj. mi na VPSce odmita startovat SSH a SCREEN - oboje ma problem s chybejicim adresarem ve /var/run, jede to na ubuntu 16.04
- sshd chybi /var/run/sshd a proto nenajede po restartu, musim rucne vytvorit /var/run/sshd a nastartovat sshd, nicmene po dalsim restartu adresar opet chybi a je nutno ho vytvorit znova
---
root@bgrserver:~# systemctl status sshd
● ssh.service - OpenBSD Secure Shell server
Loaded: loaded (/lib/systemd/system/ssh.service; enabled; vendor preset: e
Active: failed (Result: start-limit-hit) since Mon 2019-01-14 16:06:32 UTC
Process: 376 ExecStartPre=/usr/sbin/sshd -t (code=exited, status=255)
xxx@bgrserver:~$ sudo cat /var/log/syslog | grep ssh
[sudo] password for xxx:
Jan 14 16:06:14 bgrserver systemd-tmpfiles[86]: Failed to validate path /var/run/sshd: Too many levels of symbolic links
Jan 14 16:06:31 bgrserver sshd[326]: Missing privilege separation directory: /var/run/sshd
Jan 14 16:06:31 bgrserver systemd[1]: ssh.service: Control process exited, code=exited status=255
Jan 14 16:06:31 bgrserver systemd[1]: ssh.service: Unit entered failed state.
Jan 14 16:06:31 bgrserver systemd[1]: ssh.service: Failed with result 'exit-code'.
Jan 14 16:06:31 bgrserver systemd[1]: ssh.service: Service hold-off time over, scheduling restart.
---
- screenu prozmenu chybi /var/run/screen a situace je stejna jako u sshd - po restartu je nutne rucne znova vytvorit a zmenit mod na 777, pak jede
---
xxx@bgrserver:~$ screen -S test
Cannot make directory '/var/run/screen': Permission denied
... screen nejede ...
xxx@bgrserver:~$ sudo mkdir /var/run/screen
[sudo] password for xxx:
xxx@bgrserver:~$ screen -S test
Directory '/var/run/screen' must have mode 777.
xxx@bgrserver:~$ sudo chmod 777 /var/run/screen
xxx@bgrserver:~$ screen -S test
... ted screen funguje, co po rebootu? ...
[detached from 7334.test]
xxx@bgrserver:~$
xxx@bgrserver:~$ sudo reboot
packet_write_wait: Connection to 37.205.11.73 port 22: Broken pipe
... ted je treba nahodit sshd pres VPSadmina, vytvorenim /var/run/sshd a restartem sshd, jinak connection refused ...
jdrozd@jdrozd-MS-7592:~$ ssh xxx(a)srv.dread.cz
ssh: connect to host srv.dread.cz port 22: Connection refused
jdrozd@jdrozd-MS-7592:~$ ssh xxx(a)srv.dread.cz
Welcome to Ubuntu 16.04.5 LTS (GNU/Linux 3.16.6-042stab134.43 x86_64)
* Documentation: https://help.ubuntu.com
* Management: https://landscape.canonical.com
* Support: https://ubuntu.com/advantage
Last login: Wed Jan 16 06:10:45 2019
xxx@bgrserver:~$ screen -S test
Cannot make directory '/var/run/screen': Permission denied
... po restartu je to o5 v ...
---
Pritom prava na /var/run potazmo /run kam se to symlinkuje jsou stejna jako na jine ubuntu 16.04 masine kde vse funguje.
---
xxx@bgrserver:~$ ll /var | grep run
lrwxrwxrwx 1 root root 9 lis 15 2016 lock -> /run/lock/
lrwxrwxrwx 1 root root 4 lis 15 2016 run -> /run/
xxx@bgrserver:~$ ll / | grep run
drwxr-xr-x 17 root root 560 led 16 06:11 run/
---
Nesetkal se nekdo z Vas s necim podobnym, nebo netusite kde by mohl byt problem?
Poslal sem to i na podporu VPSfree, protoze si nejsem jisty jestli se jedna o problem na jejich strane, nebo se mi rozbilo Ubuntu (i kdyz k tomu nemelo duvod)...
Diky - Buger
zdravim
na nasem vps je ubunutu 16.04
po reboot nenajede postgres
> FATAL: could not create lock file
"/var/run/postgresql/.s.PGSQL.5432.lock": Permission denied
> chmod 777 /var/run/postgresql
umozni alespon start postgres
systemctl start postgresql(a)10-main.service
se sice zasekne, takze pro navrat do console musim Ctrl+C, ale DB zda se
bezi, no service je v nejakem divnem stavu:
> postgresql.service loaded active
exited PostgreSQL RDBMS
> postgresql(a)10-main.service loaded activating start start
PostgreSQL Cluster 10-main
po restartu stroje jsou ale permission znovu spatne, takze to nenajede
neresil ste toto nahodu nekdo?
predem dik za pripadnou radu
s pozdravem
tyctor
zdravim ve spolek
na nasem vps jsem chtel installnout fail2ban
jenze se pred nim updatnul systemd
a na nem ted pada install cehokoliv
fchownat() of /var/log/journal failed: Invalid argument
dpkg: error processing package systemd (--configure):
installed systemd package post-installation script subprocess returned
error exit status 73
zkousel jsem dowgrade
> apt install systemd=229-4ubuntu4 libsystemd0=229-4ubuntu4
> apt-mark hold systemd
to jsem nasel tady
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1804847
ale to se zasekne uplne, na nejakej Connection timed out
dpkg: warning: downgrading libsystemd0:amd64 from 239-7ubuntu10 to
229-4ubuntu4
(Reading database ... 41892 files and directories currently installed.)
Preparing to unpack .../libsystemd0_229-4ubuntu4_amd64.deb ...
Unpacking libsystemd0:amd64 (229-4ubuntu4) over (239-7ubuntu10) ...
Setting up libsystemd0:amd64 (229-4ubuntu4) ...
dpkg: warning: downgrading systemd from 239-7ubuntu10 to 229-4ubuntu4
(Reading database ... 41892 files and directories currently installed.)
Preparing to unpack .../systemd_229-4ubuntu4_amd64.deb ...
Unpacking systemd (229-4ubuntu4) over (239-7ubuntu10) ...
Setting up systemd (229-4ubuntu4) ...
Installing new version of config file /etc/pam.d/systemd-user ...
Installing new version of config file /etc/systemd/journald.conf ...
Installing new version of config file /etc/systemd/logind.conf ...
Installing new version of config file /etc/systemd/resolved.conf ...
Installing new version of config file /etc/systemd/system.conf ...
Installing new version of config file /etc/systemd/timesyncd.conf ...
Installing new version of config file /etc/systemd/user.conf ...
addgroup: The group `systemd-journal' already exists as a system group.
Exiting.
Could not watch jobs: Connection timed out
nevite nahodou nekdo co s tim?
tyctor
Hello,
I ran into some bug with Systemd during an upgrade of my Debian 8 and the
vps became unusable.
I tried to restore from backup, setup the vps from scratch and then restore
the backup, but none of that worked.
What worked was to clone the vps to staging, however the IPs are different.
Since it would be quite hard to restore manually all the configs and users
to the fresh install of the production vps, is it possible to migrate the
IPs from production to staging?
Thank you!
--
-p
zdravim ve spolek
vsiml jsem si, ze na nasi vps smerujou requesty z jinych domen
nejcasteji je to z domeny leopardo.ackee.cz ale take z veggiegarden.cz,
vps.ackee.cz, zahrady-krupkova.cz
zapnul jsem u nas logovani jen nedavno, za 4 dny prislo dohromady 150
takovych requestu
muze to byt chyba v nastaveni uvedenych domen, nebo proc se to deje?
dik za info
z pozdravem
tyctor
Ahoj,
testování vpsAdminOS se dostává do další významné fáze: můžete klonovat
produkční VPS z OpenVZ na staging s vpsAdminOS [1].
VPS se klonují stejně jako na Playground [2], jen jako lokaci vyberte
Staging. Dejte pozor na checkbox "Stop" -- můžete si vybrat, jestli
chcete při klonování produkční VPS vypnout pro vytvoření konzistentního
snapshotu (data z paměti se zapíšou na disk). Pro pouhé otestování na
stagingu to ale nemusí být potřeba a klonování tak můžete provést bez
restartu produkční VPS. Klonuje se vše kromě mountů, ty jsou prozatím
odstraněny.
Pokud by někdo chtěl klonovat větší VPS, nebo už na stagingu něco máte,
napiště prosím na podporu a navýšíme vám tam RAM/HDD, abyste se tam vešli.
Nyní očekávám větší zájem o vyzkoušení zda běží vše co potřebujete.
Naším cílem je zajistit, aby následné migrace VPS probíhaly spolehlivě a
z pohledu administátora VPS nebylo potřeba nic moc řešit, takže prosím
hlaste vše na co narazíte, abychom se mohli připravit. Napište nám
prosím i když bude vše v pořádku. Potřebujeme vědět, jak na tom jsme, co
funguje a co ne :)
Po naklonování musí být funkční:
- IPv4/IPv6 síť
- vzdálená konzole
- ideálně všechny služby ve VPS
Pokud něco z toho nepůjde, nebo něco bude vyžadovat změnu konfigurace z
důvodu jiné virtualizace/kernelu, informujte nás prosím.
S migracemi všech produkčních VPS bychom chtěli začít v Q1/Q2 2019,
podle toho co bude potřeba dodělat. V listopadu 2019 končí podpora
OpenVZ Legacy kernelu ze strany OpenVZ teamu [3], takže do té doby
chceme stihnout přesunout co nejvíce VPS na vpsAdminOS.
[1] https://kb.vpsfree.cz/navody/vps/vpsadminos
[2] https://kb.vpsfree.cz/navody/vps/sprava#klonovani_vps
[3] https://wiki.openvz.org/Releases
Jakub
Ahoj,
při klonování produkční VPS z OpenVZ na staging s vpsAdminOS, se mě nezklonovaly Private IPv4 a ani je nelze ve staging s vpsAdminOS dodatečně nastavit. Tedy současnou konfiguraci produkční VPS z OpenVZ nemohu ve staging s vpsAdminOS testovat.
Bohužel neznám ani finální pánovanou konfiguraci produkční VPS s vpsAdminOS co se tíká parametrů a síťování či přidělení a počtu IP4, IP6 či Private IPv4 adres za NATem pro produkční VPS s vpsAdminOS, abych mohl tuto konfiguraci případně testovat.
Mohli by jste zveřejnit plánovanou konfiguraci pro produkční VPS s vpsAdminOS, aby bylo jasné, co do budoucna očekávat?
Renda
čt 1. 11. 2018 v 9:40 odesílatel Jakub Skokan <jakub.skokan(a)vpsfree.cz <jakub.skokan(a)vpsfree.cz>> napsal:Ahoj,
testování vpsAdminOS se dostává do další významné fáze: můžete klonovat
produkční VPS z OpenVZ na staging s vpsAdminOS [1].
VPS se klonují stejně jako na Playground [2], jen jako lokaci vyberte
Staging. Dejte pozor na checkbox "Stop" -- můžete si vybrat, jestli
chcete při klonování produkční VPS vypnout pro vytvoření konzistentního
snapshotu (data z paměti se zapíšou na disk). Pro pouhé otestování na
stagingu to ale nemusí být potřeba a klonování tak můžete provést bez
restartu produkční VPS. Klonuje se vše kromě mountů, ty jsou prozatím
odstraněny.
Pokud by někdo chtěl klonovat větší VPS, nebo už na stagingu něco máte,
napiště prosím na podporu a navýšíme vám tam RAM/HDD, abyste se tam vešli.
Nyní očekávám větší zájem o vyzkoušení zda běží vše co potřebujete.
Naším cílem je zajistit, aby následné migrace VPS probíhaly spolehlivě a
z pohledu administátora VPS nebylo potřeba nic moc řešit, takže prosím
hlaste vše na co narazíte, abychom se mohli připravit. Napište nám
prosím i když bude vše v pořádku. Potřebujeme vědět, jak na tom jsme, co
funguje a co ne :)
Po naklonování musí být funkční:
- IPv4/IPv6 síť
- vzdálená konzole
- ideálně všechny služby ve VPS
Pokud něco z toho nepůjde, nebo něco bude vyžadovat změnu konfigurace z
důvodu jiné virtualizace/kernelu, informujte nás prosím.
S migracemi všech produkčních VPS bychom chtěli začít v Q1/Q2 2019,
podle toho co bude potřeba dodělat. V listopadu 2019 končí podpora
OpenVZ Legacy kernelu ze strany OpenVZ teamu [3], takže do té doby
chceme stihnout přesunout co nejvíce VPS na vpsAdminOS.
[1] https://kb.vpsfree.cz/navody/vps/vpsadminos <https://kb.vpsfree.cz/navody/vps/vpsadminos>
[2] https://kb.vpsfree.cz/navody/vps/sprava#klonovani_vps <https://kb.vpsfree.cz/navody/vps/sprava#klonovani_vps>
[3] https://wiki.openvz.org/Releases <https://wiki.openvz.org/Releases>
Jakub
_______________________________________________
Community-list mailing list
Community-list(a)lists.vpsfree.cz <Community-list(a)lists.vpsfree.cz>
http://lists.vpsfree.cz/listinfo/community-list <http://lists.vpsfree.cz/listinfo/community-list>
Ahoj,
mám nainstalovaný Virtualmin
<https://geotrack.email/ext/l?idx=KqmNAgzO4FR1NOqWVtbd&ret=https%3A%2F%2Fwww…>
na
debian8, všechno vypadá v pořádku, ale nevidí to php. Php 5.6, 7.0, 7.1,
7.2 je nainstalované, ale když chci nainstalovat wordpress (klasickým
způsobem) tak kvůli nefunkčnosti php to jen vypíše, místo načtení
instalačního scriptu:
<?php
> /**
> * Front to the WordPress application. This file doesn't do anything, but
> loads
> * wp-blog-header.php which does and tells WordPress to load the theme.
> *
> * @package WordPress
> */ /**
> * Tells WordPress to load the WordPress theme and output it.
> *
> * @var bool
> */
> define('WP_USE_THEMES', true); /** Loads the WordPress Environment and
> Template */
> require( dirname( __FILE__ ) . '/wp-blog-header.php' );
Když chci ve virtualmin nainstalovat SquirrelMail tak to hlásí chybu:
> Failed to install script : Could not find PHP version for
> /home/"user"/public_html/squirrelmail
Při php -v to vypíše verzi:
> php -v
> PHP 5.6.38-0+deb8u1 (cli) (built: Sep 20 2018 02:32:02)
> Copyright (c) 1997-2016 The PHP Group
> Zend Engine v2.6.0, Copyright (c) 1998-2016 Zend Technologies
> with Zend OPcache v7.0.6-dev, Copyright (c) 1999-2016, by Zend
> Technologies
Jak to teda rozchodit?
Jindra
[image: GeoTrack]
<https://geotrack.email/?utm_source=gmail&utm_medium=signature&utm_campaign=…>
Sender
notified with GeoTrack
<https://geotrack.email/?utm_source=gmail&utm_medium=signature&utm_campaign=…>
[image: 48]
Ahoj,
podařilo se nám najít jiný, jednodušší způsob routování IP adres do VPS
bez spojovacích sítí. Ve VPS na stagingu tak už nejsou žádné spojovací
adresy, jen adresy veřejné. Jak síťování VPS aktuálně funguje je popsáno
zde:
https://vpsadminos.org/networking/veth-routed/#routing
U VPS na stagingu vpsAdmin rozlišuje adresy sítí, ty jsou do VPS
naroutované, a koncové adresy co jsou přiřazeny na rozhraní. Správa IP
adres je tak ve webovém rozhraní rozdělena na dva formuláře. Je to zatím
jen takový základ na kterém budeme později stavět.
Díky zrušení spojovacích adres funguje maškaráda v iptables a s tím i
výchozí síť v dockeru, která maškarádu využívá. Není potřeba si vytvářet
vlastní síť. Teď už instalace dockeru neobsahuje žádné kroky navíc.
Zbývá dořešit delegace ZFS datasetů do VPS, aby se v dockeru dal použít
ZFS driver.
Pokud jste chtěli vpsAdminOS vyzkoušet, ale nechtělo se vám instalovat
Nix a zjišťovat jak se to sestavuje, sorki připravil ISO s vpsAdminOS
[1], které si můžete stáhnout a rovnou nabootovat. Je to live systém a
obsahuje i instalátor [2], pokud to chcete nainstalovat na disk nebo si
vyzkoušet deklarativní konfiguraci s Nixem.
Od pátku jsou VPS na stagingu zálohované, abychom se nemuseli bát o
data. Obnova VPS ze záloh funguje, ale na staging si je zatím
nepřipojíte. Na produkční VPS ty zálohy připojit půjdou. Nemáme ještě
dořešené NFS, přijde to pak spolu s NASem.
Koncem srpna jsme narazili na nečekané omezení: věděli jste, že
maximální počet memory cgroup je 65536? Několika členům už se podařilo
je vyčerpat, takže jsme řešili jak ten limit navýšit. snajpa napsal
patch [3] do kernelu, který navyšuje maximální počet memory cgroup na
2147483648, nicméně zatím s tím nefunguje swap. Nám to nevadí, protože
swap nepoužíváme.
Dále bylo potřeba omezit počet cgroup, které mohou vytvořit jednotlivé
VPS, aby nikdo nemohl vyčerpat všechny a omezit tak ostatní. K tomuto
účelu snajpa vytvořil cglimit cgroup controller [4]. Můžete jej vidět i
a používat i ve VPS. Přes `cglimit.all.max` se nastavuje limit na počet
všech cgroup a přes `cglimit.memory.max` jen memory cgroupy.
Za pomoc s testováním děkujeme (nicky na IRC): ppar, somm, domogled,
pdostal, etnyx a všem dalším co píší na podporu. Pokud narazíte na
nějakou chybu, dejte nám o tom prosím vědět, rádi to opravíme.
[1] https://iso.vpsadminos.org
[2] https://vpsadminos.org/os/installation/
[3]
https://github.com/vpsfreecz/vpsadminos/commit/87cd90ab99b5f4d527d3b33adfda…
[4]
https://github.com/vpsfreecz/vpsadminos/commit/e73db73975e240b865497af4b40d…
Jakub
Z nějakého důvodu po upgrade Debianu na verzi 9 (stretch) mi nefunguje logování do souborů. Procházel jsem konfiguraci /etc/syslog-ng, ale nenašel žádný důvod proč by to nemělo jít.
Přes journalctl ty logy vidím. Nevím zda to nesouvisí s tím, že u každé služby hlásí systemd např.:
systemd-udev-trigger.service: Failed to set invocation ID on control group /system.slice/systemd-udev-trigger.service, ignoring: Operation not permitted
systemd-journal-flush.service: Failed to set invocation ID on control group /system.slice/systemd-journal-flush.service, ignoring: Operation not permitted
networking.service: Failed to set invocation ID on control group /system.slice/networking.service, ignoring: Operation not permitted
... atd.
Ahoj,
zkousim ISPConfig (3.1.11) na Debian 9. Vytvorim uzivatele, domenu a
FTP. Nahraju obsah do adresare web. V systemu je obsah skutecne treba na
/var/www/clients/client6/web10/web. Puvodni default obsah jsem smazal.
Nicmene kdyz se na tu domenu podivam kdekoliv a jakymkoli prohlizecem,
vidim stale ten default obsah. Predpokladam, ze to bude nejaka banalni
zacatecnicka chyba, ale vygooglit se mi nic rozumneho nepodarilo.
Zkousel jsem to na vic domenach a porad stejne.
Dik
Libor Boldan
Ahojte,
tak mame nainstalovane nove masiny, maji komplet zaplatovani proti vsem
znamym CPU chybam;
pokud mate senzitivni veci, piste na podporu, presuneme vam to. Prednost
dostanou ti, co maji na disku zabrano par desitek GB :)
Kdo jste mel v posledni dobe problem s vykonem IO, piste taky.
Nove servery maji zatim jenom 3x 2T SSD v raidz, bude se pridavat dal po
3 SSD (cca 60-70k CZK najednou, proto takhle);
jsou to bazarove Intely, 2x E5-2680 v4 @ 2.40GHz (28 cores, vypnute HT)
+ 512 GB RAM, Dell R730xd, jeden vysel cca na 300k CZK (SAS3, 2x10GE,
iDRAC enterprise and what not).
Ve vpsAdminu to jsou: node17.prg, node18.prg a node4.brq.
Mam z nich docela radost, svisti pekne.
Ale abych pravdu rekl, uplne nejvic se tesim na to, az se AMD vytahne s
trochu poaktualizovanym fabricem mezi temi jejich cipy a DDR4 az
zlevni... Zatim Intel vede vykonove pro nase use-cases i po vsech
mitigacich (pokud teda pocitame apriori vsechen symetric multithreading
za nebezpecny, i kdyz to AMD zatim nikdo verejne nedokazal).
/snajpa
Hoj,
resim tedka takovou zajimavou vec. Mam servery s LXD. Tech serveru jsou ted
desitky a v planu je rust az na tisice nebo nizke desetitisice. Konfiguracne
jsou vsechny plus minus stejny. A ja chci zaridit, abych:
- mohl snadno pridat nove servery/desitky serveru
- mohl kontejner presouvat odkudkoliv kamkoliv
Klasicka cesta pres lxc remote mi prijde dost silena, protoze bych pak mel
konfiguraci s tisici remoty a musel bych to volat na kazdem stroji a to
pochybuju, ze bude zdrave a udrzitelne (Vlastne pro N serveru budu muset
volat N-1 krat lxd remote add, to je hodne osklive). Zavest omezeni
"kontejner se nepresouva kamkoliv, ale pouze po nodech v ramci racku" neni
pruchozi. Napadlo me pouzit LXD clustering, ale nikdy jsem si s tim nehral.
Mate nekdo zkusenosti s LXD clusteringem nebo s movem kontejneru mezi vetsim
mnozstvim nodu? Jsou na to nejake tipy a triky, jak se z toho nezblaznit?
Diky
Ondra Flidr