KaNDAS 0.2

KaNDAS 0.2 is out. Packages for openSUSE 10.3 and openSUSE 11.0 are available, and I hope to figure out soon why the packages for 11.1 do not build.

KaNDAS 0.2.0

Update: Someone commented that I should have explained what KaNDAS is. I have done so in my last blog post, and was tired to do it yet again. Check the project homepage or this very old blog post which tells the story behind the project.

Dear lazyweb: Question about udev/HAL

Is there a way to tell udev/HAL that a certain device file is a block device which it should automount (ideally through some C/C++ method calls)?

On the background: I’ve been working on KaNDAS again, and as most of you did not hear of KaNDAS, I’ll introduce it again: NDAS is a patented system for network drives with a closed-source Linux driver. Its only interface is a folder in procfs and a quite inconvenient command-line administration tool. As I have to use such a device, I implemented a better solution. A root daemon (KaNDASd) polls on the procfs and sends some metadata about connected devices to DBus clients (a KDE 4 client and a suite of command line tools is available). The clients send action requests (connect or disconnect) to the root daemon which transfers them to the standard administration tool.

The problem I’m having is that when I connect the NDAS, a block device /dev/ndas-[serial]-0p1 (with the “p1” for the first partition) appears which I can mount, but I want KaNDAS to tell udev or HAL that this device be offered for automounting. Do you know a solution for this? (I haven’t found something like API documentation for udev or HAL.)

On a completely unrelated side note, the ODE port of Kolf is complete after I brought the black hole back to life.

KaNDAS 0.1.0

KaNDASd, KaNDAS, and KaNDASconsole 0.1.0 have been released. A source tarball is available from the project page, packages for openSUSE 10.3 and 11.0 (aka Factory) are currently being built (use the the openSUSE package search to find and install them).

This release arrived one day later than expected because yesterday was too busy for me. Besides KaNDAS and some recent work on the jigsaw puzzle game Palapeli, there were some quantum physics lessons to go through.

If you try to compile trunk these days, you’ll notice that KaNDAS fails. That is, in fact, not a problem with KaNDAS which is working fine when used with KaNDASd 0.1, but KaNDASd has iterated its interface version from 0.1 to 0.2 with some massive cleanups. KaNDASconsole has already been ported with just 4 lines of code changed, so KaNDAS should be an easy job once I get into it seriously.

Besides the API cleanup, I’m hoping to get some new features into KaNDASd (driver control and device registration) and stabilize KaNDAS (its lists are sometimes behaving in a quite interesting manner).

KaNDAS 0.1 beta 1

KaNDAS, KaNDASd, and KaNDASconsole 0.1beta1 (aka 0.0.81 for package management systems) have been released:

• Source tarballs
• openSUSE 10.3 packages
• openSUSE Factory packages

The latter two links are repositories, add these to your repo list.

Approaching KaNDAS 0.1 release

Yesterday I said that only state transitions in KaNDAS are missing for a release. Today, I can say that state transitions are available in KaNDAS. I did also write an init.d script for kandasd to allow it to start automatically when you boot your computer. With these changes, everything is in place.

I’ve written a release schedule for KaNDAS 0.1, KaNDASd 0.1, and KaNDASconsole 0.1. After one week to cool down from the recent development, Beta 1 will be tagged on Friday and released on Monday. In the mean time, I’ll try to set up a repository on the openSUSE build service, which will enable me to build packages for openSUSE, Fedora, Mandriva, Ubuntu, and probably some other distros I did not mention.

The complete release schedule is available on the project page.

Simulation of NDAS devices

Of course, my NDAS device is located at home. But my notebook, where most KaNDAS development takes place, is designed to be mobile. I’ve decided to make my NDAS device mobile, too. It is not in my bag, but on my hard drive is KaNDASsimul.

Like the name indicates, KaNDASsimul simulates NDAS devices (or better: NDAS drivers). The KaNDASd daemon gets all information it needs from the /proc/ndas tree which is generated by the ndas-core kernel module. KaNDASsimul generates such a tree from the commands one enters on its CLI. The only disadvantage with this approach is that you have to do state transitions (namely connection and disconnection of devices) manually as KaNDASd is not able to know whether its source is real or simulated and that is good of course; simulation is a development tool and not intended for a mainstream release.

Talking of a mainstream release, you might have noticed that there have not been any until now. I’m simply busy with real life issues. The only thing that is missing for a first release is the invocation of state transitions in KaNDAS (and some bugfixing: it does some quirks while loading). If everything goes well, KaNDAS, KaNDASd, and KaNDASconsole will be entering the alpha phase before the end of this month.

Introducing KaNDAS, second attempt

From earlier blog posts, you might have noticed that I’m working on a project called KaNDAS. I did not write much about what it really means, and the official KaNDAS page is not very helpful for newcomers. Therefore, I’m going to provide an overview of nearly everything you need to know about KaNDAS for now.

