canonical wayof making changes to wbar and menu survive reboots

[jamtat]

I've got my test install working and am now struggling with getting the system configured properly. This is post refers to a brand new 2.9 mount implementation of TCE, btw.

I find myself now trying to reverse some of the ways in which this distro is designed to work, since they are not appropriate to the setting in which the target machines are used. Again, this is for a small computer lab I volunteered to set up and administer in a retirement community.

Tinycore is set up to always reboot to some pristine state. In my case this is undesirable since the pristine state to which it wants to reboot is one that contains some problematic elements. So, as I see it,  I need to somehow thwart the system's design on each reboot.

The problem I have with tinycore's out-of-the-box design is that there are several readily-available elements in the GUI which are bound to cause problems for my implementation. You see, most of the users of these machines are pretty clueless about how computers work. Experience thus far has shown that they sit in front of the computer rooting around through various menus and clicking on things without any clear understanding of what those things do. This can lead to serious problems when certain administrative functions are at their disposal.

For example, I foresee all kinds of undesirable results and misconfigurations occuring if these users will have access to the Appbrowser and/or Cpanel. In addition to being readily available in the taskbar (wbar) these and other potential weapons of mass destruction are located in the popup menu as well.

I can, of course, get rid of them by deleting items from the /home/tc/.wmx directory or from /usr/share/wbar/dot.wbar. But I note that, owing to the way the system is designed, those things get restored on reboot.

Thus I need to ask: what's the canonical way of permanently getting rid of items in the wbar? Likewise, how can I cause certain menu items to disappear and remain inaccessible across reboots?

Input will be appreciated.

Thanks,
James

PS Should I perhaps be using the local/install instead of the mount option for this implementation?

[Guy]

You could look at remastering.

http://wiki.tinycorelinux.com/tiki-index.php?page=Remastering


After you have removed things, you will not be able to use them yourself.

If the computers will boot from a usb drive, you could use a usb installation for future system administration. However, older computers will not boot from a usb drive.

You could make integrate extensions in an iso and use that for future system administration.
http://wiki.tinycorelinux.com/tiki-index.php?page=Integrating+Extensions

Another option is to connect the hard drive in another computer for future system administration.

[althalus]

1. Make use of backups to maintain changes to the popup menu
2. Install pcmanfm, configure it to control the desktop to hide the popup menus. Use persistent home/backups to maintain wbar config.

Whilst the design is to reboot to a pristine state, I think very few people use TC as such. Much more common is pristine state + files contained within a backup.

[roberts]

Pristine refers to the fact that system files come from an gzipped initramfs and the apps from squashfs.
Much less chance from system rot or user oops.

Of course users can have a backup of the data files typically in their home directory. But system is flexible enough to include whatever.

Custom configuration files can easily be made into a custom tcz extension and then no backup would be necessary for use an an appliance.

 I am a senior. My friends are all senior, they have used DSL when I was writing that and now they use tinycore. Much less support needed than typical scatter mode installed systems.

It is worhtwhile to learn the Core way.

[jamtat]

The way I went about this so far has been to add several rm arguments to ~/.xsession, which made the pop-up menu appear as I wanted it to appear (minus a lot of the administrative functions otherwise contained there). So far so good. But I was still left with some undesirable administrative functions in the wbar. I tried getting rid of those by adding some rm and cp arguments to bootlocal.sh: that didn't work out so well. I'm now left with an invisible or non-existent wbar. To compound the problem, I don't have access to a terminal while in the GUI and so cannot change back bootlocal.sh to its former state, then logout and chose to back up. I could log out of the GUI and change back bootlocal.sh, but I need to know what is the command to reboot-with-backup. Any hints on how to reboot the system with back-up from the CLI?

Thanks,
James

PS I have no opposition to learning the core way. But I'm beginning that process by working from what I currently know, as discussed in this thread.

[Guy]

When experimenting, you may want to create two Ext3 partitions, and install Tiny Core on both. When something doesn't work, you can boot the other one and fix it.

I recommend using persistent home and opt, and not including them in backup.


One way to modify the menu and wbar is as follows.

Create a new directory in /home/tc, let's call it .mymenu (names beginning with . are hidden).


Wbar

In .mymenu, create another directory, let's call it wbar.

Copy tce.wbar from /usr/local to /home/tc/.mymenu/wbar

Edit tce.wbar how you want it.

Add the following to /opt/bootlocal.sh

mv /usr/local/tce.wbar /usr/local/origtce.wbar
cp /home/tc/.mymenu/wbar/tce.wbar /usr/local/tce.wbar


Menu

Create a new directory in /home/tc/.mymenu called .wmx.

Copy files and directories from /home/tc/.wmx to /home/tc/.mymenu/.wmx

Edit them as you want them. (Remember OnDemand is there)

Add the following to /opt/bootlocal.sh

mv /home/tc/.wmx /tmp/.origwmx
cp -r /home/tc/.mymenu/.wmx /home/tc/.wmx


If you have a file manager (such as Xfe) and text editor installed, and keep a (non-root) terminal in the menu. You can still do any administrative tasks yourself.

For example, you can type sudo xfe in the terminal to start Xfe as root. You can copy anything from .origwmx to .wmx and use those applications.

[jamtat]

I'm finally getting around to trying your solution, Guy, and it does not work. I've double- and triple-checked spelling, paths, existence of newly-created directories, and so on. There is no origtce.wbar in /usr/local, for one thing. So that part's not working. Furthermore, /usr/local/tce.wbar does not match /home/tc/.mymenu/wbar/tce.wbar, so that part's not working either. mv /home/tc/.wmx /tmp/.origwmx seems to be about the only part of this routine that works, since I do find a /.origwmx in /tmp. But what's in /home/tc/.wmx does not match the content of /home/tc/.mymenu/.wmx, so that part doesn't work either.

Thus, my original question still stands: how can I modify, such that it survives reboots, wbar and the pop-up menu that appears when you click on the background? For this distro to be a multi-user system (one where you don't want all users to be able to fiddle with important system files and settings), this sort of thing has to made more straightforward. As it stands I'm stuck trying to reverse-engineer the way the system has been set up to function.

James

[tinypoodle]

To compound the problem, I don't have access to a terminal while in the GUI and so cannot change back bootlocal.sh to its former state, then logout and chose to back up.

In jwm Ctrl+Alt+Enter brings up an aterm 

I could log out of the GUI and change back bootlocal.sh

No need to logout, Ctrl+Alt+F1 to switch to tty1, Ctrl+Alt+F2 to switch back to X

[jur]

I have written a set of instruction of how to accomplish the wbar hack. See
http://forum.tinycorelinux.net/index.php?topic=6762.0