Das schmuffligste Blog der Welt

Für eine Alarmanlage habe ich mir bei Pollin die Relaiskarte K8io für den Parallelport bestellt. Nun gibt es leider für den Raspberry Pi keine USB->Paralleladapter, die diesen Namen auch verdienen, also musste gebastelt werden.
Da haben wir dann auch gleich das erste Problem, die parallele Schnittstelle arbeitet mit 5V high Pegeln, der Pi mit 3.3V TTL. Außerdem will ich die Karte mit 12V DC betreiben und nicht mit 9V AC. Wer hat sich denn das einfallen lassen? Wer hat denn irgendwo 9V AC liegen? 😀
Aber wo ein Wille ist, da ist ein Weg! Insofern muss man das Layout der K8io ein wenig modifzieren und dann geht auch das und zwar so:

-Vom Gleichrichter ersparen wir uns D2 und D4, da 12V DC Betrieb. Der + Pol ist dann außen und GND ist innen.
-Außerdem können wir mit dem Spannungsregler 7805 (12V DC -> 5V DC) nichts anfangen. Wir wollen nativ die 3.3V des Pi nutzen. Das spart auch schön Platz, es gibt keinen Kühlkörper mehr 🙂
Nachtrag: Wir erleichtern das Netzteil der K8io auch gleich noch um die beiden 100nf Kondensatoren, dann können wir aus den Resten (7805, Kühlkörper, 2x 100nF) eine kleine Wandlerplatine für den Pi bauen und alles mit 12V betreiben)
Nachtrag 2: Die o.g. Idee ist doch nicht so grandios wie zunächst vermutet. Der Raspi zieht doch recht ordentliche 0.5A max aus dem 7805. Bei 12V DC Betrieb sind das dann 3.5W Wärme Verlustleistung die an dem kleinen Sparkühlkörper verbraten werden müssen. Sprich: Das Teil wird recht heiss. Ich werde daher vermutlich auf ein kleines Schaltnetzteil umrüsten. Die haben idR einen wesentlich besseren Wirkungsgrad und verbraten nicht einfach in Wärme.
Nachtrag 3: Ich habe nun auf Basis des LM2576T-5.0 ein kleines Schaltnetzteil gebaut (u.A. hier vorgestellt). Die 150µH Drossel war nirgends zu bekommen, also musste mit dem ebenfalls dort vorgestellten Tool neu berechnet werden. Dies hat ergeben, dass ich auch eine 100µH Drossel verwenden kann, wenn ich den Kondensator anpasse.
Man merkt deutlich, dass nun der Gesamtaufbau wesentlich weniger Strom aufnimmt. Hatte ich vorher in der Spitze rund 500mA Stromaufnahme, so habe ich mit dem SNT nur noch max. 330mA Stromaufnahme! Und da ist noch ein kleiner NF-Verstärker hinzugekommen. Es lohnt sich also auf jeden Fall, den 7805 auszutauschen. Der Aufbau wird auch nur noch handwarm.

Soviel zu den techn. Änderungen! JP1 lassen wir drin, darüber kommen die 3.3V des Pi aufs Board. Es ginge zwar theoretisch auch ohne die Versorgung über JP1, und man hätte dann einen weiteren Eingang, aber sicher ist sicher.
Weitere Änderungen muss man eigentlich nicht vornehmen. Zu beachten ist, dass über die Pull Up Widerstände immer 3.3V an den Eingängen 1-4 anliegen.
Jetzt muss eigentlich nur noch ein passendes Adapterkabel gebastelt werden. Das geht am einfachsten mit einem 2×13 poligen Pfostenstecker, passendem Flachbandkabel und einem 25 poligen Sub-D Stecker mit Lötkelchen. Gibt es alles für ein paar EUR beim Trödler um die Ecke 😉

Hier ist die genaue Belegung für das Adapterkabel:

Die erste Spalte bezeichnet den GPIO Signalname, die zweite Spalte den zugehörigen Pin auf dem Raspi Board (Achtung: Version 2!). Last not least die letzte Spalte die Pins auf dem Sub-D Stecker.

Hat man das dann alles ordentlich verlötet und auf Kurzschlüsse geprüft, kann man anstöpseln und sich mit den entsprechenden Tools austoben 🙂
Wer möchte, kann sich eine kleine Huckepackplatine für die K8io basteln und dann noch die brachliegenden Control Leitungen als weitere Eingänge oder Ausgänge nutzen. Ich habe mir da vier LEDs mit Vorwiderständen auf einen Platinenrest gelötet und realisiere damit Statusanzeigen.

