eklenet

Da ich für einen Freund dieses Rezept niederschreiben musste, dachte ich kann ich es auch gleich hier rein stellen. Ist quasi eine eingedeutschte Carbonara, ohne Ei.

1. ca. 50-100g fein gewürfelter Speck mit Oliven-Öl und nach belieben (0-2) zerdrückten Knoblauchzehen, anbraten
2. vom Feuer nehmen und warten bis es nicht mehr kocht
3. ein Becher Sahne (eventuell auch anteilig mit Milch, wenn euch die Sahne zu ungesund ist) dazu leeren
4. wieder zum köcheln bringen
5. 50-100g, jungen Parmesan langsam direkt in die Soße reiben, während sie köchelt
6. eine Priese Pfeffer zugeben
7. mit etwas Salz abschmecken (Achtung: nur wenig, da der Speck bereits sehr salzig ist)
8. fertig

Mit Spagetti und als Verzierung frischen Basilikum-blättern servieren.

Wenn die Soße zu dick wird, oder man mehr braucht, einfach mehr Milch rein leeren.

Da mich Ubuntu-oneiric bei jedem Boot mit der Frage nach der PIN für die UMTS-Karte nervt, hab ich selbige einfach deaktiviert. Den Bug gabs auch schon frühr ab und an. Vielleicht schaffen sie es ja ihn bis 12.04 zu beheben.

Als root einfach folgende Befehle ausführen fertig. 1234 durch die PIN ersetzen und das Device anpassen. Dabei verliert man nur kurz die Netzwerk-Verbindung.

apt-get install gsm-utils
service network-manager stop
gsmctl -d /dev/ttyACM0 -o unlock sc all 1234
service network-manager start

Linux noch schneller machen, wenn man schon eine SSD hat ? Ja das geht !

Als erstes sollte man trim aktivieren und nicht bei jedem Zugriff auf eine Datei einen Zeitstempel dafür setzen lassen. Geht ganz einfach in der fstab indem man die mount Optionen discard,nodiratime,noatime für die entsprechenden Partitionen hinzufügt. Es sei denn man hat eine Anwendung wo die Access-Times braucht.

Dann kann man noch /tmp in den RAM verlagern, sollte man ja heute genug haben:

tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0

Den Scheduler kann man auch noch von cfq wechseln, zu einem der besser zur SSD passt, z.B. deadline. Es gibt zwar einen schönere Weg, aber am einfachsten geht es, wenn man einfach in die Datei /etc/rc.local die folgenden zwei Zeilen packt. Man könnte das aber auch irgendwie grub bei bringen, um den Kernel gleich damit zu booten.

echo deadline > /sys/block/sda/queue/scheduler
echo 1 > /sys/block/sda/queue/iosched/fifo_batch

fifo_batch reduziert die Disk-seek-queue, da SSD ja bei random Zugriffen ziemlich schnell sind.

Also rein Subjektiv ist mein System damit noch einen Tick schneller, nachgemessen hab ich das natürlich nicht

Gemacht hab ich das ganze auf einem Kubuntu 11.11

kein Problem, auch wenn er Iceweasel heißt:

echo "deb http://backports.debian.org/debian-backports squeeze-backports main" > /etc/apt/sources.list.d/iceweasel
.list
echo "deb http://mozilla.debian.net/ squeeze-backports iceweasel-release" >> /etc/apt/sources.list.d/iceweasel
.list
gpg --keyserver keys.gnupg.net --recv-key 06C4AE2A
gpg -a --export 06C4AE2A | apt-key add -
apt-get update
apt-get install -t squeeze-backports iceweasel

Mit linux-vserver hatte man früher ab und an Probleme mit dem Loopback-Interface. Es wurde einfach an den Vserver vom Host weitergereicht, und nur unter den Vservern isoliert.

Wenn man also auf dem Host einen Port des lo verwendete, war der auch auf allen Vserver belegt. Mitlerweile gibts unter Debian Squeeze abhilfe:

Jede VM kann nun ihr eigenes lo beklommen mit einem einfachen flag:

echo LBACK_REMAP >> nflags
im config Ordner der VM (/etc/vservers/abcdef/) 
VM neu-starten Fertig!

Ein Debian RootFS für einen ARM-Rechner oder Board zu erstellen ist gar nicht schwer, denn debootstrap läuft mit ein paar Tricks auch Cross-Plattform. So kann man bequem auf einem X86 oder AMD64 Rechner (oder wahrscheinlich auch mit was ganz anderem, solange nur eine DEB-basierende Distribution bereits drauf läuft) ein komplettes RootFS erstellen.

Als erstes braucht man ein paar Tools die aber schnell installiert sind:

 apt-get install binfmt-support qemu qemu-user-static debootstrap

und schon kanns los gehen.

mkdir ./newrootfs 
/usr/sbin/debootstrap --arch armel --foreign squeeze ./newrootfs http://ftp.de.debian.org/debian 

Das ganze erstellt ein relativ großes RootFS mit vielen Tools drin. Wer ein Basis-RootFS ohne alles will, erreicht das mit dem zusätzlichen Parameter --variant=minbase , aber da fehlt dann wirklich alles, außer apt und bash, selbst so grundlegende Tools wie ifconfig, müsst ihr dann manuell im chroot nachinstallieren.

