Zu wenig Bilder?

Bei einem der letzten Updates von Firefox Version 3.6 auf Version 11.0 aus den offiziellen Repositories ging bei mir irgendwie das Java Plugin verloren. Dies hat zur Folge, dass Websites mit Java-Anteil (Post Portodruck, oder der online Foto-Dienst von DM) nicht mehr funktionieren.

Installation überprüfen

Ob das JRE-Plugin installiert ist, kann man folgendermaßen herausfinden:

about:plugins

in die Adresszeile des Browsers eingeben. Es erscheint eine Liste mit allen installierten Plugins. Falls hier kein Eintrag auftaucht, der “Java(TM) Plug-in 1.6.****” oder ähnlich heißt, ist das Java-Plugin nicht mehr richtig installiert.

Java Plugin für Firefox 11 wieder richtig installieren

Als erstes suchen wir uns die Plugin Datei:

$ locate libnpjp

Lustigerweise heißt das Browserplugin libpjp2.so und nicht sunjavaplugin.so oder libjavaplugin_jni.so was ich zuerst vermutete.
Als Ergebnis sollte euch der Pfad angezeigt werden, in welchem die Plugin-Datei zu finden ist. Bei mir ist das beispielsweise:

$ locate libnpjp
/usr/lib/jvm/java-6-sun-1.6.0.26/jre/lib/amd64/libnpjp2.so

Falls ihr locate nicht installiert habt, erfüllt das gute alte find die Aufgabe natürlich ebenso (so zu suchen könnte etwas länger dauern ):

$ find / -iname "*libnpjp*" -type f 2> /dev/null

Wenn die Plugin-Datei gefunden wurde, muss eine symbolischer Link zur Plugin-Datei im Plugins-Verzeichnis von Firefox angelegt werden. Bei mir wäre das beispielsweise /usr/lib/mozilla/plugins. Hierzu werden root-Rechte benötigt, bei Ubuntu also ein sudo vorne anhängen:

# ln -s /usr/lib/jvm/java-6-sun-1.6.0.26/jre/lib/amd64/libnpjp2.so /usr/lib/mozilla/plugins/

Dann noch Firefox neu starten und mit obiger Methode prüfen, ob das Plugin wieder in der Liste auftaucht.

Quellen: [1] und [2]

mogrify -strip $BILD

Der Nachteil: mogrify überschreibt das Basisbild, was meistens nicht gewünscht ist. Abhilfe schafft hier – ebenfalls aus dem ImageMagick-Paket – das convert-Tool:
$ convert $BILD -strip $AUSGABE
Das wars! Ganz praktisch, wenn man sich die Bilder per Script für den Upload ins Web aufbereiten lässt.

Das Entfernen der EXIF-Daten mittels ImageMagick hat allerdings einen Nachteil: ImageMagick komprimiert das Bild neu. Die Entfernung der EXIF-Daten ist also nicht verlustfrei. Das hat laut einem Thread im ImageMagick-Forum folgenden Grund: ImageMagick versucht zu berechnen, welche Einstellungen für das jpg-Format bei der Erstellung des Bilder verwendet wurde. Da, zumindest in meinem Fall, die zu komprimierenden Bilder meistens von einer Digitalkamera erstellt wurden, ist das Ergebnis der Berechnung nicht exakt, sondern nur eine Annäherung an die proprietären Quantisierungstabellen der Kamerahersteller.

Abhilfe schafft hier das Tool jpegtran, das speziell für die verlustfreie Konvertierung von jpg-Dateien gedacht ist:

jpegtran -copy none $BILD.jpg > $AUSGABE.jpg
jpegtran -copy none -outfile $AUSGABE.jpg $BILD.jpg

Quelle: Stackoverflow
Mit ImageMagick kann man übrigens noch viele weitere tolle Dinge machen –> Man-page!

Hier mal grob zusammengefasst die Releasenotes von Version 1.1:

• 4 neue Getränkeicons hinzugefügt – insgesamt sind es jetzt 79
• GUI Redesign
• Es werden Sprüche passend zum Promillestand angezeigt
• Multilanguagesupport in Deutsch, Englisch, Französisch und Polnisch (Danke Kamill!!)
• Die Zeit, bis man wieder nüchtern ist, wird angezeigt.
• Sicherheitsabfrage für “Neue Saufrunde”-Button hinzugefügt. Ein versehentliches löschen aller getrunkenen Drinks wird so verhindert.
• Alle Getränke sind nun löschbar.
• Größe der Getränkeicons wird automatisch gewählt oder kann manuell eingestellt werden.
• Das alte Layout kann über das Optionsmenü wieder aktiviert werden.
• Das Anlegen von Mischgetränken ist jetzt komfortabler.
• Voreingestellte Getränke wurden verbessert.
• Der Startzeitpunkt einer Trinksession kann jetzt auch in der Vergangenheit liegen.
• Facebook-Support integriert

