Shell: RAM und Swap freigeben ohne Reboot

Der Hauptspeicher ist fast voll und ein Reboot soll nicht erfolgen? Dann gibt es andere Optionen. Zum einen können Dienste/Services restarted werden, die dafür bekannt sind Speicher zu fressen (zB Apache2). Wenn das nichts mehr bringt und eigentlich ein Reboot ansteht, dann kann die nachfolgende Befehlssequenz helfen:

sync ; sync ; sync ; echo 3 > /proc/sys/vm/drop_caches

Sie schreibt die Daten im Speicher auf die Platte (Pagecache, Inodes etc.). Als ich die Kommandos das erste Mal aufgerufen habe, waren 12GB von 16GB belegt. Nach Ausführung wurden nur noch ~300MB belegt.

Ein weiteres Problem kann ein zu grosser (belegter) Swap sein. Aber auch hier gibt es eine hilfreiche Sequenz, um das Rebooten zu vermeiden:

sync ; sync ; sync ; swapoff -a && swapon -a

Dadurch wird der Swap in den Arbeitspseicher geholt, der ausreichend kapazität zur Aufnahme des Swaps haben sollte (sonst kann im Ernstfall der rechner abstürzen).

Postgres: Auflisten aller Datenbanken mit deren Größe 

SELECT datname, pg_size_pretty(pg_database_size(datname))
FROM pg_database
ORDER BY pg_database_size(datname) DESC;

Listet alle Datenbanken nach Größe sortiert auf (aus psql).

psql -c "SELECT datname, pg_size_pretty(pg_database_size(datname)) FROM pg_database ORDER BY pg_database_size(datname) DESC;" -U postgres -W "password" -h localhost -x

Dieser Befehl kann auf der Shell abgesetzt werden.
– c = Query
– U = Username
– W = Password
– h = Host
-x = Ausgabe als „expanded“

Shell: Debian/Raspian booten zur Console

Wer Raspberry OS (ehemals Raspian) installiert hat, landet nach dem Boot-Vorgang auf dem Desktop. In diesem Fall kann eine Console geöffnet werden und mit „sudo raspi-config“ das Konfigurationsprogramm aufgerufen werden (1 System Options > S5 Boot / Auto Login). Dort lässt sich einstellen, dass nach dem Booten die Console und nicht der Desktop angezeigt wird.

In Debian gibt es kein „sudo raspi-config“, wohl aber eine Möglichkeit das Booten zur Console als Standart einzustellen:

sudo systemctl set-default multi-user.target

Von der Console kann mit „startx“ X-Windows gestartet werden. Den aktuellen Zustand erhält man mit:

systemctl get-default

Um zurück zum grafischen Modus (Desktop) zu gelangen wird folgendes eingegeben:

sudo systemctl set-default graphical.target

Git: Deploy Repo auf Webserver ohne .git-Files

Wer sein Projekt in einem Git-Repository verwaltet, kann Git nutzen, um die Dateien via Git auf den Webserver zu übertragen. Wird ein einfaches „git clone“ genutzt, dann befinden sich die Meta-Dateien von Git auf dem Webserver (.git-Verzeichnis) und geben Hackern & Co. Angriffsvektoren.

Wer jetzt nicht Tools wie Jenkins etc einsetzen will, kann mit Git aber trotzdem ein sicheres Deployen ermöglichen. Dazu wird auf dem Webserver ein „bare“ Repo (nacktes Repo) angelegt und über einen post-receive-Hook festgelegt, wo die Dateien ausgecheckt werden sollen.

Lokaler Rechner = Workstation zum Entwickeln, Remote Server = Webserver, wo die Dateien ausgecheckt werden sollen (im DOCUMENT_ROOT).

Annahme: Das „bare“-Repo soll in einem Homeverzeichnis untergebracht werden (/home/user/production.git). Die Pfadendung .git soll hier anzeigen, dass sich in diesem Ordner das Repo befindet. Es könnte auch in einem Ordner ausserhalb des DOCUMENT_ROOT liegen (zB /var/repo). Der Webserver DOCUMENT_ROOT soll /var/www/production sein. Der Name des Webserver-Users ist „user“, die Gruppe „users“.

Remote (myserver.de):

$ mkdir production.git
$ cd production.git
$ git init --bare
$ cd hooks
$ nano post-receive

#!/bin/sh
git –work-tree=/var/www/production –git-dir=/home/user/production.git checkout -f master

Dateiinhalt: /home/user/production.git/hooks/post-receive
$ chmod +x post-receive
# Der Hook muss ausführbar sein.
$ mkdir  /var/www/production
$ chown -R user:users /var/www/production
# Das Verzeichnis muss von dem User beschrieben werden können.

Lokal (Workstation, mit existierendem Repo „production“):

$ cd /home/localuser/production
$ git remote add web ssh://myserver.de/home/user/production.git

„web“ ist in diesem Fall der frei gewählte Name des remote Repos. Mit „git push web master“ wird nun eine Änderung in den Master-Branch des „web“-Repos gepusht. D.h in myserver.de/home/user/production.git befinden sich die Dateien für Git (vergleichbar dem lokalen Ordner /home/localuser/production/.git/) – aber nicht die Verzeichnisstruktur für den Webserver. Diese Dateien werden nach dem Push über den Git-Hook „post-receive“ in den Work-Tree kopiert (/var/www/production)

Shell: Rekursiv nach verschiedenen Dateitypen suchen 

find ./ -type f \( -name \*.gz -o -name \*.tgz -o -name \*.tar -o -name \*.zip \)

Hier werden verschiedene Archiv-Typen in einem find-Durchgang gesucht.
Damit mehrere Extensions gefunden werden können, werden sie mit „-o“ (ODER) verknüpft und in einer runden Klammer (escaped und mit Leerzeichen nach/vor der Klammer) zusammengefasst. Statt dem Parameter „-name“ kann auch „-iname“ verwendet werden, der dann Groß- und Kleinschreibung abdeckt (zB -iname \.jpg)