autossh als Dienst einrichten

So nutze ich AutoSSH aum meinem Gnubee 2 NAS um von überall an die Daten auf meinem NAS zu gelangen!
Die verwendung von autossh wurde auf meinem NAS notwendig da sie sonst nicht mehr über das Internet erreichbar ist. Mein Internetprovider bietet nur noch DS-Light an. 🙁

autossh?

Autossh ist ein Programm das einen Open-SSH Tunnel bei Verbindungsabbrüchen automatisch wiederherstellt.

Verbindung zum Server etablieren

Meine NAS muss eine Passwortlose Verbindung zu meinem Server aufbauen können.
Hiezu generiere ich einen SSH-Key und übertrage den Public-Key auf den Server.:

ssh-keygen -t rsa -b 2048
mv ~/.ssh/id_rsa.pub ~/.ssh/autossh-key.pub
mv ~/.ssh/id_rsa ~/.ssh/autossh-key
ssh-copy-id -i autossh-key [email protected]

Verbindung testen

ssh [email protected]

Dienst anlegen

Um den Tunnel beim Systemstart automatisch wieder herstellen zu lassen lege ich die Datei /etc/systemd/system/sshtunnel.service mit dem folgenden Inhalt an:

[Unit]
Description=Keeps a tunnel to 'example.org' open
After=network-online.target ssh.service

[Service]
User=root
Environment="AUTOSSH_PORT=0"
Environment="AUTOSSH_GATETIME=0"
RestartSec=30
Restart=always

ExecStart=/usr/bin/autossh -NT -o "ExitOnForwardFailure=yes" -R 17777:127.0.0.1:22 -p 22 -l benutzername example.org -i /root/.ssh/autossh-key
ExecStop=killall -s KILL autossh
TimeoutStopSec=10

[Install]
WantedBy=multi-user.target

example.org ist durch den Hostnamen des Servers zu ersetzen, benutzername durch den verwendeten Benutzernamen.

Dienst aktivieren

Um den neu angelegten Dienst sshtunnel zu aktivieren muss dieser noch aktiviert und gestartet werden.

sudo systemctl enable sshtunnel.service
sudo systemctl start sshtunnel.service

EMail Datenschutz – Mail Header filtern

Vor einigen Tagen fiel mir bei der Untersuchung  des, auch an dieser Stelle behandelten, TLS-Fehlers auf, das die E-Mail Header aller über meinen Server vesandten EMails die folgenden beiden Header-Zeilen enthalten.:

Received: from [192.168.*.*] (ip********.dynamic.kabel-deutschland.de [95.91.*.*])
by server.angststalt.de (Postfix) with ESMTPSA id A64D13FCE1
for <*****@*****.de>; Mon, 26 Mar 2018 21:46:44 +0200 (CEST)
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101
Thunderbird/52.6.0

Ich bin mir, mit Blick auf den 25. Mai 2018 nicht sicher ob eine EMail diese zusätzlichen, nicht für die Erfüllung des Dienstes erforderlichen, Metadaten weiterhin beinhalten darf.
(Lieber Leser, liebe Leserin, wenn Du eine Online-Rechtsberatung erteilen darfst und dich mit der EU-Datenschutz-Grundverordnung auskennst, würde ich mich über einen Kommentar ↓ von Dir sehr freuen!)

Da ich es persönlich nicht mag wenn Daten versteckt vorliegen (in diesem Fall im EMail-Header) die nicht benötigt werden aber dritten unter bestimmten Umstenden helfen können mir zu schaden habe ich mich für die Entfernung der Header-Zeilen entschieden. Auch ein Blick in die RFC5321, und einige eigene Tests, zeigen das diese beiden Header-Zeilen nicht für die Zustellung verwendet werden und somit die Entfernung nicht schadet.

Vorgehen:

1.) Den EMail-Server Prüfen

Mit dem Postfix-Konfigurationsparameter header_checks kann ich die EMails am einen PCRE Filter weitergeben und verändern lassen.
Mit dem Postfix-Konfigurationsparameter smtpd_sasl_authenticated_header Erweitere ich den EMail-Header um einen Eintrag über den zur Authentifizierung am EMail-Server genutzten Benutzernamen.

postconf -n header_checks 2>/dev/null
postconf -n smtpd_sasl_authenticated_header 2>/dev/null

Ich bekomme für beide Konfigurationen eine leere Antwort, daher schaue ich nach den Defaultwerten.:

postconf -d header_checks 2>/dev/null
header_checks =
postconf -d smtpd_sasl_authenticated_header 2>/dev/null
smtpd_sasl_authenticated_header = no

2.) EMail-Server Konfiguration anpassen

Da ich vor habe den Filter über PCRE umzusetzen benötige ich das Debian Paket postfix-pcre, welches die Unterstützung dür die gewünschten Perl Regular Expressions für Postfix mitbringt.:

sudo apt install postfix-pcre
The following NEW packages will be installed:
postfix-pcre
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 320 kB of archives.
After this operation, 373 kB of additional disk space will be used.

Nach dem das Paket installiert ist lege ich auf dem Server eine Datei mit dem Namen „header_checks“, im Postfix Verzeichnis, an. In dieser Datei werden die Filterregeln hinterlegt.:
sudo vi /etc/postfix/header_checks

/^Received: .*\(Authenticated sender:.*/ IGNORE
/^Received: by server\.angststalt\.de .*from userid [0-9]+\)/ IGNORE
/^User-Agent:/ IGNORE

