Wer die Temperatur des System immer im Auge behalten möchte und viel in der Shell arbeitet kann dies direkt mit der Prompt erledigen.
Öffnen der Datei
~/.bashrc dies kann man mit diesem Befehl erledigen
nano ~/.bashrc
Anlegen einer speziellen Prompt für den Benutzer, indem man den folgenden Text ganz unten in die Datei
~/.bashrc kopiert.
# Prompt
export PS1='\[\033[1;33m\]\u\[\033[1;30m\]@\[\033[1;31m\]\H \[\033[1;30m\]- \A - $(vcgencmd measure_temp) \[\033[0m\] #> '
Ich möchte hier einmal auf ein interresantes Projekt aufmerksam machen. Es nennt sich
pi-hole und braucht sich vor kommerziellen Lösungen nicht zu verstecken.
Es biegt DNS Abfragen auf bestimmte Werbe Domains um auf sich selbst und ersetzt somit die Werbung. Es gibt die Möglichkeit eigene Listen hinzuzufügen, eine Blacklist und eine Whitelist zu führen. Es ist dafür konzipiert auf einem
Raspberry Pi installiert zu werden, kann aber grundsätzlich auf jedem Debian basierenden System installiert werden.
Anmerkung :
Eins sollte man noch Anmerken, viele Webseiten finanzieren sich durch Werbung. Sollte also eure Lieblingsseite Werbung beinhalten setzt diese auf die Whitelist um den Betreiber zu unterstützen.
Weiter führende Links :
https://www.raspbian.org = Raspbian - Debian für Raspberry
https://pi-hole.net = AdBlocker - Pi-Hole
Problem : Man möchte mit einem Bash Script (Server A) z.B. Sicherungen von einem entfernten Server (Server B) automatisiert abholen. Da hier die Eingabe eines Passwortes hinderlich ist realisiert man das über einen SSH Key.
Lösung :
1.) erstellen eines SSH Keys auf Server A mit dem Befehl
ssh-keygen -t rsa
2.) erstellen des Ordners
.ssh im Homeverzeichnis auf Server B, sollte dieser bereits existieren auch gut
mkdir -p ~/.ssh
3.) importieren des erstellten Keys von Server A in der Datei .ssh/authorized_keys auf Server B
cat ~/.ssh/id_rsa.pub | ssh user@[Hostname von Server B] 'cat >> .ssh/authorized_keys'
oder
cat ~/.ssh/id_rsa.pub | ssh user@[IP-Adresse von Server B] 'cat >> .ssh/authorized_keys'
Anmerkung: Man kann auch Schritt 2 und 3 in einem zusammenfassen. Das gute daran man muss sich nicht erst auf Server B anmelden
cat ~/.ssh/id_rsa.pub | ssh root@[Hostname von Server B] 'mkdir -p ~/.ssh ; cat >> .ssh/authorized_keys'
4.) testen des Zugangs ohne Passwort z.B. mit diesem Befehl von Server A aus
ssh user@hostname
oder
ssh user@ip-adresse
Ein Debian Squeeze System auf die Bash-Lücke: ShellShock testen und diese schließen.
Bash Shellshock testen :
env x='() { :;}; echo "WARNUNG: SHELLSHOCK GEFUNDEN"' bash --norc -c ':' 2>/dev/null;Sieht der output so aus ist das System verwundbar
WARNUNG: SHELLSHOCK GEFUNDEN
Die Jungs von #shellshock haben einen besseren Test geschrieben, in der Sektion "Testing Your System" ist der Aufruf dafür zu finden.
Auf meinen Debian (6) Squeeze Server konnte ich die Lücke , soweit bekannt , schließen.
Ich habe meine
/etc/apt/sources.list auf den LTS Zweig konfiguriert
deb http://http.debian.net/debian/ squeeze main contrib non-free
deb-src http://http.debian.net/debian/ squeeze main contrib non-free
deb http://security.debian.org/ squeeze/updates main contrib non-free
deb-src http://security.debian.org/ squeeze/updates main contrib non-free
deb http://http.debian.net/debian squeeze-lts main contrib non-free
deb-src http://http.debian.net/debian squeeze-lts main contrib non-free
danach nur das Packet bash geupdatet
apt-get update && apt-get install --only-upgrade bash
Erneut Bash Shellshock testen :
env x='() { :;}; echo "WARNUNG: SHELLSHOCK GEFUNDEN"' bash --norc -c ':' 2>/dev/null;Wenn hier jetzt kein Output mehr zu sehen ist dann ist die bekannte Lücke geschlossen.
Weitere Quellen :
Bash-Luecke-Shellshock-Tests-auf-Verwundbarkeit-und-Abwehr
how-to-fix-shellshock-vulnerability-on-debian-squeeze
Mitigating the shellshock vulnerability (CVE-2014-6271 and CVE-2014-7169)
#shellshock
Wenn man an einem VHOST unter Apache2 eine Änderung vornimmt muss man entweder den Apache2 neustarten dies macht man mit
/etc/init.d/apache2 restart
oder man läd nur die Konfigurationsdateien neu. Dann hat man keine Downtime
1.) Überprüfen ob die Konfiguratinsdateien geparst werden können
apache2ctl configtest
2.) Konfigurationsdateien einlesen , gemachte Einstellung werden aktiv
apache2ctl graceful
Es gibt mehrere Wege um das Logging auf einem MySQL Server zu aktivieren. Der eine Weg ist über die
/etc/mysql/my.cnf allerdings muss hier MySQL neu gestartet werden.
Um die Konfiguration ohne Neustart zu ändern bietet sich dieser Weg an.
Anmelden am MySql Server :
BENUTZER und PASSWORT muss natürlich mit den eigenen Werten ersetzt werden.
mysql -uBENUTZER -pPASSWORT
Dann die globalen Variablen setzen
SET global log_output = 'FILE';
SET global general_log_file='/var/log/mysql/mysql_general.log';
SET global general_log = 1;
ausschalten kann man das ganze wieder mit
SET global general_log = 0;
Man sollte das global_log nicht allzu lange aktiv lassen da hier je nach Anwendung schnell 1 GB zusammen kommt.
