Archiv der Kategorie: Memo

PDF nach JPG und zurück

PDFs putzen ist oft heikel, weil bei der Arbeit mit Acrobat oft nur ein neuer Layer über den Teil gelegt wird, den man hatte löschen wollen. Mit etwas Geschick kommen die „verborgenen“ Daten wieder zum vorschein.

Die Konvertierung nach JPG und das Löschen mit der Bildbearbeitung liefert 100%ige Ergebnisse. Bei diesem Verfahren ist das Ergebnis nicht nur sauber, sondern rein. Jedoch: convert exportiert PDFs in einer Auflösung, dass es einem die Schuhe auszieht.

So geht’s besser:

convert -density 1200 input.pdf input.jpg

Dabei entstehen zwar monsterdicke JPGs – die man in GIMP wieder auf eine ordentliche Größe bringen sollte, soll das Endprodukt nicht zu dick werden.

Mit

convert input_0.jpg input_1.jpg output.pdf

schiebt man die Bilder wieder in ein neues PDF.

Kernelbackede

Kein Backofen in der Wohnung hier … also muss ein Debian 6 darunter leiden, dem ich gerade versuchsweise einen 3.4.7 Kernel unterschieben will.

cd /usr/src/

wget http://www.kernel.org/pub/linux/kernel/v3.0/linux-3.4.7.tar.bz2

tar jxvf linux-3.4.7.tar.bz2

cp /boot/config-$(uname -r) /usr/src/linux-3.4.7/.config

cd linux-3.4.7

make menuconfig

make-kpkg clean

fakeroot make-kpkg –initrd –revision=custom.0.1 kernel_image

Ich hätte allerdings den Prozess nicht unbedingt als root durchlaufen müssen, sondern mich in die Gruppe src einschreiben können. Weiter wäre es wohl schlau gewesen in /etc/kernel-pkg.conf zuerst noch CONCURRENCY_LEVEL=n (wobei n = CPU Cores + 1 und damit wie der Schalter -j bei make zu behandeln) zu setzen, statt nun blöd auf die Shell zu glotzen, weil alles ziemlich ewig dauert. Bis zum finalen

dpkg -i linux-image-3.4.7_custom.0.1_i386.deb

und dem Reboot dauert es demnach noch … und ich vertreibe mir so lange die Zeit mit dem Schreiben von Posts. Auch gut.

Da mir mein Backprozess immer wieder mit einer Fehlermeldung zu lguest auf die Nase fiel, hab ich die folgenden Auskommentierungen noch in der .config händisch vorgenommen [1]:

# CONFIG_LGUEST_GUEST
# CONFIG_PARAVIRT_SPINLOCKS
# CONFIG_LGUEST

SSH absichern

Mein root Server bei Hetzner nutzt schon lange das publickey-Verfahren, um sich gegen Attacken gegen Port 22 und damit SSH zu schützen. Dafür hat Frank gesorgt. Meine Server in der Schule nun endlich auch … und damit bestand das Problem, dass ich nicht den gleichen Key für zwei Server nutzen wollte bzw die Neuerstellung eines weiteren Keys den Inhalt der id_dsa Datei im .ssh Verzeichnis überschreibt und ich so meinen alten Key verloren hätte. Wer zwei oder mehr getrennte Keys wünscht, muss also Pfade zu denselben angeben.

Während der gesamten folgenden Schritte immer eine root-shell auf dem Server offen haben, damit man sich die alten Einstellungen im Notfall zurück holen kann, sollte man sich aussperren.

Zur Vorbereitung die /etc/ssh/sshd_config an einen sicheren Ort wegkopieren und dann anpassen – und zwar die folgenden Zeilen in derselben, sofern man unter einem Debian / einer SuSE mit installiertem sudo bzw. Ubuntu arbeitet:

Port 222222
PermitRootLogin no
X11Forwarding no
PrintMotd no
ChallangeResponseAuthentication no
PasswordAuthentication no

Port 22222 ist evtl. etwas übertrieben – aber Paranoia schadet ja nicht.

Auf dem Client dann den Key erstellen und die Rückfrage nach einem Passwort für den Key mit einer entsprechend komplizierten und langen Passphrase beantworten:

ssh-keygen -f /home/benutzer/.ssh/benutzer-servername

Der öffentliche Teil muss dann mit Hilfe von scp auf den Server transferiert werden:

scp /home/benutzer/.ssh/benutzer-servername.pub benutzer@servername.domain:/home/benutzer

