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?