x2go-commits January 2017

x2go-commits@lists.x2go.org

3 participants
366 discussions

[[X2Go Wiki]] page changed: doc:howto:tce
by wiki-admin＠x2go.org 02 Jan '17

02 Jan '17

A page in your DokuWiki was added or changed. Here are the details: Date : 2017/01/02 12:25 Browser : Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0 IP-Address : 78.43.90.159 Hostname : HSI-KBW-078-043-090-159.hsi4.kabel-badenwuerttemberg.de Old Revision: http://wiki.x2go.org/doku.php/doc:howto:tce?rev=1483359802 New Revision: http://wiki.x2go.org/doku.php/doc:howto:tce Edit Summary: User : stefanbaur @@ -182,9 +182,9 @@ <code> cd $(mktemp -d) wget -Y off http://your-http-server-ip-here/ wget -Y off http://your-http-server-ip-here/x2go-tce/x2go-tce-filesystem.squashfs </code> - In case of an FTP URL, replace http with ftp in the example above. Same goes for https when trying to get that to work with iPXE. + In case of an FTP URL, replace http with ftp in the example above. Same goes for https when trying to get that to work. **Note that you MUST use an IP address. X2Go-TCE WILL NOT WORK with a DNS name, even though this test here will accept IPs and DNS names alike. The only exception is when a template actually spells out that you should input a DNS name.** </note> @@ -226,9 +226,9 @@ === What options are available under FURTHER-OPTIONS-GO-HERE? === These two are mutually exclusive, i.e. never put both of them in the same config: - * ''sessionsurl=http://your-http-server-ip-or-dns-here/x2go-tce/x2go-tce.sessions'' - use this to specify a sessions file. You need this unless you are using a session broker. See below for how to add this file to your HTTP, HTTPS, or FTP server. Note that whoever manages to spoof the server name can inject rogue session config files into your ThinClients. To mitigate this risk, use HTTPS, where the attacker would have to spoof both server name and matching certificate. + * ''sessionsurl=https|http|ftp://your-http-server-ip-or-dns-here/x2go-tce/x2go-tce.sessions'' - use this to specify a sessions file. You need this unless you are using a session broker. See below for how to add this file to your HTTP, HTTPS, or FTP server. Note that whoever manages to spoof the server name can inject rogue session config files into your ThinClients. To mitigate this risk, use HTTPS, where the attacker would have to spoof both server name and matching certificate. * ''broker-url=ssh:<nowiki>//</nowiki>your-broker-address-here'' - this allows you to specify an X2Go Session Broker instead of a sessions file (not limited to an ssh-based broker, works with an http-based broker as well) These are entirely optional: * ''xorg-resolution=HRESxVRES'' - will force the horizontal resolution to HRES and the vertical resolution to VRES, e.g. ''xorg-resolution=1280x1024'', useful if autodetection for the correct screen size fails, but you do get as far as seeing the X2Go GUI -- This mail was generated by DokuWiki at http://wiki.x2go.org/

1 0

[[X2Go Wiki]] page changed: doc:howto:tce
by wiki-admin＠x2go.org 02 Jan '17

02 Jan '17

