Plug-and-Pray

RapidShare Premium, wget and your download queue

2010-02-14T09:47:00.012+02:00

So you just bought a RapidShare Premium account and would like to automatize fetching your link list? Here is a very raw solution with cookie-based authentication handled by wget and a download queue in the form of a plain text file.

An overview

The idea for getting your download queue with wget, using your RapidShare Premium account, is very simple. Here are the main steps:

Enable direct downloads from your RapidShare profile;
Make wget save your RapidShare cookie;
Make wget use the cookie to fetch a link;
Paste all your links in a plain text file;
Write a basic bash script that reads the said plain text file – your "download queue".

The step-by-step guide

1. Log into your RapidShare Premium account and go to "Settings". Under the "Configuration" paragraph, you need to tick the "Direct downloads" check box and then click the "Save" button. The direct downloads option means that you will not be shown the free-vs-premium download page each time you open a RapidShare link. You will get the "save as" dialog instead.

2. You need to make wget to store your RapidShare cookie.

wget 
    --save-cookies ~/.rs \ 
    --post-data "login=YOUR_RS_USERNAME&password=YOUR_RS_PASSWORD" \ 
    -O - \ 
    https://ssl.rapidshare.com/cgi-bin/premiumzone.cgi

You obviously need to replace YOUR_RS_USERNAME with your RapidShare user name and YOUR_RS_PASSWORD with the password associated to your Premium account. The cookie will be saved in a new file called .rs, in your home directory. It is now time to adjust the permissions on that file:

chmod 400 ~/.rs

There is one final thing to do here: suppose somebody browses through your command history. You would not want that. So take a look with

history | tail

You will probably see an output such as:

503 ls
504 wget --save-cookies ~/.rs --post-data "login=YOUR_RS_USERNAME&password=YOUR_RS_PASSWORD" -O - https://ssl.rapidshare.com/cgi-bin/premiumzone.cgi
505 chmod 400 ~/.rs
506 history | tail

Notice the "offset" (the number associated to the wget command) – in our example, it is 504. You will just have to delete the command at this offset from your bash history:

history -d 504

3. Now that your RapidShare cookie is saved, you can instruct wget to use it. Here is how you can download a single file using your RapidShare Premium account and wget:

wget --load-cookies ~/.rs URL

(You need to replace URL above with an actual valid RapidShare link.)

4. It is time to build your "download queue". Just paste the RapidShare links you want to download in a plain text file, one URL per line. Your file might be called rs_download_queue.txt and it might look a bit like this:

http://rapidshare.com/files/123456781/archive.part1.rar
http://rapidshare.com/files/123456782/archive.part2.rar
http://rapidshare.com/files/123456783/archive.part3.rar

5. The final step is to wrap up the whole thing and start downloading without further interaction. A very raw solution would be to write a script like this one:

#!/bin/bash

dq="/path/to/rs_download_queue.txt" # your "download queue"
ck="/home/yourusername/.rs"         # your RS cookie from step 2

for line in `seq "$( wc -l "$dq" | awk '{ print $1 }' )"`
do
    URL="$( sed -n ''$line'p' "$dq" )"
    URL="$( echo "$URL" | sed -e 's/^[ \t]*//;s/[ \t]*$//' )"
    if [ "x${URL}" != "x" ]
    then
        wget --load-cookies "$ck" "$URL"
    fi
done

Save this script as rsdq.sh. Do not forget to make it executable:

chmod 755 rsdq.sh

So each time you need to download something, you just have to edit the rs_download_queue.txt file accordingly and then launch the script rsdq.sh that you just wrote.

Caveats

As stated at the beginning of this post, this is a very unsophisticated solution. Since for me it works wonders, I will not bother to improve it, but it is only fair to let you know that:

The script does not check for dead links.
The script provides no way to resume an interrupted download.
The script does not check for the space you have left on the device.
The script does not check whether you still have RapidShare traffic left for the current day.
The script does not parse the "download queue" file in any way other than skip empty lines.

As I said, it works fine for me – as long as I can use it during the RapidShare Happy Hours (when your traffic gets counted only as 10% of the real one), it's enough.

Mass-(re)naming files from .flac tags

2010-02-07T19:58:00.009+02:00

The story is usually the other way around: you have a bunch of correctly named audio files and you want to automatically mass-tag them. Most players and tag editors already allow you to do that.

My problem was the exact reverse of this situation: I had neatly tagged .flac-s and I wanted to rename the files, which were bleakly called split-track01.flac, split-track02.flac etc.

I came up with a handy script that allows me to do just that. In order for it to work, you will of course need the FLAC tools:

sudo aptitude install flac

Note that this script works only for .flac files at the moment (I have not yet taken the time to dig into the differences between ID3v1 and ID3v2 tags for .mp3-s, nor did I figure out how is it that I should decide on which tag version to take into account – in case both are present).

Before proceeding with the actual script, let me explain a bit what it does and how it should be used. Suppose you have a directory with these files (all with their tags in place):

alex@enterprise$ ls -1
cd7split-track05.flac
cd8split-track01.flac
cd8split-track02.flac

You know these files are part of the same album and you want to rename them, according to their tags. Here's what the script does if it is invoked with the --display argument:

alex@enterprise$ track_number=1 ; for track in cd7split-track05.flac cd8split-track01.flac cd8split-track02.flac ; do ./flacrename.sh $track $track_number --display ; track_number=$(($track_number+1)) ; done
cd7split-track05.flac: 01_Anton_Bruckner_-_Symphony_No._9_in_D_minor_-_I._Feierlich._Misterioso.flac
cd8split-track01.flac: 02_Anton_Bruckner_-_Symphony_No._9_in_D_minor_-_II._Scherzo._Bewegt_lebhaft_-_Trio._Schnell.flac
cd8split-track02.flac: 03_Anton_Bruckner_-_Symphony_No._9_in_D_minor_-_III._Adagio._Langsam_feierlich.flac

As you can see, the second argument (the one between the file name and the optional --display) represents the track number that is to be inserted at the beginning of the file name. The above output is just that, an output. No changes have been made upon the files themselves. So now that you've checked and made sure there is no error in the file naming scheme, you can run it without the --display parameter. The files will be renamed:

alex@enterprise$ track_number=1 ; for track in cd7split-track05.flac cd8split-track01.flac cd8split-track02.flac ; do ./flacrename.sh $track $track_number ; track_number=$(($track_number+1)) ; done
alex@enterprise$ ls -1
01_Anton_Bruckner_-_Symphony_No._9_in_D_minor_-_I._Feierlich._Misterioso.flac
02_Anton_Bruckner_-_Symphony_No._9_in_D_minor_-_II._Scherzo._Bewegt_lebhaft_-_Trio._Schnell.flac
03_Anton_Bruckner_-_Symphony_No._9_in_D_minor_-_III._Adagio._Langsam_feierlich.flac

That was the usage part. Here is a short description of what the script actually does:

If the script is called with anything but two or three arguments: a usage reminder is displayed;
If it is called with three arguments but the third one is different from --display: a usage reminder is displayed;
If the second argument (the track number) is not a number or if it is a number less than 1 (i.e. zero or negative): an error message and a usage reminder are displayed;
If the file specified by the first argument does not exist: an error message is displayed;
If the file specified by the first argument is not a valid .flac: an error message is displayed;
The values of the artist, album and track title tags are stored in local variables. The values stored in these variables have two characteristics: all spaces are turned into underscores ('_') and other special characters (that should not appear in a file name) are suppressed;
The new file name is finally constructed from the said variables. If the --display argument is called, the script will only show what the file name(s) would look like, without doing the actual renaming. If the --display argument is not invoked, the renaming will proceed normally.

These being said, here's the script:

#!/bin/bash                                                                                     
# Return codes
# 0 - success 
# 1 - incorrect usage
# 2 - incorrect <track_number> argument
# 3 - file <file_name.flac> not found  
# 4 - file <file_name.flac> not .flac  

function usage() {
    echo "Usage: $0 <file_name.flac> <track_number> [--display]"
    echo ""                                                     
    echo "  e.g. The command "                                  
    echo "       $0 split-track01.flac 3 "                      
    echo "  will read the tags in 'split-track01.flac' and will rename "
    echo "  the file accordingly, preceding it by the specified track "  
    echo "  number – '03' in this case."                            
    echo ""                                                               
    echo "--display    Use this if you only wish to check the resulting "
    echo "             file name, without actually renaming the file."
    echo "             e.g. $0 split-track01.flac 3 --display"                      
}
                                        
function display() {
    echo "$1: $2"       
    exit 0              
}                   

if [ $# -ne 2 ] 
then            
    if [ $# -ne 3 ]
    then           
        usage  
        exit 1 
    else           
        if [ "$3" != "--display" ]
        then                      
            usage             
            exit 1            
        fi                        
    fi                                
fi                                        

if [ "$( expr $2 - $2 2>/dev/null )" != "0" -o $2 -lt 1 ]
then                                                     
    echo "The <track_number> must be a numeric, greater than zero value!"
    echo                                                                 
    usage                                                                
    exit 2                                                               
fi                                                                           

if [ ! -e "$1" ]
then
    echo "The file you specified does not exist."
    exit 3
fi

if [ "$( file "$1" | grep -c "FLAC audio bitstream data" )" -eq 0 ]
then
    echo "The file you specified is not a valid FLAC."
    exit 4
fi

flac_artist="$( metaflac --show-tag=artist "$1" | awk -F= '{ print $2 }' )"
flac_artist="$( echo "$flac_artist" | sed -e 's/\ /_/g' | sed -e "s/'//g" )"
flac_artist="$( echo "$flac_artist" | sed -e 's/[|\/\\",;:?!%&]//g' )"

flac_album="$( metaflac --show-tag=album "$1" | awk -F= '{ print $2 }' )"
flac_album="$( echo "$flac_album" | sed -e 's/\ /_/g' | sed -e "s/'//g" )"
flac_album="$( echo "$flac_album" | sed -e 's/[|\/\\",;:?!%&]//g' )"

flac_title="$( metaflac --show-tag=title "$1" | awk -F= '{ print $2 }' )"
flac_title="$( echo "$flac_title" | sed -e 's/\ /_/g' | sed -e "s/'//g" )"
flac_title="$( echo "$flac_title" | sed -e 's/[|\/\\",;:?!%&]//g' )"

if [ $2 -ge 10 ]
then
    flac_track="$2"
else
    flac_track="0$2"
fi

flac_name="${flac_track}_${flac_artist}_-_${flac_album}_-_${flac_title}.flac"

if [ "$3" == "--display" ]
then
    display "$1" "$flac_name"
fi

# if the execution has reached this line, it means the '--display' argument 
# was not used; proceed with renaming the file

mv "$1" "$flac_name"

exit 0

Splitting and converting large .ape files

2010-02-06T20:07:00.012+02:00

In a previous post I talked about how a large .flac file can be split into the original CD tracks (provided you have a correct .cue file).

Here is how to do the same for a large .ape file.

Installing the mac utility

