Trial1 Server Software
This page describes the software for a quick first prototype of the School server, intended for use in trials of the XO laptop using Trial1 Software. This is not necessarily representative of the system OLPC plans to ship in production, it contains many simplifications to speed prototyping.
Target Platform
The target platforms for this software are:
- An XO laptop (AMD i586) -- An image to start with
- A conventional desktop machine (Intel or AMD i586)
- XSX, a dozen early prototypes (hardware selection ongoing, i586)
- developer boards for processors under consideration
At least 128 MB of memory (and a storage device capable of supporting virtual memory) is required. 256 MB or more is suggested.
The storage device may be attached using:
- SATA
- IDE (PATA)
- USB
The networking interfaces will be varied. Each server will support up to three Marvell wireless mesh networking modules connected via USB 2.0. In addition, at least two 100baseT network intefaces will be provided for connection to the WAN and LAN. These may also be connected via USB.
No graphics capabilities are planned. If a server (such as a desktop machine) has an attached keyboard and display, they will used for a text console.
Installation
It has been suggested that Pilgrim be used for building bootable images of the server software.
Disk Partitions
The OS and applications should have the root partition, initialized by the disk image. Optimum size TBD, 5GB for now. /dev is provided by udev, /proc and /sys by the kernel.
A logical volume manager will be used to manage the storage used by students and library content. One logical volume will be used, which will use a second partition on the disk.
Memory swap space will require one 2GB partition
Can Pilgrim handle a separate /var partition ? (1GB for now)
Manifest
This is the software manifest for the school server.
OS
The software will be based on Fedora Core 6. Where no explicit version information is provided for software, the version included in FC6 should be assumed.
We will be running a recent kernel (currently 2.6.20.), capable of booting on both the laptop and a more conventional desktop machine.
Interpreters
Perl
Python
Python 2.4 for now. When the laptop transitions to 2.5 (before release in September ?), the server will as well.
Database Servers
MySQL
MySQL will be provided for use by local services. Access will be limited to localhost.
SQLite
SQLite 3 will be provided.
Web Server
Apache 2 will be provided.
Installed modules will include:
- mod_perl
- mod_php
- mod_include
Moodle
Moodle will provide tools for teachers.
Martin Langhoff will help with this once we have an image ?
Moodle may provide a solution for some of the school administration tasks as well.
MediaWiki
MediaWiki will be installed on the server, and made available at: http://schoolserver/wiki/
Content (SJ) will provide default content. How is this packaged and installed ?
MoinMoin
MoinMoin will be installed on the server.
Networking
Trial1 School Network
(printable version)
A single school server will be deployed in these initial installations, simplifying the network. Between two and three wireless mesh network interfaces will be deployed, attached to the school server via USB. Two wired networking interfaces will also be provided, for connection to the Internet via a WiFi interface or DSL, satellite, or 2.5G/3G modem.
Network Interfaces
Currently, we are providing each school server with two wired interfaces, eth0 and eth1. Additional mesh interfaces will be located at msh0/eth2, msh1/eth3, and msh2/eth4. The Fedora network scripts are being used. The interface configuration scripts currently look like:
/etc/sysconfig/network-scripts/ifcfg-wan
DEVICE=eth0 # sn: 002 HWADDR=00:40:63:E9:99:9B # In a real schoolserver, we are likely to DHCP BOOTPROTO=dhcp # Sometimes, a static address is assigned # IPADDR=18.85.46.32 # NETMASK=255.255.255.0 # NETWORK=18.85.46.0 # BROADCAST=18.85.46.255 # GATEWAY=18.85.46.1 ONBOOT=yes DHCP_HOSTNAME=schoolserver1
/etc/sysconfig/network-scripts/ifcfg-lan
DEVICE=eth1 # sn: 002 D-Link DFE-530TX+ HWADDR=00:19:5B:68:9D:4E IPADDR=10.0.0.1 NETMASK=255.255.0.0 NETWORK=10.0.0.0 BROADCAST=10.0.255.255 ONBOOT=yes
/etc/sysconfig/network-scripts/ifcfg-msh0
# Marvell mesh network module, mesh side # (this device also appears as ethN+2) DEVICE=msh0 # Ideally, this would work: # MACADDR=00:17:C4:00:00:01 IPADDR=10.2.0.1 NETMASK=255.255.0.0 NETWORK=10.2.0.0 BROADCAST=10.2.255.255 ONBOOT=yes iwconfig msh0 channel 11 iwconfig msh0 mode ad-hoc iwconfig msh0 essid olpc-schoolserver1
/etc/sysconfig/network-scripts/ifcfg-eth2
# Marvell mesh network module, infrastructure mode side # (this device also appears as mshN-2) DEVICE=eth2 MACADDR=00:17:C4:00:00:01 ONBOOT=yes
The ad-hoc side of the Marvell wireless network interface is brought up only to assign a new MAC address to the Marvell modules being used by the School server. They are development boards, and don't have the "proper" MAC address prefix for the laptops to associate with. With the current driver, this MAC address reassignment can only be done on the ad-hoc interface, not the mesh interface.
Filtering & Masquerading
Network Address Translation (NAT) and Port Address Translation will be provided on the network interface connecting to the Internet. These mechanisms allow all of the laptops in the school to share a single IP address. Fedora's native iptable startup script is used, which relies on two configuration files: /etc/sysconfig/iptables-conf (which identifies modules to load and the behavior of the startup script -- we don't ever save out the running configuration) and /etc/sysconfig/iptables.
The current firewall provides NAT functionality. Devices on the LANs (wired or mesh) may initiate outgoing connections. Tracked protocols (those which the NAT understands and supports) include:
- FTP
- IRC
- SIP
- PPTP
- H.323
Incoming traffic to the school server from the WAN (Internet) is allowed on the following ports:
- SSH (22)
- HTTP (80)
- HTTPS (443)
Incoming traffic to the school server from the LANs (wired or mesh) is allowed on the following ports:
- SSH (22)
- HTTP (80)
- HTTPS (443)
- DNS (53)
- BOOTP (67/68)
- NTP (123)
- RNDC (953, used by mesh portal protocol)
- in addition, select ICMP packets are accepted
The /etc/sysconfig/iptables file is currently:
# iptables for schoolserver firewall # Trial1 version # # OLPC, March 2007 *nat :PREROUTING ACCEPT [0:0] :POSTROUTING ACCEPT [0:0] :OUTPUT ACCEPT [0:0] -A POSTROUTING -o eth0 -j MASQUERADE COMMIT *filter :INPUT DROP [0:0] :FORWARD DROP [0:0] :OUTPUT ACCEPT [0:0] :allowed_icmp - [0:0] -A INPUT -i lo -j ACCEPT -A INPUT -i eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT -A INPUT -i eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT -A INPUT -i msh0 -m state --state RELATED,ESTABLISHED -j ACCEPT -A INPUT -i eth1 -p udp -m udp --dport 53 -j ACCEPT -A INPUT -i eth1 -p tcp -m tcp --dport 53 -j ACCEPT -A INPUT -i msh0 -p udp -m udp --dport 53 -j ACCEPT -A INPUT -i msh0 -p tcp -m tcp --dport 53 -j ACCEPT -A INPUT -i msh0 -p udp -m udp --dport 953 -j ACCEPT -A INPUT -p tcp -m tcp --dport 22 -j ACCEPT -A INPUT -p tcp -m tcp --dport 80 -j ACCEPT -A INPUT -p tcp -m tcp --dport 443 -j ACCEPT -A INPUT -i eth1 -p udp -m udp --dport 123 -j ACCEPT -A INPUT -i msh0 -p udp -m udp --dport 123 -j ACCEPT -A INPUT -i eth1 -p udp -m udp --sport 68 --dport 67 -j ACCEPT -A INPUT -i msh0 -p udp -m udp --sport 68 --dport 67 -j ACCEPT -A INPUT -p icmp -j allowed_icmp -A INPUT -d 255.255.255.255 -j DROP -A INPUT -d 224.0.0.251 -j DROP -A INPUT -j LOG -A INPUT -j DROP -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT -A FORWARD -i eth1 -m state --state NEW -j ACCEPT -A FORWARD -i msh0 -m state --state NEW -j ACCEPT -A FORWARD -p icmp -j allowed_icmp -A FORWARD -d 255.255.255.255 -j DROP -A FORWARD -d 224.0.0.251 -j DROP -A FORWARD -j LOG -A FORWARD -j DROP -A OUTPUT -o lo -j ACCEPT -A OUTPUT -j ACCEPT -A allowed_icmp -p icmp -m icmp --icmp-type 8 -j ACCEPT -A allowed_icmp -p icmp -m icmp --icmp-type 0 -j ACCEPT -A allowed_icmp -p icmp -m icmp --icmp-type 4 -j ACCEPT -A allowed_icmp -p icmp -m icmp --icmp-type 11 -j ACCEPT -A allowed_icmp -p icmp -m icmp --icmp-type 3 -j ACCEPT -A allowed_icmp -p icmp -m icmp --icmp-type 12 -j ACCEPT COMMIT
We are logging dropped packets, to aid in debugging, yet the very common broadcast and multicast packets are dropped before logging to avoid overwhelming the log.
Doubtlessly there are ports we should have open, but don't. Send your requests to server-devel AT laptop.org.
I still need to wire squid into forwards with a dport of 80. These are redirected to the school server's port 3128, where the Squid HTTP cache will be listening.
Forwarding was enabled by editing /etc/sysctl.conf to be:
# OLPC School server Kernel sysctl configuration file # # Forward packets net.ipv4.ip_forward = 1 # Perform source route verification net.ipv4.conf.default.rp_filter = 1 # Do not accept source routing net.ipv4.conf.default.accept_source_route = 0 # Controls the System Request debugging functionality of the kernel kernel.sysrq = 0 # Controls whether core dumps will append the PID to the core filename. # Useful for debugging multi-threaded applications. kernel.core_uses_pid = 1 # Controls the use of TCP syncookies net.ipv4.tcp_syncookies = 1
Mesh Portal
The server functions as a mesh portal on the mesh networks it is a member of.
It does this using the following server, mpp_server.py:
#!/usr/bin/python
# derived from mpp.py, from Marvell/cozybit
import socket, traceback, commands
ANY_MPP_IP="192.168.2.99"
MPPREQ_PORT=953
host =
port = MPPREQ_PORT
dnss='172.16.0.1'
mesh_iface_a='msh0'
mesh_addr_a='10.2.0.1'
mymessage_a='IPv4-0\n' + mesh_addr_a + '\n' + dnss + '\n '
# Start MPP functionality at firmware
commands.getoutput('echo 1 > /sys/class/net/' + mesh_iface_a + '/libertas_mpp')
# Alias ANY_MPP_IP to the mesh interface
print commands.getoutput('ifconfig ' + mesh_iface_a + ':0 ' + ANY_MPP_IP)
# Start the mppreq server
s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
s.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
s.bind((host, port))
while 1:
try:
message, address = s.recvfrom(8192)
print "MPPREQUEST from:", address
s.sendto(mymessage_a, address)
except (KeyboardInterrupt, SystemExit):
raise
except:
traceback.print_exc()
Routing
The server will be tasked with routing between the different network segments attached to it. These include:
- Between one and three mesh network segments
- A wired network segment, which may include standalone APs.
- An optional wireless segment using the server as the AP ?
Bridging vs. Routing
While there is a temptation to declare the individual network segments part of the same subnet and bridge between them, it was instead decided to declare them individual subnets and route between them. The main outcome of this being that broadcast and multicast packets will not be relayed between wireless mesh segments. In cases where it is determined that this poses a problem, we may explicitly route some multicast packets between mesh segments.
DHCP
DHCPD will be provided on all network segments except the one connected to the WAN.
Devices on the 'internal' network will be assigned non-routable IP addresses, in the 10.0.x.x range.
DNS
A local DNS server will be provided to cache common requests, in order to provide better network performance. It may also be used to provide a DNS entry for each laptop, using a DHCP-DNS connection script, or explicit DHCP/DNS server integration.
HTTP Cache
Squid 2.6 will be used for now.
Maintenance & Utility
The following services will be provided:
sshd
Used both for maintenance and as the transport for backups from the laptops.
rsync
Provided as a command line tool, not run as a daemon. Used for backups.
Updating
The School server software will be updated from an OLPC maintained repository, using yum, the package manager in Fedora. While this repository will probably be country/region specific, it currently resides in Cambridge, US.
An software update will be periodically triggered on the school server. Probably weekly ?
For managing the different needs (localisation, applications, configuration) we will either use FAI or slack (or rewrite a tool with similar functionality from scratch ;)
Laptop updates use a separate mechanism, which relies on the school server to provide the update files.
Monitoring
A method for monitoring the health of school servers deployed in the field is still under investigation.