Happy first time Linux users, with Mandriva 2010

I recently setup a new computer for a friend, who’s win98 computer had broken some time ago. Purchased a really cheap new PC, dual core E5300 cpu, 2GB ram, on board everything, with sata disk and dvd writer, plus an 18.5 inch screen, came out to $630 NZD.

Now, I had the difficult call to make, as to Mandriva or Ubuntu, because Ubuntu is very popular in NZ so he might be able to get better community support for it, and their are local mirrors for updates. Anyway, decided that it was going to be Mandriva x86_64, 2010.0 with KDE 4.3, because I know it well and because is has some tools I planned on using.

He received the machine today and was rapped. Plugged his printer in and it just worked!.. and they even got imap with kmail configured without my help.

Now, I usually configure systems for myself, but this was for a real beginner, so I needed to keep things simple and make it easy for him, so I made a few changes to the configuration, however discovered some things that I think need improvement along the way.

First thing was, I installed Mandriva 2010.0 Free, then had to add in a bunch of commercial apps, because you can’t expect a beginner user to go without them or install them himself.. The most notable was Flash Player, I think this should be easier to get, for 2010.0 free. It’s in PLF, but only in the i586 repo, and beginners are not even going to know about PLF. So, my point here is, since it ships with Mandriva one, should be easy to get for Mandriva Free 2010.0 users.

Also installed Skype, Picasa and Google Earth and the necessary codecs to play DVDs, mp3, movies, etc. No packages available for the Google apps so had to install them by downloading the installers from Google.

Next, thought I’d fire up Transfugdrake and pull the configurations from his old hard drive, plugged in via USB. Not so easy, I ended up having to hack the source code in /usr/lib/libDrakX/transfugdrake.pm to even get it to look at the disk. It should be able to be pointed at a mount point, and told to run.. without having to rely on the auto detection, which did not work at all in my case.

Transfugdrake did import some bookmarks, and the wall paper, plus some documents, although it missed all his documents that were on the desktop in windows. So, some thoughts around transfugdrake is…. it needs some improvements and a lot of testing! It also found his email address, but didn’t import it into anything useful in KDE4.3.

Next I tried to make life simpler for him, so did things like, reduced the number of desktops, added applications to the bottom panel, configured updates, added a link to the documentation, added him to the wheel group and configured sudo.

I wanted passwordless login, so I ran systemsettings as root, then configured KDM to auto-login and to not require passwords if he logged out. Pity this method of configuring auto-login is hidden for the average user.

Next I fired up Amarok, and discovered it wanted to use kwallet.. even when I had not entered any passwords for Amarok. The Last-fm plugin seems to want to open kwallet, even when it’s not storing a password… this brought me to the next thing, which was I wondered if it was possible to make kwallet not require a password for the default wallet. I could not find a way to do this, so ended up just turning off kwallet to keep in simple.

Next was making the configuration tools easy to get to. I set most things in the Mandriva authentication settings to not require a password, but could not find a way to allow access to drakconf without a password, so a quick edit of the .desktop file to run sudo drakconf fixed the problem nicely.

Maybe drakconf should try sudo, if the user can use sudo to run it, then use sudo instead of always requesting the root password.. This would make it easier for users, and is no less secure.

Next was backups, as I remembered drakbackup… however, found draksnapshot, which is even nicer. I created a ext4 partition on his old hard drive and used that for the backups with draksnapshot. It’s nice, but configuration is too simple, and, although it works, it runs on cron, so the user can’t trigger a backup, and it will only do daily backups at 4am by default.. So, was kindof limiting. I reconfigured cron to run the daily backups at a time he might be using the computer, then explained how it works. It would be good if the user could trigger a backup when the backup media is added. This kind of makes sense because draksnapshot initially prompted to use the media for backups in the first place.

I think using rsnapshot is smart, efficient and makes recovery easy, but think we need to work on improving the user interface of draksnapshot… Looking at the Ubuntu solution, of SimpleBackupSuite, it has many more options to control the backup.. Now, sbackup could be packaged for Mandriva, but it creates tar based backups, similar to drakbackup, which don’t seem as good to me as using rsnapshot.

anyway, a happy user, and looks like another couple of Mandriva converts.

allowing guests in via ssh

I recently setup a demo machine for a presentation on pxe boot, where I wanted people to be able to login and have a look around a demo pxe boot VM.

Lots of ways to do this, but the way I wanted to make this work was via ssh, without requesting a password.

To do this, I configured sshd with:

UsePAM yes
PermitEmptyPasswords yes

and configured /etc/pam/sshd, to allow members of the demo group access, by adding the following line:

auth sufficient pam_succeed_if.so user ingroup demo


then I just add users, and put them in the demo group if I want them to login without a password.. neat.

Improving pxe boot menus

Mandriva has a fairly good tool for building and managing pxe configuration. It’s called drakpxelinux. This is the tool that got me started with network booting and although it has some fairly rough edges, worked fairly well.

After exploring some more, I discovered that pxelinux, part of the syslinux package can do much more than people traditionally use it for.. This includes graphics, multiple boot options and menus, context and general help text and passwords and ability to change kernel options. A screenshot below is an example of what we now use at work for the default menu.

