Hook’s Humble Homepage

I’m sorry for the recent downtime and any inconveniences this might have caused.

There were two reasons for this.

At first, the thing is that I have a static IP by contract. But due to a misunderstanding between my ISP and me, I assumed that they would issue a static IP via DHPC. What actually happened though was that I was living with dynamic one with a very long timeout period.

So I lived with the same IP for a whole year and only after a longer storm-induced blackout this week, my IP changed. This in turn, of course, made all my domains (including this one) point to a wrong IP.

As luck has it, I just happened to away from home for almost the whole day and unable to identify the issue, since I couldn’t SSH to my box, since that IP was unreachable.

After a (few) quick call(s), I got a fixed IP now actually also reserved at the ISP, I changed my router’s settings from DHCP to fixed IP and updated the DNS’s.

So, from then on, everything should be running fine again, but as lady luck seemed to be at a very lively party and chose to vomit once again on my blue-suede shoes, that wasn’t the case.

Just as everything started to work just fine SW and service wise, enter HW problems.

My DreamPlug server started restarting itself in a random intervals around 4^th of October. Nothing can be seen in the logs and looking at all sorts of stuff it seems like the best bet is a power issue with the device itself¹.

At the moment I’m temporarily hosted again at Kiberpipa².

As soon as I my DreamPlug becomes alive again, I’ll migrate back onto it and things will be fun and cool again :]

hook out → still waiting to negotiate a replacement DreamPlug. But the disk hasn’t died

1. Too tired to write my 2 weeks of trying to pin-point the issue and what all is not the issue. Will share if someone requests it. ↩
2. Thank you Hruške for all the help with the migration ↩

Since today I will move my office every Wednesday from 09:00 to 17:00 CET¹ to the biggest Slovenian hacklab — Cyberpipe.

I’m extremely happy to be back in my hacker’s alma mater and thus in better contact with the local community and general public.

Frist day I’m ending with a much longer workday then planned — which just proves that this was a good decision — and with great collaboration with both Cyberpipe’s old cats and new leadership as well as the community at large. It’s great to see C| being alive and kicking into the new season and to be part of that again. And it’s quite flattering that they put the notice up on their official website already hours before I managed to find time to even blog about this.

After setting up the office there and putting some posters, we carried some FSFE promo material together with a Free Your Android poster upstairs where hundreds of freshmen wait in line to get their phones identified to be able to get public student’s discount for eating out. Especially the FYA flyers have been gratefully taken by some, so I will probably need to re-fill the flyer stand every few days. All the other time was packed with planning and discussing FS-related projects.

hook out → dead tired, but happy

1. i.e. 08:00-16:00 UTC in winter and 07:00-15:00 UTC in summer time ↩

One of great things with stuff being files is that you can simply copy and move them around.

Taking this fact to my advantage, here’s a simple backup system I wrote for my SQLite databases — it’s just a one-liner shell-script inside an fcronjob¹ — and pretty self-explanatory, I hope:

# Backup SQLite
%daily,nice(7),random,mail(no) * 04-05 cp -p /path/to/htdocs/data/owncloud.db /backup/owncloud/$(date +%Y-%m-%d)_ownloud.db
%daily,nice(7),random,mail(no) * 04-05 cp -p /path/to/htdocs/user/habari.db /backup/habari/$(date +%Y-%m-%d)_habari.db

# Clean backup
%monthly,nice(7),mail * * *  rm /backup/habari/$(date -d "2 months ago" "+%Y-%m")-??.habari.db
%monthly,nice(7),mail * * *  rm /backup/owncloud/$(date -d "2 months ago" "+%Y-%m")-??.owncloud.db

The cleaning bit has a failsafe. When I make an important backup (e.g. by hand before messing with something), I append a note to the filename. And the script only deletes files that end with the database name.

For example, if this is the satate of your backups at the moment:

/backup/habari:
2012-09-20_habari.db_first_post
2012-09-21_habari.db_faled_migration
2012-09-23_habari.db_pre-deletion_of_MarkUp
2012-09-24_habari.db_pre-migration_from_Drupal
2012-09-25_habari.db
2012-09-25_habari.db_post-successful_migration_from_Drupal
2012-09-25_habari.db_post-successful_migration_to_matija.suklje.name
2012-09-25_habari.db_pre_migration_to_matija.suklje.name
2012-09-26_habari.db
2012-09-27_habari.db
2012-09-28_habari.db
2012-09-29_habari.db
2012-09-29_habari.db_post_markup_and_link_cleanup
2012-09-29_habari.db_post_markup_link_and_logs_cleanup

/backup/owncloud:
2012-09-20_owncloud.db
2012-09-25_ownloud.db_just_a_failsafe_backup
2012-09-26_ownloud.db
2012-09-27_ownloud.db
2012-09-28_ownloud.db
2012-09-29_ownloud.db

…after the cleaning, you would still be left with:

/backup/habari:
2012-09-20_habari.db_first_post
2012-09-21_habari.db_faled_migration
2012-09-23_habari.db_pre-deletion_of_MarkUp
2012-09-24_habari.db_pre-migration_from_Drupal
2012-09-25_habari.db_post-successful_migration_from_Drupal
2012-09-25_habari.db_post-successful_migration_to_matija.suklje.name
2012-09-25_habari.db_pre_migration_to_matija.suklje.name
2012-09-29_habari.db_post_markup_and_link_cleanup
2012-09-29_habari.db_post_markup_link_and_logs_cleanup

/backup/owncloud
2012-09-25_ownloud.db_just_a_failsafe_backup

…quite a simple overview, isn’t it? ☺