APE is Monkey's Audio file format for lossless audio compression. It will be a bit of a problem if you want to actually use the Monkey's Audio encoder/decoder, since there is no official Linux port. You can't even officially download the sources, because they're hosted on a Chinese server that drops all non-Chinese incoming traffic (you'd need a Chinese proxy to bypass that).

Not knowing all this, when I found an APE image in my collection I attempted to split it and convert it to flac. Well, here's what happened:

alex@enterprise$ cuebreakpoints CDImage.cue | shnsplit CDImage.ape
shnsplit: warning: failed to read data from input file using format: [ape]
shnsplit: + you may not have permission to read file: [CDImage.ape]
shnsplit: + arguments may be incorrect for decoder: [mac]
shnsplit: + verify that the decoder is installed and in your PATH
shnsplit: + this file may be unsupported, truncated or corrupt
shnsplit: error: cannot continue due to error(s) shown above

After unsuccessfully trying to find the said mac package, I eventually came across this very useful post.

It all boils down to this: either you download the mac 3.99 .deb package for Ubuntu (i386), or you have to get the source mirrored by that guy and compile it yourself.

My case was the lucky one:

wget http://members.iinet.net.au/~aidanjm/mac-3.99-u4_b3-1_i386.deb
sudo dpkg -i mac-3.99.u4_b3_1_i386.deb

If you do not use Ubuntu or Debian or if you use a different architecture from i386, you will need to get the source and compile the mac utility yourself:

sudo aptitude install build-essential nasm
wget http://members.iinet.net.au/~aidanjm/mac-3.99-u4-b5.tar.gz
tar xfz mac-3.99-u4-b5.tar.gz
cd mac-3.99-u4-b5
./configure
make
sudo make install

Splitting the .ape file

You can decompress the file(s) directly:

mac CDImage.ape CDImage.wav -d

Now you can split the .wav file the normal way, converting the parts into .flac files at the same time:

cuebreakpoints CDImage.cue | shnsplit -o flac CDImage.wav

...and add the tags from the .cue sheet:

cuetag CDImage.cue split-track*.flac

(If you need to actually convert .flac files to .mp3-s, check out this post.)

Splitting large .flac files

2010-02-03T06:40:00.006+02:00

Suppose you have a large .flac file and a .cue one (which provides the correct and complete ripping information). The large .flac stands for the whole CD. How to split it into the tracks that should make it up?

0. First off: if there is no .cue file, no splitting is possible!

This being said, we can move on:

1. Install these tools:

sudo aptitude install cuetools shntool

2. Split the file:

cuebreakpoints large_file.cue | shnsplit -o flac large_file.flac

3. Tag the tracks (according to the ripping information present in the .cue file):

cuetag large_file.cue split-track*.flac

This should be it.

How to gobble (GNU scrobble) to Libre.FM using Amarok2

2010-02-02T11:49:00.006+02:00

Remember my Last.FM rant? Ever since, I have not used their service anymore. In the meantime, I found a more open alternative for the ones who like to keep track of their listening habits – it is called Libre.FM and it keeps growing.

One does not scrobble on Libre.FM, but gobbles instead.

It would have all been nice if there wouldn't have been so many issues with clients with poor or no support at all. I discontinued using my Libre.FM account when I switched to Amarok2, which offered no support for Libre.FM. Not any more! It is now possible to submit the metadata in your tracks to your Libre.FM account, even from Amarok2.

Here's a step-by-step guide.

1. Go to Libre.FM and create an account.

2. Configure Amarok: Go to Settings -> Configure Amarok... -> Internet Services -> tick the "Last.fm" check box and click the settings icon next to it. Enter here your Libre.FM username and your Libre.FM password and untick the "Submit tracks" and "Retrieve similar artists" check boxes, then click "OK".

3. Install lastfmsubmitd. If you are using (K)Ubuntu, use this command in a terminal:

sudo aptitude install lastfmsubmitd

When asked, enter audio as the group.

4. Edit /etc/lastfmsubmitd.conf and add the following:

[server]
url=http://turtle.libre.fm/

5. Make these directories accessible:

sudo chmod -R 777 /var/spool/lastfm
sudo chmod -R 777 /var/log/lastfm

6. Download the Amarok2LibreFM script for Amarok2 (no need to unpack it, just leave it as it is).

7. Configure Amarok to use this script: Tools -> Script Manager -> Install Script, then choose the Amarok2LibreFM.amarokscript.tar.gz that you just downloaded.

8. Restart Amarok and you should be able to scrobble/gobble the tracks that you listen to.

Don't know about you, but I'm very glad that Libre.FM is "usable" again.

How to split large files in Linux and *BSD

2009-11-25T15:24:00.005+02:00

Suppose you have a large file that you need to "break down" to smaller pieces and then reconstruct. It's fairly simple, using the split command.

I will only give a brief usage example. For more information, check out man split (and info coreutils 'split invocation' on Linux).

1. Splitting

You split a larger file into smaller ones issuing a command such as:

split -b 100M your.file

The command above will split your.file in 100 megabytes volumes, called by default "xaa", "xab", "xac" and so on.

If you feel you need another "pattern" or prefix, add that string to the end of the command:

split -b 100M your.file file.part.

The above command will split your.file in volumes called "file.part.aa", "file.part.ab" etc. (instead of the default "xaa", "xab" etc.).

If you prefer the suffix (the "increment") to be digits rather than letters, use the -d flag.

split -db 1G your.file file.part.

would produce volumes of your file of exactly 1 gigabyte, called "file.part.00", "file.part.01" etc.

2. Joining

To join the volumes, it is this simple:

cat `echo file.part.* | sort` > your.file.reloaded

Both your.file and your.file.reloaded have the same MD5 sum – they are identical.

IPFW: rule-based forwarding disabled

2009-11-19T17:47:00.004+02:00

If you want to enable IPFW (or load the module) and you get "rule-based forwarding disabled" in dmesg... and you need forwarding, well, that is just too bad. You will need to enable IPFW forwarding support in the kernel.

Yes, you will have to compile a custom FreeBSD kernel.

It's not that awful, actually.

First off, make sure you have the kernel sources (i.e. in /usr/src/sys).

You will be better off if you will run sysinstall beforehand: select "Configure" -> "Distributions" -> "Src" -> select "base" and "sys" and install them.

Right, now you're ready to configure your kernel to support IPFW and forwarding.

cd /usr/src/sys/i386/conf
cp GENERIC NEWKERNEL
vim NEWKERNEL

Here, add the following:

options IPFIREWALL
options IPFIREWALL_VERBOSE
options IPFIREWALL_FORWARD
options IPFIREWALL_VERBOSE_LIMIT=5
options IPFIREWALL_DEFAULT_TO_ACCEPT
options IPDIVERT

Now you should be ready to compile the new kernel:

cd /usr/src
make buildkernel KERNCONF=NEWKERNEL
make installkernel KERNCONF=NEWKERNEL
reboot

Basically, you will now need to explicitly enable IPFW and to point to the location of the file containing its rules. So you can add to your /etc/rc.conf the following:

firewall_enable="YES"
firewall_script="/etc/ipfw.rules"

The command

# ipfw list

will show you which rules are in effect at the moment.

Shockwave content on Linux

2009-11-19T15:07:00.006+02:00

Suppose you have the misfortune of having to access a page which only provides its interactive content in Shockwave, not Flash or Java. A stupid, ugly and slow leftover of old Macromedia (just before they released Shockwave Flash) that should not be supported anymore, anywhere, in my opinion.

If you will try to get the Shockwave Player from Adobe, you will have a lame surprise. They don't offer it for Linux. There are only the Windows and Mac OS versions there.

However, do not despair. There is a way to overcome this. It will only work on Firefox, but it's better than nothing. Here are the steps (the following takes place on my Ubuntu machines):

0. If you haven't already, install Firefox.

1. Install wine:

sudo aptitude install wine

2. Now download and install the Windows version of Firefox (from here); I am not kidding; you will be using wine for this purpose.

3. Install mozplugger (a useful tool that allows you to "embed" other applications in your browser):

sudo aptitude install mozplugger

4. Launch the Windows version of Firefox (using wine) and access Adobe's Shockwave and Flash test page. Install the missing Adobe Shockwave plug-in. When done, close the browser.

5. Edit the file /etc/mozpluggerrc – add these lines at the end:

application/x-director: dir,dcr,dxr,cst,cct,cxt,w3d,fgd,swa: Macromedia Director file
swallow(firefox.exe) fill stream: wine "C:\\Program Files\\Mozilla Firefox\\firefox.exe" -chrome "$file"

If you have a recent Ubuntu (from 9.04 onwards) and a decent Firefox version (at least 3.0.14), you should be able to skip the following step; otherwise, do this:

6. Remove or rename the pluginreg.dat file in Firefox's profile directory:

rm ~/.mozilla/firefox/string.default/pluginreg.dat

mv ~/.mozilla/firefox/string.default/pluginreg.dat ~/.mozilla/firefox/string.default/pluginreg.dat.bck

There you go. Now stupid Shockwave content should at least load for you. If it doesn't, have fun at using your colorful vocabulary when referring to the stupid web developers that made use of Shockwave contents.

Keypad/Numpad gone mad in KDE4

2009-11-02T14:05:00.003+02:00

I upgraded to KDE4 – Kubuntu Karmic Koala (9.10).

All was fine, excepting for the numerical keypad. My notebook's design includes this keypad which allows me to use the digits (when NumLock is on) and the other keys, respectively (Del, Home, End, Page Up, Page Down, Ins) – when the NumLock LED is off.

I found it impossible to get this basic behavior out-of-the-box: I tried for several hours messing up with System Settings > Regional and Language > Keyboard Layout > Advanced > all kinds of XkbOptions.

Nothing seemed to work.

So I finally decided to "remap" these keys as if they were the independent ones (Delete, Home, End, Page Up, Page Down, Insert) from a default keyboard.

"xev" is a useful tool. For instance, pressing the "Home" key on the numpad when NumLock is off will make xev return the following information:

KeyPress event, serial 34, synthetic NO, window 0x5200001,
root 0x116, subw 0x0, time 49770457, (162,-8), root:(166,17),
state 0x0, keycode 79 (keysym 0xff95, KP_Home), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False

Notice that all the keys that were troublesome (that wouldn't "do" anything) were the KP_something ones in this particular case.

My solution was to edit a .Xmodmap file where I re-mapped the keys I was interested in. I then included this file in Xsession's routines:

$ vim ~/.Xmodmap

keycode 79 = Home KP_7 Home KP_7 Home KP_7
keycode 87 = End KP_1 End KP_1 End KP_1
keycode 81 = Prior KP_9 Prior KP_9 Prior KP_9
keycode 89 = Next KP_3 Next KP_3 Next KP_3
keycode 91 = Delete KP_Decimal Delete KP_Decimal
keycode 90 = Insert KP_0 Insert KP_0 Insert KP_0

To quickly check if you achieved the results you were aiming for, run:

xmodmap ~/.Xmodmap

To make the changes permanent (i.e. have them loaded at each login), edit /etc/kde4/kdm/Xsession:

case $SHELL in
[... leave this unchanged ... ]
esac
if [ -f $HOME/.Xmodmap ] ; then
/usr/bin/xmodmap $HOME/.Xmodmap
fi
# invoke global X session script
. /etc/X11/Xsession

Just add the above text (the one in bold) in your /etc/kde4/kdm/Xsession file.

Logout and login again.

Editing Midnight Commander's color scheme

2009-09-06T13:54:00.003+03:00

In a previous post I was sort of laying out a "formula" on how to transform your Midnight Commander default color scheme into a trasnparent skin, without talking too much about how you can change the other colors.

To my great shame, I didn't pay too much attention to this blog or to the comments asking for further advice. I found Mateus' comment rather late (just now!) and decided to dig further, in order to find out how exactly to deal with more refined color changes, while still keeping the transparent background (in both in Midnight Commander and its editor).

So the first thing to know is which are the colors that Midnight Commander supports; the available colors are:

black
gray
lightgray
white
red
brightred
green
brightgreen
blue
brightblue
magenta
brightmagenta
cyan
brightcyan
brown
yellow
default

The "default" color is the one giving out the nice transparency.

Now, there are certain "components" in Midnight Commander's display that can have their colors altered. Here they are:

base_color, normal, selected, marked, markselect, errors, menu, reverse, dnormal, dfocus, dhotnormal, dhotfocus, viewunderline, menuhot, menusel, menuhotsel, helpnormal, helpitalic, helpbold, helplink, helpslink, gauge, input, directory, executable, link, stalelink, device, core, special, editnormal, editbold, editmarked, errdhotnormal, errdhotfocus

Each and every one of these "components" can have its own colors set accordingly to the user's wish. Each component is assigned a color pair and must be followed by a colon (':') in order to separate it from the color pair of the next component. Here's how this basic syntax must look like:

component=foreground_color,background_color:

When you start modifying the color scheme in your Midnight Commander configuration file (located at ~/.mc/ini), you just have to add a section called "[Colors]" and proceed with enumerating the color pairs. So you'd have something like this:

# the rest of your ~/.mc/ini file

[Colors]
component1=foreground_color1,background_color1:...:componentN= foreground_colorN,background_colorN

For increased readability, I will "truncate" that long line, adding a backslash ('\') to indicate that in fact what follows on the next line should be adjacent to the text on the previous line. This being said, the [Colors] section could look like this:

# the rest of your ~/.mc/ini file

[Colors]
component1=foreground_color1,background_color1:\
component2=foreground_color2,background_color2:\
...
componentN=foreground_colorN,background_colorN

Now that you've gotten the hang of this, let's see how the [Colors] section looks like in the default Midnight Commander color scheme (you know, the "ugly" one, with blue and dull cyan):

IMPORTANT NOTE: For visual impact's sake and due to Blogspot breaking long lines, I wrote each color pair on a single row, followed by a backslash ('\'). Please note that this does NOT work in the ~/.mc/ini file, so the final [Colors] section in your Midnight Commander configuration file MUST be a SINGLE line with no spaces and with each color pair separated from the next one by a colon (':').

# the rest of your ~/.mc/ini file

[Colors]
base_color=lightgray,blue:\
normal=lightgray,blue:\
selected=black,cyan:\
marked=yellow,blue:\
markselect=yellow,cyan:\
errors=white,red:\
menu=white,cyan:\
reverse=black,lightgray:\
dnormal=black,lightgray:\
dfocus=black,cyan:\
dhotnormal=blue,lightgray:\
dhotfocus=blue,cyan:\
viewunderline=brightred,blue:\
menuhot=yellow,cyan:\
menusel=white,black:\
menuhotsel=yellow,black:\
helpnormal=black,lightgray:\
helpitalic=red,lightgray:\
helpbold=blue,lightgray:\
helplink=black,cyan:\
helpslink=yellow,blue:\
gauge=white,black:\
input=black,cyan:\
directory=white,blue:\
executable=brightgreen,blue:\
link=lightgray,blue:\
stalelink=brightred,blue:\
device=brightmagenta,blue:\
core=red,blue:\
special=black,blue:\
editnormal=lightgray,blue:\
editbold=yellow,blue:\
editmarked=black,cyan:\
errdhotnormal=yellow,red:\
errdhotfocus=yellow,lightgray

Now let's see. What you want to change first of all is most of the background of these "components", such that the display will be one with a neat looking transparent background. So first of all you might want to make a few changes to these color pairs by replacing the background color "blue" with "default". After doing these changes, your [Colors] section will look a bit like this:

# the rest of your ~/.mc/ini file

[Colors]
base_color=lightgray,default:\
normal=lightgray,default:\
selected=black,cyan:\
marked=yellow,default:\
markselect=yellow,cyan:\
errors=white,red:\
menu=white,cyan:\
reverse=black,lightgray:\
dnormal=black,lightgray:\
dfocus=black,cyan:\
dhotnormal=blue,lightgray:\
dhotfocus=blue,cyan:\
viewunderline=brightred,default:\
menuhot=yellow,cyan:\
menusel=white,black:\
menuhotsel=yellow,black:\
helpnormal=black,lightgray:\
helpitalic=red,lightgray:\
helpbold=blue,lightgray:\
helplink=black,cyan:\
helpslink=yellow,default:\
gauge=white,black:\
input=black,cyan:\
directory=white,default:\
executable=brightgreen,default:\
link=lightgray,default:\
stalelink=brightred,default:\
device=brightmagenta,default:\
core=red,default:\
special=black,default:\
editnormal=lightgray,default:\
editbold=yellow,default:\
editmarked=black,cyan:\
errdhotnormal=yellow,red:\
errdhotfocus=yellow,lightgray

Now you've got the basic "Midnight Commander transparent scheme" that was the result of this post.

Proceeding to Mateus' question, regarding how to change the rest of the colors now, it's about the same as before. What he didn't like there (and as a matter of fact I don't quite like it, either) is the dull cyan that's still seen in the following places:

the bottom line (the one displaying the F1...F10 function keys);
the line that signifies the current selection, the "prompt" which shows you on which file/directory you're "on" at a given moment;
the uppermost line (the "menu" line);
the menus themselves, once you open them.

To "fix" issues 1, 2, and 3 it is sufficient to alter the value of the "selected" parameter. Notice how it is initially

selected=black,cyan:\

My personal choice is to replace the background cyan, which I don't really like, with green. To do this, I'll change this color pair to

selected=black,green:\

You can, of course, change the foreground color as well. For me, it's alright to keep the foreground (the text) "black". You can change it to whatever suits your taste.

To "fix" issue number 4 in the list above, you need to change the "menu" parameter. To get it transparent, just change the "cyan" background to "default". Make other adjustments as you see fit. In other words, change

menu=white,cyan:\

into, for instance,

menu=ligthgray,default:\

However, there are a few "leftovers" from the default color scheme.

One of them is the parameter regarding the hotkeys in the menus (the "underlined" character on most of the menu options, showing you what key you can press in order to access that option faster than by moving to it with the arrow keys). This color pair is called "menuhot". I changed it from

menuhot=yellow,cyan:\

into

menuhot=yellow,default:\

Another thing which might bother you is the color of the line in the panel you're in when you've "selected all" files (when you've pressed the "*" key). This parameter is called "markselect". I changed it from

markselect=yellow,cyan:\

into

markselect=white,green:\

The color pair of the selected buttons in dialogs is called "dfocus". I changed mine from

dfocus=black,cyan:\

into

dfocus=black,green:\

In the "focused" buttons or options, the underlined character is called "dhotfocus". I changed mine from

dhotfocus=blue,cyan:\

into

dhotfocus=brightgreen,green:\

since the background color was already green, after I modified the "dfocus" color pair.

The other buttons or options in the dialogs which have hotkeys assigned to them, but which are not "focused" (the buttons/options that you're not located on at a given moment) are still displayed in blue on a light gray background. This color pair is referred to as "dhotnormal". Since the blue looks a bit odd there, I changed

dhotnormal=blue,lightgray:\

into

dhotnormal=brightgreen,default:\

Well, this is nice, in window titles and on normal (unfocused) hotkeys I get the transparent background. The problem now is that the rest of the dialog window is still light gray. To change this (to make the window transparent as well), you only need to alter the "dnormal" color pair, such as changing it from

dnormal=black,lightgray:\

into

dnormal=white,default:\

You may notice that the input fields stay cyan, as well; you find these fields in quite a lot of dialog boxes. To alter this, I changed

input=black,cyan:\

into

input=black,green:\

One thing which I consider useful is to have symbolic links displayed in bright cyan (as in the colored listings in the terminal). So I just changed

link=lightgray,default:\

into

link=brightcyan,default:\

Now, regarding the rest of the color pairs, I don't really know what they do. However, if at some point after using Midnight Commander more with this new, neat, transparent/green color scheme you'll notice unwanted leftovers, you can try out other changes in the color pairs values, one at a time, until you determine the troublesome one.

After operating the changes above, my [Colors] section in ~/.mc/ini now looks like this:

[Colors]
base_color=lightgray,default:\
normal=lightgray,default:\
selected=black,green:\
marked=yellow,default:\
markselect=white,green:\
errors=white,red:\
menu=lightgray,default:\
reverse=black,lightgray:\
dnormal=white,default:\
dfocus=black,green:\
dhotnormal=brightgreen,default:\
dhotfocus=brightgreen,green:\
viewunderline=brightred,default:\
menuhot=yellow,default:\
menusel=white,black:\
menuhotsel=yellow,black:\
helpnormal=black,lightgray:\
helpitalic=red,lightgray:\
helpbold=blue,lightgray:\
helplink=black,cyan:\
helpslink=yellow,default:\
gauge=white,black:\
input=black,green:\
directory=white,default:\
executable=brightgreen,default:\
link=brightcyan,default:\
stalelink=brightred,default:\
device=brightmagenta,default:\
core=red,default:\
special=black,default:\
editnormal=lightgray,default:\
editbold=yellow,default:\
editmarked=black,cyan:\
errdhotnormal=yellow,red:\
errdhotfocus=yellow,lightgray

I need to direct you to the "IMPORTANT NOTE" above. The final [Colors] section above is written like this - one pair on each row, followed by a backslash - for clarity's sake. The actual final [Colors] section in your ~/.mc/ini file will have to be a one-liner, with no blanks and no backslashes. So it will probably look similar to this:

base_color=lightgray,default:normal=lightgray,default:selected=black,green:marked=yellow,default:markselect=white,green:errors=white,red:menu=lightgray,default:reverse=black,lightgray:dnormal=white,default:dfocus=black,green:dhotnormal=brightgreen,default:dhotfocus=brightgreen,green:viewunderline=brightred,default:menuhot=yellow,default:menusel=white,black:menuhotsel=yellow,black:helpnormal=black,lightgray:helpitalic=red,lightgray:helpbold=blue,lightgray:helplink=black,cyan:helpslink=yellow,default:gauge=white,black:input=black,green:directory=white,default:executable=brightgreen,default:link=brightcyan,default:stalelink=brightred,default:device=brightmagenta,default:core=red,default:special=black,default:editnormal=lightgray,default:editbold=yellow,default:editmarked=black,cyan:errdhotnormal=yellow,red:errdhotfocus=yellow,lightgray

Now, the next time you start mc, the new color scheme will take effect.

As a bonus, here's a picture of how my Midnight Commander looks like, with this new "skin" on:

Core dumps

2009-09-04T15:04:00.002+03:00

Since I'm interested in examining core dumps (in order to submit them to the ones developing the application that crashed) I prefer to keep core dumping enabled at all times on my systems.

Here is a brief hands-on to core dumps management.

To check whether core dump is enabled, do this:

ulimit -c

If the result is '0', the system isn't configured to dump cores. Other values specify how large the core file can get. If you need untruncated dumps, as I do, the best thing to do would be to run:

ulimit -c unlimited

However, this doesn't permanently solve the problem. It will only work under the current user and in the current terminal.

To have core dumping enabled at all times, for all users and on all ttys, you have to set this option in your /etc/security/limits.conf file. Add to the end of this file the following lines:

* - core unlimited
root - core unlimited

Now, the next thing to do is to establish a naming scheme for the cores and a location where you want to have them dumped. Suppose you want to have core dumps in /core; if so, create the directory and then change ownership accordingly (to give your normal, non-root user write permission in that directory):

# mkdir /core
# chown joe:joe /core

The only thing left to do now is to instruct your system to dump cores there and to name them according to your preferences. In order to do this, edit your /etc/sysctl.conf file and insert somewhere a line describing the "core pattern" that you want to use. The available format specifiers for core naming patterns are the following:

%% A single % character
%p PID of dumped process
%u real UID of dumped process
%g real GID of dumped process
%s number of signal causing dump
%t time of dump (seconds since 0:00h, 1 Jan 1970)
%h hostname (same as ’nodename’ returned by uname(2))
%e executable filename

Since I'm interested in my cores to contain information on the name and PID of the process which created them and on the specific signal which led to the core dump, the line that I'd insert in my /etc/sysctl.conf file would be:

kernel.core_pattern = /core/core.%e.%s.%p

To have these changes take effect, you'd have to log out and login again. This is because the file /etc/security/limits.conf has also been altered. If this wouldn't have been the case, in order to reload the new /etc/sysctl.conf file, you'd have only need to run:

sysctl -p

which assumes the new settings are to be reloaded from the default /etc/sysctl.conf. Otherwise,

sysctl -p /path/to/sysctl.conf

would have been needed.

But since you did change both /etc/sysctl.conf and /etc/security/limits.conf, you'll need to log out and login again in order for all changes to take effect.

SSH, backspace and UTF-8

2009-07-02T08:40:00.002+03:00

Just great. If you use UTF-8 characters encoded on more than 1 byte (such as Latin diacritics, Armenian, Japanese etc. characters) and you attempt to hit [backspace] through SSH to delete them, you might be surprised to find out that backspace in SSH only deletes the last byte.

This can lead to a lot of unexpected results in your documents and it can generate a lot of confusion for any app you might be running via SSH.

Case study: the letter "ș" is encoded as "c8 99". On the host machine, backspace deletes both bytes. Via SSH, only the second one ("99") will get deleted.

Let's see what happens if you write "testș[backspace]test".

Note: endline (Ctrl+D) is encoded as "0a".

user@host:~$ cat > test.txt
testș[backspace]test
^d
user@host:~$ hexdump -C test.txt
00000000 74 65 73 74 74 65 73 74 0a |testtest.|
00000009

Great. Now try it via SSH. Just SSH as the same user on the same machine (ssh user@localhost):

user@host:~$ ssh user@localhost
user@localhost's password:
user@host:~$ cat > test.txt
testș[backspace]test
^d
user@host:~$ hexdump -C test.txt
00000000 74 65 73 74 c8 74 65 73 74 0a |test.test.|
0000000a

Notice how

74 65 73 74 74 65 73 74 0a

turned into

74 65 73 74 c8 74 65 73 74 0a

I filed in a bug report on launchpad. I am not yet sure whether I should take it to OpenSSH's bug list directly.

mt-daapd / Firefly media server -- follow-up

2009-06-07T01:49:00.002+03:00

A little while back I was talking very angrily about mt-daapd / Firefly media server.

It just so happened that it was 1) crashing and 2) apparently scanning outside of the directories I told it to scan in.

I started a thread on the Firefly forums.

Taking down every issue one step at a time, it proved that I was in err and that mt-daapd was actually working OK.

What happened was that in one of the directories it was scanning into I had an old backup of root's home directory that I've forgotten about. And there, in '/foo/backup/root/.wine', there was a naughty symbolic link pointing to '/'.

lrwxrwxrwx 1 root root 1 2007-11-11 11:45 /media/sda9/backup/b4gg/root/.wine/dosdevices/z: -> /

So, kids, my advice is that the next time you feel like starting swearing a software for "not doing what it's supposed to do", you double- and triple-check your setup first; there's a big chance that you were the one doing something stupid in the first place. :P

So far, after discovering this... user fault, mt-daapd seems to be working nicely for me. I use the svn-1696 release.

mt-daapd is not the answer

2009-05-29T01:36:00.001+03:00

Depending on how lucky you are, mt-daapd / Firefly Media Server might or might not work for you.

The problem at hand is how to elegantly share media files in your LAN without resorting to NFS exports or Samba shares.

Simple! DAAP! "The best open-source media server, Firefly"! a.k.a. mt-daapd.

Installing and configuring it is really simple:

sudo aptitude install mt-daapd

It should be started already, once the install finishes. If it isn't, however, you can start it with

sudo /etc/init.d/mt-daapd start

Then, the configuration is straight-forward. You can even avoid manually editing .conf files.

For that, you'd just go to http://hostname:3689, which is the default port it runs on.

"hostname" is, of course, the host name of the machine in your LAN that hosts this DAAP server. In other words, the host name of the machine you installed it on. Or its IP, whatever suits you better.

The default login name is "admin" with the password "mt-daapd".

From the web-based administration console of the Firefly server (mt-daapd) you'd just need to go to the "Configuration" tab and specify there a few things, the most important being the directories where you'd want Firefly to search for your music files, the extensions etc.

Then you'd be able to access the DAAP server using a client on the other machines in your LAN.

One such client is Rhythmbox, the default music player in Gnome. In the left pane it would display a "Shares" drop-down (below "Library", "Stores" etc.) and you'd be able to browse the collection on the remote server and copy parts of it into your collection.

Simple, huh?

...If only it mt-daapd wouldn't crash every time it finds a few thousand tracks in its scans!!!

...If only it wouldn't scan outside of the directories I told it to scan!!!

...If only the "most detailed log level" would show me something more useful than:

2009-05-29 01:53:02 (b6c1bb90): Received a message from daap server
2009-05-29 01:53:02 (b6c1bb90): Rendezvous socket closed (daap server crashed?) Aborting.
2009-05-29 01:53:02: Aborting

So, no, mt-daapd is not a solution to my problems.

I'll just go back to the Samba shares and NFS exports... But it's all so lame.

Of course, there might be lots of defenders of mt-daapd who have 2,000 tracks in their collection.

I have 40,000 and that's barely a "big" number.

The irony of these advanced times... we now have storage devices that can hold terabytes of information. However, open-source applications scale to the 2000s information capacity.

Long live alternatives! :-/

However, it seems I'm not the only one who is frustrated in regards to mt-daapd.

Migrating from KMail to Evolution

2009-05-13T00:31:00.001+03:00

I've decided to give Gnome one more go (I've been a KDE user so far) so I installed Ubuntu 9.04 on my laptop. What's more is that I decided to use only GTK applications, nothing Qt whatsoever. At least for a while, to see how it goes : )

So far, nothing but confusion. What was notable though was the painful migration of my e-mails from KMail to Evolution.

Evolution can import inboxes... but only in a few formats.

In simple words, KMail uses the maildir format (each e-mail is an individual file), whereas Evolution uses the mailbox format (the inbox is one huge file where all e-mails are appended).

So, in order to import the e-mails from KMail into Evolution, I first had to convert the maildir-ed e-mails to a big mailbox.

First off, install procmail -- it provides formail (which is an e-mail (re)formatter):

sudo aptitude install procmail

Then, create the following simple script:

#!/bin/bash

# $1 is the file name (e-mail in maildir format);
# $2 is the name of the resulting mbox file.

echo -n "."
cat "$1" | formail -ds >> "$2"

Save it as mdir2mbox.sh and make it executable:

chmod 755 mdir2mbox.sh

What the script does is it accepts a first parameter (which is the path and file name of an e-mail in maildir format) and a second one (which is the name of the resulted mailbox file); it creates a big .mbox file.

Next, KMail keeps the e-mails in /home/yourusername/.kde/share/apps/kmail/mail. Now, we want to create a mailbox for each of the folders you've had in KMail and you're interested in.

Suppose we want to create 5 mailboxes (according to the folders from KMail that you need to import into Evolution): "tech", "announcements", "tasks", "meetings" and "offtopic".

What you need to do is:

for email_folder in tech announcements tasks meetings offtopic ; do echo "=== $email_folder ===" ; find /home/yourusername/.kde/share/apps/kmail/mail/"$email_folder" -type f -exec ./mdir2mbox.sh "{}" "$email_folder.mbox" ";" ; echo ; done

If the above long line looks unreasonable to you, it's because I wrote it like that in order to allow a simple copy/paste in a console. If you feel more comfortable with a proper formatting, here's how it would look like as a script:

#!/bin/bash

# You need to do 2 things here:
# 1. replace the list "tech announcements tasks meetings offtopic"
# with the list of folders in *your* KMail instance;
# 2. replace "/home/yourusername" with the location of your home
# directory and the actual user name you have.

for email_folder in tech announcements tasks meetings offtopic
do
echo "=== $email_folder ==="
find /home/yourusername/.kde/share/apps/kmail/mail/"$email_folder" -type f -exec ./mdir2mbox.sh "{}" "$email_folder.mbox" ";"
echo
done

That's it. Now, go to Evolution: File >> Import... >> Forward >> select the "Import a single file" radio button >> Forward >> click on the "Filename" drop-down and navigate to the place you created your brand new .mbox files and select one of them >> if it's not already selected, select the "Berkeley Mailbox (mbox)" option from the "File type" drop-down >> Forward >> choose the destination folder (where the .mbox will be imported >> Forward >> click "Import".

Asus Pro57Vr notebook (M51VR) and Linux

2009-05-11T00:25:00.002+03:00

I bought this Asus Pro57Vr notebook (scroll and click "Specifications") about 10 days ago; it's reported as M51VR on Ubuntu.

It's very nice, for its price. Plus, I've grown fond of Asus over the past years, due to the great quality/price balance. After I've stuffed my desktop system with a lot of Asus components, I thought I'd buy a laptop from them as well.

Operating system and drivers

I was glad to find it at a local distributor with no operating system installed whatsoever.

Asus recommend Vista for it and of course it forces this upon customers -- the CD with the drivers is for Vista (32b) only. Still, you can download the Windows (XP, 2000 etc.) drivers from their website.

I set it up as a dual boot between Windows 7 RC (which I was curious to try) and Ubuntu 9.04.

I have to mention the fact that on Windows 7 RC I didn't need to install additional drivers - everything was handled by Windows *somehow* and when there were a few unrecognized devices left in "Device Manager", just as I began to wonder how to handle them, the operating system somehow automatically downloaded and installed them. Very nice.

Things that didn't go as expected

Two annoying things here:

1. The ambient light sensor -- it's designed so stupidly -- it's probably meant for outdoors situations (when you have more direct sunlight, the display will be bad so you'd need more brightness and, respectively, when it's not too sunny you can see the screen quite well so you don't need so much brightness).

However, for indoor use, this ambient light sensor behavior makes no sense -- it's quite the opposite! When the lights are turned off, I need more brightness and the other way around.

The thing that is annoying from Asus' part is the fact that, while on Windows turning off the ambient light sensor is done easily ('Fn' key + 'a'), they didn't bother to draw any blue symbol on the "A" key to show you can use it in a "Fn" combination (whereas all other possible "Fn" options are drawn on the keyboard).

On Linux however, surprise! this doesn't work. So you will have to do (as root):

echo 0 > /sys/devices/platform/asus_laptop/ls_switch

in order to turn off the ambient light sensor.

Obviously, this is necessary because as long as the stupid sensor is turned on, you can't adjust the brightness manually.

2. Built-in microphone. As of Ubuntu 9.04 and Alsa v. 1.0.18 (and 1.0.19, which I've also tried), the built-in microphone doesn't work.

The problem is the Intel ICH9 device and the Realtek ALC663 codec.

I've tried editing /etc/modprobe.d/alsa-base.conf and adding (among other things)

options snd-hda-intel model=m51va

also changing the model to the ones available in Alsa's configuration (ALC662/663 section here), but still no go. Also, everything in alsamixer is unmuted and properly volume-d.

It simply won't work. Maybe... someday...

Anyhow, I can always plug in an external microphone (from my headset) -- the jack controller is infallible. Still, this issue is annoying.

Pros

Everything else : ) I really love this notebook. For its price, it does a lot of things.

Goodbye, last.fm!

2009-03-26T23:52:00.001+02:00

After 2.5 years of using last.fm constantly and advocating for it, basically doing free advertising for it to all of my friends, the last.fm staff just took their worst decision ever.

It cost them a bunch of members, including myself.

I used to be "LLRnR" on last.fm. Not any more.

In order to keep providing the best radio service on the web, we need to ask our listeners from countries other than USA, UK and Germany to subscribe for €3.00 per month. In return you’ll get unlimited access to Last.fm Radio, and a promise that we’ll be hard at work improving the service for years to come.

Yes, you guessed it right, I don't live in either of those 3 privileged and Arian places. So I got pissed off. NOT at the fact that I would be required to pay in order to use the radio stations feature, but at the way the author of this post, who is last.fm staff and who reflects last.fm's official views upon its user base, treats -- no, I mean disregards -- people living in the "wrong countries".

I'm not as absurd as some of the folks commenting on the blog entry proved to be -- I know that people in the "wrong countries" are not paying for the ones in the privileged places to listen to the radio stations. This supposition would turn out as false for anyone having the decency of taking a second look at the problem.

My frustration emerges from many other "details":

After being a loyal user who involuntarily beta tested the website and the player, now I'm getting a kick in the butt.
After being a loyal user who provided feedback, now I'm getting a kick in the butt.
After being a loyal user, I'm getting this announcement via a damned blog entry! Hellooooo last.fm staff! it's not as if I'd subscribe to the feed of any blog of any site I own an account on!
After being a loyal user, I could have at least gotten this announcement on-site, in the user dashboard, not on the blog; or a private message; or an e-mail. They can do that when they want to.
The news was posted only 5 days before it is to take effect.
After helping out on the site -- improving wiki entries, submitting photos, adding videos etc. -- now I'm getting a kick in the butt.
After allowing last.fm and audioscrobbler to gather my personal data -- listening habits, personal preferences, this kind of stuff --, after they've used me in order to improve their recommendations system and after I've contributed in my way to their building of a lot of radio stations, I'm now disregarded, getting a kick in the butt and being asked to pay for the things that I helped them build!!

On top of all that, I'm being basically asked to pay some sort of penalty for the fact that I'm not Arian enough to be a user from a country which supports its streaming from ads income.

So, if last.fm is mocking me, then my only option is to screw them and go elsewhere! I deleted my account. And it seems I was not the only one if I was to draw a conclusion from the comments on that article.

I agree no other similar service is as neat as last.fm was, but I can live with it.

As a user, I have my principles.

I can listen to radio stations for free on Deezer or GrooveShark, to only name 2 such free services.

Anyhow, this was a huge disappointment.

As a final note, I know that my way of "protest" is ineffective. I'm sure they did their Maths right and they must have reached a conclusion along the lines of "Even if 95% of our users stop using last.fm and the remaining 5% will either renew their subscriptions, either purchase them, as we are asking, we will still get our profits".

I'm sure they are actually relieved at the fact that they now have a user less - charts, recommendations a.s.o. to be generated for one less user since I deleted my account. However, it's the only position I can take because it's the only way I could have made my protest and my frustration visible.

The only thing I can hope for is that all actual or former last.fm users who feel offended or who feel this crap management decision is not fair will somehow show solidarity and the last.fm guys will record the largest number of deleted accounts over a very short period.

One thing they could have done was to at least provide a text field that was optional to fill in when pushing the "Delete my account!" button. But then again, they really don't give a shit on their users' feedback. So they don't need such a button.

The hell with you, last.fm!

Disclaimer: The hand in the image above is not mine, mkay? I just added the text on the pic. I googled for "middle finger" on images.google.com.

svn bad commit?

2009-02-25T16:32:00.001+02:00

Suppose you do a bad svn commit. Here is a quick hands-on.

Suppose you have the following revisions:

- r532 - a good commit
- r533 - a "bad" commit
- r534 - another good commit

Now, you realize you shouldn't have svn-committed revision number r533.

What to do? Well, "svn revert" will not be of much help here -- you use "svn revert" just if you mess up a file locally and you want to get the correct one from the svn server.

The answer is:

* cd to the working branch, otherwise you'd get:
svn: Cannot replace a directory from within

* from here, run:
svn merge -r 534:532 file.sh

* next, you should see:
U file.sh

* after making sure the updated file.sh is fine, you should commit your changes and you will therefore have the new revision, r535:
svn commit

Pidgin bug -- update

2009-02-19T17:24:00.001+02:00

After more than half of year after noticing the issue and getting frustrated with the "can't set new Yahoo! avatar in Pidgin" bug, it seems that things have finally gotten a move on!

Testing whether the avatar updates for the Yahoo protocol in Pidgin 2.5.4 -- this finally works, with no other user intervention! Just go to Accounts >> Manage accounts and change the display picture.

However, the previous version of Pidgin that I used, 2.4.1, didn't do that automatically. To sum it all up:

The workaround for the avatar not updating for the Yahoo! protocol for Pidgin builds prior to version 2.5.3, was to:

- quit pidgin;
- edit ~/.pidgin/accounts.xml, where I removed the values attached to the Yahoo! account, for the following settings: picture_url, picture_checksum, buddy_icon, picture_expire, and buddy_icon_timestamp.

The next time I ran it and set a picture, the values for the settings mentioned above were computed instantly and handled properly.

Also, the picture displayed as the user avatar on the Yahoo! servers looked fine: http://img.msg.yahoo.com/avatar.php?yids=Your_YM_ID_here.

Midnight Commander transparent color scheme

2008-11-17T16:42:00.002+02:00

Midnight Commander (or "mc") can have transparent panels instead of the ugly, dull default blue. So can "mcedit", its text editor.

Here's how to do it. Edit the file ~/.mc/ini and add at the end the following:

[Colors]
base_color=normal=,default:selected=,:marked=,default:\
markselect=,:menu=,:menuhot=,:menusel=,:\
menuhotsel=,:dnormal=,:dfocus=,:dhotnormal=,:dhotfocus=,:\
input=,:reverse=,:executable=,default:directory=,default:\
link=,default:device=,default:special=,:core=,:helpnormal=,:\
helplink=,:helpslink=,:editnormal=,default:

Note #1: In the above 'code' block, there is only one line below [Colors]. I truncated the line with the backslash because of blogspot rendering issues. You just write all that on one single line, without the "\" (backslash-es).

Note #2: At the end of this line, the "editnormal,=default:" option means that mcedit will have transparent background in your console, as well.

UPDATE: If you want to see a more in-depth look upon color customization in Midnight Commander, check out this post.

Postfix on FreeBSD - Maildir delivery

2008-09-02T14:09:00.001+03:00

Suppose you have a clean FreeBSD install and you want to get Postfix as your MTA.

Current setup:

OS: FreeBSD 7.0-RELEASE
SHELL: bash
no previously installed MTA present on the system

Create a system user, say test. Then create the Maildir for this user:

# su test
$ cd ~
$ mkdir -p Maildir/{cur,new,tmp}
$ chmod -R 700 Maildir
$ exit
#

Then let's get on with the Postfix thing:

# pkg_add -rv postfix

If this line is not present in /etc/rc.conf:

# echo 'sendmail_enable="YES"' >> /etc/rc.conf
# /usr/bin/newaliases
# postconf -e home_mailbox="Maildir/"
# postfix start

You're done. Now every mail sent to a user (who of course has his "Maildir/" in place) will arrive in the /home/user/Maildir/new directory.

Triple boot pain

2008-06-29T15:39:00.002+03:00

Today I went at a friend's place to help him set up a triple boot system. The PC is brand new and bleeding edge (it will be used primarily as a gaming device), but the guy was still curious about Linux. So I told him about Linux in general and offered to install Ubuntu. He agreed and we went on with the partitioning scheme.

The HDD had 500 GB and we agreed to set up the partitions as follows:

* primary partition - 50 GB - Vista Business x64
* primary partition - 50 GB - XP Professional x64
* primary partition - 25 GB - Kubuntu 8.04
* extended partition - ~375 GB
- 4 GB - Linux swap
- the rest - big storage partition

OK, so when all this was settled, I started the Vista install. It went OK, no troubles whatsoever. Then came Kubuntu - all went fine. I used GRUB in order to be able to choose between the two operation systems.

After customizing the two operating systems, adding all the necessary applications etc. we thought we should finish the setup and have XP installed as well.

Surprise! Just after the reboot - after I chose the partition I was going to install XP unto and formatting it as NTFS and after the setup disk copied the necessary files and drivers on the HDD before the graphical installer could be launched - the PC came up with a gross error:

A disk read error has occurred. Press CTRL+ALT+DEL to restart.

"Whoa! And it didn't even get to the bootloader!" I said to myself with disdain.

So, what to do? I googled for the error and came up with an "explanatory" article on the Microsoft support website. In short, you are not supposed to dare to attempt to install another Microsoft Windows operating system after you installed any version of Vista. Hah! What do you think about that?

What to do? I thought about the alternatives. My first go was to try to boot again from the XP install disk and attempt a repair (a "fixmbr" or "fixboot" something). Fired up the XP recovery console, chose the right partition (the one that had the XP GUI installer ready to start if I managed to boot of that HDD) and came to face a horror like surprise... the administrator password, which I didn't set, because I didn't have the chance to, was not blank. Under normal circumstances, I should have been faced with the opportunity to pick (and set) an administrator password after the first boot off the HDD (off the XP partition), but since this didn't happen, I thought the password shouldn't exist. Well, apparently it did. I'm not so much into Windows internals so if anyone has an explanation for this, please let me know (yes, I tried some "admin" and "administrator" variations but they didn't work).

So the XP recovery console repair solution was off the list... moving on.

I was trying with all means necessary to follow Microsoft's indications and completely remove both operating systems and then only install XP (or the 'old' Windows version) and in the end Vista.

So it only seemed natural to load the Kubuntu Live CD and restore GRUB. For this, you need to boot off the Live CD, wait until it loads, start a konsole or a terminal and then

$ sudo grub
grub> find /boot/grub/stage1
grub> root (hd?,?)
grub> setup (hd?)
grub> quit
and then restart. (For more info on restoring GRUB after Windows overwrote the MBR using a Linux Live CD, check here.)

Using the Live CD, I mounted the partition with the Kubuntu install and manually edited /boot/grub/menu.lst in order to add the XP entry there, too.

Then rebooted. Vista was fine, Kubuntu was fine, XP yielded a "NTLDR not found" error. Grrr.

Next off, booted Ubuntu, manually mounted the XP partition, insterted the XP install disk, copied (disk)\i386\ntldr and (disk)\i386\ntdetect.com to the root of the XP filesystem, i.e. something like:
cp /media/cdrom0/i386/ntldr /media/xp
cp /media/cdrom0/i386/ntdetect.com /media/xp

and then rebooted. Now XP didn't complain anymore about the missing NTLDR, but apparently it had no boot.ini file. So I booted in Ubuntu once more, mounted the XP partition once more and wrote a boot.ini file that contained:
[boot loader]
timeout=30
default=multi(0)disk(0)rdisk(0)partition(2)\WINDOWS
[operating systems]
multi(0)disk(0)rdisk(0)partition(2)\WINDOWS="Microsoft Windows XP Professional" /noexecute=optin /fastdetect

The "partition(2)" part there was OK, since XP was installed on the 2nd partition of the HDD.

This way, I finally managed to boot XP and the GUI installer started off the HDD. It all went fine from there on.

Still, this was a challenging experience. Overall, in the end (and in the end solely!) I enjoyed a good laugh on the gay-ness of the whole "Windows Vista no longer starts after you install an earlier version of the Windows operating system in a dual-boot configuration" thing. Mwhaha!

Manually modifying a .deb package

2008-06-26T18:52:00.001+03:00

From time to time, you might be facing a binary .deb package that you have to tweak for suiting your own needs or for testing purposes. By "a binary .deb package" I mean the final .deb, with a few configuration files and pre/post-inst/rm scripts and not the source files for the .deb themselves.

So, what to do if you only want to change, say, the behavior of a postinst file and then have the .deb prepared for installation?

First of all, the .deb itself is a kind of an archive. This is why you can browse its contents while in mc, for instance ("Midnight Commander").

Step 1. So, in order to operate upon the files contained within your .deb, you need to unpack it. Suppose your .deb package is called your_package.deb. You need to unpack it using the ar command, which is part of binutils.

ar x your_package.deb

This will result in 3 files:

debian-binary: ASCII text
control.tar.gz: gzip compressed data, from Unix
data.tar.gz: gzip compressed data, from Unix

Now, a brief explanation on the two gzip files:

data.tar.gz is the archive that contains the files that actually get installed (in /usr or /opt etc.), while control.tar.gz is an archive containing other important files. Usually, this latter archive has to contain:

control: UTF-8 Unicode English text
md5sums: ASCII text (a text file that contains the md5 sum for every file contained within the data.tar.gz archive)
postinst: Bourne shell script text executable (a script that is to be executed after installing the package)
postrm: Bourne shell script text executable (a script that is to be executed after removing the package)
preinst: Bourne shell script text executable (a script that is to be executed before installing the package)
prerm: Bourne shell script text executable (a script that is to be executed before removing the package)

Just a quick note: it's not necessary to have all of the preinst, postinst, prerm and postrm scripts (sometimes there's no need for some of them and they can be omitted).

Step 2. OK so now that you've gotten this straighted out, it's time to unpack one of the two archives and modify the file or files you need to customize. Suppose your file is one that actually gets 'installed', so it's in data.tar.gz. To unpack this archive in a 'safe' way (to be able to easily re-pack it), execute:

mkdir extras-data
cd extras-data
tar xfz ../data.tar.gz

Step 3. Now go on and modify the file or files you need to change.

Step 4. Remember, since you changed the contents of at least one file in the data.tar.gz archive, its md5sums have changed as well. So it's time to update the md5sums file in control.tar.gz.

mkdir extras-control
cd extras-control
tar xfz ../control.tar.gz

Now, edit the file md5sums, carefully replacing each modified file's md5 sum with the new one.

Step 5. Next, repack control.tar.gz:

tar cfz control.tar.gz *
mv control.tar.gz .. # Warning: this will overwrite the original control.tar.gz archive

Step 6. Next step is to repack the data.tar.gz archive:

cd ../extras-data
tar cfz data.tar.gz *
mv data.tar.gz .. # Warning: this will overwrite the original data.tar.gz archive

Step 7. Then clean up:

cd ..
rm -fr extras*

Step 8. The final step is to actually rebuild your .deb package:

ar r your_new_package.deb debian-binary control.tar.gz data.tar.gz

That's it, you're done. You will now have your custom .deb package, called your_new_package.deb.

Good luck.

LATER EDIT: Be careful, when repackaging the ar archive, always do it in the order specified above (i.e. 1) debian-binary, 2) control.tar.gz and 3) data.tar.gz). Otherwise it won't work. I noticed the mistake when a colleague told me the resulted archive is not a valid Debian package if the 'instructions' were followed exactly.

