pclos edu: how do we lock icons on their position?

[pclosgr]

Ok I have just one think to say about pclinuxos edu
BRAVO BRAVO BRAVO!
very nice! very usefull!!
I burned it, put locales and some other things in it in order to use it for my children and started giving it to friends

It is the first time that many of my friends showed interest about linux and pclinuxos!!

I think it can prove itself as the first step towards the linux family for many! Bravo melodie and all the others!

I also have a question : Is there a way in openbox to lock the icons on their position (as my daughter keeps pressing the mouse button) so  "nobody" can easily accidentally delete any of them??

[melodie]

Hi,

You can easily do a "snap to grid", or "keep position" (something looking like that) with a right-click on each icon, but nothing can be done to prevent accidental removing. On the other hand, it is very easy to add them again, just go to the menu entry from the general menu button, right-click on the desired entry and select "add to desktop".

I have put all these icons on the desktop to easy their finding, because the menu entries can't be tweaked easily to get a section specific to Edu games, directly available as main menu, or first sub-menu... but you will always find them in the general menus anyhow, if you search a little. You can also find a copy of them all, in the directory : /etc/skel/Desktop.

Thank you for sharing your joy to have it. I am happy to know you are one more user who likes it and finds it useful.

Regards,
Mélodie

[travisN000]

I do not use open box, but it seems with some creative use of file permissions you should be able to make it so that they cannot be deleted by the kids...  

change the ownership so that they are owned by a different user (root, or parent account), but can still be viewed/executed by others in the group.  I believe all regular users are part of the group "users", but if not you could set this up easily from PCC.  

Just a hint on setting this up... delete is controlled by the "write" permission (allow read and execute by the group, but not write)  

[melodie]

Just a hint on setting this up... delete is controlled by the "write" permission (allow read and execute by the group, but not write)  

Hi,

travisn000, that looks like a good idea, simple to do. I would even suggest to go to the Desktop directory with the file manager, PCManFM, and do a right click on each of the desktop files, then remove the write permission, in the right-click menu "properties > tab permissions".

That could work.

[djohnston]

I do not use open box, but it seems with some creative use of file permissions you should be able to make it so that they cannot be deleted by the kids...  

change the ownership so that they are owned by a different user (root, or parent account), but can still be viewed/executed by others in the group.  I believe all regular users are part of the group "users", but if not you could set this up easily from PCC.  

Just a hint on setting this up... delete is controlled by the "write" permission (allow read and execute by the group, but not write)  

I had looked at doing something like this after reading the original poster. On an installed Edu, I su'ed to root and changed ownership and permissions on all the desktop files.

chown root:root *.desktop
chmod 555 *.desktop

All the files are owned by root, and none are writable. However, when logged in as the regular user, I'm still able to right-click a desktop file and send it to the trash.

[Texstar]

I do not use open box, but it seems with some creative use of file permissions you should be able to make it so that they cannot be deleted by the kids...  

change the ownership so that they are owned by a different user (root, or parent account), but can still be viewed/executed by others in the group.  I believe all regular users are part of the group "users", but if not you could set this up easily from PCC.  

Just a hint on setting this up... delete is controlled by the "write" permission (allow read and execute by the group, but not write)  

I had looked at doing something like this after reading the original poster. On an installed Edu, I su'ed to root and changed ownership and permissions on all the desktop files.

chown root:root *.desktop
chmod 555 *.desktop

All the files are owned by root, and none are writable. However, when logged in as the regular user, I'm still able to right-click a desktop file and send it to the trash.

http://linuxhelp.blogspot.com/2005/11/make-your-files-immutable-which-even.html

[Taco.22]

Another option is to use "idesk".  It's in the repo and the .ideskrc file gives you the option of locking icons in position.  It's footprint is small and it's easy to configure.  It does require manual file editing to add icons, but in the case of OB Edu I don't think that is an issue - the idea is a version that is bullet proof, fool proof and child proof!  Just make sure the obvious icons are covered and that should do it.  You will need to disable PCManFM's control on icons.  I used to use idesk some years back but have gone away from icons, not to mention docks, panels, bars and all that other frippery .  I gave it a trial run just now and it works well - can't move an icon at all in locked state.  Maybe something to consider.