Im Anchluss verlange ich vom Postfix dem Benutzernamen, der zur Anmeldung am EMail-Server verwendet wurde in die Header einzufügen und die Mail Header über meinen Filter zu leiten.:

postconf -e smtpd_sasl_authenticated_header=yes
postconf -e header_checks=pcre:/etc/postfix/header_checks

Nach dem folgenden neustart von Postfix kann ich mir eine Testnachricht senden und die Header prüfen.

service postfix restart

Bei meinem Vergleich des neuen EMail-Headers mit dem EMail-Header einer älteren EMail, die ich mir vor der Einrichtung des Filters gesandt habe, fehlen die von mir zu begin beanstandeten Header Zeilen.

STRATO Linux VServer mit Webserver im Rettungssystem

Maintenance Seite

Ich kann den STRATO vServern in ein Rettungssystem starten, welches leider keinen Webserver enthält.
Das Rettungssystem ist Praktisch, da ich über dieses Alternative Betriebssystem an alle Daten die auf dem Server abgelegt sind gelangen kann, auch wenn mein selbst verwaltetes Betriessystem auf dem Server nicht mehr funktioniert. Die Besucher meiner Seite erfahren leider nicht das ich meinen Server grade warte.
Um den potentiellen besuchern meiner Seite jedoch zeigen zu können das meine Seite durchaus noch vorhanden, nur grade in einem Wartungsfenster ist, ist ein solcher sehr wünschenswert.

Der einfache versuch via „apt update && apt install lighttps“ führt jedoch leider zu ein paar nicht sehr aussagekräftigen Fehlermeldungen.

Es fehlen jedoch einfach nur ein paar Benutzer, genauer die Benutzer _apt, der Benutzer postfix und der Benutzer www-data.

adduser --quiet --gecos "" --no-create-home --disabled-password --disabled-login --ingroup nogroup --force-badname -uid 119 _apt
adduser --quiet --gecos "" --no-create-home --disabled-password --disabled-login --ingroup postfix -uid 111 postfix
adduser --quiet --gecos "" --no-create-home --disabled-password --disabled-login --ingroup www-data --uid 33 www-data

Im Anschluss kann der Webserver einfach installiert werden.:

apt update
apt -y install lighttpd php-cgi
lighttpd-enable-mod fastcgi

Im Anschluss bearbeite ich die Datei /etc/lighttpd/lighttpd.conf und füge am ende die folgenden 4 Zeilen an.:

url.rewrite = ( "" => "/maintenance.php" )
fastcgi.server = ( ".php" => ((
 "bin-path" => "/usr/bin/php-cgi",
 "socket" => "/tmp/php.sock"
)))

Die Raute # in der Zeile ‚#  „mod_rewrite“,‘ muss entfernt werden, so das die erste Zeile jedwede Anfragen an die Datei maintenance.php im Ordner /var/www/html/ umleiten kann.
Die verbleibenden drei Zeilen ermöglichen es dem Webserver PHP-Scripte auszuführen.

Die Datei /var/www/html/maintenance.php gibt in meinem Beispiel den HTTP StatusCode 503 (Vorübergehend nicht verfügbar; Server überlastet, ausgefallen oder in Wartung) und einen kurzen Wartungstext aus.:

<?php
if ( $_SERVER['SERVER_PROTOCOL'] === 'HTTP/1.1' )
 { $p = 'HTTP/1.1'; }else{ $p = 'HTTP/1.0'; }
