.LNX-WORLD

Ich letzter Zeit bon ich selbst immer wieder in die gleiche Falle gegangen: Route für ein bestimmtes Netz auf einem Server hinzugefügt (für meinen Zugriff via VPN) und nach einem Reboot – alles wieder weg, ergo keinen direkten Zugriff mehr. Und alles nur weil ich zu faul war mir zu merken wie ich permanente statische Route in Ubuntu erstelle. Das soll sich nun ändern – ich schreibe wie so oft einfach einen Blog dazu – und schon ist es unauslöschlich in meinem Kopf. Hier also:

HowTo: Permanente Routen unter Ubuntu Linux

Für ein Netzwerk eine Route zu erstellen ist ja (fast) allgemein bekannt, aber damit wir in diesem Artikel alle über das gleiche Netz sprechen, hier mein Beispiel für die Route die ich permanent hinzufügen möchte und nach jedem Reboot auch immer gleich online haben will:

route add -net 192.168.101.0 netmask 255.255.255.0 gw 192.168.1.1 dev eth0

Zu Deutsch: Alle Anfragen an und von IPs aus dem netzbereich von 192.168.101.1 bis 192.168.101.255 sollen über das Gateway 192.168.1.1 abgewickelt werden. Das Gateway ist über das Netzwerkinterface eth0 zu erreichen.

Wenn man dies nun so in die Konsole haut, funktioniert die Route gleich und sofort (sofern keine Tippfehler drin sind). jedoch ist diese Route nach einem Reboot wieder weg – und genau das wollen wir ja nicht, wir wollen einen permanente statische Route für dieses Netzwerk!

Um diese statische Route nun permanent zu machen, müssen wir die Datei “/etc/network/interfaces” editieren – ganz unten sammel ich meine Routen um die Übersichtlichkeit zu bewahren.

Wir ergänzen einfach die obige Zeile leicht ergänzt und angepasst:

up route add -net 192.168.101.0/24 gw 192.168.1.1 dev eth0

Mehr ist wirklich nicht zu tun – eine Route also nicht gleich hier einzutragen ist wahrlich nur Faulheit.

Aber hier nochmal kurz der Syntax für die Route:

up route add [-net|-host] / gw  dev

Welche Netzmaske ihr habt, solltet ihr wissen – wenn nicht, habt ihr ganz andere Probleme :)

[aartikel]B001H30QNU:left[/aartikel]
SSH absichern – ich sagte es schon in Teil 1 dieser Reihe – dies ist etwas, dass jeder der Linux Server betreibt (egal ob in einem Firmennetzwerk, direkt über das Web erreichbar, oder beides) mit als erstes in den Angriff nehmen sollte.

In diesem Teil 2 der Reihe “SSH absichern” gehe ich auf einen Punkt ein, welcher oftmals schlicht unterschätzt wird: Den SSH Port ändern! Wenn man im Mittelalter nicht wollte, dass jemand einen Schatz fand, bzw. einen geheimen Ort, dann wurde dieser versteckt. Genauso funktioniert das gute alte Kinderspiel des Versteckens.

Was damals funktionierte, tut auch heute noch seine Wirkung! Denn beim den simplen Portscans auf offene SSH Zugänge wird meist nur nach dem default Port von SSH gesucht, dem Port 22. Was nun wenn der Server bei Anfragen auf den SSH Port 22 ganz simpel nicht antwortet? Meist fliegt man aus der Liste der Server die per Script und Brute Force angegriffen werden sollen, zumindest ist dies mein Ergebniss aus den Erfahrungen der Vergangenheit. Mehr…

[aartikel]3897215233:left[/aartikel]
SSH absichern – dies ist etwas was jeder der Linux Server betreibt (egal ob in einem Firmennetzwerk, direkt über das Web erreichbar, oder beides) mit als erstes in den Angriff nehmen sollte. Linux hat einen Nachteil was Angriffe angeht: Der Benutzer auf den es alle zuerst abgesehen haben ist root und der heißt nunmal immer so.

Um root den direkten Login per SSH zu verbieten, muss nur eine Zeile in der /etc/ssh/sshd_config geändert werden:

PermitRootLogin yes
ändern zu
PermitRootLogin no

Diese Änderung in der SSH Konfiguration sorgt dafür das der direkte Login über SSH als Benutzer root untersagt wird, sprich unser SSH ist ein wenig mehr abgesichert. Mehr…

Um einen zeitgesteuerten Aufruf / Start eines Scriptes oder Programmes unter Linux auszulösen (unter Linux heisst dies dann cronjob), bedint man sich der Crontab (so heißt im übrigen auch das Programm welches diese Crontabeinträge nachher abarbeitet). Jeder User hat so eine, mit die Wichtigste ist jene, welche sich unter /etc/crontab befindet. Hier schreibe ich fast alle Cronjob´s rein die auf meinem System laufen sollen, also genau solche Jobs wie SQL Datenbankdumps, Datensicherungen, Dienstneustarts, Benachrichtigungsscripts über Systemupdates, etc.

# m h dom mon dow user  command
17 *    * * *   root    /usr/local/cronjob1.sh
25 6    * * *   root    /usr/local/cronjob2.sh

