yum spookiness

Recently, I started getting tracebacks on a simple "yum update"

# yum update -y
Loaded plugins: fastestmirror, presto, refresh-packagekit
Setting up Update Process
Traceback (most recent call last):
  File "/usr/bin/yum", line 29, in <module>
    yummain.user_main(sys.argv[1:], exit_code=True)
  File "/usr/share/yum-cli/yummain.py", line 309, in user_main
    errcode = main(args)
  File "/usr/share/yum-cli/yummain.py", line 178, in main
    result, resultmsgs = base.doCommands()
  File "/usr/share/yum-cli/cli.py", line 352, in doCommands
    return self.yum_cli_commands[self.basecmd].doCommand(self, self.basecmd, self.extcmds)
  File "/usr/share/yum-cli/yumcommands.py", line 368, in doCommand
    return base.erasePkgs(extcmds)
  File "/usr/share/yum-cli/cli.py", line 641, in erasePkgs
    if not self.remove(pattern=arg):
  File "/usr/lib/python2.6/site-packages/yum/__init__.py", line 3023, in remove
    (e,m,u) = self.rpmdb.matchPackageNames([kwargs['pattern']])
  File "/usr/lib/python2.6/site-packages/yum/packageSack.py", line 224, in matchPackageNames
    exactmatch.append(self.searchPkgTuple(pkgtup)[0])
IndexError: list index out of range


Initially I thought it was due to corrupted yum metadata. So, I ran a "yum clean all" to no avail. But then, rpm also started acting spooky. "rpm -q kdelibs" returned nothing although I was pretty sure I had installed kdelibs (since amarok depends on it). Looked like a bombed rpm database.
So, the simple solution was to run "rpm --rebuilddb" which reconstructs the rpm database. Everything worked like a charm after this!

PS: This is more a note to myself than a post. If it helps anyone, well and good. :)

Using the IRC

(Following are some ways I know to ensure privacy and avoid someone spoofing your identity.)

First, I'll recommend registering yourself with a nickname so that no one can steal your identity.
Use this nice tutorial to register your nick on freenode. Other services will have their how-tos.

Second you might want to disable FINGER, TIME and VERSION requests.
FINGER enables getting personal information like Email. TIME gives out your location information and VERSION gives out the OS and client names and versions you are using. Knowing the versions, an attacker might try a specific exploit.
Here is a nice tutorial to do it in xchat. Look at the client specific documentation if you use a different client.

Also, you might want to hide yourself from the global who/whois list (The way to do it on freenode is:)
/umode +i
(+i = invisible mode)

Leave a comment if you know a good addition to this list.

Automake supports cscope and ctags!

Finally!
Automake includes support for automatic generation of cscope and ctags targets. Now, theoretically, you can take any open-source project which uses GNU build system (and manyyy of them do) and type "make cscopelist" or "make ctags" or "make tags" and it will automatically generate the tags! Not that generating tags was a very difficult process earlier, but with support in automake, we can tinker around with the tags a lot.

Eg. If there is an arch/ subdirectory in your source-code and you don't want your cscope tags to be polluted by the IA64 code that you don't really care about, you can do it very easily by modifying the Makefile.am file in the arch directory.

I.e. you can easily control how your tags are generated!

This is the commit that went in,
http://git.savannah.gnu.org/cgit/automake.git/commit/?id=ffad481680a4e6a8f220c70f07b105c9f3f2dfdf


Hail automake!

Masochism ...

Objective : Whenever volumes are mounted, I see volume icons on my Desktop. I want to hide the icons because they mess with my wallpaper.

Method 1 : Find a GUI option.
Result : None present

So, after half an hour of grep-ing in ~ and lsof-ing, I found out that the option I need to set is probably hidden deep down into one of the huge gconf schemas.

 So, I started to learn the gconftool-2 tool. Its one nasty command.

# gconftool-2 --dump / > /tmp/gconf-dump
# wc -l /tmp/gconf-dump
96086 /tmp/gconf-dump


Crap! that huge!
So, I grep-ed for various keywords for another 15 min. Thats when I got a match.


# grep volumes /tmp/gconf-dump
<key>/schemas/apps/nautilus/desktop/volumes_visible</key>
(hiding other results for the purpose of sanity)


So, thats the key I have to flip. Pored over the man-page of gconftool-2 and here is the magic command:


# gconftool-2 --type bool --set /schemas/apps/nautilus/desktop/volumes_visible false


Similarly, you can also turn-off, trash_icon_visible, network_icon_visible (hides samba mounts), home_icon_visible and computer_icon_visible. and voila! A clean desktop!

You'll have to logout and login back again to see the changes. Although, I am sure there's better way. (Like to ask gconfd to reload the config). But, its 2:00am already and I need some sleep. So, I'll update this post tomorrow!

Whew!

RPM Hell

End-users these days are rarely exposed to "rpm". They'll probably be using yum or PackgeKit (or a GUI-based software installer). RPM, FYI, is the backend package management tool used by Fedora, SuSe, Mandriva, etc (together known as the RPM-based distributions). And it sucks bigtime!