header( $p.' 503 Service Unavailable', true, 503 );
header( 'Retry-After: 3600' );
?><!doctype html>
<title>Site Maintenance</title>
<style>
  body { text-align: center; padding: 150px; }
  h1 { font-size: 50px; }
  body { font: 20px Helvetica, sans-serif; color: #333; }
  article { display: block; text-align: left; width: 650px; margin: 0 auto; }
  a { color: #dc8100; text-decoration: none; }
  a:hover { color: #333; text-decoration: none; }
</style>

<article>
    <h1>We&rsquo;ll be back soon!</h1>
    <div>
        <p>Sorry for the inconvenience but we&rsquo;re performing some maintenance at the moment.</p>
        <p>we&rsquo;ll be back online shortly!</p>
        <p>&mdash; The Team</p>
    </div>
</article>

Zu guter letzt muss der Webserver nur noch neu gestartet werden, und es wird die Wartungsseite angfezeigt.

service lighttpd restart

git als static binary compilieren

GIT

Was ist eine „static binary“?

Während der Übersetzung eines Quellcodes in ein ausführbares Programm verknüpft der Compiler die ausführbare Datei des Programms, um später bei der Ausführung des Programms Arbeitsspeicher zu sparen, mit „shared dynamic libraries“.

Diese Bibliotheken sind eine Sammlung von Funktionen welche von mehreren Programmen geteilt verwendet werden um bestimmte Aufgaben zu zu erfüllen. Durch die gemeinsame Nutzung dieser Bibliotheken kann der Arbeitsspeicher des Computers geschont werden, da nur eine Kopie der Bibliothek für viele verschiedene Programme im Speicher geladen sein muss. Um ein unerwartetes Verhalten von Programmen zu vermeiden, ist es manchmal unumgänglich das Programm mit einer bestimmten Version einer Bibliothek zu Übersetzen. Auch um die Portabilität eines Programms zu verbessern ist es wichtig die Abhängigkeit vom vorhanden sein einer dynamischen Bibiothek zu vermeiden. In Linux Systemen sorgt ein Paketmanager dafür, dass Versionsabhängigkeiten korrekt erfüllt werden. Wenn Du auf einem Computer arbeitest über den Du keine Administrative Kontrolle besitzt kannst Du die Version der verwendeten Bibliothek nicht bestimmen oder eine aktualisiert verhindern.
Programme können, wenn sie mit „shared dynamic libraries“ übersetzt wurden nur auf andere Computer übertragen werden auf der, die gleiche Prozessorarchitektur und die gleichen Bibliotheken verfügbar sind.
Falls die Bibliotheken des Computers auf den das Programm übertragen wurde aktualisiert werden, eine Bibliothek entfernt wird oder eine der Bibliotheken auf dem Zielrechner werden kompromittiert oder durch bösartige Versionen ersetzt. Hier kommt das bauen einer „static binary“ ins Spiel.   Wie wird GIT als „static binary“ übersetzt?

in diesem Beispiel gehe ich davon aus das auf der NAS, entsprechend meiner Anleitung, bereits mit dem hier notwendigen Buildsystem ausgestattet wurde. Im Anschluss kann die entstehende GIT Binärdatei auf allen identischen ARM Prozessoren verwendet werden.
Die aktuellste GIT Version kann auf http://git-scm.com gefunden werden.

Die Folgenden 3 Schritte sind auszuführen:

1) Lade den GIT Quellcode herunter, entpacke die tar.gz-Datei und wechsle in das GIT Buildverzeichnis:

wget --no-check-certificate https://kernel.org/pub/software/scm/git/git-2.9.5.tar.gz
tar xzf git-2.9.5.tar.gz
cd git-2.9.5

2) Setze die Compilervariablen und konfiguriere ihn mittels ./configure. Hierbei kannst du ein  separates Verzeichnis zum übersetzen angeben.:

mkdir /usr/src/git-static
CHOST="armv6j-hardfloat-linux-gnueabi"
CFLAGS="-Os -march=arm1136jf-s -mfpu=vfp -mfloat-abi=hard -pipe -fomit-frame-pointer"
CXXFLAGS="${CFLAGS}"
./configure --prefix=/usr/src/git-static CFLAGS="${CFLAGS} -static"

3) übersetze GIT:

make

…und installiere GIT in das Zielverzeichnis

make install

4) Prüfe anschließend das deine neue GIT-Version wie erwartet funktioniert

cd /usr/src/git-static
./git --version

Inotify: Dateien überwachen

007-Tux Logo

Du kannst in Linux Systemen die Veränderungen an Dateien im Dateisystem mit inotify überwachen.

Um, sobald Dateien verändert wurden ein .tar.gz-Archiv zur Datensicherung zu erstellen oder die veränderte Datei auf einen anderen Server hochladen, oder auch an ein Filter / Beautifier zu übergeben oder auch einfach nur um auf meinem NAS eine LED anschalten ist inotify das Werkzeug auf das alle die es noch nicht kennen gewartet haben.

Ich bin schon vor einigen Jahren auf ein Problem gestoßen für das inotify die richtige Lösung gewesen wäre. Damals konnte ich nir nur eine Endlosschleife schreiben die immer wieder alle Dateien in meinen Verzeichnissen durchgegangen ist, keine schöne Lösung und endlose Festplattenzugriffe.
Diese Endlosschleife gefiel meinem damaligen Provider garnicht, da diese zu häufig auf die zu überwachenden Dateien Zugriff und die Festplatten am einschlafen hinderten und die Lebensdauer der Festplatten reduzierte.
Damals konnte ich die Schleife einfach mit einer längeren pause() zügeln, bin bald auf einen Cronjob gewechselt der noch seltener lief.

Auf meines eigenen NAS und meinen eigenen Servern bin ich jedoch nicht auf eine Schleife oder Cronjobs angewiesen! Mit einem Inotify Event kann ich die Änderungen direkt im Dateisystem abpassen und die gewünschte Anktion direkt nach der änderung starten.

apt install inotify-tools
Inotify-Events
KürzelFormat
ACCESSZugriff auf die Datei
ATTRIBMetadaten geändert
CLOSE_WRITEzum Schreiben geöffnete Datei geschlossen, sie muss nicht geändert worden sein
CLOSE_NOWRITEEine Datei wurde geschlossen nachdem sie schreibgeschützt geöffnet wurde
CREATENeue Datei angelegt
DELETEDatei gelöscht
DELETESELFÜberwachtes Verzeiuchnis gelöscht
MODIFYDatei modifiziert
MODIFYSELFÜberwachtes Verzeichnis modifiziert
MOVEDFROMDatei aus dem überwachten Verzeichnis verschoben
MOVEDTODatei in das überwachte Verzeichnis verschoben
OPENDatei geöffnet
inotifywait -mrq -e create --format %w%f /pfad/zum/verzeichnis/ | while read FILE
do
echo "neue Datei: $FILE"
done

Um zum Beispiel das WordPress Verzeichnises auf neue Dateien zu überwachen kann ich folgendes Snippet nutzen:

inotifywait -mrq -e create --format %w%f /home/customer/der_metzger/loteks_de/www/ | while read FILE;
 do
  echo "neue Datei: $FILE";
done

