So now this user’s PDFs open in Acrobat Reader on our Windows server, instead of using Acrobat Reader on Linux.  That would not in itself cause a problem, except that the Windows server cannot access the location of the temporary location of Kmail attachments.  I could probably fix that, but I don’t really want users opening email attachments using Windows applications.

This user cannot access File Associations to fix this problem, as the menu option is removed; so I need to find a way to fix this problem from the command line.

In solving this particular problem I discovered the existence of the users’ ~/.local/share/application directory, and was able to remove the application shortcut to the PDF and normal functionality was restored, but I thought it would be worth writing up what I have found to be the case.  Some of the following information may be wrong or misleading and please feel free to comment any issues, and I will endeavour to update this page accordingly.

KDE File Associations

I have to say that KDE file associations seem hellishly complicated, which is to say that there are so many different locations of files that it is very difficult to work out what is happening.  The three key factors in play seem to be:

MIME Types

Mime-types, appear to be stored in:

• ~/.kde/share/mimelnk directories (for each user)
• /usr/share/mimelnk
• /etc/kde-profile/standard/share/mimelnk (for kiosktool - a symlink back to /usr/share/mimelnk)

These look like this:

$ cat pdf.desktop
[Desktop Entry]
Comment=PDF
DocumentHidden=false
Icon=application-pdf
MimeType=application/pdf
Patterns=*.pdf;*.PDF
Type=MimeType
X-KDE-AutoEmbed=false

In other words they link the file extension, in this case *.pdf, with the MimeType, in this case application/pdf.  I believe I am right in saying that the users’ files take precedence over the global ones.

Application Shortcuts

Next up are the application shortcuts, and these also can be in diverse locations:

• ~/.kde/share/applnk
• ~/.local/share/applications
• /usr/share/applications
• /etc/kde-profile/standard/share/applications (for kiosk-tool)

As with the mimetypes, the users’ copy take precedence over the shared ones.  These application shortcuts define how to run an application, and look something like this:

$ cat "Adobe Reader 9 PDF Viewer.desktop"
[Desktop Entry]
Comment=
Exec=acroread
GenericName=PDF
ViewerIcon=AdobeReader9
MimeType=
Name=Adobe Reader 9
Path=
StartupNotify=false
Terminal=0
TerminalOptions=
Type=Application
X-KDE-SubstituteUID=false
X-KDE-Username=

As you can see, this tells the system how to run the application.

profilerc

Lastly there needs to be some way of tying the above two things together, something that tells the system that you use X application shortcut to open Y mime-type, and this appears to be the role of the profilerc files.  As with the other components, there are multiple copies of this file:

• ~/.kde/share/config/profilerc
• /etc/kde-profile/standard/share/config/profilerc

An extract of this file in respect of my PDF example, looks something like this:

[application/pdf - 1]
AllowAsDefault=true
Application=Adobe Reader 8 PDF Viewer.desktop
GenericServiceType=Application
Preference=2
ServiceType=application/pdf
[application/pdf - 2]
AllowAsDefault=true
Application=kpdf_part.desktop
GenericServiceType=KParts/ReadOnlyPart
Preference=1
ServiceType=application/pdf
[application/pdf - 3]
AllowAsDefault=true
Application=kde-kpdf.desktop
GenericServiceType=Application
Preference=2
ServiceType=application/pdf

This shows both the mime-type application/pdf and the application shortcut, e.g. “Adobe Reader 8 PDF Viewer.desktop”, and gives the different choices for opening the same mimetype.

I have found this exercise to be hugely frustrating, and I hope this information is of use to someone.  As I said earlier, my intention will be to correct this post as I find out more, so please forgive any errors, and if you have the time, please do let me know by commenting below.

First let’s take a look at where KDE squirrels away all these settings. KDE is complex, but it’s well-organised, and there is always a method to whatever KDE madness you find yourself in.

• /etc/kderc : This points to the file locations where configuration profiles are stored.
• /etc/kde3 : Global configuration files are here.
• /home/~username~/.kde : User’s individual settings go here.

You can see for yourself where your particular KDE installation is going to look for configuration files:

$ kde-config --path config
/home/carla/.kde/share/config/:/etc/kde3/:/usr/share/kubuntu-
default-settings/kde-profile/default/share/config/