Dort den öffentlichen Schlüssel in den Schlüsselbund kopieren:

cat benutzer-servername.pub >> /home/benutzer/.ssh/authorized_keys

Ein

/etc/init.d/ssh restart

schaltet die Änderungen scharf.

Jetzt die Verbindung vom Client aus testen:

ssh benutzer@servername.domain -p 22222 -i /home/benutzer/.ssh/benutzer-servername

Wenn alles klappt, man also nach der Passphrase für den Key und nicht mehr nach einem Serverkennwort gefragt wird, sich also anmelden und mit Hilfe von sudo auch root werden kann, ist alles gut. Wenn nicht, dann zuerst die Rechte der eben angelegten Dateien und Verzeichnisse kontrollieren.

Echo

Bei der Einrichtung des Wetterservers meiner Schule mit wview muss ein Administratorkennwort als MD5 Summe vergeben werden. Klingt einfach – ist aber ein Stolperstein gewesen.

echo „geheim“ | md5sum

ergibt

3255e5acced6e40fc7c73ac6eaa34cdc

Also hab ich diese MD5 Summe eingetragen und konnte mich dann doch nicht einloggen.

Wer kann auch ahnen, dass echo nicht so einfach funktioniert wie von mir gedacht. Es klappte erst mit

echo -n „geheim“ | md5sum

das etwas völlig anderes, nämlich

e8636ea013e682faf61f56ce1cb1ab5c

ergibt. Damit war die Anmeldung dann möglich.

Das Problem war also, dass echo eine Newline automatisch anhängt, was aber bei der Passworteingabe in die Weboberfläche nicht möglich ist. Wieder was gelernt.

KDE 4 Fensterknöpfe

Ich nutze wohl schon zu lange Ubuntu und habe mich an die Position der Knöpfe im Fenster gewöhnt.

Unter KDE kann man diese wie folgt einstellen. Unter /Systemeinstellungen /Erscheinungsbild wählen und dort im Bereich /Fenster auf den Reiter für /Knöpfe klicken. Hier kann die Position der Schalterchen mit der Maus beliebig verschoben werden.

Nachtrag 11.03: Unter KDE 4.4.5 sind diese Einstellungen an einer anderen Stelle zu finden – und zwar unter /Erscheinungsbild der Arbeitsfläche /Fensterdekoration /Knöpfe einrichten. Dann muss man zusätzlich noch ein Häkchen bei „Benutzerdefinierte Position von Titelleistenknöpfen verwenden“ setzen.

Arbeitsnachweis

Ich hab immer wieder das Problem, dass ich wissen sollte, welche Arbeiten in den letzten 7, 14, 21 oder 28 Tagen von mir / jemand anderem in einem bestimmten Verzeichnis erledigt wurden – also vor allem, welche Dateien angelegt oder verändert wurden. Dazu hab ich mir ein kleines Script geschrieben:

#!/bin/bash
echo „7 TAGE“ > /home/user/workdone.txt
find . -mtime -7 -print >> /home/user/workdone.txt
echo „14 TAGE“ >> /home/user/workdone.txt
find . -mtime -14 -print >> /home/user/workdone.txt
echo „21 TAGE“ >> /home/user/workdone.txt
find . -mtime -21 -print >> /home/user/workdone.txt
echo „28 TAGE“ >> /home/user/workdone.txt
find . -mtime -28 -print >> /home/user/workdone.txt
sed ‚/zuloeschen/d‘  /home/user/workdone.txt > /home/user/workdone2.txt
cat /home/user/workdone2.txt

Der Einschub sed ‚/zuloeschen/d‘ workdone.txt sorgt dafür, dass ich Elemente, die vom Server selbst kommen (im konkreten Fall sind dies täglich erneuerte Steuerdateien) einfach wieder raus werfen kann. Im Beispiel oben würde demnach die Zeile, die das Wort zuloeschen enthält, gelöscht.

OpenNIC und Smoothwall

Wer OpenNIC Domains hinter einer Smoothwall nutzen möchte, die (auf Grund des Basteltriebs des Besitzers) per DHCP ihre „rote“ IP und damit auch die Nameserverangaben bekommt, kann/etc/resolv.conf leider nicht direkt ändern, weil a) ein Startskript diese beim Hochfahren der Smoothwall plättet und b) diese lediglich einen Verweis auf 127.0.0.1 enthält.

