Nextcloud /data mappa adatok importálása

Tegyük fel, hogy szerver költöztetés volt és álmodban sem gondoltad volna, hogy ahhoz, hogy a nextcloud fájljaid látszódjanak az új gépen nem elég csak a data mappát másolni.

Nos, van egy jó hírem: ez nem így van.

Az adatok visszamásolása után ezt kell csak lefuttatnod:

sudo -u www-data php /var/www/nextcloud/occ files:scan --all

Nyilván a /var/www/nextcloud helyére azt a path-t írod be ahol a te nextcloud appod telepítésre került.

Ekkor “újraszámolja” az adataidat és adatbázisba felvezeti őket. Ezt persze nem kellett volna futtatnod/nom ha az adatbázist is viszem magammal… 😑

webmin ssl beállítás leggyorsabban

Belefutottam abba a hibába, hogy a webmin webes felületén állítottam be az új ssl certet ami az sslforfree oldalon kértem és töltöttem le. Ezek a tanusítványok remekül működnek apache alatt, de soso mindig elfelejtem, hogy a ca_bundle, vagy certificate kell-e és hova másolni a webmin felületen – és most sikerült annyira reflexből félretalálni, hogy ssl hibával elszállt az oldal és sehogyan nem sikerült azt vissza betölteni.

Persze tutorialok is csak a webes felületről vannak, de sebaj, irány a konzol.

Ha hosszas kutatás után sikerült borzasztóan szétbarmolni az alkalmazás beállításait és még mentésed sem volt érdemes kezdeni azzal, hogy magát a szolgáltatást leállítod, törlöd a config fájlokat és “újratelepíted” a plugint.

$ /etc/init.d/webmin stop

$ rm -rf /etc/webmin/*

$ dpkg-reconfigure webmin

Ha ez megvan akkor vegyük keressük meg a sslforfree-ről származó 3 fájlunk mappáját, lépjünk bele, majd:

$ cat private.key certificate.crt > /etc/webmin/miniserv.pem

Mivel ez esetben sortörés nélkül kerül összefűzésre a két állomány nyissuk meg a miniserv.pem fájlt és üssünk entert a private és a cert közé az alábbi minta alapján:

...
-----END PRIVATE KEY-----
-----BEGIN CERTIFICATE-----
...

Enjoy!

Rejtélyes tárhelyproblémák – avagy a disk és a kernel viszonya

Az utóbbi néhány napban a szerverem lévő root partíción – ami egy 60G ssd – hirtelen a foglalt terület felkúszott átlag 55%-ról fokozatosan 100%-ig, 0b szabad, a rendszer megáll és nem értem mi történt.

Az első kör

du -sh * / --exclude <azon könyvtárak, melyekbe a diskek vannak felcsatolva>

Nem találtam semmi érdekeset. De szabad hely fokozatosan elfogyott és megszűnt.

Akkor újraindítjuk a rendszert hátha egyszerűen nincs szinkronban a disk foglalt területe a rendszer által “tudottakkal”. Tehát feltételeztem azt, hogy a rendszer valamit csinált (lehet frissítés vagy programhiba), televerte a disk-et, majd leállt, a hely felszabadult (tehát nem megszámlálható, nem látható), csak erről a kernel maga már/még nem tud.

Szóval újraindítottam. Hely ugyanúgy nincs, a szolgáltatások bő fele már el sem indult.

Töröltem a logokat, még mindig ugyanaz a helyzet. Letiltottam néhány service-t amire gyanakodtam, hogy problémázhatnak, majd újraindítottam ismét a gépet. Lett hely ismét, hurrá! Nem világos miért, de hurrá. Amúgy itt követtem el már a második bakimat.

Eltelt egy nap, majd figyelem a muninon, hogy az elmúlt napokban folyamatosan egy fűrészfog mintát sikerült rajzolni a >szépen lassan megtelik a tárhely, majd törlök valamit és újra lesz hely< alapon. És meglátom, hogy ismét ugyanabban a mértékben foly a hely.

Hogy kiderítsem mi okozza a balhét kicsit utánnakutattam és láttam példát, hogy du-t hogyan lehet hatékonyabban használni – konkrétan sorbarendezés, total számítás.

Ebből megszületett ez, amit a / helyen futtatok:

 du -sch * --exclude home --exclude disks | sort -h

És itt szembesültem vele, hogy az apache2 egy nap alatt kb 11G-nyi error.log-ot termel. Botok rátévedtek a szerveremre ahol folyamatosan olyan hívást csinálnak ami php hibát okoz ezért a hibajelentés oda bekerül.

Mit rontottam el?

Először is nem sorrendeztem így elsiklott a szemem felett a du által számolt terület kb/GB eloszlása és nem vettem elsőre észre, hogy az apache2 okozza a balhét.

Második. Ha töröltem a /var/log-ot korábban miért nem szabadult fel a hely? Az alkalmazás az access.log-ot és az error.log-ot nyitva tartja. Valami rejtélyes oknál fogva engedi az OS, hogy töröljem az appendelt fájl-t, de ennek ellenére továbbra is írja azt a kernel, tehát nincs felszabadult terület. Szerinte. Mert hogy még a fájl valószínűleg nyitva marad.

Egy egyszerű

systemctl restart apache2

után újra megjelent 55% foglalt terület és mindenki boldog.

Most már csak a php hibát kell kiküszöbölni, hogy ne legyen tele az apache error log ezekkel. 🙂