Dirch dieses Snippet werden alle im WordPressverzeichnis  neu erstellten Dateien ausgegeben.

In meinem Verzeichnis vor allem viele Dateien wp-content/temp-write-test-1492771373. (Die Zahl an ende ändert sich bei jedem Aufruf)
Jedoch werden auch alle Updates, Uploads, Plugin und Theme Installationen und auch all die neuen Dateien an die ich grade nicht denke.

Um herauszufinden welche Dateien „angefasst“ werden wird nur der Parameter „-e create“ auf „-e access“ geändert:

inotifywait -mrq -e access --format %w%f /pfad/zum/verzeichnis/ | while read FILE
do
echo "zugriff auf Datei: $FILE"
done

Inotify ist unter Linux ein sehr nützliches Werkzeug, auch für die Fehleranalyse. 😉

Reverse SSH Tunnel

Tunnel aus der anderen Richtung

Seit der Deaktivierung extern erreichbarer IPv4 Adressen, von den Providers Dual-Stack Lite oder DS-Lite genannt, bei meinem und auch vielen anderen Internetzugängen lassen sich die heimischen Computer und Router nicht mehr ohne weiteres mittels OpenSSH erreichen.

Die Alternativen, wie Beispielsweise einen VPN Tunnel und die teilweise recht obskuren Shell sharing-Dienste (Nach aufruf einer URL habe zugriff auf die Shell als der Benutzer der die Shell freigegeben hat, ohne Passwort, ohne Key), überzeugen mich einfach nicht. Besonders zur Administration meines heimischen Servers und der NAS verlange ich einfach mehr vertraulichkeit von meiner Verbindung.

In diesem Blogbeitrag zeige ich Schritt für Schritt wie ein reverser, mit anderen Worten umgekehrter, SSH Tunnel errichtet werden kann.

Revers SSH-Tunnel? Das ist wenn Bob eine Verbindung zur Shell des Computers von Alice herstellen möchte, der Computer von Alice ist jedoch wegen einem NAT oder einer Firewall nicht erreichbar ist. Alice muss dann zuerst eine Verbindung zu Bobs Computer herstellen und in dieser die Verbindung zu ihrem eigene Computer mitbringen.

Für mein Beispiel nehmen wir an, das der Computer von Alice die IP-Adresse 10.0.0.2 und der Computer von Bob die IP-Adresse 192.168.0.2 hat, und zwar eine Verbindung von Alice zu Bob, jedoch umgekehrt keine Verbindung möglich ist.

1.) SSH Verbindung von Alice zu Bob herstellen. (Vom Zielcomputer zu dem Computer auf dem eine Verbindung auf die Shell eigentlich hergestellt werden soll)

ssh -R 49152:localhost:22 [email protected]

Der Port 49152 den ich hier verwende ist ein beliebiger, auf Bobs Computer nicht verwedeter Port.

2.) Nun kann Bob eine SSH-Verbindung zum Computer von Alice über den jetzt aufgebauten SSH-Tunnel herstellen.

ssh localhost -p 49152

Wenn die von Alice hergestellte Verbindung zu Bob jedoch abbricht verliert auch Bob seine Verbindung zu Alice.
Bob sollte aus diesem Grund due Konfiguration seines SSH-Servers so anpassen, das die Verbindung nicht wegen eines Timeout getrennt wird.

Die Daten /etc/ssh/sshd_config kann zu diesem Zweck wie folgt angepasst werden.:
TCPKeepAlive no
ClientAliveInterval 30
ClientAliveCountMax 100

Linux: sudo ohne Passwort

sudo

Auf dem eigenen Laptop, Raspberry Pi oder Computer ist es verlockend mittels sudo -s als root zu arbeiten um nicht bei jedem aufruf eines Befehls der erhöhte Rechte benötigt das eigene Passwort eingeben zu müssen. Aus diesem Grund zeige ich in dieser einfachen Anleitung aufzuzeigen wie diese Verlockung abzuschwächt werden kann in dem das Passwort nicht immer oder wenigstens nicht bei jedem aufruf eines Befehls eingegeben werden muss.

Die Einstellungen zum Befehl sudo werden in der Datei /etc/sudoers hinterlegt. In dieser Datei kann festgelegt werden welche Benutzer sudo nutzen können, ob bei jedem Aufruf das eigene Passwort eingegeben werden muss und wie in dem Fall verfahren werden soll wenn wenn ein Benutzer ohne das recht zur nutzung versucht erhöhte Rechte zu erlangen.

Die Syntax der Konfiguration der Benutzerrechte erfolgt nach dem folgenden Schema:

user_list host_list=effective_user_list tag_list command_list

Die einzelnen Tele dieser Konfigurationszeile haben die folgenden Bedeutungen:

user_list – Liste der Benutzer oder einen Benutzer-Alisa der bereits zuvor angelegt wurde
host_list – eine Liste der Hostcomputer oder eine Host-Alias auf dem ein Benutzer sudo ausführen kann
effective_user_list – list of users they must be running as or a run as alias.
tag_list – Liste von Eigenschaften wie beispielsweise NOPASSWD.
command_list – Liste von Befehlen die mit sudo ausgeführt werden dürfen

Um einem Benutzer, in meinem Beispiel kuehnel, die Ausführung aller Befehle via sudo ohne die Eingabe eines Passworts zu erlauben öffne ich die „sudoers“ Konfigurationsdatei.:

$ sudo vi /etc/sudoers