A page in your DokuWiki was added or changed. Here are the details: Date : 2017/01/02 12:23 Browser : Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0 IP-Address : 78.43.90.159 Hostname : HSI-KBW-078-043-090-159.hsi4.kabel-badenwuerttemberg.de Old Revision: http://wiki.x2go.org/doku.php/doc:howto:tce?rev=1483358971 New Revision: http://wiki.x2go.org/doku.php/doc:howto:tce Edit Summary: User : stefanbaur @@ -7,9 +7,9 @@ During the time of Debian Wheezy being Debian's stable release, we started developing a new ThinClientEdition (TCE) - one that is based on Debian-Live and thus does no longer rely on NFS. Instead, the entire image is loaded into the RAM of the ThinClient machine. The disadvantage is that your ThinClient now needs at least 1 GB of RAM (see below). - However, the huge advantage is that there no longer is a need for any high-availibility setup concerning NFS. All you need is an HTTP or FTP server with a dedicated IP, if you want to use netbooting. It is also possible to deploy the image to the ThinClient's local storage, if present, and have it update in the background. Besides, making changes/updating the NFS-based TCE was rather finicky - with the current TCE, you build and deploy a new image every time you make a change, and you can test it on a single client without interrupting your production environment. The "local storage" feature can also be used to create a portable version of both X2Go-TCE and X2goClient for Windows, sharing the same configuration, on CD/DVD/USB media. + However, the huge advantage is that there no longer is a need for any high-availibility setup concerning NFS. All you need is an HTTP (HTTPS optional for later stages) or FTP server with a dedicated IP, if you want to use netbooting. It is also possible to deploy the image to the ThinClient's local storage, if present, and have it update in the background. Besides, making changes/updating the NFS-based TCE was rather finicky - with the current TCE, you build and deploy a new image every time you make a change, and you can test it on a single client without interrupting your production environment. The "local storage" feature can also be used to create a portable version of both X2Go-TCE and X2goClient for Windows, sharing the same configuration, on CD/DVD/USB media. We've also received reports that the old NFS-based TCE wouldn't work with Jessie, or at least it was very hard to get it to work. Our current TCE works just fine with Jessie, and we expect it to work in Stretch and hopefully in Buster (Stretch+1) as well. The one catch is that the live-build package in Debian/the Debian-Live project is currently looking for a new maintainer - so there is a slim chance that live-build might be removed from Debian Buster, especially if no new maintainer steps up and the live-build replacement that is currently in the works (called live-wrapper) contains all the required functionality of live-build by then. @@ -144,18 +144,22 @@ ===== Netbooting ===== ==== Prerequisites ==== * You need an existing DHCP/PXE/TFTP setup with the usual pxelinux.0/pxelinux.cfg boot and configuration files, and a directory where kernel and initrd can be stored. This is not covered here, though we might add a separate howto for that some time later on. - * You will also need an HTTP/FTP server with a dedicated IP (no name-based virtual hosts) for the squashfs image. + * Note that whoever manages to spoof this server name can deploy rogue images to your ThinClients. If this is a serious issue for you, consider using local storage media and the autoupdater instead. + * It **might** be possible to already use HTTPS in this early stage when using iPXE. This is untested. + * You will also need an HTTP/HTTPS/FTP server with a dedicated IP (no name-based virtual hosts) for the squashfs image. * This image cannot be deployed via TFTP as it is too large - some TFTP servers refuse to serve files lager than 32MB, and some TFTP clients have problems with that as well. * Also, even if you have a TFTP server/client combination that handles files larger than 32 MB, it will still be waaaay slower than the HTTP/FTP transfer. + * Note that whoever manages to spoof this server name can deploy rogue images to your ThinClients. If this is a serious issue for you, consider using local storage media and the autoupdater instead. + * It **might** be possible to use HTTPS with the ''fetch='' command. This is untested. * Once your setup fulfills all the requirements listed above, go ahead and build the image using the scripts listed in [[doc:howto:tce#build_system_prerequisites_for_all_variants|Build system prerequisites for all variants]] - make sure to choose ''export LBX2GO_IMAGETYPE='netboot''' (this should be the default) ==== Setting up your own netbootable X2Go-TCE environment ==== === Adding the X2Go-TCE files to your Boot and Web Server(s) === - This is assuming you already have an existing, working PXE/TFTP and HTTP or FTP server setup. + This is assuming you already have an existing, working PXE/TFTP and HTTP (with optional HTTPS) or FTP server setup. Once you see the message "Build is done:", go to the directory mentioned there, and copy x2go-tce-vmlinuz and x2go-tce-initrd.img to a suitable subdirectory under your TFTP root. We suggest using ./x2go-tce. @@ -169,18 +173,18 @@ tftp> quit </code> </note> - Next, copy x2go-tce-filesystem.squashfs from the directory mentioned after "Build is done:" to a suitable subdirectory under your HTTP or FTP root. + Next, copy x2go-tce-filesystem.squashfs from the directory mentioned after "Build is done:" to a suitable subdirectory under your HTTP, HTTPS, or FTP root. We suggest using ./x2go-tce. - <note tip>To verify that both your installation in general and the newly copied file are reachable via HTTP or FTP, use an HTTP/FTP client - we suggest wget - and perform these steps: + <note tip>To verify that both your installation in general and the newly copied file are reachable via HTTP, HTTPS, or FTP, use an HTTP/HTTPS/FTP client - we suggest wget - and perform these steps: <code> cd $(mktemp -d) wget -Y off http://your-http-server-ip-here/ wget -Y off http://your-http-server-ip-here/x2go-tce/x2go-tce-filesystem.squashfs </code> - In case of an FTP URL, replace http with ftp in the example above. + In case of an FTP URL, replace http with ftp in the example above. Same goes for https when trying to get that to work with iPXE. **Note that you MUST use an IP address. X2Go-TCE WILL NOT WORK with a DNS name, even though this test here will accept IPs and DNS names alike. The only exception is when a template actually spells out that you should input a DNS name.** </note> @@ -188,9 +192,9 @@ Again, this is assuming you already have an existing, working PXE/TFTP server setup. * Change to the pxelinux.cfg directory in your tftproot. * create a file x2go-tce there, using the template below and adjusting it to your needs * options ending in "=de" and "=de_DE.UTF-8" should be set to match your desired country/locale setting - * options containing "http://your-http-server-ip-here" should be replaced with the proper HTTP or FTP URL for your server + * options containing "http://your-http-server-ip-here" should be replaced with the proper HTTP, HTTPS, FTP, or, where mentioned as an alternative, rsync URL for your server * where it says FURTHER-OPTIONS-GO-HERE, you can (must!) add one or more of the options explained below. All options are separated from the next option using a single blank (space bar), just like the options before that placeholder. **DO NOT** use newlines. All "APPEND" options must be on **one and the same** line. <note tip>To have different hostnames for each thin client: * assign DNS names for your thin clients @@ -222,14 +226,14 @@ === What options are available under FURTHER-OPTIONS-GO-HERE? === These two are mutually exclusive, i.e. never put both of them in the same config: - * ''sessionsurl=http://your-http-server-ip-or-dns-here/x2go-tce/x2go-tce.sessions'' - use this to specify a sessions file. You need this unless you are using a session broker. See below for how to add this file to your HTTP or FTP server. + * ''sessionsurl=http://your-http-server-ip-or-dns-here/x2go-tce/x2go-tce.sessions'' - use this to specify a sessions file. You need this unless you are using a session broker. See below for how to add this file to your HTTP, HTTPS, or FTP server. Note that whoever manages to spoof the server name can inject rogue session config files into your ThinClients. To mitigate this risk, use HTTPS, where the attacker would have to spoof both server name and matching certificate. * ''broker-url=ssh:<nowiki>//</nowiki>your-broker-address-here'' - this allows you to specify an X2Go Session Broker instead of a sessions file (not limited to an ssh-based broker, works with an http-based broker as well) These are entirely optional: * ''xorg-resolution=HRESxVRES'' - will force the horizontal resolution to HRES and the vertical resolution to VRES, e.g. ''xorg-resolution=1280x1024'', useful if autodetection for the correct screen size fails, but you do get as far as seeing the X2Go GUI - * ''xorgconfurl=tftp|http|https|ftp://your-http-server-ip-here/x2go-tce/x2go-tce.xorg.conf'' - when a client outright refuses to boot into the graphical X2Go login screen, but gets stuck at the console or a black screen instead, yet you can get the GUI to work using a regular Linux on the same hardware, you can disable the X Server's autodetection and force it to use the xorg.conf specified here. Note that you should use a more descriptive name for the file, as described below. + * ''xorgconfurl=tftp|http|https|ftp://your-http-server-ip-here/x2go-tce/x2go-tce.xorg.conf'' - when a client outright refuses to boot into the graphical X2Go login screen, but gets stuck at the console or a black screen instead, yet you can get the GUI to work using a regular Linux on the same hardware, you can disable the X Server's autodetection and force it to use the xorg.conf specified here. Note that you should use a more descriptive name for the file, as described below. Also note that whoever manages to spoof the server name can inject rogue xorg config files into your ThinClients. To mitigate this risk, use HTTPS, where the attacker would have to spoof both server name and matching certificate. * ''pubkey=tftp|http|https|ftp://your-http-server-ip-or-dns-here/x2go-tce/x2go-tce.authorized_keys'' - Allows you to add an ssh public key file to the ThinClient, so your administrators can log in remotely using SSH. Note that this file needs to be chmodded 644, not 600, on the web server. **Attention: Whoever manages to spoof this server name will have root access to your ThinClients. Using HTTPS will mitigate this - an attacker would not only have to spoof the server name, but also the matching certificate.** * ''xinerama=left-of|right-of|above|below|same-as'' - Allows you to specify how multiple screens are handled (same-as clones the primary screen to all secondary screens, the other commands will cascade and thus expand the screen). Note that the current implementation will enforce "same-as" if it detects a touch screen driver (wacom) and no other pointing device. This is so you won't get stuck being unable to log off, for example, due to your touch device being limited to one screen. * ''ldap=ldap.example.com:389:cn=cngoeshere,dc=example,dc=com'' - this allows you to specify an LDAP server to authenticate against * ''ldap1=ldap-backupserver-1.example.com:389'' - this allows you to specify the first of up to two LDAP backup servers when using LDAP authentication @@ -241,9 +245,9 @@ * ''tcpprint'' - Will allow you to use local LPT/USB printers like "dumb" network printers (listening to port 9100 and above). Requires MAC->IP mapping in DHCP server (and optionally, DNS->IP mapping), or static IPs - else your print jobs will end up on random devices. This setup is preferred over the X2GoClient's built-in printing for locally attached printers if X2GoServer and ThinClients are on the same network. It is not recommended when your X2Go connection goes across the internet or when the ThinClient is actually a laptop roaming between different networks. * ''tcpprintonlyfrom=x.x.x.x'' - Will allow you to specify which IP address may connect to Port 9100 and above for printing to a locally attached LPT/USB printer. This should be the IP of your CUPS server or whatever print server system you use. Understands the same syntax as xinetd's ''only_from''. These are //not yet implemented//, but planned for a future release, and only intended to be used with TCE images stored on local media: - * ''updateurl=rsync|http|ftp://your-http-server-ip-or-dns-here/path-to-update-files'' - Will allow you to update an image in the background when using local storage instead of PXE. Download task will start at a randomized interval to avoid unintentional dDOSing of the update server/network infrastructure. The updater will even work when using NTFS for local storage, but only if the //toram// boot option is used. Regardless of NTFS or not, the updater requires three directories: ''/boot/live1, /boot/live2, /boot/live-download'' + * ''updateurl=rsync|https|http|ftp://your-http-server-ip-or-dns-here/path-to-update-files'' - Will allow you to update an image in the background when using local storage instead of PXE. Download task will start at a randomized interval to avoid unintentional dDOSing of the update server/network infrastructure. The updater will even work when using NTFS for local storage, but only if the //toram// boot option is used. Regardless of NTFS or not, the updater requires three directories: ''/boot/live1, /boot/live2, /boot/live-download'' **Attention:** Whoever manages to spoof the server name can deploy rogue images to your ThinClients. Even though it is slower, using an HTTPS web server is the safer way of doing this. Be sure that your web server delivers a last-modified header for all files. * ''updatesleep=nnnnn'' - Will allow you to specify the upper limit (in seconds) of the update timer's randomizer. Allowed range: 121-32767. Will default to 900 if unset or set to an out-of-range value. * ''bwlimit=nnn'' - Will allow you to specify a bandwidth limit (valid values: 1-100) in percent for the backgrounded update task. * ''ntfs-uuid='' - Will be required for updating images stored on NTFS filesystems. Full UUID as shown under /dev/disk/by-uuid/ is preferred, but can work with the volume serial number shown in the output of "vol c:" as well. @@ -563,9 +567,9 @@ hosts allow = 192.168.0.0/255.255.0.0 # change this to your local subnet(s) </file> * after you have prepared all this, execute ''service rsync start'' - * Note that whoever manages to spoof the server name can inject rogue images to your ThinClients. Even though it is slower, using an HTTPS web server is the safer way of doing this. Be sure that your web server delivers a last-modified header for all files. + * Note that whoever manages to spoof the server name can deploy rogue images to your ThinClients. Even though it is slower, using an HTTPS web server is the safer way of doing this. Be sure that your web server delivers a last-modified header for all files. FIXME Some of the optional steps above could be moved to a separate subpage to reduce clutter. FIXME The steps for the build process could probably streamlined into an x2go-tcebuilder.deb Debian package -- This mail was generated by DokuWiki at http://wiki.x2go.org/

