Installing MySQLdb - the 'easy' way

Just a quick reminder.
If MySQL is installed in non-default directory like '/opt/mysql' the usual sudo easy_install MySQL-python (or similar) won't work. Instead download the tarball package and extract it. In the source directory find the file named 'site.cfg' and edit the line

#mysql_config = /usr/local/bin/mysql_config

to

mysql_config = /path/to/optional/bin/mysql_config

EDIT:
There is more convenient solution to this problem. No need to change the site.cfg file. If symlink to mysql_config file is created in /usr/bin directory, easy_install will run fine.
But I faced another (apparently famous) problem:

>>> import MySQLdb
Traceback (most recent call last):
  File "", line 1, in 
  File "build/bdist.linux-x86_64/egg/MySQLdb/__init__.py", line 19, in 
  File "build/bdist.linux-x86_64/egg/_mysql.py", line 7, in 
  File "build/bdist.linux-x86_64/egg/_mysql.py", line 6, in __bootstrap__
ImportError: libmysqlclient_r.so.16: cannot open shared object file: No such file or directory

... which i fixed typing line:

/opt/mysql/lib

... in /etc/ld.so.conf file and running:

$ sudo ldconfig

Lets see if Django works now? YEP!

Visudo editing

Visudo is a command that opens /etc/sudoers file for editing. Editing sudoers file is essensial if for some reason user needs to be able to execute superuser commands via sudo command. Simple example line to put in /etc/sudoers file might be:

user ALL=(ALL) ALL

Here, user is the username of the user that is being assigned the privilege. For this to apply to a group of users on the machine you would prefix the name with a % (%user). First ALL entry represents the hosts that these permissions apply to. ALL option is always safe to use if the system is local. Second ALL entry in brackets defines what user the first user is applying the command as. In this example ALL option means that user can execute commands as any other user on system. Last ALL entry is a comma separated list of commands that the user will have access to. ALL means that user can execute any command that is privileged to user listed in second entry. Overall, this line is saying user can execute any command as any user on every host on the system simply by providing its password.

Personally, I use the above line on my system, simply because i'm the only user on it and it saves me time, but it isn't really safe on multiuser systems. Another example can be:

user ALL=(root) /usr/bin/apt-get, /sbin/halt

Here, the user can only use apt-get and halt commands as root user using sudo.

Using 'checkinstall' tool with python source packages

Most python modules can be installed using a package management program. Important thing is, this modules can easily be uninstalled the same way. But if a module is only available as gzipped tar file (.tar.gz) source, installation is done using:

$ sudo python setup.py install

But there is no uninstall option and the manual removal of the files seems the only way.
Today I stumbled on the checkinstall tool. Here's what the manual say:

checkinstall is a program that monitors an installation procedure (such as make install, install.sh), and creates a standard package for your distribution (currently deb, rpm and tgz packages are supported) that you can install through your distribution's package management system (dpkg, rpm or installpkg).

Good thing it can also be used on python source packages, and it's really easy:

$ sudo checkinstall python setup.py install

This will prompt user for some answers and best thing is to use the default ones (in other words, just press enter). After this checkinstall will create a standard package file, and install it, in my case a .deb package. The module can now be uninstalled easily with a package management program.

Debian: Setting Up JAVA - 'update-alternatives'

Got back to using Linux for a while now and I came up with some new stuff to put here. So this will be some kinda comeback to blogging since 2008.
This post will be adition to my last one about using update-alternatives command to setup which java VM your Debian system should use. Using this method is sometimes good enough, but for manual installation of java it won't work.
Let's say the java VM is unpacked as:

/opt/jdk1.5.0_09/

To succesfully use this version as default one the java command needs to be installed as a alternative first:

sudo update-alternatives --install /usr/bin/java java /opt/jdk1.5.0_09/bin/java 500

The last argument in the command is priority and it is mandatory. Priority is used when automatic mode for the link group is set. Any random number will do, for example '500'. Personally I don't know much about this so I won't go any further.

Last thing to do is executing one of this commands to use freshly installed java as default:

sudo update-alternatives --set java /opt/jdk1.5.0_09/bin/java
sudo update-alternatives --config java

That's all from me. Hope it helped someone.

Choosing which version of Java JRE system should use

Sometimes a number of various Java Runtime Environment versions is needed to be installed on a Linux system. To chose which one to use as a default use this command:

sudo update-alternatives --config java

An output like this will show up:

There are 6 alternatives which provide `java'.

  Selection    Alternative
-----------------------------------------------
          1    /usr/bin/gij-4.3
          2    /usr/lib/jvm/java-gcj/jre/bin/java
          3    /usr/lib/jvm/java-6-sun/jre/bin/java
*         4    /usr/lib/jvm/java-1.5.0-sun/jre/bin/java
 +        5    /usr/lib/jvm/java-6-openjdk/jre/bin/java
          6    /usr/bin/gij-4.2

Press enter to keep the default[*], or type selection number:

All to do here is enter the number of the selection next to the alternative JRE name and press enter.

Hope this was helpful. Enjoy.

Schedule fsck program to check disks on next reboot

It's not save to run fsck (file system check) while the disks are mounted. But it can be scheduled to run check on the next reboot simply by creating a file named 'forcefsck' on he root partition. Like this:

$ sudo touch /forcefsck

OpenSUSE: Install RPM packages with zypper CLI tool

Open Suse Linux uses RPM packages for software installation. Those files end in .rpm extension.
Most Suse users are familiar with the YaST graphic interface, but sometimes the quicker way to install a RPM package is from command line with the tool named zypper. This tool is similar to apt-get tool that Debian users use to install .deb packages and it uses already configured repositories to fetch packages. I'll explain its basic usage here.
All zypper commands have its longer and readable variant, and its shorter and less readable one. Commands for installing, removing and updating software needs root privileges.

Commands for software management:

Installing software

$ zypper install [package name]
$ zypper in [package name]

Removing software

$ zypper remove [package name]
$ zypper rm [package name]

Updating all installed software

$ zypper update
$ zypper up

Distribution upgrade

$ zypper dist-upgrade
$ zypper dup

Note: All of the above commands require root priviledeges.

Commands for software querying:

Search for packages matching a pattern

$ zypper search [pattern]
$ zypper se [pattern]

Show package information

$ zypper info [package]
$ zypper se [package]

Commands for repository management:

List all repositories

$ zypper repos
$ zypper lr

For all other commands and help type:

$ zypper --help