Eingebaut in einem alten Gehäuse kann sich das sehen lassen 🙂

–

Ich liebe Telefonterror von Marketingtrotteln. Das spornt mich immer dazu an,  etwas an Capisuite herumzubasteln 🙂
Leider fehlt bei Capisuite eine out-of-the-box Blacklistfunktion zum sperren von übermittelten Rufnummern, aber dem kann abgeholfen werden.

Wie auch schon in meinem Beitrag hier erwähnt, kann man dies durch anpassen der incoming.py (wo die Datei liegt steht in der Regel in /etc/capisuite.conf) erreichen. Bei openSUSE liegt die Datei in /usr/lib64/capisuite.

Die Blacklist werten wir am besten in der Funktion callIncoming aus, und zwar NACH dem try/except Block:

# read config file and search for call_to in the user sections
try:
    config=cs_helpers.readConfig()
    userlist=config.sections()
[...]
except IOError,e:
    capisuite.error("Error occured during config file reading: "+e+" Disconnecting...")
    capisuite.reject(call,0x34A9)
    return

Das wäre besagter try/except Block. Hintendran fügen wir ein

if (call_from in (open("/etc/capisuite/blacklist.conf").read().split())):
   capisuite.log("call from blocked number "+call_from+". suppressed.",1,call)
   capisuite.reject(call,0x34A9)
   return

Nun fehlt natürlich noch unsere Liste mit geblockten Nummern, dazu erstellen wir ganz einfach eine Textdatei blacklist.conf im Capisuite ConfigDir /etc/capisuite. Jede Zeile enthält genau eine vollständige Telefonnummer.
Et voilá, betreffende Anrufe werden mit einem Capi Fehler rejected und der nervige Anrufer weiss nicht, wie im geschieht:

Thu Aug  9 10:22:07 2012 Connection 0xa9aed0: call from blocked number 069XXXXXXX. suppressed.

Hihihihi.

Some people want a recent libtorrent (in this case the 0.12.9 sources from openSUSE 12.1) patched with the no-upload-patch made public on

http://citylight.thinkbay.net/Disable_sharing_in_rtorrent

Here you go: libtorrent-0.12.9-no_upload.tar.gz

Just tar xvfz, ./configure, make and make install.

Careful: Disables upload for all aplications using libtorrent with all consequences (superseeding!)

Please scroll down for english version!

Gestern Abend hatte ich darüber nachgedacht, ob es mit dd irgendwie möglich ist, differentielle dumps zu erstellen.
Dabei sollen von einer Datei/einem Device nur die Blöcke in eine bestehende Datei/bestehendes Device geschrieben werden, die sich geändert haben. Hört sich kompliziert an, ist aber eigentlich ganz einfach:

Man macht einen Dump einer Festplatte mit dd. Dann einige Zeit später möchte man die Platte wieder dumpen ohne erneut das ganze File zu schreiben. Da wäre es praktisch, wenn man lediglich die Änderungen also quasi das Delta schreiben müsste.

Die kurze Version:
Es geht, hier ist das Skript. Bitte reinschauen und ggf. anpassen, das ist ganz schnell und dreckig runtergehackt.

Die lange Version:
Was das Skript macht ist erstmal die beiden Dateigrößen einzulesen. Die werden dann in K und M Blocks umgerechnet. Dann wird je ein Block der Quelle und des Ziels gelesen und die MD5 Summe erstellt. Unterscheiden sie sich, sind die Blöcke unterschiedlich, haben sich also geändert. Die Nummer des Blocks wird in einem Array gespeichert. Anschließend werden die unterschiedlichen Blöcke aus der Quelle gelesen und über skip/seek und notrunc in das Ziel geschrieben. Anschließen kann man sich die MD5 Summen von Quelle und Ziel berechnen lassen (optional).
Die ganze Aktion ist natürlich völliger Schwachsinn, weil man um die MD5 Summen der Blocks zu errechnen 1. die Quelle und 2. das Ziel komplett lesen muss. Das Ganze macht also nur Sinn, wenn man zwar rel. schnell lesen aber nur sehr langsam schreiben kann.

Zum Beispiel:
-Target liegt auf einem entfernten Rechner (Internet, WAN, etc. pp) und der entfernte Rechner hat hohen Upstream man selbst aber nur einen sehr geringen
-Source ist eine SSD die wesentlich schneller lesen als schreiben kann, sofern man on-the-fly auf das selbe Device schreibt

Aber es hat Spaß gemacht und vielleicht kann ja jemand etwas damit anfangen 😀

