Sie sind hier

März 2009

Übercart bald nutzbar

Nachdem ich mir per Sixxs wieder IPv6 Connectivity besorgt habe, hab ich mich mal heute dran gemacht und den Webserver dafür konfiguriert. Allerdings scheint das nicht ganz so einfach zu sein, wenn man ausgiebig VirtualHosts benutzt und dann auch noch SSL.
Wenn man nämlich einen Haufen Listen ip:port Statements in die Config schreibt, kann man die bisherigen <VirtualHosts ip:port> und NameVirtualHost ip:port Statements durch einfache <VirtualHost ∗> und NameVirtualHost ∗ Statements ersetzen. Mal abgesehen von der Tatsache, dass "*" Statements für gewöhnlich nicht so toll sind, funktioniert das soweit auch ganz gut. Nur beim SSL scheitert es dann scheinbar.

Denn bisher hatte ich per Redirect von http://ip:80 auf https://ip:443 umgeleitet. Nur dummerweise bekomme ich dann mit der obigen Lösung einen SSL-Fehler. Der CommonName (CN) des Zertifikats stimme nicht mit dem Server Name überein. Bisher ist mir da auch noch keine Lösung zu eingefallen, wie man die VirtualHosts sowohl auf IPv4 als auch auf IPv6 lauschen lassen und gleichzeitig SSL benutzen kann.

Die andere Alternative ist nämlich, alle Configs sowohl für IPv4 als auch für IPv6 vorzuhalten. Das kann man einigermaßen einfach über ein Script handhaben, das einfach die ipv4:port durch ipv6:port ersetzt. Aber besonders schön finde ich die Lösung nicht. Wer also eine Idee hierzu hat: nur her damit! Ich würde mich freuen! :-)

Ebenso würde ich mich über Feedback freuen, ob z.B. das Blog auch per IPv6 erreichbar ist?

Kategorie: 

"Allein, allein... "

Wie man auf rufzeichen-online.de lesen kann, soll das Drupal Shopsystem Übercart bald in einer Form vorliegen, die man problemlos in Deutschland bzw. in der EU einsetzen kann:

Die zweite Lücke betraf die in vielen EU-Ländern vorhandene Vorschrift, dass die Mehrwertsteuer an jeder Stelle des Bestellprozesses getrennt ausgewiesen werden muss. Da in den USA diese Notwendigkeit nicht besteht, war das Feature bis jetzt nicht implementiert. Dank des Engagements der europäischen Community, namentlich Alexander Köhnlein hat allerdings das Core-Development-Team von Übercart die Notwendigkeit eingesehen, dies zu ändern. Auf seiner Session auf der Drupalcon in Washington hat Übercart Project Lead Ryan Rzrama nun verkündet, daß die Version 2.0 diese Lücke definitiv beheben wird.

Damit dürfte dann wirklich eines der großen Hemmnisse für Drupal im europäischen Raum entfallen. Man darf gespannt sein! :-)

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: 

Upgrade auf Serendipity 1.4.1

Dear Lazyweb,
some time ago I upgraded my Gallery2 installation to 2.3-1 and since then I'm missing the exif information in the block below the foto. Although the exif plugin is activated and the exif plugin is properly configured (default). The Theme is configured to show "EXIF/IPTC photo info" to show the exif block on photo pages, but as you can see on this example there's no exif data showing up.

The exif console tool is showing the correct information for those images, so I can't figure why gallery2 fails here. Any tips how to get exif information back into my gallery2, dear lazyweb?

Kategorie: 

Bild-Blog für den Nordosten

Heute hab ich mein Blog mal auf Serendipity 1.4.1 geupgraded. Das hat u.a. zur Folge, daß man sich nun auch wieder für Kommentare subscriben kann. Zur Erinnerung: im Oktober ging es durch die Blogosphäre, daß man aufgrund der Benachrichtung bei Kommentaren abgemahnt werden kann. S9y 1.4.x verfügt auch über eine Double-OptIn Option für dieses Problem, so daß ich die Funktion "Subscribe to comments" wieder aktivieren konnte. Die alten Subscriptions sind allerdings gelöscht. Sicher ist sicher.

