Entries Tagged as 'Werkzeuge'

Missing locales on remote system

Since this is now the third time I ran into this issue and it always mislead me in a completely wrong direction, I’ll finally document it.

So, you are SSH-ing into a remote system (typically Debian or a derivative), then you you install a package or do something else that triggers some access to the locales (UNIX style localization for shell commands etc.) and you see messages similar like this:

perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LC_TIME = "de_CH.UTF-8",
LC_MONETARY = "de_CH.UTF-8",
LC_ADDRESS = "de_CH.UTF-8",
LC_TELEPHONE = "de_CH.UTF-8",
LC_NAME = "de_CH.UTF-8",
LC_MEASUREMENT = "de_CH.UTF-8",
LC_IDENTIFICATION = "de_CH.UTF-8",
LC_NUMERIC = "de_CH.UTF-8",
LC_PAPER = "de_CH.UTF-8",
LANG = "en_US.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
locale: Cannot set LC_ALL to default locale: No such file or directory

You might assume that you did not install all the required locales. In the example above I saw these settings of de_CH.UTF-8 on an english only system. So you could generate/install the missing languages i.e. with „dpkg-reconfigure locales„. But note the mentions of „(unset)“ above. Even with all the required locales you still will see these messages.

So, what is the cause of this mess? Nothing is wrong with your server. The actual culprit is a misconfiguration on the host you are running the SSH session from. It has these settings and newer SSH clients provide the comfort functions of exposing your local locale settings to the remote system.

In an ideal scenario this allows you to talk to your server in your native language. Unfortunately some newer linux distributions like Ubuntu starting from 12.04 (it has also been reported on MacOS X) don’t set all of these variables leading to these warnings on system that want these to be set.

TL;DR: The quick solution is to comment the setting in your /etc/ssh/ssh_config file that causes the exposure of these environment variables to your server:

# SendEnv LANG LC_*

Pakete verwalten mit aptitude auf Debian-basierten Systemen

Ein Freund hat mich vor Kurzem um Rat gefragt, da er eine Installation eines Ubuntu-Ablegers für ein Resourcen-armes System zurechtstutzen wollte und ihm dabei die Abhängigkeiten der Pakete in den Weg kamen. Ich arbeite meist mit aptitude auf Debian-basierten Systemen, komme daher mit diesem Werkzeug am besten zurecht um solche Abhängigkeits-Probleme zu lösen und habe ihm einige Tips dazu gesendet: [Read more →]

Debian on the SGI O2

Yet another post on the net about installing Debian on the SGI O2. Mine is a bit on the lower end, it runs with only 64 MiB RAM on an R5000 CPU. I’m still pretty amazed by the EFI-like BIOS with mouse support. That is pretty advanced for a machine from 1996!

But back to topic: Most tutorials and tips about installing Debian on an O2 that you find online are a bit dated by now. Also, most of those sites link to a tutorial by Jiann-Ming Su, which is offline by now. Thanks to the Internet Archives WayBackMachine I was still able to retrieve it:

Installing Debian on SGI O2 by Jiann-Ming Su

Thank you, Su, Martin, Jon and all those other friendly folks for your documentations!

Convert a UNIX timestamp into a date

Was just googling for a fast way to convert a timestamp into a date without having to leave the shell (yes, I’m lazy 😉 ) and thanks to Anton found some solutions:
clipped from anton.lr2.com

BASH: Convert Unix Timestamp to a Date

Awk has a wrapper for the standard C strftime function:
echo $EPOCH|awk ‘{print strftime(”%c”,$1)}’
[UPDATE]
# date -d @1000000042
Sun Sep  9 01:47:22 GMT 2001
But this only works on newer versions of date.  It fails on my FC2 server and my Debian Sarge machine, but works fine on Ubuntu Feisty and Debian Etch.

Printing dd status

clipped from prefetch.net
The dd utility doesn’t report status information by default, but when fed a SIGUSR1 signal it will dump the status of the current operation:
$ dd if=/dev/zero of=/dev/hda1 bs=512 &
$ kill -SIGUSR1 1749
1038465+0 records in
1038465+0 records out
531694080 bytes (532 MB) copied, 11.6338 seconds, 45.7 MB/s

RRDs are architecture dependent

When migrating our old monitoring server (x86), running munin and smokeping, to our new virtualized platform (x86_64), I ran into a problem. After copying the RRD-files to the new system I did not get nice graphs, but instead the error message „This RRD was created on another architecture“ in the logs. After searching around in the ’net I found the solution in a forum post which worked for me:
clipped from rrd-mailinglists.937164.n2.nabble.com

How do I move my rrds to my new MRTG system.

I dont know if rrdtool has a option for doing it recursivly,

but something like this should do it if the filenames stay the same:
for i in *.rrd; do rrdtool dump $i > `basename $i .rrd`.xml; done
for i in *.xml; do rrdtool restore $i `basename $i .xml`.rrd; done
HTH
Matthias.Merk

Less is more: the hidden treasure of less command

Wow, I just stumbled over less‘ PDF display capability and found this blog post with even more awsome features of less:
clipped from www.cyberciti.biz