Ubuntu 8.04 Live CD and weird SATA HDD

2008-06-22T16:59:00.001+03:00

Today I went at a friend's to help her set up a new PC in a dual boot configuration (Windows XP, which was already installed, and Kubuntu 8.04).

XP came preinstalled so I burned a CD with Kubuntu 8.04 and booted from it... just to find out that there was no normal way of detecting the HDD as device. Indeed,

sudo fdisk -l

showed nothing at all. Also, in dmesg there were some errors regarding an ATA port error.

So I booted back in XP and saw the HDD model was a HD502IJ Samsung on SATA that just might pose boot problems (not being detected).

I managed to have the HDD detected only by specifying at the boot prompt the option

all_generic_ide

After this, the HDD was visible, its partitions were visible and I could operate on it normally.

Compiling Pidgin MTN

2008-06-10T08:22:00.002+03:00

This post explains how to compile Pidgin from source, but not the stable Pidgin releases available for download on the website; instead, I'm talking about the latest development Pidgin version (often called "Pidgin MTN"), available via Monotone (a distributed version control system). See this post regarding compiling Monotone from source.

Step 1. Install Monotone version 0.36 or newer. If this version is not already available in your distro repositories, you must compile it from source.

Step 2. Think of a place you'll save the Pidgin Monotone database in.