Außerdem hab ich das Upgrade dazu genutzt, mal ein neues Theme auszuprobieren. So ganz zufrieden bin ich allerdings damit noch nicht, aber das alte hatte ich nun doch schon etwas "über"... Naja, da ich nunmal kein Theme-Designer bin, muss ich mich halt im wesentlichen auf die vorgefertigten Themes beschränken.

S9y ist ja schon eine nette Blog-Software, aber es ist halt zum einen nur eine Blog-Software und zum anderen finde ich die Themes nun nicht so pralle. Insofern kam mir dann heute beim Stöbern durch die vorhandenen Themes der Gedanke, auf Drupal für das Blog zurückzuwechseln. Allerdings ist das halt mit recht hohem Aufwand verbunden, den ich gerne scheue... ;)

Kategorie: 

Probleme mit initramfs nach RAID1 Erweiterung

Wie gestern via mv-spion.de erfahren, setzt sich der Journalist Ulrich Meyke kritisch mit der Berichterstattung der Ostsee-Zeitung auseinander - ähnlich wie es das Bildblog mit der Bild-Zeitung macht. Dies tut er auf:

http://ostsee-zeitung-blog.blogspot.com/

Wie ich bereits in einem vorherigen Artikel kurz geschrieben habe, ist die Situation der Zeitungen hier im Nordosten schon bedenklich. Eigentlich könnte man schon von einem Informationsmonopol in den Händen des Springer-Verlags sprechen. Wie Ulrich in seinem Ostsee-Zeitung-Blog auch sehr schön darlegt, ist die Verwandtschaft zur Bild und dem damit einhergehenden Niveau auch nicht zu verleugnen. Wünschenswert ist, daß das Blog möglichst viele Leser bekommt und Ulrich weiterhin den Unfug aufdeckt, den die OZ häufig verbreitet. Im Grunde sind noch mehr Journalisten wie er wünschenswert.

Update:
Wie in den Kommentaren zu sehen ist, hat Springer seine OZ-Anteile verkauft.

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: 

HowTo: RAID1 auf RAID5 migrieren

As I wrote last week (German), I had the plan to make a RAID5 out of my existing RAID1 after I received my third 1 TB harddisk. Migrating to RAID5 doesn't work online yet, because mdadm doesn't support the use of --grow and --level together, as you can read in the man page when looking for "-l, --level":

-l, --level=
Set raid level. When used with --create, options are: linear, raid0, 0, stripe, raid1, 1, mirror, raid4,
4, raid5, 5, raid6, 6, raid10, 10, multipath, mp, faulty. Obviously some of these are synonymous.

When used with --build, only linear, stripe, raid0, 0, raid1, multipath, mp, and faulty are valid.

Not yet supported with --grow.

But there's always a way to obtain your goal. If you're brave enough you can find the solution by a quick internet search. Ok, I'm not that brave to try this without a backup, but you shouldn't do that kind of work without having a good backup anyway.

But before I describe the way how to do it, as usual a strong disclaimer: use this howto on your own risk! There's no warranty that this will work for you and you should take care to have a backup of your data. Whoever is doing this migration without having a backup risks the loss of all the data!

I'll describe the migration using an example... there are three logical volumes (LVs) with 1 GB in size each. This is enough for testing purposes and demonstrates how the migration works. You can use real partitions like swap partitions if you want. The LVs are r1, r2, and r3 and are within the Volume Group (VG) /dev/vg:

r1 vg -wi-a- 1.00G
r2 vg -wi-a- 1.00G
r3 vg -wi-a- 1.00G

Two of these LVs are being setup for a RAID1 /dev/md5:

[code]
muaddib:/home/ij# mdadm --create /dev/md5 -l 1 -n 2 /dev/vg/r[12]
mdadm: /dev/vg/r1 appears to be part of a raid array:
level=raid1 devices=2 ctime=Thu Feb 26 16:16:59 2009
mdadm: /dev/vg/r2 appears to be part of a raid array:
level=raid1 devices=2 ctime=Thu Feb 26 16:16:59 2009
Continue creating array? yes
mdadm: array /dev/md5 started.
[/code]

The warning to be a part of another raid array can be ignored. It's just a testing array. The result should look similar to:

md5 : active raid1 dm-12[1] dm-11[0]
1048512 blocks [2/2] [UU]
[========>............] resync = 40.2% (422900/1048512) finish=0.7min speed=14096K/sec

Now a filesystem can be created on the raid array and some data can be stored there:

[code]
muaddib:/home/ij# mkfs.xfs -f /dev/md5
meta-data=/dev/md5 isize=256 agcount=4, agsize=65532 blks
= sectsz=512 attr=2
data = bsize=4096 blocks=262128, imaxpct=25
= sunit=0 swidth=0 blks
naming =version 2 bsize=4096 ascii-ci=0
log =internal log bsize=4096 blocks=1200, version=2
= sectsz=512 sunit=0 blks, lazy-count=0
realtime =none extsz=4096 blocks=0, rtextents=0
muaddib:/home/ij# mount /dev/md5 /mnt
muaddib:/home/ij# cp pics/backdrops/*.jpg /mnt/
muaddib:/home/ij# dir /mnt/
amigager_back1.jpg Dansk-Dunes14.jpg Dansk-Nature-2.jpg
CapeCod_085.jpg Dansk-Dunes15.jpg Dansk-Priel.jpg
ct-1-p1600.jpg Dansk-Dunes16.jpg Dansk-Woods-1.jpg
ct-2-p1600.jpg Dansk-Dunes17.jpg earth_lights_lrg.jpg
Dansk-Beach1.jpg Dansk-Dunes18.jpg HanseSail-AlterStrom2.jpg
Dansk-Beach2.jpg Dansk-Dunes2.jpg HanseSail-AlterStrom.jpg
Dansk-Beach3.jpg Dansk-Dunes3.jpg HanseSail-Mast.jpg
Dansk-Beach4.jpg Dansk-Dunes4.jpg HanseSail-Warnemuende.jpg
Dansk-Beach5.jpg Dansk-Dunes5.jpg LinuxInside_p1600.jpg
Dansk-Beachstones.jpg Dansk-Dunes6.jpg prerow.jpg
Dansk-Cliffs.jpg Dansk-Dunes7.jpg sgi-1440.jpg
Dansk-Dunes10.jpg Dansk-Dunes8.jpg sgi.jpg
Dansk-Dunes11.jpg Dansk-Dunes9.jpg Sonnenuntergang-2.jpg
Dansk-Dunes12.jpg Dansk-Dunes.jpg Sonnenuntergang.jpg
Dansk-Dunes13.jpg Dansk-Nature-1.jpg
muaddib:/home/ij# umount /mnt
[/code]

After umounting the real challenge arise: creation of a RAID5 label! Normally this is no issue, but I guess you like your data and think twice before proceeding... but hey! You have a backup anyway, don't you?!

[code]
muaddib:/home/ij# mdadm --create /dev/md5 --level=5 --raid-devices=2 /dev/vg/r[12]
mdadm: /dev/vg/r1 appears to be part of a raid array:
level=raid1 devices=2 ctime=Mon Mar 2 18:18:09 2009
mdadm: /dev/vg/r2 appears to be part of a raid array:
level=raid1 devices=2 ctime=Mon Mar 2 18:18:09 2009
Continue creating array? yes
mdadm: array /dev/md5 started.
muaddib:/home/ij# cat /proc/mdstat
md5 : active (auto-read-only) raid5 dm-12[2](S) dm-11[0]
1048512 blocks level 5, 64k chunk, algorithm 2 [2/1] [U_]
muaddib:/home/ij# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md5 : active raid5 dm-12[2] dm-11[0]
1048512 blocks level 5, 64k chunk, algorithm 2 [2/1] [U_]
[>....................] recovery = 3.1% (33152/1048512) finish=0.5min speed=33152K/sec
[/code]

After stopping /dev/md5 the new RAID5 label can be written. The data ought to be safe because of the RAID5 algorithm when running with 2 disks. To verify the theory you can mount /dev/md5 again. The next steps can be done with the array online.

