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