findgrep: Rekursive Textsuche (shell script)

Ende Juli veröffentlichte ich das Skript „findgrep“, das mit Hilfe von „find“ und „grep“ Verzeichnisse rekursiv nach Textmustern durchsucht.

Lizenz:Creative Commons Attribution ShareAlike 3.0; (click pic for details)

Der dazu erschienene Artikel (samt Skript für die bash) hat sich inzwischen zu einem der meistaufgerufenen Artikel  dieses Blogs gemausert. Auch bei den Suchanfragen, über die dieses Blog gefunden wird, stehen Ausdrücke wie „find und grep rekursiv“ oft ganz oben auf der Hitliste. Bevor ich das Skript zusammengeschustert hatte, war ich auch eine gute Weile mit Recherche beschäftigt, ohne auf die Schnelle eine passende Lösung zu finden.

Deshalb habe ich das Skript in den letzten Wochen auf meinem Klapprechner  überarbeitet. Das Resultat, „findgrep Version 0.2″ kann weiter unten heruntergeladen werden.

findgrep v 0.2: Verzeichnisse rekursiv nach Text durchsuchen

Verbesserungen:

• Die gefilterten Ergebnisse werden ja in einer Textdatei (Variable $SAVEFILE) gespeichert. War diese Datei jedoch unterhalb des Suchverzeichnisses angesiedelt, suchte sich findgrep einen Wolf, da es die bereits gefundenen Ergebnisse erneut als Treffer anzeigte. Dieser Bug wurde behoben.
• Bisher musste der Nutzer nach jedem Start des Programms den Suchpfad angeben. Zusätzlich hat der Nutzer nun die Möglichkeit, durch „ENTER“ das Standardverzeichnis zu bestätigen (Standard: /var/log)  Zum Ändern einfach die Variable $SEARCHDIR im Skript anpassen.
• Sowohl bei der Auswahl als auch bei der Präsentation der Ergebnisse wurde das Programm grafisch anschaulicher aufpoliert
• findgrep zeigt nun die Anzahl der gefundenen Matches an

findgrep: Suche nach "warning" in /var/log beendet ...

Download findgrep v 0.2: Bitte hier klicken und mit copy und paste holen. Rechtsklick und „Speichern unter …“ funktioniert nicht.

Das Skript ist für Ubuntu getestet. Manche Versionen von grep kennen die Option „color“ nicht und brechen das Skript mit Fehlermeldung ab. Äh, ach ja: Der nette junge Herr oben bin nicht ich. Ich fand das Bild nur passend zum Thema und habe es auf Wikimedia gefunden.

Alle findgrep Artikel

Wir basteln uns einen Sprachroboter („robo“)

Wie bringt man seine Ubuntubox dazu, beliebige Texte (auch dynamisch generierte) mit einer Computerstimme vorlesen zu lassen?
Der hier beschriebene Weg ist dabei nur einer von mehreren möglichen. Damit der Computer sagt, was wir wollen, basteln wir uns ein kleines Skript mit dem Namen „robo“, das auf der Sprachsynthetisierungssoftware „festival“ aufbaut. Außerdem benötigen wir eine Möglichkeit, die durch diese Software erzeugten wav-Dateien über die Konsole abzuspielen. Hier benutze ich den Befehl „play“ aus dem Paket „sox“. Unter Ubuntu installieren wir die benötigten Pakete mit:

sudo apt-get install festival sox

„festival“ beinhaltet den Befehl „text2wave“, der (nomen est omen!) eine Textdatei in eine wav-Datei umwandeln kann. Beispiel:

text2wave /etc/hostname -o /tmp/hostname.wav

Obiger Befehl liest die Datei /etc/hostname (den Namen des Computers, hier: „ubuntukiste“) ein, wandelt den Text nach wav um und legt die generierte Sounddatei als /tmp/hostname.wav ab. Spielen wir nun die Datei /tmp/hostname.wav mit einem beliebigen Player (hier: play) ab, sagt der Computer: „ubuntukiste“. Für den Einzelgebrauch ist dies mehr als gut genug, doch wir wollen uns den Ablauf in einem Skript namens „robo“ möglichst so automatisieren, dass all diese Schritte zusammengefasst werden und „robo“ auch skriptgenerierte Texte vorlesen kann:

#!/bin/sh
TXTTMP=$HOME/.tmp.txt           # where to save text
WAVTMP=$HOME/.tmp.wav           # where to save audio
echo $@ > $TXTTMP               # save input as text
text2wave $TXTTMP -o $WAVTMP    # convert to audio
echo `cat $TXTTMP`              # write to console
play -q   $WAVTMP               # play as audio
exit                            # bye bye

Das Skript speichern wir nun als /usr/local/bin/robo ab und machen es ausführbar:

sudo chmod +x /usr/local/bin/robo

Im Prinzip ist unser kleiner Sprachroboter nun fertig und einsetzbar.

Direkte Texteingabe:
Damit „robo“ z.B. „hello world“ sagt starten wir ihn mit:

robo hello world

Vorhandene Textdatei einlesen:
„robo“ soll uns nun die Datei /home/ubufreak/greetings vorlesen, in die wir den Satz „hello ubuntuusers, how are you?“ hinterlegt haben:

robo `cat /home/ubufreak/greetings`

Dynamische Texte: Zur Erinnerung: Alles zwischen den seltsam anmutenden Anführungszeichen (`backticks`) wird als Befehlssubstitution ausgeführt, d.h. der zwischen den `backticks` stehende Befehl wird zuerst ausgeführt und dann die Ausgabe dieses Befehls an „robo“ als Argument übergeben. Dies können wir uns auch für andere Befehle als „cat“ zu Nutze machen. Beispiel:

robo `uname -r`

Mit obigem Befehl wird uns „robo“ die aktuelle Kernelversion vorlesen. Ein weiteres Beispiel:

robo "The time ... `date +'%H:%M'`"

Mit diesem Befehl liest „robo“ die aktuelle Zeit ein und sagt dann: „The time: 8:37″. Den ersten Teil nimmt „robo“ dabei als direkten Text auf, die Zeit selbst über die dynamisch generierte Kommandosubstitution. (In solchen Fällen die komplette Befehlskette mit regulären Anführungszeichen einrahmen). So ein Miniskript können wir z.B. in der Datei /etc/cron.hourly ablegen und ausführbar machen, damit „robo“ uns die Zeit jede Stunde ansagt.

Weierführende Infos: Damit sollten die grundlegenden Möglichkeiten von „robo“ deutlich geworden sein. Grundsätzlich sollte „robo“ auch unter anderen Linuxsystemen funktionieren. „festival“ ist standardmäßig mit einer männlichen englischsprachigen Stimme konfiguriert. Eine deutsche Stimme gibt es noch nicht. Längere Textdateien benötigen eine gewisse Zeit zum konvertieren. Mit „robo“ könnten wir z.B. auch bei sicherheitsrelevanten Ereignissen zeitnah alarmiert werden, z.B. könnten wir ein kleines Skript schreiben, dass regelmäßig die Logfiles nach bestimmten Ereignissen (z.B. Zugriffsversuch per SSH) grept und dies umgehend an uns verpetzt: „Attention! Secure Shell connection attempt from IP ***.***.***.***“.

Viel Spaß mit „robo“!

Android auf Freerunner: USB-Verbindung per Shellskript

Eine einfache und schnelle USB-Verbindung auf das Openmoko Freerunner (mit Android OS) wird durch ein kleines Skript erleichtert.

androidshell

Hinweis: Dieser Artikel erschien ursprünglich am 11.5.2009 und erfährt aus rein technischen Gründen eine überarbeitete Neuauflage. Danke für das positive feedback!

Nach der Installation von Android will man schnell Daten zwischen dem lokalen Rechner und dem Freerunner austauschen. Dazu nötig ist die korrekte Netzwerkkonfiguration der lokalen Schnittstelle (z.B. usb0, bei Ubuntu 9.04 eth1), eine bestehende USB-Verkabelung (muss zum Bootzeitpunkt des Freerunners bestehen), sowie eine funktionierende Verbindung via adb (Details: Android auf Freerunner: Einstieg und USB-Networking).

