Archive for January, 2011

Update (2011-04-22): Zach let me know in the meantime that there's a much easier way to implement stickfile in BASH:

0 1 2 3

while true; do inotifywait -q -q -e modify -e delete $2 cp $1 $2 done

Moral of the story: I should have searched for inotify command line which would lead me to inotify-tools which contains inotifywait.

And now to the original post:

My employer uses SonicWALL NetExtender for his VPN needs. Saying that I'm not a fan of IPsec would be definitely an understatement, but my major problem is that NetExtender overwrites my resolv.conf upon every connection which screws the hostname resolution on my LAN from my laptop. chmoding or chowning resolv.conf doesn't help because it gets re-chowned and re-chmoded by NetExtender.

I was thinking about overwriting resolv.conf on a regular basis from a script but it seemed rather inelegant. But how should I do it otherwise? With inotify, of course.

Here's the script I've written which you should save as "stickfile" to a directory that is featured in your $PATH.

0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50

#!/usr/bin/env python
 
import os
from sys import argv, exit
from shutil import copyfile
from pyinotify import *
 
def add_watch():
    global watch_manager, watch_descriptor, file_to_stick
    watches = watch_manager.add_watch(file_to_stick, IN_MODIFY | IN_DELETE_SELF)
    watch_descriptor = watches[file_to_stick]
 
def remove_watch():
    global watch_manager, watch_descriptor
    watch_manager.rm_watch(watch_descriptor)
 
class MyProcessEvent(ProcessEvent):
    def process_IN_DELETE(self, event):
        self.stick_file()
 
    def process_IN_MODIFY(self, event):
        self.stick_file()
 
    def stick_file(self):
        global file_to_stick, file_to_clone
        print 'Sticking %s as %s' % (file_to_clone, file_to_stick)
        remove_watch()
        copyfile(file_to_clone, file_to_stick)
        add_watch()
 
if __name__ == '__main__':
    if len(argv) != 1+2:
        program_name = argv[0]
        print 'Usage %s: FILE-TO-CLONE FILE-TO-STICK' % (program_name)
        exit(1)
 
file_to_clone = argv[1]
file_to_stick = argv[2]
 
watch_manager = WatchManager()
notifier = Notifier(watch_manager, MyProcessEvent())
add_watch()
 
while True:
    try:
        notifier.process_events()
        if notifier.check_events():
            notifier.read_events()
    except KeyboardInterrupt:
        notifier.stop()
        break

After I created a valid resolv.conf and saved it as /etc/resolv.conf.orig I only had to execute the following as root before starting up NetExtender:

0

stickfile /etc/resolv.conf.orig /etc/resolv.conf

I know many geeks. Most of them are smart. Some of them are brilliant. Few of them are world class. And guess what? Many of them blog on a regular basis. These are tech savvy folks who run their blogs on their own (or rented) server for maximum customizability and pay a monthly fee. What do you think, how long will the information they produced survive if some of them get hit by a train? It's very simple. You divide the amount on their bank account with their monthly hosting fees and you got the number of months in question.

What I wanna ultimately conclude is that there are lots of folks who create valuable content on a daily basis and their content is way too much vulnerable.

I was thinking a lot about this issue. I have 350 posts at the moment and although I know that mankind would happily survive without any of them, I feel the need to secure this information just in case.

Since I (and most of the people) use WordPress, I was thinking about a WordPress specific solution. The idea is to dump my self hosted blog to my cloud hosted WordPress.com blog on a regular basis from cron. Of course, there are some drawbacks, like Google may find the mirrored content along or before my primary site and I won't be able to really customize the cloud hosted blog but I think that the benefits outweight the drawbacks.

The term I'm about to coin is the "backup blog" what is a cloud hosted blog where you mirror your content on a regular basis in an automated manner. I'm about to do this but I'm not there yet.

I've just set up sundevil, my first Mini-ITX box which serves as my home server. OpenWrt wasn't enough for my needs anymore because I want to heavily encrypt all my data and I don't wanna make so much compromises.  I plan to use this server as a NAS and file sharing box and I'd like to have another one soon for a different location where I frequently stay.

This box is a rare combination of power efficiency and lots of horsepower featuring:

• D510MO Mini-ITX mainboard with integrated dual core Intel Atom processor
• 2GB DDR2 RAM
• WD20EARS - 2TB big ass HDD
• 12V 80W power supply
• PicoPSU-80 - 12V super-tiny, super-efficient DC-DC ATX power supply

That's all.  It's not worth buying a Mini-ITX enclosure because they're tiny and relatively expensive.  Most of them cannot even house a 3.5'' HDD.  It's better to grab a used ATX box.

I'm very satisfied with this server so far but I was having much headache when setting it up. Booting from USB wasn't possible because of some BIOS bug. I considered netboot install but it's a pain to set it up so I finally bought a DVD writer for this purpose (it almost costs the same as a reader). Another caveat that is worth mentioning that I couldn't boot Ubuntu after installation. Turns out that the GUID partition table that was the default option of the alternate Maverick boot CD probably wasn't supported by the BIOS so I had to chose the traditional MSDOS partition table.