mkdir /root/mtn_dbs
cd /root/mtn_dbs

Step 3. Fetch the Pidgin MTN database archive and unpack it.

wget http://developer.pidgin.im/static/pidgin.mtn.bz2
bzip2 -d pidgin.mtn.bz2

Step 4. MTN pull:

mtn pull -d pidgin.mtn --set-default pidgin.im "im.pidgin.*"

If you get this message:

mtn: misuse: database /root/mtn_dbs/pidgin.mtn is laid out according to an old schema
mtn: misuse: try 'mtn db migrate' to upgrade
mtn: misuse: (this is irreversible; you may want to make a backup copy first)

it means you need to "update" the scheme used by the Pidgin MTN database. Use this:

mtn -d pidgin.mtn db migrate
mtn pull -d pidgin.mtn --set-default pidgin.im "im.pidgin.*"

If everything was OK, you should see something very similar with:

mtn: setting default server to pidgin.im
mtn: setting default branch include pattern to 'im.pidgin.*'
mtn: setting default branch exclude pattern to ''
mtn: doing anonymous pull; use -kKEYNAME if you need authentication
mtn: connecting to pidgin.im
mtn: finding items to synchronize:
mtn: certificates | keys | revisions
mtn: 75,738 | 52 | 25,104
mtn: bytes in | bytes out | certs in | revs in
mtn: 199.8 k | 120.2 k | 137/137 | 34/34
mtn: successful exchange with pidgin.im

