Hello,

I'm a newbie on linux programming.
I wrote a linux daemon, which needs to communicate (sometimes) with the user. The communication-channel should be configurable (i.e. network, serial line or direkt desktop), so I like to know, what would be the best solution?

My first attempt was, to create separate subdirectories for each user-channel and place there some scripts, that could be edited by the enduser. Network- and serial-communication is not the problem, but direct destop-communication is.

I would prefer a solution without KDE-programming, means usable in shellscripts. If that's not possible, does KDE have a socket, where I can connect for a question and get a reply, or how can I start kdialog from a daemon without exposing X to root.

Any hint is welcome.

kind regards

Geronimo

Due to the way X works, you will need to execute 'kdialog' as the user with the $DISPLAY variable set correctly, which you will need to retrieve somehow ( I believe it is listed as their session like virtual terminals are )

I would recommend doing this for the scripts as well, especially since you mention they are user editable, which could be used by malicous users as a exploit to gain root powers.

If you are running as root then the following should be workable:

Code: Select all

sudo -u $USERNAME $COMMAND

should work fine, executing $COMMAND as $USER without problem.

Me, I would have the daemon call a root owned script as the appropriate user, which would, determine then set $DISPLAY, then finally call the users script.

Are we talking about a session or a system daemon?

Are we talking about general information or something requiring user input?

Cheers,
_

Hello,

thanks for your attention.

I'm really confused. Yesterday I was able to start kdialog from a background task, but today it does not work.
So, may be, that with the lots of experiments I got some leftovers from userenvironment.

Actually the DISPLAY variable is not enuf to start a X-app.

No matter 'su -c' or 'sudo' don't work either.
I thought, with 'su -l -c' I would get an authentic login session - but that's not the case.

> Are we talking about a session or a system daemon?
> Are we talking about general information or something requiring user input?

I'm talking about a real system daemon (started as root), which requires user input. First I thought about two threads, talking to each others, but as it worked yesterday without caring about threads, I thought it should be possible.

Today I'm struggled and I have no idea, why it could have worked yesterday.

The system-daemon is a selfwritten C-program, so if you could tell me, how to setup the environment, I might be able to start a shellscript from the daemon already in the right user-environment.

User interaction with a system daemon is quite a complex thing, since you are crossing between users and possible priviledges, there might be more than one user session, etc.

The currently preferred way to do this is using D-Bus and having a "GUI peer" running in the user sessions, e.g. like nm-applet (GNOME) and KNetworkManager (KDE) being the GUI peers of the NetworkManager service.

Cheers,
_

Thank you for the right keyword

OK, I read the tutorials and I think I have an idea, on how parts play together ...
... what I'm missing is:
How can I figure out the message, I have to send, to bring kdialog to popup?
I only need somewhat like --yesno, so very "trivial".
Or does there already exists a D-Bus client, that is usable in a shellscript, executed from the daemon?

kind regards

Geronimo

Hello,

I'm a bit unsettled. I can't compile the code-sample from D-Bus tutorial and running qdbus finds only org.freedesktop.DBus

Is D-Bus the appropiate protocol for KDE 3.5 also?
I think, my kde is running DCOP, but I did not succeed in finding a "simple" sample to use.

I'm not too lazy, but the available information is too much and much of it is outdated or my apps are outdated, so I need someone shining a light on where/how to start.
I don't want to create a new KDE-app, just to be able to use the D-Bus protocol.
I'm running debian etch with kde 3.5 and want to find a solution for that system-components.
(I'm not interested in ultimate techniques that aren't available on stable systems)

Any help is appreciated.

KDE 3.5 uses DCOP, whereas KDE4 introduced a change to DBUS. So you can't use DBUS from 3.5 applications. See this for an overview of DCOP.

Thanks for that clarification!

I stumbled around through KDE online docs / developer docs and IBM developer docs about DCOP and I tried to solve my problem with kdcop/dcop helper apps.

Well, talking about dcop as command line tool, not the communication technique.

If I understood a little bit, I need to talk to klauncher to start kdialog from the background.
The function 'start_service_by_name' sounded usable for my requirements, but I was not able to solve it.

Do you know a sample, where I can get the usage from?

My daemon communicates with several different clients. Only one of them is a desktop user. So I created a shell-script interface, where the final user can change the question/answer-handling to fit his needs.
So if it is possible, to start kdialog from a shellscript, wich gets executed from a daemon, I would prefer that.
If not, I would like to write a little client with glib or so.
If avoidable, I don't wonna work with Qt.

I'd like to pass a title and a string built by the shellscript to kdialog (in yes/no-mode) and give the exitcode from kdialog back to the caller of the script.

kind regards

Geronimo

Hello,