Wie gesagt, ist mit Vorsicht zu genießen und wie immer auf eigene Gefahr zu nutzen.

— english version —

Yesterday evening I thought about if it is possible with dd to make differential dumps.
Only changed blocks on a file/device should be written to the target. Sounds complicated but it is quite easy:

If you have a dump of a harddisk, for example, and some time later you want to do a new dump but without writing the whole disk again. Only the changed blocks should be written to the target file.

The short version:
It works, here is the script. Please look at it and modify to fit your needs, it is hacked very quick and dirty.

The long version:
What the script does, is first read the two file sizes and convert it to K and M blocks. Each block is then read from source and target and a MD5 sum is generated. If these two sums are different, then the block has changed. The number of the changed blocks is stored in an array and later the changed blocks are read from the source and written to the target with skip/seek and notrunc. Later you can calculate the MD5 sum of source and target (optional).
Of couse this is totally useless, because to calculate the MD5 sums of the blocks you both have to read the source AND the target file completely. This whole thing will only make sense if you can read very fast but only write very slow.

For example:
-Target lies on a remote machine (Internet, WAN, etc. pp) and the remote machine has a much higher upstream bandwith than your local machine
-Source is a SSD which can read much faster than it can write, if you read/write on the same device.

However, it was fun writing the script and maybe it is of use to someone.

Be careful, as always this comes without warranty and use at your own risk 😉

Wer kennt sie nicht, die täglichen/nächtlichen SPAM Faxe. Wenn man alles elektronisch über einen zentralen Faxserver kaufen lässt und die Faxe als PDF per Mail bekommt, hat man zwar keine Papierkosten, aber es nervt halt einfach.
Die Faxe kommen auch regelmäßig mit unterdrückter Rufnummer rein, damit man

a) keinen Nummernfilter setzen kann und
b) keine (triviale) Möglichkeit hat den Absender herauszufinden oder bei der Bundesnetzagentur Beschwerde einzulegen.

Da CapiSuite per default keine Möglichkeit bietet, anonyme Faxe abzulehnen, muss das entsprechende Python Skript händisch um diese Funktion erweitert werden. Bei openSUSE befindet sich dieses Skript unter

/usr/lib64/capisuite/incoming.py

Die betreffende Eingangsfunktion für die Faxe (faxIncoming) muss jetzt um ein IF Statement erweitert werden und sieht dann (Auszug) so aus:

def faxIncoming(call,call_from,call_to,curr_user,config,already_connected):
  try:
    udir=cs_helpers.getOption(config,"","fax_user_dir")
    if (udir==None):
      capisuite.error("global option fax_user_dir not found! -> rejecting call")
      capisuite.reject(call,0x34A9)
      return
    if (call_from=="-"):
      capisuite.log("call from empty number. suppressed.",1,call)
      capisuite.reject(call,0x34A9)
      return
    udir=os.path.join(udir,curr_user)+"/"

Praktischerweise setzt CapiSuite bei unbekannter Rufnummer diese auf „-„, so kann man mit dem o.g. IF Statement ganz einfach einen Capi Reject senden.  Man kann so nett sein und ein 0x3495 (Call Rejected) senden oder wie ich ein 0x34A9 (Temporary failure). Hier eine Liste der Capi Fehlercodes: Link

Wenn nun ein Fax mit unterdrückter Nummer hereinkommt, sieht man im Logfile was genau passiert:

0x8c8750: Connection object created for incoming call PLCI 401 from - to x CIP 0x4
0x8c8750: call from empty number. suppressed.
0x8c8750: rejecting with cause 34a9
0x8c8750: Connection object deleted

Da ich einen termporären Fehler zurückgebe, versucht es der Spammer dann noch ein paar dutzend mal, was die Leitung – eventuell – etwas ausbremst und er nicht so viele SPAM Faxe verschicken kann wie sonst 😉

Hier das diff File für alle Schreibfaulen als tar.gz: incoming.py.tar.gz

For a english version scroll down!

Heute habe ich noch einen Leckerbissen: Ein Script für ESX3/ESX4 mit dem einfache, automatisierte VCB Backups möglich sind.
Über die Annotations kann die Variable DO_BACKUP als einfacher Text für jede VM gesetzt werden, z.B. DO_BACKUP=DAILY.
Das Skript liest diese Anmerkungen aus und sichert die Maschine dann täglich. Aber genug der Rede, hier ist der Download Link:

esx3_4_backup.sh