1 0

[[X2Go Wiki]] page changed: doc:howto:tce
by wiki-admin＠x2go.org 02 Jan '17

02 Jan '17

A page in your DokuWiki was added or changed. Here are the details: Date : 2017/01/02 12:09 Browser : Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0 IP-Address : 78.43.90.159 Hostname : HSI-KBW-078-043-090-159.hsi4.kabel-badenwuerttemberg.de Old Revision: http://wiki.x2go.org/doku.php/doc:howto:tce?rev=1483358777 New Revision: http://wiki.x2go.org/doku.php/doc:howto:tce Edit Summary: [List of open ToDos/FIXMEs for this page] User : stefanbaur @@ -563,8 +563,9 @@ hosts allow = 192.168.0.0/255.255.0.0 # change this to your local subnet(s) </file> * after you have prepared all this, execute ''service rsync start'' + * Note that whoever manages to spoof the server name can inject rogue images to your ThinClients. Even though it is slower, using an HTTPS web server is the safer way of doing this. Be sure that your web server delivers a last-modified header for all files. FIXME Some of the optional steps above could be moved to a separate subpage to reduce clutter. FIXME The steps for the build process could probably streamlined into an x2go-tcebuilder.deb Debian package -- This mail was generated by DokuWiki at http://wiki.x2go.org/