Außerdem ist der Alcomat jetzt in zwei Versionen erhältlich:

Alcomat Lite

1. Alcomat Lite

Mit komplettem Funktionsumfang, allerdings mit Werbung. Den Alcomat Lite kann man wie bisher auch kostenlos aus dem Android Market / Google Play herunterladen.
Alcomat Lite Promillerechner in Version 1.1 im Androidmarket

Alcomat Pro

2. Alcomat Pro

Ebenfalls mit komplettem Funktionsumfang, allerdings werbefrei! Diese Version ist einmalig kostenpflichtig und ist ebenfalls über den Android Market bzw. Google Play erhältlich.
Alcomat Pro Promillerechner in Version 1.1 im Androidmarket

Beider Versionen sind ab Android 2.1 aufwärts lauffähig!

Screenshots:

Voraussetzung ist ein Linux-Server mit ssh-Zugang und vorhandenen root-Rechten.

Git installieren: Als erstes sollte man auf dem Server git an sich installieren:

root@server:~# aptitude install git-core -y

Git-User anlegen: Danach wird der git-User angelegt und in dessen Home-Verzeichnis gewechselt:

root@server:~# adduser git
root@server:~# cd /home/git

Als nächstes loggt man sich als der git-User ein:

root@server:/home/git# su git

Public-Key-Authentisierung einrichten: Legt den .ssh-Ordner und die Datei mit den authorisierten Keys an:

git@server:~$ mkdir .ssh
git@server:~$ touch .ssh/authorized_keys
git@server:~$ chmod 600 .ssh/authorized_keys

Als nächstes kopiert man den eigenen Public-Key auf den Server. Ich benutze dazu immer das kleine Tool ssh-copy-id, man kann es natürlich auch manuell machen, da das authorized_keys-File nur eine Textdatei ist. Den eigenen Public-Key findet man normalerweise im eigenen home-Verzeichnis im Ordner “.shh“. Er trägt den Namen “id_rsa.pub”

user@host:/home/user$ ssh-copy-id -i $PFAD-ZUM-.SSH-VERZEICHNIS/id_rsa.pub git@$IP-DES-SERVERS

Obigen Befehl führt man auf dem eigenen Rechner aus und nicht auf dem Server.
Hat man noch keinen Public-Key kann man sich einen mit ssh-keygen generieren (Manpage lesen).
Leeres Git-Repository erstellen: Jetzt können wir auf dem Server eine leeres git-Repository erstellen:

git@server:~$ mkdir testrepo.git
git@server:~$ cd testrepo.git
git@server:~$ git --bare init

Folgende Meldung sollte erscheinen:

Initialized empty Git repository in /home/git/testrepo.git

Erster Commit: So auf dem Server sind wir jetzt fast fertig. Vor der letzten Änderung auf dem Server testen wir noch, ob alles wie gewünscht funktioniert, indem wir einen ersten commit in das Repository machen. Auf dem eigenen Rechner:

user@host:~$ git clone ssh://git@$IP-ADRESSE/~/testrepo.git
Initialized empty Git repository in /home/user/testrepo/.git/
warning: You appear to have cloned an empty repository.

Für diese Anleitung erstelle ich jetzt einfach eine kleine Textdatei und commite diese und pushe die Änderungen dann auf den Server:

user@home:~/testrepo$ echo "Das wird der erste Commit" > testdatei
user@home:~/testrepo$ git add testdatei
user@home:~/testrepo$ git commit -am "Erster Commit"
[master (root-commit) c6b03a5] Erster Commit
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 testdatei
user@home:~/testrepo$ git push origin master
Counting objects: 3, done.
Writing objects: 100% (3/3), 243 bytes, done.
Total 3 (delta 0), reused 0 (delta 0)
To ssh://git@$IP-ADRESSE/~/testrepo.git
* [new branch] master -> master

So damit läuft der Server
Jeder, der Zugriff auf das Repo habe will, muss euch jetzt sein Public-Key zuschicken, damit ihr ihn an das authorized_keys-File anhängen könnt.
Login-Shell des git-Users deaktivieren: Damit das nicht Missbraucht wird, verhindern wir jetzt noch, dass man über den git-User auf dem Server eine Login-Shell bekommt. Hierzu loggt man sich als root auf dem Server ein und öffnet die /etc/passwd:

root@server:~# vi /etc/passwd

Dort ändern wir die Shell des git-Users von /bin/bash auf /usr/bin/git-shell:

git:x:1001:1001:,,,:/home/git:/bin/bash

wird zu:

git:x:1001:1001:,,,:/home/git:/usr/bin/git-shell

Versucht man sich mit dem git-User per ssh einzuloggen erscheint folgende

Meldung: "fatal: What do you think I am? A shell?"

Ob man anstatt der git-shell auch wie üblich einfach /bin/false verwenden kann habe ich nicht ausprobiert.