Step 5. MTN checkout in order to fetch the latest branches:

mtn -d pidgin.mtn co -b im.pidgin.pidgin _pidgin

This will create a _pidgin directory in your /root/mtn_dbs one.

cd _pidgin

Step 6. If you want full support for ALL features that Pidgin provides, you need to install the dependencies. I can't stress this enough. You won't probably need all of these, but it's just meant as an example. So, on a Debian / Ubuntu system, such as mine, which already has a few compilers and general build tools and gettext installed, the dependencies required to build ALL the Pidgin features will look like:

aptitude install libxss-dev intltool libstartup-notification0-dev libgtkspell-dev libgstreamer0.10-dev libmeanwhile-dev libdbus-glib-1-dev network-manager-dev libperl-dev tcl8.4-dev tk8.4-dev

Step 7. Time to compile Pidgin:

./autogen.sh --enable-debug

Normally, there shouldn't be any troubles if you hadn't missed anything from Step 6. out. (I usually build Pidgin with the "--enable-debug" switch.)

Step 8. If everything went OK in the compile stage, it's time to

make && make install

Your "Pidgin MTN" should now... work, unless you were really unlucky and fetched the sources just when a critical bug infiltrated in the developement process. :-) Good luck bug hunting!

Compile Monotone from source

2008-06-10T00:06:00.001+03:00