in another forum I read that 'kdeinit_exec' would be the function of choice.
From kdcop entering 'kdialog', '--yesno' and 'test' works, with this from commandline:
"dcop klauncher klauncher kdeinit_exec kdialog --yesno test"

I get: Not enough arguments.

No matter whether I quote '--yesno' or put the arguments together separated by comma ...

Trying this from a root-session:
"dcop --user gero klauncher klauncher kdeinit_exec kdialog --yesno test"

results in: object not accessible.

What am I missing?

Communication between a system daemon and user sessions is one of the things D-Bus can do better than DCOP.

While it is possible to send a DCOP command to all users sessions, e.g. by using the commandline tool dcop and its --all-users and --all-sessions switches, this give no relyable return channel.

Relyable two way communication between user sessions and system services basically always requires two components talking to each other, e.g. through a socket (Unix or Network), similar mechanisms on other platforms, etc.

While a service running as root (usually running as some sort of daemon users) could start interactive programs into user sessions on demand, this would either be restricted to systems with only one user session or have to deal with potentially conflicting responses from several users.

Cheers,
_

anda_skoa wrote:Communication between a system daemon and user sessions is one of the things D-Bus can do better than DCOP.

That may be true - but I don't think, that's my problem.

anda_skoa wrote:While it is possible to send a DCOP command to all users sessions, e.g. by using the commandline tool dcop and its --all-users and --all-sessions switches, this give no relyable return channel.

I don't like to do that.

anda_skoa wrote:Relyable two way communication between user sessions and system services basically always requires two components talking to each other, e.g. through a socket (Unix or Network), similar mechanisms on other platforms, etc.

While a service running as root (usually running as some sort of daemon users) could start interactive programs into user sessions on demand, this would either be restricted to systems with only one user

I take for granted, that systems wich use my daemon with user-interaction are single-user systems. Single-user in the sense of one user at certain time, not the count of configured users. It makes no sense at all, to use that kind of interation on multiuser-systems (on multiuser-systems, communication would be over serial line or over network, not directly to the user).

The major question for me is:
- do I have to create a GUI-app to realize user-interaction (then of cause I could do socket communication or the like), or can I talk to an existing GUI-component to get a user-response.

I think, at the moment my problem has to do more with authorization, than with functionality. As a quick hack I tried to link the users .Xauthority to /root and the my user-interaction with kdialog from the shell works fine. No problems with performance or feedback - I'm totally content with that functionality.

But I think, that link is nothing desirable in a system and it does not work on systems with several changing users. So I'm looking for a way on how to do in right - not in the sense of reinventing the wheel, but for configuration and usage. Security is an issue for me.

Don't know, how does hotplugging work? Is the popup a component from hotplug or is it a kde-component, hotplug talks to?

kind regards

Geronimo

Geronimo-013 wrote:

anda_skoa wrote:Communication between a system daemon and user sessions is one of the things D-Bus can do better than DCOP.

That may be true - but I don't think, that's my problem.

Right, I just wanted to clarify that DCOP was intended to be used between applications on the same user session, while D-Bus explicitly as the additional use case of talking to system services.

Geronimo-013 wrote:I take for granted, that systems wich use my daemon with user-interaction are single-user systems. Single-user in the sense of one user at certain time, not the count of configured users. It makes no sense at all, to use that kind of interation on multiuser-systems (on multiuser-systems, communication would be over serial line or over network, not directly to the user).

Ok, you know your system requirements/restrictions better than anybody.
Most of the times a system service developer cannot rule out more than one active client session, e.g. terminal server setups, multi-seat, etc.

Geronimo-013 wrote:The major question for me is:
- do I have to create a GUI-app to realize user-interaction (then of cause I could do socket communication or the like), or can I talk to an existing GUI-component to get a user-response.

Since you can be sure you only have one user session at a given time, it might be easier to just do the direct launching.

Geronimo-013 wrote:I think, at the moment my problem has to do more with authorization, than with functionality. As a quick hack I tried to link the users .Xauthority to /root and the my user-interaction with kdialog from the shell works fine. No problems with performance or feedback - I'm totally content with that functionality.

You could try to allow root connecting to the X session through an xhost command in the session's startup scripts.

Geronimo-013 wrote:Don't know, how does hotplugging work? Is the popup a component from hotplug or is it a kde-component, hotplug talks to?

The HAL system service sends signals onto the D-Bus system bus and applications interested in that listen for those signals.
That can be other system services (e.g. NetworkManager interested in availability of network devices), user session services like the "mount watcher" or even user session applications (e.g. setting a document read-only if the source file system becomes unavailable)

These use cases are obviously more complex than yours since they also have to work properly in multi user cases.

Cheers,
_