plaes.org | Be free!

I decided to take a peek into Django world and while playing around with tutorial project I decided to use also git for version control.
As basic Django project layout is following:

project/
    __init__.py
    manage.py
    settings.py    # < -- Contains sensitive information
    urls.py

Where settings.py contains sensitive information like usernames/passwords and other data one doesn’t actually want to save in the repository.
But fortunately it’s possible to use external configure file which is included by main configuration file and thanks to Python’s clever exception system, or ImportError exception, we can simply make following modification to settings.py:

diff --git a/project/settings.py b/project/settings.py
index 641c97f..9019d9e 100644
--- a/project/settings.py
+++ b/project/settings.py
@@ -84,4 +84,9 @@ INSTALLED_APPS = (
     'django.contrib.sites',
 )
-
+
+try:
+	import sys
+	from settings_local import *
+except ImportError, e:
+	print "Unable to load local settings: %s" % e
+	sys.exit(1)

Then we create settings_local.py which contains all these defines you do not want to appear inside the repository.

Pic by Timmu

After some fiddling, it works

Although, it doesn’t look as good as Ross’s due to the missing image. Google Maps doesn’t have one yet..

Few days ago I was setting up a machine which was supposed to have two hard disks running in RAID1 (mirror mode). As I do not have much experience with RAIDx stuff I encountered few problems during the setup
My first approach was to create a kernel with embedded initramfs image which worked until it had to mount the filesystems from RAID device, failing with following error:

The filesystem size (according to the superblock) is
212144483 blocks. The physical size of the device is 212144384 blocks.
Either the superblock or the partition table is likely to be corrupt.

Quite quickly we discovered (as I was installing remotely, relying on Taavi feeding me the error messages) when using ext2/ext3 filesystem one has to fix and resize the filesystems before using them in RAID system. This is because the RAID superblock will be written near the end of the partitions thus reducing the physical size of the filesystem. So here it goes:

mdadm --create /dev/mdx --raid-devices=2 /dev/sdax /dev/sdbx
e2fsck -f /dev/mdx
resize2fs /dev/mdx

Before I even tested it I wanted first to try out another trick - I tried the partition type for all raid components to 0xFD. I then quickly made another kernel image without initramfs and booted it.. Voila.. everything worked even without initramfs

So to sum it up:

1. First set the partition type to 0xFD which stands for “Linux RAID autodetect” for all the partitions taking part in the RAID setup.
2. After assigning partitions to RAID, run a forced filesystem check (forced because otherwise utility refuses to check clean filesystem)
3. Resize the partition because added RAID superblock has shrinked the filesystem area…

“64-bit capable” translates as a mode where a 64-bit application/OS can access 64-bit instructions and registers and is also known as “Long mode“.

On Linux machine just check the contents of /proc/cpuinfo. If processor flags contain lm, then your CPU is 64-bit capable.

Also, a little excerpt from Linux Kernel Sources:

#include/asm/cpufeature_32.h
[snip]
#define X86_FEATURE_LM          (1*32+29) /* Long Mode (x86-64) */
[/snip]