Problem with Program-Autostart in KDE 3.1 (Kiosk-Mode)
Hello, I'd like to autostart a program for a special user (is logged in automatically) at the startup of KDE. I use Suse Linux Prof. 8.2 and KDE 3.1 Version 3.1.1-17 (Standardinstallation of Suse 8.2). Actually the program ist started automatically for the desired user by adding a start-script in '$HOME/.kde/Autostart/'. But before starting the program all parts of KDE (KDesktop, Kicker/Panel(control bar)) are loaded and started. Until the start of the program it is possible to interact with the System (with the help of kde). But this should not be possible. I want to avoid that the special user can interact with anything other than the desired program. Based on some tips and hints I tried to load the start-script with the help of the file '$HOME/.xinitrc'. Part of the edited file: . . # #Add your own lines here # exec <start-script> & # # exec $WINDOWMANAGER #all failsafe exit 0 With this implementation the program ist loaded in the background, before the windowmanager (KDE) is loaded and started. But the program was also started just after the startup of KDesktop, Kicker and the other parts of KDE. The interaction with KDE was also possible for the user. I edited the .xinitrc again: . . # # exec $WINDOWMANAGER & exec <start-script> #all failsafe exit 0 After the modification the windowmanager was loaded in the background and the program was loaded and started directly. But some of the KDE-parts were loaded after the program-start. As a result the Kicker/Panel was displayed over the program. This wasn't what I wanted, because there is also interaction possible (for a longer time than the other solutions). The files in '/opt/kde3/share/autostart/' seem to advise KDE what services to load in which order. This files seem to be responsible for the whole system (all users). I found no possibility to edit the startup-options for only one user. Because of that I thought about editing the rights of the files and to add a command to the .xinitrc of the special user to move the files (in /opt/kde3/share/autostart/) to a subdirectory before executing the windowmanager. Another command before the command 'exit 0' should write the files back into the right directory. But I don't think, that this is really safe. When the system hang up during the execution of the program the files are not written back. Is there another simple way that is more safe? Greets, Marc ----------- Deutsch --------------------------------------------------------------------------------------- Hallo, ich würde gerne bei einem bestimmten Benutzer (wird mittels Autologin automatisch angemeldet) beim Start vom KDE automatisch ein KDE-Programm laden. Als System verwende ich Suse Linux Prof. 8.2 KDE 3.1 Version 3.1.1-17 (Standardinstallation unter Suse 8.2). Bisher habe ich dazu in dem Verzeichnis '$HOME/.kde/Autostart/' ein Skript hinzugefügt, welches das gewünschte Programm startet. Allerdings wird das Programm natürlich erst geladen, wenn alle KDE-Komponenten, wie z.B. der KDesktop und die Kontrollleiste (Kicker/Panel) geladen wurden. In der Zeit bis zm Programmstart ist somit eine Interaktion mit dem System (mittels KDE) möglich. Dies sollte nicht möglich sein. Anhand verschiedener Tips und Hinweise habe ich das Skript zum Programmstart dann in der Datei '$HOME/.xinitrc' laden lassen. Dies sah dann folgendermassen aus: . . . # #Add your own lines here # exec <Skriptname> & # # exec $WINDOWMANAGER #all failsafe exit 0 Somit wurde das Programm bereits vor dem Windowmanager in Hintergrund geladen, und dann erst KDE. Der eigentliche Start des Programm erfolgte allerdings weiterhin erst nach dem Start von KDesktop, Kicker & Co. Auch hier war leider eine zwischenzeitliche Interaktion möglich. Ich habe die .xinitrc schließlich nochmals modifiziert: . . . # # exec $WINDOWMANAGER & exec <Skriptname> #all failsafe exit 0 Dadurch wurde der Windowmanager im Hintergrund geladen, aber das Programm direkt gestartet und auch angezeigt. Da allerdings noch die gesamten KDE-Komponenten geladen wurden hatte ich nach dem Ladevorgang das Problem, dass die Kontrollleiste mein Programm überlagerte. Nicht nur dass das blöd aussah, es war wiederum die unerwünschte Interaktion möglich. Die Vorgaben, welche KDE-Komponenten geladen werden stehen scheinbar im Verzeichnis '/opt/kde3/share/autostart/'. Leider gelten diese Einstellungen systemweit, also für alle Benutzer. Ich habe keine Möglichkeit gefunden, entsprechende Einstellungen für einzelne Benutzer vorzunehmen. Meine Idee war folglich, die Dateiberechtigungen für die enthaltenen Dateien zu erweitern und in die .xinitrc des gewünschten Benutzers vor dem Laden des Windowmanagers einen Befehl einfügen, welcher die (in der .../share/autostart/) enthaltenen Dateien in einen Unterordner verschiebt. Weiterhin würde dann vor dem Befehl exit 0 ein Befehl eingefügt, welcher die Dateien wieder zurückschreibt. Dies finde ich allerdings weder sicher noch elegant. Denn schon bei einem möglichen Absturz des System im Programmbetrieb würden die Daten nicht wieder zurückgeschrieben. Gibt es evtl. eine andere Lösung, die einfacher/eleganter und vor allem sicherer ist? Grüße, Marc
On Wednesday 13 October 2004 16:58, Marc Klünder wrote:
Hello, I'd like to autostart a program for a special user (is logged in automatically) at the startup of KDE. I use Suse Linux Prof. 8.2 and KDE 3.1 Version 3.1.1-17 (Standardinstallation of Suse 8.2).
Actually the program ist started automatically for the desired user by adding a start-script in '$HOME/.kde/Autostart/'. But before starting the program all parts of KDE (KDesktop, Kicker/Panel(control bar)) are loaded and started. Until the start of the program it is possible to interact with the System (with the help of kde). But this should not be possible. I want to avoid that the special user can interact with anything other than the desired program.
...
Is there another simple way that is more safe?
(I have a bad internet connection so I could not RTFM for you) IIUC, this is controlled in .desktop files. Find info on .desktop files on www.kde.org, there is a description somewhere of the file format. Also there might be more info about the kiosk mode (there is an executable to configure kiosk mode). Cheers, Leen
Marc Klünder's Message from Wednesday 13 October 2004 16:58:
Hello, I'd like to autostart a program for a special user (is logged in automatically) at the startup of KDE. I use Suse Linux Prof. 8.2 and KDE 3.1 Version 3.1.1-17 (Standardinstallation of Suse 8.2).
Actually the program ist started automatically for the desired user by adding a start-script in '$HOME/.kde/Autostart/'. But before starting the program all parts of KDE (KDesktop, Kicker/Panel(control bar)) are loaded and started. Until the start of the program it is possible to interact with the System (with the help of kde). But this should not be possible. I want to avoid that the special user can interact with anything other than the desired program.
Why do you want to start a complete KDE session if the only thing that should be accessible is your program? Wouldn't it be better to just use a plain X session and run only your program (and maybe a lightweight window manager) on it? You probably can achieve this by hardcoding some other window manager in .xinitrc: # # Add your own lines here... # <start-script> & # # finally start the window manager # WINDOWMANAGER=/usr/X11R6/bin/fvwm2 exec $WINDOWMANAGER Then configure fvwm2 in a way that the user cannot start anything else (I hope that is possible). Mario
Hello, Mario Streiber schrieb:
Marc Klünder's Message from Wednesday 13 October 2004 16:58:
Hello, I'd like to autostart a program for a special user (is logged in automatically) at the startup of KDE. I use Suse Linux Prof. 8.2 and KDE 3.1 Version 3.1.1-17 (Standardinstallation of Suse 8.2).
Actually the program ist started automatically for the desired user by adding a start-script in '$HOME/.kde/Autostart/'. But before starting the program all parts of KDE (KDesktop, Kicker/Panel(control bar)) are loaded and started. Until the start of the program it is possible to interact with the System (with the help of kde). But this should not be possible. I want to avoid that the special user can interact with anything other than the desired program.
Why do you want to start a complete KDE session if the only thing that should be accessible is your program? Wouldn't it be better to just use a plain X session and run only your program (and maybe a lightweight window manager) on it?
I tried some other windowmanagers, too. But then i have to find a solution for nearly the same problem just for another windowmanager. Because I found the most relevant informations for KDE, I chose the KDE-solution. Unfortunately I just found most of the solutions for KDE, but not all. ;-)
Then configure fvwm2 in a way that the user cannot start anything else (I hope that is possible).
This is the problem I meant. I also don't know jow to configure this for fvwm2 or any other lightweight windowmanager. If someone wants to give me a hint to increase my knowledge of some other windowmanager than KDE I would be happy of an alternative solution. Marc
Why do you want to start a complete KDE session if the only thing that should be accessible is your program? Wouldn't it be better to just use a plain X session and run only your program (and maybe a lightweight window manager) on it?
I tried some other windowmanagers, too. But then i have to find a solution for nearly the same problem just for another windowmanager. Because I found the most relevant informations for KDE, I chose the KDE-solution. Unfortunately I just found most of the solutions for KDE, but not all. ;-)
Then configure fvwm2 in a way that the user cannot start anything else (I hope that is possible).
This is the problem I meant. I also don't know jow to configure this for fvwm2 or any other lightweight windowmanager. If someone wants to give me a hint to increase my knowledge of some other windowmanager than KDE I would be happy of an alternative solution.
Do you really need a window manager at all? You could also start your application so that it fills the whole screen (using the -geometry X option). If your application exits, the session will terminate and you get back to the login screen. Mario
Hello,
I tried some other windowmanagers, too. But then i have to find a solution for nearly the same problem just for another windowmanager. Because I found the most relevant informations for KDE, I chose the KDE-solution. Unfortunately I just found most of the solutions for KDE, but not all. ;-)
Then configure fvwm2 in a way that the user cannot start anything else (I hope that is possible).
This is the problem I meant. I also don't know jow to configure this for fvwm2 or any other lightweight windowmanager. If someone wants to give me a hint to increase my knowledge of some other windowmanager than KDE I would be happy of an alternative solution.
Do you really need a window manager at all? You could also start your application so that it fills the whole screen (using the -geometry X option). If your application exits, the session will terminate and you get back to the login screen.
I forgot, I tried this way too. But I need some of the supplies of an windowmanager for my program. For example when I want to open a sub-dialog of my program, I got a password dialog. When I run my program without windowmanager, it's not possible toenter the password into the LineEdit. It gets no focus. And I have no window decorations (just for some better look and clarity). Thank you nevertheless. Marc
Marc Klünder a écrit :
Hello, I'd like to autostart a program for a special user (is logged in automatically) at the startup of KDE. I use Suse Linux Prof. 8.2 and KDE 3.1 Version 3.1.1-17 (Standardinstallation of Suse 8.2).
Actually the program ist started automatically for the desired user by adding a start-script in '$HOME/.kde/Autostart/'. But before starting the program all parts of KDE (KDesktop, Kicker/Panel(control bar)) are loaded and started. Until the start of the program it is possible to interact with the System (with the help of kde). But this should not be possible. I want to avoid that the special user can interact with anything other than the desired program.
Based on some tips and hints I tried to load the start-script with the help of the file '$HOME/.xinitrc'. Part of the edited file: . . # #Add your own lines here # exec <start-script> &
# # exec $WINDOWMANAGER
#all failsafe exit 0
With this implementation the program ist loaded in the background, before the windowmanager (KDE) is loaded and started. But the program was also started just after the startup of KDesktop, Kicker and the other parts of KDE. The interaction with KDE was also possible for the user.
I edited the .xinitrc again: . . # # exec $WINDOWMANAGER &
what happens if here you add : sleep 1 (or sleep n) depending of the time necessary to start kde. Michel.
exec <start-script>
#all failsafe exit 0
After the modification the windowmanager was loaded in the background and the program was loaded and started directly. But some of the KDE-parts were loaded after the program-start. As a result the Kicker/Panel was displayed over the program. This wasn't what I wanted, because there is also interaction possible (for a longer time than the other solutions).
The files in '/opt/kde3/share/autostart/' seem to advise KDE what services to load in which order. This files seem to be responsible for the whole system (all users). I found no possibility to edit the startup-options for only one user.
Because of that I thought about editing the rights of the files and to add a command to the .xinitrc of the special user to move the files (in /opt/kde3/share/autostart/) to a subdirectory before executing the windowmanager. Another command before the command 'exit 0' should write the files back into the right directory.
But I don't think, that this is really safe. When the system hang up during the execution of the program the files are not written back.
Is there another simple way that is more safe?
Greets, Marc
----------- Deutsch ---------------------------------------------------------------------------------------
Hallo, ich würde gerne bei einem bestimmten Benutzer (wird mittels Autologin automatisch angemeldet) beim Start vom KDE automatisch ein KDE-Programm laden. Als System verwende ich Suse Linux Prof. 8.2 KDE 3.1 Version 3.1.1-17 (Standardinstallation unter Suse 8.2).
Bisher habe ich dazu in dem Verzeichnis '$HOME/.kde/Autostart/' ein Skript hinzugefügt, welches das gewünschte Programm startet. Allerdings wird das Programm natürlich erst geladen, wenn alle KDE-Komponenten, wie z.B. der KDesktop und die Kontrollleiste (Kicker/Panel) geladen wurden. In der Zeit bis zm Programmstart ist somit eine Interaktion mit dem System (mittels KDE) möglich. Dies sollte nicht möglich sein.
Anhand verschiedener Tips und Hinweise habe ich das Skript zum Programmstart dann in der Datei '$HOME/.xinitrc' laden lassen. Dies sah dann folgendermassen aus:
. . . # #Add your own lines here # exec <Skriptname> &
# # exec $WINDOWMANAGER
#all failsafe exit 0
Somit wurde das Programm bereits vor dem Windowmanager in Hintergrund geladen, und dann erst KDE. Der eigentliche Start des Programm erfolgte allerdings weiterhin erst nach dem Start von KDesktop, Kicker & Co. Auch hier war leider eine zwischenzeitliche Interaktion möglich.
Ich habe die .xinitrc schließlich nochmals modifiziert:
. . . # # exec $WINDOWMANAGER & exec <Skriptname>
#all failsafe exit 0
Dadurch wurde der Windowmanager im Hintergrund geladen, aber das Programm direkt gestartet und auch angezeigt. Da allerdings noch die gesamten KDE-Komponenten geladen wurden hatte ich nach dem Ladevorgang das Problem, dass die Kontrollleiste mein Programm überlagerte. Nicht nur dass das blöd aussah, es war wiederum die unerwünschte Interaktion möglich.
Die Vorgaben, welche KDE-Komponenten geladen werden stehen scheinbar im Verzeichnis '/opt/kde3/share/autostart/'. Leider gelten diese Einstellungen systemweit, also für alle Benutzer. Ich habe keine Möglichkeit gefunden, entsprechende Einstellungen für einzelne Benutzer vorzunehmen.
Meine Idee war folglich, die Dateiberechtigungen für die enthaltenen Dateien zu erweitern und in die .xinitrc des gewünschten Benutzers vor dem Laden des Windowmanagers einen Befehl einfügen, welcher die (in der .../share/autostart/) enthaltenen Dateien in einen Unterordner verschiebt. Weiterhin würde dann vor dem Befehl exit 0 ein Befehl eingefügt, welcher die Dateien wieder zurückschreibt. Dies finde ich allerdings weder sicher noch elegant. Denn schon bei einem möglichen Absturz des System im Programmbetrieb würden die Daten nicht wieder zurückgeschrieben.
Gibt es evtl. eine andere Lösung, die einfacher/eleganter und vor allem sicherer ist?
Grüße, Marc
participants (4)
-
Catimimi -
Leendert Meyer -
Marc Klünder -
Mario Streiber