I assume then, you are also unable to upgrade the SSDs in these machines to something that would bypass this issue. As, with 16GB, the issue isn’t even getting Windows Licenses, since you wouldn’t have the space to even install Windows 10 on that size drive. If the SSDs are not upgradable, I know your pain, as I’ve had to help deal with two of these recent “HP Stream 14” laptops that have only 32GB of storage which is barely enough to install Windows 10, but then not enough for it to later download updates leading to all kinds of ridiculous nonsense… My solution was indeed to install Linux as the eMMC storage is soldered to the Motherboard on those laptops…
A simpler solution however, that doesn’t bring up many potential headaches would be to just use a single shared user account on each of the machines. This is what 3468 does with our 6 shared programming laptops. If you really still want to stick to having separate user accounts, and heal with the headaches therein, then keep reading.
So, to start, I’m not sure why you are symlinking each individual sub-directory.
You should just need one symlink.
/home/user/wpilib -> /opt/wpilib
and in theory you’re covered for multiple years in one go (assuming the directory structure doesn’t get changed yet again).
As for if it will work. Based on what I know of how the WPILIB is setup (for which I am making several assumptions, so hopefully someone more familiar does chime-in) I’m pretty sure it will provided you setup the permissions correctly. Also note, I think a lot about security, so some of that will have shaped my answers/explanations below.
You’ll need to make sure every other user will have the proper minimum permissions. Clearly this will involve Read permissions and probably Execute Permissions. If we can get away without Write permissions that would be good since it would keep one student from nuking the whole WPILIB install for the system. Looking at my own WPILIB install from this year, I see no file changes after the initial install except for updating the tools and changes in the maven dir from adding the SparkMAX VendorLib. With these considerations in mind, know that these ares may be pain points down the line if the students don’t have write permissions.
There are a few ways we can setup the permissions. The first and simplest is to just give everyone access to the /opt/wpilib/ directory and its sub-directories/files. chmod -R 755 /opt/wpilib/ for example.
A more fancy method would be to create a group, say wpilib, frc, programmer, ect. have the /opt/wpilib/ directory structure’s group set to it, as well as give the group as a secondary group to the student’s accounts.
groupadd wpilib
chown -R root:wpilib /opt/wpilib
chmod -R 750 /opt/wpilib
usermod -aG wpilib user
IF Write permissions are needed, or you want to give them, then I HIGHLY recommend going with the group setup rather than give everyone write access to the directory.
Also, there are options on linux meant to maintain shared directories. These tools are the umask, sticky bit and setuid/setgid.
The umask allows us to set what the permissions should be on any newly created files in a directory/directory structure. So we could make sure the right permissions are set on any files a student may have to create if they have write perms. You can even specify Sticky and SUID/SGID perms.
The Sticky Bit sets a directory such that only the owner of the file/directory can rename/move and delete files/directories in that structure where the sticky bit is set. So someone else can’t come in and nuke the directory unless they have root (or whatever other user you set to own /opt/wpilib) can remove things.
The SUID/SGID (User ID/Group ID) on the other hand set directories/files such that the user has a sort of elevated permissions to allow them to read/write/execute as if they were that user or group. So if SetGID was set for the wpilib group, all files created in the /opt/wpilib directory would have the group wpilib making sure everyone would still have access to them, and not just the user that created the new file.
One thing of note, I’m not certain how SUID and Sticky Bit would interact together. I’ve used each before, but never together. With SUID set to root, all new files created in the structure would be created owned by root as well, and so Sticky Bit would keep anyone but root from deleting the files, but SUID also means that the user is acting as root, so the SUID may kinda cancel out the Sticky Bit. I’d have to do more testing to validate that. From what I’m reading on the wikipedia page (which isn’t the proper documentation so I could be wrong) the Sticky Bit takes priority, so it may work out perfectly that they could create files and they’d be owned by root, but then they wouldn’t be able to delete them.