WordPress Container auf Docker

Dieser Blog-Eintrag beschreibt, wie man auf WordPress auf einem Docker-Host installieren und damit mehrere WordPress-Instanzen auf einem Host betreiben kann.
Ich betreibe die Docker-Container hinter einem Proxy-Server, der aber nicht als Container läuft. Der Proxy-Server leitet die HTTPS-Requests an die entsprechenden Docker-Container weiter.

Dieser Beitrag setzt ein vorinstalliertes Photon 3.0 inkl. Docker und Docker-Compose voraus. Siehe hier.

Die Docker-Container können über diverse Befehle gemanaged werden. Siehe dazu eine kleine Übersicht hier.

WordPress installieren

Wir installieren WordPress mit Hilfe von Docker Compose. Dazu erstellen wir ein template:

mkdir wordpress
cd wordpress
vi docker-compose.yml

Im yml-Script erstellen wir eine WordPress- inkl. DB-Instanz.

WordPress-Instanz

  • Die WordPress-Instanz hat eine Abhängigkeit zur DB.
  • Die WordPress-Files werden unter /var/www/html abgelegt
  • der Host-Port 80 wird zur wordpress-Instanz port 80 weitergeleitet (“80:80”)
  • Die DB ist über Port 3306 anzusprechen (WORDPRESS_DB_HOST: db:3306)
  • Der DB-User ist wordpress (WORDPRESS_DB_USER: wordpress)
  • Das DB-Passowort ist zu setzen: WORDPRESS_DB_PASSWORD: <wordpress_db_password>

DB-Instanz

  • Die DB-Files werden hier abgelegt: db_data:/var/lib/mysql
  • Passort setzen: MYSQL_ROOT_PASSWORD: <mysql root password>
  • Datenbank definieren: MYSQL_DATABASE: wordpress
  • User definieren: MYSQL_USER <wordpress>
  • DB-Passwort setzen: MYSQL_PASSWORD: (wordpress db password)
version: '3.3' services:

wordpress:
   depends_on:
     - db
   image: wordpress:latest
   volumes:
     - wordpress_files:/var/www/html
   ports:
     - "8080:80"
   restart: always
   environment:
     WORDPRESS_DB_HOST: db:3306
     WORDPRESS_DB_USER: wordpress
     WORDPRESS_DB_PASSWORD: (wordpress_db_password)

db:
   image: mysql:5.7
   command: '--default-authentication-plugin=mysql_native_password'
   volumes:
     - db_data:/var/lib/mysql
   restart: always
   environment:
     MYSQL_ROOT_PASSWORD: (mysql root password)
     MYSQL_DATABASE: wordpress
     MYSQL_USER: wordpress
     MYSQL_PASSWORD: (wordpress db password)
   volumes:
     wordpress_files:
     db_data:

 

Die letzten beiden Linien restellen lokale Verzeichnisse auf dem Photon-Host. Hier werden die WordPress- und SQL-Files abgespeichert. Diese Files überleben somit, wenn der container zerstört und neu generiert wird.

Die Volumes werden unter

cd /var/lib/docker/volumes

erstellt und bleiben bestehen. Dies solange bis die Volumes mittels

docker-compose down -v

zerstört werden.

WordPress Container starten

Nun kann der Container einfach gestartet werden. Dank Docker Compose braucht man nur noch einen Befehl. Docker Compose erkennt automatisch das YAML im aktuellen Verzeichnis, durchläuft die Konfiguration und startet die Container-Anwendung:

docker-compose up -d

Den Prozess kann man anzeigen lassen

docker ps

Nun ist über http://<ip>:8080 auf die WordPress-Instanz zugegriffen werden.

WordPress Container mit SSL erweitern

Das so bereitgestellte Container-Image bietet WordPress “out-of-the-Box” über Port 80 an. Port 443 ist nicht aktiviert. Man geht dabei davon aus, dass die Verschlüsselung (https) eine zusätzliche, neue Funktion darstellt und damit über einen weiteren Container abzubilden ist. Dazu kann ein Proxy-Container aufgebaut werden, für den es auch bereits fertige Docker-Images gibt. Architektonisch mag das Sinn machen.

