Differences between revisions 4 and 6 (spanning 2 versions)
Revision 4 as of 2011-09-03 11:56:46
Size: 15499
Editor: HolgerLevsen
Comment: we use 10.0.0.0/8 now
Revision 6 as of 2012-01-12 03:01:29
Size: 15677
Editor: JustinBRye
Comment: proofreading
Deletions are marked like this. Additions are marked like this.
Line 16: Line 16:
In order to simplify the standard setup of Skolelinux, the Internet connection runs over a separate router. It is possible to set up Debian with both a modem and an ISDN connection, however no attempt is made to make such a setup work out of the box for Skolelinux (the setup needed to adjust the default situation to this should be documented separately). In order to simplify the standard setup of Skolelinux, the Internet connection runs over a separate router. It is possible to set up Debian with both a modem and an ISDN connection; however, no attempt is made to make such a setup work out of the box for Skolelinux (the setup needed to adjust the default situation to this should be documented separately).
Line 20: Line 20:
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 requiered) to also select and install the thin-client-server and workstation profiles in addition to the main server profile. 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 thin-client-server and workstation profiles in addition to the main server profile.
Line 23: Line 23:
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 thin-client-server should be a separate machine (though it is possible to install both the main server and thin-client 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 setup on that machine first of course). 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 thin-client-server should be a separate machine (though it is possible to install both the main server and thin-client 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).
Line 25: Line 25:
To ensure security all connections where passwords are transmitted over the network are encrypted, so no passwords are send over the network as plain text. 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.
Line 44: Line 44:
 * Machine and Service Surveillance with Error Reporting, plus Status and History on the Web. Error Reporting by E-mail (munin,nagios and site-summary)
