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