The current version of Monotone, a distributed version control system, is 0.40. To compile it from source:

wget http://monotone.ca/downloads/0.40/monotone-0.40.tar.gz
tar xfz monotone-0.40.tar.gz
cd monotone-0.40

You'll need to install its dependencies before compiling it, i.e.:

autoconf
automake
gettext
g++ 3.2 or newer
boost 1.33.0 or newer
zlib 1.1.4 or newer
libiconv

On a Debian / Ubuntu system, you'll need to do:

sudo aptitude install autoconf automake gettext libboost-dev libz-dev g++

Next, we're on to compile it:

./configure && make && make install

Next... erm... learn how to use it?! Here's a comprehensive Monotone manual. Enjoy... or not.

Later edit: Ah, finally, here's an "Essential Monotone" page for foolish mortals.

How to overlap two images using Gimp

2008-06-09T00:09:00.001+03:00

Gimp - one of the greatest professional apps ever to be found out there... professional image manipulation software; and, of course, open source.

Too bad there are a lot of idiots in this world - starting with myself - who don't have the slightest clue on how to use it. I mean, I always loved photography and as a kid I used to play with my grandfather's "borrowed" old Zenit camera, but since photographic films were not cheap and I had no means of editing the photos, I quit. Since then, I've been planning... and planning to get a camera of my own, but since I don't want anything below a SLR - and a decent one is around 1,000 EUR - it'll have to wait. But that's another story...

Getting back to Gimp. My concrete problem was how to get two images of exact size (after adjusting their size such that they "fitted" the dimensions) overlap with an amount of transparency. I'm aware this must be an extremely easy task for anyone just a little bit more photo editing savvy than myself, but anyways - I had no clue what to do so after googling and reading a little bit, I found out.

I'm posting here the "short version", suitable for my concrete issue. (Such that I'll know next time where exactly to go to for instructions.)

Step 1. Get two images and, after making the suitable adjustments for each of them, be sure they have the same width and height. Have both of them opened in Gimp.

In my case, here's where I started from:

The first image:

and the second one:

Step 2. Select the image that will be the "base" one, i.e. the one you want as, say, "background". (In my case, this was the "Matrix" picture.) Next, select "Layer" -> "New Layer...", then give the new layer a name and select "Transparency" in the "Layer Fill Type" section.

Step 3. Naturally, now that you've created the new layer on the base image, you want to paste onto it the overlapping photo. To do this, go to the second photo and copy it ("Edit" -> "Copy") and then come back to the base image and paste it on the new layer ("Edit" -> "Paste").

Step 4. Now you've got the "top" photo over the "base" photo, in a separate layer. The problem is you can't do much on this second layer because, erm, well, it's "floating". You have to make it stay still :-) Go to the "Layer" menu and select "Anchor Layer" from there.

Step 5. Next, you need to add to your overlay ("top") layer what is known as a layer mask. To do this, select from the "Layer" menu "Mask" -> "Add Layer Mask..." and from the options present there, pick "White (full opacity)".

Step 6. Next, you need a gradient on this layer mask in order to "make" the transition between the two images. From Gimp's main window, select from the toolbox the Gradient tool ("Blend tool"). For the purpose of this particular blending, I chose a radial gradient, from light gray to an even lighter gray. The selected fill options are the same as in the image below:

Step 7. Now it's time to actually apply the gradient on the mask layer. I chose to drag a diagonal line in order to apply the radial gradient (such that the radial gradient could cover all the picture). Just drag a line (with the gradient tool selected) on the mask layer, from, say, the upper left corner to the lower right corner.

Step 8. Voilà. The gradient is now applied and the two images should be present in a "blend". The result should be something similar to the picture below:

Step 9. If you're not satisfied with the results, you can tweak various parameters and repeat Step 6. and Step 7. until you get to like the final result.

Step 10. In order to be able to save the resulted picture in an usable image format, you must have only one layer; that is, you need to "flatten the layers" present in the picture. From the "Image" menu, pick "Flatten Image".

Step 11. Now you're ready to save your new picture. Choose "File" -> "Save As..." and set a file name for your picture. (Just make sure you pick "Save As..." instead of "Save", otherwise you'd end up overwriting your original "base" image - in my case, the "Matrix" one.)

I don't know if anyone might find this useful, but as for myself, it's certainly a good idea to keep a good account of new learned "skillz". :-)