This really makes things a lot easier to use and looks quite professional.

We have menu items for:

Installers:

• Red Hat
• Red Hat with kickstart
• Centos
• Mandriva with nfs preconfigured

Running off the network:

• Red Hat using it’s nfs snapshots, confugration created from the system-config-netboot tool
• Knoppix
• FreeDos
• Memtest86 and PXEKnife, which includes some basic Linux flavors, firmware updating tools, password reset tools, disk wiping and other random stuff.
• Clonezilla and udpcast

I am wondering about adding a “Graphics” option into drakpxelinux which would allow people using drakpxelinux to configure a graphical boot menu, probally using a couple of templates and allow them to incorporate their company logo.  I am also thinking it might be nice to provide a package that contains a bunch of common pxe tools and configurations. I am Interested in this, because I am also interested in making a better way to network boot Mandriva to run it diskless.   I might see if I can get some help with some of it, as have limited perl skills, although the code not looking too tricky from my breif inspection.

Anyone interested in my sample configurations, can get them here.

• pxe_example_config.tar.bz2 ( syslinux-3.82 files and configuration files)
• pxe_inkscape_graphics.tar.bz2 ( templates for the graphics I used.  Edit and export as 640×480, convert to jpg)
• pxe_example_images.tar.bz2 ( large: 138 MB.  Contains images directory, of limited use, but may be handy if your building this, I would recommend just getting the images you need from the installers and pxeknife from http://pxeknife.erebor.org/)

DHCP and tftpd configuration is mostly standard for pxe setups, let drakpxelinux configure it for you, although you will need to point to pxelinux.0 rather than linux.0 in the dhcpd.conf file.

Screen shots in the package manager

I’ve been doing some thinking about what would make Mandriva stand out and also what could help Linux distributions in general.   I think that although rpmdrake is pretty good, it has room for improvement.   Two features I am thinking of are screenshots of packages that are graphical and ways for end users to provide feedback about packages.

Here, I want to talk about my ideas for screenshots:

Requirements I’ve thought of:

• Stored in srpms and owned by the package maintainer
• Available from the mirrors for the package manager application like rpmdrake
• Ability to be shared by other distributions
• Everyday users able to submit screen shots to package maintainers
• Easy to add to packages
• Multiple screen shots per package, including where multiple packages are created from a single srpm.
• Min/Max resolutions

To meet these, I see that this should be done starting from the bottom, which is how to store screenshots.  I’d like suggestions on the best way go about storing them is adding a “Screenshot0: filename.png” field to rpm, so that spec files can list screenshots, which would be included in the SOURCES directory the same as Sources and Patchs are.   The Screenshot[num]: fields should be able to be in multiple %package sections.

I’d invision that these screenshots should then be packaged and included in the generated src.rpm when the rpm is built.   I don’t see the need to include the screenshot in binary packages, as see this as un-necceary because users don’t need screenshot of installed packages, and including them would make packages bigger than they need to be.

So, these steps would involve changes to rpm,  rpmbuild and rpm-lint.  So far, these changes could be used for any rpm based distro.  I think that Fedora, OpenSuse and others will eventually also want screenshots for applications.  Advantages of the Screenshot field in the spec files is that automated tools can understand this and extract/update screenshots as needed.

The next stage I would see is the ability to get these screenshots onto the repositories.  To achieve this, I see that whatever tool is used to generate meta data for the package management tool would need to be updated to support generating a directory full of screenshots at different sizes, extracted from srpms.  In Mandriva’s case, modifications to genhdlist2.  I would expect it to extract full size screenshots from a directory of SRPMS and create a directory structure with screenshots for each package at various resolutions.  These would then be mirrored to repositories along with the hdlists.

The last piece of this puzzle would be to update rpmdrake to check for available screenshots and display them when a package is selected.  It would need to download them in the background from the same mirror as package and only if the a working internet connection.

This leaves a few features I’d like to see, but is the basic infrastrucre I’ve been thinking of.  With these in place, I’d then provide a way for users to submit screenshots to maintainers via a web based interface linked to from rpmdrake.  A maintainer could then see the associated screenshot and if it’s ok, have the tool automatically update the spec file and commit it to SVN in Mandriva’s repository.

I’d also invisiage distributions like Mandriva would probally have a web based package browser that would include these screenshots and a simple way for a user to trigger the installation from the web page.  The web based version may also include other ways for the user to provide feedback about packages, which I’ll discuss in a later post.

Memory usage - 2009.1 with KDE4

Running Mandriva 2009.1 on my EEE pc, I am sensitive to performance, as it’s a fairly low end system. 900 Mhz, 1GB ram, and also have laptop with only 192 MB .    I could not understand why plasma was using 47 MB of ram and some other processes where also really hogging a lot of ram considering what they do.  The tools I am going to pick on are:

mdkapplet (14 MB), net_applet (19MB), redhat printer config tool (8MB), codina update (20 MB when running.. stops sometime after login).

I wonder if something can be done to make these tools use less ram.  I  like net_applet, but can’t have it using that much ram on a low end system.

In: /usr/share/autostart
I removed some things:

• mandriva-galaxy.desktop ( I think this must just exit anyway if the use has closed the initial popup)
• mandriva-mdvonline.desktop
• nepomukserver.desktop  ( I wonder if I need this or not.. don’t know)
• net_applet.desktop

In: /etc/xdg/autostart, I removed:

• redhat-print-applet.desktop  ( I don’t print )

Doing this got plasma down to using 14 MB or ram and  206MB total memory usage, instead of 235 MB. (Read using free -m, -/+ buffers/cache row). It didn’t have much effect on my usage.  I now start netapplet from the menu when I want to change my network settings, and auto updates won’t happen (which I never use anyway).

systemtap on 2009.1

Today I decided to have a play with systemtap and see if it worked on 2009.1, since it’s quite a need tool that Fedora has had for some time.  Luckly enough, it looked like the was an RPM available for it, so installed it and gave it a go..  no such luck.  The rpm is old and builds c code that won’t compile against the current kernel.  The way systemtap works, is it takes a system tap script  and compiles this script into C, It then compiles the C against the current kernel to build a kernel module, which is then loaded into the running kernel.

Not to be deterred by an out of date package (bug logged), I downloaded systemtap 0.9 from http://sourceware.org/systemtap/ftp/releases/ and compiled it.   (required: lib64elfutils-static-devel, gcc-c++).   It  requires quite a lot of the kernel files, so installed kernel-server-debug, kernel-server-devel.

After that, it worked pretty well,  I downloaded a few of the examples, like nettop.stp, which will output a nice top of network traffic by process. for example:

# stap nettop.stp
PID    UID DEV     XMIT_PK RECV_PK XMIT_KB RECV_KB COMMAND
10219  500 eth0        101      67      19      73 firefox
0        0 eth0         55      92       3      46 swapper
2863     0 eth0         27      28       1      26 X
3583   500 eth0         13       4       5       0 sshd
3582    76 eth0          7       2       2       0 sshd
2913     0 eth0          4       4       0       0 python
2996     0 eth0          2       2       0       0 nmbd
4205   500 eth0          1       1       0       0 net_applet

How to prevent graphical grub menu on startup

I just discovered by accident, that holding down left shift during mandriva bootup from install cd prevents the graphical boot loader from starting.  It also provides debugging output for grub if you are booting from HDD.

I wish I knew this awhile ago, as it would have helped with installing Mandriva as a guest inside KVM where the graphical grub menu would always kill the virtual machine.

interactive debugging /boot/initrd.img

Sometimes, it is handy to figure out what is going wrong in your initrd file.  This can be tricky, as it’s a single script that if it’s breaking, usually results in a kernel panic.  I needed to figure out today why the call to mdadm to assemble the raid was not working, so I could add something of value to bug #48844.  To debug an initrd.img, here is what I do:

• Boot rescue mode from a Mandriva CD.
• Go to the console, mount your /boot partition into /mnt, unpack your initrd

mount /dev/sda1 /mnt
mkdir /mnt/initrd ; cd /mnt/initrd
cat ../initrd.img | gzip -d | cpio -i

• copy in bash and necessary libraries to run a shell

cp /lib/* lib/
cp /bin/* bin/
cp /lib64/* lib64/

• edit init and add in /bin/bash at the point you would like a shell
• rebuild your new initrd

find . | cpio -H newc -o | gzip -9 > ../initrd-new.img

• edit ../grub/menu.1st to use your the new initrd-new.img file.  Also turn off graphical boot.
• umount /mnt
• reboot

If you want to run some of the actions in /init from the command line manually, they are nash builtin’s, so cannot be run directly from bash.  I run them by creating an file with vi containing

#!/bin/nash
mkblkdevs

then running the file.

Bug reporting and patching for 2009.1

I am trying to help make Mandriva 2009.1 one of the best ever Mandriva releases, however I am having a little bit of a frustrating time getting responses from the Mandriva cooker team.

I have to say that most of 2009.1 looks fantastic, great work with the msec changes, KDE 4.2 and a bunch of other really nice touches.  I love the wallpaper!

I know everyone is busy working on 2009.1, but getting no response when I send patches  to package maintainers is a bit disheartening, especially when I would like to see the patches get into 2009.1.  Likewise, bugs that I logged, even some bugs that I logged back for 2009.0 have not been updated, they just still sit there, usually triaged as valid, but no action or updates, yet they are not the kind of just cosmetic bug, they are a feature is unusable bug!

I wonder what I can do to help, when by the looks of things, supplying patches that fix valid bugs, and logging bugs, sometimes just gets no response.   I do get a response sometimes, so don’t take this the wrong way.  I just want to get some bugs fixed.  Bugs that would be easy to fix and are visible to users are not look good I think.   I currently have 8 bugs logged, 6 of which have patches or solutions in the bug report, just not applied.

Tonight I’ve been doing a few tests on Mandriva 2009.1 RC1, x86_64 inside vmware and logging / voting on bugs where things in the installer don’t work. Mostly around encryption.