Ahoj,
neřešili jste někdo gitlab runner na nixosu?
Když použiju nasledujici config, systemctl služba se sic zapne, ale do toml
souboru (/etc/gitlab-runner/config.toml) se nezapíše a nezaregistruje se
samotny runner (jak to například děla ten baliček po naklonovani https://
gitlab.com/arianvp/nixos-gitlab-runner/ )
```
{
services.gitlab-runner = {
enable = true;
configOptions = {
runners = [
{
name = "nixos";
url = "https://gitlab.com/";
token = "tady_token";
executor = "shell";
}];
};
};
}
```
Ahoj,
nějak jsem nikde nedohledal informace k rozdělování prostředků k
jednotlivým VPS. Prosím, mohl by mi někdo napsat buď link kde to je
napsané nebo nějak aspoň stručně co lze a jak přerozdělovat mezi VPS?
Aktuálně mám 2 VPS a jednu bych potřeboval "vytunit" a druhou trochu
"přiškrtit".
Ve VPSAdminu vidím, že asi půjde přehodit kus paměti a nějaké to jádro
(předpokládám, že jednomu uberu a to mohu druhému přidat ??), mohu za běhu?
Ale zdá se mi, že asi nebudu moci takto hýbat s datasety, ne? Ty mají ID
datasetu shodné s ID VPSky, když dám create dataset, tak dělám jen
subdataset. I když v editaci datasetu se skoro zdá, že velikost editovat
mohu a že bych tedy mohl jednomu zmenšit. Tak když jeden dataset
zmenším, mohu potom u druhé VPSky dataset zvětšit?
A doplňující otázka - mám VPSky v různých lokalitách (prg, brq) - je to
možné i tak?
Předem díky za trochu světla,
Š.
Ahoj,
snažil jsem se marně poskládat aktualní stav vpsadminos, ale nějak jsem z
toho zmaten, proto se hloupě zeptám konkrétně:
Je už možné přesunout se se svou vps na vpsadminos, včetně své ipv4,
případně výměnou za jinou veřejnou ipv4? Svou vps používám povětsinou jako
glorifikovanou ssh proxy a občas si tam něco pustím, takže nepotřebuju
úplně produkční spolehlivost, i když je samozřejmě vítaná.
Zároveň nevím zda jsem použil správný komunikační kanál, tak mě případně
prosím přesměrujte, kam to patří.
Díky,
Petr
Ahoj,
zkousel sem rozchodit na VPSfree (Ubuntu 16.04) nextcloud, coz se podarilo, nicmene chtel sem do nej mountnout dalsi data z disku, ktery je fyzicky u me doma v PC ktere bezi Ubntu 18.04 a tady sem narazil na problem s kompletnim vytizenim linky (50/50mbit) mezi temito stroji v pripade, ze vylistuju data z druheho disku v nextcloudu.
Popisu to trosku detailneji:
- na vpsfree ubuntu 16.04, posledni verze nextloudu, php 7.2, mariadb
- datova slozka nextcoudu je v /srv/nextcloud
- user slozka je tim padem /srv/nextcloud/user
- do /srv/nextcloud/user/files/music/rec-dread je mountnuty pres sshfs folder z toho druheho PC beziciho ubuntu 18.04 pomoci nasledujiciho fstab zaznamu (jsou tam vymenene ssh klice a mezi masinama je openvpnka proto 172 IP):
sshfs#mountrecvps@172.23.0.8:/mnt/music/audio2/REC/ /srv/nextcloud/user/files/music/rec-dread/ fuse defaults,delay_connect,idmap=user,ro,reconnect,allow_other 0 0
- do nextcloudu sem tyhle fajly naimportoval podle manualu pres:
sudo -u www-data ./occ files:scan --path="/user/files"
- data dou pres nextclouc stahovat, prehravat mp3ky, nejdou mazat / prejmenovavat protoze read only (naschval), potud vse OK
- bohuzel jakmile user v nextcloudu jen vylistuje (otevre) tu rec-dread slozku, zacne vpsfree tahat plnou rychlosti (tj 50mbit) nekolik (co si pamatuju tak 5 nebo 6) souboru z toho druheho PCka, toto trva dokud nerestartuju apache na VPSfree (ty fajly tam maji stovky mega kazdy, nechal sem to bezet asi 10-15minut a furt to tahalo, za tu dobu potahal tak 3GB+)
ALE...
Pokud nextcloud dam primo na ten druhy stroj kde je fyzicky ten disk, je vse OK, postup:
- vyinstalil sem nextcloud posledni verze, mariadb, stejne jako na vpsce
- do user slozky do slozky music bindnul ten samy folder rec-dread (akorat tentokrate ne pres sshfs protoze to je lokalni disk) a okriplil to linux pravama na read only
- import pres
sudo -u www-data ./occ files:scan --path="/user/files"
- vysledek - vse funguje jak ma, zadne besneni s datovym diskem se v pripade vylistovani rec-dread nekonna (v iotop sem ani nepostrehl ze by na nej sahl)
Netusi nekdo v cem by mohl byt problem / kam kouknout / co zkusit / co delam blbe? Aktualne nevim jestli ten problem dela nextcloud, vpsfree, sshfs nebo kombinace techto veci dohromady (openvpn sem vyloucil coby pricinu, ta s tim nema imho moc co delat, i kdyz data pres ni tecou, nicmene ten sshfs mount funguje spolehlive, nepada, takze openvpn sem neuvazoval).
Ten druhy PC je stary a ten nexcloud na nem sice jede, ale odezva neni tak rychla jako kdyz bezi na VPSce.
Diky - Buger
Ahoj,
vyzná se někdo v konfiguraci RSpamd prosím? Na několikátý pokus se ho
pokouším nasadit, protože mě vytáčí spam, který leze pouze na jednu
mou emailovou adresu, na ostatní neleze žádný spam.
Vše už mi zřejmě šlape, jak má. Akorát když pošlu GTUBE
https://spamassassin.apache.org/gtube/ , tak se mi mail vrátí, jako
nedoručený, ale já chci, aby se email hodil do spamu a ne, aby se mi
vrátil jako nedoručený.
Instaloval jsem podle návodu
https://thomas-leister.de/en/mailserver-debian-stretch/ .
Díky za pomoc.
Petr
Ahoj,
od vypadku viz subj. mi na VPSce odmita startovat SSH a SCREEN - oboje ma problem s chybejicim adresarem ve /var/run, jede to na ubuntu 16.04
- sshd chybi /var/run/sshd a proto nenajede po restartu, musim rucne vytvorit /var/run/sshd a nastartovat sshd, nicmene po dalsim restartu adresar opet chybi a je nutno ho vytvorit znova
---
root@bgrserver:~# systemctl status sshd
● ssh.service - OpenBSD Secure Shell server
Loaded: loaded (/lib/systemd/system/ssh.service; enabled; vendor preset: e
Active: failed (Result: start-limit-hit) since Mon 2019-01-14 16:06:32 UTC
Process: 376 ExecStartPre=/usr/sbin/sshd -t (code=exited, status=255)
xxx@bgrserver:~$ sudo cat /var/log/syslog | grep ssh
[sudo] password for xxx:
Jan 14 16:06:14 bgrserver systemd-tmpfiles[86]: Failed to validate path /var/run/sshd: Too many levels of symbolic links
Jan 14 16:06:31 bgrserver sshd[326]: Missing privilege separation directory: /var/run/sshd
Jan 14 16:06:31 bgrserver systemd[1]: ssh.service: Control process exited, code=exited status=255
Jan 14 16:06:31 bgrserver systemd[1]: ssh.service: Unit entered failed state.
Jan 14 16:06:31 bgrserver systemd[1]: ssh.service: Failed with result 'exit-code'.
Jan 14 16:06:31 bgrserver systemd[1]: ssh.service: Service hold-off time over, scheduling restart.
---
- screenu prozmenu chybi /var/run/screen a situace je stejna jako u sshd - po restartu je nutne rucne znova vytvorit a zmenit mod na 777, pak jede
---
xxx@bgrserver:~$ screen -S test
Cannot make directory '/var/run/screen': Permission denied
... screen nejede ...
xxx@bgrserver:~$ sudo mkdir /var/run/screen
[sudo] password for xxx:
xxx@bgrserver:~$ screen -S test
Directory '/var/run/screen' must have mode 777.
xxx@bgrserver:~$ sudo chmod 777 /var/run/screen
xxx@bgrserver:~$ screen -S test
... ted screen funguje, co po rebootu? ...
[detached from 7334.test]
xxx@bgrserver:~$
xxx@bgrserver:~$ sudo reboot
packet_write_wait: Connection to 37.205.11.73 port 22: Broken pipe
... ted je treba nahodit sshd pres VPSadmina, vytvorenim /var/run/sshd a restartem sshd, jinak connection refused ...
jdrozd@jdrozd-MS-7592:~$ ssh xxx(a)srv.dread.cz
ssh: connect to host srv.dread.cz port 22: Connection refused
jdrozd@jdrozd-MS-7592:~$ ssh xxx(a)srv.dread.cz
Welcome to Ubuntu 16.04.5 LTS (GNU/Linux 3.16.6-042stab134.43 x86_64)
* Documentation: https://help.ubuntu.com
* Management: https://landscape.canonical.com
* Support: https://ubuntu.com/advantage
Last login: Wed Jan 16 06:10:45 2019
xxx@bgrserver:~$ screen -S test
Cannot make directory '/var/run/screen': Permission denied
... po restartu je to o5 v ...
---
Pritom prava na /var/run potazmo /run kam se to symlinkuje jsou stejna jako na jine ubuntu 16.04 masine kde vse funguje.
---
xxx@bgrserver:~$ ll /var | grep run
lrwxrwxrwx 1 root root 9 lis 15 2016 lock -> /run/lock/
lrwxrwxrwx 1 root root 4 lis 15 2016 run -> /run/
xxx@bgrserver:~$ ll / | grep run
drwxr-xr-x 17 root root 560 led 16 06:11 run/
---
Nesetkal se nekdo z Vas s necim podobnym, nebo netusite kde by mohl byt problem?
Poslal sem to i na podporu VPSfree, protoze si nejsem jisty jestli se jedna o problem na jejich strane, nebo se mi rozbilo Ubuntu (i kdyz k tomu nemelo duvod)...
Diky - Buger
zdravim
na nasem vps je ubunutu 16.04
po reboot nenajede postgres
> FATAL: could not create lock file
"/var/run/postgresql/.s.PGSQL.5432.lock": Permission denied
> chmod 777 /var/run/postgresql
umozni alespon start postgres
systemctl start postgresql(a)10-main.service
se sice zasekne, takze pro navrat do console musim Ctrl+C, ale DB zda se
bezi, no service je v nejakem divnem stavu:
> postgresql.service loaded active
exited PostgreSQL RDBMS
> postgresql(a)10-main.service loaded activating start start
PostgreSQL Cluster 10-main
po restartu stroje jsou ale permission znovu spatne, takze to nenajede
neresil ste toto nahodu nekdo?
predem dik za pripadnou radu
s pozdravem
tyctor
zdravim ve spolek
na nasem vps jsem chtel installnout fail2ban
jenze se pred nim updatnul systemd
a na nem ted pada install cehokoliv
fchownat() of /var/log/journal failed: Invalid argument
dpkg: error processing package systemd (--configure):
installed systemd package post-installation script subprocess returned
error exit status 73
zkousel jsem dowgrade
> apt install systemd=229-4ubuntu4 libsystemd0=229-4ubuntu4
> apt-mark hold systemd
to jsem nasel tady
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1804847
ale to se zasekne uplne, na nejakej Connection timed out
dpkg: warning: downgrading libsystemd0:amd64 from 239-7ubuntu10 to
229-4ubuntu4
(Reading database ... 41892 files and directories currently installed.)
Preparing to unpack .../libsystemd0_229-4ubuntu4_amd64.deb ...
Unpacking libsystemd0:amd64 (229-4ubuntu4) over (239-7ubuntu10) ...
Setting up libsystemd0:amd64 (229-4ubuntu4) ...
dpkg: warning: downgrading systemd from 239-7ubuntu10 to 229-4ubuntu4
(Reading database ... 41892 files and directories currently installed.)
Preparing to unpack .../systemd_229-4ubuntu4_amd64.deb ...
Unpacking systemd (229-4ubuntu4) over (239-7ubuntu10) ...
Setting up systemd (229-4ubuntu4) ...
Installing new version of config file /etc/pam.d/systemd-user ...
Installing new version of config file /etc/systemd/journald.conf ...
Installing new version of config file /etc/systemd/logind.conf ...
Installing new version of config file /etc/systemd/resolved.conf ...
Installing new version of config file /etc/systemd/system.conf ...
Installing new version of config file /etc/systemd/timesyncd.conf ...
Installing new version of config file /etc/systemd/user.conf ...
addgroup: The group `systemd-journal' already exists as a system group.
Exiting.
Could not watch jobs: Connection timed out
nevite nahodou nekdo co s tim?
tyctor
Hello,
I ran into some bug with Systemd during an upgrade of my Debian 8 and the
vps became unusable.
I tried to restore from backup, setup the vps from scratch and then restore
the backup, but none of that worked.
What worked was to clone the vps to staging, however the IPs are different.
Since it would be quite hard to restore manually all the configs and users
to the fresh install of the production vps, is it possible to migrate the
IPs from production to staging?
Thank you!
--
-p
zdravim ve spolek
vsiml jsem si, ze na nasi vps smerujou requesty z jinych domen
nejcasteji je to z domeny leopardo.ackee.cz ale take z veggiegarden.cz,
vps.ackee.cz, zahrady-krupkova.cz
zapnul jsem u nas logovani jen nedavno, za 4 dny prislo dohromady 150
takovych requestu
muze to byt chyba v nastaveni uvedenych domen, nebo proc se to deje?
dik za info
z pozdravem
tyctor
Ahoj,
testování vpsAdminOS se dostává do další významné fáze: můžete klonovat
produkční VPS z OpenVZ na staging s vpsAdminOS [1].
VPS se klonují stejně jako na Playground [2], jen jako lokaci vyberte
Staging. Dejte pozor na checkbox "Stop" -- můžete si vybrat, jestli
chcete při klonování produkční VPS vypnout pro vytvoření konzistentního
snapshotu (data z paměti se zapíšou na disk). Pro pouhé otestování na
stagingu to ale nemusí být potřeba a klonování tak můžete provést bez
restartu produkční VPS. Klonuje se vše kromě mountů, ty jsou prozatím
odstraněny.
Pokud by někdo chtěl klonovat větší VPS, nebo už na stagingu něco máte,
napiště prosím na podporu a navýšíme vám tam RAM/HDD, abyste se tam vešli.
Nyní očekávám větší zájem o vyzkoušení zda běží vše co potřebujete.
Naším cílem je zajistit, aby následné migrace VPS probíhaly spolehlivě a
z pohledu administátora VPS nebylo potřeba nic moc řešit, takže prosím
hlaste vše na co narazíte, abychom se mohli připravit. Napište nám
prosím i když bude vše v pořádku. Potřebujeme vědět, jak na tom jsme, co
funguje a co ne :)
Po naklonování musí být funkční:
- IPv4/IPv6 síť
- vzdálená konzole
- ideálně všechny služby ve VPS
Pokud něco z toho nepůjde, nebo něco bude vyžadovat změnu konfigurace z
důvodu jiné virtualizace/kernelu, informujte nás prosím.
S migracemi všech produkčních VPS bychom chtěli začít v Q1/Q2 2019,
podle toho co bude potřeba dodělat. V listopadu 2019 končí podpora
OpenVZ Legacy kernelu ze strany OpenVZ teamu [3], takže do té doby
chceme stihnout přesunout co nejvíce VPS na vpsAdminOS.
[1] https://kb.vpsfree.cz/navody/vps/vpsadminos
[2] https://kb.vpsfree.cz/navody/vps/sprava#klonovani_vps
[3] https://wiki.openvz.org/Releases
Jakub
Ahoj,
při klonování produkční VPS z OpenVZ na staging s vpsAdminOS, se mě nezklonovaly Private IPv4 a ani je nelze ve staging s vpsAdminOS dodatečně nastavit. Tedy současnou konfiguraci produkční VPS z OpenVZ nemohu ve staging s vpsAdminOS testovat.
Bohužel neznám ani finální pánovanou konfiguraci produkční VPS s vpsAdminOS co se tíká parametrů a síťování či přidělení a počtu IP4, IP6 či Private IPv4 adres za NATem pro produkční VPS s vpsAdminOS, abych mohl tuto konfiguraci případně testovat.
Mohli by jste zveřejnit plánovanou konfiguraci pro produkční VPS s vpsAdminOS, aby bylo jasné, co do budoucna očekávat?
Renda
čt 1. 11. 2018 v 9:40 odesílatel Jakub Skokan <jakub.skokan(a)vpsfree.cz <jakub.skokan(a)vpsfree.cz>> napsal:Ahoj,
testování vpsAdminOS se dostává do další významné fáze: můžete klonovat
produkční VPS z OpenVZ na staging s vpsAdminOS [1].
VPS se klonují stejně jako na Playground [2], jen jako lokaci vyberte
Staging. Dejte pozor na checkbox "Stop" -- můžete si vybrat, jestli
chcete při klonování produkční VPS vypnout pro vytvoření konzistentního
snapshotu (data z paměti se zapíšou na disk). Pro pouhé otestování na
stagingu to ale nemusí být potřeba a klonování tak můžete provést bez
restartu produkční VPS. Klonuje se vše kromě mountů, ty jsou prozatím
odstraněny.
Pokud by někdo chtěl klonovat větší VPS, nebo už na stagingu něco máte,
napiště prosím na podporu a navýšíme vám tam RAM/HDD, abyste se tam vešli.
Nyní očekávám větší zájem o vyzkoušení zda běží vše co potřebujete.
Naším cílem je zajistit, aby následné migrace VPS probíhaly spolehlivě a
z pohledu administátora VPS nebylo potřeba nic moc řešit, takže prosím
hlaste vše na co narazíte, abychom se mohli připravit. Napište nám
prosím i když bude vše v pořádku. Potřebujeme vědět, jak na tom jsme, co
funguje a co ne :)
Po naklonování musí být funkční:
- IPv4/IPv6 síť
- vzdálená konzole
- ideálně všechny služby ve VPS
Pokud něco z toho nepůjde, nebo něco bude vyžadovat změnu konfigurace z
důvodu jiné virtualizace/kernelu, informujte nás prosím.
S migracemi všech produkčních VPS bychom chtěli začít v Q1/Q2 2019,
podle toho co bude potřeba dodělat. V listopadu 2019 končí podpora
OpenVZ Legacy kernelu ze strany OpenVZ teamu [3], takže do té doby
chceme stihnout přesunout co nejvíce VPS na vpsAdminOS.
[1] https://kb.vpsfree.cz/navody/vps/vpsadminos <https://kb.vpsfree.cz/navody/vps/vpsadminos>
[2] https://kb.vpsfree.cz/navody/vps/sprava#klonovani_vps <https://kb.vpsfree.cz/navody/vps/sprava#klonovani_vps>
[3] https://wiki.openvz.org/Releases <https://wiki.openvz.org/Releases>
Jakub
_______________________________________________
Community-list mailing list
Community-list(a)lists.vpsfree.cz <Community-list(a)lists.vpsfree.cz>
http://lists.vpsfree.cz/listinfo/community-list <http://lists.vpsfree.cz/listinfo/community-list>
Ahoj,
mám nainstalovaný Virtualmin
<https://geotrack.email/ext/l?idx=KqmNAgzO4FR1NOqWVtbd&ret=https%3A%2F%2Fwww…>
na
debian8, všechno vypadá v pořádku, ale nevidí to php. Php 5.6, 7.0, 7.1,
7.2 je nainstalované, ale když chci nainstalovat wordpress (klasickým
způsobem) tak kvůli nefunkčnosti php to jen vypíše, místo načtení
instalačního scriptu:
<?php
> /**
> * Front to the WordPress application. This file doesn't do anything, but
> loads
> * wp-blog-header.php which does and tells WordPress to load the theme.
> *
> * @package WordPress
> */ /**
> * Tells WordPress to load the WordPress theme and output it.
> *
> * @var bool
> */
> define('WP_USE_THEMES', true); /** Loads the WordPress Environment and
> Template */
> require( dirname( __FILE__ ) . '/wp-blog-header.php' );
Když chci ve virtualmin nainstalovat SquirrelMail tak to hlásí chybu:
> Failed to install script : Could not find PHP version for
> /home/"user"/public_html/squirrelmail
Při php -v to vypíše verzi:
> php -v
> PHP 5.6.38-0+deb8u1 (cli) (built: Sep 20 2018 02:32:02)
> Copyright (c) 1997-2016 The PHP Group
> Zend Engine v2.6.0, Copyright (c) 1998-2016 Zend Technologies
> with Zend OPcache v7.0.6-dev, Copyright (c) 1999-2016, by Zend
> Technologies
Jak to teda rozchodit?
Jindra
[image: GeoTrack]
<https://geotrack.email/?utm_source=gmail&utm_medium=signature&utm_campaign=…>
Sender
notified with GeoTrack
<https://geotrack.email/?utm_source=gmail&utm_medium=signature&utm_campaign=…>
[image: 48]
Ahoj,
podařilo se nám najít jiný, jednodušší způsob routování IP adres do VPS
bez spojovacích sítí. Ve VPS na stagingu tak už nejsou žádné spojovací
adresy, jen adresy veřejné. Jak síťování VPS aktuálně funguje je popsáno
zde:
https://vpsadminos.org/networking/veth-routed/#routing
U VPS na stagingu vpsAdmin rozlišuje adresy sítí, ty jsou do VPS
naroutované, a koncové adresy co jsou přiřazeny na rozhraní. Správa IP
adres je tak ve webovém rozhraní rozdělena na dva formuláře. Je to zatím
jen takový základ na kterém budeme později stavět.
Díky zrušení spojovacích adres funguje maškaráda v iptables a s tím i
výchozí síť v dockeru, která maškarádu využívá. Není potřeba si vytvářet
vlastní síť. Teď už instalace dockeru neobsahuje žádné kroky navíc.
Zbývá dořešit delegace ZFS datasetů do VPS, aby se v dockeru dal použít
ZFS driver.
Pokud jste chtěli vpsAdminOS vyzkoušet, ale nechtělo se vám instalovat
Nix a zjišťovat jak se to sestavuje, sorki připravil ISO s vpsAdminOS
[1], které si můžete stáhnout a rovnou nabootovat. Je to live systém a
obsahuje i instalátor [2], pokud to chcete nainstalovat na disk nebo si
vyzkoušet deklarativní konfiguraci s Nixem.
Od pátku jsou VPS na stagingu zálohované, abychom se nemuseli bát o
data. Obnova VPS ze záloh funguje, ale na staging si je zatím
nepřipojíte. Na produkční VPS ty zálohy připojit půjdou. Nemáme ještě
dořešené NFS, přijde to pak spolu s NASem.
Koncem srpna jsme narazili na nečekané omezení: věděli jste, že
maximální počet memory cgroup je 65536? Několika členům už se podařilo
je vyčerpat, takže jsme řešili jak ten limit navýšit. snajpa napsal
patch [3] do kernelu, který navyšuje maximální počet memory cgroup na
2147483648, nicméně zatím s tím nefunguje swap. Nám to nevadí, protože
swap nepoužíváme.
Dále bylo potřeba omezit počet cgroup, které mohou vytvořit jednotlivé
VPS, aby nikdo nemohl vyčerpat všechny a omezit tak ostatní. K tomuto
účelu snajpa vytvořil cglimit cgroup controller [4]. Můžete jej vidět i
a používat i ve VPS. Přes `cglimit.all.max` se nastavuje limit na počet
všech cgroup a přes `cglimit.memory.max` jen memory cgroupy.
Za pomoc s testováním děkujeme (nicky na IRC): ppar, somm, domogled,
pdostal, etnyx a všem dalším co píší na podporu. Pokud narazíte na
nějakou chybu, dejte nám o tom prosím vědět, rádi to opravíme.
[1] https://iso.vpsadminos.org
[2] https://vpsadminos.org/os/installation/
[3]
https://github.com/vpsfreecz/vpsadminos/commit/87cd90ab99b5f4d527d3b33adfda…
[4]
https://github.com/vpsfreecz/vpsadminos/commit/e73db73975e240b865497af4b40d…
Jakub
Z nějakého důvodu po upgrade Debianu na verzi 9 (stretch) mi nefunguje logování do souborů. Procházel jsem konfiguraci /etc/syslog-ng, ale nenašel žádný důvod proč by to nemělo jít.
Přes journalctl ty logy vidím. Nevím zda to nesouvisí s tím, že u každé služby hlásí systemd např.:
systemd-udev-trigger.service: Failed to set invocation ID on control group /system.slice/systemd-udev-trigger.service, ignoring: Operation not permitted
systemd-journal-flush.service: Failed to set invocation ID on control group /system.slice/systemd-journal-flush.service, ignoring: Operation not permitted
networking.service: Failed to set invocation ID on control group /system.slice/networking.service, ignoring: Operation not permitted
... atd.
Ahoj,
zkousim ISPConfig (3.1.11) na Debian 9. Vytvorim uzivatele, domenu a
FTP. Nahraju obsah do adresare web. V systemu je obsah skutecne treba na
/var/www/clients/client6/web10/web. Puvodni default obsah jsem smazal.
Nicmene kdyz se na tu domenu podivam kdekoliv a jakymkoli prohlizecem,
vidim stale ten default obsah. Predpokladam, ze to bude nejaka banalni
zacatecnicka chyba, ale vygooglit se mi nic rozumneho nepodarilo.
Zkousel jsem to na vic domenach a porad stejne.
Dik
Libor Boldan
Ahojte,
tak mame nainstalovane nove masiny, maji komplet zaplatovani proti vsem
znamym CPU chybam;
pokud mate senzitivni veci, piste na podporu, presuneme vam to. Prednost
dostanou ti, co maji na disku zabrano par desitek GB :)
Kdo jste mel v posledni dobe problem s vykonem IO, piste taky.
Nove servery maji zatim jenom 3x 2T SSD v raidz, bude se pridavat dal po
3 SSD (cca 60-70k CZK najednou, proto takhle);
jsou to bazarove Intely, 2x E5-2680 v4 @ 2.40GHz (28 cores, vypnute HT)
+ 512 GB RAM, Dell R730xd, jeden vysel cca na 300k CZK (SAS3, 2x10GE,
iDRAC enterprise and what not).
Ve vpsAdminu to jsou: node17.prg, node18.prg a node4.brq.
Mam z nich docela radost, svisti pekne.
Ale abych pravdu rekl, uplne nejvic se tesim na to, az se AMD vytahne s
trochu poaktualizovanym fabricem mezi temi jejich cipy a DDR4 az
zlevni... Zatim Intel vede vykonove pro nase use-cases i po vsech
mitigacich (pokud teda pocitame apriori vsechen symetric multithreading
za nebezpecny, i kdyz to AMD zatim nikdo verejne nedokazal).
/snajpa
Hoj,
resim tedka takovou zajimavou vec. Mam servery s LXD. Tech serveru jsou ted
desitky a v planu je rust az na tisice nebo nizke desetitisice. Konfiguracne
jsou vsechny plus minus stejny. A ja chci zaridit, abych:
- mohl snadno pridat nove servery/desitky serveru
- mohl kontejner presouvat odkudkoliv kamkoliv
Klasicka cesta pres lxc remote mi prijde dost silena, protoze bych pak mel
konfiguraci s tisici remoty a musel bych to volat na kazdem stroji a to
pochybuju, ze bude zdrave a udrzitelne (Vlastne pro N serveru budu muset
volat N-1 krat lxd remote add, to je hodne osklive). Zavest omezeni
"kontejner se nepresouva kamkoliv, ale pouze po nodech v ramci racku" neni
pruchozi. Napadlo me pouzit LXD clustering, ale nikdy jsem si s tim nehral.
Mate nekdo zkusenosti s LXD clusteringem nebo s movem kontejneru mezi vetsim
mnozstvim nodu? Jsou na to nejake tipy a triky, jak se z toho nezblaznit?
Diky
Ondra Flidr