(!) If LTSP is intended to be used, take a look at the
Sommaire
Requirements for network setup
Services running on the main server
File system access configuration
There are different ways of setting up a Skolelinux solution. It can be installed on just one standalone PC, or as a region-wide solution at many schools operated centrally. This flexibility makes a huge difference to the configuration of network components, servers and client machines.
The purpose of the different profiles is explained in the network architecture chapter.
(!) •.The computers running Debian Edu / Skolelinux must have either 32 bit (Debian architecture 'i386', oldest supported processors are 686 class ones) or 64 bit (Debian architecture 'amd64') x86 processors.
•.Thin clients with only 256 MiB RAM and 400 MHz are possible, though more RAM and faster processors are recommended.
•.For workstations, diskless workstations and standalone systems, 1500 MHz and 1024 MiB RAM are the absolute minimum requirements. For running modern webbrowsers and LibreOffice at least 2048 MiB RAM is recommended.
•.The minimum disk space requirements depend on the profile which is installed:
•.LTSP servers need two network cards when using the default network architecture:
•.Laptops are movable workstations, so they have the same requirements as workstations.
:) https://wiki.debian.org/InstallingDebianOn is an effort to document how to install, configure and use Debian on some specific hardware, allowing potential buyers to know if that hardware is supported and existing owners to know how get the best out of that hardware.
When using the default network architecture, these rules apply:
•.You can have hundreds of workstations on the main network.
•.You can have a lot of LTSP servers on the main network; two different subnets are preconfigured (DNS, DHCP) in LDAP, more can be added.
•.You can have hundreds of thin clients and/or diskless workstations on each LTSP server network.
•.You can have hundreds of other machines which will have dynamic IP addresses assigned.
•.For access to the Internet you need a router/gateway (see below).
A router/gateway, connected to the Internet on the external interface and running on the IP address 10.0.0.1 with netmask 255.0.0.0 on the internal interface, is needed to connect to the Internet.
The router should not run a DHCP server, it can run a DNS server, though this is not needed and will not be used.
In case you already have a router but are unable to configure it as needed (eg because you are not allowed to do so, or for technical reasons), an older computer with two network interfaces can be turned into a gateway between the existing network and the Debian Edu one.
A simple way is to install Debian Edu on this computer; select 'Minimal' as profile during installation.
After installation, run /usr/share/debian-edu-config/tools/configure-edu-gateway --firewall <yes|no> which will make the following changes:
If you need something for an embedded router or accesspoint we recommend using OpenWRT, though of course you can also use the original firmware. Using the original firmware is easier; using OpenWRT gives you more choices and control. Check the OpenWRT webpages for a list of supported hardware.
It is possible to use a different network setup (there is a documented procedure to do this), but if you are not forced to do this by an existing network infrastructure, we recommend against doing so and recommend you stay with the default network architecture.
This section of the document describes the network architecture and services provided by a Skolelinux installation.
The figure is a sketch of the assumed network topology. The default setup of a Skolelinux network assumes that there is one (and only one) main server, while allowing the inclusion of both normal workstations and LTSP servers (with associated thin clients and/or diskless workstations). The number of workstations can be as large or small as you want (starting from none to a lot). The same goes for the LTSP servers, each of which is on a separate network so that the traffic between the clients and the LTSP server doesn't affect the rest of the network services. LTSP is explained in detail in the related HowTo chapter.
The reason that there can only be one main server in each school network is that the main server provides DHCP, and there can be only one machine doing so in each network. It is possible to move services from the main server to other machines by setting up the service on another machine, and subsequently updating the DNS configuration, pointing the DNS alias for that service to the right computer.
In order to simplify the standard setup of Skolelinux, the Internet connection runs over a separate router, also called gateway. See the Internet router chapter for details how to set up such a gateway if it is not possible to configure an existing one as needed.
DHCP on the main server serves the 10.0.0.0/8 network, providing a PXE boot menu where you can choose whether to install a new server/workstation, boot a thin client or a diskless workstation, run memtest, or boot from the local hard disk.
This is designed to be modified; for details, see the related HowTo chapter.
DHCP on the LTSP servers only serves a dedicated network on the second interface (192.168.0.0/24 and 192.168.1.0/24 are preconfigured options) and should seldom need to be changed.
The configuration of all subnets is stored in LDAP.
A Skolelinux network needs one main server (also called "tjener" which is Norwegian and means "server") which per default has the IP address 10.0.2.2 and is installed by selecting the Main Server profile. It's possible (but not required) to also select and install the LTSP Server and Workstation profiles in addition to the Main Server profile.
With the exception of the control of the thin clients, all services are initially set up on one central computer (the main server). For performance reasons, the LTSP server(s) should be separate (though it is possible to install both the Main Server and LTSP Server profiles on the same machine). All services are allocated a dedicated DNS-name and are offered exclusively over IPv4. The allocated DNS name makes it easy to move individual services from the main server to a different machine, by simply stopping the service on the main server, and changing the DNS configuration to point to the new location of the service (which should be set up on that machine first, of course).
To ensure security all connections where passwords are transmitted over the network are encrypted, so no passwords are sent over the network as plain text.
Below is a table of the services that are set up by default in a Skolelinux network and the DNS name of each service. If possible all configuration files will refer to the service by name (without the domain name) thus making it easy for schools to change either their domain (if they have an own DNS domain) or the IP addresses they use.
Personal files for each user are stored in their home directories, which are made available by the server. Home directories are accessible from all machines, giving users access to the same files regardless of which machine they are using. The server is operating system agnostic, offering access via NFS for Unix clients and via SMB2/SMB3 for other clients.
By default email is set up for local delivery (i.e. within the school) only, though email delivery to the wider Internet may be set up if the school has a permanent Internet connection. Clients are set up to deliver mail to the server (using 'smarthost'), and users can access their personal mail through IMAP.
All services are accessible using the same username and password, thanks to the central user database for authentication and authorisation.
To increase performance on frequently accessed sites a web proxy that caches files locally (Squid) is used. In conjunction with blocking web-traffic in the router this also enables control of Internet access on individual machines.
Network configuration on the clients is done automatically using DHCP. All types of clients can be connected to the private 10.0.0.0/8 subnet and will get according IP addresses; LTSP clients should be connected to the corresponding LTSP server via the separate subnet 192.168.0.0/24 (this is to ensure that the network traffic of the LTSP clients doesn't interfere with the rest of the network services).
Centralised logging is set up so that all machines send their syslog messages to the server. The syslog service is set up so that it only accepts incoming messages from the local network.
By default the DNS server is set up with a domain for internal use only (*.intern), until a real ("external") DNS domain can be set up. The DNS server is set up as caching DNS server so that all machines on the network can use it as the main DNS Server.
Pupils and teachers have the ability to publish websites. The web server provides mechanisms for authenticating users, and for limiting access to individual pages and subdirectories to certain users and groups. Users will have the ability to create dynamic web pages, as the web server will be programmable on the server side.
Information on users and machines can be changed in one central location, and is made accessible to all computers on the network automatically. To achieve this a centralised directory server is set up. The directory will have information on users, user groups, machines and groups of machines. To avoid user confusion there won't be any difference between file groups and network groups. This implies that groups of machines which are to form network groups will use the same namespace as user groups.
Administration of services and users will mainly be via the web, and follow established standards, functioning well in the web browsers which are part of Skolelinux. The delegation of certain tasks to individual users or user groups will be made possible by the administration systems.
In order to avoid certain problems with NFS, and to make it simpler to debug problems, the different machines need synchronised clocks. To achieve this the Skolelinux server is set up as a local Network Time Protocol (NTP) server, and all workstations and clients are set up to synchronise with the server. The server itself should synchronise its clock via NTP against machines on the Internet, thus ensuring the whole network has the correct time.
Printers are connected where convenient, either directly onto the main network, or connected to a server, workstation or LTSP server. Access to printers can be controlled for individual users according to the groups they belong to; this will be achieved by using quota and access control for printers.
A Skolelinux network can have many LTSP servers, which are installed by selecting the LTSP Server profile.
The LTSP servers are set up to receive syslog from thin clients and workstations, and forward these messages to the central syslog recipient.
•.LTSP diskless workstations are using the programs installed on the server.
•.The client root filesystem is provided using NFS. After each modification to the LTSP server the related image has to be re-generated; run debian-edu-ltsp-install --diskless_workstation yes on the LTSP server.
A thin client setup enables ordinary PCs to function as (X-)terminals. This means that the machine boots directly from the server using PXE without using the local client hard drive. The thin client setup now uses X2Go, because LTSP has dropped support.
Thin clients are a good way to still make use of very old (mostly 32-bit) machines as they effectively run all programs on the LTSP server. This works as follows: the service uses DHCP and TFTP to connect to the network and boot from the network. Next, the file system is mounted from the LTSP server using NFS, and finally the X2Go client is started.
A diskless workstation runs all software on the PC without a locally installed operating system. This means that client machines boot via PXE without running software installed on a local hard drive.
Diskless workstations are an excellent way of using powerful hardware with the same low maintenance cost as with thin clients. Software is administered and maintained on the server with no need for local installed software on the clients. Home directories and system settings are stored on the server too.
The term "networked clients" is used in this manual to refer to both thin clients and diskless workstations, as well as computers running macOS or Windows.
All the Linux machines that are installed with the Skolelinux installer will be administrable from a central computer, most likely the server. It will be possible to log in to all machines via SSH, and thereby have full access to the machines. As root one needs to run kinit first to get a Kerberos TGT.
All user information is kept in an LDAP directory. Updates of user accounts are made against this database, which is used by the clients for user authentication.
Currently there are two kinds of installation media images: netinst and BD. Both images can also be booted from USB sticks.
The aim is to be able to install a server from any type of medium once, and install all other clients over the network by booting from the network.
Only the netinstall image needs access to the Internet during installation.
The installation should not ask any questions, with the exception of desired language, location, keyboard and machine profile (Main Server, Workstation, LTSP Server, ...). All other configuration will be set up automatically with reasonable values, to be changed from a central location by the system administrator subsequent to the installation.
Each Skolelinux user account is assigned a section of the file system on the file server. This section (home directory) contains the user's configuration files, documents, email and web pages. Some of the files should be set to have read access for other users on the system, some should be readable by everyone on the Internet, and some should not be accessible for reading by anyone but the user.
To ensure that all disks that are used for user directories or shared directories can be uniquely named across all the computers in the installation, they can be mounted as /skole/host/directory/. Initially, one directory is created on the file server, /skole/tjener/home0/, in which all the user accounts are created. More directories may then be created when needed to accommodate particular user groups or particular patterns of usage.
To enable shared access to files under the normal UNIX permissions system, users need to be in supplementary shared groups (such as "students") as well as the personal primary group that they're in by default. If users have an appropriate umask to make newly created items group-accessible (002 or 007), and if the directories they're working in are setgid to ensure the files inherit the correct group-ownership, the result is controlled file sharing between the members of a group.
The initial access settings for newly created files are a matter of policy. The Debian default umask is 022 (which would not allow group-access as described above), but Debian Edu uses a default of 002 - meaning that files are created with read access for everybody, which can later be removed by explicit user action. This can alternatively be changed (by editing /etc/pam.d/common-session) to a umask of 007 - meaning read access is initially blocked, necessitating user action to make them accessible. The first approach encourages knowledge sharing, and makes the system more transparent, whereas the second method decreases the risk of unwanted spreading of sensitive information. The problem with the first solution is that it is not apparent to the users that the material they create will be accessible to all other users. They can only detect this by inspecting other users' directories and seeing that their files are readable. The problem with the second solution is that few people are likely to make their files accessible, even if they do not contain sensitive information and the content would be helpful to inquisitive users who want to learn how others have solved particular problems (typically configuration issues).
In order for ltsp to meet your needs it is necessary to prepare both hardware and software configuration. In this section we look at the hardware requirements.
The network is crucial and requires more attention using ltsp. In a typical ltsp setup several clients will be sending and receiving packets with the server(s).
Do not use a simple hub. When a packet is sent to a hub, all segments of the lan will see all packets. Traffic slows to a useless crawl. A switch, managed or unmanaged, however, keeps a record of the MAC addresses of all the devices connected to it. With this information, a switch can identify which system is sitting on which port. So when a frame is received, it knows exactly which port to send it to, without significantly increasing network response times. Unlike a hub, a 10/100Mbps switch will allocate a full 10/100Mbps to each of its ports. So regardless of the number of PCs transmitting, users will always have access to the maximum amount of bandwidth.
2 – 1000Mbps or gigabit (or greater) vs 100Mbps
If one has gigabit everywhere, i.e. all the clients and server(s) are all equipped with gigabit network cards, the switch has all gigabit ports, the router, ethernet wall points and rj45 jacks are all gigabit-rated and the cabling is category 5e or 6 (i.e. gigabit-rated) then there is no flow control issue and the bandwidth should suffice for small and medium ltsp usage. In larger setups with many clients then consider 10 gigabit-rated equipment instead.
This is what is recommended when planning a setup from scratch.
Otherwise using legacy hardware requires careful attention to certain details.
a – The router need only handle 100Mbps through its wired ports which is ample for most typical internet connections. Wireless is much slower which, while still able to deliver internet to non-ltsp devices is much more complicated trying to use it with ltsp.
b – A hub (see above) is not useful for ltsp.
c – The switch can be managed or unmanaged but (in most cases) should have at least one gigabit port for each server.
d - All pcs may have either uefi or legacy bios.
e – The server should have at least one gigabit (onboard or not) network interface. In simple cases where it is feasible to run everything within one subnet the server only needs the one network interface. Otherwise the server needs two interfaces to run a local area network or lan (separate from the router) containing the clients, and a wide area network or wan to run the subnet containing the router. The lan requires at least a gigabit network interface on the server whereas the wide area network or wan can manage with a 100Mbps network interface on the server.
f – Clients which have only 100Mbps (onboard or not) network interface are adequate and can be connected to 100Mb ps or gigabit ports on the switch. In either case, however, there arises the issue of flow control. Using the latest ltsp software resolves this issue.
g – Cabling and wall sockets may be only 100Mbps capable except for the connection from the gigabit device from the server to the gigabit port on the switch which all must be gigabit capable.
In addition to the above, legacy pc’s need further scrutiny.
i – A server’s hardware requirements are less severe with fat clients. The amount of ram memory is calculated: 2000 MB + 30 MB for each fat client it serves + 300 MB for each thin client. Examples: 10 fat clients only, 2300 MB of ram memory is the minimum but will do; 10 thin clients only, 5 GB is the minimum; 5 fat clients and 2 thin clients, 4.1 GB is the minimum. The recommended cpu benchmark rating (http://www.cpubenchmark.net/cpu_list.php) is similarly calculated: 2000 + 30 for each fat client + 300 for each thin client. Thus a 2300 rating is a minimum if running 10 fat clients only; a 5000 rating for 10 thin clients only; a 4100 rating for 5 fat and 2 thin clients. Of course these numbers represent the least amount acceptable.
ii – At the very least a fat client should have more than 1 GB ram memory (not SDRAM) but DDR, the newer the version, the better.) 2 GB is recommended. Its cpu benchmark rating is the most important. A rating of 1000 or more is recommended.
In general legacy pc’s which have similar characteristics are easier to setup and maintain. Otherwise variety requires more work.
iii – A thin client needs less memory but should have at least 256 MB. Otherwise the above remarks for fat clients apply.
iv – All clients may be diskless, uefi or legacy bios, 64 or 32 bit. Where these are similar there is less work for the administration.
The Debian Edu network topology