Und füge die folgende Zeile ein.:

kuehnel ALL=(ALL) NOPASSWD: ALL

Alternativ kann mit der folgenden Zeile einer Gruppe, in meinem Beispiel der Gruppe sudo, mit dem Prozentzeichen (%) der Zugriff auch ohne die eingabe des Passworts ermöglicht werden.

%sudo ALL=(ALL) NOPASSWD: ALL

Um meinem Benutzer kuehnel ausschließlich die Nutzung eines einzelnen Befehls zu ermöglichen kann die Zeile durch den entsprechenden Befehl ergänzt werden, wie im folgenden Beispiel mit dem Befehl kill.

kuehnel ALL=(ALL) NOPASSWD: /bin/kill

Die folgende Zeile ermöglicht allen Benutzern der Gruppe sys die nutzung des Befehls sudo zu der Ausführung der Befehle kill und rm ohne dafür das Passwort des Benutzers eingeben zu müssen.

%sys ALL=(ALL) NOPASSWD: /bin/kill, /bin/rm

Ich hoffe diese Beispiele reichen aus um eine Vorstellung von den Konfigurations-Optionen zu erhalten. Wenn Du Fragen zu einem Bestimmten Beispiel hast oder Fragen wie Du eine bestimmte Konfiguration erreichen kannst freue ich mich über Deinen Kommentar.

logfile

sudo gibt die Log-Informationen an syslog. Es kann nach wunsch aber auch ein eigenes Logfile schreiben.

Defaults        logfile="/var/log/sudo.log"

Die in der Logdatei gespeicherten Daten können den eigenen anforderungen angepasst werden, zum Beispiel so.:

Defaults        log_host, log_year, logfile="/var/log/sudo.log"

lecture

Hinweis bei der Nutzung von sudo anzeigen.

Es gibt 3 mögliche Konfigurationen:

always – bei jedem Aufruf dem Benutzer den Hinweisen zeigen
once – nur bei der ersten Nutzung den Hinweis anzeigen
never – dem Hinweis niemals anzeigen

Defaults        lecture="always"

Zusätzlich kann festgelegt werden in welcher Datei der Text für den Hinweis hinterlegt ist:

Defaults        lecture_file="/path/to/file"

timeout

Zeitspanne in Minuten nach der das Passwort erneut abgefragt werden soll.

Defaults        env_reset,timestamp_timeout=20

Server Benchmark Test from Loteks

Ab dem erleben dieser wird es interessant das Ergebnis eines Benchmarks zu haben um belastbare Zahlen zum vergleich zu haben.

Ein Benchmark? Es gibt für Linux unglaublich viele Benchmark Werkzeuge. Ich möchte kein Benchmark Werkzeugs. Ich möchte nichts großes und ich will nicht herausfinden welches Werkzeug den Parameter misst der mich interessiert.

Ich möchte ein einfachen kleinen Hack der Messen kann was mich interessiert!

Zu diesem Zweck dient dieser Artikel

Dieser Artikel ist ein wenig im Fluss und wird je nach vorliegenden Kommentaren angepasst.

Messen der CPU Geschwindigkeit: (Pi bis zur Stelle 5000 berechnen)

time echo "scale=5000; a(1)*4" | bc -l

Messen der Festplatten Schreibrate:

dd if=/dev/zero of=/test.file bs=1024 count=10240

Messen der Festplatten Leserate:

dd if=/test.file of=/dev/null

Messen der Netzwerkgeschwindigkeit:

wget -O speedtest-cli https://raw.githubusercontent.com/sivel/speedtest-cli/master/speedtest.py
chmod +x speedtest-cli
./speedtest-cli

Für alle die Virtuelle Server gemietet haben:
Ja, es ist schade das euer VServer wirklich langsam ist. Lebt damit! Ihr teilt euch die CPU, Netzwerkverbindung und die Festplattenzugriffszeiten mit anderen. Seid sozial und übertreibt es nicht mit den Festplattenzugriffen, die anderen wollen auch mal. Lebt mit den 10MByte lese und Schreibrate!
Wenn es darauf ankommt nutzt doch bitte dedizierte Server!

Postfix, maximale größe der EMails festlegen

In Postfix kann die maximale Größe von zu verarbeitenden EMails übder die Konfigurationsvariable „message_size_limit“ festgelegt werden.

Postfix wird alle EMails ablehnen die größer als der festgelegte Wert von „message_size_limit“ ist. Der Vorgabewert von message_size_limit ist 10240000 (nahezu 10 Megabyte).

In der Postfix Konfigurationsdatei wird dieses Limit, zumindest unter debian nicht aufgeführt. Es kann direkt in der Datei /etc/postfix/main.cf, oder mit postconf hinzugefügt werden.

Die aktuelle Einstellung von Postfix kann mit dem folgenden Befehl angezeigt werden:

postconf message_size_limit

Mit der Eingabe von „postconf“, ohne zusätzliche Parameter, wird die gesammte Postfix konfiguration ausgegeben werden. Durch den Zusatz des „message_size_limit“ wird nur diese eine Option ausgegeben. Die ausgabe des obig angegebenen Befehl zeigt die folgende Zeile:

message_size_limit = 10240000

Um den zugewiesenen Wert zu Ändern kann mit der folgenden Eingabe ein abweichender Wert zugewiesen werden. Um herauszufinden kann mit dem folgenden Shellscript eine beliebige anzahl MB in Bytes, die Angabe in der Postconf erfolgt in Bytes, umgerechnet werden.