Obwohl jeder, der Zugriff auf des Repository hat, über den git-User auf den Server geht, sind die Commits übrigens nicht immer vom gleichen User, sondern werden wie gewohnt durch die user-option von git festgelegt. Diese Optionen kann man global durch eine Datei mit dem Namen “.gitconfig” im eigenen Home-Verzeichnis ferstlegen. Mehr dazu hier.

Ja und jetzt kann man anfangen mit Git zu arbeiten! Man wird nie wieder SVN, CVS oder ähnliches verwenden wollen! Git ist toll! Siehe auch “Warum git besser als X ist”

Meine Quellen: Pro-Git Kapitel 4 und Bradley Wrigths Blogpost

Im speziellen ging es um die Ersetzung von Links auf den alten Webspace in den Beiträgen und noch ein paar andere kleinere Änderungen.

Fügt man in Wordpress ein Bild ein, wir der Pfad nicht relativ zum Webspace sondern absolut gespeichert, also mit kompletter URL. Zieht man mit dem Blog über den Lauf der Jahre mehrfach um (so wie ich) und ändert evtl. noch die Domain des Blogs, entstehen so einige Karteileichen.

Hier mal ne kleine Anleitung, wie man die ungültigen Links auf die aktuelle Adresse umbiegt:

1. Als erstes erstellt man ein Backup – das ist wirklich sehr wichtig! Ich benutze dazu immer mysqldump Damit kann man den kompletten Inhalt einer Datenbank einfach in eine Datei “dumpen”:
   shell> mysqldump --all-databases -u$USER -p$PASSWORT > dump.sql
   Geht anschließend etwas schief, hat man ein Backup und kann darauf zurückgreifen. Das Backup kann man mit:
   shell> mysql < dump.sql
   wieder einspielen. Hat man beim Erstellen des Dumps eine spezielle Datenbank ausgewählt sollte man:
   shell> mysql $DB-NAME < dump.sql
   verwenden.
2. Jetzt die eigentliche Aufgabe, suchen und ersetzen: Hier zu setzt man ein Konstrukt aus dem UPDATE und REPLACE Befehl ein, führt man hintereinander mehrere Ersetzungen durch ist der Feldname in der REPLACE-Funktion besonders tückisch, da man leicht vergisst ihn mitzuändern:
   mysql> UPDATE [table_name] SET [field_name] = REPLACE([field_name],'[string_to_find]','[string_to_replace]');
3. Im Vorfeld sollte man natürlich auch per SELECT schauen, wie viele Datensätze man überhaupt ändern muss. Hier für ist LIKE ganz praktisch:
   mysql> SELECT * FROM [table_name] WHERE [field_name] like "%SUCHTEXT%";
4. Das war’s!
5. Kleiner Hinweise noch: Ich lösche immer noch die bash_history, wenn ich das mysql-Passwort per Befehl mitgebe. Man weiß ja nie…

Am leichtesten geht es mit dem kleinen Tool pdftk, welches man sich aus den Repositories installieren kann:
~$ sudo aptitude install pdftk
Anschließend kann man einfach mit:
~$ pdftk datei1.pdf datei2.pdf datei3.pdf cat output out.pdf
die pdf-Dateien zusammenführen.

Es gibt noch eine etwas kompliziertere Variante mit Ghostscript, welche den Job genauso souverän erledigt, aber schlechter zu merken ist:
~$ gs -dNOPAUSE -sDEVICE=pdfwrite -sOUTPUTFILE=out.pdf -dBATCH datei1.pdf datei2.pdf

Beide Versionen funktionieren bei mir sehr gut! Anstatt alle Inputfiles einzeln anzugeben, kann man auch mit *.pdf arbeiten. Hierzu müssen sich die Files aber alle in einem Verzeichnis befinden.

Quellen: klick und klick

cvlc --oss-audio-device=/dev/dsp *.pls

Da ich in letzter Zeit immer häufiger den altgedienten mplayer verwende, musste ich mal nachschauen und bin hier fündig geworden. Der Befehl für den mplayer lautet:

mplayer -ao oss:/dev/dsp *.mp3

Ist ganz praktisch, so kann man im Hintergrund Musik spielen lassen und z.B. über das Headset noch skypen etc.!

Update: Per Mail kam der Hinweis auf die Antiquiertheit des Open Sound Systems: Der Grund warum ich OSS verwende ist folgender:
Ich habe momentan zwei Soundkarten im PC. Über die erste Soundkarte lasse ich meistens Musik über normale Lautsprecher laufen. Deshalb starte ich den Mplayer oder vlc im OSS-Mode. Über die zweite Soundkarte ist mein Headset angeschlossen, hierüber läuft dann der ganze Rest mit Pulseaudio, also Skypen, irgendwelche Videos die man sich anschaut usw. Hat den Vorteil, dass man die Lautstärke getrennt voneinander regeln kann und kurz mal eines von beidem ausschalten.