1 0

[[X2Go Wiki]] page changed: doc:howto:tce
by wiki-admin＠x2go.org 02 Jan '17

02 Jan '17

A page in your DokuWiki was added or changed. Here are the details: Date : 2017/01/02 12:06 Browser : Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0 IP-Address : 78.43.90.159 Hostname : HSI-KBW-078-043-090-159.hsi4.kabel-badenwuerttemberg.de Old Revision: http://wiki.x2go.org/doku.php/doc:howto:tce?rev=1483358261 New Revision: http://wiki.x2go.org/doku.php/doc:howto:tce Edit Summary: [Setting up your own netbootable X2Go-TCE environment] User : stefanbaur @@ -227,10 +227,10 @@ * ''broker-url=ssh:<nowiki>//</nowiki>your-broker-address-here'' - this allows you to specify an X2Go Session Broker instead of a sessions file (not limited to an ssh-based broker, works with an http-based broker as well) These are entirely optional: * ''xorg-resolution=HRESxVRES'' - will force the horizontal resolution to HRES and the vertical resolution to VRES, e.g. ''xorg-resolution=1280x1024'', useful if autodetection for the correct screen size fails, but you do get as far as seeing the X2Go GUI - * ''xorgconfurl=http://your-http-server-ip-here/x2go-tce/x2go-tce.xorg.conf'' - when a client outright refuses to boot into the graphical X2Go login screen, but gets stuck at the console or a black screen instead, yet you can get the GUI to work using a regular Linux on the same hardware, you can disable the X Server's autodetection and force it to use the xorg.conf specified here. Note that you should use a more descriptive name for the file, as described below. - * ''pubkey=tftp|http|ftp://your-http-server-ip-or-dns-here/x2go-tce/x2go-tce.authorized_keys'' - Allows you to add an ssh public key file to the ThinClient, so your administrators can log in remotely using SSH. Note that this file needs to be chmodded 644, not 600, on the web server. + * ''xorgconfurl=tftp|http|https|ftp://your-http-server-ip-here/x2go-tce/x2go-tce.xorg.conf'' - when a client outright refuses to boot into the graphical X2Go login screen, but gets stuck at the console or a black screen instead, yet you can get the GUI to work using a regular Linux on the same hardware, you can disable the X Server's autodetection and force it to use the xorg.conf specified here. Note that you should use a more descriptive name for the file, as described below. + * ''pubkey=tftp|http|https|ftp://your-http-server-ip-or-dns-here/x2go-tce/x2go-tce.authorized_keys'' - Allows you to add an ssh public key file to the ThinClient, so your administrators can log in remotely using SSH. Note that this file needs to be chmodded 644, not 600, on the web server. **Attention: Whoever manages to spoof this server name will have root access to your ThinClients. Using HTTPS will mitigate this - an attacker would not only have to spoof the server name, but also the matching certificate.** * ''xinerama=left-of|right-of|above|below|same-as'' - Allows you to specify how multiple screens are handled (same-as clones the primary screen to all secondary screens, the other commands will cascade and thus expand the screen). Note that the current implementation will enforce "same-as" if it detects a touch screen driver (wacom) and no other pointing device. This is so you won't get stuck being unable to log off, for example, due to your touch device being limited to one screen. * ''ldap=ldap.example.com:389:cn=cngoeshere,dc=example,dc=com'' - this allows you to specify an LDAP server to authenticate against * ''ldap1=ldap-backupserver-1.example.com:389'' - this allows you to specify the first of up to two LDAP backup servers when using LDAP authentication * ''ldap2=ldap-backupserver-2.example.com:389'' - this allows you to specify the second of up to two LDAP backup servers when using LDAP authentication -- This mail was generated by DokuWiki at http://wiki.x2go.org/