Extra thought - may be useful in situations of public access computers.  Amazing what some people can do to icons!!
 

[melodie]

Another option is to use "idesk".  It's in the repo and the .ideskrc file gives you the option of locking icons in position.  It's footprint is small and it's easy to configure.  It does require manual file editing to add icons, but in the case of OB Edu I don't think that is an issue - the idea is a version that is bullet proof, fool proof and child proof!  Just make sure the obvious icons are covered and that should do it.  You will need to disable PCManFM's control on icons.  I used to use idesk some years back but have gone away from icons, not to mention docks, panels, bars and all that other frippery .  I gave it a trial run just now and it works well - can't move an icon at all in locked state.  Maybe something to consider.

Extra thought - may be useful in situations of public access computers.  Amazing what some people can do to icons!!
 

Hi,

I find idesk difficult to use. I tried it once and I had to look into the config files to see how to use it. I was looking forward to someone working again on it, as it was not updated since many years, but no one does, at the moment.

The trick Texstar points to, with the chattr attribute is not difficult to use and deserves a test. I don't know if that really works, because I wanted to use it on some system file (maybe a file belonging to initscripts) before an update, and that didn't work : the file had been rewritten by the update. I had a copy of the file somewhere else, of course... the point is in that case the chattr attribute didn't do anything. Maybe in the home user this will work ?

Another idea would be to have a backup of the files in one of the user's hidden directories, and have the $HOME/.config/openbox/autostart.sh file contain a line to make a copy of the files to the desktop at each new session.

[Texstar]

Another option is to use "idesk".  It's in the repo and the .ideskrc file gives you the option of locking icons in position.  It's footprint is small and it's easy to configure.  It does require manual file editing to add icons, but in the case of OB Edu I don't think that is an issue - the idea is a version that is bullet proof, fool proof and child proof!  Just make sure the obvious icons are covered and that should do it.  You will need to disable PCManFM's control on icons.  I used to use idesk some years back but have gone away from icons, not to mention docks, panels, bars and all that other frippery .  I gave it a trial run just now and it works well - can't move an icon at all in locked state.  Maybe something to consider.

Extra thought - may be useful in situations of public access computers.  Amazing what some people can do to icons!!
 

Hi,

I find idesk difficult to use. I tried it once and I had to look into the config files to see how to use it. I was looking forward to someone working again on it, as it was not updated since many years, but no one does, at the moment.

The trick Texstar points to, with the chattr attribute is not difficult to use and deserves a test. I don't know if that really works, because I wanted to use it on some system file (maybe a file belonging to initscripts) before an update, and that didn't work : the file had been rewritten by the update. I had a copy of the file somewhere else, of course... the point is in that case the chattr attribute didn't do anything. Maybe in the home user this will work ?

Another idea would be to have a backup of the files in one of the user's hidden directories, and have the $HOME/.config/openbox/autostart.sh file contain a line to make a copy of the files to the desktop at each new session.

Then you don't know how to use chattr if it didn't work.

[root@thenudiebar Music]# ls
Rihanna-Rockstar.mp3
[root@thenudiebar Music]# chattr +i Rihanna-Rockstar.mp3
[root@thenudiebar Music]# rm -rf Rihanna-Rockstar.mp3
rm: cannot remove `Rihanna-Rockstar.mp3': Operation not permitted
[root@thenudiebar Music]# ls
Rihanna-Rockstar.mp3

[Taco.22]

I find idesk difficult to use. I tried it once and I had to look into the config files to see how to use it. I was looking forward to someone working again on it, as it was not updated since many years, but no one does, at the moment.

OK, maybe it's just me, but setting up new icons in idesk is no different to setting up .desktop files.  The default install gives a number of link options - you just need to set the icon path to make these happen.  One of the options was Thunderbird, which I use.  However I had to reset the icon path for it to appear.  Then it worked.  The files are stored in the /.idesktop folder in the user folder.  Just copy and modify them to add whatever icons on the desktop - position is given as co-ordinates, just like conky.  It is quite simple, and once set up then it doesn't need to be fiddled with again.  Remember, this is to set icons as immovable to suit OB Edu - not something that needs to be done under usual circumstances.  

[melodie]

Then you don't know how to use chattr if it didn't work.

[root@thenudiebar Music]# ls
Rihanna-Rockstar.mp3
[root@thenudiebar Music]# chattr +i Rihanna-Rockstar.mp3
[root@thenudiebar Music]# rm -rf Rihanna-Rockstar.mp3
rm: cannot remove `Rihanna-Rockstar.mp3': Operation not permitted
[root@thenudiebar Music]# ls
Rihanna-Rockstar.mp3

Hi,
I'can try to fix the attributes of theses files for next version. I suppose it can be done on the files which are in
/etc/skel/Desktop as well ? Would a "-a" instead of a "-i" be a better way for that purpose ?

Thanks,
Mélodie

[djohnston]

http://linuxhelp.blogspot.com/2005/11/make-your-files-immutable-which-even.html

Bingo! I forgot that one. That does the trick. Thanks, Tex!

#chattr +i *.desktop

[djohnston]

I find idesk difficult to use. I tried it once and I had to look into the config files to see how to use it. I was looking forward to someone working again on it, as it was not updated since many years, but no one does, at the moment.

OK, maybe it's just me, but setting up new icons in idesk is no different to setting up .desktop files.  The default install gives a number of link options - you just need to set the icon path to make these happen.  One of the options was Thunderbird, which I use.  However I had to reset the icon path for it to appear.  Then it worked.  The files are stored in the /.idesktop folder in the user folder.  Just copy and modify them to add whatever icons on the desktop - position is given as co-ordinates, just like conky.  It is quite simple, and once set up then it doesn't need to be fiddled with again.  Remember, this is to set icons as immovable to suit OB Edu - not something that needs to be done under usual circumstances.  

Thanks, Taco.22. Something more to experiment with. Linux is fun. 

[melodie]

Thanks, Taco.22. Something more to experiment with. Linux is fun. 

Yes, it's fun ! Thanks to all.

I was wondering if the "chattr -i", done on the desktop files in /etc/skel would still allow the files to be copied to a new user's account ? This is why I was asking if a "-a" would not be more appropriate in this case ? (I don't have enough time just these days to search about it, but if no one knows, I'll dig it later, when it will be time to update the ISO).

Regards,
Mélodie

[djohnston]

I was wondering if the "chattr -i", done on the desktop files in /etc/skel would still allow the files to be copied to a new user's account ? This is why I was asking if a "-a" would not be more appropriate in this case ?

From the chattr man page:

A file with the `a' attribute set can only be open in append mode for writing. Only the superuser or a process possessing the CAP_LINUX_IMMUTABLE capability can set or clear this attribute.

A file with the `i' attribute cannot be modified: it cannot be deleted or renamed, no link can be created to this file and no data can be written to the file. Only the superuser or a process possessing the CAP_LINUX_IMMUTABLE capability can set or clear this attribute.

I started the Edu installation, then as root did:

cd /etc/skel/Desktop
chmod 555 *.desktop
chattr +i *.desktop

Then I ran mylivecd. I took the generated iso and used it to install to a VirtualBox VM. The installation went normally. On first boot, I created a new user and logged in as that user. The skeleton desktop files' attributes did not carry over to the user's Desktop directory. The user's desktop files still have the same modes of read and execute for user, group and others. No one has write access. The files are owned by newuser:newuser. The immutable attributes did not carry over. I then checked the /etc/skel/Desktop directory on the installation. They still have the immutable bit set. So, the immutable bit is not being preserved when a new user is created.