Ich möchte das aber nicht so umsetzen. Ich betreibe bereits einen Proxy-Server und dieser soll auch so weiter beibehalten werden. Ich verzichte also auf einen Proxy-Container und erweitere das WordPress-Image durch die SSL-Funktionalität. Damit das geht, muss ich das docker-compose.yml bzw. die WordPress-Container Beschreibung erweitern.

Als erstes erstelle ich ein zusätzliches File

vi wordpress/wp-init.sh
!/usr/bin/env bash
apt-get update
apt-get install -y --no-install-recommends ssl-cert
rm -r /var/lib/apt/lists/*
a2enmod ssl
a2dissite 000-default.conf
a2ensite apache2-vhosts.conf
docker-entrypoint.sh apache2-foreground

Dieses Bash-Script soll bei jedem Starten des Containers ausgeführt werden. Mittels diesem Script wird
– SSL nachinstalliert
– Die Default Konfig “000-default.conf” auf dem Apachen entfernt und stattdessen
– eine neue Konfig “apache2-vhosts.conf” installiert.
– Anschliessend wird der Apache neu gestartet.

Damit das Script funktioniert braucht es noch eine Apache-Config. Diese Config wird in den WordPress-Container gemappt und beim Container-Start aktiviert. Damit kann ich von ausserhalb des Containers, die Apache-Config manipulieren:

vi wordpress/apache2-vhosts.conf
NameVirtualHost * 
<VirtualHost *:443> 
   ServerName domain.ch 
   DocumentRoot /var/www/html/ 
   DirectoryIndex index.php 
   Options -Indexes 
   SSLEngine On 
   SSLCertificateFile /etc/ssl/certs/ssl-cert-snakeoil.pem 
   SSLCertificateKeyFile /etc/ssl/private/ssl-cert-snakeoil.key 
   SSLCACertificateFile /etc/ssl/certs/ssl-cert-snakeoil.pem 
</VirtualHost>

Nun ist das das docker-compose.yml zu erweitern (siehe die markierten Erweiterungen):

version: '3.3'
   services:
   wordpress:
     depends_on:
       - db_node
     image: wordpress:latest
     volumes:
       - wordpress_files:/var/www/html
       - ./wp-init.sh:/usr/local/bin/apache2-custom.sh
       - ./apache2-vhosts.conf:/etc/apache2/sites-available/apache2-vhosts.conf
     ports:
       - "8080:80"
       - "8443:443"
     restart: always
     environment:
       WORDPRESS_DB_HOST: db_node:3306
       WORDPRESS_DB_USER: wordpress
       WORDPRESS_DB_PASSWORD: (wordpress db password)
     container_name: wordpress_web
     command: "bash -c apache2-custom.sh"

   db_node:
     image: mysql:5.7
     command: '--default-authentication-plugin=mysql_native_password'
     volumes:
       - db_data:/var/lib/mysql
     ports:
       - 6601:3306
     restart: always
     environment:
       MYSQL_ROOT_PASSWORD: (wordpress root password)
       MYSQL_DATABASE: wordpress
       MYSQL_USER: wordpress
       MYSQL_PASSWORD: (wordpress db password)
     container_name: wordpress_db
     volumes:
       wordpress_files:
       db_data:

Wie man sieht wird
– das wp-init.sh Skript in den Container gemappt
– Die Apache-Config apache2-vhosts.conf in den Container gemappt.
– Der Container um den Port 8443 erweitert, der Container-Intern auf 443 routet und
– Das Commando “bash -c apache2-custom.sh” bei starten ausgeführt.

Damit startet der Container ab sofort mit aktiviertem SSL und der Apache-Container kann über das File apache2-vhosts.conf konfiguriert werden.

Reverse Proxy

Auf dem Reverse-Proxy wird nun einfach eine Reverse-Rule für den Container eingeführt. Der Reverse-Proxy leitet die HTTPS-Anfragen intern an den Container-Host mit Port 8443 weiter. Diese kann so aussehen:

<VirtualHost serverIp:80> 
ServerAdmin info@domain.ch 
ServerName www.domain.ch 
ServerAlias domain.ch 
RewriteEngine on 
ReWriteCond %{SERVER_PORT} !^443$ RewriteRule ^/(.*) https://www.domain.ch/$1 [NC,R,L] 
</VirtualHost>

<VirtualHost serverIp:443> 
ServerAdmin info@domain.ch 
ServerName www.domain.ch 

#aktiviert SSL Unterstuetzung 
SSLEngine On 
SSLProxyEngine on 
SSLProxyVerify none 
SSLProxyCheckPeerCN off 
SSLProxyCheckPeerName off 
SSLProxyCheckPeerExpire off 

SSLCertificateKeyFile /etc/letsencrypt/live/www.domain.ch/privkey.pem 
SSLCertificateFile /etc/letsencrypt/live/www.domain.ch/cert.pem 
SSLCertificateChainFile /etc/letsencrypt/live/www.domain.ch/chain.pem 

# Regeln zum umleiten auf den internen Server 
ProxyPreserveHost On 
ProxyRequests Off 
ProxyPass / https://www.domain.ch:8443/ 
ProxyPassReverse / https://www.domain.ch:8443/ 

RequestHeader unset Accept-Encoding 

ErrorLog /var/log/apache2/error.log 

# Possible values include: debug, info, notice, warn, error, crit, 
# alert, emerg. 
LogLevel warn 

CustomLog /var/log/apache2/access.log combined 
ServerSignature On 
</VirtualHost>

SMTP auf WordPress-Container

Ich betreibe einen eigenen Mailserver. Ich stellte rasch fest, dass WordPress keine Mails über diesen Server versenden kann. Dies, weil das WordPress-Image einerseits grundsätzlich keinen SMTP-Agent mit dabei hat und andererseits mein Mailserver auch nicht aus dem Container heraus erreichbar war:

Um das Problem zu lösen habe ich mir einfach das Plugin “WP Mail SMTP” installiert. Dieses erweitert WordPress um die Mailfunktion. Das Connectivity-Problem konnte ich mit einer einfach Erweiterung von /etc/hosts lösen:

192.168.xx.xx    mx.domain.ch

Man beachte, dass ich die interne IP des Mailservers verwende.

Damit diese Erweiterung auch bei einem neuen Create des Containers übernommen wird, muss wordpress/wp-init.sh noch modifiziert werden:

#!/usr/bin/env bash

# modify /etc/hosts with mx.intelli.ch
cat >> /etc/hosts <<-EOF

/* mx.intelli.ch */
192.168.xx.xx    mx.domain.ch
EOF

