linux

das bibliographische institut ist ja dafür bekannt nicht gerade liebevollen umgang mit libre- bzw openoffice zu pflegen.

unter windows 7 scheint das problem diesmal allerdings am java framework zu liegen, zumindest an der jre7.
bei der installation der duden rechtschreibprüfung friert libreoffice 3.3.x / 3.4.x ein und nach einer weile kommt die bekannte windows 7 meldung "das programm funktioniert nicht mehr" – der task wird somit abgeschossen.
auf meinen systemen war allerdings die java runtime 7 installiert, welche wohl noch zu neu ist, ein downgrade auf jre6 brachte die lösung und ich konnte die extension sauber installieren.
download der jre6 (aktuell: update 27) unter: https://www.java.com/de/download/manual.jsp

 

unter ubuntu 11.04 war eine installation im ersten moment auch nicht möglich, angeblich sei die version nicht kompatibel.
das nachinstallieren von fehlenden packeten brachte hier die lösung – für libreoffice 3.3.x, für version 3.4.x wird das dev libstlport packet benötigt (fehler: loading component library failed).
an dieser stelle sei auch bemerkt das die aktuelle version des korrektors wieder nicht 64-bit kompatibel ist, zumindest unter linux, dies erfährt man übrigends erst nach dem kauf in der begelegten LIESMICH.txt. explizit erwähnt wird dies nicht, man merkt es nur daran das 64-bit linux keine erwähnung findet.
 

sudo -s apt-get install libreoffice libreoffice-l10n-de libreoffice-base libreoffice-common libreoffice-gnome \
libreoffice-gtk libreoffice-java-common libstlport5.2-dev

 

sollte dies dennoch nicht ausreichen, meine installation enthält auch noch einige extensions, weiß der geier …
 

sudo -s apt-get install libreoffice libreoffice-l10n-de libreoffice-base libreoffice-common \
libreoffice-style-crystal libreoffice-wiki-publisher libreoffice-filter-mobiledev libreoffice-ogltrans \
libreoffice-pdfimport libreoffice-presentation-minimizer libreoffice-report-builder openclipart-libreoffice \
libreoffice-gnome libreoffice-gtk libreoffice-java-common libstlport5.2-dev

bei fail2ban 0.8.4 (und früher?) kann es auf multicore systemen zu race condition problemen beim start kommen und somit wird nur ein teil der iptable-chains erstellt – wenn überhaupt.

auszug /var/log/fail2ban.log:

 

iptables -I INPUT -p tcp -m multiport –dports 22 -j fail2ban-ssh-ddos returned 400
iptables -I INPUT -p tcp -m multiport –dports 22 -j fail2ban-ssh-ddos returned 200

 

mit dem release der 0.8.5 stable gehört dieses problem vermutlich der vergangenheit an, dieses wurde allerdings noch nicht im stable repo von debian freigegeben.

die jetzt benötigte lösung fand sich auf der debian bug list: Michael Saavedra hat auf sourceforge einen patch veröffentlicht.

zum einspielen des patches die datei action_executeCmd_locking-1.diff herunterladen und mit dem folgenden befehl einspielen:

 

patch -b /usr/share/fail2ban/server/action.py action_executeCmd_locking-1.diff

 

mit der option -b wird ein backup der datei erstellt, falls es zu problemen kommt, zu finden unter /usr/share/fail2ban/server/action.py.orig
 

ein kleines script um eine per pear installierte horde installation wieder zu entfernen, nicht hübsch und geht sicher auch besser, aber es erfüllt seinen zweck.
hintergrund für dieses script war ein kleiner test mit horde, allerdings wird bei der installation per pear mehr als nur eine handvoll packete installiert, die deinstallation ist somit etwas aufwendiger – wenn man jedes einzelnes packet von hand deinstallieren will.

merke: es werden nur die pear horde packete entfernt – NICHTS ANDERES! überbleibsel in wie verzeichnisse und apache oder lighttpd module sind darin nicht enthalten! Continue Reading

wie immer läuft nicht alles so rund bei uh-buntu.
die atheros chipsätze machen aktuell etwas probleme, bei mir war es ein drastischer packetverlust (ping hatte >40% packet loss im lan und wan) und die daraus resultierenden geschwindigkeits- und verbindungsprobleme, sobald ich ein paar meter vom wlan router entfernt war.

eine kleine änderung des entsprechenden kernel modules brachte eine deutliche besserung:

sudo -s echo "options ath9k nohwcrypt=1" > /etc/modprobe.d/ath9k.conf

 

bzw. für ath5k chipsätze:

sudo -s echo "options ath5k nohwcrypt=1" > /etc/modprobe.d/ath5k.conf

 

ein anschliessender reboot des systems (bzw. neu laden des modules) rundet das ganze nun ab.
durch diese änderung wird die hardware crypt schnittstelle des chipsatzes umgangen.
das problem tritt wohl nur in bestimmten konstellationen auf, z.b. bei wpa2 in verbindung mit einem IEEE 802.11n (draft-n) router.

an anderer stelle wurde empfohlen den aktuellen kernel 2.6.38(-8) durch das 2.6.39 release des ubuntu teams zu ersetzen, da die rumspielerei mit dem kernel evtl. wieder ein anderes problem mit sich bringt, habe ich darauf verzichtet, wer es trotzdem probieren will:

sudo add-apt-repository ppa:kernel-ppa/ppa
sudo apt-get update; sudo apt-get dist-upgrade