1 0

[[X2Go Wiki]] page changed: doc:howto:tce
by wiki-admin＠x2go.org 02 Jan '17

02 Jan '17

A page in your DokuWiki was added or changed. Here are the details: Date : 2017/01/02 11:57 Browser : Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0 IP-Address : 78.43.90.159 Hostname : HSI-KBW-078-043-090-159.hsi4.kabel-badenwuerttemberg.de Old Revision: http://wiki.x2go.org/doku.php/doc:howto:tce?rev=1483353986 New Revision: http://wiki.x2go.org/doku.php/doc:howto:tce Edit Summary: [List of open ToDos/FIXMEs for this page] User : stefanbaur @@ -583,11 +583,13 @@ 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 + * 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 + * 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. -- This mail was generated by DokuWiki at http://wiki.x2go.org/

1 0

[[X2Go Wiki]] page changed: doc:howto:tce
by wiki-admin＠x2go.org 02 Jan '17

02 Jan '17

A page in your DokuWiki was added or changed. Here are the details: Date : 2017/01/02 10:46 Browser : Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0 IP-Address : 78.43.90.159 Hostname : HSI-KBW-078-043-090-159.hsi4.kabel-badenwuerttemberg.de Old Revision: http://wiki.x2go.org/doku.php/doc:howto:tce?rev=1483353699 New Revision: http://wiki.x2go.org/doku.php/doc:howto:tce Edit Summary: [List of open ToDos/FIXMEs for this page] User : stefanbaur @@ -589,4 +589,12 @@ * saving to local media means you need a way to determine where to save them * 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. + For USB media, this may require adding an automounter. + * Stefan once wrote a script 2500-x2go-keychange for this, but it only handles local storage media, also, it needs to be adapted to the current TCE. + * 1150-openssh-readsshprivatekeys or 1150-x2go-readsshprivatekeys would probably be the proper names + * Maybe it would be better to split the process into 2 scripts, one that fetches the keys from local storage/USB media, and one that patches the sessions file + * 2800-x2go-thinclientconfig would also have to be changed so it uses the keyfile(s) when in broker mode + -- This mail was generated by DokuWiki at http://wiki.x2go.org/