muaddib:/home/ij# mount /dev/md5 /mnt
muaddib:/home/ij# dir /mnt/
amigager_back1.jpg Dansk-Dunes14.jpg Dansk-Nature-2.jpg
CapeCod_085.jpg Dansk-Dunes15.jpg Dansk-Priel.jpg
ct-1-p1600.jpg Dansk-Dunes16.jpg Dansk-Woods-1.jpg
ct-2-p1600.jpg Dansk-Dunes17.jpg earth_lights_lrg.jpg
Dansk-Beach1.jpg Dansk-Dunes18.jpg HanseSail-AlterStrom2.jpg
Dansk-Beach2.jpg Dansk-Dunes2.jpg HanseSail-AlterStrom.jpg
Dansk-Beach3.jpg Dansk-Dunes3.jpg HanseSail-Mast.jpg
Dansk-Beach4.jpg Dansk-Dunes4.jpg HanseSail-Warnemuende.jpg
Dansk-Beach5.jpg Dansk-Dunes5.jpg LinuxInside_p1600.jpg
Dansk-Beachstones.jpg Dansk-Dunes6.jpg prerow.jpg
Dansk-Cliffs.jpg Dansk-Dunes7.jpg sgi-1440.jpg
Dansk-Dunes10.jpg Dansk-Dunes8.jpg sgi.jpg
Dansk-Dunes11.jpg Dansk-Dunes9.jpg Sonnenuntergang-2.jpg
Dansk-Dunes12.jpg Dansk-Dunes.jpg Sonnenuntergang.jpg
Dansk-Dunes13.jpg Dansk-Nature-1.jpg

The next step is to add the third "disk":

[code]
muaddib:/home/ij# mdadm --add /dev/md5 /dev/vg/r3
mdadm: added /dev/vg/r3
muaddib:/home/ij# cat /proc/mdstat
md5 : active raid5 dm-13[2](S) dm-12[1] dm-11[0]
1048512 blocks level 5, 64k chunk, algorithm 2 [2/2] [UU]
[/code]

That was the first step. As you can see the third "disk" has been added as a spare device. Because we don't want a spare but a RAID5 we need to expand the number of disks to 3 and tell the RAID to grow its capacity:

[code]
muaddib:/home/ij# mdadm --grow /dev/md5 --raid-devices=3
mdadm: Need to backup 128K of critical section..
mdadm: ... critical section passed.
muaddib:/home/ij# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md5 : active raid5 dm-13[2] dm-12[1] dm-11[0]
1048512 blocks super 0.91 level 5, 64k chunk, algorithm 2 [3/3] [UUU]
[>....................] reshape = 3.1% (33472/1048512) finish=3.0min speed=5578K/sec
[/code]

The last two commands were made with the mounted filesystem that just needs to get enlarged. With XFS you make this happen by invoking xfs_growfs:

[code]
muaddib:/home/ij# df -h /mnt
Filesystem Size Used Avail Use% Mounted on
/dev/md5 1020M 21M 1000M 2% /mnt
muaddib:/home/ij# xfs_growfs /mnt
meta-data=/dev/md5 isize=256 agcount=4, agsize=65532 blks
= sectsz=512 attr=2
data = bsize=4096 blocks=262128, imaxpct=25
= sunit=0 swidth=0 blks
naming =version 2 bsize=4096 ascii-ci=0
log =internal bsize=4096 blocks=1200, version=2
= sectsz=512 sunit=0 blks, lazy-count=0
realtime =none extsz=4096 blocks=0, rtextents=0
data blocks changed from 262128 to 524256
muaddib:/home/ij# df -h /mnt
Filesystem Size Used Avail Use% Mounted on
/dev/md5 2.0G 21M 2.0G 1% /mnt
[/code]

Done!

If you have an LVM on your RAID you'll need to use the appropriate LVM tools to enlarge the PVs and VGs as well. But the hardest work is already done. The reshaping can take a lot of time, as you can see here:

md4 : active raid5 sda6[0] sdc6[2] sdb6[1]
969161152 blocks super 0.91 level 5, 64k chunk, algorithm 2 [3/3] [UUU]
[>....................] reshape = 2.8% (27990592/969161152) finish=1485.0min speed=10562K/sec

There might be other pitfalls if you change your setup from 2-disk arrays to 3-disk arrays. For example you'll need to adopt the changes to your configuration files like /etc/mdadm/mdadm.conf. But this has not much to do with the migration from RAID1 to RAID5 itself.

Many thanks to Goswin Brederlow for his advice and writing a wishlist bug: #517731

Kategorie: 