Voraussetzungen/Infos:
-es gibt die Methoden ONCE, DAILY, WEEKLY und MONTHLY
-DO_BACKUP muss immer am Ende der Annotations stehen. Also z.B. „Nur eine Testmaschine, blah blah blah, DO_BACKUP=WEEKLY“
-Annotations dürfen keine Sonderzeichen (ß,ü,ä,ö, usw) enthalten
-je nach Größe der Backup-LUNs muss die default Vorhaltezeit angepasst werden, sonst laufen die LUNs voll.
-es müssen die UUIDs für _alle_ Produktions-LUNs und Backup-LUNS angepasst werden
-über die Variable ESX müssen alle Hostnamen der ESXe richtig gesetzt sein
-remote SSH login für alle ESXe muss über ein root Zertifikat möglich sein. Default ist /root/.ssh/id_rsa

Ganz wichtig: bevor das Skript ausgeführt wird, sollte DEBUG=1 gesetzt werden. Außerdem solltet Ihr das Skript durchlesen, verstehen und auf eure Bedürfnisse anpassen! Das Skript löscht Dateien auf LUNs auf Konsolenebene, also OBACHT!
1. LESEN
2. VERSTEHEN
3. ZURÜCK ZU 1.

Ich lehne natürlich jegliche Haftung für gelöschte Daten ab. Benutzung auf eigene Gefahr!
(Für alle Schlaumeier: Ja, man kann das besser machen, awk überall durch cut ersetzen, sed zusammenziehen, blablabla. Help yourself.)

English version:

Today I have another gimmick for you: A script for ESX3/ESX4 which makes creating automated VCB backups very easy.
You can set a variable DO_BACKUP as text in the VMs annotations, e.g. DO_BACKUP=DAILY.
The script then reads the annotations, finds the variable and executes the desired vcbbackup.
Here is the download link:

esx3_4_backup.sh

Requirements/Infos:
-you can use backup methods ONCE, DAILY, WEEKLY und MONTHLY
-DO_BACKUP has to be defined at the end of the annotations, e.g. „This is a test machine, blah blah blah, DO_BACKUP=WEEKLY“
-annotations  must not contain special characters (ß,ü,ä,ö, etc)
-depending on the size of your backup LUNs you have to change the default keep times or your LUNs will end up with no space left.
-you have to set the correct UUIDs for  _all_ production and backup LUNS
-variable ESX must be set correctly to contain all ESX hostnames
-remote SSH login must be working for all ESX using a root certificate. Default is /root/.ssh/id_rsa

Very important: before you execute the script you should set DEBUG=1. Additionally you should read, understand and modify the script to fit your needs! The script deletes files directly from LUNs, be careful!
1. READ
2. UNDERSTAND
3. BACK TO 1.

This script comes without any warranty. Use at own risk!
(For all wise guys: yes you can solve this better, replace all awk with cut, shorten the seds, blablabla. Help yourself.)

Please scroll down for the english version of this article!

Heute habe ich ein besonderes Häppchen für alle Spamassassin Benutzer. Eine Bayesdatenbank mit ein paar Millionen gelernten Mails.
Die Datenbank stammt von einem ISP und hat die gelernten Mails von einigen tausend Kunden intus.

Im Detail:

spam_count    ham_count    token_count    oldest_token_age   newest_token_age
591151        4433526      144282         1259699456         1259823676

Also rund 4.4 Millionen HAM counts, knapp 600.00 SPAM counts.
Das ist schon ganz ordentlich 😉

Die Datenbank wurde mit

sa-learn -u public --backup > bayes_02-12-09

gesichert und kann mit

sa-learn -u public --restore ./bayes_02-12-09

wieder importiert werden. Der Pfad sowie der von euch verwendete User (hier: ‚public‘) sollte ggf.  angepasst werden. Vorher das File natürlich gunzippen!

Hier der Link (120MB!):
http://rapidshare.com/files/315578995/bayes_02-12-09.gz

As this is quite an international matter of interest, here the english version:

Today I have a special gimmick  for all Spamassassin users. A bayes database with a few million entries.
The database originates from a German ISP and contains the learned mail of a few thousand customers.

In detail:

spam_count    ham_count    token_count    oldest_token_age   newest_token_age
591151        4433526      144282         1259699456         1259823676

So we have about 4.4 million HAM counts and almost 600.00 SPAM counts.

That is quite a chunk 😉

The database had been dumped with

sa-learn -u public --backup > bayes_02-12-09

and can be imported with

sa-learn -u public --restore ./bayes_02-12-09

The path to the file and the user (‚public‘ in my example) has to be altered to fit your needs. Careful: The file is  gzipped and has to be unzipped before use!

