Kategoriearchiv: Linux

Alles rund um die Pinguine – auf dem Desktop und dem Server

Bildschrumpfede

Hier hab ich ein Skript für imagemagick gefunden, das ein Bild so lange in den Abmessungen schrumpft, bis es eine bestimmte Größe in KB hat. Ich brauch aber meistens keine Größenanpassungen, sondern lediglich eine „Gewichtsreduktion“ schon in den Abmessungen angepasster Bilder.

Ein Script für die Anpassung der Größe einer einzelnen Datei, ohne die Abmessungen anzufassen, könnte so aussehen:

#!/bin/bash
if [ $# -ne 2 ]
then
echo -e „\nusage:  $0 <file size limit> <image>\n“
exit
fi
IMAGE_FORMAT=jpg
FILE_SIZE_LIMIT=$1
IMAGE_IN=$2
BASENAME=`echo ${IMAGE_IN} | cut -d‘.‘ -f-1 `
IMAGE_OUT=${BASENAME}.smaller.jpg
FILE_SIZE=`ls -sk $IMAGE_IN | cut -d‘ ‚ -f1`
if [ $FILE_SIZE -ge $FILE_SIZE_LIMIT ]
then
echo „reducing $IMAGE_IN from: $FILE_SIZE KB to $1 KB“
SIZE=`identify $IMAGE_IN | cut -d‘ ‚ -f7`
S=`echo $SIZE`
echo „SIZE: ${S}“
QUAL=100
while [ $FILE_SIZE -ge $FILE_SIZE_LIMIT ]
do
let QUAL=QUAL-1
echo „Current quality: ${QUAL}“
convert $IMAGE_IN -quality ${QUAL} $IMAGE_OUT
FILE_SIZE=`ls -sk $IMAGE_OUT | cut -d‘ ‚ -f1`
echo „Current filesize: $FILE_SIZE KB“
done
mv $IMAGE_OUT ${BASENAME}.${QUAL}.${IMAGE_FORMAT}
fi

Den obigen Codeschnipsel für eigene Versuche und Anpassungen in eine Textdatei einfügen (nennen wir sie filesize.sh) und diese ausführbar machen.

./filesize.sh 100 bild.jpg

macht dann bild.jpg 100kb groß und speichert das Ergebnis in der Datei

bild.qualitätsstufenangabe.jpg

Oft muss man aber gleich ganze Ordner bearbeiten – was mit dem Script oben auch ginge:

find /pfad/zum/ordner -iname „*.jpg“ -exec filesize.sh 100 {} \;

Meist ist das aber doch viel zu dick aufgetragen, denn ohne Script geht das schnell mal so:

for i in `ls *.jpg`; do convert -quality 80 $i conv_$i; done

Dann schau man sich das Ergebnis an

ls -l conv*.jpg

und schreibt, sollte es nicht passen, halt eine niedrigere Zahl hinter -quality, nachdem man den ersten Durchgang mit

rm conv*.jpg

gelöscht hat. So lange bis es passt. Schnell und dreckig.

Nachdem die Zeilen einmal eingegeben sind, stecken die in der History der Bash und können mit den Cursortasten nach Oben zügig aufgerufen oder noch Tage später mit [Strg] [R] gesucht und gefunden werden.

OOo 3.1 Bug in Hardy 64

Wenn ich ein Word DOC mit Tabellen in OOo 3.1 unter Ubuntu Hardy 64 öffne, dann sind zwar die Texte noch da – aber die Tabellen selbst sind nicht zu sehen:

screenshot_0031

Eine Lösung für dieses Problem existiert – und das ArchLinux Forum brachte mich auf die richtige Spur. Wie grey hier richtig anmerkt, ist es ausreichend, die Tabelle über den Navigator zu bearbeiten, um diese wieder zu sehen.

bildschirmfoto-2

Also der Reihe nach:

  1. Navigator öffnen;
  2. Eintrag „Tabellen“ öffnen;
  3. Rechtsklick auf „Tabelle 1“;
  4. Im Kontextmenü zu „Tabelle“ und dort zu „Bearbeiten“;

screenshot_004

Hier im Reiter „Tabelle“ die Breite verändern und OK klicken.

screenshot_005

Schwupps – ist die Tabelle wieder da.

Ich hab nun keine Ahnung, ob das unter anderen Distris oder Windows auch so ist. Anyway: Hoffentlich wird das bald gefixt.

Shalla Memo

Da ich heute bei Uli einen IPCop aufsetzen muss, setz ich kurz meine Einstellungen hier rein – als Memo für die Konfiguration der Shalla Blacklist. Ich kann mir die Zusammenhänge zwischen manchen Kategoriennamen und deren Wirkung einfach nicht richtig merken.

Ältere IPCop Installationen verwenden evtl. noch andere Bezeichnungen. Da der Updatemechanismus die nicht mehr gepflegten Kategorien wohl nicht (immer?) selbst entfernt, muss hier gelegentlich von Hand nachgeholfen werden. Gespeichert werden die Einträge auf dem Cop hier:

/var/ipcop/urlfilter/blacklists

In der Datei global_usage ist jeweils eine kurze Beschreibung der Kategorien zu finden.

Zuerst auf dem Weboberfläche des Cops die Häkchen bei der entsprechenden Kategorie entfernen und [Speichern und Neustart] anklicken. Dann im oben genannten Verzeichnis als root mit

rm -r kategorienname/

die entsprechenden Unterverzeichnisse und deren Inhalte entfernen und die URL Filter Seite im Anschluss im Cop neu laden. Die Kategorie sollte dann verschwunden sein. Wer aus Versehen zu viel gelöscht hat führt ein Update der Filterliste durch, was dazu führt, dass die aus Versehen gelöschten Verzeichnisse wieder angelegt werden.

Alle Einträge, die auf der Weboberfläche vorgenommen werden, scheinen in die folgenden Dateien geschrieben zu werden:

/var/ipcop/urlfilter/settings
/var/ipcop/urlfilter/squidGuard.conf

Zwecks ‚em Überblick hier mal meine Einstellungen:

screenshot_003

mount

… und noch eine Spielerei als Gedächtnisstütze zum Thema mount und /etc/fstab.

LRFS

Bastelphase mit XMind zum Linux Root File System.

Meinen Anfängerstatus merk ich immer daran, dass mir die Logik bei der Unterteilung in /bin, /sbin und /usr nicht immer so klar ist. Unterscheidungen nach essential und non-essential scheinen eben gewachsen und nicht entworfen worden zu sein.

public key für scp only Nutzer

Auf unserem Root sind mehrere Nutzer angelegt, die sich nur über scp anmelden können. Damit dies auch im public key Verfahren inklusive Passwort für den Key und dann auch noch mit gFTP funktioniert, müssen die folgenden Schritte durchlaufen werden.

Zuerst einen neuen Schlüssel für den Nutzer erzeugen, was auch lokal auf dem Client geschehen kann. Dabei einen gesonderten Namen für den Key angeben, damit dieser nicht in id_dsa landet (im Beispiel unten ist dies /home/dirk/.ssh/scpnutzer_dsa):

dirk@lokal:~$ ssh-keygen -t dsa
Generating public/private dsa key pair.
Enter file in which to save the key (/home/dirk/.ssh/id_dsa): /home/dirk/.ssh/scpnutzer_dsa
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/dirk/.ssh/scpnutzer_dsa.
Your public key has been saved in /home/dirk/.ssh/scpnutzer_dsa.pub.
The key fingerprint is:
1a:7a:19:9d:86:fc:01:34:ad:c5:94:13:81:8f:76:c6 dirk@lokal

Diesen dann mit scp auf den Server schieben – und zwar von einem Account aus, der auch über SSH auf den Server darf (ist ja klar):

scp scpnutzer_dsa.pub dirk@www.server.de:/home/scpnutzer/.ssh/

Auf dem Server den gerade hochgeladenen public key im Verzeichnis .ssh in die Datei authorized_keys integrieren:

cat scpnutzer_dsa.pub >> authorized_keys

Jetzt die Nutzung von gFTP (sofern gewünscht) vorbereiten. Da gFTP nicht selbst mit public keys umgehen kann (soweit ich weiß), den key zuerst „laden“ mit Hilfe von ssh-add:

dirk@lokal:~/.ssh$ ssh-add /home/dirk/.ssh/scpnutzer_dsa
Enter passphrase for /home/dirk/.ssh/scpnutzer_dsa:
Identity added: /home/dirk/.ssh/scpnutzer_dsa (/home/dirk/.ssh/scpnutzer_dsa)

Ob alles funktioniert hat ist nach Eingabe von

dirk@loakl:~/.ssh$ ssh-add -l

zu sehen. Eine Liste der von ssh-add verwalteten Keys wird ausgegeben.

In gFTP selbst nun zuerst zu /FTP /Optionen /Netz und hier als „Voreingestelltes Protokoll“ den Eintrag SSH2 wählen. Dann in gFTP unter /FTP /Optionen /SSH und dort den Haken bei „Benötige SSH Nutzername/Passwort“ entfernen.

Der Zugriff mit gFTP sollte nun funktionieren. Wenn nicht, dann hilft eine Analyse mit Hilfe von scp und dem Schalter -v im Terminal – das gFTP Log selbst gibt meist wenig Brauchbares aus.

Die Dateien scpnutzer_dsa.pub und scpnutzer_dsa – wenn alles funktioniert – an den SCP Nutzer weitergeben (und dabei einschärfen, dass diese Dateien nicht verloren gehen dürfen). Nicht vergessen das Kennwort mitzuteilen 🙂

Quelle und weitere Informationen (vor allem zum Setup von SSH über public key auf dem Server selbst): http://wiki.ubuntuusers.de/SSH