awk '{$1=$1*1024*1024;printf "%.0f\n",$1}'

Nach der Eingabe auf der Shell zum Beispiel 20 eingeben und Enter drücken, als Ausgabe erfolgt 20971520. (Das Script  im Anschluss mit Strg und C abbrechen) Diesen Wert weisen wir jetzt mit postconf dem message_size_limit zu:

postconf message_size_limit=20971520

Hiermit wird in die letzte Zeile der Datei /etc/postfix/main.cf die Zeichenfolge „message_size_limit=20971520“ angefügt und alle eventuell zuvor in der Dastei vorkommenden Zuweisungen „message_size_limit=“ entfernt.

Im Anschluss muss noch der Dienst Postfix die neue Konfiguration lesen. Dies erfolgt durch die eingabe von:

service postfix reload

Im Anschluss gilt die neue Option und entsprechend größere EMails können angenommen werden.

shellshock II (RPM-Paket erstellen)

In der chroot-Umgebung aus der ersten Anleitung kann auch direkt ein rpm Paket erstellen, welches eine saubere Installation der aktualisierten Bash ermöglicht.

Die Anleitung beginnt an Punkt 2 (2. Bash Quellen bereitstellen) der ersten Anleitung!

In der chroot-Umgebung des Build Systems einen Benutzer für den Paketbau anlegen:

chroot /mnt/chroot
adduser builder  && su builder && cd ~

Im Anschluß werden die für rpmbuild notwendigen Verzeichnisse, die drei Bash Konfigurations-Dateien .bashrc, .bash_profile, .bash_logout und die Specs-Datei für den rpm-Paketbau angelegt und die Bash Quellcodes sowie Patches heruntergeaden.:

mkdir -p ~/rpmbuild/{BUILD,RPMS,SOURCES,SPECS,SRPMS}
cd ~/rpmbuild/SOURCES/
wget ftp://ftp.gnu.org/gnu/bash/bash-4.3.tar.gz
wget ftp://ftp.gnu.org/gnu/bash/bash-4.3-patches/ -m -nd
cat <<'EOF' > dot-bash_logout
# ~/.bash_logout: executed by bash(1) when login shell exits.

# when leaving the console clear the screen to increase privacy

if [ "$SHLVL" = 1 ]; then
[ -x /usr/bin/clear_console ] && /usr/bin/clear_console -q
fi
EOF
cat <<'EOF' > dot-bash_profile
# .bash_profile

# Get the aliases and functions
if [ -f ~/.bashrc ]; then
. ~/.bashrc
fi

# User specific environment and startup programs

PATH=$PATH:$HOME/bin

export PATH
EOF
cat <<'EOF' > dot-bashrc
# If not running interactively, don't do anything
[ -z "$PS1" ] && return

# don't put duplicate lines or lines starting with space in the history.
# See bash(1) for more options
HISTCONTROL=ignoreboth

# append to the history file, don't overwrite it
shopt -s histappend

# for setting history length see HISTSIZE and HISTFILESIZE in bash(1)
HISTSIZE=10000
HISTFILESIZE=20000

# check the window size after each command and, if necessary,
# update the values of LINES and COLUMNS.
shopt -s checkwinsize

# make less more friendly for non-text input files, see lesspipe(1)
[ -x /usr/bin/lesspipe ] && eval "$(SHELL=/bin/sh lesspipe)"

# set variable identifying the chroot you work in (used in the prompt below)
if [ -z "$debian_chroot" ] && [ -r /etc/debian_chroot ]; then
debian_chroot=$(cat /etc/debian_chroot)
fi

# set a fancy prompt (non-color, unless we know we "want" color)
case "$TERM" in
xterm-color) color_prompt=yes;;
esac

# uncomment for a colored prompt, if the terminal has the capability; turned
# off by default to not distract the user: the focus in a terminal window
# should be on the output of commands, not on the prompt
#force_color_prompt=yes

if [ -n "$force_color_prompt" ]; then
if [ -x /usr/bin/tput ] && tput setaf 1 >&/dev/null; then
# We have color support; assume it's compliant with Ecma-48
# (ISO/IEC-6429). (Lack of such support is extremely rare, and such
# a case would tend to support setf rather than setaf.)
color_prompt=yes
else
color_prompt=
fi
fi

if [ "$color_prompt" = yes ]; then
PS1='${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\[email protected]\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\$ '
else
PS1='${debian_chroot:+($debian_chroot)}\[email protected]\h:\w\$ '
fi
unset color_prompt force_color_prompt

# If this is an xterm set the title to [email protected]:dir
case "$TERM" in
xterm*|rxvt*)
PS1="\[\e]0;${debian_chroot:+($debian_chroot)}\[email protected]\h: \w\a\]$PS1"
;;
*)
;;
esac

# enable color support of ls and also add handy aliases
if [ -x /usr/bin/dircolors ]; then
test -r ~/.dircolors && eval "$(dircolors -b ~/.dircolors)" || eval "$(dircolors -b)"
alias ls='ls --color=auto'
#alias dir='dir --color=auto'
#alias vdir='vdir --color=auto'

alias grep='grep --color=auto'
alias fgrep='fgrep --color=auto'
alias egrep='egrep --color=auto'
fi

# some more ls aliases
alias ll='ls -alF'
alias la='ls -A'
alias l='ls -CF'