Als root per SSH auf der Smoothwall anmelden. Die Datei

/etc/rc.d/resolv.conf.dnsmasq

anlegen und den folgend strukturierten Inhalt hinterlassen:

nameserver ip.des.opennic.dns
nameserver ip.des.rout.ers

Mögliche IPs für die OpenNIC DNS Server erfährt man auf der Startseite von OpenNIC. Die IP des von der Smoothwall aktuell genutzten DNS (ergo: des Routers) erfährt man aus der aktuellen /etc/resolv.conf.dnsmasq durch ein

cat /etc/resolv.conf.dnsmasq

Nun zur Datei

/etc/rc.d/rc.updatered

am Ende den folgenden Eintrag hinzufügen:

cp /etc/rc.d/resolv.conf.dnsmasq /etc

Dann die Smoothwall einmal neu booten und durch

ping www.opennic.glue

testen, ob es tut. Bei Problemen hilft die OpenNIC Seite weiter.

Quelle: http://www.opendns.com/support/article/212

keybindings II

Für den manuellen Weg und für eine allgemeine Beschreibung siehe diesen Beitrag.

Im Alltag taugt für eine Synchronisation von Tastenkombinationen mal wieder rsync. Um die Tastenkombinationen vom Homeserver auf den Laptop zu bekommen, das Serververzeichnis (z.B. mit Hilfe von NFS oder Samba) am Laptop einhängen und dann auf dem Laptop das folgende, selbstverständlich an die eigene Umgebung angepasste, Skript laufen lassen:

#!/bin/bash
# Standardkeybindings
rsync -r -t -v –progress –delete /home/user/eingehaengtesserververzeichnis/.gconf/desktop/gnome/keybindings/ /home/user/.gconf/desktop/gnome/keybindings/ ;
# Zusatzkeybindings
rsync -r -t -v –progress –delete /home/user/eingehaengtesserverzeichnis/.gconf/apps/gnome_settings_daemon/keybindings/ /home/user/.gconf/apps/gnome_settings_daemon/keybindings/ ;

Ausloggen – Einloggen. Die Tastenkombinationen des Laptops entsprechen nun denen vom Homeserver.

Evolution Müll leeren

Hier hatte ich es ja schon einmal davon, dass sich der Mülleimer von Evolution nicht leeren ließ. Ein Teil der Lösung war,  ganz prinzipiell keine 4GB an Mails mehr allein Evolution anzuvertrauen, sondern einen lokalen IMAP Server als Speicher für die Mail-Altbestände zu nutzen. Die Anleitung hierzu schrieb ich hier.

Heute – knapp 250MB an Mails später – hatte ich schon wieder das Problem, dass Evolution den Mülleimer nicht putzen wollte … dafür hab ich aber nun eine Schnelllösung in den Foren von Ubuntuusers gefunden:

Evolution beenden. Dann im Ordner ~/.evolution/mail/local die Datei folders.db erst einmal auf den Desktop verschieben (man weiß ja nie – gleich löschen könnte heikel sein). Evolution wieder starten und der Mülleimer sollte sich leeren lassen.

keybindings

Unter /System /Einstellungen /Tastenkombinationen ist das Programm gnome-keybinding-properties abgelegt und erlaubt die komfortable Konfiguration vieler (nicht: aller) Schnellzugriffstasten (vulgo: Tastaturkürzel). Leider ist eine derartige Konfiguration pro Rechner jeweils erneut durchzuführen. Bei einem entsprechend großen Rechnerpark dauert es demnach eine Weile, bis alle Maschinen sich gleich verhalten.

Die Konfiguration lässt sich jedoch einfach von einem Rechner auf einen anderen übertragen – zumindest bei den Einstellungsdateien für Programmaufrufe, die man zusätzlich angelegt hat. Die liegen hier:

~/.gconf/desktop/gnome/keybindings

Auf die schon fertig angelegten Einträge kann man z.B. mit Hilfe von gconf-editor zugreifen. Hier habe ich unter

/apps/gnome_settings_daemon/keybindings

entsprechende Einträge gefunden. Weiter liegen diese Einträge auch unter

~/.gconf/apps/gnome_settings_daemon/keybindings

Das Vorgehen ist nun relativ einfach: Man kopiert sich die entsprechenden Verzeichnisse bzw. Verzeichniseinträge von der fertig konfigurierten Maschine auf den neu einzurichtenden Rechner.

Einmal ausloggen – wieder einloggen. Fertig.