Boot directly to an X app?

[jonathanbrickman0000]

I am checking feasibility of converting the PC TSC project ( http://pctsc.ponderworthy.org ) to Tiny Core, and have one question:  if I wanted to make a custom Tiny Core setup which would always boot directly into a certain GUI app, with no X desktop, what would be the best route?  rc.S?  ~/tc/.profile?  Other?

J.E.B.

[SamK]

...boot directly into a certain GUI app...

A way is described in the FAQ. If I recall correctly it requires at least TC3.1.  Have a look here:
http://www.tinycorelinux.com/faq.html#appstart
   

[jonathanbrickman0000]

That will do very nicely, thanks.  One more question:  Is there a recommended way to suppress the default desktop, and run just my little X app (rdesktop in a script)?  I didn't find those items in ~/.xsession, and I'd like to be as well-behaved as possible.  The idea is to hopefully replace one file in such a way that if the user flips to a vc he/she can log in and run a script which brings the Tiny Core back to default running.

[tinypoodle]

I suspect what you mean by

Code: [Select]

suppress the default desktopmight be to start X with a single X app, but without any window manager.

This should be possible, but exact syntax to do it may depend on the X server used.

[jonathanbrickman0000]

Yup, that's exactly it.  I believe it was at the bottom of ~/.profile that I saw "startx", and that could be a really good jumping-off point for this, but I thought I would ask before assuming, I have come to really appreciate the Tiny Core community.

J.E.B.

[curaga]

Comment out the $DESKTOP line in .xsession. It should work no matter which WM is used.

[maro]

@jonathanbrickman0000: I'm not at all familiar with the application you plan to use, and to be honest I have no prior experience with what I'd consider a "kiosk mode" setup. Therefore my musings are probably incomplete, but might still give you at least some idea.

You already had a quick glance into what I believe would lead you to your aim: In following the "trail" one finds that '~/.profile' has 'startx' as it's last command. That brings up the X server (which defaults to 'Xvesa') and finally hands over controll to '~/.xsession'. In there the WM is started via the "$DESKTOP" 2>/tmp/wm_errors & line. That explains the suggestion from curaga to suppress it's execution. As the value of $DESKTOP is controlled by the 'desktop' boot code I've come up with an alternative approach:

As I'm doing all my testing via virtual systems (using mostly QEMU, but also VBox) I've done a quick test where the (virtual) hard disk has just the 'opera.tcz' extension as my "default" application for this test installed. Now simply using boot code 'desktop=opera' results in the browser been run instead of the window manager.

Since I did not choose the boot code 'noicons' the 'wbar' will still been started. And if a user terminates the "default" application (i.e. 'opera') one gets a chance of playing around with a terminal, the control panel or 'appbrowser'. I assume you would rather avoid this for your project, so you could add the 'noicons' boot code to your respective boot manager stanza. OTOH you might want to allow a user to restart the "default" application and having therefore it's icon in the 'wbar' (like it was the case in my play with 'opera'). I therefore did
sudo sed -i -e '/[Aa]term/d' -e '/[Pp]anel/d' -e '/[Aa]pp/d' \
    -e 's#exittc#sudo poweroff#' /usr/local/tce.icons && wbar.sh
to remove those temptations, but still leave the option to restart the "default" application and the option to turn the system off (albeit in a non-standard way, but eliminating the reboot, CLI and backup options). If you put this command sequence into a file like '~/.X.d/reduce_wbar' you would get the "reduced wbar" automatically at each X server start.

It now depends how much you need to further "nail down" the ability for the user to get hold of a terminal session. The two ways that I can think of are to either use 'ctrl-alt-backspace' to crash the X server and arrive at the console, or via 'ctrl-alt-F1' to gracefully change to the underlying console. IIRC for the former there is a option when using 'Xorg' to prevent this to happen. I also believe that the latter has been discussed here in the forum, but I'm right now running a bit out of time to search for it.

[curaga]

Clever, $APP_as_$DESKTOP

[jonathanbrickman0000]

I like that a whole lot!!!  

I do have multiple requests for keeping users out of shell altogether.  So in all probability, I need to do both.

I tried adding "exit" to the end of .profile, this takes care of Ctrl-Alt-Backspace very nicely, and VC respawn getty is working nicely; I'll have to try Alt-F1 later.

Hopefully tonight I'll have time to have some fun with this :-)  I am new to Tiny Core, but increasingly I am amazed.  

J.E.B.

[maro]

I think I have now a possible solution to the issue of keeping the user out of the console, even when using Xvesa (to be honest I've only tested it with Xvesa):

Simply adding 'exit' to '~/.profile' did not work for me. I suspect that the fact that the execution of '~/.profile' came to an (early) end got gets signalled to the starting Xserver, and that leads to an end of the GUI. But by adding the following few lines to the very end of ~/.profile' (after the 'startx' command) I achieved that any login shell terminates itself as soon as it "sees" the X server running:
APP=$( cat /etc/sysconfig/Xserver )
if [ "$APP" ] ; then
    while [ -z "$(ps -o args | grep -E "(^|/)${APP}( |$)" )" ] ; do
        sleep 1
    done
    exit
fi

This seems to work quite well for the two cases I mentioned yesterday: when the X server gets killed the user ends up at the console login prompt. Now the user could try to login again as user 'tc', which would just lead to a restart of the X server and the "default" application (without allowing for access to a shell prompt). Likewise when the user switches to the console (with the X server still running) it will find the login prompt. Trying to login as user 'tc' leads to a quick end of the affair (as the X server is already running), without gaining access to a login prompt. So the "probing" user would not have much choice and might as well return back to the GUI.

So far so good, but there is a small window of opportunity to interrupt the execution of '~/.profile' with 'crtl-C' (i.e. SIGINT). Well, I think that can be prevented by inserting the following few lines at the very start of ~/.profile':
catch()  {
    printf "\nWas this not a bit naughty of you?\n"
    sleep 3
    exit
}
trap catch SIGINT

After these few admendments the only way I could get hold of a login shell is when using boot codes 'base' or 'norestore'. I assume the user should not get much of a chance to enter any additional boot codes, but that depends on the choice of the boot loader. I furthermore assume that the changes to '~/.profile' would be integrated (together with the "default" application) in a remastered initrd. In which case neither of the two boot codes would have any effect, as no extension loading or restoration from backup would need to take place. BTW, in case of remastering the file that needs to be changed is actually '/etc/skel/.profile'.

[tikbalang]

i hope this becomes a feature.

[Goldcap]

This is a great thread, and I'm hoping someone is still out there working on this.

I need a kiosk iso, and would love to not spend a week on it, if possible.

Anyone have the winning combo for this? What eventually worked?

[maro]

What do you mean with "... someone is still out there working on this ..."? I for one believe that I've already done quite a bit in explaining (in reply #6 & #9) what I'd consider as required to produce a reasonably "tight" kiosk mode TC system.

So it really depends on yourself to properly read the Wiki (e.g. re. remastering and integration of extensions) and integrate what has been proposed above. To undertake your own testing I highly recommend to use VMs. In particular QEMU due to it's '-kernel', '-initrd' and '-append' options is particular good in this regard. Nevertheless the time it takes for you to finish such a project depends on how well you know Linux in general, and how quickly you come to grasp TC's unique features.

There are several ways to achieve the same end result and there are probably pros and cons for each of them. For example to implement the basic idea of using an apps name instead of a WM via the 'desktop' boot code. You could:
(a) amend the boot loader configuration and add a 'desktop=xxx' entry, or
(b) create an entry in '/opt/bootsync.sh' like echo xxx > /etc/sysconfig/desktop to overwrite the default entry during system startup (but before the X server startup), or
(c) change the entry in '/etc/sysconfig/desktop' directly to be 'xxx' when you remaster the initrd.

Likewise the suggested change to the 'wbar' configuration could be either done "dynamically" (by execution of the 'sed' command at a suitable time during the system startup (e.g. in '/opt/bootsync.sh'), or "statically" by changing the '/usr/share/wbar/dot.wbar' default configuration file. Or it might not be required at all if you decide to not offer a 'wbar' at all (hint: boot code 'noicons').

I for one are not planning to "work on this" any further as the steps are IMHO to be sufficiently tested and documented. It is now up to the interested user to apply them for any individual project. If specific issues arise I'd suggest to create a new thread to seek some more help from the community.