Nach der x-ten Verbindung war ich es Leid, dieselben Befehle immer wieder einzugeben. Ich beschloss also, dies durch ein Skript ein bisschen effektiver zu gestalten. Das Resultat in action sieht dann so aus:

androidshell

Ach ja: das schöne (eigentlich vollkommen unnötige Banner) wurde mit Hilfe von figlet erstellt.

Das Skript nun als „androidshell“ umbenennen, ausführbar machen und in PATH ablegen.

#!/bin/sh
# Easily connect to Openmoko phones with Android OS.
# This script first configures your local interface.
# This script then utilizes Android Debug Bridge (adb) to connect.
# Possibly you have to change the variable INT.
# INT may vary on different systems (eth1, usb0, eth0 ...).
# All other variables should be fine.
######################### Configure local interface to connect to android by USB
INT="eth1"              # you might have to change this (eg usb0)
IPADDR="192.168.0.200"  # local IP: should be fine
NETMASK="255.255.255.0" # local netmask: should be fine
IPFREE="192.168.0.202"  # IP freerunner (default): fine
PROGNAME="androidshell" # name of program: no need to change
#########################
######################### make a nice banner
clear
echo "                 _                 _     _          _ _ " | grep --colour "."
echo "  __ _ _ __   __| |_ __ ___ (_) __| |___| |__   ___| | |" | grep --colour "."
echo " / _. | '_ \ / _. | '__/ _ \| |/ _. / __| '_ \ / _ \ | |" | grep --colour "."
echo "| (_| | | | | (_| | | | (_) | | (_| \__ \ | | |  __/ | |" | grep --colour "."
echo " \__,_|_| |_|\__,_|_|  \___/|_|\__,_|___/_| |_|\___|_|_|" | grep --colour "."
echo "      Android on Freerunner - adb connector via USB"      | grep --colour "."
echo "--------------------------------------------------------"
echo "2009 by linuxnetzer -GPLv3- www.linuxnetz.wordpress.com"
echo "--------------------------------------------------------"
echo "                 PLEASE MAKE SURE... " | grep --colour "."
echo "... adb is installed in PATH."
echo "... Freerunner was connected whilst booting."
echo "... $INT is your correct local USB interface."
echo "--------------------------------------------------------"
######################## configure local interface
echo "setting up $INT for connection (needs root privileges)"
sudo ifconfig $INT $IPADDR netmask $NETMASK
######################## prepare adb
echo "preparing adb..."
adb kill-server
ADBHOST="$IPFREE" adb devices 1> /dev/null
echo "If prompt has changed (#), connection was successful."    | grep --colour "\#"
echo "Type 'exit' to finish connection. Keep up the vibes!" | grep --colour "exit"
######################## start adb
adb shell
exit

# chmod +x /usr/local/bin/androidshell

Das Skript sollte – theoretisch – „out of the box “ funktionieren. Sollte die lokale Schnittstelle (im Skript: eth1) nicht erkannt werden, muss die Variable ‘INT’ gleich zu Beginn des Skripts entsprechend geändert werden. usb0 ist eine wahrscheinliche Alternative.

Wer solche Skripten wegen ihres „grafischen Overloads“ meidet und die Dinge lieber einfach hält, für den tut es auch ein minimalistisches Skript. Zur Erinnerung: Per default hat Freerunner seiner Schnittstelle die IP Adresse 192.168.0.202 zugeteilt. Um mit ihm zu kommunizieren, müssen wir uns in dasselbe Netz begeben…

#!/bin/sh
sudo ifconfig eth1 192.168.0.200 netmask 255.255.255.0
adb kill-server
ADBHOST=192.168.0.202 adb devices
adb shell

Links:

http://linuxnetz.wordpress.com/2009/05/09/freerunner-android-sd-card-vorbereiten/
http://linuxnetz.wordpress.com/2009/05/05/android-auf-freerunner-einstieg-und-usb-networking/
http://wiki.openmoko.org/wiki/Android_on_Freerunner#On_Linux
http://wiki.openmoko.org/wiki/Android_on_Freerunner#Installing_Android_on_an_SD_card
http://www.freeyourphone.de/portal_v1/viewforum.php?f=18

Ohne Mailserver emails per shell script versenden (SMTP over TLS)

Das Programm „sendEmail“ versendet emails auf der Kommandozeile per smtp via TLS-Verschlüsselung und kommt dabei ohne Mailserver aus.

Lizenz: GFDL 1.2

Wer auf der Kommandozeile bzw. scriptgesteuert emails versenden will, der tut dies meist mit Hilfe eines Mailservers. Ein Mailserver wie sendmail ist jedoch nur mit einem nicht unerheblichen Aufwand aufzusetzen und zu warten. Darüberhinaus kann er – gerade auf Servern – ein Sicherheitsrisiko bedeuten.

In diese Bresche springt das Programm „sendEmail“, mit dem auch Dateianhänge versandt werden können. Der Einsatzbereich dieses kleinen Programms, das in perl geschrieben ist, ist vielfältig. So könnten z.B. Warnmails an den Administrator versandt werden, wenn:
- sich der Speicherplatz einer Festplatte seiner Maximalkapazität nähert
- bestimmte Schlüsselbegriffe in den Logdateien auftauchen
- ein Passwort mehrmals falsch eingegeben wurde

Geübte Shellscripter können mit „sendEmail“ (immer das große „E“ benutzen!) den Eintritt eines beliebigen Ereignisses mit dem Versand einer email verknüpfen. Die folgenden Informationen gelten für ein System „Ubuntu Jaunty Jackalope“ und einen email-Account bei web.de, sollten jedoch auch grundsätzlich für andere Systeme gelten.

Installation:
Neben „sendEmail“ werden folgende Pakete benötigt:
libio-socket-ssl-perl, libnet-ssleay-perl, perl
Unter Ubuntu werden alle benötigten Pakete  aus den Paketquellen installiert:

sudo apt-get install sendEmail libio-socket-ssl-perl libnet-ssleay-perl perl

Infos zur Installation des Tarballs finden sich auf der sendEmail Homepage.

Mails senden:
Zum Versenden einer Mail muss man sich zunächst für einen SMTP-fähigen email-Account mit TLS-Unterstützung registriert haben. Eine reguläre email-Adresse bei web.de erfüllt diesen Zweck. Dabei bitte beachten, dass das Passwort zwar verschlüsselt übertragen wird, jedoch in der Bash-History bzw. im Shellscript im Klartext aufzufinden sind. Eine eigene Email-Adresse nur zu diesem Zweck zu registrieren, scheint also empfehlenswert. Im folgenden Beispiel wird die fiktive Adresse „username@web.de“ verwendet. Die Mail wird per SMTP an web.de gesendet und von hier an die Empfangsadresse weitergeleitet.
Am folgenden Beispiel soll verdeutlicht werden, wie „sendEmail“ eine mail versendet:

sendEmail -v -f username@web.de -s smtp.web.de:25 -xu username -xp totalgeheim -t adminempfaenger@gmx.de -o tls=yes -u „Betreff: Test!“ -m „Hallo, dies ist ein Test!“

Die Optionen im Einzelnen:
-v   verbose: geschwätziger Modus (hilfreich zur Fehlersuche)
-f    from: die Absenderadresse, von der die mail versandt werden soll (hier: username@web.de)
-s    server&port: Der zuständige SMTP-Server samt Portangabe
-xu    username: Der Benutzername. (Manche Provider erwarten hier die komplette Emailadresse)
-xp    password (SMTP): bei web.de das reguläre Benutzerpasswort
-t    to: Empfängeradresse
-cc    Kopie der Mail senden an: 2. Emailadresse
-bcc    Versteckte Kopie der Mail senden an: 2. Emailadresse
-o    hier: tls=yes – sorgt für eine verschlüsselte TLS-Übertragung
-u    subject: Betreffzeile
-m    message: Inhalt der Email
-a    attachement: Pfad zu Dateianhang, der mitgesendet werden soll