Each user stores his personal files in his home folder which is made available by the server. Home folders 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 in offering access using NFS for Unix Clients, SMB for Windows and Macintosh clients.
 * Machine and Service Surveillance with Error Reporting, plus Status and History on the Web. Error Reporting by email (munin,nagios and site-summary)
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, SMB for Windows and Macintosh clients.
Line 47: Line 47:
By default e-mail is set up for local delivery (i.e. within the school) only, though e-mail delivery to the wider Internet may be set up if the school has a fixed Internet-connection. Mailing lists are set up based on the user database, giving each class their own mailing list. Clients are set up to deliver mail to the server (using 'smarthost'), and users can [[DebianEdu/Documentation/Squeeze/HowTo/Users#Usingemail|access their personal mail]] through either POP3 or IMAP. 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. Mailing lists are set up based on the user database, giving each class their own mailing list. Clients are set up to deliver mail to the server (using 'smarthost'), and users can [[DebianEdu/Documentation/Squeeze/HowTo/Users#Usingemail|access their personal mail]] through either POP3 or IMAP.
Line 53: Line 53:
Network configuration on the clients is done automatically using DHCP. Normal clients are allocated IP addresses in the private subnet 10.0.0.0/8, while thin clients are connected to the corresponding thin-client-server via the seperate subnet 192.168.0.0/24 (this to ensure that the network traffic of the thin clients doesn't interfere with the rest of the network services). Network configuration on the clients is done automatically using DHCP. Normal clients are allocated IP addresses in the private subnet 10.0.0.0/8, while thin clients are connected to the corresponding thin-client-server via the separate subnet 192.168.0.0/24 (this is to ensure that the network traffic of the thin clients doesn't interfere with the rest of the network services).
Line 59: Line 59:
Pupils and teachers have the possibility to publish websites. The web server provides mechanisms for authenticating users, and for limiting access to individual pages and subdiretories to certain users and groups. Users will have the possibility to create dynamic web pages, as the web server will be programmable on the server side. 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.
Line 61: Line 61:
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 centralized 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, mailing lists, and network groups. This implies that groups of machines which have to be network groups, have the same namespace as user groups and mailing lists. 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 centralized 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, mailing lists, and network groups. This implies that groups of machines which are to form network groups will use the same namespace as user groups and mailing lists.
Line 63: Line 63:
Administration of services and users will by and large be via 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. Administration of services and users will by and large 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.
Line 65: Line 65:
In order to avoid certain problems with NFS, and to make it simpler to debug problems, time needs to be synchronized on the different machines. 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 synchronize their clock with the server. The server itself should synchronize its clock via NTP against machines on the Internet, thus ensuring the whole network has the correct time. In order to avoid certain problems with NFS, and to make it simpler to debug problems, the different machines needs synchronized 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 synchronize with the server. The server itself should synchronize its clock via NTP against machines on the Internet, thus ensuring the whole network has the correct time.
Line 67: Line 67:
Printers are connected where convenient, either directly onto the network, or connected to a server, workstation or thin-client-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. Printers are connected where convenient, either directly onto the network, or connected to a server, workstation or thin-client-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.
Line 76: Line 76:
A thin client setup enables a ordinary PC to function as an (X-)terminal. This means that this machine boots from a diskette or directly from the server using network-PROM (or PXE) without using the local client hard drive. The thin client setup used is that of the Linux Terminal Server Project (LTSP). A thin client setup enables ordinary PCs to function as (X-)terminals. This means that the machine boots from a diskette or directly from the server using network-PROM (or PXE) without using the local client hard drive. The thin client setup used is that of the Linux Terminal Server Project (LTSP).
Line 78: Line 78:
Thin clients are a good way to make use of older, weaker 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 via NFS from the LTSP-server, and finally X11 is started.
The display manager (LDM) connects to the LTSP-Server via SSH with X-forwarding. That way all data is encrypted on the network.
For very old thin clients which are to slow for the encryption this can be set to the behaviour from former versions: use direct X connection via XDMCP.
Thin clients are a good way to make use of older, weaker 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 via NFS from the LTSP server, and finally the X Window System is started.
The display manager (LDM) connects to the LTSP server via SSH with X-forwarding. This way all data is encrypted on the network.
For very old thin clients which are too slow for the encryption this can be set to the behavior from former versions, which is to use a direct X connection via XDMCP.
Line 86: Line 86:
A diskless workstation runs all software on the PC without a locally installed operating system. This means that client machines boot direcly from the servers hard drive without running software installed on a local hard drive. A diskless workstation runs all software on the PC without a locally installed operating system. This means that client machines boot directly from the server's hard drive without running software installed on a local hard drive.
Line 88: Line 88:
Diskless workstations are an exellent way of reusing newer hardware with the same low maintanence 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. Diskless workstations are an excellent way of reusing newer 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.
Line 94: Line 94:
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. 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.
Line 97: Line 97:
All the linux machines that are installed by means of a Skolelinux CD or DVD will be administrable from a central computer, most likely the server. It will be possible to login to all machines by ssh, and thereby have full access to the machines All the Linux machines that are installed by means of a Skolelinux CD or DVD 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.
Line 101: Line 101:
All user information is kept in an LDAP directory. Updates of user accounts are made against this database and is used by the clients for user authentication. 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.
Line 108: Line 108:
The installation should not ask any questions, with the exception of desired language (e.g. Norwegian Bokmal, Nynorsk, Sami) and machine profile (server, workstation, thin client server). All other configuration will be set up automatically with reasonable values, to be changed from a centrally location by the system administrator subsequent to the installation. The installation should not ask any questions, with the exception of desired language (e.g. Norwegian Bokmal, Nynorsk, Sami) and machine profile (server, workstation, thin client 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.
Line 111: Line 111:
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. 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.
Line 113: Line 113:
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 accomodate particular user groups or particular patterns of usage. 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.
Line 115: Line 115:
To enable shared file access control using the file groups, each user must be assigned a primary group with no other members. The name of this private group should be identical to the username. ([[http://www.redhat.com/docs/manuals/linux/RHL-9-Manual/ref-guide/s1-users-groups-private-groups.html|More info on private groups]] is available from Redhat.) This allows for all new files created by the user to be set with full access for the file's group. Together with set-gid bit on directories and inheritance of rights, this enables controlled file sharing between the members of a file group. Therefore, the users' umask should be 00X. (If all users initially should be able to read newly created files, then X=2. If only the relevant group should be given initial read access then X=7.) To enable shared file access control using the file groups, each user must be assigned a primary group with no other members. The name of this private group should be identical to the username. ([[http://www.redhat.com/docs/manuals/linux/RHL-9-Manual/ref-guide/s1-users-groups-private-groups.html|More info on private groups]] is available from Redhat.) This allows for all new files created by the user to be set with full access for the file's group. Together with the setgid bit on directories and inheritance of rights, this enables controlled file sharing between the members of a file group. Therefore, the users' umask should be 00X. (If all users initially should be able to read newly created files, then X=2. If only the relevant group should be given initial read access then X=7.)
Line 117: Line 117:
The initial access settings for newly created files is a matter of policy. They may either be set to give read access to everybody, which can later be removed by explicit user action, or they may be 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. This is detectable only upon inspection of other users' directories, where one can see that the 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). The initial access settings for newly created files are a matter of policy. They may either be set to give read access to everybody, which can later be removed by explicit user action, or they may be 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. This is detectable only upon inspection of other users' directories, where one can see that the 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).
Line 119: Line 119:
FIXME: check if our umask differs from Debians default and possible describe it here. this chapter needs a bit cleanup FIXME: check if our umask differs from Debian's default and possible describe it here. This chapter needs a bit of cleanup. The Debian default umask is 022, while Debian Edu change this to 002 by adding /usr/share/pam-configs/edu-umask.
Line 125: Line 125:
DHCPD on Tjener serves the 10.0.0.0/8 network, via PXE-Boot you get a
syslinux menu where you can choose whether to install a new
s
erver/workstation, boot a thinclient or a diskless workstation,
memtest, or
from local harddisc.
DHCPD on Tjener serves the 10.0.0.0/8 network, providing a syslinux menu via PXE-boot where you can choose whether to install a new
server/workstation, boot a thinclient or a diskless workstation, run memtest, or boot from the local hard disk.
Line 130: Line 128:
This of course can be modified, ie. you can have the nfs-root in syslinux point to one of the ltspservers or change next-server in DHCP to have clients
directly boot via PXE from the terminalserver.
This of course can be modified - that is, you can have the NFS-root in syslinux point to one of the LTSP servers or change next-server in DHCP to have clients directly boot via PXE from the terminal server.
Line 133: Line 130:
DHCPD on the ltspservers only serves a dedicated 192.168.0.0/24
network on the second interface and is of no interest for this scenario.
DHCPD on the LTSP servers only serves a dedicated 192.168.0.0/24 network on the second interface and is of no interest for this scenario.
Line 137: Line 133:
'''This chapter was initially copied and pasted from http://developer.skolelinux.no/arkitektur/arkitektur.html.en ( at that time it was Copyright © 2001, 2002, 2003, 2004 Petter Reinholdtsen < pere@hungry.com >, released under the GPL) and has since then been edited.''' '''This chapter was initially copied and pasted from http://developer.skolelinux.no/arkitektur/arkitektur.html.en (at that time it was Copyright © 2001, 2002, 2003, 2004 Petter Reinholdtsen < pere@hungry.com >, released under the GPL) and has since then been edited.'''

Architecture

This section of the document describes the network architecture and services provided by a Skolelinux installation.

Network

network-arch.png

(The debian-edu-doc source package contains this image as a dia file.)

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 thin-client-servers (with associated thin-clients). The number of workstations can be as large or small as you want (starting from none to a lot). The same goes for the thin-client servers, each of which is on a separate network so that the traffic between the thin-clients and the thin-client server doesn't affect the rest of the network services.

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. It is possible to set up Debian with both a modem and an ISDN connection; however, no attempt is made to make such a setup work out of the box for Skolelinux (the setup needed to adjust the default situation to this should be documented separately).

Main server (tjener)

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 thin-client-server and workstation profiles in addition to the main server profile.

Services running on the main server

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 thin-client-server should be a separate machine (though it is possible to install both the main server and thin-client 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 list of the services that are set up by default in a Skolelinux network, with the DNS name of each service given in square brackets. 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.

  • Centralized Logging [syslog]
  • DNS (PowerDNS) [domain]
  • Automatic Network Configuration of Machines (DHCP) [bootps]
  • Clock Synchronization (NTP) [ntp]
  • Home Directories via Network File System (SMB/NFS) [homes]
  • Electronic Post Office [postoffice]
  • Directory Service (OpenLDAP) [ldap]
  • User Administration (lwat)
  • Web Server (Apache/PHP) [www]
  • Central Backup (sl-backup, slbackup-php) [backup]
  • Web Cache / Proxy (Squid) [webcache]
  • Printing (CUPS) [ipp]
  • Remote Login (OpenSSH) [ssh]
  • Automatic Configuration [cfengine]
  • Thin Client Server/s (LTSP) [ltspserver\#]
  • Machine and Service Surveillance with Error Reporting, plus Status and History on the Web. Error Reporting by email (munin,nagios and site-summary)

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, SMB for Windows and Macintosh 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. Mailing lists are set up based on the user database, giving each class their own mailing list. Clients are set up to deliver mail to the server (using 'smarthost'), and users can access their personal mail through either POP3 or IMAP.

All services are accessible using the same username and password, thanks to the central user database for authentication and authorization.

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. Normal clients are allocated IP addresses in the private subnet 10.0.0.0/8, while thin clients are connected to the corresponding thin-client-server via the separate subnet 192.168.0.0/24 (this is to ensure that the network traffic of the thin clients doesn't interfere with the rest of the network services).

Centralized 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 centralized 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, mailing lists, and network groups. This implies that groups of machines which are to form network groups will use the same namespace as user groups and mailing lists.

Administration of services and users will by and large 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 needs synchronized 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 synchronize with the server. The server itself should synchronize 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 network, or connected to a server, workstation or thin-client-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.

LTSP server(s) (Thin client server(s))

A Skolelinux network can have many LTSP servers (also called thin client servers), which are installed by selecting the LTSP server profile.

The thin client servers are set up to receive syslog from the thin clients, and forward these messages to the central syslog recipient.

Thin clients

A thin client setup enables ordinary PCs to function as (X-)terminals. This means that the machine boots from a diskette or directly from the server using network-PROM (or PXE) without using the local client hard drive. The thin client setup used is that of the Linux Terminal Server Project (LTSP).

Thin clients are a good way to make use of older, weaker 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 via NFS from the LTSP server, and finally the X Window System is started. The display manager (LDM) connects to the LTSP server via SSH with X-forwarding. This way all data is encrypted on the network. For very old thin clients which are too slow for the encryption this can be set to the behavior from former versions, which is to use a direct X connection via XDMCP.

Diskless workstations

For diskless workstations the terms "stateless workstations", "lowfat clients" or "half-thick clients" are also used. For the sake of clarity this manual sticks to the term "diskless workstations".

A diskless workstation runs all software on the PC without a locally installed operating system. This means that client machines boot directly from the server's hard drive without running software installed on a local hard drive.

Diskless workstations are an excellent way of reusing newer 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.

Diskless workstations were introduced as part of the Linux Terminal Server Project (LTSP) with version 5.0.

Networked clients

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.

Administration

All the Linux machines that are installed by means of a Skolelinux CD or DVD 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.

We use cfengine to edit configuration files. These files are updated from the server to the clients. In order to change the client configuration, it suffices to edit the server configuration and let the automatation distribute the changes.

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.

Installation

Installation is possible either from a CD or DVD.

The aim is to be able to install a server from CD/DVD, and install clients over the network by booting all other machines from the network. The DVD installation works without access to the Internet.

The installation should not ask any questions, with the exception of desired language (e.g. Norwegian Bokmal, Nynorsk, Sami) and machine profile (server, workstation, thin client 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.

File system access configuration

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 file access control using the file groups, each user must be assigned a primary group with no other members. The name of this private group should be identical to the username. (More info on private groups is available from Redhat.) This allows for all new files created by the user to be set with full access for the file's group. Together with the setgid bit on directories and inheritance of rights, this enables controlled file sharing between the members of a file group. Therefore, the users' umask should be 00X. (If all users initially should be able to read newly created files, then X=2. If only the relevant group should be given initial read access then X=7.)

The initial access settings for newly created files are a matter of policy. They may either be set to give read access to everybody, which can later be removed by explicit user action, or they may be 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. This is detectable only upon inspection of other users' directories, where one can see that the 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).

FIXME: check if our umask differs from Debian's default and possible describe it here. This chapter needs a bit of cleanup. The Debian default umask is 022, while Debian Edu change this to 002 by adding /usr/share/pam-configs/edu-umask.

The default network setup

FIXME: maybe move to a page of its own or further up.

DHCPD on Tjener serves the 10.0.0.0/8 network, providing a syslinux menu via PXE-boot where you can choose whether to install a new server/workstation, boot a thinclient or a diskless workstation, run memtest, or boot from the local hard disk.

This of course can be modified - that is, you can have the NFS-root in syslinux point to one of the LTSP servers or change next-server in DHCP to have clients directly boot via PXE from the terminal server.

DHCPD on the LTSP servers only serves a dedicated 192.168.0.0/24 network on the second interface and is of no interest for this scenario.


This chapter was initially copied and pasted from http://developer.skolelinux.no/arkitektur/arkitektur.html.en (at that time it was Copyright © 2001, 2002, 2003, 2004 Petter Reinholdtsen < pere@hungry.com >, released under the GPL) and has since then been edited.

CategoryPermalink