# Add an "alert" alias for long running commands. Use like so:
# sleep 10; alert
alias alert='notify-send --urgency=low -i "$([ $? = 0 ] && echo terminal || echo error)" "$(history|tail -n1|sed -e '\''s/^\s*[0-9]\+\s*//;s/[;&|]\s*alert$//'\'')"'

# Alias definitions.
# You may want to put all your additions into a separate file like
# ~/.bash_aliases, instead of adding them here directly.
# See /usr/share/doc/bash-doc/examples in the bash-doc package.

if [ -f ~/.bash_aliases ]; then
. ~/.bash_aliases
fi

# enable programmable completion features (you don't need to enable
# this, if it's already enabled in /etc/bash.bashrc and /etc/profile
# sources /etc/bash.bashrc).
if [ -f /etc/bash_completion ] && ! shopt -oq posix; then
. /etc/bash_completion
fi

export LANG=de_DE.utf8
export LC_CTYPE=de_DE.UTF-8

test "$SSH_AUTH_SOCK" || exec ssh-agent $SHELL -c "ssh-add; exec $SHELL -login"
EOF
cd ~/rpmbuild/SPECS
cat < <'EOF' > bash.spec
# BASH spec File TEST
#%define beta_tag rc1
%define patchlevel .30
%define baseversion 4.3

# Build auch mit unpackaged files abschliessen
%define _unpackaged_files_terminate_build 0
%define _missing_doc_files_terminate_build 0

Version: %{baseversion}%{patchlevel}
Name: bash
Summary: The GNU Bourne Again shell
Release: 1%{?dist}
Group: System Environment/Shells
License: GPLv3+
Url: http://www.gnu.org/software/bash
Source0: ftp://ftp.gnu.org/gnu/bash/bash-%{baseversion}.tar.gz

Source1: dot-bashrc
Source2: dot-bash_profile
Source3: dot-bash_logout

# Official upstream patches
Patch001: ftp://ftp.gnu.org/pub/gnu/bash/bash-4.3-patches/bash43-001
Patch002: ftp://ftp.gnu.org/pub/gnu/bash/bash-4.3-patches/bash43-002
Patch003: ftp://ftp.gnu.org/pub/gnu/bash/bash-4.3-patches/bash43-003
Patch004: ftp://ftp.gnu.org/pub/gnu/bash/bash-4.3-patches/bash43-004
Patch005: ftp://ftp.gnu.org/pub/gnu/bash/bash-4.3-patches/bash43-005
Patch006: ftp://ftp.gnu.org/pub/gnu/bash/bash-4.3-patches/bash43-006
Patch007: ftp://ftp.gnu.org/pub/gnu/bash/bash-4.3-patches/bash43-007
Patch008: ftp://ftp.gnu.org/pub/gnu/bash/bash-4.3-patches/bash43-008
Patch009: ftp://ftp.gnu.org/pub/gnu/bash/bash-4.3-patches/bash43-009
Patch010: ftp://ftp.gnu.org/pub/gnu/bash/bash-4.3-patches/bash43-010
Patch011: ftp://ftp.gnu.org/pub/gnu/bash/bash-4.3-patches/bash43-011
Patch012: ftp://ftp.gnu.org/pub/gnu/bash/bash-4.3-patches/bash43-012
Patch013: ftp://ftp.gnu.org/pub/gnu/bash/bash-4.3-patches/bash43-013
Patch014: ftp://ftp.gnu.org/pub/gnu/bash/bash-4.3-patches/bash43-014
Patch015: ftp://ftp.gnu.org/pub/gnu/bash/bash-4.3-patches/bash43-015
Patch016: ftp://ftp.gnu.org/pub/gnu/bash/bash-4.3-patches/bash43-016
Patch017: ftp://ftp.gnu.org/pub/gnu/bash/bash-4.3-patches/bash43-017
Patch018: ftp://ftp.gnu.org/pub/gnu/bash/bash-4.3-patches/bash43-018
Patch019: ftp://ftp.gnu.org/pub/gnu/bash/bash-4.3-patches/bash43-019
Patch020: ftp://ftp.gnu.org/pub/gnu/bash/bash-4.3-patches/bash43-020
Patch021: ftp://ftp.gnu.org/pub/gnu/bash/bash-4.3-patches/bash43-021
Patch022: ftp://ftp.gnu.org/pub/gnu/bash/bash-4.3-patches/bash43-022
Patch023: ftp://ftp.gnu.org/pub/gnu/bash/bash-4.3-patches/bash43-023
Patch024: ftp://ftp.gnu.org/pub/gnu/bash/bash-4.3-patches/bash43-024
Patch025: ftp://ftp.gnu.org/pub/gnu/bash/bash-4.3-patches/bash43-025
Patch026: ftp://ftp.gnu.org/pub/gnu/bash/bash-4.3-patches/bash43-026
Patch027: ftp://ftp.gnu.org/pub/gnu/bash/bash-4.3-patches/bash43-027
Patch028: ftp://ftp.gnu.org/pub/gnu/bash/bash-4.3-patches/bash43-028
Patch029: ftp://ftp.gnu.org/pub/gnu/bash/bash-4.3-patches/bash43-029
Patch030: ftp://ftp.gnu.org/pub/gnu/bash/bash-4.3-patches/bash43-030

Requires(post): ncurses-libs
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)

