Upgrade server: Difference between revisions
(Basic upgrade-server installation information.) |
DanielDrake (talk | contribs) No edit summary |
||
(4 intermediate revisions by 3 users not shown) | |||
Line 1: | Line 1: | ||
{{Software}} |
|||
<b><font color=red><big>upgrade-server was never officially released. If you want to run a local server for [[olpc-update]], we currently recommend [[XS-rsync]] via the school server.</big></font></b> |
|||
{{Dated}} |
|||
These are basic instructions for installing an upgrade server. This feature is available for testing but is not yet released. |
These are basic instructions for installing an upgrade server. This feature is available for testing but is not yet released. |
||
Line 11: | Line 16: | ||
$ cd ~ |
$ cd ~ |
||
$ mkdir builds |
$ mkdir builds |
||
$ git |
$ git clone git://dev.laptop.org/users/cscott/upgrade-server |
||
Make sure that /home/upserv/upgrade-server/upserv.py has: |
Make sure that /home/upserv/upgrade-server/upserv.py has: |
||
Line 42: | Line 47: | ||
* Some versions of inetd/xinetd, used to run the upgrade server, generate an AUTH request when you connect, so an ident server on the system running rsync may be helpful, Debian package ''oidentd'' is sufficient. |
* Some versions of inetd/xinetd, used to run the upgrade server, generate an AUTH request when you connect, so an ident server on the system running rsync may be helpful, Debian package ''oidentd'' is sufficient. |
||
== How the upgrade server works == |
|||
The upgrade server downloads builds on demand and installs them in a 'builds' directory. It then garbage-collects old builds from 'builds' to maintain the size of the build directory at a specified size (16GB by default). It deletes the build "last accessed the longest time ago", except if the build has a special "sticky" file present, which will cause that build to be preserved from collection. |
Latest revision as of 17:06, 19 February 2011
upgrade-server was never officially released. If you want to run a local server for olpc-update, we currently recommend XS-rsync via the school server.
These are basic instructions for installing an upgrade server. This feature is available for testing but is not yet released.
The source code for the updates server is available at:
From a basic Debian etch installation, the following will yield a functioning updates server:
# apt-get install xinetd rsync git-core python2.5 file fakeroot bzip2 zip unzip # adduser upserv # passwd -l upserv # su upserv $ cd ~ $ mkdir builds $ git clone git://dev.laptop.org/users/cscott/upgrade-server
Make sure that /home/upserv/upgrade-server/upserv.py has:
UPSERV_DIR = "/home/upserv/builds" EXTRACT_BUILD = "/home/upserv/upgrade-server/extract-build.sh"
As root, create a new /etc/xinetd.d/rsyncd file:
# default: off # description: The rsync server is a good addition to an ftp server, as it \ # allows crc checksumming etc. service rsync { disable = no socket_type = stream wait = no user = upserv group = upserv groups = yes server = /home/upserv/upgrade-server/upserv.py server_args = server # log_on_failure += USERID # this invokes identd, which is often unfriendly per_source = UNLIMITED }
Change the localhost line in /etc/hosts to:
127.0.0.1 localhost updates updates.laptop.org
Restart xinetd.
# /etc/init.d/xinetd restart
- Some versions of inetd/xinetd, used to run the upgrade server, generate an AUTH request when you connect, so an ident server on the system running rsync may be helpful, Debian package oidentd is sufficient.
How the upgrade server works
The upgrade server downloads builds on demand and installs them in a 'builds' directory. It then garbage-collects old builds from 'builds' to maintain the size of the build directory at a specified size (16GB by default). It deletes the build "last accessed the longest time ago", except if the build has a special "sticky" file present, which will cause that build to be preserved from collection.