So, nun kommt der interessante Teil, der aber relativ simpel ist, nämlich das RootFS zu konfigurieren. Dazu kopiert man sich qemu für arm in das RootFS:

cp /usr/bin/qemu-arm-static ./newrootfs/usr/bin/ 

Und oh wunder, man kann einen ganz normalen chroot in das RootFS machen, trotz anderer Architektur! Nun können wir debootstrap seine Arbeit vollenden lassen:

chroot ./newrootfs /debootstrap/debootstrap --second-stage 

Und fertig ist das RootFS. Mit chroot kann man jetzt das RootFS noch nach seinen Wünschen anpassen und fertig !

Nein hier geht es nicht darum, wie man ein Backup von einem MySQL-Server macht

Vor kurzem hatte ich das Problem, das ein MySQL-Server sporadisch nicht mehr zu erreichen war. Der Fehler auf auf Client-Seite war: "Lost connection to MySQL server at 'reading authorization packet', system error" und auf Server-Seite: "unauthenticated user"

Der erste Verdacht war natürlich max_connection, doch nein, alles im grünen Bereich. Ist der Server ausgelastet ? Nein, ebenfalls fehl-Anzeige. Die Logs waren auch sauber, bis auf besagte Verbindungs-Fehler. Ein Angriff auf den Server vielleicht, solls ja geben, doch das Traffic-Log von meinem Provider zeigte ebenfalls keine Auffälligkeiten.

Dann hab ich so einen komischen Prozess gefunden, der da lief und "curl" hieß. Da kam es mir dann in den Sinn, das da ein FTP-Backup, auf eine anderen Server beim selben Provider, läuft. Das war dann auch die Lösung des Problem. Der Backup-Vorgang hat das 100Mbit-Interface arg genug ausgelastet, das MySQL keine Verbindung mehr aufbauen konnte, aber nicht so arg, das die sonstigen Dienste auf selbigem Server nicht mehr zu erreichen waren. Und der Provider zeigte mir diesen Traffik natürlich nicht an, da er lediglich Netz-intern lief.

Der curl lässt sich zum Glück einfach in die Schranken weisen --limit-rate 5M .

Nachdem ich vor ein paar Tagen ein fake DEB für einen Mail-Server gebraucht habe, hier kurz die Erklärung wie das geht, ist ganz einfach:

einfach: apt-get install equivs

dann ein equivs-control NameFürDasPaket

dadurch wird eine Datei NameFürDasPaket erstellt, in der man schön einstellen kann welche Abhängigkeiten das Paket faken soll.

nun ein equivs-build NameFürDasPaket und fertig ist ein neues DEB

PS: equivs hat selbst verdammt viele Abhängigkeiten, der wollte mir auf dem Server knappe 100MB installieren. Hab deshalb das ganze auf meinem Ubuntu Desktop gemacht, da praktisch alle Abhängigkeiten schon erfüllt. Wer will sich schon seinen Debian-Server zu müllen nur um ein 3Kb DEB zu machen ...

Anbei ein kleines virtuelles Debian-Package das nicht anderes tut, als die Abhängigkeit nach dem mail-transport-agent zu erfüllen:

 # dpkg -I mta-fake_1.0_all.deb 
 neues Debian-Paket, Version 2.0.
 Größe 2278 Byte: control-Archiv= 725 Byte.
     764 Byte,    19 Zeilen      control              
     208 Byte,     3 Zeilen      md5sums              
 Package: mta-fake
 Version: 1.0
 Architecture: all
 Maintainer: none
 Installed-Size: 36
 Provides: mail-transport-agent
 Section: misc
 Priority: optional
 Description: Dummy package to fulfill package dependencies
  This is a dummy package that makes Debian's package management
  system believe that equivalents to packages on which other
  packages depend on are actually installed.  Deinstallation of
  this package is only possible when all pending dependency issues
  are properly resolved in some other way.
  .
  Please note that this is a crude hack and if thoughtlessly used
  might possibly do damage to your packaging system.  And please
  note as well that using it is not the recommended way of dealing
  with broken dependencies.  It is better to file a bug report.

Wofür das ganze ? Ich hab auf einem Server Zimbra installiert. Wollte dann, dass ein paar Cronjobs mir Protokolle mailen können und dachte fluchs bsd-mailx installiert und fertig. Pustekuchen, der hat ein Depend nach mail-transport-agent. Dieser wird nur leider nicht von den Zimbra-DEBs erfüllt. Mittels equivs kann mans sich glücklicherweise recht einfach fake Pakete, wie diese, erstellen.

Mit dem mta-fake DEB und einem ln -s /opt/zimbra/postfix/sbin/sendmail /usr/sbin/sendmail kann ich nun wunderbar Mails mittels mail auf dem Zimbra-Server versenden.

Wieder was gelernt.

hab versucht eine Domain auf einem Mailserver einzurichten, die per CNAME auf eine andere Domain zeigt.

Nun ja, offenbar ignoriert postfix dann die MX-Einträge. Ob das jetzt so sinnvoll ist ist ne andere frage, aber nun gut, hinterher ist man schlauer. In den RFCs steht anscheinend auch was drüber: http://www.ferris.com/2008/09/08/why-you-shouldnt-mix-cname-and-mx/, aber ob das wirklich so sinnvoll ist sei mal dahin gestellt. Verhalten sich andere Dienste, die auf speziellen DNS-Eintragen aufbauen, eigentlich auch so ?