Weiterführende Infos:
Mit einem gmx-Account ist es mir nicht gelungen, mit sendEmail mails zu versenden („Segmentation fault“). Wer weiß woran es hapert, kann gerne einen Kommentar hinterlassen. Ach ja: sendEmail scheint im Moment nur TLS, nicht aber SSL zu unterstützen.
Ein schönes (englischsprachiges) Beispiel, wie man sich täglich Logdateien per email aus einer Kombination von sendEmail, shellscripting und cronjob senden lassen kann, ist in diesem Tutorial beschrieben, das kürzlich erschienen ist. Die sendEmail Homepage mit allen Optionen und mehr Informationen ist hier: sendEmail Homepage

Rootkit Alarm! Mit „unhide“ versteckte Prozesse entlarven

Nach einem Einbruch auf ein System platzieren Rootkits gerne Software und Dateien, die den Einbruch verschleiern und künftige diskrete Zugriffe des Angreifers ermöglichen sollen.

Bild Lizenz: GNU Free Documentation License, Version 1.2 oder später

Damit solche tiefgreifenden Eingriffe im Wirtssystem verborgen bleiben, arbeiten Rootkits gerne mit versteckten Prozessen, die dem durchschnittlichen User/Administrator nur schwer ins Auge springen dürften.

Solche versteckten Prozesse zu entlarven, hat sich das Kommandozeilenprogramm „unhide“ zur Aufgabe gemacht. Dazu nutzt es drei verschiedene Techniken:

• proc:    Vergleicht die Prozesse in /proc mit der Ausgabe von /bin/ps
• sys:        Vergleicht Infos von /bin/ps mit Infos aus Systemaufrufen
• brute:    PID Bruteforcing Technik (nur ab Kernel 2.6.*)

Um z.B die Technik „proc“ anzuwenden, wird „unhide“ wie folgt gestartet:

unhide proc

Um alle drei Techniken in Folge anzuwenden, kann „unhide“ so gestartet werden:

for H in proc sys brute; do unhide $H; done

Weitere Programme zur Enttarnung bösartiger Rootkits sind „chkrootkit“ und „rkhunter„. Bei Ubuntu lassen sich alle 3 Programme über die Paketquellen installieren.

Mit ‘du’ den Speicherverbrauch von Verzeichnissen ermitteln

Neulich war die Festplatte eines meiner Systeme voll. Ich suchte deshalb nach einer simplen Methode, um zu ermitteln, wo sich das Gros der Daten versteckt hielt.

Die Lösung ist der Befehl du (du: disk usage). Als Argument nimmt er ein Verzeichnis und spuckt dann den Gesamtspeicherplatz aller Dateien innerhalb dieses Verzeichnisses als Rückgabewert aus. Um z.B. zu ermitteln, wieviel Speicher die Logdateien im Verzeichnis „/var/log“ belegen, wird du am Besten so aufgerufen:

du -sh /var/log
15M            /var/log

Das Verzeichnis inklusive aller Unterdateien belegt also 15 MegaByte. Die Option -h sorgt dafür, dass der Speicherplatz in KB, MB oder GB ausgegeben wird (h: human readable). Die Option -s (s: summarize) sorgt dafür, dass der Speicherverbrauch der jeweiligen Dateien schön kompakt in einer Zahl für den Gesamtverbrauch zusammengefasst wird. Ohne diese Option würde der Befehl für jede einzelne Unterdatei den Verbrauch auflisten.

Die zweite praktische Spielart dieses Befehls ist die Option –max-depth. (Das Minus vor dem max-depth muss 2mal gesetzt werden. Oh Mann ich bin es Leid. Wann wird dieser dämliche bug endlich bei WordPress gefixt?) Wird diese Option mit dem Wert 1 versehen, steigt der Befehl eine Verzeichnisebene hinab und zeigt den Verbrauch aller Unterordner an. Im folgenden Beispiel versuche ich herauszufinden, in welchem Verzeichnis direkt unter / der größte Speicherplatz verbraucht wird:

du -h –max-depth=1 /

51M    /boot
0    /sys
40G    /opensourcevideos
2,6M    /root
6,1M    /bin
1,2G    /home
424M    /lib
68K    /tmp
4,0K    /mnt
16K    /lost+found
8,0K    /media
0    /proc
716K    /dev
4,0K    /opt
8,4M    /sbin
15M    /etc
3,0G    /usr
463M    /var
45G    /

Für das / Verzeichnis sollte der Befehl mit root-Rechten ausgeführt werden, um „permission denied“ zu unterdrücken. Von den 45 GB, die / insgesamt belegt (siehe letzte Zeile), werden alleine 41 GB durch das Verzeichnis /opensourcevideos belegt. Na also, dann weiß ich auch, wo ich mal wieder aufräumen muss…

Weiteführende Infos:

man du

NICs zuordnen: Welche ist eth0,eth1,eth2 ?

Wer schon mal eine Maschine mit mehreren Netzwerkkarten in ein Netzwerk integriert hat, kennt vielleicht das Problem: Welche RJ45-Buchse entspricht nun eth0, eth1 und eth2?

Wie kann man die Schnittstellen möglichst schnell zuordnen? Der folgende Befehl bringt die Netzwerkkarte eth0 für 30 Sekunden zum Blinken und identifiziert sie eindeutig, ohne Kabel zu stecken und groß herumzupingen (erfordert root-Rechte):

ethtool -p eth0 30

Um diese Methode für alle drei Karten in einem Aufwasch anzuwenden, verwenden wir die folgende Befehlskette (Jede Schnittstelle soll 15 Sekunden blinken, dann geht’s weiter zur nächsten):

for NIC in eth0 eth1 eth2; do echo „Jetzt blinkt $NIC“; ethtool -p $NIC 15; done

Auf diese Methode aufmerksam geworden bin ich durch diesen Blogeintrag.

Bildlizenz: Public Domain

Grüße aus dem Sommerloch (2)

"Alle Rechte vorbehalten"

Grüße aus dem Sommerloch (1)

Hurra! Es lebe die freie Mediengesellschaft!

Bei der Sichtung meiner Abonnements mit meinem Feedreader Liferea machte mich heute der folgende Wikio-feed stutzig, den ich unbedingt mit allen Mitgliedern einer freien Mediengesellschaft teilen möchte:

(feed 27.8.09:     http://rss.wikio.de/high-tech/computer/betriebssysteme/linux.rss)

Ich bin noch immer nicht sicher, warum ich dieses Bild für veröffentlichungswert halte. Hier ein paar vorläufige Thesen:

1. Journalismus (vulkanischer Ursprung) bedeutet: „Voneinander abschreiben“

2. Hey! Wow! Nokia ist echt ein tolles Phone, Mann!

3. Zwischen 10 und 19 Uhr ist seit 1834 in der Linuxwelt noch nie etwas Wichtiges passiert…

4.  Dieser Torvalds muss aber auch jede Harmonie zerstören!

5. Jetzt reichts! Ich werde sofort einen Kommentar hinterlassen!

Ubuntu: Flaschenoptionen deaktivieren?

Beim Mounten einer CD unter Jaunty erhielt ich heute die folgende für mich rätselhafte Fehlermeldung:

Hilfe! Wie kann man bitte die Flaschenoptionen deaktivieren?

Von diesen Flaschenoptionen habe ich aber noch nie etwas gehört. Offenbar würde das Einhängen der CD ohne diese mysteriöse Flaschenoption wohl funktionieren.  Selbst durch scroogeln konnte ich nichts über die Flaschenoptionen unter Ubuntu herausfinden.

Hilfe! Wie kann man bitte die Flaschenoptionen deaktivieren?

Ansonsten befürchte ich, dass es – ähnlich wie bei RecordMyDesktop – zu erheblichen Leistungseinbusen kommen könnte. Und das möchte ich bitte schon verhindern…

Leistungseinbusen bei RecordMyDesktop?