In this situation, we need at least 2 servers (see figure 1). One Linux server for LTSP and one W2K3 server for TSE.
Users who use Linux sessions will simply receive display on their workstations from the Linux server with XDMCP. They authenticate through basic Unix authentication and access to their home directories as if they are sitting in front of the Linux server.
Users who use Windows sessions will receive display from the Windows server using the RDP protocol. To be able to authenticate using the same identifiers as with Linux sessions, the TSE server will be configured as a member of a Windows domain whose controller is the Linux server by use of SAMBA. Then, users will access to their home directories by means of samba shares.
Install K12LTSP. If you have enough disk space then make a full install.
![[Caution]](./stylesheet-images/caution.png)
Caution If you have many network cards then be sure that eth0 is the interface on your internal network. Also pay attention to the firewall rules otherwise the network services will not be available to workstations (leaving SELinux activated and enabling the firewall with eth0 configured as a trusted device will be fine).
Install GPG keys
# rpm --import /usr/share/rhn/RPM-GPG-KEY # rpm --import /usr/share/rhn/RPM-GPG-KEY-fedora # rpm --import /usr/share/doc/k12ltsp/K12LTSP-GPG-KEY
Apply updates if any
# yum -y update
![[Tip]](./stylesheet-images/tip.png)
Tip If you want your server to be updated automatically then activate nightly updates by issuing the following commands:
# chkconfig yum on # service yum start
Initialize LTSP with the following command, it issues a bunch of settings and configures some services including dhcpd, named, nfs, and tftp
# /opt/ltsp/templates/k12linux/K12Linux-LTSP-initialize
Reboot
# reboot
To see if the default installation of LTSP is ok, you just have to power on a workstation (already configured to boot with PXE) and you will see the LTSP login screen. Below some explanations about all what you see on the workstation's screen:
The workstation sends a broadcast to find a DHCP server
The DHCP server responds by sending some network information (including an IP address taken from a range of IP addresses, a netmask, and so on) and the name of a file to load (in /etc/dhcpd.conf you can see that this file is /tftpboot/lts/pxe/pxelinux.0).
The workstation initializes its network using the information received, loads the file by using tftp and executes it. This binary looks in /tftpboot/lts/pxe/pxelinux.cfg/ for a configuration file which name matches the MAC address or the whole or part of the hex representation of the IP address of the workstation otherwise it uses the default configuration file (/tftpboot/lts/pxe/pxelinux.cfg/default)
The default configuration file tells pxelinux.0 to load a kernel (vmlinuz.ltsp) and a ramdisk (initrd.ltsp). They are stored under /tftpboot/lts/pxe/. The kernel is compiled with some specific options needed by LTSP such as devfs, and the ramdisk is a compressed ext2 file system containing essentially some network cards modules and a text file with PCI IDs of the network cards and the corresponding modules to be loaded by the kernel.
The system probes for a network card, loads the corresponding module, issues a new DHCP request, mounts some directories using NFS (see /etc/exports on the server), builds an X config file using the setting in /opt/ltsp/i386/etc/lts.conf or the defaults otherwise (3 buttons mouse, US keyboard, screen resolution of 1024x768, and color depth of 16), starts X, and establishes an XDMCP connection with the server.
![[Note]](./stylesheet-images/note.png) | Note |
|---|---|
The problems arise when your network card and/or your video card are not detected by LTSP (see Tips, tricks and tweakings for some hints). | |
The file /opt/ltsp/i386/etc/lts.conf is very important because it must reflect your hardware on the workstations. It's like a .ini file and each section corresponds to a workstation (refer to the LTSP documentation for more details). Here's an example for a workstation with a french keyboard, a PS/2 wheel mouse, a screen resolution of 1280x1024, and a color depth of 24. Usually the label of the section is the name of the workstation but you can use the IP address or the MAC address instead:
[workstation_name] # french keyboard XkbSymbols = "fr(pc105)" XkbModel = "pc105" XkbLayout = "fr" # wheel mouse X_MOUSE_PROTOCOL = "PS/2" X_MOUSE_DEVICE = "/dev/psaux" X_MOUSE_RESOLUTION = 400 X_MOUSE_BUTTONS = 3 X_ZAxisMapping = "4 5" # resolution X_COLOR_DEPTH = 24 X_MODE_0 = 1280x1024 # start an X session SCREEN_01 = startx
![[Warning]](./stylesheet-images/warning.png)
Warning By default, in LTSP the DHCP server is configured to assign a range of IP addresses to workstations. This means that a workstation may have different IP addresses (hence different names) across reboots. You must use reservations in DHCP to be sure that a workstation always gets the same name and IP address. In /etc/dhcpd.conf
Comment the line beginning with the keyword range
Add the lines below for each workstation (see examples in /etc/dhcpd.conf) and restart dhcpd
host workstation_name { hardware ethernet MAC_address; fixed-address IP_address; }
Create a user account on the LTSP server and try to login on the workstation. You will be in !
# useradd tsuser # passwd tsuser
Install W2K3 (for the purpose of this document, we have used an evaluation kit)
Run Windows updates (this is the first thing you have to do. Also install an antivirus and get the latest virus definitions)
Tip You can configure Automatic Updates in Windows Server 2003 using the steps outlined below:
Open the System applet by clicking Start, pointing to Control Panel, and clicking System.
Click the Automatic Updates tab from within the System Properties window.
If automatic update is not enabled, click the option "Keep my computer up-to-date".
Under the Settings section, select the option "Automatically download the updates, and install them on the schedule I specify".
Using the arrows beside the drop down box, select the day and time.
Install the Terminal Server by clicking on Start -> Administrative Tools -> Manage Your Server
"Add or remove a role" and click "Next"
Select "Custom configuration" and click "Next"
Select "Terminal server" and click "Next"
Click on "Next" to begin the installation of terminal services. If the wizard asks you to close any open programs, do so and click on "OK"
After the reboot, the wizard warns you that it stops accepting connections from unlicenced clients 120 days after the Terminal Server installation. In fact, each client needs a tscal to be able to connect to the terminal server after this period of time. You need to install a licence server and purchase some tscals. Click on "Finish".
Now we must configure things such that workstations can get a Windows login screen together with a Linux login screen.
In /opt/ltsp/i386/etc/lts.conf add the following lines in the section defining the characteristics of the workstation:
[workstation_name] ... # start a Windows session with rdesktop in full screen mode using a french keyboard SCREEN_02 = rdesktop RDP_SERVER = name_or_IP_of_TSE_server RDP_OPTIONS = -f -k fr
Reboot the workstation and just press CTRL+Alt+F2 to have a Windows login screen. If you want to go back to the Linux login screen then press CTRL+Alt+F1. That's it!
Caution Due to incomplete configure parameters in the building process of rdesktop in LBE (the LTSP Build Environment), the keyboard doesn't map correctly. This problem was reported here. The solution consists of rebuilding rdesktop in LBE with the correct options. Since I do it, you must just replace your /opt/ltsp/i386/usr/bin/rdesktop binary with http://math.univ-lille1.fr/~hafidi/terminal-services/rdesktop and make sure that it is executable.
Now we must configure TSE for user authentication and access to the homedirs
On the LTSP server:
Create a Unix group for the TSE computer account
# groupadd -g 1000 winmachines
Be sure that the following entries exist in your /etc/samba/smb.conf to make the LTSP server a domain controller for the domain EXAMPLE with SAMBA
[global] workgroup = EXAMPLE netbios name = K12LTSP domain logons = yes domain master = yes os level = 99 preferred master = yes add machine script = /usr/sbin/useradd -d /dev/null -g winmachines -s /bin/false -M %u logon drive = H: [homes] create mask = 0600 directory mask = 0700 path = %H read only = no valid users = %S [netlogon] path = /home/netlogon guest ok = yes writable = no share modes = no
Create the netlogon directory
# mkdir /home/netlogon
Check the correctness of the /etc/samba/smb.conf file
# testparm -s # testparm -sv
Create a SAMBA root account which will be granted administrative privilieges such as joining computers to the domain. Make sure to use a different password than the Unix root account.
# smbpasswd -a root
Start SAMBA
# chkconfig smb on # service smb start
If you want a Unix user to be able to connect using a Windows session, you have to add a samba account for that user
# smbpasswd -a tsuser
On the TSE server:
Click on Start -> Control Panel -> System.
Click the "Computer Name" tab and then on the "Change..." button
In "Member of", select "Domain" and type the domain name (EXAMPLE) then "OK"
You will be asked to enter the name and the password of an account with permission to join the domain. Use the samba root account you added earlier and click on "OK". The message "Welcome to the EXAMPLE domain" is then displayed.
Restart your computer.
If you try to connect from a workstation using a Windows login screen (before connecting, click on the "Options>>" button to check if you log on the domain not the local computer), you will have the following message: "The local policy of this system does not permit you to login interactively". This is because W2K3 TSE, in contrast of W2K TSE, allows only the administrators and the members of the group "Remote Desktop Users" to login interactively. Here's the procedure to add a user in this group:
Start -> Administrative Tools -> Computer Management
In "System Tools", expand "Local Users and Groups" and click on "Groups"
Right click on "Remote Desktop Users" and click on "Properties"
Click on the "Add..." button then on the "Advanced..." button. Click on "Find Now", enter the samba root password to see all samba users and groups.
Select the user you want to add and click on "OK"
Tip If you want new created users automatically have permission to logon then use Windows and Unix group mapping:
On the LTSP server:
Create a Unix group
# groupadd tsusers
Map it to the Windows group "Domain Users"
# net groupmap modify ntgroup="Domain Users" unixgroup=tsusers
Check if the mapping is correct
# net groupmap list
On the TSE server:
Add the group "Domain Users" to the group "Remote Desktop Users"
To create a new user just issue the following commands and the new user will be immediatly able to connect to both Linux and Windows
# useradd -G tsusers newtsuser # smbpasswd -a newtsuser # passwd newtsuser
Caution Make sure that you select the domain (EXAMPLE) and not the local computer when you log on. If you want this to be the default behavior then add the -d option to RDP_OPTIONS in /opt/ltsp/i386/etc/lts.conf
[workstation_name] ... RDP_OPTIONS = -f -k fr -d EXAMPLE
If you'd like to enable roaming profiles, then:
Make the following changes to your /etc/samba/smb.conf file
[global] logon path = \\%L\Profiles\%U [Profiles] path = /home/profiles read only = no create mask = 0600 directory mask = 0700
Create the /home/profiles dir and restart smb
# mkdir /home/profiles # chmod a+rxwt /home/profiles # service smb restart
Warning If you want to use mandatory profiles, just rename the file NTUSER.DAT to NTUSER.MAN in the user's profile dir. The problem is that a user can login using a Linux session and rename again the file or even delete his whole profile dir. If you only make a profile dir read only then this will NOT work. You must also use the VFS fake permissions module (I haven't tested it yet)
[Profiles] ... vfs objects = fake_perms
Users may have to change their passwords. If they issue the change from a Linux session then only the UNIX password is changed and if they issue the change from a Windows session then only the SMB password is changed. Since we need that the users always have the same identifiers regardless of the environment used, we must synchronize UNIX and SMB passwords.
To automatically change the UNIX password whenever a SMB password is changed, uncomment the following lines in /etc/samba/smb.conf and restart smb
[global] unix password sync = Yes passwd program = /usr/bin/passwd %u passwd chat = *New*UNIX*password* %n\n *ReType*new*UNIX*password* %n\n *passwd:*all*authentication*tokens*updated*successfully*
To automatically change the SMB password whenever a UNIX password is changed, add the following line to /etc/pam.d/system-auth below the pam_cracklib.so invocation
password required /lib/security/$ISA/pam_smbpass.so nullok use_authtok try_first_pass
| Caution |
|---|---|
Be very careful when changing pam config files. A simple mistake can prevent you from connecting even if you are root | |
From now, to Create a user account do the following
# useradd -G tsusers newtsuser # smbpasswd -a -n newtsuser # passwd newtsuser
We said earlier that using a Linux session on a workstation means receiving display from the LTSP server and all what you see runs on the LTSP server. Thus, accessing drives on the workstation returns to a remote access from the LTSP server to the local drives on the workstation
Floppyd is used as a server to grant access to the floppy drive to clients running on a remote machine, just as an X server grants access to the display to remote clients. floppyd is always associated with an X server. It runs on the same machine as its X server, and listens on port 5703 and above.
mtools is a collection of tools to allow Unix systems to manipulate MS-DOS files: read, write, and move around files on an MS-DOS filesystem (typically a floppy disk) without mounting/unmounting it. MtoolsFM is a little file manager that uses mtools and has a nice GUI.
| Note |
|---|---|
When you connect using a Linux session, you will see an icon on the desktop named "Floppy access" which launches MtoolsFM. | |
To use floppyd on the workstation to grant access to the floppy drive
Add the following line in /opt/ltsp/i386/etc/lts.conf at the end of the workstation's section
[workstation_name] ... # start floppyd to access the floppy drive (listen on port 5703) RCFILE_01 = floppyd
Reboot the workstation
To access the floppy drive from a Linux session
Make sure that /etc/mtools.conf contains only the following lines
# Assign drive "a:" to floppy drive a: file="$DISPLAY" mtools_skip_check=1 remote
Create a file named /etc/mtoolsfm.conf and put the following lines in it
# MToolsFM config file. comments start with a hash sign. # # This variable sets the allowed driveletters (all lowercase). Example: # DRIVES="ab" DRIVES="a" # # This variable sets the driveletter upon startup in the left window. # An empty string or space is for the hardisk. Example: # LEFTDRIVE="a" LEFTDRIVE="" # # This variable sets the driveletter upon startup in the right window. # An empty string or space is for the hardisk. Example: # RIGHTDRIVE="a" RIGHTDRIVE=""
Use the mtools commands or the MtoolsFM GUI
Many USB keys are preformatted with a MS-DOS filesytem. This means that it is possible to access the USB keys with floppyd. The procedure is outlined below (for more details, see USB Storage in the K12LTSP wiki)
To use floppyd on the workstation to grant access to the USB key
Create a directory called dev-files containing the device file sda1. This is because USB keys are generally assigned /dev/sda1 under a Linux system
# mkdir /opt/ltsp/i386/dev-files # MAKEDEV -d /opt/ltsp/i386/dev-files -x sda1
Create the file /opt/ltsp/i386/etc/rc.d/usbkey containing the following and make it executable
#!/bin/bash # # First, since floppyd runs as nobody, make /tmp world accessible. # chmod 777 /tmp # #copy the previously created device node # mkdir /tmp/dev cp -a /dev-files/sda1 /tmp/dev/sda1 # # and make it world accessible # chmod 666 /tmp/dev/sda1 # # Finally, start floppyd. # # In order to have access to both floppy and USB keys, we tell floppyd # to listen on port 5704. floppyd -l -s 5704 -d /tmp/dev/sda1
# chmod 755 /opt/ltsp/i386/etc/rc.d/usbkey
Add the following line in /opt/ltsp/i386/etc/lts.conf at the end of the workstation's section
[workstation_name] ... # Load USB Mass Storage driver MODULE_01 = usb-storage #MODULE_02 = ehci-hcd # start floppyd to access the USB key (listen on port 5704) RCFILE_02 = usbkey
Reboot the workstation
To access the floppy drive from a Linux session
Modify /etc/mtools.conf so that is looks like this
# Assign drive "a:" to floppy drive a: file="$DISPLAY" mtools_skip_check=1 remote # Assign drive "u:" to USB key drive u: file="$DISPLAY/5704" mtools_skip_check=1 remote
Modify /etc/mtoolsfm.conf so that is looks like this
# MToolsFM config file. comments start with a hash sign. # # This variable sets the allowed driveletters (all lowercase). Example: # DRIVES="ab" DRIVES="au" # # This variable sets the driveletter upon startup in the left window. # An empty string or space is for the hardisk. Example: # LEFTDRIVE="a" LEFTDRIVE="" # # This variable sets the driveletter upon startup in the right window. # An empty string or space is for the hardisk. Example: # RIGHTDRIVE="a" RIGHTDRIVE=""
Use the mtools commands or the MtoolsFM GUI
Tip If you don't see any of the drives in MtoolsFM, then quit MtoolsFM, delete ${HOME}/.mtoolsfm and start MtoolsFM. You can also use "Configure MtoolsFM..." in the "Options" menu of MtoolsFM.
Warning You can plug/unplug a same USB key as many time as you want but if you plug another USB key it will not be accessed because the system assigned to it another device (likely /dev/sdb1). I think that this is because of using devfs. If you want to use another USB key then the only solution I know is to reboot the workstation
If you plug a USB key for the first time and you can't have access to it, be sure that it has a MS-DOS filesystem on it.
Floppyd is limited to MS-DOS filesystems which means that you can't use it to access to devices with other filesystems like a CDROM drive. Since LTSP 4, we can use supermount and a samba server on the workstation to access various devices (for more details, see LTSP localdev). The big problem with this solution is about security and confidentiality of the removable media you use: anyone can read, write or even destroy your data. Accessing the SMB shares on the workstation by issuing mounts under the user's home directory (see http://wiki.ltsp.org/twiki/bin/view/Ltsp/LocalDrives) doesn't solve the problem because the SMB shares on the workstation remain accessible to everyone. If you have a more secure solution (kerberos?) let me know and I will update this document.
Supermount is a pseudo-filesystem which manages filesystems on removable media like floppy disks and CD-ROMs. It frees you from need to manually mount and unmount media. With supermount, you can change the disk in the drive whenever you want (with the obvious exception that you shouldn't do it when the filesystem is actively in use). You don't need to "cd" out of the directory first, and you don't need to tell the kernel what you're doing --- supermount will detect the media change automatically.
Supermount will automatically detect whether the media you are mounting is read-write or readonly, and if you mount a write-protected disk, then the subfs will be mounted as a readonly filesystem.
Supermount detects when you have finished activity on the subfs, and will flush all buffers to the disk before completing the operation. So, if you copy a file onto a supermounted floppy disk, the data will all be written to disk before the "cp" command finishes. When the command does complete, it will be safe to remove the disk.
To use supermount on the workstation to manage the removable media and a samba server to allow access to these media through smb shares
First of all, run ltspadmin the LTSP Administration Utility. Go to Install/Update LTSP Packages, see if there's any updates for "ltsp_localdev" and install them if any
Add the following lines in /opt/ltsp/i386/etc/lts.conf at the end of the workstation's section
[workstation_name] ... # IDE CDROM drive (here a secondary master) LOCAL_DEVICE_01 = /dev/hdc:cdrom # Floppy drive LOCAL_DEVICE_02 = /dev/fd0:floppy # USB key LOCAL_DEVICE_03 = /dev/sda1:usbkey # USB CDROM LOCAL_DEVICE_04 = /dev/sr0:usbcdrom # USB floppy LOCAL_DEVICE_05 = /dev/sdb:usbfloppy
Reboot the workstation
Check if samba is sharing as expected
# smbclient -L workstation_name -N
To access the various drives from a Linux session, use the automounter with mount.cifs (instead of mount.smbfs) to access to the workstation's smb shares. For each workstation:
Create the mount point
# mkdir -p /localdev/workstation_name
Add the following line to /etc/auto.master
/localdev/workstation_name /etc/auto.workstation_name --timeout=60
Create the file /etc/auto.workstation_name with the following lines
cdrom -fstype=cifs,workgroup=LTSP,guest ://workstation_name/cdrom floppy -fstype=cifs,workgroup=LTSP,file_mode=0666,dir_mode=0777,guest,username=nobody,rw ://workstation_name/floppy usbkey -fstype=cifs,workgroup=LTSP,file_mode=0666,dir_mode=0777,guest,username=nobody,rw ://workstation_name/usbkey usbcdrom -fstype=cifs,workgroup=LTSP,guest ://workstation_name/usbcdrom usbfloppy -fstype=cifs,workgroup=LTSP,file_mode=0666,dir_mode=0777,guest,username=nobody,rw ://workstation_name/usbfloppy
Restart the automounter
# service autofs restart
Go to /localdev/workstation_name/{cdrom,floppy,usbkey,usbcdrom, usbfloppy}
Tip If you want to know the name of the workstation you are working on, issue the following command:
# echo $DISPLAY
| Note |
|---|---|
You can use supermount together with floppyd on the same workstation | |
At the time of this writing, rdesktop doesn't support local drive mapping but if you have configured supermount and a samba server to be used on the workstation, then accessing the drives on the workstation with a Windows session becomes easy: connect to the SMB shares on the workstation.
You can connect the drives manually or make things more transparent so that when a user opens a Windows session, the SMB shares on the workstation will be connected automatically
Check the SMB shares on the workstation (Start -> Run... -> \\workstation_name) or
c:\> net view \\workstation_name
Note If you get trouble with this command you likely have a netbios resolution problem. Check that the TSE server is configured to use WINS and that the WINS server is setup correctly
Connect to the shares
We can tell Windows to execute a script each time a user logs on. In the script we simply put instructions to connect the SMB shares. To write the script we can use the rudimentary DOS BATCH or a more rich language such as VBScript or KiXtart
Add the following line to /etc/samba/smb.conf
[global] logon script = logon.bat
Create a file named /home/netlogon/logon.bat with the following lines where %Clientname% is an environment variable containing the netbios name of the workstation from which you are logging on the TSE server
@echo off REM Delete existing drive mappings if any REM This is useful if users connect using different workstations NET USE V: /DELETE /Y NET USE W: /DELETE /Y NET USE X: /DELETE /Y NET USE Y: /DELETE /Y NET USE Z: /DELETE /Y REM Map workstation's drives IF "%Clientname%" == "workstation_name" GOTO workstation_name IF "%Clientname%" == "another_workstation_name" GOTO another_workstation_name GOTO END :workstation_name NET USE V: \\workstation_name\cdrom /PERSISTENT:NO NET USE W: \\workstation_name\floppy /PERSISTENT:NO NET USE X: \\workstation_name\usbkey /PERSISTENT:NO NET USE Y: \\workstation_name\usbcdrom /PERSISTENT:NO NET USE Z: \\workstation_name\usbfloppy /PERSISTENT:NO GOTO END :another_workstation_name NET USE V: \\another_workstation_name\cdrom /PERSISTENT:NO NET USE W: \\another_workstation_name\floppy /PERSISTENT:NO NET USE X: \\another_workstation_name\usbkey /PERSISTENT:NO GOTO END :END
Convert it to DOS format (don't forget this)
# unix2dos /home/netlogon/workstation_name.bat
Open a Windows session to check if it works
Note Using a .bat file per workstation and setting "logon script" to %m.bat will NOT work because %m will always be expanded to the name of the TSE server and not the workstation you are logging on
You can configure your printers on either the LTSP and TSE server independently or better configure them on one server and make them available on the other server.
todo...
Linux is under GPL ; the General Public License. To understand licencing with Windows, see The Ultimate Guide to Windows 2003 Terminal Server Licensing
With figure 1, if you have N workstations and M users then (FIXME please, complete the table):
| Machine type | Number of Machines | Commercial License type | Number of licenses |
|---|---|---|---|
| LTSP server | 1 | - | 0 |
| TSE server | 1 | Windows Server 2003 (server license) | 1 |
| Workstation | N | Temporary Lincense (limited to 120 days) | N |
| Terminal Server Device Client Acces License (TS Device CAL) (beyond 120 days) | N | ||
| Terminal Server User Client Acces License (TS User CAL) (beyond 120 days) | M | ||
| External Connector License (ECL) (beyond 120 days) | 1 |
Table 1. Licenses needed in figure 1
Remember that W2K3 doesn't support the use of built-in licenses.
What about using the -n option with rdesktop after 120 days ???
Most of the solutions I have seen around make workstations provide only Linux sessions and if you want to connect to a Windows server, you must first connect using the Linux session and then use rdesktop to connect to the Windows server (see figure 2).
The table below summarizes the main differences between using Windows sessions in figure 1 and figure 2
| Figure 1 | Figure 2 | |
|---|---|---|
| network traffic between TSE server and workstations | direct | must pass through LTSP server |
| protocols used to transport Windows display | RDP | RDP + XDMCP |
| rdesktop processes are | distributed (on workstations) | centralized (on the LTSP server) |
| rdesktop binary location | /opt/ltsp/i386/usr/bin/rdesktop | /usr/bin/rdesktop |
| need a Linux session when using Windows | no | yes |
| must authenticate | once | twice |
| Connect local drives automatically with a logon script | yes (%Clientname% is set to the workstation's name) | no (%Clientname% is always set to the LTSP server's name) |
Table 2. Differences between using Windows sessions in figure 1 and figure 2
For licensing with figure 2, if you have N workstations and M users then (FIXME please, complete the table):
| Machine type | Number of Machines | Commercial License type | Number of licenses |
|---|---|---|---|
| LTSP server | 1 | - | 0 |
| TSE server | 1 | Windows Server 2003 (server license) | 1 |
| Workstation | N | Temporary Lincense (limited to 120 days) | N |
| Terminal Server Device Client Acces License (TS Device CAL) (beyond 120 days) | 1? | ||
| Terminal Server User Client Acces License (TS User CAL) (beyond 120 days) | M | ||
| External Connector License (ECL) (beyond 120 days) | 1 |
Table 3. Licenses needed in figure 1
This is what LTSP was primarily designed for. K12LTSP made things very easy to be set up. Just follow the few steps in section Setting up the LTSP server. If you don't use K12LTSP then follow the Installation Instructions of LTSP.
A LTSP based solution where workstations provide only a Windows (rdesktop) session is more interesting than a pure Windows solution.
todo...
Follow the steps 1-3,7 and 7-tip-b in the section Setting up the TSE server.
Set RDP_SERVER for each workstation in /opt/ltsp/i386/etc/lts.conf
iptables is blocking services
SCREEN_01 = shell to debug
%Clientname% doesn't correspond to the workstation name
todo...