History and program design

First of all, KaNDAS is not a monolithic program. In fact, it was when I wrote it first. The problem I had is that I own a network-attached hard drive from Trekstor which, for Windows, has a nice GUI with a tray icon. The software provided for Linux are: a kernel module and a command line administration tool (only for usage with root rights). Not a very friendly situation. The whole interface I have is /proc/ndas and this tool which allows me to start and stop the kernel module, connect, and disconnect devices. At first, I wrote a simple GUI with five friendly buttons for these actions (connect is two actions since one can connect read-only and read-write). It was called KaNDAS which is an abbreviation for “KDE adapter for NDAS devices” (the “adapter” is type of a backronym; I chose the “a” to have an easily pronouncible name). This simple approach had some big deficiencies: It could only handle exactly one device, and it was, well, too simple. It did not automatically adapt itself to external changes, for instance. The biggest disadvantage, however, was that one needs to enter the root password for every single action since the admin tool requires root privileges.

My solution to these problems is a client-server architecture: A daemon called KaNDASd (d = daemon, obviously) is running with root privileges. It scans through /proc/ndas to detect any changes on the devices. These changes are propagated using a D-Bus interface on the system bus. This interface can also be used by clients to invoke status changes, e.g. when you choose to connect or disconnect a device. This has two advantages: You do not have to enter the root password every time you connect your device, as the admin tool is started by the root daemon KaNDASd; and you can use two different clients at once without having them both to scan for changes.

So, it is very easy to have multiple clients. By now, there are two clients available: KaNDAS itself which is a KDE 4 application with nice list views of all available devices and all the well-known KDE4 goodies. For fans of scripting, there is also KaNDASconsole available. KaNDASconsole is an application suite which consists of three tools at the moment: kandas-info lists all available information, kandas-up connects devices, kandas-down disconnects them (naming in resemblance to ifup and ifdown).

Installation

KaNDAS is in development at the moment, there hasn’t been a release yet. Therefore, you’ll have to get the sources from my version control system. Create an empty folder, open a console in it and say:

svn checkout http://kandas.googlecode.com/svn/trunk/ kandas-trunk

This creates a directory “kandas-trunk” with three subdirectories for each application in the KaNDASd family.

For compilation, you need Qt 4 and kdelibs 4 installed, along with the development packages. At first, you’ll need to compile KaNDASd as it installs header files necessary for the client applications. The build process is as usual with CMake. Go into the kandasd subdirectory of the downloaded kandas-trunk directory, create a directory “build” in it, open a console in it and say:

cmake ..
make
sudo make install

The output says where the “kandasd” executable is installed; you’ll need this path later. Proceed with compiling kandas-console and kandas in the same manner.

Usage

At first, make sure that your NDAS driver is installed and started, and that you have registered at least one device (unless you want to see empty lists). At first, you’ll need to start the KaNDASd daemon. To start it as a background service, use

sudo /path/to/kandasd --detach

If no output appears on the console, the initialisation of KaNDASd went well. You can now view the available devices and their slots (which are connection points which you use to connect to this device) by running kandas-info. (KaNDAS-info displays quite much information, use its command line options to lower its output.) If there is, for example, a device “Cookie” with the slots 1 and 2, you can use the following commands to connect to and disconnect from your device:

kandas-up 1 #connects slot 1 (read-write mode)
kandas-up -r 2 #connects slot 2 (read-only mode)
kandas-up -d Cookie #connects all slots of device "Cookie" (read-write mode)
kandas-down 1 #disconnects slot 1
kandas-down -d Cookie #disconnects all slots of device "Cookie"

Everything after the number sign is a comment. I tried to align them with extra blank spaces, but WordPress removes these. (Time for a bug report…)

Aside KaNDASconsole, there is KaNDAS which has at the moment about the same functionality as KaNDASinfo, just nicer. There are already buttons for connection and disconnection, but these are not working at the moment. Once they are, I will prepare a first release to spread the word of KaNDAS.

The KaNDAS project

If you are interested in helping KaNDAS, this is your chance: It’s one of the project’s goals to integrate with your personal workflow and environment as much as possible. Due to my own limited spare time and programming experience, I’m in need of more programmers to extend the team:

• A GTK+ programmer with D-Bus experience is searched to create a client for GNOME.
• A Plasma nerd is wanted to work on a KaNDAS plasmoid. (I think of a user interface boiled down to only one device as users own only one device in most cases.)
• Of course, you can come up with your own ideas to make KaNDAS rock. If you’ve found a bug, use the issue tracker on the project page.

Introducing KaNDAS

I’ve finally started a blog, mostly to be able to write about progress on my new project KaNDAS, a management infrastructure for NDAS devices (as the one I own). (As you see, I like to keep things short.)