Pidgin bug

2008-06-08T12:51:00.001+03:00

While I have to admit that Pidgin is generally speaking a great multi-protocol IM (instant messaging) client, it's got its flaws too... just like any software. And I'm not talking here about the notorious developers / users scandal, resulting in a Pidgin fork because users just wanted a resizable text input field, while the developers said they don't care. I'm not even talking about the lack of voice and web cam support (there's a ticket from the beginning of time there... prioritized as minor).

No, I'm talking about 'ordinary', 'daily life' bugs... such as the old, recurring "why can't I set / see my Yahoo avatar?" issue. While on Gaim I recall it worked with no problems, at a later point in Pidgin developement, users (including myself) got frustrated (well not really, but it's a functionality problem) that they couldn't get Windows Yahoo Messenger users to see their Yahoo avatar set with Pidgin. (Instead, Yahoo Messenger Windows users only saw a black square instead of the picture.)

I searched through the Pidign tickets, saw some "hey, it works" remarks and thought it was a local problem of mine; then forgot about it, I didn't really need to use an avatar. A few days ago though I really meant to set one, and, surprise, the problem popped up again.

I found the ticket again and decided to investigate further. The "Can't set Yahoo avatar" ticket is here, with a descriptive comment from me (llrnr).

Soon after my comment, somebody took care of the issue and closed the ticket with the "Fixed" resolution... still waiting for the fix to be available through SVN, weee! :-D

In short, the problem resided in the way the checksum for the avatar was computed. My "on-the-fly-dumb-end-user-fix" was to look at what another IM client did after I got sure the Yahoo avatar was set OK and visible to any user. So I took a closer look at what Kopete was doing.

In /home/user/.kde/share/config/kopeterc, there were two important variables regarding the Yahoo avatar: iconRemoteUrl and iconCheckSum. While keeping this in mind, I checked out the avatar-related settings for Pidgin, in /home/user/.purple/accounts.xml and it turned out I just had to replace Pidgin's picture_url string with the string I got in the Kopete iconRemoteUrl string and Pidgin's picture_checksum string with what Kopete stored in the iconCheckSum string.

While I can't guarantee this works for everybody, it kind of worked for me... Now I'm waiting for the official fix while enjoying all the thrills and wonders of open source software.

Convert .flac files into .mp3

2008-04-09T06:40:00.003+03:00

In order to convert .flac to .mp3, you'd need to do the following: first cd into the directory with the .flac files, then

for x in *.flac ; do OUTF=`echo "$x" | sed s/\.flac$/.mp3/g` ; flac -c -d "$x" | lame -m j -q 0 -V 0 -s 44.1 - "$OUTF" ; done

Default charset in apache (2)

2008-02-29T20:54:00.005+02:00

Yep, so getting back... apparently I've missed some important hint:

http://www.apache.org/dist/httpd/CHANGES_2.2

This file contains a paragraph I missed:

*) mod_autoindex: Add in Type and Charset options to IndexOptions directive. This allows the admin to explicitly set the content-type and charset of the generated page and is therefore a viable workaround for buggy browsers affected by CVE-2007-4465
(cve.mitre.org). [Jim Jagielski]

Not really obvious, but anyways... they did say something about it after all.
The really useful answer to this issue came from somebody on the httpd mailing lists - I really need to quote this, it's really straightforward:

In earlier versions, mod_autoindex didn't set any charset at all. This meant that AddDefaultCharset, which only works when no other charset is specified, was picked up. But it also meant that no charset was sent at all if AddDefaultCharset wasn't present.
To protect buggy browsers from cross-site scripting (XSS) attacks, all content originated from apache needs to have a charset assigned, so a change was made in 2.2.6 to assign a charset (utf-8 for windows and iso-8859-1 for everything else, if I recall correctly). The charset option was also added to IndexOptions for those who need to override it.
So, yes, the current behavior is expected and correct and the old behavior is wrong. You should use IndexOptions charset= to change the mod_autoindex charset and not AddDefaultCharset.

Default charset in apache

2008-02-28T01:02:00.009+02:00

Darn! I finally got over my problem... so let's get back to the very beginning...

I use apache 2.2.4. I've been using it without a problem for a long time. My needs for apache are very basic: I just need tons of directory listings (indexes) with the ability to follow symbolic links, and ~10 aliases. The files in the directory listings are on my local computer and they usually have "weird" encodings, so I needed to let apache know I need it to use UTF-8 as default charset/encoding. Simple to achieve... or so it seemed: I used to run apache installed via aptitude under /etc/apache2.

In /etc/apache2/apache2.conf there was a line:

Include /etc/apache2/conf.d/

And furthermore, of course,

cat /etc/apache2/conf.d/charset
AddDefaultCharset UTF-8

All was fine until a while ago, when after the last apache2 package update, I realized the AddDefaultCharset directive didn't take effect anymore – no matter what encoding I would have tried to use instead of UTF-8.

First thing I did was go check with the apache documentation... and God saw that it was right! No, wait...

I was playing according to the manual, but somehow things didn't work as expected. I even tried adding the AddDefaultCharset line to /etc/apache2/apache2.conf directly, but to no avail.

Then I looked for an answer in the apache httpd bugs section, on mailing lists, forums... still no result.

