Self-Registration Web Interface for BackupPC ============================================ by Harry Mangalam //Harry Mangalam mailto:harry.mangalam@uci.edu[harry.mangalam@uci.edu] //v0.4, 09 July 2009 // generate HTML with: // export fileroot="/home/hjm/nacs/webbackuppc/WebBUPC_Planning_Doc"; asciidoc -a toc -a numbered ${fileroot}.txt; scp ${fileroot}.* moo:/home/hjm/public_html Introduction ------------ This document describes: * some advantages and disadvantages of using a web interface that allows clients to self-register and self-administer their backups using http://backuppc.sourceforge.net[BackupPC] as the server software. * how this system works, including modifications and additions that have to made to both the server and client sides. This project was undertaken as a test case to try out the http://turbogears.org[Turbogears web development platform] in preparation for a larger project. It turned out to be a fairly smooth project, but it's a little schizophrenic as BackupPC is http://en.wikipedia.org/wiki/Perl[Perl]-based and Turbogears is http://en.wikipedia.org/wiki/Python_(programming_language)[Python]-based. Nevertheless, I believe it has some value. Below I describe what the web interface does, why it does it, and what you should be aware of. What is it for? --------------- http://backuppc.sourceforge.net[BackupPC] is an http://en.wikipedia.org/wiki/OpenSource[Open Source], disk-based backup service written in Perl that runs on a *nix server and uses some neat features to backup specified directories on groups of computers running a variety of Operating Systems. The web interface I'm describing currently works with MS Win2K, WinXP, and WinVista (the latter with minor client-side changes)., Those are the the most popular Desktop OSs in our environment, but BackupPC also works with MacOSX and Linux and while those systems are even easier to support, they are less popular at UCI. Therefore, the web interface was initially targeted at Windows, but a new interface that includes MacOSX and Linux is underway and the mechanism for installing the client software for both those platforms is well-characterized and considerably simpler than with Windows. BackupPC is useful for short-term backups - up to months - to prevent catastrophic loss of data if the client disk crashes or if the PC walks away (increasingly more likely with more people using laptops). In our environment, it is especially targeted at researchers whose entire intellectual corpus may be on their hard disk - their publication record, email, lab & personnel records, scientific results, presentations, and especially their in-progress grants. The loss of this data really would be quite serious. After personally using BackupPC for a while, I very much like the architecture and performance (even with multi-user servers), was very impressed by the protocol options, and REALLY liked that clients could restore their backups by themselves, but was concerned that it was too complicated for a 'mere human' to install on a Windows machine. Hence this Web interface. How does it work? ----------------- The short version ~~~~~~~~~~~~~~~~~ For Windows (2k, XP, Vista) ^^^^^^^^^^^^^^^^^^^^^^^^^^^ * Fill out the web interface. * Click the submit button. * You get an email with a 1MB zip file containing the entire installation (usually*). * Unzip the zip file to create C:\rsyncd * cd into the C:\rsyncd directory. * run the installation batch/bat file. * That's it (usually*). For MacOSX & Linux (very soon) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ * Fill out the web interface. * Click the submit button. * You get an email with a small zip file containing the entire installation (usually*). * unzip it into a temporary dir * run the installation shell script as sudo root * That's it (usually*). \* Due to individual configuration changes wanted, non-standard firewall configuration, and occasional missing DLLs, about 1/5 of the installs done so far have required intervention or correction. As we install on more clients, we will get a better idea of what the usual configuration state is. Also, some email systems will strip zip files from emailo attachments due to security concerns. This transfer can be re-written to email only the URL, and login info to download the same zipfile from the server. The long version ~~~~~~~~~~~~~~~~ For Windows (2k, XP, Vista) ^^^^^^^^^^^^^^^^^^^^^^^^^^^ Windows is the most troublesome platform, but the following also describes the approach for MacOSX and Linux clients. * Fill out the form - Agree to the Service Level Agreement (SLA - a 'strawman' version is included) - Fill in the IP # and client hostname of the registering computer. The form auto-populates the values via a host lookup, but they can be erased and filled in with other values if a computer support person is filling out the form for others. If the IP # of the client is set dynamically, the user is asked to set a uniquely identifying hostname *NOTE TO SELF: which must be checked before being used*. Many DHCP hostnames refer to network and IP number ('dhcp-125.english.uci.edu') whereas we want one that we can use to map it more uniquely, perhaps a combination of username and favorite pet/movie/book/city ('churchill_fluffypoo.english.uci.edu'). - Whether the PC IP # assignment is static or DHCP. If 'DHCP' is selected, additional functionality is added to the client package to track changes in the assigned IP, so the machine will continue to be backed up even if its IP # changes. *NOTE TO SELF: maybe this option should be moved above the preceding one? Also, is it possible to portably test whether this is the case?? checking '/etc/network/interfaces' on Linux? * - what Operating System and Version to support. Currently, the only distinction that matters is Win2K, WinXP and Vista ( *Any server-side differences between Vista and XP?* ). The new interface offers the 2 most recent versions of MacOSX ('Tiger' and 'Leopard') and several Linux distributions (altho whether different versions will be necessary remains to be seen). - What directory you want backed up. For Windows, you have restricted options. Either you can back up your existing *C:\Documents and Settings* or *C:\Users* dirs or choose *C:\Data* or *C:\Backup*. This is to prevent you from choosing the entire *C:\ drive*, which in most cases is mostly Applications and Operating System files. The point is not to back up *all* files, but only those that cannot be easily replaced. For MacOSX and Linux, you can choose the directory, but do so carefully. For multi-user machines, the */home* and */etc* directories are recommended, but note that ALL files not explicitly excluded will be backed up. *Examine the 'rsync.exclude' file carefully.* - Provide contact info, and a login name/password to interact with the server. You can use your UCINetID, but don't use the corresponding password. Only [a-zA-Z0-9_] are allowed for for logins. DO NOT use a full email address ('@' will cause problems - *NOTE TO SELF: this should be checked on submission*). - Click the *Submit* button. If anything was wrong, you get sent back to the registration page to correct it; if everything was fine, you get a "Thank You" confirmation notice. *NOTE TO SELF: don't re-check the host lookup - if the user changed it, don't change it back. But do an nslookup on it to see whether it's a real one or not (if it's a DHCP address). * * After a few minutes, you get an email with a 1MB zip file containing the entire installation and complete instructions in text and HTML. * Unzip the file to create *C:\rsyncd* (or *~/rsyncd* on MacOSX and Linux) * Browse or 'cd' into the *rsyncd* directory. * Run the installation script (*winXP_install_rsync.bat* on Win; *install_LinMac_backuppc_client.sh* on Linux/MacOSX) file. You will be prompted for an administrator password to install the scheduled task - this may be a problem if you don't have admin privs on your own machine. * That's it. Once the server has validated your information, it automatically updates the BackupPC files and within 24 hours your PC should be automatically backed up, unless you http://WebBUPC.xxx.uci.edu/cgi-bin/BackupPC_Admin[log in] before then and request an immediate backup (recommended). For Linux Client ^^^^^^^^^^^^^^^^ We assume that each Linux client has a recent, working rsync executable. If it doesn't, the installation script will tell you to install it and then you can rerun the script again. For each Linux client, the server needs to generate 3 files: * rsyncd.conf (generated from the form input) * rsyncd.secrets (generated from form input (backuppc_user:plaintext_password) * rsyncd.exclude (optional, copied from a single multiplatform version) The backuppc client runs under a regular user UID so it can only read things that it should - sensitive system files cannot be read (altho sensitive user files can be if they are not explicitly excluded). If the backup needs exceptions, they should be made by manipulating the appropriate group in /etc/group. The rsyncd.* files above should have the following permissions: -------------------------------------------------------------------------- -rw-r--r-- 1 root root 987 2008-06-18 08:23 rsyncd.conf -rw-r--r-- 1 root root 357 2008-06-18 08:23 rsyncd.exclude -rw------- 1 root root 52 2008-10-15 15:07 rsyncd.secrets <== NOTE!! -------------------------------------------------------------------------- The *rsyncd.conf* file defines how the different backup modules or shares are backed up. Here's the *rsyncd.conf* file that will back up an entire /home dir on Linux or MacOSX -------------------------------------------------------------------------- # GLOBAL OPTIONS log file=/var/log/rsyncd pid file=/var/run/rsyncd.pid # the following line 'auth users' is not a real login user. This is the ID that the # rsync server and client have agreed to use to allow rsyncs back and forth. auth users = user_from_form # the 'secrets file' contains the CLEARTEXT passwords of the 'auth users' group # so it MUST NOT be readable by everyone. secrets file = /etc/rsyncd.secrets # the 'dont compress' line contains regexes for files that should not be compressed dont compress = *.gz *.tgz *.zip *.z *.rpm *.deb *.iso *.bz2 *.tbz *.exe # MODULE OPTIONS [home] comment = The complete /home dir (all users) # Note that everything in /home will be read by the uid defined # below. If that user doesn't have sufficient privs, the backup will just # skip the file/dir. Adjust required privs to the user by adding that user # to an appropriate group in '/etc/group' path = /home use chroot = no max connections=1 lock file = /var/lock/rsyncd # the default for read only is yes... read only = yes list = yes # the uid/gid should be that of a regular user so we don't accidentally read private data uid = backuppc gid = backuppc # this sets a universal exclude, but each Module (or share) can have its own exclude file. exclude from = /etc/rsyncd.exclude strict modes = yes # 1st we deny all hosts hosts deny = * # then allow ONLY the BackupPC server. Files will be read only if # 1 - a request comes from the BackupPC server IP # 2 - the auth matches # 3 - an rsyncd (with the correct auth) is running on the client # 4 - the files have ownership and privs that allows the backuppc user to read them hosts allow = ###.###.84.82 ignore errors = no ignore nonreadable = yes transfer logging = yes timeout = 600 refuse options = checksum dry-run -------------------------------------------------------------------------- Installation Problems noted --------------------------- * as noted above, if you submit a User ID that is an email address or contains the '@' character, everything will appear to install, but the rsync connection will fail. *This must be checked on the server side at Submission time.* * in a few cases on WindowsXP, the *netsh* script that is executed to set up the firewall parameters will fail, citing the absence of *framedyn.dll*. This Dynamic Link Library should be present on all Windows machines but sometimes the search path has not been set to include it. http://support.microsoft.com/kb/319114[This Microsoft page] tells you how to address this. * if you change, move, rename, or delete the files *rsyncd.conf* or *rsyncd.secrets* file, the backup may fail due to configuration and/or authorization problems. If you know what you're doing, you can change your configuration to be more to your liking, but make copies of these files before you edit. To prevent backing up confidential files, you can edit the file *rsyncd.exclude* which defines file types to ignore (files matching the patterns therein will NOT be backed up). * If you selected *C:\Data* or *C:\Backup* as the target directory and did not create them before the backup is initiated, then (unsurprisingly) the backup will fail. Day to day usage ---------------- Once the client software is installed, you can either wait for the server to initiate a backup or you can log into the http://WebBUPC.xxx.uci.edu/cgi-bin/BackupPC_Admin[BackupPC web admin page] and initiate a backup yourself (advised). The 1st run will do a complete backup of the requested directory tree, taking a time proportional to the size of the directory. Successive backups will take time proportional to the changed files (the backup protocol is rsync). As an example, my home dir is about 43GB, but after subtracting mp3s, pictures, and Virtualbox partition, there are only about 12GB to be backed up, which took about 35m. The time taken to do an incremental backup was less than 2 min over a 100Mb connection, most of that time exchanging rsync comparison data. The slowdown on my system (a 1.6GHz, 2core laptop) when doing the backup is almost undetectable unless I'm doing a lot of other disk activity. Remaining known issues ---------------------- * If you make an error filling out the registration page, you are returned to the original registration page and the form again auto-populates the client PC IP # and hostname of the PC from which you're working, even if you've set it to something different the 1st time. Bug or feature? * One login name can be used to create packages for other PCs, but you can't create multiple packages for one PC. This is a feature - if we allowed this, anyone could essentially delete a PC from the backup schedule. If you need to delete a PC and start over, an administrator has to step in to delete the PC from the database. This is one of the few times administrative intervention is needed. * If one login is used to set up multiple PCs, that login is the only one allowed to 'self-administer' the PCs via the normal BackupPC web interface. This was done to allow a group administrator to oversee a number of PCs with one login. This feature should be used only if the regular user is unable or unwilling to do it. Server Changes required for the auto-registration mechanism ----------------------------------------------------------- Owners and Permissions ~~~~~~~~~~~~~~~~~~~~~~ BackupPC normally runs under a non-root user and group (normally *backuppc* for both) and stores its configuration files in /etc/BackupPC. Because of the web interaction, the backuppc group must include the web user (often www-data) so the cgi script can write new configuration files into that directory. The additional options that the web form allows requires some additional directories to be created in the root (/etc/BackupPC) dir beyond those created by a standard BackupPC installation Handling Dynamic IPs ~~~~~~~~~~~~~~~~~~~~ An increasing number of people are using laptops as their main computer. Such machines often connect using dynamic IP assignment (DHCP) so that their IP number can vary from day to day. The feature that allows BackupPC to back up even such roving PCs requires the creation of a new directory (/etc/BackupPC/alive) to hold the periodic IP updates. This directory is populated by the client machines periodically sending their current IP #s to the server via a restricted, constricted (low bandwidth connection) rsyncd process running on the server. On MacOSX (M) and Linux (L), if the client is registered as DHCP, it will get a few additional bits of code that * adds a line to the crontab to run the update script (*imalive.py*) * *imalive.py* generates a tiny, uniquely named file that contains the current client IP # * *imalive.py* sends that file back to the server via rsync. Every X minutes (15 is the default), the server runs a cron script that checks to see if any DHCP info has changed and if so, stream-edits it into the server's /etc/hosts file between identifying fencepost markers, as below ------------------------------------------------------------------ 20 #### BackupPC hosts BEGIN - DO NOT MODIFY THIS LINE #### 21 ###.###.###.147 flip.xxx.uci.edu flip 22 ###.###.###.231 jackrabbit.xxx.uci.edu jackrabbit 23 ###.###.###.148 flop.xxx.uci.edu flop 24 ###.###.###.8 tatry.xxx.uci.edu tatry 25 ###.###.###.144 flipper.xxx.uci.edu flipper 26 ###.###.###.31 haggis.xxx.uci.edu haggis 27 ###.###.###.211 mmg-dhcp77.xxx.uci.edu mmg-dhcp77 < 'real' hostname=fredo 28 #### BackupPC hosts END - DO NOT MODIFY THIS LINE #### ----------------------------------------------------------------- These entries, being in the /etc/hosts file, pre-empt the 'official' hostname <-> IP mapping of the client machine. This should bypass the requirement of 'making up' a unique hostname, but may saddle the user with a hostname that no relationship to the name that the user gave it or thinks of it as (see fredo example above). We may be able to address this with more sophisticated web forms, but for now, I'm going to just keep the DHCP-supplied hostname and have the user make one up that will be used here. Security Concerns FAQ --------------------- BackupPC and our web interface to it are not highly secure. They are meant to provide Backup services in a fairly protected environment (local networks, not Enterprise WANs) Because of this, the default configuration provides for reasonable security but not full end-to-end encryption and encrypted storage. A determined, talented attacker should be able to read BackupPC data over the wire, but over modern switched wired networks this should not be trivial. Note that for security and bandwidth constraints, wireless networks *should not* be used as a communication channel for BackupPC. We can certainly add ssh encryption to the protocol, but it's not being done now. Because our implementation of BackupPC uses rsync as the transfer protocol, any security weakness of rsync also applies to BackupPC. The web registration form constrains Windows clients to use the *C:\Documents and Settings* directory or a (probably) new *C:\Data* or *C:\Backup* dir in part to make them copy data to that dir to be backed up so that they will not inadvertantly back up sensitive data. The http://moo.nac.uci.edu/~hjm/rsyncd.exclude[current 'exclude' list] lists the default file types that are excluded. The client-side configuration files included with the installation package allow an interested client to manipulate many of the rsyncd parameters. She could increase the directories to back up, enable backing up normally excluded files (such as her MP3 collection, tax returns, and in fact her entire disk, OS included.) However, this would show up on a quota scan and the BackupPC administrator could suspend her backups and/or delete her stored backups. The *imalive.py* script sends small files back to the server via an bandwidth-constrained (1kB/s) rsyncd process. A normally registered, but malevolent client could configure his client to send a stream of data back to the server to slowly fill up the root file system and therefore crash the server. At this point in the development process, I haven't added a check for that (is the *imalive* dir larger than X bytes), but it could easily be added to the *imalive.py* script. Question & Answers ------------------ These Q&As are answered to the best of my ability. Please correct them if you find an error or mistaken assumption. ====================================================================================== Q: If a person fills out a form for another PC, can that person 'subvert' the other PC? A: Only if the owner of the target PC copies and installs the customized package for the target PC. The owner would normally not get the client package emailed to them or if they did and they didn't know what it was, they wouldn't normally(?) follow the directions to install something they didn't ask for. If the person who filled out the form for another PC was doing so in a support role, the administrative owner of the PC would still have to agree to allow the client software to be installed. ====================================================================================== ====================================================================================== Q: Could a cracker provide a doctored download package to the client? A: Yes, but they would have to also find a way to introduce it to the target PC and run the installation scripts. They could do this via social engineering, for example. ====================================================================================== ====================================================================================== Q: Is the rsync stream readable in transit? A: As it's written now, yes, altho with switched networks, this should be less of a problem. In addition, the rsync stream is not a linear stream of files, so while it's possible, it's not trivial. This protocol should not be used for backing up clients over unencrypted wireless networks where all communication streams are 'broadcast'. ====================================================================================== ====================================================================================== Q: What changes are made to the client PC? A: on WinXP, a *.bat* file is run by the user to install the package. It installs the Cygwin DLL & rsync as a Windows Service, pokes a hole in the Windows firewall for port 873 (the default rsync port), and allows a specific rsync server to request backups of the share selected during the registration. It leaves the *rsync.secrets* file in the C:\rsyncd directory, which contains the *unencrypted rsync password* to the server. If the PC is identified as a DHCP client, it also installs a scheduled task using 'schtasks' to send the IP number of the server to allow for changing IP #s (the server checks for updated IP#s before attempting a backup). It does not install ssh on the client to use as an encryption tunnel, altho this could be done. ====================================================================================== ============================================================================================ Q: Will the zip file email attachment interfere with the delivery of the notification email? A: It could, depending on how you've set up your anti-virus and email-scanning software. Some scanning software doesn't allow zipped attachments; some don't allow binaries inside of zipped attachments. There are some work-arounds, but they require a re-write of the server software to send the minimum info (as text files) and to download the rest via URL. ============================================================================================ ====================================================================================== Q: What sensitive information resides on the server? A:The per-PC configuration files contain the *cleartext password* for client rsync services, so you must be very careful to keep this directory readable only by the backuppc user. Also, the client files can be read by the root user and anyone who has sudo privs on the server, so it's strongly recommended that the server be dedicated to the BackupPC service or at least that it is not used for shell login by many people. This is not specific to the web interface, but is also the case with the native BackupPC configuration. ====================================================================================== ====================================================================================== Q: Will the server back up my sensitive files? A: It will back up everything in the directory that you specify (ie *C:\My Documents*). The program of course makes no distinction as to whether they're sensitive or not. It will ignore all the files you tell it to ignore via the *C:\rsyncd\rsync.exclude* file which lists the types of tiles to exclude. This file is editable to increase the kinds of files to ignore. It uses http://www.wikipedia.org/Regular_Expressions[regular expressions] to define filename patterns to ignore. ====================================================================================== Server PreRequisites -------------------- * a unix-like OS. BackupPC runs on BSD & Solaris, but most instances run on Linux. The current Long Term Support Ubuntu distribution of Linux (8.04) is what we're using. * root privs on the server. * reliable storage - most users use at least RAID5 (preferably RAID6) to provide some redundancy to the storage. It should be noted that BackupPC is not typically used for long term or archival storage so it does not require elaborate multi-level storage systems. * enough hard disk space to store the client files. BackupPC is fairly efficient about pooling files, but you should assume about 2 times the amount of disk space for each client due to incremental backups and overhead. * sufficiently fast network connections to service the clients. You may want to use multiple interfaces to enable connections to multiple networks simultaneously. * the apache web server to provide BackupPC services (requests for file restores, initiating off-schedule backups, etc). * a recent version of BackupPC installed and verified that it can back up a client or two. * the Python & a recent Turbogears 1.x runtime requirements to handle the registration form - python version 2.3 or greater - cherrypy - kid templates - SQLAlchemy - SQLite3 * the *todos* utility to convert unix End-Of-Lines to DOS. * the WebBUPC package, either as a tarball or pulled from the Subversion repository. Setup ----- I'm going to assume that you're using the Ubuntu 8.04 LTS release. * Install in order, apache2, backuppc, python, python-turbogears, sqlite3 * the backuppc user should be created when you install backuppc, but if not, create it. * add the www-data user to the backuppc group.so the cgi can write to the backuppc-owned dir. * configure the backuppc instance to use rsync, rest of configurations (include local config file) with the package & add it to backuppc dir of SVN. * download the webbupc pkg or pull from SVN. * unpack the WebBUPC tarball or move it to it's final resting place. * use supplied BackupPC.config as template to configure the BackupPC server. * change the server IP number and port in dev.cfg and start the form server to answer requests on the port you've requested. * create the appropriate subdirs in /etc/BackupPC. the ones needed are: - *alive* holds the most current info for the DHCP-allocated IP#s. The file names indicate the hostname and user of the machine. The contents of each file is the naked IP number of the host. - *backup* simply contains backups of files that get changed automatically, in case something goes wrong and I have to restore the info. - *pc* is a standard BackupPC directory that contains customized configuration lines (as Perl code) for each client. - NB: the 'backuppc' user below is completely separate from any login user. it is the username that the user chooses when filling in her webbupc form (possibly their UCINetID) The rsyncd.conf file requires the "auth users = xxxxx" line to refer to that user, the same one as in the rsyncd.secrets file, with the same passwd. Files created / modified by BackupPC and WebBUPC ------------------------------------------------ ------------------------------------------------------------------------- /etc |-- hosts <- BackupPC DHCP hosts added between fenceposts |-- crontab <- entry for running /etc/BackupPC/alive/alive.py | [3,18,21,33,48 * * * * root cd /etc/BackupPC/alive && ./alive.py ] `-- BackupPC |-- LOCK |-- README_apache |-- config.pl <- BackupPC configuration file (Perl syntax) |-- etchosts <- interim file of data inserted into /etc/hosts |-- hosts <- BackupPC hostname list with IP type, declared user |-- htpasswd.4.backuppc <- for BackupPC web interface (encrypted passwords) |-- rsyncd.lock |-- rsyncd.secrets <- includes CLEARTEXT passwd (RW only BUPC admin user) | |-- alive <- contains IP#:hostname mapping info | |-- alive.py <- for processing the alive files, see crontab entry above | |-- flip.xxx.uci.edu_hjmangalam_dhcp | |-- flop.xxx.uci.edu_hjmangalam_dhcp | |-- | |-- haggis.xxx.uci.edu_hjmangalam_dhcp | |-- jackrabbit.xxx.uci.edu_mlwaterm_dhcp | `-- tatry.xxx.uci.edu_tsoeller_dhcp | |-- backup <- contains backups for debugging; created by alive.py | |-- etchosts.20081017T123806 | |-- etchosts.20090122T155833 | |-- etchosts.20090123T154801 | |-- etchosts.20090123T160301 | |-- hosts.20080420T180006 | |-- hosts.20080420T180950 | |-- hosts.20090120T093145 | |-- hosts.20090120T161744 | |-- hosts.20090121T122344 | |-- htpasswd.4.backuppc.20080420T180006 | |-- htpasswd.4.backuppc.20080420T180950 | |-- rsyncd.secrets.20090120T093145 | |-- rsyncd.secrets.20090120T161744 | `-- rsyncd.secrets.20090121T122344 | `-- pc <- contains config files for each client | all files have to be owned by user.backuppc user/group. | [If root wrote them, backuppc can't read them] |-- LOCK |-- aries.xxx.uci.edu.pl |-- athina.xxx.uci.edu.pl |-- bongo.xxx.uci.edu.pl |-- cg1.xxx.uci.edu.pl |-- flip.xxx.uci.edu.pl $Conf{RsyncdUserName} = "dubya"; |-- kenyi.xxx.uci.edu.pl ie...... $Conf{RsyncdPasswd} = "thegreat1"; |-- flop.xxx.uci.edu.pl $Conf{RsyncShareName} = [BACKUP]; |-- jackrabbit.xxx.uci.edu.pl |... etc |-- palisade.xxx.uci.edu.pl |-- philia.xxx.uci.edu.pl |-- pinch2.xxx.uci.edu.pl |-- psatarri.xxx.uci.edu.pl `-- tatry.xxx.uci.edu.pl -------------------------------------------------------------------------