Oben habe ich mal die ersten 3 Zeilen aus meiner Crontab eingestellt… Wie man erkennen kann, teil sich jeder Eintrag / Cronjob für eine Aufgabe in viele Spalten. In dem erstem 5 Spaltigen Bereich, welcher die Zeiten steuert, zu denen der Cronjob ausgeführt werden soll, stehen zuerst die Minute(n), dann die Stunde(n), der Tag, der Monat und der Wochentag. In der nächsten Spalte steht der Benutzer unter dem der Cronjob ausgeführt werden soll, gefolgt von dem Aufruf des zu startenden Programmes inklusive aller Optionen.

Die Crontab eines normalen Benutzers sieht etwas anders aus

# m h dom mon dow command
17 *    * * *   /usr/local/meinscript --optionen

Quasi das Gleiche, jedoch ohne die Spalte vom Benutzer / User, da normale Benutzer nur unter ihrem eigenem Namen Cronjob´s starten dürfen. Auch editiert der Benutzer seine Crontab nicht mit der /etc/crontab, sondern mit dem Kommando “crontab -e”. Ansehen kann man sich seine Cronjob´s mittels “crontab -l”. Dieser Weg ist dem meinem auch eindeutig zu bevorzugen!

Um diesen doch sehr gewöhnungsbedürftigen Sytax mal zu erklären, ein paar Beispiele dazu:

Um ein Script zum Beispiel jede Minute auszuführen müsste der Cronjob wie folgt aussehen:

* * * * *   /usr/local/meinscript --optionen

Wenn das Script alle 15 Minuten laufen soll, also zu jeder 15ten Minute und jeder Stunde, sähe der Cronjob so aus:

*/15 * * * *   /usr/local/meinscript --optionen

Cronjob für ein Script welches genau jeden morgen um 06:00 Uhr ausgeführt werden soll:

0 6 * * *   /usr/local/meinscript --optionen

Cronjob um ein Script jeden morgen zwischen 6 Uhr und 9 Uhr alle 15 Minuten zu starten:

*/15 6-9 * * *   /usr/local/meinscript --optionen

Cronjob f+r ein Script das genau am Heiligabend um 18 Uhr laufen soll:

0 18 24 12 *   /usr/local/meinscript --optionen

Cronjob für ein Scriptdas welches jeden Montag morgen laufen soll:

* * * * 1   /usr/local/meinscript --optionen

Beim letztem Beispiel wird der Wochentag als Zahl angegeben. Gültig hierfür sind die Zahlen 0-7, wobei die 0 und die 7 für den Sonntag stehen – Bitte nicht verzählen!

Ich habe so einige PDF Dokumente, welche regelmässig in Intranetseiten oder in das SAP integriert werden. Leider gab es selten eine schöne Thumbnailgrafik zu dem jeweiligem Dokument – was die Suche nach einigen Dokumenten erschwerte, bzw. optisch nicht so schön war.

Praktisch war nur, das alle PDF Dokumente an einem zentralem Ort abgelegt sind und werden. So kam dann auch die Idee zu dem nachfolgendem Script, welches den als $SOURCE definierten Ort nach PDF Dokumenten durchsucht, zu welchen dem Namen nach noch kein Thumbnail im $TARGET Ordner existiert. Wenn kein Thumbnail zu einem Dokument existiert, wird aus der ersten Seite des PDF via ImageMagick ein Thumbnail erzeugt und unter $TARGET abgelegt. Der Name des Thumbnails entspricht dabei dem Namen des PDF, nur die Dateiendung ist logischerweise .jpg statt .pdf.

Unter $DENSITY und $QUALITY kann die Qualität des jpg Thumbnails noch eingestellt werden, die Grösse ist über den Parameter “-geometry x200″ im Imagmagickkommando fest auf 200 pixel Breite eingestellt. Die Höhe wird automatisch ermittelt, damit nihts verzerrt wird, selbst wenn das Quelldokument  kein DIN A4 hat.

Script:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

#!/bin/bash
#set -x
###########################################################
###
### Variablen Definition
###
###########################################################
SOURCE=/pub/scan
TARGET=/pub/scan
DENSITY=50
QUALITY=65
 
###########################################################
###
### Script
###
###########################################################
 
cd $SOURCE
for i in `ls *.pdf`; do
        FILE=`/bin/echo $i | /bin/sed 's/pdf/jpg/'`
        ANAME=`/bin/echo $i | /bin/sed 's/.pdf//'`
        if [ -f $TARGET/$ANAME.jpg ]; then
                /bin/echo "JPEG to $i exists, skipping file"
        else
                /usr/bin/convert -geometry x200 -density $DENSITY $SOURCE/$i[0] -colorspace rgb -quality $QUALITY $TARGET/$FILE
        fi
done

Damit auch automatisiert der $SOURCE Ordner brav auf neue PDF gescannt wird, sollte das Script optimalerweise im Cron stehen. Nach meiner Erfahrung reichen 3-4 Läufe pro Tag auch locker aus…

Verbesserungsvorschläge oder gar Korrekturen nehme ich gerne als kleinen Kommantar entgegen. Ebenso gern gesehn ist die Weiterverlinkung dieser Seite ;)