Finally, somehow I found the answer (after an hour of frustrated googling)... actually it's not an answer as in: an explanation for why the AddDefaultCharset directive doesn't take effect anymore (this is why I'm labeling this post with "bugs" too), but it's at least a workaround for my problem at hand: my /etc/apache2/apache2.conf needs to have the following line:

IndexOptions Charset=UTF-8

At least now "it works"... I have all directory listings displayed in the UTF-8 encoding, such that all non-Latin content on my server is displayed correctly.

Note #1: Somehow, trying the good ol' AddDefaultCharset directive in apache 1.3 under FreeBSD yields the expected results.

Note #2: Somehow, trying the good ol' AddDefaultCharset directive in apache 2.2.8 (the latest release as of now), compiled from source, still doesn't work.

Webmin in FreeBSD

2008-02-27T07:04:00.002+02:00

Webmin installation in FreeBSD is pretty straightforward:

pkg_add -rv webmin
echo 'webmin_enable="YES"' >> /etc/rc.conf
/usr/local/lib/webmin/setup.sh
/usr/local/etc/rc.d/webmin start

Apache...

2008-02-26T22:40:00.004+02:00

For a wealth of apache documentation: apache.org httpd docs. (Just change '1.3' in the URL into '2.0' or '2.2' for different flavors.)

Note to self: RTFM.

Basic apache configuration in FreeBSD

2008-02-26T21:53:00.003+02:00

So I decided to try out apache in FreeBSD...

pkg_add -rv apache
vi /usr/local/etc/apache/httpd.conf

Added the lines:

ServerName www
BindAddress *

Supposing my hostname is dvorak, I need to edit

vi /etc/hosts

and add the line:

127.0.0.1 dvorak

And now

apachectl start

The DocumentRoot is /usr/local/www/data in this default configuration.

Great. Now it "works" but being given the default config, right now I can't enter non-Latin characters in files/filenames. I'd basically need UTF-8 exported as charset. The solution is to make use of ~/.login_conf.

For a minimalistic ~/.login_conf, I need to do:

echo "me:\" >> ~/.login_conf
echo ":charset=UTF-8:\" >> ~/.login_conf
echo ":lang= en_US.UTF-8" >> ~/.login_conf

Wheee now I can enter stuff such as "şţăîâабкдеф" in the terminal!

More on setting locales (via ~/.login_conf) in the FreeBSD handbook.

Next on, I need to make apache know of UTF-8:

echo "AddDefaultCharset utf-8" >> /usr/local/etc/apache/httpd.conf
apachectl restart

Voilà!

Just one more thing: in order to have apache started automatically at each boot, I need an entry in /etc/rc.conf:

echo 'apache_enable="YES"' >> /etc/rc.conf

procfs and loadavg

2008-02-26T21:21:00.003+02:00

I think that one of the biggest problems somebody with a Linux background faces with FreeBSD is having gotten used to procfs.

Sure nobody is going to stop you from adding

proc /proc procfs rw 0 0

to /etc/fstab and then mount it:

mount proc

But all those useful things in /proc are now elsewhere to be found.

Many of my scripts need loadavg. Now I need to remember to get the 3 loadavg values like this:

load01m=`sysctl vm.loadavg | awk -F{ '{print $2}' | awk '{print $1}'`
load05m=`sysctl vm.loadavg | awk -F{ '{print $2}' | awk '{print $2}'`
load15m=`sysctl vm.loadavg | awk -F{ '{print $2}' | awk '{print $3}'`

Sendmail: Maildir format

2008-02-26T20:40:00.002+02:00

Here's a quick one: on FreeBSD, how to configure sendmail to deliver mail in Maildir format?

...Using procmail for this example.

Let's assume the user in question is called test.

1. First, create a Maildir for the user:

for x in cur new tmp ; do
mkdir -p /home/test/Maildir/${x}
done
chown -R test:test /home/test/Maildir
chmod -R 700 /home/test/Maildir

2. Install procmail and edit the user's .procmailrc file:

pkg_add -rv procmail
echo ":0" >> /home/test/.procmailrc
echo "/home/test/Maildir/" >> /home/test/.procmailrc

3. Tell sendmail to use procmail as delivery agent (suppose my hostname is dvorak):

cd /etc/mail
vi dvorak.mc

Add the line:

FEATURE(local_procmail)dnl

Save, quit; build the new sendmail.cf:

make && make install && make restart

Done. Now sendmail will deliver all mail for test@dvorak in /home/test/Maildir(/new).

PACKAGESITE

2008-02-26T19:35:00.002+02:00

Coming from my Linux background, I expected that after installing FreeBSD and choosing my geographical location – and, most importantly, choosing a local FTP mirror for the bootonly install CD –, somehow the system would "guess" that I'd want to keep the same location when doing further package installs - with pkg_add for instance. Unfortunately, pkg_add goes to the default ftp://ftp.freebsd.org package location and it can take a long time to install a package with lots of dependencies.

After fiddling around I found out there's an environment variable called PACKAGESITE that instructs pkg_add to go to a "package site" designated by the user.

The thing one needs to remember regarding PACKAGESITE is that it needs to containt the full URL to the "Latest/" directory on that FTP mirror.

First of all you will need the list of FreeBSD mirrors. Just pick up your mirror and then proceed to...

Exporting the variable. This depends of course on the shell you're using.

* If using the default csh shell, you will need to setenv:

setenv PACKAGESITE "ftp://ftp1.ro.freebsd.org/pub/FreeBSD/ports/packages/Latest/"

(for instance – just remember not to limit yourself to "ftp://ftpwhatever.country.freebsd.org" because it won't be enough; you need to enter the full path, up to "Latest/", and to also include the trailing slash!)

You obviously don't want to setenv every time you install a package, so you'll need to enter that line in your /root/.cshrc file:

echo 'setenv PACKAGESITE "ftp://ftp1.ro.freebsd.org/pub/FreeBSD/ports/packages/Latest/"' >> /root/.cshrc

* If you're using bash, you'll need to export the variable:

export PACKAGESITE="ftp://ftp1.ro.freebsd.org/pub/FreeBSD/ports/packages/Latest/"

Of course you don't want to do this every time you install a package, therefore you'll need to add this line in your /root/.bash_profile file:

echo 'export PACKAGESITE="ftp://ftp1.ro.freebsd.org/pub/FreeBSD/ports/packages/Latest/"' >> /root/.bash_profile

dpkg-reconfigure locales...

2008-02-26T19:02:00.003+02:00

"Open source features" take N+1 :-)

On a Debian system,

sudo dpkg-reconfigure locales

would prompt you with a nice menu allowing you to select new locales... Unfortunately, this is not the case with Ubuntu. You just get to generate or update the already selected locales. This is actually an Ubuntu bug, confirmed (with status: wishlist).

However, no need to despair - there's actually a fix for this (suitable for scripting automations too).

In /usr/share/i18n/SUPPORTED you get a list of available locales (the same list that on a Debian system comes at sudo dpkg-reconfigure locales as a menu).

You just need to add the lines from /usr/share/i18n/SUPPORTED you're interested in in the file /var/lib/locales/supported.d/local and then run sudo dpkg-reconfigure locales to add the new locales.

As an example, if I'm interested to add all the available Romanian locales on my system I'd need to run as root:

grep ^ro /usr/share/i18n/SUPPORTED >> /var/lib/locales/supported.d/local
dpkg-reconfigure locales

...So, there is a way!

Make Konqueror remember the default view

2008-02-25T22:38:00.002+02:00

One of the 'features' of open-source is this phrase that I'm sure you heard at least once: "Well now... that's not a bug, it's a *feature*!" -- yeah, right!

One of those "features" is the fact that Konqueror doesn't seem to remember the default view I set up in any profile. Namely, when I use Konqueror as a file manager and type something in the address bar, such as ~/tmp, I really want it to display the contents of ~/tmp in "Detailed List View", the way I chose it as default! But it doesn't.

Apparently there's a workaround for this and it's actually a point-and-click solution.

Settings -> Configure Konqueror -> File Associations -> expand "inode" -> select "directory" -> Embedding tab -> Services Preference Order -> click on the view you need ("Detailed List View" in my case) -> click on "Move Up" until it reaches the top of the list -> Apply -> OK.

Whew! That did it.

Convert .wma files into .mp3

2008-02-25T22:31:00.005+02:00

Another thing that's been troubling me regarding audio files is those damn .wma-s that cannot be played by my iPod. So it's time for a handy script that will convert .wma into .mp3:

for x in *.wma ; do mplayer -vo null -vc dummy -af resample=44100 -ao pcm:waveheader "$x" ; lame -m s audiodump.wav -o "${x%wma}mp3" ; rm audiodump.wav ; done

Pretty impressive – lame's manual page deserves a good read.

Convert .m4a files into .mp3

2008-02-25T21:49:00.006+02:00

One of the things that's been troubling me lately has been the fact that on a standard Debian/Ubuntu system I can't seem to be able to edit the tags for the .m4a files I have.

So, in order to edit the tags on the .m4a files... I'd rather convert them into .mp3-s. The way to do this is actually simple.

The only prerequisites are the lame and faad packages, so better have them installed (in the examples that will follow throughout this blog I'll be assuming a Debian or Ubuntu system, featuring the all-mighty aptitude or apt-get):

sudo aptitude install lame faad

Next, use faad and lame for the conversion:

for x in *.m4a ; do faad -o - "$x" | lame -V 0 - "${x%m4a}mp3" ; done

Et voilà! Finally you can remove the .m4a-s if you no longer need them:

rm *m4a

LSCOLORS

2008-02-25T08:30:00.004+02:00

As stated earlier, I came back to the problem of LSCOLORS.

If using bash, in order to get colorful directory listings in FreeBSD the user needs to set the CLICOLOR environment variable to "YES" and export it and would also need to define (and export) the LSCOLORS variable, all inside ~/.bash_profile.

So, how do we define LSCOLORS?

Here's a quick explanation: LSCOLORS is a string made up of 11 "FB" pairs, where F is the foreground color and B is the background color.

The available color codes are:

a -- black

b -- red

c -- green

d -- brown

e -- blue

f -- magenta

g -- cyan

h -- light gray

A -- bold black, usually shows up as dark gray

B -- bold red

C -- bold green

D -- bold brown, usually shows up as yellow

E -- bold blue

F -- bold magenta

G -- bold cyan

H -- bold light gray; looks like bright white

x -- default foreground or background

So now that we've got the color codes, all we need to do is to come up with suitable color pairs for each file type; below is an example of such an association:

DIR=Ex

SYM_LINK=Gx

SOCKET=Fx

PIPE=dx

EXE=Cx

BLOCK_SP=Dx

CHAR_SP=Dx

EXE_SUID=hb

EXE_GUID=ad

DIR_STICKY=Ex

DIR_WO_STICKY=Ex

Next, we want to assign the values above to the LSCOLORS variable and export it, therefore we need to specify:

export LSCOLORS="$DIR$SYM_LINK$SOCKET$PIPE$EXE$BLOCK_SP\

$CHAR_SP$EXE_SUID$EXE_GUID$DIR_STICKY$DIR_WO_STICKY"

And this settles it! Just remember to have somewhere in your ~/.bash_profile a line defining and exporting CLICOLOR as well:

export CLICOLOR="YES"

Logout, login again and you should be able to get your directory listings in color.

NOTE: Above, in the line with export LSCOLORS="...", I used an escape sequences ("\") in order to prevent the breaking of long lines. You, of course, should enter the whole line without ever using "\" and the [return] key.

First customizations

2008-02-24T12:56:00.001+02:00

OK, first things first. For an 'experiment' with FreeBSD I first needed it installed somewhere... for the purpose of my own mental and psychical health, I choose to get FreeBSD running in a virtual machine first.

Since I'm not eager to see it (...yet) as a viable fully fledged desktop system, I was not interested in the X part of this install so I chose a minimal install, by using the "boot only" CD.

As the time of this post, I chose the latest stable release for my i386 architecture, namely the iso I got is 6.3-RELEASE-i386-bootonly.iso. It can be found on any FreeBSD mirror. For a list of available FreeBSD mirrors, check here.

Alright, I got the iso... then what? I needed a virtualisation environment... so after thinking about the bad things I've heard about QEMU and Xen I decided to go for one of the other two decent alternatives - VMware Server and VirtualBox.

I used to use (!) VMware Server before, but I had a few hops with it. First of all, when I first found out about it and decided to give it a go, I had to download it like any foolish mortal would from VMware's website - it was a pretty big tar.gz, a little over 100 MB -, then unpack it and then run vmware-config.pl - their, uhm, "install" script. I always had troubles recompiling the vmmon module after a kernel update, and I also did a lot of system re-installs back then (you know, the old story, small hard disk with lots of partitions... that from time to time needed resizing and stuff). I always forgot to apply the damned vmware-whatever-patch-any-any-update patch (or something like this, anyway) so, being sick of all this stuff, decided to try something a little bit more lightweight and friendly, such as VirtualBox. Sure, VirtualBox was smooth and all... until I noticed some disadvantages. Here are two of them: if I ran some Linux distro inside a virtual machine in VirtualBox, I wasn't able to ssh to it from my own host OS "out-of-the-box" (of course it's possible, but you have to set up bridged networking and I just didn't have the mood then to do it) and the second issue is that... well, VirtualBox can't boot FreeBSD 6.3-RELEASE. (The reason I don't want to use 6.2-RELEASE in VirtualBox is the fact that I can't get on a local FTP mirror the files for the 6.2 release, they only have the stuff for 6.3, so, since I don't want to use the 'multipurpose' FreeBSD FTPs - I need to speed things up, dammit! - it's just gonna have to wait).

Long story short, when I eventually got back to VMware, poof! the magic had happened, I found it in the Ubuntu repos. (Yeah, I currently run Kubuntu 7.10.) So after a smooth vmware-server install it just... "works". NAT networking out of the box and stuff. No more headaches.

Alright, so much for the intro. So I finally had a minimal FreeBSD 6.3 install in a VMware virtual machine. Some of the first customizations:

make sure SSH (and root login) is enabled in the FreeBSD virtual machine:

vi /etc/ssh/sshd_config
Find the line
# PermitRootLogin no
and change it into
PermitRootLogin yes

vi /etc/rc.conf
Add the line
sshd_enable="YES"

Finally,
/etc/rc.d/sshd restart

provide myself with a friendly login:

vi /etc/rc.conf
Find the line
hostname="whatever"
and change it into
hostname="dvorak" # it's obviously just an example...

Then in the guest OS, look in ifconfig's output for a line looking like this one:
inet 192.168.40.129 netmask 0xffffff00 broadcast 192.168.40.255

OK, now I know the guest's address, i.e. 192.168.40.129. In the host OS, edit the /etc/hosts file in order to add the guest's ' ' set:
vi /etc/hosts
Under the line
127.0.0.1 localhost
add a new one:
192.168.40.129 dvorak

Perfect! Now I can simply
ssh root@dvorak
anytime I need

next, I'll want to get bash and add some color to the directory listings...

pkg_add -rv bash
Next, get the $SHELL to default to bash:
chsh -s /usr/local/bin/bash

vi ~/.bash_profile
Add the following lines:
# First, define some useful aliases:
alias ll='ls -l'
alias lh='ls -lh'
alias lA='ls -la'
# Add some color:
CLICOLOR="YES"
export CLICOLOR
LSCOLORS="ExGxFxdxCxDxDxhbadExEx"
export LSCOLORS

Notice how FreeBSD differs in this point from Linux, where:
- I only need ~/.bash_profile to contain... stuff;
- Apart from LSCOLORS, I also need to set CLICOLOR to YES and export it as well.

More info on LSCOLORS in a future post.

next I'll need to get some stuff on my system since, well, at install time I only chose "Minimal" install:

Run (as root)
sysinstall
and from sysinstall's main menu -> Configure -> Distributions -> [ x ] base ; [ x ] man ; [ x ] ports for a start; it's obviously a good idea to select from here [ ] src and, from it, [ x ] base and [ x ] sys - one can never know when kernel recompiling is needed.

OK, suppose that at the previous step I didn't use sysinstall to install the ports collection as well. There is another method to get the ports collection. For this example, I'll use cvsup.

pkg_add -rv cvsup-without-gui

Now, we need to edit the ports-supfile file... first, make a copy of it (and work on the copy):

cp /usr/share/examples/cvsup/ports-supfile /root
vi /root/ports-supfile

Find the line
*default host=CHANGE_THIS.FreeBSD.org
and change it such that it will point to a cvsup mirror near you:
*default host=cvsup1.ro.FreeBSD.org

Next you need to make up your mind - you either get all the ports - in this case save the file and exit - either you want to get just a part of them; if so, find the line
ports-all
and comment it out:
# ports-all
and look below to the list of all the ports that make up ports-all; remove the comment '#' sign if front of the ports you do want to get (and leave the comment '#' sign if front of the ports you don't want), but you need to make sure you enable (i.e. remove '#' in front of) ports-base!

Next, you need to run (-L refers to the level of verbosity, and 2 means 'high'):
cvsup -L 2 /root/ports-supfile
And now go get a cup of tea or something...

Default title for a 1st post (?)

2008-02-22T22:58:00.004+02:00

The next boring step after having finally edited my "Blogger profile" is the first post... so let's get this over with.

Q: Why am I here?
A: I just thought I'll make somebody really angry (sooner or later) for getting such a cool blogspot URL...
A: (The serious version) I need to use FreeBSD at work. Or I try to recall what the procedure to do foo thing on Linux was. So I started this blog as some sort of online "notebook". If it manages to stress or even help somebody else, that's fine by me.

Q: What's this gonna be all about?
A: As stated before, FreeBSD. No, wait. Linux. No, wait. I might occasionally post whatever crosses my head at the moment.

Q: What about the poor visitor, the one reading this crap?
A: Sorry, bud, it wasn't me who landed here in the first place. (I "own" this.)

One more thing: comments are not moderated at the moment. So enjoy it while this lasts, because it might change at some later point.