Less is more: the hidden treasure of less command
# less +53 /etc/httpd/httpd.conf
Ok let us display an error at line number 53 (no need to scroll down all 52 lines)
Search and highlight particular text:
# less "+/*VirtualHost" /etc/httpd/httpd.conf
lessfile and lesspipe are programs that can be used to modify the way the contents of a file are displayed in less. What this means is that less can automatically open up tar files, uncompress gzipped files, and even display something reasonable for graphics files.
less command supports following extensions:

  • *.arj

  • *.tar.bz2

  • *.bz

  • *.deb, *.udeb

  • *.bz2

  • *.doc

  • *.gif, *.jpeg, *.jpg, *.pcd, *.png, *.tga, *.tiff, *.tif

  • *.lha, *.lzh

  • *.iso, *.raw, *.bin

  • *.pdf

  • *.rar, *.r[0-9][0-9]

  • *.rpm

  • *.tar.gz, *.tgz, *.tar.z, *.tar.dz

  • *.gz, *.z, *.dz

  • *.tar

  • *.jar, *.war, *.xpi, *.zip

  • *.zoo
Watch a log file
Watch maillog in real time, useful to troubleshoot mail server problem
less +F /var/log/maillog
less +F /var/log/message
You can also use tail command:
tail -f /var/log/maillog

Installierte Debian Pakete auf einen neuen Rechner übertragen

sudo dpkg --get-selections "*" > datei.txt
sudo dpkg --set-selections < datei.txt
sudo apt-get -u deselect-upgrade

Bilder rasch und schnell mit imagemagick verkleinern

clipped from snippets.aktagon.com

for image in *.jpg; do convert $image -resize 800x600 800x600-$image; done

Eclipse 3.2 Setup unter Ubuntu

Leider ist im Ubuntu Stable (derzeit 8.04.1 Hardy Heron) Repository immer noch nur die Version 3.2 von Eclipse abgelegt. Da ich in letzter Zeit öfters Eclipse auf neuen Maschinen im Geschäft oder Privat auf der genannten Plattform installieren musste, möchte ich die wichtigen Punkte mal rasch für mich notieren. Ziel ist es Eclipse mit Subversion- und PHP-Plugin einzurichten.

Ein gutes Tutorial zur Eclipse-Installation findet sich in der Wiki des Deutschen Ubuntu Forums. Hier die nötigen Schritte für die eigentliche Eclipse Installation:

  1. Über den Paketmanager Deiner Wahl folgende Pakete installieren: eclipse („), eclipse-nls (Sprachpakete), sun-java6-jre (gewisse Plugins machen Zicken mit dem GNU Java), sowie optional auch subversion (falls man mal etwas von Hand im SVN machen muss).
  2. Damit auch Sun Java verwendet wird, muss man noch folgenden Befehl ausführen:
    sudo update-alternatives --config java

    und Sun’s Java auswählen.

  3. Zudem muss man noch in Eclipse die Prioritäten-Liste der Java-Umgebungen aktualisieren, so dass Sun’s Java an erster Stelle steht. Diese Datei hört auf den Namen „/ etc/eclipse/java_home“. Weitere Details dazu finden sich auf der Originalen englischen Ubuntu Wiki.

Die Plugins werden in Eclipse über einen Assistenten installiert der über das Menü „Hilfe > Software-Updates > Suchen und installieren“ gestartet wird. Man muss dort lediglich die unten stehenden URLs eintragen und die gewünschten Funktionen auswählen. Für die beiden Plugins gilt folgendes:

  1. Subversion Synchronisierung nutzen wir über das Subversive Plugin. Für Eclipse 3.2 muss aber eine alte Version (1.1) genutzt werden. Diese findet man über die „alte“ Polarion Webseite, die Plugin-URL lautet „http://www.polarion.org/projects/subversive/download/1.1/update-site/“. Die beiden benötigten Funktionen heissen „SVN Team Provider“ und „SVNKit 1.1.4 Implementation“. Die „Java SVN Implementation“ unterstützt leider nur SVN 1.3. Alle unsere Server (auf Debian Etch) sind aber bereits Version 1.4 und machen mit dem älteren Plugin einige Schwierigkeiten.
    Subversion Synchronisierung nutzen wir über das Subclipse Plugin. Für Eclipse 3.2 muss Version 1.4 genutzt werden. Diese findet man über die Tigris Webseite, die Plugin-URL lautet „http://subclipse.tigris.org/update_1.4.x“. Die benötigten Funktionen heissen „Subclipse – Required“, „Subversion Client Adapter – Required“, „SVNKit Client Adapter“ und „SVNKit Library“.
    Da wir keine Windows-Plattform nutzen müssen wir dem neuen Plugin noch mitteilen, dass es die SVNKit Bibliothek nutzen soll. Dies geschieht über das Menü „Fenster > Benutzervorgaben“ und dort unter „Team > SVN“ im Reiter „SVN Client“. Im Dropdown „SVN Client“ „SVN interface“ muss die oben installierte Bibliothek ausgewählt werden.
  2. Die korrekte Version von PHPeclipse für Eclipse 3.2 ist unter der Plugin-URL „http://update.phpeclipse.net/update/archives“ zu finden. Installiert werden muss nur die Funktion „PHPeclipse“. Die beiden anderen Funktionen stehen für spezielle Webserver mit Debug-Ausgabe. Damit die PHP-„Rechtschreibkorrektur“ (Syntax-Prüfung) funktioniert, sollte man auf dem Entwicklungsrechner ebenfalls PHP installieren.

Und nun viel Spass beim Versionieren und bei der Arbeit in einer professionellen PHP-IDE.

Update vom 15. März 2009:
Aufgrund eines Updates unserer SVN-Server ist das Subversive-Plugin nicht mehr kompatibel mit diesen. Daher mussten wir auf Subclipse umsteigen, von dem noch eine kompatible Version für Eclipse 3.2 existiert. Die Doku wurde entsprechend angepasst.