1 0

[[X2Go Wiki]] page changed: doc:howto:tce
by wiki-admin＠x2go.org 02 Jan '17

02 Jan '17

A page in your DokuWiki was added or changed. Here are the details: Date : 2017/01/02 10:41 Browser : Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0 IP-Address : 78.43.90.159 Hostname : HSI-KBW-078-043-090-159.hsi4.kabel-badenwuerttemberg.de Old Revision: http://wiki.x2go.org/doku.php/doc:howto:tce?rev=1483353457 New Revision: http://wiki.x2go.org/doku.php/doc:howto:tce Edit Summary: [List of open ToDos/FIXMEs for this page] User : stefanbaur @@ -588,5 +588,5 @@ * 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 * 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. -- This mail was generated by DokuWiki at http://wiki.x2go.org/

1 0

[[X2Go Wiki]] page changed: doc:howto:tce
by wiki-admin＠x2go.org 02 Jan '17

02 Jan '17

A page in your DokuWiki was added or changed. Here are the details: Date : 2017/01/02 10:37 Browser : Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0 IP-Address : 78.43.90.159 Hostname : HSI-KBW-078-043-090-159.hsi4.kabel-badenwuerttemberg.de Old Revision: http://wiki.x2go.org/doku.php/doc:howto:tce?rev=1483353090 New Revision: http://wiki.x2go.org/doku.php/doc:howto:tce Edit Summary: [List of open ToDos/FIXMEs for this page] User : stefanbaur @@ -579,5 +579,14 @@ * /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 + * 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 + * saving to a remote server means you need some kind of login credentials that could be abused + -- This mail was generated by DokuWiki at http://wiki.x2go.org/

1 0

[[X2Go Wiki]] page changed: doc:howto:tce
by wiki-admin＠x2go.org 02 Jan '17

02 Jan '17