hook out → wow, I haven’t done so much admining in aaaageeeeeees …feels good :3

Update 0: Added an actual example.

Update 1: In light of a wider backup plan, I migrated to RSnapshot. I can warmly recommend it.

1. Sure, the same could be done in any Cron, but I prefer FCron. ↩

Woo, that’s went surprisingly smooth!

I’m happy to announce the 4^th incarnation of Hook’s Humble Homepage!

As you can see, the migration from my Drupal website (kindly hosted by Kiberpipa) to a self-hosted Habari is finished and all is well.

Due to the already mentioned limitations of Habari’s Drupal Importer I had to either work around them or get the 3-year old code of the importer changed.

Luckily this simple module to change node types in Drupal was just right for me¹ and I could simply change all the story type nodes on Drupal into blog type nodes. …that solved problem №1 (either stories or blog posts).

As for preparing a single taxonomy to import, I followed this tip on how to merge vocabularies in Drupal with SQL on my Drupal DB. …which solved problem №2 (just one taxonomy structure).

With those two out of the way, problem №3 (comments for either stories or blog posts) was also worked around, so the import could begin…

The import did fail half-way on first try then, but when I re-ran it, it worked just fine. So here we are!

Next steps were to fix by hand all inconsistencies in markup due to different plug-ins being used on Drupal and on Habari, deleting of old spam comments, users, fixing broken links and changing the DNS to point here now. While time consuming, I gladly took this trip down memory lane and I hope I managed to get it right.

What got migrated:

• all posts ☺ — blog and stories;
• pages ☺ — edited and cleaned up;
• taxonomy ☺ — cleaned up and flattened into tags;
• good vibes and a desire to write again ☺.

There are also some things that did not get migrated:

• URL’s ☹ — Drupal’s ?q=node/<number> URL structure is not supported by Habari, but at least everything is here and the new system produces actually meaningful URL’s²;
• users ☹ — I decided to drop these, since a) you don’t need one to write comments; and b) spam bot users were a hundred-fold bigger in numbers than actual users making it a real bother to admin. If you really need one, just ask for one;
• spam ☺ — got rid of all spam and as an added bonus, I am not running any pesky checker if you’re human (or a smart bot). Let’s first see how smart Habari’s stock filter is and if need arises to toughen the barricades, I’ll do it then …In the migration it performed quite well, so I’m hopeful.

Last, but not least, lots of thanks to the wonderful community on #habari and Sam Tuke for all the help and support in making this migration possible.

hook out → nodding approvingly with his cuppa in hand

1. If you need anything even a bit more complex (e.g. you use CCK), you should rather look at Node Convert ↩
2. I made sure that all links on this page point to the right pages. This issue should exist only if you have outdated bookmarks or links that reference here from the outside. ↩

Since my first post on this new website, I tried to migrate the MySQL database from my old Drupal 6.x website. It was a mixed experience that taught me many things…

Regarding databases I learnt, that SQLite fits me just perfectly. It’s very lightweight on the resources and needs no daemon, which makes it ideal for such a small low power ARM as my server¹. Since SQLite stores databases as files, backing it up means just copying the .db file, so writing a backup system in FCron should be easy peasy. It also impressed me how nimble and powerful it is for such a small thing!

As for the migration itself I found a Drupal import plug-in for Habari. After fidling with it for some time and lots of help from kind people on Kiberpipa and Habari IRC channels, I managed to connect to my database and import most of it. Surprisingly that 3 year old code worked just fine, but doesn’t fit my usecase. Namely you can only import one entry type and one taxonomy list at a time, which resulted in lots of missing comments and tags. I hope I’ll manage with my superior lack of coding skill, which I compensate with my boyish charms social engineering skills to hack the importer to my liking — to import it all in one go. Also, probably checkboxes instead of pull-down menues would be better choice in the UI.

In case you were (un)lucky enough to see all the 3/4-migrated stuff here a few days ago, I hope this explains it. I restored from a backup today and hope to get it right soon. I’m optimistic :]

Some small observations I made during this experiment:

• SSH tunnelling is very useful — e.g. if your provider only allows local access to your database and you have ssh access, you can access the database remotely via an ssh tunnel;

• creating SSH tunnels is dead easy once someone explains it to you: e.g.

  1. log into the box you want to use the tunnelled service (e.g. MySQL) from;

  2. ssh to the remote server with²:

     ssh -L 3007:localhost:3306 user@example.com
     

  3. now if you connect to port 3307 on your localhost (the box in step 1.) you will be accessing port 3306 on example.org and this inside a secure and encrypted connection.
• Distcc as a client is very easy to set up, amazing when it works, but counterproductive when the nodes are not accessible, as it takes a even longer and under a bigger load³. So I guess distcc is great as long as you have stable nodes to count on.
• Sqliteman is a very intuitive tool to edit SQLite databases.

I really love Habari’s admin UI! I know that as with any software there will be days when I’ll just want to strangle it, but right now, I adore it :3 Oh, did I mention how awesome it is to be able to navigate the menu with keyboard? Everything is just 1 or 2 keypresses away! Brilliant!

In conclusion: I’m not rueing the day I got my PlugComputer — I learned that just by using a bit more streamlined and lightweight code, you can squeeze a hell lot out of a small ARM.

hook out → right, back to my books

1. I have a small DreamPlug plug computer. I wrote an FAQ about it, if you’re interested in the details. ↩
2. Of course, change the user, example.com and ports accordingly ↩
3. As an example, emerging PHP on this box with -j1 takes 1h30’, with a working distcc node in Amazon EC2 and -j8 it takes 40’, but if that one’s down it takes 2h ↩