BuildRequires: ncurses-devel
BuildRequires: autoconf, gettext

%description
The GNU Bourne Again shell (Bash) is a shell or command language
interpreter that is compatible with the Bourne shell (sh). Bash
incorporates useful features from the Korn shell (ksh) and the C shell
(csh). Most sh scripts can be run by bash without modification.

%define pkgdocdir %{_datadir}/doc/%{name}-%{version}

%prep
#%setup -q -a 2
%setup -q -n %{name}-%{baseversion}

# Official upstream patches
%patch001 -p0 -b .001
%patch002 -p0 -b .002
%patch003 -p0 -b .003
%patch004 -p0 -b .004
%patch005 -p0 -b .005
%patch006 -p0 -b .006
%patch007 -p0 -b .007
%patch008 -p0 -b .008
%patch009 -p0 -b .009
%patch010 -p0 -b .010
%patch011 -p0 -b .011
%patch012 -p0 -b .012
%patch013 -p0 -b .013
%patch014 -p0 -b .014
%patch015 -p0 -b .015
%patch016 -p0 -b .016
%patch017 -p0 -b .017
%patch018 -p0 -b .018
%patch019 -p0 -b .019
%patch020 -p0 -b .020
%patch021 -p0 -b .021
%patch022 -p0 -b .022
%patch023 -p0 -b .023
%patch024 -p0 -b .024
%patch025 -p0 -b .025
%patch026 -p0 -b .026
%patch027 -p0 -b .027
%patch028 -p0 -b .028
%patch029 -p0 -b .029
%patch030 -p0 -b .030

echo %{version} > _distribution
echo %{release} > _patchlevel

%build
autoconf
%configure --with-bash-malloc=no --with-afs --with-installed-readline
make "CPPFLAGS=-D_GNU_SOURCE -DRECYCLES_PIDS `getconf LFS_CFLAGS`"
%check
make check
strip bash
strip bashversion

%install
rm -rf $RPM_BUILD_ROOT

if [ -e autoconf ]; then
  export PATH=.:$PATH
fi

# Fix bug #83776
perl -pi -e 's,bashref\.info,bash.info,' doc/bashref.info

make DESTDIR=$RPM_BUILD_ROOT install

mkdir -p $RPM_BUILD_ROOT/etc

# Not for printf, true and false (conflict with coreutils)
rm -f $RPM_BUILD_ROOT/%{_mandir}/man1/printf.1
rm -f $RPM_BUILD_ROOT/%{_mandir}/man1/true.1
rm -f $RPM_BUILD_ROOT/%{_mandir}/man1/false.1

pushd $RPM_BUILD_ROOT
mkdir ./bin
mv ./usr/bin/bash ./bin
ln -sf bash ./bin/sh
rm -f .%{_infodir}/dir
popd
mkdir -p $RPM_BUILD_ROOT/etc/skel
install -c -m644 %SOURCE1 $RPM_BUILD_ROOT/etc/skel/.bashrc
install -c -m644 %SOURCE2 $RPM_BUILD_ROOT/etc/skel/.bash_profile
install -c -m644 %SOURCE3 $RPM_BUILD_ROOT/etc/skel/.bash_logout
LONG_BIT=$(getconf LONG_BIT)
mv $RPM_BUILD_ROOT%{_bindir}/bashbug \
   $RPM_BUILD_ROOT%{_bindir}/bashbug-"${LONG_BIT}"

%find_lang %{name}

# lua-code von Jesse Keating  so das keine Externen Abhängigkeiten benötigt werden.
# lua-Code von Ignacio Vazquez-Abrams
%post -p 
bashfound = false;
shfound = false;

f = io.open("/etc/shells", "r");
if f == nil
then
  f = io.open("/etc/shells", "w");
else
  repeat
    t = f:read();
    if t == "/bin/bash"
    then
      bashfound = true;
    end
    if t == "/bin/sh"
    then
      shfound = true;
    end
  until t == nil;
end
f:close()

f = io.open("/etc/shells", "a");
if not bashfound
then
  f:write("/bin/bash\n")
end
if not shfound
then
  f:write("/bin/sh\n")
end
f:close()

%postun
if [ "$1" = 0 ]; then
    /bin/grep -v '^/bin/bash$' < /etc/shells | \       /bin/grep -v '^/bin/sh$' > /etc/shells.new
    /bin/mv /etc/shells.new /etc/shells
fi

%files -f %{name}.lang
%defattr(-,root,root)
%config(noreplace) /etc/skel/.b*
/bin/sh
/bin/bash
%attr(0755,root,root) %{_bindir}/bashbug-*
EOF

Die bash.spec-Datei enthält die Konfigutarion des Paketes sowie die bei der Installation und deinstallation notwendigen Scripte. Die Vorliegende SPECS Datei ist eine bearbeitung der Original Quelle von Fedora Core 12, welche ich für die aktuelle BASH angepasst habe.

Jetzt kann mit rpmbuild das Paket erstellt werden, welches direkt im Anschluss mit rpm Installiert werden kann. Das alte Bash Paket wird hierbei durch das neue Paket ersetzt.

rpmbuild -ba  bash.spec
rpm -U --force --replacefiles /mnt/chroot/home/builder/rpmbuild/RPMS/armv6l/bash-4.3.30-1.fc12.armv6l.rpm

Das aus diesem Tutorial entstehende Bash-Binary und RPM-Datei zur Installation