Wieder zurück!

Wie ich letzte Woche bereits angedeutet habe, hatte ich nach dem Erhalt meiner dritten 1 TB Platte vor, aus meinem RAID1 ein RAID5 zu machen. Das geht zwar derzeit leider nicht online, weil mdadm nicht die gleichzeitige Verwendung von --grow und --level zuläßt, wie man in der man page bei "-l, --level" nachlesen kann:

-l, --level=
Set raid level. When used with --create, options are: linear, raid0, 0, stripe, raid1, 1, mirror, raid4,
4, raid5, 5, raid6, 6, raid10, 10, multipath, mp, faulty. Obviously some of these are synonymous.

When used with --build, only linear, stripe, raid0, 0, raid1, multipath, mp, and faulty are valid.

Not yet supported with --grow.

Aber es gibt durchaus einen Weg, das gewünschte Ziel zu erreichen, indem man ein wenig im Internet sucht und ein bißchen wagemutig ist. Ok, ich war nicht ganz so wagemutig, das ganze ohne Backup durchzuführen, aber sowas sollte man ja grundsätzlich nicht ohne Backup machen. Das ist dann auch der Grund, warum die Durchführung dann bis nach dem Wochenende warten mußte.

Bevor ich zur Vorgehensweise komme, noch einmal eine gründliche Warnung: Ich übernehme keine Gewähr für die Richtigkeit der Angaben, noch für das fehlerfrei Funktionieren der einzelnen Schritte. Und wer das ganze ohne Backup macht, ist sowieso selber schuld, wenn er seine Daten komplett verliert!

Ich führe das mal an einem Beispiel vor... gegeben sind drei Logical Volumes (LVs) zu je 1 GB Größe. Das reicht völlig zum Testen und demonstriert dennoch die Vorgehensweise. Alternative kann man natürlich auch irgendwelche anderen Partitionen (Swap o.ä.) nehmen. Die LVs heissen bei mir r1, r2, r3 und befinden sich in der Volume Group (VG) /dev/vg:

r1 vg -wi-a- 1.00G
r2 vg -wi-a- 1.00G
r3 vg -wi-a- 1.00G

Zwei dieser LVs fasse ich nun erst einmal zu einem RAID1 (/dev/md5)zusammen:

[code]
muaddib:/home/ij# mdadm --create /dev/md5 -l 1 -n 2 /dev/vg/r[12]
mdadm: /dev/vg/r1 appears to be part of a raid array:
level=raid1 devices=2 ctime=Thu Feb 26 16:16:59 2009
mdadm: /dev/vg/r2 appears to be part of a raid array:
level=raid1 devices=2 ctime=Thu Feb 26 16:16:59 2009
Continue creating array? yes
mdadm: array /dev/md5 started.
[/code]

Die Warnung, daß die LVs bereits zu einem RAID gehören ignoriere ich einfach mal... Das Resultat sieht dann in etwa so aus:

md5 : active raid1 dm-12[1] dm-11[0]
1048512 blocks [2/2] [UU]
[========>............] resync = 40.2% (422900/1048512) finish=0.7min speed=14096K/sec

Nun kann man noch ein Filesystem auf dem RAID1 erstellen und mit ein paar Testdaten füllen:

[code]
muaddib:/home/ij# mkfs.xfs -f /dev/md5
meta-data=/dev/md5 isize=256 agcount=4, agsize=65532 blks
= sectsz=512 attr=2
data = bsize=4096 blocks=262128, imaxpct=25
= sunit=0 swidth=0 blks
naming =version 2 bsize=4096 ascii-ci=0
log =internal log bsize=4096 blocks=1200, version=2
= sectsz=512 sunit=0 blks, lazy-count=0
realtime =none extsz=4096 blocks=0, rtextents=0
muaddib:/home/ij# mount /dev/md5 /mnt
muaddib:/home/ij# cp pics/backdrops/*.jpg /mnt/
muaddib:/home/ij# dir /mnt/
amigager_back1.jpg Dansk-Dunes14.jpg Dansk-Nature-2.jpg
CapeCod_085.jpg Dansk-Dunes15.jpg Dansk-Priel.jpg
ct-1-p1600.jpg Dansk-Dunes16.jpg Dansk-Woods-1.jpg
ct-2-p1600.jpg Dansk-Dunes17.jpg earth_lights_lrg.jpg
Dansk-Beach1.jpg Dansk-Dunes18.jpg HanseSail-AlterStrom2.jpg
Dansk-Beach2.jpg Dansk-Dunes2.jpg HanseSail-AlterStrom.jpg
Dansk-Beach3.jpg Dansk-Dunes3.jpg HanseSail-Mast.jpg
Dansk-Beach4.jpg Dansk-Dunes4.jpg HanseSail-Warnemuende.jpg
Dansk-Beach5.jpg Dansk-Dunes5.jpg LinuxInside_p1600.jpg
Dansk-Beachstones.jpg Dansk-Dunes6.jpg prerow.jpg
Dansk-Cliffs.jpg Dansk-Dunes7.jpg sgi-1440.jpg
Dansk-Dunes10.jpg Dansk-Dunes8.jpg sgi.jpg
Dansk-Dunes11.jpg Dansk-Dunes9.jpg Sonnenuntergang-2.jpg
Dansk-Dunes12.jpg Dansk-Dunes.jpg Sonnenuntergang.jpg
Dansk-Dunes13.jpg Dansk-Nature-1.jpg
muaddib:/home/ij# umount /mnt
[/code]

Nach dem umount kommt nun die eigentliche Herausforderung: das Erstellen eines RAID5 Labels! Im Prinzip kein Ding, aber so ohne weiteres mag man sowas natuerlich auch nicht machen. Aber egal, wir haben ja ein Backup, also los geht's!

[code]
muaddib:/home/ij# mdadm --create /dev/md5 --level=5 --raid-devices=2 /dev/vg/r[12]
mdadm: /dev/vg/r1 appears to be part of a raid array:
level=raid1 devices=2 ctime=Mon Mar 2 18:18:09 2009
mdadm: /dev/vg/r2 appears to be part of a raid array:
level=raid1 devices=2 ctime=Mon Mar 2 18:18:09 2009
Continue creating array? yes
mdadm: array /dev/md5 started.
muaddib:/home/ij# cat /proc/mdstat
md5 : active (auto-read-only) raid5 dm-12[2](S) dm-11[0]
1048512 blocks level 5, 64k chunk, algorithm 2 [2/1] [U_]
muaddib:/home/ij# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md5 : active raid5 dm-12[2] dm-11[0]
1048512 blocks level 5, 64k chunk, algorithm 2 [2/1] [U_]
[>....................] recovery = 3.1% (33152/1048512) finish=0.5min speed=33152K/sec
[/code]

Nachdem man /dev/md5 erst gestoppt hat, kann man ein RAID5 Label draufschreiben. Die Daten bleiben aufgrund der Besonderheit des RAID5 Algorithmus' mit 2 Platten erhalten. Zur Überprüfung dieser gewagten These kann man /dev/md5 wieder mounten. Der Rest geht wieder online im Betrieb, aber schauen wir erstmal nach:

muaddib:/home/ij# mount /dev/md5 /mnt
muaddib:/home/ij# dir /mnt/
amigager_back1.jpg Dansk-Dunes14.jpg Dansk-Nature-2.jpg
CapeCod_085.jpg Dansk-Dunes15.jpg Dansk-Priel.jpg
ct-1-p1600.jpg Dansk-Dunes16.jpg Dansk-Woods-1.jpg
ct-2-p1600.jpg Dansk-Dunes17.jpg earth_lights_lrg.jpg
Dansk-Beach1.jpg Dansk-Dunes18.jpg HanseSail-AlterStrom2.jpg
Dansk-Beach2.jpg Dansk-Dunes2.jpg HanseSail-AlterStrom.jpg
Dansk-Beach3.jpg Dansk-Dunes3.jpg HanseSail-Mast.jpg
Dansk-Beach4.jpg Dansk-Dunes4.jpg HanseSail-Warnemuende.jpg
Dansk-Beach5.jpg Dansk-Dunes5.jpg LinuxInside_p1600.jpg
Dansk-Beachstones.jpg Dansk-Dunes6.jpg prerow.jpg
Dansk-Cliffs.jpg Dansk-Dunes7.jpg sgi-1440.jpg
Dansk-Dunes10.jpg Dansk-Dunes8.jpg sgi.jpg
Dansk-Dunes11.jpg Dansk-Dunes9.jpg Sonnenuntergang-2.jpg
Dansk-Dunes12.jpg Dansk-Dunes.jpg Sonnenuntergang.jpg
Dansk-Dunes13.jpg Dansk-Nature-1.jpg