KDE reads these in reverse order, so if it encounters any conflicts, the last value read is the one used. User’s individual configurations take precedence, so they are read last. There is a way to make an exception to the precedence rule: using $i, or the “immutable” key. You’ll see how this is used in the examples below. Anything marked immutable has precedence, no matter what order it’s in.

Installing Kiosktool

This is now unnecessary, as this has been fixed on Debian, you should now be able to simply do an aptitude install.

Kiosktool is simply an easy way of administering the above files. Kiosk Admin Tool is available in Debian Testing/Unstable and should be as simple to install as:

$ sudo apt-get install kiosktool

Unfortunately the current version of Kiosktool is broken for Debian, as Debian have changed the filename for the menu configuration from applications.menu to kde-applications.menu, and unfortunately Kiosktool is now unmaintained, so to install requires a few more steps than normal:

Install the build dependencies

$ sudo apt-get build-dep kiosktool

Before installing the dependencies, please copy them into the clipboard.

Download the source

Note that you do not need to be root to do this, and it helps later if you’re not! Change your repository if necessary, or remove it entirely to install from your default repository. Note however that at the time of writing Kiosktool is only available in testing, unstable and backports (the same versions in each).

$ apt-get -t etch-backports source kiosktool

Edit the source

This will download three files: a .orig.tar.gz, a .dsc and a .diff.gz. In the case of packages made specifically for Debian, the last of these is not downloaded and the first usually won’t have “orig” in the name. The .dsc file is used by dpkg-source for unpacking the source package into the directory packagename-version. Within each downloaded source package there is a debian/ directory that contains the files needed for creating the .deb package.

Navigate to this directory and open the following file in a text editor:

/path/to/kiosktool-1.0/kiosktool/menueditComponent.cpp

Replace all instances of applications.menu with kde-applications.menu.

Build the deb

From within the directory that was created for the package after downloading.

$ apt-get -b source kiosktool

To install the package built by the commands above one must use the package manager directly, like this:

# dpkg -i kiosktool-<version>.deb

Remove the build dependencies

It seems that some of the build dependencies may be incompatible with the LTSP enlightened sound daemon (esd), if you copied them (as recommended in Install the build dependencies section), then please purge them now. Otherwise you will need to review /var/log/dpkg.log for the relevant files.

$ sudo apt-get --purge remove package1 package2 etc

Using Kiosktool

After installation you should have a menu entry for it in System -> KIOSK Admin Tool, or use the kiosktool command to start it from the command prompt.

You may find that a copying dialog crops up at regular intervals and that often it will stall, please read:

• Fix kiosktool fish protocol stalls

References

This document was cobbled from the following sources:

• APT HOWTO Chapter 6 Working with source packages
• Lock Down Desktops with KDE Kiosk by Carla Schroder

Other references:

• http://techbase.kde.org/User:Danimo/KIOSK

The advice in the Edit the source section was copied from a mailing list post, which I now cannot find. The post also mentioned that patches were available for this issue, although I could not find any such patches, and anyway the method above is probably just as easy.

When making changes to profiles under kiosktool, it stalls when uploading changes to the local machine using the fish protocol, see screenshots.

Persistently clicking cancel followed by retry does deliver the goods, but sometimes it can take ten attempts or more, with the load average quickly escalating to ten times the server’s usual level.

I understand it requires the fish protocol, even though it is editing the local machine, because kiosk has to be run as a standard user, but requires root access to edit the profile.

The fish protocol usually works fine in konqueror.

Under our Kiosk configuration I have the base directory set as /etc/kde-profile and the option “On exit, upload profiles to a remote server” is unchecked.

Screenshots

Workaround

Keep cancelling the copy and then retry.

Never come out without successfully completing the copy, or you can end up with corruption in your personal desktop, or menus, or even end up unable to log in. You have been warned.

The Solution

The solution seems to be to edit the menu entry for Kiosk-Tool and change it to:

env KDE_FORK_SLAVES=true kiosktool

References

• http://lists.kde.org/?t=111633283900002&r=1&w=2 (Similar problem under SUSE)
• http://bugs.kde.org/show_bug.cgi?id=8137 (similar problem under FreeBSD)