A picture is worth a thousand words people say, let alone a dozen of them.

The CPU has more than enough juice (2 threads per 2 cores).  Thankfully, I won't have to upgrade it for a while.

0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99

# cat /proc/cpuinfo
processor	: 0
vendor_id	: GenuineIntel
cpu family	: 6
model		: 28
model name	: Intel(R) Atom(TM) CPU D510   @ 1.66GHz
stepping	: 10
cpu MHz		: 1666.654
cache size	: 512 KB
physical id	: 0
siblings	: 4
core id		: 0
cpu cores	: 2
apicid		: 0
initial apicid	: 0
fpu		: yes
fpu_exception	: yes
cpuid level	: 10
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good aperfmperf pni dtes64 monitor ds_cpl tm2 ssse3 cx16 xtpr pdcm movbe lahf_lm
bogomips	: 3333.30
clflush size	: 64
cache_alignment	: 64
address sizes	: 36 bits physical, 48 bits virtual
power management:
 
processor	: 1
vendor_id	: GenuineIntel
cpu family	: 6
model		: 28
model name	: Intel(R) Atom(TM) CPU D510   @ 1.66GHz
stepping	: 10
cpu MHz		: 1666.654
cache size	: 512 KB
physical id	: 0
siblings	: 4
core id		: 0
cpu cores	: 2
apicid		: 1
initial apicid	: 1
fpu		: yes
fpu_exception	: yes
cpuid level	: 10
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good aperfmperf pni dtes64 monitor ds_cpl tm2 ssse3 cx16 xtpr pdcm movbe lahf_lm
bogomips	: 3333.38
clflush size	: 64
cache_alignment	: 64
address sizes	: 36 bits physical, 48 bits virtual
power management:
 
processor	: 2
vendor_id	: GenuineIntel
cpu family	: 6
model		: 28
model name	: Intel(R) Atom(TM) CPU D510   @ 1.66GHz
stepping	: 10
cpu MHz		: 1666.654
cache size	: 512 KB
physical id	: 0
siblings	: 4
core id		: 1
cpu cores	: 2
apicid		: 2
initial apicid	: 2
fpu		: yes
fpu_exception	: yes
cpuid level	: 10
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good aperfmperf pni dtes64 monitor ds_cpl tm2 ssse3 cx16 xtpr pdcm movbe lahf_lm
bogomips	: 3333.40
clflush size	: 64
cache_alignment	: 64
address sizes	: 36 bits physical, 48 bits virtual
power management:
 
processor	: 3
vendor_id	: GenuineIntel
cpu family	: 6
model		: 28
model name	: Intel(R) Atom(TM) CPU D510   @ 1.66GHz
stepping	: 10
cpu MHz		: 1666.654
cache size	: 512 KB
physical id	: 0
siblings	: 4
core id		: 1
cpu cores	: 2
apicid		: 3
initial apicid	: 3
fpu		: yes
fpu_exception	: yes
cpuid level	: 10
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good aperfmperf pni dtes64 monitor ds_cpl tm2 ssse3 cx16 xtpr pdcm movbe lahf_lm
bogomips	: 3333.37
clflush size	: 64
cache_alignment	: 64
address sizes	: 36 bits physical, 48 bits virtual
power management:

I've moved it over to Google Code and fixed its help instructions. I've also included builds to the tarball both for i386 and amd64.

I've just moved it over to Google Code and improved its help instructions.

I've been trying to find this out for a while. I have a digicam which produces uncompressed .MOV files which are huge. I wanted a simple way to encode those to MPEG-4 from the command line.

You have to be a rocket scientist to comprehend the command line options of ffmpeg. I finally succeded by encoding a movie using Kdenlive and eventually realized that it can export encoder scripts. Making a flexible script from such an exported script wasn't trivial for me but with some help from the mailing list of the Media Lovin' Toolkit I was able to do it.

Here's my mov2mp4 script:

0
1
2
3
4
5
6
7
8
9
10

#!/bin/bash
 
if [[ "$#" -ne "1" ]]; then
    echo "Usage: $0 input.mov"
    exit
fi
 
input_mov=$1
output_mp4=${input_mov:0:$((${#input_mov}-4))}.mp4
melt $input_mov -profile hdv_720_30p -consumer avformat:$output_mp4 acodec=libmp3lame ab=128k ar=44100 vcodec=libmpeg4 b=6000k &&
rm $input_mov

I have this board for a while so it was time to shoot some images to show its guts. It is currently the best keyboard on the market in my opinion, except that I prefer blue switches. I ordered browns this time because I wanted to try them out.

This board is constructed in a much sturdier way than the Das. You won't break anything when disassembling it because Diatec used thick plastic everywhere without any overhangs.

The brain is the HT82K94E USB Multimedia Keyboard Encoder 8-Bit MCU which is the big brother or HT82K95E which was used in the Das. I'm not sure whether breaking out the MCU was a practical move or a smart sales tactic (to differentiate between the price of the NKRO and non-NKRO version) but it's an interesting solution.