Als nächstes muss man dann die dritte "Platte" hinzufügen:

[code]
muaddib:/home/ij# mdadm --add /dev/md5 /dev/vg/r3
mdadm: added /dev/vg/r3
muaddib:/home/ij# cat /proc/mdstat
md5 : active raid5 dm-13[2](S) dm-12[1] dm-11[0]
1048512 blocks level 5, 64k chunk, algorithm 2 [2/2] [UU]
[/code]

Das war der erste Schritt. Wie man sieht, ist die dritte "Platte" als Spare Device eingetragen. Da wir aber kein Spare haben wollen, sondern ein RAID5, erweitern wir zum Schluß die Anzahl der aktiven Platten auf 3 und teilen dem RAID mit, daß es wachsen soll:

[code]
muaddib:/home/ij# mdadm --grow /dev/md5 --raid-devices=3
mdadm: Need to backup 128K of critical section..
mdadm: ... critical section passed.
muaddib:/home/ij# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md5 : active raid5 dm-13[2] dm-12[1] dm-11[0]
1048512 blocks super 0.91 level 5, 64k chunk, algorithm 2 [3/3] [UUU]
[>....................] reshape = 3.1% (33472/1048512) finish=3.0min speed=5578K/sec
[/code]

Die letzten beiden Aktionen fanden mit einem gemounteten Filesystem statt, das nun nur noch vergrößert werden muss. Bei XFS geht das einfach online mittels xfs_growfs:

[code]
muaddib:/home/ij# df -h /mnt
Filesystem Size Used Avail Use% Mounted on
/dev/md5 1020M 21M 1000M 2% /mnt
muaddib:/home/ij# xfs_growfs /mnt
meta-data=/dev/md5 isize=256 agcount=4, agsize=65532 blks
= sectsz=512 attr=2
data = bsize=4096 blocks=262128, imaxpct=25
= sunit=0 swidth=0 blks
naming =version 2 bsize=4096 ascii-ci=0
log =internal bsize=4096 blocks=1200, version=2
= sectsz=512 sunit=0 blks, lazy-count=0
realtime =none extsz=4096 blocks=0, rtextents=0
data blocks changed from 262128 to 524256
muaddib:/home/ij# df -h /mnt
Filesystem Size Used Avail Use% Mounted on
/dev/md5 2.0G 21M 2.0G 1% /mnt
[/code]

Fertig!

Wer noch ein LVM auf dem RAID hat, muss dann noch die entsprechenden LVM Tools bedienen, um PV und VG zu vergrößern. Aber im Prinzip ist die schwierigste Arbeit bereits erledigt. Das Reshapen kann aber durchaus seine Zeit in Anspruch nehmen, wie man meinem RAID5 entnehmen kann:

md4 : active raid5 sda6[0] sdc6[2] sdb6[1]
969161152 blocks super 0.91 level 5, 64k chunk, algorithm 2 [3/3] [UUU]
[>....................] reshape = 2.8% (27990592/969161152) finish=1485.0min speed=10562K/sec

Bei dem ganzen gibt es allerdings auch den einen oder anderen Fallstrick, wenn man von einem 2-disk RAID1 auf ein 3-disk RAID1 wechselt. Unter anderem müssen natürlich noch die Konfigurationsdateien angepaßt werden, z.B. /etc/mdadm/mdadm.conf. Das hat nun weniger was mit dem Reshapen von RAID1 auf RAID5 zu tun, aber ich wollte es nur der Vollständigkeit halber erwähnen. Ein eigener Blog-Artikel hierzu folgt dann auch gleich noch.

Vielen Dank übrigens an Goswin Brederlow für die Tipps und das Schreiben eines Wishlist Bugreports: #517731

In den nächsten Tagen stelle ich eventuell nochmal eine englischsprachige Version hiervon ins Blog. Mal schauen...

Kategorie: 

Seiten

Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer