A page in your DokuWiki was added or changed. Here are the details: Date : 2017/11/20 12:43 Browser : Mozilla/5.0 (X11; Linux x86_64; rv:52.9) Gecko/20100101 Goanna/3.4 Firefox/52.9 PaleMoon/27.6.0 IP-Address : 134.3.37.90 Hostname : HSI-KBW-134-3-37-90.hsi14.kabel-badenwuerttemberg.de Old Revision: https://wiki.x2go.org/doku.php/doc:howto:tce?rev=1511181721 New Revision: https://wiki.x2go.org/doku.php/doc:howto:tce Edit Summary: [List of open ToDos/FIXMEs for this page] removed FIXME that has been fixed User : stefanbaur @@ -997,18 +997,8 @@ * /usr/share/x2go-tcebuilder/template-scripts (scripts we ship, with a big fat header that they should not be changed, but copied) * store the results somewhere under /var/lib/x2go-tcebuilder/ or whatever the proper place according to FHS and Debian would be * turning it into a package would mean we could add dependencies as well, so the manual apt-get install would not be neccessary * additional scripts could be added that work "automagically" if there's no PXE/TFTP/HTTP/FTP server yet - maybe in a separate package x2go-tce-setup-aids.deb which then has dependencies on atftpd and apache|lighttpd, ... - - FIXME To avoid re-generating SSH Server keys on each ThinClient on every boot, they could be stored - * in a file on a HTTP(S)/FTP/RSYNC server - * on local storage (/etc/ssh) - * a script 1155-openssh-readsshserverkeys would have to inject them before the server starts Tricky parts: - * reading to local media means you need a way to determine where to read them from (in case of "toram", look for ntfs-uuid and findiso path) - * reading from a remote server means you should use https, rsync, and/or some kind of signature check - * a script 1165-openssh-writesshserverkeys would have to save them to local media/upload them after initial generation. Tricky parts: - * saving to local media means you need a way to determine where to save them (in case of "toram", look for ntfs-uuid and findiso path) - * saving to a remote server means you need some kind of login credentials that could be abused FIXME To be checked: Does the live-config "builtin" command ''live-config.nottyautologin'' do the same as our ''nouser'' command? If yes, ''nouser'' could be removed. Note that ''live-config.nottyautologin'' **might** mean "there's a login prompt, but you just need to enter username ''user'' and password ''live'' to login" - this is not what we want. We need a solution to entirely block user logons. FIXME It would be cool if there was some kind of autodetection for SSH private keys, on local storage media and/or on USB media. -- This mail was generated by DokuWiki at https://wiki.x2go.org/