apt-get update
apt-get install -y  --no-install-recommends ssl-cert   # SSL
rm -r /var/lib/apt/lists/*

a2enmod ssl
a2dissite 000-default.conf
a2ensite apache2-vhosts.conf

# finally execute default command
docker-entrypoint.sh apache2-foreground

Links

Nextcloud Sync mit Ftp-Server

Hier habe ich beschrieben, wie man auf Nextcloud einen FTP-Server als externen Speicher konfigurieren kann. Mit einem kleinen Hack ist es damit möglich Files von einem FTP-Server auf Nextcloud zu “pushen”. Wirklich funktioniert hat das bei mir nicht zufriedenstellend. – Das wird so von Nextcloud/Owncloud auch nicht offiziell supported. Zeit für einen zweiten Anlauf, der nun seit einem knappen Jahr für mich zufriedenstellend funktioniert:

Der Use-Case ist immer noch derselbe:

  • Mein Drucker kann auf einen FTP-Server scannen, nicht aber in ein Webdav Verzeichnis
  • Ich möchte die gescannten Dokumente aber direkt in Nextcloud haben und mich nicht noch zusätzlich mühsam auf den FTP-Server connecten um die Dokumente abzuholen.

Meine Lösung:

  • Ich betreibe einen eigenen FTP Server.
  • Statt in Nextcloud diesen FTP Server als externen Speicher hinzuzufügen, mounte ich auf dem FTP-Server selber das Nextcloud-Verzeichnis mittels davfs2 (also mit WebDav):
  • Dazu richte ich auf Nextcloud einen speziellen User (Scan) ein, der nur für das Scanning verwendet wird. Dieser Nextcloud-User hält das Verzeichnis in welches gescannt wird.
  • Dieses Verzeichnis wird dann mit allen  Nextcloud-Usern geteilt, welche über das “Scan-Feature” verfügen möchten (über Verzeichnis teilen).
  • Auf dem  FTP Server mounte ich das Nextcloud Scan-Verzeichnis des Users “Scan” mittels davfs und konfiguriere das Ziel-Scanverzeichnis des FTP Servers auf eben dieses Verzeichnis des Scan-Users. Damit verwende ich das offiziell von Nextcloud unterstützte WebDav Protokoll um vom FTP Server nach Nextcloud zu speichern.

Und los geht’s:

davfs2 installieren

Auf dem FTP-Server “webdav” installieren:

sudo apt-get install davfs2

Nextcloud Webdav als root mounten

Der mount kann folgendermassen durchgeführt werden:

sudo mount -t davfs https://nextcloud/remote.php/webdav/  /home/user/nextcloudScan/ -o uid=<userid>,gid=<groupid>,file_mode=775,dir_mode=775

Damit dies automatisch beim Systemstart passiert, trage ich dies in /etc/fstab ein. Bitte beachten, dass ich zusätzlich die Option “noauto” hinzufüge. Ein direktes mounten beim booten (auto) schlägt fehl, weil das Netzwerk zu diesem Zeitpunkt noch nicht aufgebaut ist. Das automatische mounten kommt später.

https://nextcloud/remote.php/webdav/  /home/user/nextcloudScan/ davfs noauto,uid=<userid>,gid=<groupid>,file_mode=775,dir_mode=775 0 0

Nun wird jeweils noch der Webdav-User inkl. Passwort abgefragt. Diese Infos kann man im file /etc/davfs2/secrets hinterlegen:

/home/user/nextcloudScan <nextcloudUser> <nextcloudPasswort>

Nun sollte ein mount automatisch funktionierten:

sudo mount /home/user/nextcloudScan

Der Trick liegt nun dabei, dass das der FTP-Server in das Verzeichnis nextcloudScan schreibt. Meinen FTP Drucker konfiguriere ich entsprechend. Damit schreibt der Drucker indirekt nach Nextcloud.

Automatisch beim booten mounten

Das file /etc/rc.local wird nach dem booten ausgeführt. Hier hinterlege ich nun noch meinen mount-Befehl:

vi /etc/rc.local

mount /home/user/nextcloudScan

…Voilà, jetzt werden alle Einträge in der fstab gemounted.

Alternative: Das lokale FTP-Verzeichnis mit rsync nach nextcloud synchen

Ansonsten könnte man auch das FTP-Verzeichnis auf dem FTP-Server mit rsync synchronisieren. Das ist aber mit obiger Lösung so nicht mehr nötig.

rsync -rutv --inplace scan/ nextcloudScan/

Referenzen

FTP-Scanning nach Nextcloud

Dieser Beitrag ist deprecated. Siehe hier für neue Lösung.

Ich habe zuhause einen schönen Drucker/Scanner stehen. Dieser Drucker/Scanner kann Dokumente einscannen und direkt an einen FTP-Server senden. Tolle Sache. Nun möchte ich aber, dass der Drucker direkt nach Owncloud scant. Owncloud selber hat keinen integrierten FTP-Server. Aber man kann in Owncloud einen FTP-Server als externen Speicher hinzufügen (siehe hier). Continue reading

ioBroker: Node.js Update / Reinstallation ioBroker

Ich betreibe seit einigen Jahren ioBroker, welches auf nodejs basiert. Heute war es an der Zeit die Nodejs Version von 8 auf 12 anzuheben, was leider nicht ganz ohne Probleme funktionierte. Hier fasse ich kurz zusammen, welche Schritte bei meiner Installation nötig waren. Die Schritte basieren auf diesem Howto.

Die einzige, im Howto beschriebenen und für mich funktionierende Lösung für das Update war, die komplette Reinstallation des ioBrokers. Dabei wird zuerst die neue Node.js Version installiert. Dann ein Backup des iobroker-data Verzeichnisses gezogen, die ioBroker-Installation gelöscht, neu installiert und dann das Backup wieder zurück gespielt:

Installation neue Node.js Version 12

cd /opt/iobroker
iobroker stop
cd
curl -sL https://deb.nodesource.com/setup_12.x | sudo -E bash -
sudo apt-get install -y nodejs

Bei einer Aktualisierung von Node.js müssen bereits installierte JavaScript- Module im ioBroker-Ordner aktualisiert werden, da sonst Fehler bei deren Ausführung auftreten. Hier traten bei mir dann die Probleme auf. Die einzige bei mir funktionierende Lösung war, den ioBkoker neu zu installieren:

Backup und Neuinstallation ioBroker

  • Backup des iobroker-data Verzeichnisses nach “Home” ziehen
  • Die alte Installation löschen
  • ioBroker neu installieren
cp -r /opt/iobroker/iobroker-data ~/iobroker-data 
sudo rm -r /opt/iobroker/ 
sudo mkdir /opt/iobroker
cd /opt/iobroker
curl -sL https://iobroker.net/install.sh | bash -

ioBroker wird nach der Installation wieder gestartet. Wir stoppen ioBroker deswegen wieder:

iobroker stop

Nun löschen wir das neu erstellte iobroker-data Verzeichnis und kopieren das Backup

rm -r /opt/iobroker/iobroker-data
cp -r ~/iobroker-data /opt/iobroker/iobroker-data

Während meinen Installations-Bemühungen habe ich festgestellt, dass die Berechtigungen immer wieder durcheinander gehen. Es existiert deswegen ein korrektur-Script, welches die Berechtigungen des ioBrokers wieder gerade zieht. Es ist ratsam dieses jetzt durchzuführen:

cd /opt/iobroker
curl -sL https://iobroker.net/fix.sh | bash -

Jetzt den ioBroker neu starten

iobroker start

Der Start kann jetzt sehr lange dauern. Der ioBroker merkt jetzt, dass die Adapter (gem. Backup) fehlen und installiert diese neu nach.

Um zu schauen, wo die Installation steht, kann man das log konsultieren

tail -f /opt/iobroker/log/iobroker.current.log

Ein Adapter (zigbee) liess sich jetzt immer noch nicht installieren. Diesen habe ich dann noch manuell installiert:

cd /opt/iobroker
iobroker stop
sudo -H npm install iobroker.zigbee --unsafe-perm

Ganz zum Schluss dann nochmals die Berechitigungen gerade ziehen, um sicher zu gehen…

cd /opt/iobroker
curl -sL https://iobroker.net/fix.sh | bash -

Das wars. Jetzt den Raspi neu booten und sich über die neue ioBroker-Installation freuen 🙂

sudo reboot

 

Sonos: Gut zu wissen

Dieser Beitrag ist “Deprecated”. Sonos ist dabei das schöne Upnp mit ihrer neuen API abzulösen (siehe https://developer.sonos.com/). Es wird wohl zwei API-Versionen geben. Eine für private Developer, für welche eine Cloud-API zur Verfügung gestellt wird und eine für Firmen, welche ein “lokales” API nutzen (und sich dafür zertifizieren) dürfen. Für Entwickler wie mich wäre also zukünftig das Ansteuern der Boxen nur noch über die Cloud möglich, was für mich nicht in Frage kommt. Ich hoffe Sonos bietet da dann doch noch etwas womit die Sonos Boxen über das LAN angesprochen werden können. Aktuell sieht es aber leider nicht so aus. Erste Funktionen, welche ich hier noch beschrieben habe, sind bereits durch Firmware-Updates herausgefallen (z.B. reboot). Wundert euch also nicht, wenn nicht mehr alle Upnp oder HTTP-Calls funktionieren.

Mittlerweile habe ich meine Sonos Boxen verkauft und bin auf eine OpenSource-Lösung, basierend auf Hifiberry und Max2Play umgestiegen. Damit ist es möglich, die gleiche Funktionalität von Sonos mit eigenen Boxen nachzubauen. Wie ich das gemacht habe, werde ich hier dokumentieren – sobald ich Zeit dafür habe.

Hints, Tips und Tricks rund um Sonos

Mein Sonos System umfasst insgesamt 7 Player (1 Sonos Soundbar und 6 Sonos Play:1). Sonos erstellt und unterhält sein eigenes Netz (Sonos-Net) selber. Grundsätzlich funktioniert das “out of the box”. Es kann aber doch manchmal nötig sein das Sonos-Net zu optimieren. Dazu anbei ein paar nützliche Infos:

Tools

Auf jeder Sonos-Box läuft ein Webserver, den man über den Browser ansprechen kann. Dabei können einige nützliche Infos eingesehen oder aber auch Einstellungen vorgenommen werden:

http://IP:1400/support/review Übersicht über die Sonos Box. Hier kann auch die Network-Matrix aufgerufen werden
http://IP:1400/advconfig.htm Einstellen der Root-Bridge (FirstZP und Priority auf „enabled“).
http://IP:1400/reboot Reboot der Sonos Box
http://IP:1400/region.htm WLAN Region sezten  (bei uns EU – Europa)
http://IP:1400/tools.htm Netzwerktools wie Ping, Traceroute, nslookup
http://IP:1400/status Status-Seite
http://IP:1400/wifictrl?wifi=off Stellt das WIFI bis zum nächsten Reboot ab
http://IP:1400/wifictrl?wifi=persist-off Stellt das WIFI Interface komplett ab. Wenn man nur über Kabel arbeiten möchte
http://IP:1400/status/scanresults Scanresults zeigt euch alle WLAN-Verbindungen an, welche von Sonos erreicht wurden. Kann je nachdem noch nützlich sein, für Android Smartphones gibt es da noch bessere Apps
http://<IP>:1400/status/tracks_summary Mit diesem Befehl kannst Du dir die Anzahl der Tracks anzeigen lassen
http://<IP>:1400/status/topology Zeigt die Sonos Topologie mit allen Sonos Playern und Media Servern

Nützliche Links:

Raspberry Images komprimieren/verkleinern

Hier beschreibe ich, wie man Images einer ganzen HD/SD ziehen kann. DD erstellt 1:1 Kopien und die daraus resultierenden Images sind entsprechend gleich gross wie die ursprüngliche HD/SD. Wenn man nun ein Image eines Raspberry Pis auf eine kleinere SD kopieren möchte, gibt es ein schönes Tool dazu: Pishrink

Hier wird schön beschrieben, wie man das Tool installieren und nutzen kann.

Linux Referenz Card

Hilfe

man cmdLesen des Manualeintrags zu cmd
man -k printfDurchsucht den Index der Manpages (Whatis-Datenbank) nach Stichworten (hier printf)
type cmdAnzeigen der Art, resp. des Typs von cmd
file fileAnzeigen der Art, resp. des Typs von file
whereis cmdSuchen des Speicherortes von cmd

Allgemeine Commands

dateAusgabe der Zeit und des Datums
echo [-n][Argumente]Ausgabe der Argumente (-n keine NewLine am Ende)

File/Directory Commands

pwdAnzeigen des aktuellen Datums
cd [directory]Wechseln des aktuellen Directories zu directory
ls [files(s)/director(ies)]Anzeigen von Files / Directories
cp source(s) targetKopieren von Files / Directories
rm file(s) / director(ies)Löschen von Files / Directories
mv file(s) / director(ies)Verschieben (auch Umbenennen) von Files / Directories
mkdir [-p] directory(ies)Erstellen eines leeren Directories (-p ganze Trees)
ln [-s] source targetErstellen eines Links (-s symbolischer Link)

File Commands

Wenn kein file(s) Parameter => Lesen von StdIn

cat [file(s)]Ausgeben / Zusammenhängen von Files
more, less file(s)Seitenweises Lesen von Files
cmp, diff file1 file2Vergleichen zweier Files
touch file(s)/directory(ies)Aktualisieren des Datums von Files/Directory(ies)

File Filter Commands

Wenn kein file(s) Parameter => Lesen von StdIn

grep [-cinrv] pattern [file(s)]Suchen nach Mustern (z.B. Grep -i “user” ~/.profile)
head [-n count] [file(s)]Ausgabe der ersten n Zeilen (Ohne Parameter n: n=10)
tail [-f] [-n count] [file(s)]Ausgabe der letzten n Zeilen (Ohne Parameter n: n=10)
cut -crange [file(s)]Ausschneiden von Textblöcken (z.B. cut -c10-20 index.html)
sort [file(s)]Sortieren (Mehrere Files werden gesamthaft sortiert
wc [-lwc] [file(s)]Zählen von Zeilen (-l), Wörtern (-w), Zeichen (-c)
tr char-old char-newErsetzen von Zeichen (z.B.: tr a A < index.html)
sed cmd [file(s)]Stream-Editor (z.B. sed s/test/TEST/g index.html)
awk cmd [file(s)]Tabellenstream-Editor (z.B.: awk ‘{print $2}’ /etc/fstab)

User & Zugriffsrechte

id, fingerAnzeigen der persönlichen Identifikation
passwdÄndern des Passwortes
who, rwhoAnzeigen der eingeloggten Benutzer
who: localhost, rwho: remotehosts
chmod mode target
mode: u=rwx,g=rwx,o=rwx
mode (oktal): r=4,w=2,x=1
Umdefinieren der Zugriffsrechte von Files/Directory(ies)
u: User (owner), g: Gropu, o: Others (world)
z.B. mode o=rwx, g=rx, o= – ergibt 750
umask [mode]Zeigen/Setzen der Defaultrechte beim erstellen von Files/Directories

Prozesse, Job-Control

ps [-alf]Anzeigen der aktuellen Prozesse
jobsAnzeigen der Prozesse im Hintergrund (BIC)
bg [%job-nummer]Starten eines gestoppten Prozesses im Hintergrund (BIC)
fg [%job-nummer]Starten eines Prozesses im Vordergrund (BIC)
kill [-signal] processs-idSenden eines Signals an einen Prozess
<ctrl> CAbbrechen/Beenden eines Prozesses im Vordergrund
<ctrl> ZStoppen eines Prozesses im Vordergrund und Verschieben in den Hintergrund;
=> muss mit bg/fg gestartet werden.

Shell Commands

.scriptScript wird in aktueller Shell abgearbeitet (kein Subprozess)
historyAusgabe der Commandhistory
exitTerminieren der Shell; Logout auf Terminal
alias name=defDefinition eines alias
alias [name]Ausgabe eines definierten Alias; Ohne Parameter [name] alle
unalias nameLöschen eines Alias
(set) var=defZuweisen eines Wertes an eine lokale Variable (z.B. myvar=’test’)
(set) var=$(cmd)Zuweisen der Ausgabe eines Commands an eine lokale Variable
unset varLöschen einer Variable
$varZugriff auf Variable var (z.B. echo $myvar)
export var=valueDefinition einer globalen Umgebungsvariablen (exportieren)
set, export, env, printenvAusgabe aller definierten Variablen
set -oAusgabe der Shell Optionen
set (-/+)o optionSetzen (-)/Löschen(+) einer Shell Option
<crtl> DEnd-Of-File (Abschluss Standard Input)

Shell-Sonderzeichen

~Home-Directory
*Beliebige Folge von Zeichen (Ohne Folgen mit führendem Punkt)
?Beliebiges Zeichen
[abc]Zeichen a, b oder c
[0-9]Zeichen 0 bis 9
[!abc]Nicht a, b oder C
cmd > fileUmlenken (Redirection) von Standard-Out in ein File
cmd >> fileAnhängen von Standard-Out an ein File
cmd < fileLesen von Standard-In von einem File
cmd 2> file Umlenken von Standard-Err in ein File
cmd >fle 2>&1Umlenken von Standard-Out, Standard-Err nach Standard-Out
cmd | tee fileZeigt Ausgaben am Bildschirm an und speichert gleichzeitig in einem file
\Quoting (Ausmaskieren) des folgenden Zeichens
‘…’Quoting aller eingeschlossenen Zeichen
“…”Quoting aller eingeschlossenen Zeichen ausser $,’,”,\
cmd &Ausführen eines Befehls als Hintergrundprozess
cmd_1; cmd_2; …;Sequentielle Abarbeitung mehrerer Befehle
( cmd_1; cmd_2; .. )Befehlsgruppe in Subshell ausführen
cmd_1 $(cmd_2)Ausgabe des zweiten Commands wird als Argument an den ersten Command übergeben
cmd_1 | cmd_2 | … | cmd_nPipeing (Fliessbandverarbeitung von mehreren Commands

Spezielle Shell Variablen

$?Exit Status des letzten Commands
$#Anzahl Argumente von cmd
$nn-tes Argument von cmd
$ENVVariable für persönliches Shell-Profile
$PATHAktueller Suchpfad für Utilities
$PS1Variable mit Inhalt des primären Prompts
$RANDOMGeneriert einen Random Integer
$SHELLName/Pfad der aktuellen Shell
$HOMEPfad zu Home-Directory

Spezielle Files/Directories

.(Punkt) aktuelles Directory
..(Punkt-Punkt) übergeordnetes Directory
/Root-Directory (Basis des File-Systems)
/etcDirectory für globale Konfigurationen (Schreibgeschützt)
/etc/profile, /etc/profile.dGlobale User-Environment Scripte
/tmpDirectory für temporäre Files (nicht schreibgeschützt)
/devDirectory für alle Devices (z.B. /dev/cdrom, /dev/hda, …)
/dev/nullNull-File (unendliche Senke für nicht erwünschten Output)
~/.profilePersönliches Profile-Script für alle Shells
{x,yz,ww}Brace Expansion
z.B. ls sand{x,yz,ww}wich => sandxwich, …

Linux Datei-Rechte

GruppeUserGroupOthers
Rechtr w xr – xr – –
Wertung4 2 14 0 14 0 0
Mode (Octal)754
Recht Mode (Octal)
0
–x 1
-w- 2
-wx 3
r– 4
r-x 5
rw- 6
rwx 7

Debian sudo: Benutzer für sudo berechtigen

Erscheint die Fehlermeldung

username is not in the sudoers file. This incident will be reported.

hat der aktuelle Benutzer kein Recht, sudo zu nutzen. Das heißt, er ist nicht in einer Benutzergruppe, welche ihm die Nutzung dieser Funktion gestattet.

In der Standardkonfiguration haben der Benutzer “root” und die Benutzergruppe “sudo” Zugriff auf die gleichnamige Funktion sudo. Es gibt auch hinreichend viele Tutorials, welche sich mit der Thematik befassen, einem Benutzer das Recht zu geben, sudo zu nutzen. Diese sind jedoch meiner Meinung nach umständlicher.

Umständliche Variante

Diese nutzen das Programm visudo, welches von sudo ebenfalls mitgeliefert wird. Damit öffnet sich die Konfigurationsdatei von sudo und man kann mit der richtigen Syntax Benutzer oder Benutzergruppen hinzufügen, um ihnen das Nutzen von sudo zu erlauben.

Für den Benutzer “test” sähe das z.B. folgendermaßen aus:

test ALL=(ALL) ALL

Für die Benutzergruppe “test” sähe das dagegen folgendermaßen aus:

%test ALL=(ALL) ALL

Einfache Variante

Da jedoch bereits die Gruppe “sudo” das Recht hat, sudo zu nutzen, kann man auch einfach diese nutzen. Hierzu muss man den Benutzer lediglich dieser Gruppe hinzufügen:

usermod -a -G sudo test

Nach dem nächsten Login per SSH können dann der jeweilige Benutzer bzw. Benutzer der jeweiligen Benutzergruppe sudo problemlos nutzen und erhalten nicht mehr die Fehlermeldung “username is not in the sudoers file. This incident will be reported.”.