User Tools

Site Tools


doc:howto:tce

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
Next revision Both sides next revision
doc:howto:tce [2018/12/16 02:25]
stefanbaur [List of open ToDos/FIXMEs for this page] fixed MMD copysecring issue
doc:howto:tce [2019/01/06 13:01]
stefanbaur [List of open ToDos/FIXMEs for this page] added some more thoughts on how to handle encrypted portable media
Line 1165: Line 1165:
 FIXME <del>Maybe we should add symlinks to the mount points created by the automounter: Currently, we create ''/media/vendor_model_name/sdxn'' as a mount point. The idea is to allow the user to find their portable device using the vendor/model name description. However, this is unusable for scripting, as the ''//x//'' in ''sdxn'' may change any time. We should replace ''//sdx//'' with ''//partition//'' (or have corresponding symlinks created), but what should we do for //superfloppies// that only have ''sdx'' with no partition number? We could mount them as ''/media/vendor_model_name/partition/'' or directly at ''/media/vendor_model_name/''. Also, symlinks using labels and uuids, similar to ''/dev/by-*'' would be handy for scripting. Another problem: when replacing ''sdx'', what will happen when a user inserts two media with the same vendor/model name at the same time? Blindly replacing the string would make one of them inaccessible due to overwriting the symlink(s). We'd have to start checking active mounts and enumerate them like ''/media/vendor_model_name/1/partitionn'' or ''/media/vendor_model_name-1/partitionn''</del> Fixed. When a label is detected, a symlink is now created under ''/media/vendor_model_name/label'' that points to ''/media/vendor_model_name/partitionn''. FIXME <del>Maybe we should add symlinks to the mount points created by the automounter: Currently, we create ''/media/vendor_model_name/sdxn'' as a mount point. The idea is to allow the user to find their portable device using the vendor/model name description. However, this is unusable for scripting, as the ''//x//'' in ''sdxn'' may change any time. We should replace ''//sdx//'' with ''//partition//'' (or have corresponding symlinks created), but what should we do for //superfloppies// that only have ''sdx'' with no partition number? We could mount them as ''/media/vendor_model_name/partition/'' or directly at ''/media/vendor_model_name/''. Also, symlinks using labels and uuids, similar to ''/dev/by-*'' would be handy for scripting. Another problem: when replacing ''sdx'', what will happen when a user inserts two media with the same vendor/model name at the same time? Blindly replacing the string would make one of them inaccessible due to overwriting the symlink(s). We'd have to start checking active mounts and enumerate them like ''/media/vendor_model_name/1/partitionn'' or ''/media/vendor_model_name-1/partitionn''</del> Fixed. When a label is detected, a symlink is now created under ''/media/vendor_model_name/label'' that points to ''/media/vendor_model_name/partitionn''.
  
-FIXME Automount script currently expects a LUKS password in ''/etc/keys/keystick.key'' when it believes it has found an encrypted partition on USB media. This is a problem in general, as it should be trivial to sniff out this password using a rogue client. If we want to support this feature, though, we should add code to the build script that lets the user place a password file in the image, and sets proper restrictive permissions. Adding a boot parameter instead of hardcoding it would allow for dynamic password files, but on the other hand, would make it even easier to sniff out the password.+FIXME Automount script currently expects a LUKS password in ''/etc/keys/keystick.key'' when it believes it has found an encrypted partition on USB media. This is a problem in general, as it should be trivial to sniff out this password using a rogue client. If we want to support this feature, though, we should add code to the build script that lets the user place a password file in the image, and sets proper restrictive permissions (this would have to happen right before the ''lb build'' call). Adding a boot parameter instead of hardcoding it would allow for dynamic password files, but on the other hand, would make it even easier to sniff out the password. It would only really make sense for Netboot installations, and also not for a MiniDesktop in any way, because you have to block the user from accessing the TCE's local environment/files
  
 FIXME ''x2gocdmanager'' is currently not part of the image, but should become part of it. While optical media are on their way out, they still exist and thus we should support them. However, the script is hardcoded for X2Go-TCE-NFS and needs to be adapted to work with both TCEs. FIXME ''x2gocdmanager'' is currently not part of the image, but should become part of it. While optical media are on their way out, they still exist and thus we should support them. However, the script is hardcoded for X2Go-TCE-NFS and needs to be adapted to work with both TCEs.
Line 1173: Line 1173:
 FIXME Even though we set the hostname to ''localhost'' using the corresponding boot parameter, as recommended by Debian, changing the name via DHCP does not work for all image flavours. One way to fix this might be http://blog.schlomo.schapiro.org/2013/11/setting-hostname-from-dhcp-in-debian.html FIXME Even though we set the hostname to ''localhost'' using the corresponding boot parameter, as recommended by Debian, changing the name via DHCP does not work for all image flavours. One way to fix this might be http://blog.schlomo.schapiro.org/2013/11/setting-hostname-from-dhcp-in-debian.html
  
-FIXME At least when building a stretch TCE on a jessie system, you need to add kernel parameters ''net.ifnames=0 biosdevname=0'' to the image's kernel parameters, else you will receive error messages about the hostname script being unable to find eth0. This might not be necessary when building a stretch TCE on stretch. For a jessie TCE on jessie, it is not required.+FIXME <del>At least</del> when building a stretch TCE<del> on a jessie system,</del> you need to add kernel parameters ''net.ifnames=0 biosdevname=0'' to the image's kernel parameters, else you will receive error messages about the hostname script being unable to find eth0. <del>This might not be necessary when building a stretch TCE on stretch.</del> For a jessie TCE on jessie, it is not required.
  
 FIXME <del>There might be a race condition between the scripts handling the sshd keyfile and the ssh private key file copy task (/config ...), causing one to umount the fixed disk before the other is done reading/copying. What's weird is that there already is code that is supposed to keep this from happening, but it doesn't.</del> fixed in github repo, soon in x2go repo FIXME <del>There might be a race condition between the scripts handling the sshd keyfile and the ssh private key file copy task (/config ...), causing one to umount the fixed disk before the other is done reading/copying. What's weird is that there already is code that is supposed to keep this from happening, but it doesn't.</del> fixed in github repo, soon in x2go repo
doc/howto/tce.txt ยท Last modified: 2024/01/26 19:49 by stefanbaur