A page in your DokuWiki was added or changed. Here are the details: Date : 2017/01/02 10:31 Browser : Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0 IP-Address : 78.43.90.159 Hostname : HSI-KBW-078-043-090-159.hsi4.kabel-badenwuerttemberg.de Old Revision: http://wiki.x2go.org/doku.php/doc:howto:tce?rev=1483353031 New Revision: http://wiki.x2go.org/doku.php/doc:howto:tce Edit Summary: [ThinClient prerequisites for all variants] User : stefanbaur @@ -14,9 +14,9 @@ Our current TCE works just fine with Jessie, and we expect it to work in Stretch and hopefully in Buster (Stretch+1) as well. The one catch is that the live-build package in Debian/the Debian-Live project is currently looking for a new maintainer - so there is a slim chance that live-build might be removed from Debian Buster, especially if no new maintainer steps up and the live-build replacement that is currently in the works (called live-wrapper) contains all the required functionality of live-build by then. ===== ThinClient prerequisites for all variants ===== - * At least 1 GB of RAM + * At least 1 GB of RAM UNLESS you use non-NTFS local storage, in that case, 512MB or even 256MB might work * At least an i586-compatible CPU * Capability to boot via PXE //or// sufficient local storage (expect 250-450 MB, depending on what you decide to include) * A graphics card and input devices (Keyboard, Mouse/Trackball/Touchpad/Trackpoint/Touchscreen, ...) that are supported by the stock Debian X Server ===== Build system prerequisites for all variants ===== -- This mail was generated by DokuWiki at http://wiki.x2go.org/

1 0

[[X2Go Wiki]] page changed: doc:howto:tce
by wiki-admin＠x2go.org 02 Jan '17

02 Jan '17

A page in your DokuWiki was added or changed. Here are the details: Date : 2017/01/02 10:30 Browser : Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0 IP-Address : 78.43.90.159 Hostname : HSI-KBW-078-043-090-159.hsi4.kabel-badenwuerttemberg.de Old Revision: http://wiki.x2go.org/doku.php/doc:howto:tce?rev=1483350070 New Revision: http://wiki.x2go.org/doku.php/doc:howto:tce Edit Summary: [History, Rationale, Outlook] User : stefanbaur @@ -7,13 +7,13 @@ During the time of Debian Wheezy being Debian's stable release, we started developing a new ThinClientEdition (TCE) - one that is based on Debian-Live and thus does no longer rely on NFS. Instead, the entire image is loaded into the RAM of the ThinClient machine. The disadvantage is that your ThinClient now needs at least 1 GB of RAM (see below). - However, the huge advantage is that there no longer is a need for any high-availibility setup concerning NFS. All you need is an HTTP or FTP server with a dedicated IP, if you want to use netbooting. It is also possible to deploy the image to the ThinClient's local storage, if present, and have it update in the background. Also, making changes/updating the NFS-based TCE was rather finicky - with the current TCE, you build and deploy a new image every time you make a change, and you can test it on a single client without interrupting your production environment. + However, the huge advantage is that there no longer is a need for any high-availibility setup concerning NFS. All you need is an HTTP or FTP server with a dedicated IP, if you want to use netbooting. It is also possible to deploy the image to the ThinClient's local storage, if present, and have it update in the background. Besides, making changes/updating the NFS-based TCE was rather finicky - with the current TCE, you build and deploy a new image every time you make a change, and you can test it on a single client without interrupting your production environment. The "local storage" feature can also be used to create a portable version of both X2Go-TCE and X2goClient for Windows, sharing the same configuration, on CD/DVD/USB media. We've also received reports that the old NFS-based TCE wouldn't work with Jessie, or at least it was very hard to get it to work. Our current TCE works just fine with Jessie, and we expect it to work in Stretch and hopefully in Buster (Stretch+1) as well. - The one catch is that the live-build package in Debian/the Debian-Live project is currently looking for a new maintainer - so there is a slim chance that live-build might be removed from Debian Buster, especially if no new maintainer steps up and the live-build replacement that is currently in the works contains all the required functionality of live-build by then. + The one catch is that the live-build package in Debian/the Debian-Live project is currently looking for a new maintainer - so there is a slim chance that live-build might be removed from Debian Buster, especially if no new maintainer steps up and the live-build replacement that is currently in the works (called live-wrapper) contains all the required functionality of live-build by then. ===== ThinClient prerequisites for all variants ===== * At least 1 GB of RAM * At least an i586-compatible CPU -- This mail was generated by DokuWiki at http://wiki.x2go.org/

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

x2go-commits January 2017