Although RPM has come a long way from what it was in the 1990s and early 2000s, it stands on poor foundations and is unlikely to get any better soon. Having worked on Fedora-ARM for over half a year now, I can see the glaring issues that it faces. Fedora has done a hell of a nice job of mitigating those, but when you start to dig deeper, you realise how filthy the RPM world is.

Here is a link to a VERY old pre-yum days paper, "RPM Hell". Its a google cache link since the site which hosted the original paper was down. Here is the original paper.
Now the interesting thing is that, most of the issues mentioned in this paper STILL EXIST and are very real!

Following issues stand out:

1) Package management is pathetic. If I want to install a terminal-based editor, in all probability, I might end-up installing a whole load of GTK and X crap that I am never going to use. The main reason for this is because RPM packages are monolithic. Large packages like emacs typically install all GUI files needed to support it in X even when it is a headless server. So, we have a (needless) dependency, emacs -> gtk. Now, gtk pulls in LOTS of its own dependencies which are really not required and I end up with a bloated installation. Now, this problem can be solved by splitting emacs into 2 packages. emacs-common and emacs-gtk and I just need to install emacs-common. But, we'll soon realise that there are many capabilities a software can provide and we can't keep making a separate package for each. We'll end up with an unwieldy distribution. So, RPM should have a way of internally defining capabilities and installing only those which are really required.

While we were working on the fedora-ARM project and making a basic rootfs for F-11, we had to build almost half of the GNOME packages to satisfy dependencies. WTH!! Gnome shouldn't even come in the picture yet! But thats what happens when you are working with monolithic packages!


2) There's no way to install multiple versions of a software. Now this is not really a RPM problem, it is an inherent Linux issue. Rules like, all executables go to /usr/bin make it difficult to install multiple versions, since there'll be file conflicts.
So, if "A" needs B-1.0.0 but, "C" needs B-2.0.0, you have to choose between A and C. Fedora has greatly alleviated this problem by making sure every package that requires "B" would require the same version of "B". There are a lot of rebuilds, etc for the purpose. And they are partly justified (If we don't force packages to move to newer versions, they never will and we'll end-up with 10 versions of each package installed on our system). But sometimes, you just need a way around! and there's no way you can do it.
eg. There was a time when we had a working package built aganist python 2.4 and the new distributions had python 2.6. Now there were some difficulties because of which we couldn't rebuild the package aganist python 2.6. Only if there could be multiple versions installed! But sigh! We had to devise some dirty workarounds to get stuff working.
 

There are many other issues that yum intelligently hides. Most of them are highlighted in the "RPM hell" link above. Guess its time to rethink RPM?

Adding a swap device

Lets assume you upgrade you RAM from 1 GB to 2 GB. Since, the swap device is usually statically created during install-time and you'll probably be stuck with less swap space than the recommended figure. Then, you have 3 options
1) Who needs extra swap?
2) Make a swap file (simpler, but slower)
3) Extend the swap device.

For Approach 2, you can use the "dd" command to created a file of required size and then use it as a loop device.

Lets see the Third approach in detail.

Run "$sudo parted --list" to get a list of block devices attached to the system.
Use "parted /dev/sda resize <partition-number> <start> <end>"

"/dev/sda" is the HDD on my machine. Replace appropriately from the "parted --list"'s output.
Take the "partition-number" from the "parted --list" command's output. Use the swap device's partition number. Adjust the start end as you wish (can be specified in MBs.. eg. parted /dev/sda resize 5 5000M 7000M"

You don't need to worry about keeping the space free or defragmenting the drives to avoid data loss. Parted (claims) to take care of it.

If you never had a swap space (and created a partition just now) or you are using a swap file,
Make a swapfs on the partition

"$mkswap <device>"
(eg. $mkswap /dev/sda5)

Then, tell the system to swap on that device
"$swapon <device>"
(eg. $swapon /dev/sda5)

Add an entry in /etc/fstab for persisting the settings
Sample entry:
"/dev/sda5     swap    swap    defaults    0 0"

Thats it!

Check whether everything went fine by,
"$cat /proc/swaps"

Recommended swap-space = twice of total physical memory.

enable "sudo" in Fedora..

One fine day I became tired of "su -" and entering the password every other minute. (Also, had to write a script which needed to sudo). So, I decided to enable sudo access. Its pretty simple.
There's a sudo'ers file : /etc/sudoers

Run "man sudoers" to find out exactly what format the file has to be in. It is a bit complex, but don't distress, you won't need its complexity unless you are a funky sysadmin. The sudoers file usually comes with the basic infrastructure and most-frequently-used categories defined. You can define your own categories too. (refer to "man sudoers")

One thing to remember is that the sudoers file should be modified *only* with the "visudo" command. visudo checks the syntax while exiting and optionally, replaces the old file if the syntax is found to be invalid.

Just append the following entry to your sudoers file
jitesh ALL=(ALL)    NOPASSWD: ALL

where, "jitesh" is the username on my machine.
"NOPASSWD: ALL" means that sudo won't ask for password. Use with care.