Sie sind hier

Debian

IPv6: oddities with mtr

Heute fand die "Earth Hour" von 20:30 bis 21:30 Uhr statt. Spiegel Online berichtet. Ich finde das eigentlich eine klasse Idee, allerdings sehe ich nicht unbedingt das Energiesparen im Vordergrund, sondern vielmehr die Lichtverschmutzung.

NASA Bild: Erde bei Nacht (s.Wikipedia)

Wer sich mal den Nachthimmel auf dem Land angeschaut und ihn mit dem Himmel über einer Stadt verglichen hat, dem wird der große Unterschied aufgefallen sein. Teilweise kann man schon in mittelgroßen Städten nicht mehr die Milchstraße erkennen. Dem Kampf gegen die Lichtverschmutzung hat sich die Dark Sky Association verschrieben.

Kategorie: 
 

Linksys WET-54G not IPv6 capable

I just discovered that mtr has some problems with IPv6 enabled hosts when using the GUI. Try the following:

1) enter "mtr ipv6-host" in shell -> works
2) enter then an IPv4 only host in Hostname input line -> doesn't work

3) quit mtr

4) enter "mtr ipv4-host" in shell -> works
5) enter then an IPv6 enabled host in Hostname input line -> tracing IPv4 part of IPv6 enabled host

So, something is broken, at least for 2). One could argue if 5) might be OK or the expected behaviour, but I believe that mtr should query the AAAA records and trace for the IPv6 hostname, regardless of whether you started with an IPv4 only host first.

Is there already someone tracking IPv6 related bugs in Debian? A tag in BTS maybe? Anyway, the above is reported as #521415.

UPDATE: added blog title ;)

Kategorie: 
 

BSD in Warnemünde

Bei meinem gestrigen Gang zum Bäcker ist mir nicht nur der BSD Fachpartner aufgefallen, sondern ich bin in der Mühlenstraße auch noch an einer Wäscherei vorbeigekommen, bei deren Außenwerbung ich immer ein bißchen schmunzeln muss:

Alte Wäscherei in Warnemünde

Gereichte eine saubere Wäsche zu Zeiten, in der diese Wäscherei entstand, durchaus noch zum Lob der Frau, so ist es doch heute wohl eher ein Anachronismus. Daß eine solche Firmenbezeichnung durchaus verbreitet war/ist, zeigt übrigens Tante Google.

Kategorie: 
 

IPv6 connectivity

Nachdem ich dann mal dafür gesorgt habe, daß die Server IPv6 haben, ging es nun darum, auch daheim IPv6 haben zu wollen. Im Prinzip war das eine einfache Sache, da das LAN ja schon per OpenVPN mit dem Server eine Verbindung hatte. Da das relativ schnell ging und auch gar nicht weh tat, hier mal meine Vorgehensweise:

  1. einen IP 6-in-4 tunnel konfigurieren. Dazu geht man ähnlich vor, wie beim Einrichten des Tunnels zu Sixxs.net, bloß halt auf beiden Seiten des Tunnels.
  2. ein IPv6 ::/64 Subnet aussuchen, das man dann auf den Tunnel routet.
  3. im LAN dann /etc/radvd.conf dahingehend konfigurieren, daß es den Prefix im LAN announced.
  4. /etc/network/interfaces entsprechend konfigurieren, d.h. den richtigen Interfaces die richtigen IPs und Gateways zuweisen.
  5. fehlende Routen setzen bzw. konfigurieren.
  6. fertig.

Klingt erstmal recht einfach, oder? Ist es im Prinzip auch, wenn man nicht wie ich den Fehler macht, das falsche Interface für das Routing zu verwenden. Hintergrund: ich hab hier einen Xen-Kernel am Laufen und deshalb ist mein Interface zum LAN mit peth0 eine Bridge, die als physisches Interface eth0 hat. An die Bridge werden dann die virtuellen Interfaces der Xen VMs gekoppelt. Na, jedenfalls hab ich ca. 2 Stunden gebraucht, um festzustellen, daß mein gesamtes Tunnelsetup eth0 enthielt. Das Resultat war, daß ich zwar den Router daheim erreichen konnte, aber nicht die Rechner dahinter, obgleich von den anderen Rechnern ICMP echo requests nach draußen ging, aber die Antworten nur bis zum Router kamen. Stattdessen gingen zwischen Router und Rechner munter Neighbor advertisements und Neighbor solicitation Pakete hin und her (s.a. IPv6 Grundlagen · Funktionalität · Integration von Silvia Hagen, S. 107-110, ISBN 3-9522942-0-9).

Ansonsten ging die Einrichtung aber völlig problemlos vonstatten. Was aber zu beachten ist, wenn man sowas macht, ist, daß man dann direkt eine öffentliche IP im Internet hat und nicht mehr sicher hinter einem Router mit eingebauter Firewall sitzt. Also muss man selber dafür sorgen, daß der Rechner wieder sicher ist!

Wenn man dann noch so neugierig ist wie ich, kann man sich auch nochmal den Traffic anschauen, der nun über die IPv6 Verbindung ins Netz geht, wenn man so durchs Netz surft, um festzustellen, welche Seiten bereits mit IPv6 ausgestattet sind. Man wird feststellen: es sind die wenigsten. Sogar solche Seiten wie heise.de, die ja immer gerne darüber berichten, wie knapp IPv4 Adressen ja werden und wie dringend der Wechsel auf IPv6 doch sei, sind nicht per IPv6 erreichbar. Irgendwie kann man somit deren Berichterstattung über das Thema nicht mehr ganz so ernst nehmen, wenn sie selber mit der Implementation so zögerlich sind.

Aber um das Thema IPv6 mal etwas mehr ins Blickfeld zu rücken hab ich in der Sidebar rechts zwei kleine Applets zu diesem Thema platziert. Das eine zeigt den IPv4 Exhaustion Counter, das andere das Verhältnis zwischen IPv4 und IPv6 Besuchern auf diesem Blog.
Seit gestern hat sich das Tempo beim Exhaustion Counter übrigens verlangsamt: waren es da noch 763 Tage bis zum bitteren Ende, begrüßte mich dier Counter heute mit der Botschaft, daß es noch 765 Tage seien, also zwei mehr als gestern noch.

Kategorie: 
 

Gallery and missing exif information - solved!

Also im Moment gibt es für mich keinen größeren Nerv-Faktor im deutschen als dieser Song von Polardingsbums 18. Da finde ich Da Da Da von Trio ja noch besser und weniger nervtötend. Aber dieses "Allein, allein..." ist einfach billiger Kommerzpop. Ok, vielleicht nicht ganz so, aber nervig ist der Titel allemal!

Bei sowas hab ich dann immer die Hoffnung, daß sich es meistens nicht lange im "Business" hält.

Kategorie: 
 

Gallery and missing exif information

Yesterday I asked for help because I was missing exif information in my Gallery2 installation. Today I found the reason for this, when I was trying get a random image block displayed in my blog, which fails as well.
There seems a bug in /usr/share/php/adodb/drivers/adodb-postgres7.inc.php:

Warning: pg_query_params() [function.pg-query-params]: Query failed: ERROR: column "g_userid" is of type integer but expression is of type text HINT: You will need to rewrite or cast the expression. in /usr/share/php/adodb/drivers/adodb-postgres7.inc.php on line 113
-1: ERROR: column "g_userid" is of type integer but expression is of type text HINT: You will need to rewrite or cast the expression.

ADOConnection._Execute(
INSERT INTO
g2_ImageBlockCacheMap
SELECT DISTINCT
?, ?, g2_Entity.g_creationTimestamp, g2_Entity.g_id, FLOOR(RANDOM()
*..., Array[45]) % line 1007, file: adodb.inc.php

ADOConnection.Execute(
INSERT INTO
g2_ImageBlockCacheMap
SELECT DISTINCT
?, ?, g2_Entity.g_creationTimestamp, g2_Entity.g_id, FLOOR(RANDOM()
*..., Array[45]) % line 952, file: GalleryStorageExtras.class

GalleryStorageExtras.execute(
INSERT INTO
[ImageBlockCacheMap]
SELECT DISTINCT
?, ?, [GalleryEntity::creationTimestamp], [GalleryEntity::id],
FLOOR(R..., Array[45]) % line 507,
file: GalleryStorage.class

GalleryStorage.execute(
INSERT INTO
[ImageBlockCacheMap]
SELECT DISTINCT
?, ?, [GalleryEntity::creationTimestamp], [GalleryEntity::id],
FLOOR(R..., Array[45]) % line 742,
file: ImageBlockHelper.class

ImageBlockHelper.cacheViewableTree(17) % line 520, file: ImageBlockHelper.class

Error performing imageblock.LoadImageBlock callback realpath(/usr/share/gallery2/modules/core/classes/../../../) realpath(/var/www/net/gallery.windfluechter.net/) Error (ERROR_STORAGE_FAILURE)

* in modules/core/classes/GalleryStorage/GalleryStorageExtras.class at line 959 (GalleryCoreApi::error)
* in modules/core/classes/GalleryStorage.class at line 507 (GalleryStorageExtras::execute)
* in modules/imageblock/classes/ImageBlockHelper.class at line 742 (GalleryStorage::execute)
* in modules/imageblock/classes/ImageBlockHelper.class at line 520 (ImageBlockHelper::cacheViewableTree)
* in modules/imageblock/classes/ImageBlockHelper.class at line 283 (ImageBlockHelper::fetchViewableData)
* in modules/imageblock/classes/ImageBlockHelper.class at line 93 (ImageBlockHelper::_getBlockData)
* in modules/imageblock/Callbacks.inc at line 83 (ImageBlockHelper::loadImageBlocks)
* in modules/core/classes/GalleryTemplateAdapter.class at line 1052 (ImageBlockCallbacks::callback)
* in g2data/smarty/templates_c/%%626616196/matrix/%%A3^A3E^A3E218EA%%ImageBlock.tpl.php at line 5 (GalleryTemplateAdapter::callback)
* in /usr/share/php/smarty/libs/Smarty.class.php at line 1868
* in modules/core/classes/GalleryTemplateAdapter.class at line 983 (Smarty::_smarty_include)
* in g2data/smarty/templates_c/%%626616196/matrix/%%B4^B49^B49848CB%%sidebar.tpl.php at line 7 (GalleryTemplateAdapter::block)
* in /usr/share/php/smarty/libs/Smarty.class.php at line 1868
* in modules/core/classes/GalleryTemplateAdapter.class at line 909 (Smarty::_smarty_include)
* in g2data/smarty/templates_c/%%626616196/matrix/%%AD^AD7^AD74CEE9%%photo.tpl.php at line 12 (GalleryTemplateAdapter::theme)
* in /usr/share/php/smarty/libs/Smarty.class.php at line 1868
* in modules/core/classes/GalleryTemplateAdapter.class at line 909 (Smarty::_smarty_include)
* in g2data/smarty/templates_c/%%626616196/matrix/%%3A^3A8^3A818B59%%theme.tpl.php at line 55 (GalleryTemplateAdapter::theme)
* in /usr/share/php/smarty/libs/Smarty.class.php at line 1262
* in modules/core/classes/GallerySmarty.class at line 61 (Smarty::fetch)
* in modules/core/classes/GalleryTemplate.class at line 219 (GallerySmarty::fetch)
* in main.php at line 521 (GalleryTemplate::fetch)
* in main.php at line 104
* in main.php at line 88
* in main.php at line 3

file_exists(/var/www/net/gallery.windfluechter.net/g2data/cache/module/_all/0/0/GalleryPluginHelper_fetchPluginStatus.inc) getParameter smarty.compile_check for core plugin file_exists(/var/www/net/gallery.windfluechter.net/g2data/cache/module/core/0/0/0.inc) file_exists(/var/www/net/gallery.windfluechter.net/g2data/smarty/templates_c/%%626616196/matrix/%%C7^C79^C79EEB7F%%ItemInfo.tpl.php) strftime(%x, 1231148074) file_exists(/var/www/net/gallery.windfluechter.net/g2data/smarty/templates_c/%%626616196/matrix/%%F3^F3E^F3EB483E%%PhotoSizes.tpl.php) file_exists(/var/www/net/gallery.windfluechter.net/g2data/cache/entity/2/1/21143.inc) file_exists(/var/www/net/gallery.windfluechter.net/g2data/cache/entity/2/1/21080.inc) file_exists(/var/www/net/gallery.windfluechter.net/g2data/cache/entity/1/9/19996.inc) file_exists(/var/www/net/gallery.windfluechter.net/g2data/cache/entity/4/4/4457.inc) file_exists(/var/www/net/gallery.windfluechter.net/g2data/cache/entity/0/0/7.inc) file_exists(/var/www/net/gallery.windfluechter.net/g2data/smarty/templates_c/%%626616196/matrix/%%5A^5A3^5A33504B%%Navigator.tpl.php) file_exists(/var/www/net/gallery.windfluechter.net/g2data/cache/entity/2/1/21148.inc) file_exists(/var/www/net/gallery.windfluechter.net/g2data/cache/entity/2/1/21588.inc) file_exists(/var/www/net/gallery.windfluechter.net/g2data/cache/entity/2/1/21127.inc) file_exists(/var/www/net/gallery.windfluechter.net/g2data/cache/entity/2/1/21138.inc) file_exists(/var/www/net/gallery.windfluechter.net/g2data/cache/entity/2/5/25248.inc) file_exists(/var/www/net/gallery.windfluechter.net/g2data/smarty/templates_c/%%626616196/matrix/%%F6^F68^F68636C4%%ExifInfo.tpl.php) postgres7 error: [-1: ERROR: current transaction is aborted, commands ignored until end of transaction block] in EXECUTE(" SELECT g2_Group.g_id, g2_Group.g_groupName FROM g2_UserGroupMap, g2_Group WHERE g2_Group.g_id = g2_UserGroupMap.g_groupId AND g2_UserGroupMap.g_userId = ? ORDER BY g2_Group.g_groupName ")

So, when there's the image block activated in theme setting, some queries like the above are failing and neither the image block nor the exif data block is displayed. The temporary solution is therefor to remove the image block from your theme or deactivate/uninstall the plugin at all. The long term solution will be to wait for an updated gallery2 after I've reported this bug to the BTS... ;)

UPDATE: #518572

Kategorie: 
 

HowTo: Migrate RAID1 to RAID5

Als ich heute mein eines RAID1 auf RAID5 migriert habe, hatte ich Probleme vom RAID1 zu booten. Zur Information: md0 und md2 sind /boot und / bei mir und als RAID1 angelegt. Das LVM ist auf dem RAID5. Die Probleme gab es mit md2. Als Boot-Parameter ist "root=/dev/md2" angegeben. In /etc/mdadm/mdadm.conf steht folgendes:

ARRAY /dev/md0 level=raid1 num-devices=2 devices=/dev/sd[ab]1
ARRAY /dev/md1 level=raid1 num-devices=2 devices=/dev/sd[ab]2
ARRAY /dev/md2 level=raid1 num-devices=2 devices=/dev/sd[ab]3
ARRAY /dev/md3 level=raid1 num-devices=2 devices=/dev/sd[ab]5
ARRAY /dev/md4 level=raid1 num-devices=2 devices=/dev/sd[ab]6

Obiges ist die originale Ausgangssituation.

Nachdem nun das RAID1 um die dritte Platte erweitert wurde, muss in der mdadm.conf natürlich der Eintrag abgeändert werden, z.B. auf:

ARRAY /dev/md2 level=raid1 num-devices=3 devices=/dev/sd[abc]3

Wer seine Arrays anhand er UUID anspricht, muss da natürlich weniger ändern, aber das eigentliche Problem ist wohl, daß die mdadm.conf in der initrd vom Kernel nicht geupdated wird, selbst wenn man update-initramfs -u -k all aufruft. Dies führt dann dazu, daß der Kernel beim Booten mit der initrd feststellt, daß es einen Konflikt zwischen mdadm.conf und der Information auf dem Array selber kommt und somit das Array nicht gestartet werden kann.

Die Frage ist nun, wie man die aktuelle mdadm.conf in das initrd Image hineinbekommt. Ich vermute, daß es per dpkg-reconfigure mdadm funktionieren könnte, aber da mein RAID5 die nächste Zeit noch am reshapen ist, kann ich das gerade nicht ausprobieren.

Kategorie: 
 

Performance Tweaking with Drupal

Heute fand in Rostock das OpenLab #2 zum Thema Verschlüsselung statt. Die Veranstaltung war wieder sehr gut besucht und es wurde über die verschiedenen Themen rund um die Verschlüsselung referiert. Hauptsächlich ging es dabei um S/MIME und auch CAcert/Thawte.


Viele Fragen wurden von den Vortragenden beantwortet, insbesondere in Bezug auf die Sicherheit, Web of Trust und die Implementierung in Mailprogrammen. Am Schluß war die Signierstunde dann natürlich obligatorisch.

Mehr Bilder gibt es wieder in der Gallery.

Kategorie: 
 

Automatically restore files from lost+found - improved

NOTE: you can find the newest version at: http://blog.windfluechter.net/content/blog/2011/03/30/1095-updated-automatically-restore-files-lostfound

Ok, my last version was a pure Bash solution: working, but slow. There were some comments how to improve the performance and I decided finally to reimplement the second script as Python script.

The Bash script didn't finish within a day. The Python script ends after 1-2 hours in my test scenario. So, here are the scripts again:

make-lsLR.sh - call this regularly (cron) to create the needed files that are stored in /root/. Of course you can alter the location easily and exclude other directories from being scanned. 

check_lost+found.py - The second script is to be run when your fsck managed to mess up with your files and stored them into lost+found directory. It takes 3 arguments: 1) the source directory where your messed up lost+found directory is, 2) the target directory to which the data will be saved and 3) a switch to actually make it happen instead of a dry-run.

I've chosen to copy the files to a different place instead of moving them within the same filesystem to their original place for safety reasons. Primary goal is to retrieve the files from lost+found, not to replace a full featured backup and restore application. Because of this the script doesn't handle hard- nor symlinks correctly. It just copy files. Of course there's still room for improvements, like handling hard-/symlinks correctly or using inode number instead of md5sums to move data back to its prior location. But it works for me[tm] well enough in this way, so I'm satisfied so far. You're welcome, though, to improve this piece of ugliness if you like. Maybe someone else finds this usefull as well. Use it on your own risk, of course. :)

 

Kategorie: 
 

Upgrading to Lenny

Und wieder wird zum OpenLab eingeladen, dieses Mal bereits zum zweiten Mal. Das Thema ist das breite Spektrum "Verschlüsselung" oder genauer gesagt: "Sichere E-Mail Kommunikation / CAcert Assurance / PGP Keysigning / S/MIME"

Sichere E-Mail Kommunikation / CAcert Assurance / PGP Keysigning / S/MIME

Am Dienstag, den 24. Februar 2009, findet die zweite diesjährige Openlab Veranstaltung statt. Ralph und Thomas werden euch bei einer Einführung in das Thema Verschlüsselung unter anderem mit den Begriffen Vertrauen, Kryptografie sowie Lösungsansätzen zur Schlüsselausstellung (CA) und -verteilung (PKI) vertraut machen. Im praktischen Teil des Workshops werden wir uns gemeinsam der sicheren E-Mail Kommunikation widmen, so dass jeder am Ende in der Lage ist, seine E-Mails bei Bedarf zu signieren und zu verschlüsseln.

Wie gehabt möchten wir wieder Einsteiger wie Fortgeschrittene einladen. Ingesamt haben vier CAcert Assurer zugesagt, so dass wir erstellte CAcert Konten gleich gegenseitig beglaubigen können. Notwendig sind dafür nur zwei mitgebrachte amtliche Ausweißdokumente (keine Angst, es nimmt niemand eure Daten auf). Wer das Vertrauen seines PGP Schlüssels erhöhen möchte, kann diese ebenfalls signieren lassen.

Alle Themen könnt ihr unter Openlab 02 - Workshop Verschlüsselung nachlesen. Wir freuen uns auf deine Anmeldung und Teilnahme. Wer sich bei einem Thema noch einbringen möchtet, meldet sich bitte bei Ralph, Thomas oder Mathias 19:31, 18. Feb 2009 (CET). Inbesondere wird noch jemand gesucht, der das PGP Keysigning vorbereitet.

Anmeldung zum OpenLab #2 kann man sich hier. Ich weiss es noch nicht so genau, aber vermutlich bin ich auch dort... aber bis dahin müsste ich mich mal bei CAcert anmelden, damit sich das lohnt... ;-)

Kategorie: 
 

Seiten

Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer