piserver
piserver copied to clipboard
Feature Request: add support for importing customized RPI OS SD cards
As you might have notices we are having a very active conversation with incognitum over @ https://www.raspberrypi.org/forums/viewtopic.php?f=36&t=305747
I´d like to post some feature requests here that might be very helpfull for all the (not very admin afine) teachers out there:
Let me come directly to the point:
-
native Support for converting a SD-Card to the folder structre in PIServer. The aim is to get rid of the whole compression and decompression process. There should be a menupoint "convert SD-Card" that asks and get it automatically converted to the folder and OS choices. Insert SD-Card - get ask for the path of the SD-Card, start copying directly to the folder structure. This would lower the barrier VERY much.
-
support an option to convert the standard pi-user-settings to the standard settings of new users on server. Background: when converting an image: the changes made to the main PI user (GUI theming, ICON theming, other GUI Settings, menu-entrys, backdrops, font- and color settings etc.) should be converted to the standard settings of NEW users on the server - This would make it much easier for teachers to e.g. lowering the barrier using individual settings for e.g. inclusion
-
support the choice to have appimages included in a special folder or the /opt folder. The changes should then reflect the changes to make /tmp executable and writeable as incognito pointed in the thread.
It would be a blast to have all this included directly to the server-application.
Thank you very much for making piserver happen. We teachers really need this!
Is it ok for you guys if we post future feature requests from ateacher-perspective ? Other would appreciate this too...
Here's a build with experimental support to import SD cards in the "add software" window, that could use some testing.
-
Does do an attempt to copy entries you made with the "menu editor" as the Pi user to the global /usr/share/applications directory. If you use custom icons, you do need to put them in a global directory yourself. (The script is currently not smart enough to parse the menu entries and move over icons that are in /home/pi.)
-
Currently only have the option in "add software" in the software tab. (Not in the software installation step during initial installation)
-
There is no real progress indication during copying the files from SD card, so it is "normal" if the progress bar is stuck at 0.0 MB for quite a while.
Excellent. Thank you so much, maxnet, for listening! We´ll try that out today and give feedback soon!
But let me discuss some thoughts with you first:
We changed our internal process to generate the master-image to use etc/skel structure to reflect changes made to gui and menu to new users as stated here: https://www.raspberrypi.org/forums/viewtopic.php?f=36&t=305747&sid=c7dced0a4f33738a26dbb27a28f2185c&start=50#p1857394
My question is:
Wouldn´t it probably be a better choice to implement the menu-entry copy from the masterimage to the server /etc/skel side? This could be done directly by the SD-Copyprocess.
If I got it right your implementation would now combine the entrys in /etc/skel (if there is any located on the server) AND /usr/share/application. Wouldn´t this lead to doubleentries in the menu structure? Btw. I find lxde very buggy combining folders and hand-made changes with the menu-editor. I had to start back from scratch several times now when I make the master image and find the skel way much more robust on the local side.
So my point is: Everything I do on the masterimage should somehow be reflected on the serverside. The process could be the following:
If I add a new user on our local masterimage via "sudo adduser name" the skel content is beeing copied over and the new local Image user has the exact same environment than the standard pi user. This normal process makes my local image multiuser with ONE environment. The same should somehow be reflected on the converted image - so the contents of the local skel should be copied to the server skel.
Now we come to the problem of updates. If I UPDATE my local image and make a new copy changes won´t be reflected to the old users. Menu entry and later gui changes won´t come up etc for old users on the server. I have the same problem with the local image and copy changes by hand to the local home of the new users. I would dump the /usr/share/application copy from piservers conversion then!
So from my view there should be a "UPDATE existing image" Button where you can generate an updated server version from an updated local master image SD-Card. The copying to all the user-entrys from /etc/skel to all OLD users should then be automated on piserverside.
Non technically speaking I don´t really know if this is a good idea ;) Hope it is. And I hope I could have made myself clear - please bear in mind that I´m not a native english speaker.
BTW are incognitum and maxnet the same person ? ;)
Wouldn´t it probably be a better choice to implement the menu-entry copy from the masterimage to the server /etc/skel side?
I personally do not think so. Some people like to use Piserver with more than one image, letting some Pi in the network boot image A, and some Pi boot image B. Home directories (which are populated by /etc/skel when user is created) are not specific to an image. So if we would put entries there, there would be non functioning entries when booting the other OS.
In addition it would not be possible to add additional entries later after a user already logged in, without going into people's personal home directories (which is considered bad practice).
If you put your extra entries (for e.g. your appimages) in /usr/share/applications it do is possible to add more later.
You generally should only use /etc/skel for settings that can not be done in a global directory. An example would be if you want to put an icon on the user's desktop (where the "trash bin" icon is) instead of in the menu.
I answered over in the forum thread on raspberry forum: https://www.raspberrypi.org/forums/viewtopic.php?f=36&t=305747&start=75#p1858962 Nevertheless is there a way to make changes in TMP as described here as a clickable option to make appimages work on the pi-server OSes ? Is this a heavy security-problem when it comes to school environments?
Incognitum refered to a possible way here: https://www.raspberrypi.org/forums/viewtopic.php?f=36&t=305747&start=25#p1856075
Nevertheless is there a way to make changes in TMP as described here as a clickable option to make appimages work on the pi-server OSes ?
noexec on /tmp was already removed (see changes in convert cmds: https://github.com/raspberrypi/piserver/commit/295f9076af6bebfb8ec3fd43509538d5bd4ab714#diff-40437b51d451e4fbba7ec9fc3dbe2ea59007b7ee3bc316aab1d4d9db0a29b817 ) If your appimages still do not work with the beta, there may be something else wrong.
Here's a build with experimental support to import SD cards in the "add software" window, that could use some testing.
* Does do an attempt to copy entries you made with the "menu editor" as the Pi user to the global /usr/share/applications directory. If you use custom icons, you do need to put them in a global directory yourself. (The script is currently not smart enough to parse the menu entries and move over icons that are in /home/pi.) * Currently only have the option in "add software" in the software tab. (Not in the software installation step during initial installation) * There is no real progress indication during copying the files from SD card, so it is "normal" if the progress bar is stuck at 0.0 MB for quite a while.
thxs 4 adding this. works 4 me like a charme and spare's me pain in the a** waiting time to compress, transfer, decompress the image.
I am trying to use this feature but unfortunately my SD card with the OS flashed on it is not appearing in the SD card dropdown menu. I am not sure why this is the case but could it possibly be because my SD card is only visible at dev/mmcblk0p*
not dev/sd*
?
I am not sure why this is the case but could it possibly be because my SD card is only visible at dev/mmcblk0p* not dev/sd*?
Something like that, yes. The name of the device does by itself not really matter, however we do are currently only showing disk devices that have a "vendor" and "model" name in the list, and perhaps the mmcblk0 device of your computer does not have one.
Will get that fixed in next version. Use a USB card reader for now as workaround.