Here is the link (120MB!)
http://rapidshare.com/files/315578995/bayes_02-12-09.gz

Tja, wer kennt das Problem nicht? Man sitzt mit seinem tollen Subnotebook auf dem Sofa, aber die Möhre hat nur einen Mono Quäker unter(!) der Tastatur eingebaut. So wird das natürlich nichts mit den Youtube Musikvideos oder den neuesten Demo-MP3s.

Wenn man dann auch noch einen 24/7 Linux Server samt 5.1 Anlage im Wohnzimmer stehen hat, dann stellt sich die Frage: Kann ich den Sound von meiner Windows Kiste nicht irgendwie per Netzwerk (Kabel o. WLAN) zum Server schicken und über meine Anlage anhören?
Einige Leute empfehlen hier ja Pulseaudio, aber davon halte ich ehrlich gesagt wenig. Ist ja auch nicht sonderlich Ressourcen schonend. Also was denn dann?

Zunächst sollte der Linux Server so weit eingerichtet sein, dass man mit aplay ein paar Testsounds ausgeben kann:

server:~ # aplay /usr/share/sounds/alsa/Front_Right.wav
Playing WAVE ‚/usr/share/sounds/alsa/Front_Right.wav‘ : Signed 16 bit Little Endian, Rate 48000 Hz, Mono

Sofern Ihr jetzt „Right“ aus den Lautsprechern hört, ist der Sound soweit eingerichtet und es kann losgehen.
Das tolle ist, aplay kann die Sounddaten nicht nur von einer Datei lesen, sondern auch von ’stdin‘:

server:~ # cat /usr/share/sounds/alsa/Front_Right.wav|aplay –
Playing WAVE ’stdin‘ : Signed 16 bit Little Endian, Rate 48000 Hz, Mono

Dies sollte wieder ein „Right“ ausgeben.
Koppelt man dies jetzt mit netcat, dann ist die Hälfte schon geschafft:

server:~ # netcat -l -p 12345|aplay – -f cd

Netcat hört jetzt auf Port 12345 auf Verbindungen und piped die eingehenden Daten an aplay. Letzterem sagt man noch, dass man als Format (-f cd) 16Bit Stereo bei 44.1kHz spielen will.
Der springende Punkt ist jetzt, wie man den Sound von Windows übers Netz schiebt. Dazu braucht man natürlich zunächst mal Netcat für Windows (http://www.netzwelt.de/download/6848-netcat.html). Dann muss man noch die Lautsprecherausgabe auf stdout umleiten. Leider ist mir bisher nur das Programm „LiveInCode“ (http://liveincode.rm.pp.ru/) als nutzbare Lösung bekannt. Und dies auch nur für Aufnahme Quellen.

Im Klartext bedeutet das, eure Windowskiste muss einen entsprechenden Mixerkanal haben, hier „Stereomix“ genannt:

Also. LiveInCode runterladen, entpacken. Netcat für Windows runterladen, am besten in das selbe Verzeichnis schieben.

Gestartet wird dann mit:

<pfad zu linco>\linco.exe -B 16 -C 2 -R 44100 |<pfad zu nc.exe>\nc.exe <hostname oder ip vom server> <port>

Linco codiert 16Bit (-B 16),  2 Kanäle (-C 2) bei 44100Hz (-R 44100). Also CD Format. Der Port für Netcat wäre in unserem Beispiel dann 12345.

Gestartet sieht das dann z.B. so aus:

C:\Dokumente und Einstellungen\User\Desktop>d:\linco\linco -B 16 -C 2 -R 44100 | d:\linco\nc server 12345
****
**** LineInCode v2.10(2003-12-31)
**** (C) 2003 Roman Mamedov
****
**** Using „SoundMAX HD Audio“
**** 44100 Hz, 16 Bit, Stereo
****
**** Press Ctrl-C to stop recording…

Wenn der Connect klappt, sollte Linux bzw. aplay melden, dass es einen entsprechenden Stream empfängt:

server:~ # netcat -l -p 12345|aplay – -f cd
Playing raw data ’stdin‘ : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo

Spielt man nun einen Sound auf der Windows Maschine ab, sollte es aus den Lautsprechern der Anlage kommen. Einziger Nachteil:  Durch Linco kommt es zu einem Delay in der Ausgabe. Wer sich also Videos ansieht, wird den Versatz deutlich bemerken. Leider ist mir kein Programm bekannt, dass den Windows Speaker direkt auf stdout umleitet. Dann könnte man das Delay minimieren.