Gna admin docs stripped of hardware/security related details. Were kept only what is useless to get a installation like Gna running. 1 Introduction ************** A word about this documentation: please keep it simple, short, readable, and... up-to-date! :) The Gna! development platform is currently composed of 3 computers called Lisa, Bart and Maggie, named after the infamous children from The Simpsons cartoon serie. * Lisa takes care of CVS, download area, project homes (web) area. * Bart takes care of the web frontend, the database and the mail relay (including lists). * Maggie takes care of her brother and sister by doing backups, integrity checking and providing shell accounts to Gna! people, and finally an apt repository. This documentation is part of the debian package build from the 'admin' project CVS. It is built from a simple collection of text files kept in admin/doc. This page was built 2005-09-22 09:57:36 by yeupou on maggie. 2 Common Information ******************** 2.2 backups =========== There are two backup subsystems taking care of the Gna! platform, a local one and a remote one. The local one is meant to provide a fast way to restore a broken machine or service, but has a limited capacity (currently around 100GB, which is about 50 days worth of backlog as of today), and limited redundancy safety (plain IDE, no RAID, and it is physically next to the machines it is backuping). The remote backup is meant to protect from physical accidents in the place where Gna! is hosted, and is expected to host a wealth of data (terabytes, being disks, tapes, DVDs, etc). The local backup happens on Maggie. Every day, the bin/bak.sh script is run by cron/bak.maggie, and sequence the following tasks : * First, bak-makespace.pl cmoputes the size of the latest tarball set (ie. the one from the day before), then check if there is enough space on disk to store at least the same quantity of data. If this is not the case, it will try to erase at most 3 tarball sets, starting from the oldest one, until there is enough disk space to proceed. This script is always verbose when it decides to remove something, example : Pass #1: last backup weighted 7018 MB, and we have 5005 MB left on disk #1: removing sql_2004-05-07.tar.gz (1 MB) #1: removing cvs_2004-05-07.tar.gz (540 MB) #1: removing mail_2004-05-07.tar.gz (42 MB) #1: removing ftp_2004-05-07.tar.gz (4095 MB) #1: freed 4678 MB This operation happened on May 20, and since 5GB left on disk was not enough to store at least the expected 7GB, the oldest tarball as removed and thus 4,5GB freed. * Second, bak-get.pl sucks data from Bart and Lisa via rsync, using restricted and decicated 'backup' accounts with a restricted 'backsh.pl' shell on those machines. Authentication happens with SSH's regular PKI. Maggie thus holds a flat mirror of Gna! data on /backup/data. * Finally, bak-compress.pl tar-gzips the folders in /backup/data and put this tarball set in /backup. Currently, a tarball set is made up of 4 parts : cvs, mail, ftp, sql. The remote backup facility runs exactly the same scripts with the same configuration, at a slightly deferred time (a few hours). It is currently hosted by Mekensleep in Paris downtown. ($Id: common.backups,v 1.7 2004/10/06 16:12:08 zerodeux Exp $) 2.5 firewall ============ The firewall configuration is handled and documented in bin/coupefeu.pl. Snippet from the code : # The policy will be: # - incoming connections are allowed only to local services # by allowed machines # - outgoing connections are only allowed to services used # by the system (DNS, web browsing, pop, email....) # - the forward rule denies everything # - all other incoming or outgoing connections are denied ($Id: common.firewall,v 1.6 2005/06/11 16:22:14 yeupou Exp $) 2.11 howto-install-debian-in-chroot-partitions ============================================== * To install Debian/Woody in /chroot/ : (normally, now you want to install Sarge. Replace woody by sarge, everything should work more or less the same) apt-get install binutils debootstrap debootstrap --arch i386 woody /chroot/ * Install some GNU versions of some software, for cohesion sake, plus deborphan, to help avoiding old libs sitting for no reason: chroot /chroot/ apt-get install gawk mailutils deborphan syslog-ng * Some package, installed by default, should be removed, type the following: chroot /chroot/ apt-get --purge remove dhcp-client fdutils info man lilo mbr syslinux tasksel telnet mawk pcmcia-cs (less package on a chroot, less possible holes - check for useless libs using deborphan) * Configure passwd, activate md5, shadow, set timezone to Paris. dpkg-reconfigure passwd dpkg-reconfigure libc6 && tzconfig Make unavailable the root password mv /etc/shadow /etc/shadow.bak cat /etc/shadow.bak | sed s/^root.*/root:\!:12420:0:99999:7:::/g > /etc/shadow * Each chroot got an exim installation. Only the mail system exim config should accept mail for non local interface. Exim installs on the machine that host the mail system must have the following in the smtp routers: self = send Otherwise, sending a mail to the mail.gna.org system would be rejected. How exim should be configured in chrooted system is mentioned in the entry related to the mail system installation. * Syslog-ng needs some tuning. Edit /etc/syslog-ng/syslog-ng.conf and put in comment the following # We do not have xconsole to receive those events! # log { # source(s_all); # filter(f_xconsole); # destination(dp_xconsole); # }; At the same time, the following must be uncommented in /etc/default/syslog-ng: CONSOLE_LOG_LEVEL=2 KERNEL_RINGBUF_SIZE=16392 ($Id: common.howto-install-debian-in-chroot-partitions,v 1.9 2005/06/13 11:04:33 yeupou Exp $) 2.15 howto-upgrade-chrooted-system ================================== Chrooted systems must be kept up to date. The following command, installed in all master systems, will act like apt-get but on any chroot: apt-get-all For instance, upon a security alert you would do : apt-get-all update && apt-get-all upgrade This command comes in /etc/bash_gnap, managed by gnapgnap packages. Indeed, it must be sourced by bash, so the following should be in /root/.bashrc: . /etc/bash.bashrc . /etc/bash_gnap ($Id: common.howto-upgrade-chrooted-system,v 1.6 2005/06/11 16:37:50 yeupou Exp $) 2.16 integcheck =============== Integcheck is a tripwire-like file integrity checker. It was designed for Gna!, but lives happily as a standalone project as 'integcheck' on Gna!. * On Lisa and Bart, a specific user called 'integcheck' is created. useradd -G nogroup -s /usr/local/bin/integcheck.pl integcheck * On Maggie, the counterpart user is created as this: useradd -G nogroup -d /backup/integcheck integcheck mkdir /backup/integcheck chown integcheck.root /backup/integcheck -R chmod 700 /backup/integcheck ssh-keygen -t rsa (no passphrase) * /backup/integcheck/.ssh/id_rsa.pub is copied in the ~/ of integecheck on Bart and Lisa: mkdir -p /home/integcheck/.ssh echo "key" > /home/integcheck/.ssh/authorized_keys chmod 644 /home/integcheck/.ssh/authorized_keys * On Lisa, we add a specific /etc/checklist: #!/usr/bin/perl my @chroots = ("cvs", "download", "homepage", "members"); our @checklist; for (@chroots) { push(@checklist, "/chroot/".$_."/bin"); [...] } This file must have the following rights: chown integcheck.root /etc/checklist chmod 550 /etc/checklist * We do the same on Bart, with the correct @chroots * We add on Maggie the crontab that get the list and compares everyday. (see admin/cron/) ($Id: common.integcheck,v 1.6 2004/05/20 16:38:59 zerodeux Exp $) 2.17 kernel =========== Our policy for kernels on Gna! machines is simple: we stick to Debian/stable stock kernels. Debian is usually reliable enough to provide a secure kernel and our hardware is common enough to be correctly supported by Debian kernels. * Upgrade process When a new kernel is released in Debian/stable (fixing bugs in the currently used ones): - upgrade Maggie and restart it - if everything is fine, do the same for Lisa, then Bart Bart comes last as it handles mails and default www, the stuff we need to communicate. Maggie goes first since it does not handle public services. ($Id: common.kernel,v 1.2 2004/06/10 11:05:28 zerodeux Exp $) 3 Bart Information ****************** 3.1 hardware ============ The disk layout is : Filesystem Size Type Comment /dev/hda1 2G swap Linux 2.4 requires twice as much as RAM /dev/hda5 235M ext2 /boot /dev/hda6 7.5G ext3 / /dev/hda7 7.5G ext3 /home /dev/hda8 14G ext3 /chroot/db /dev/hda9 4.6G ext3 /chroot/www /dev/hda10 18G ext3 /chroot/mail /dev/hda11 20G ext3 /spare (not mounted at boot) It has been purchased, assembled and installed by the FSF France in the first week of january 2004. 3.2 howto-install-db-system =========================== == BASE INSTALL == * First enter the chroot and install the server: chroot /chroot/db apt-get install mysql-server * Make sure it accept network connections, edit /etc/mysql/my.cnf and comment the line: skip-networking * Start it: /etc/init.d/mysql start * Add a user for connection over tcp-ip, by typing the following: mysql mysql mysql> GRANT ALL PRIVILEGES ON * -> to root@xxx.xxx.xxx.xxx ; mysql> UPDATE user SET Password=PASSWORD('xxxxx') -> WHERE Host="xxx.xxx.xxx.xxx" AND User="root" ; (to make that change took into account, restart mysql) * Add a password: mysqladmin password * Finally, make the socket available to Bart ln -s /chroot/db/var/run/mysql /var/run * Additionally, on Bart, we put a symlink from /etc/init.d/db_chroot.sh (part of the gnapgnap-bart package) to /etc/rc2.d to get the whole system starting appropriately. == SAVANE INSTALL == IMPORTANT: all path mentioned are relatives to the chroot environment. Be sure to be logged as root *in* the chroot! * Add in /etc/apt/sources.list of the db system # Savane stable releases deb http://dl.gna.org/savane/debian/ stable/ # yeupou packages deb http://dl.gna.org/savane/debian/ dangerous-yeupou/ * Get the required packages apt-get update && apt-get install savane-database savane-backend-misc * Create the database as described in /usr/share/doc/savane-doc/README.Debian The database has been named savannah (created before Savane get its new name). * While the Savane configuration is created (with the interactive tool), say that you want sv_cleaner and sv_reminder to be activated here. * Create the dumps (backups) directory chroot /chroot/db mkdir /dumps chmod 700 /dumps * Add the appropriate cronjob in /etc/cron.d (in the chroot!), such as: # mysqldumpsavannah run mysql dump 7 5 * * * root /usr/local/bin/myqldumpsavannah > /dumps/savannah.sql 2>&1 * Add the appropriate logrotate entry /dumps/*.sql { rotate 60 daily compress nocopytruncate sharedscripts postrotate /usr/local/bin/myqldumpsavannah endscript } ($Id: bart.howto-install-db-system,v 1.8 2005/06/23 09:23:07 yeupou Exp $) 3.3 howto-install-mail-system ============================= The mail system purpose is to accept mail from the outside for @gna.org and to make local deliveries (alias + mailing list). == BASIC SETUP == * Exim 3 should already been installed. However, exim 3 is a pain to configure by comparison to exim 4. So we'll compile exim 4 in maggie:/usr/src. A source tarball should remain there, with a /debian directory created from scratch inside. (outdated since sarge release!) Once the package built, add it to maggie:/opt/apt-repos-mail, run apt-archives-update and it install it with apt-get on the mail system, which one got deb http://apt.gna.org/debian/ mail all in his apt sources. * Once installed, we need to check some files for the appropriate path: chroot /chroot/mail /etc/init.d/exim /etc/cron.d/exim /etc/logrotate.d/exim * Some configuration value should be set as described here : primary_hostname = gna.org domainlist local_domains = @ : mail.gna.org : mail.attique.org : attique.org qualify_domain = gna.org In "ROUTERS CONFIGURATION", add, before the route "system_aliases:" (ORDER DOES MATTER! this should be just before system aliases working with /etc/aliases) the following router that will allow to have specific aliases depending on the domain, in /etc/aliases.d. system_aliases_specificdomain: debug_print = "R: system_aliases for $local_part@$domain in /etc/aliases.d/$domain" driver = redirect domains = +local_domains allow_fail allow_defer data = ${lookup{$local_part}lsearch{/etc/aliases.d/$domain}} file_transport = address_file In the "REWRITE CONFIGURATION" section, add also the following: # Remove the (.*).gna.org part ^(.*)@.*gna.org ${1}@gna.org frFsbcTtr * Start it /etc/init.d/exim start * Then, remove useless users (gnats, games...). * On Bart, edit xinetd to redirect on the chrooted exim: service smtp_local { socket_type = stream protocol = tcp wait = no user = root bind = 127.0.0.1 port = 25 server = /usr/sbin/chroot server_args = /chroot/mail /usr/bin/exim -bs cps = 100 10 } # External connections: limit incoming rate service smtp_external1 { socket_type = stream protocol = tcp wait = no user = root bind = 213.228.62.10 port = 25 server = /usr/sbin/chroot server_args = /chroot/mail /usr/bin/exim -bs cps = 20 10 max_load = 2.5 per_source = 5 } service smtp_external2 { socket_type = stream protocol = tcp wait = no user = root bind = 213.228.62.13 port = 25 server = /usr/sbin/chroot server_args = /chroot/mail /usr/bin/exim -bs cps = 20 10 max_load = 2.5 per_source = 5 } * On each system but mail system (apart from www, which is expected to send a lot of mails), configure exim (with dpkg: package exim4-config, smarthost, no local mail, choose as system name the name of the chroot, gna.org as visible name) to use mail.gna.org as smarthost (so mail.gna.org deals with queuing; that's an option, using internet site that receives nothing from outside is one another. Currently all systems but the www system use the smarthost option) Configure exim4 to run on queueonly mode in /etc/default/exim4 (apart for the mail system). Hardcode in Runtime configure (in /etc/exim4/exim4.conf.template) - harcoded by because the debian way of doing it end up in problems you do not want to deal with: primary_hostname = SYSTEM.gna.org qualify_domain = gna.org Dont forget to put in comment the second declaration of these, in the same file. Add to the transport "remote_smtp_smarthost" (in /etc/exim4/exim4.conf.template) the following so it's easier to identify origin of the mail (especially useful for cron error messages), replacing SYSTEM by the real system name (like homepage): remote_smtp_smarthost: debug_print = "T: remote_smtp_smarthost for $local_part@$domain" headers_add = "X-Originator-Server: SYSTEM.gna.org (for $local_part.$domain)" # that's the line you add! driver = smtp [...] * The Savane backend is installed inside the chroot, but only sv_aliases is configured to run (/chroot/mail/etc/cron.d/savannah), and sys_mail_aliases is configured as /etc/aliases.d/gna.org instead of /etc/aliases (default). == SPAM FILTERING with spamassassin == (some details related to spamassassin tuning havent been documented) * First, install the necessary tool on the mail system: apt-get install spamassassin * Make sure mail:/usr/local/bin/spamclean.pl, part of the gnapgnap-mail package is there and ready to run. * We update the exim conffile, mail:/etc/exim/exim4.conf In the section "Runtime configuration file for Exim", add: In "ROUTERS CONFIGURATION", add, after the router "dnslookup" (ORDER DOES MATTER! condition stand on one line, without /): spamcheck_router: # When to scan a message : # - it isn't already flagged as spam (I suspect a problem here, as # the command only look for the header, not its value) # - it does not came from local # - it does not came from relay_from_hosts: set by sender IP (not clean but # it works. condition = "${if and { {!eq{$h_X-Spam-Flag:} {YES}} {!eq {$received_protocol}{spam-scanned}} {!eq {$received_protocol}{local}} {!eq {$sender_host_address}{213.228.62.13}} {!eq {$sender_host_address}{213.228.62.10}} {!eq {$sender_host_address}{213.228.62.9}} {!eq {$sender_host_address}{213.228.62.8}} {!eq {$sender_host_address}{127.0.0.1}} }{1}{0}}" driver = accept headers_add = "X-Spam-Checker-Host: mail.gna.org" transport = spamcheck Still in "ROUTERS CONFIGURATION", add, after the router "localuser" (ORDER DOES MATTER! this router should be after non-local and users aliases deliveries, before mailing-list deliveries): # This route will send any mail that got here to the spam list, if # not dealth with by previous routers (assuming users accounts and nonlocal # addresses have been already handled) and with X-Spam-Flag: YES. # This is supposed to be useful only for mailing-lists spammessage: condition = "${if and { {eq{$h_X-Spam-Flag:}{YES}} }{1}{0}}" driver = redirect data = spam@gna.org file_transport = address_file pipe_transport = address_pipe In "TRANSPORTS CONFIGURATION", add: # http://dman13.dyndns.org/~dman/config_docs/exim-spamassassin/node12.html spamcheck: driver = pipe command = /usr/bin/exim -oMr spam-scanned -bS use_bsmtp = true transport_filter = /usr/bin/spamc home_directory = "/tmp" current_directory = "/tmp" user = mail group = mail log_output = true return_fail_output = true return_path_add = false message_prefix = message_suffix = * We'll also use razor and pyzor with spamassassin: apt-get the packages pyzor and razor. Create the file /etc/mail/razor/razor-agent.conf with the following as content: razorhome = /etc/mail/razor/ logfile = /var/log/mail.razor Then run: pyzor --homedir /etc/mail/pyzor discover razor-admin -home=/etc/mail/razor -discover add in /etc/mail/spamassassin/local.cf use_pyzor 1 pyzor_options --homedir /etc/mail/pyzor use_razor2 1 razor_config /etc/mail/razor/razor-agent.conf score RAZOR2_CF_RANGE_51_100 3.2 Pyzor need also his server list to be regularly updated == SPAM FILTERING with other means == Spam assassin is reliable but it's not enough. Still in eximl conf, add, in ACL, after the line "require verify = sender": ############################################################################# # There are no checks on DNS "black" lists because the domains that contain # these lists are changing all the time. However, here are two examples of # how you could get Exim to perform a DNS black list lookup at this point. # The first one denies, while the second just warns. # ## # $sender_host_address checks: # Disallow known abusers ; accept dialup and enduser to use their own smtp deny message = rejected because $sender_host_address is in a black list at $dnslist_domain\n$dnslist_text log_message = $sender_host_address found in $dnslist_domain ($dnslist_text) !dnslists = dnsbl.ahbl.org=127.0.0.9 : dnsbl.ahbl.org=127.0.0.11 dnslists = dnsbl.ahbl.org : list.dsbl.org ## # $sender_address domain checks: # Disallow rfc-ignorant ; accept dialup and enduser to use # their own smtp (!dnslists) deny message = rejected because $sender_address_domain is in a black list at $dnslist_domain\n$dnslist_text log_message = $sender_address_domain found in $dnslist_domain ($dnslist_text) dnslists = dsn.rfc-ignorant.org/$sender_address_domain # How can I configure Exim to delay the SMTP connection if more than # 10 invalid recipients are received in one message? # (spammer frequently forge addresses and send mails to a bunch a failing # recipients) # http://www.exim.org/exim-html-4.50/doc/html/FAQ.html#TOC271 deny message = Max $rcpt_fail_count failed recipients allowed condition = ${if >{$rcpt_fail_count}{10} {1}} ! verify = recipient delay = ${eval: $rcpt_fail_count * 10}s log_message = $rcpt_fail_count failed recipient attempts == MAILMAN INSTALL == * Install mailman, set up apache apt-get install mailman libapache-mod-gzip apache-ssl Mailman needs Apache, we'll configure it like apache-ssl for www, but on anot\ her IP (*.13). Mailman is run by cronjob, make sure they are properly set up. * We make mailman working tighly with exim, without adding the list in /etc/aliases or whatever. So the following must be added in mail:/etc/exim/exim4.conf.template In the section "Runtime configuration file for Exim", add: MM_HOME=/var/lib/mailman MM_WRAP=MM_HOME/mail/mailman MM_LISTCHK=MM_HOME/lists/${lc::$local_part}/config.pck MM_UID=Debian-exim MM_GID=list In "ROUTERS CONFIGURATION", at the end of the section (ORDER MATTERS!), after "localuser", add: mailman_router: driver = accept require_files = MM_LISTCHK local_part_suffix_optional local_part_suffix = -admin : \ -bounces : -bounces+* : \ -confirm : -confirm+* : \ -join : -leave : \ -owner : -request : \ -subscribe : -unsubscribe transport = mailman_transport In "TRANSPORTS CONFIGURATION", add: mailman_transport: driver = pipe command = MM_WRAP \ '${if def:local_part_suffix \ {${sg{$local_part_suffix}{-(\\w+)(\\+.*)?}{\$1}}} \ {post}}' \ $local_part current_directory = MM_HOME home_directory = MM_HOME user = MM_UID group = MM_GID * Mailman python config file mm_config.py must contain the following: DEFAULT_HOST_NAME = 'gna.org' DEFAULT_URL = 'https://mail.gna.org/' DEFAULT_URL_PATTERN = 'https://%s/' IMAGE_LOGOS = '/mmimg/' USE_ENVELOPE_SENDER = 0 DEFAULT_SEND_REMINDERS = 0 MAILMAN_OWNER = 'mailman-owner@%s' % DEFAULT_HOST_NAME # archiving via monharc ARCHIVE_TO_MBOX = 1 PUBLIC_EXTERNAL_ARCHIVER = 'No' PRIVATE_EXTERNAL_ARCHIVER = 'No' PUBLIC_MBOX = 'Yes' PUBLIC_ARCHIVE_URL = '/public/%(listname)s' PRIVATE_ARCHIVE_URL = '/private/%(listname)s' DEFAULT_MAX_MESSAGE_SIZE = 10240 # KB # Most of others settings are set by sv_mailman, as it is unclear whether # they should be system-wide or list specific. # Note - if you're looking for something that is imported from mm_cfg, but you # didn't find it above, it's probably in Defaults.py. DEFAULT_EMAIL_HOST = DEFAULT_HOST_NAME DEFAULT_URL_HOST = DEFAULT_HOST_NAME DEFAULT_SERVER_LANGUAGE = 'en' That's it! Do not forget to create the spam mailing-list (to catch false positives). == SAVANE INSTALL == IMPORTANT: all path mentioned are relatives to the chroot environment. Be sure to be logged as root *in* the chroot! Savane will build aliases in /etc/aliases.d/gna.org and will call mailman whenever a new list must be created. * Add in /etc/apt/sources.list of the db system # Savane stable releases deb http://dl.gna.org/savane/debian/ stable/ # yeupou packages deb http://dl.gna.org/savane/debian/ dangerous-yeupou/ * Get the required packages apt-get update && apt-get install savane-backend-mail * While the Savane configuration is created (with the interactive tool), say that you want mail related cronjobs and mailing-list related cronjob to be activated, say that you want mail aliases into /etc/aliases.d/gna.org * Remove the call to sv_mailman_checkqueue from /etc/cron.d/savane-mail and add in /etc/cron.d/mailman_check: export MAILTO="root-direct" 5 * * * * list /usr/local/bin/sv_mailman_checkqueue ($Id: bart.howto-install-mail-system,v 1.21 2005/09/01 09:01:54 lnu Exp $) 3.4 howto-install-www-system ============================ == BASE INSTALL == * First enter the chroot and install the server: chroot /chroot/www apt-get install apache-ssl php4 php4-mysql libapache-mod-gzip * Start it: /etc/init.d/apache-ssl start * Then, remove useless users (gnats, games...). == SAVANE INSTALL == IMPORTANT: all path mentioned are relatives to the chroot environment. * Be sure to be logged as root *in* the chroot! chroot /chroot/www * To perform the install, you'll need to install some software first; only the client side, refuses any request for running a server: this is no longer true but it is convenient for test.gna.org apt-get install ssh cvs gettext locales make * Add in /etc/apt/sources.list of the db system # Savane stable releases deb http://dl.gna.org/savane/debian/ stable/ # yeupou packages deb http://dl.gna.org/savane/debian/ dangerous-yeupou/ * Get the required packages apt-get update && apt-get install savane-frontend-php * Edit the following settings in /etc/apache-ssl/httpd.conf Listen 213.228.62.10:80 BindAddress 213.228.62.10 Port 443 ServerAdmin root@gna.org ServerName gna.org DocumentRoot /usr/share/savane-frontend-php UseCanonicalName On Listen 213.228.62.10:443 Include /etc/apache-ssl/conf.d # should be already there NameVirtualHost *:80 NameVirtualHost *:443 SSLEnable ServerName gna.org DocumentRoot /usr/share/savane-frontend-php AllowOverride All SSLDisable ServerName gna.org ServerAlias www.gna.org Redirect permanent / https://gna.org/ # We cannot use both www.gna.org and gna.org without creating cookies issues SSLDisable ServerName www.gna.org Redirect permanent / https://gna.org/ SSLDisable ServerName www.gna.org Redirect permanent / https://gna.org/ * The site specific content is stored in /etc/savannah-content, which is managed by the project "admin", it is main cvs module. For the record, the default content shipped with savane is in /etc/savane-frontend-php-content/ To update it, update its module and run cvs update inside the directory /etc/savannah-content. ($Id: bart.howto-install-www-system,v 1.8 2005/06/23 09:23:07 yeupou Exp $) 4 Lisa Information ****************** 4.1 hardware.2 ============== This machine looks like the following : The disk layout is (FIXME: outdated!) : Filesystem Size Type Comment /dev/hda1 2G swap Linux 2.4 requires twice as much as RAM /dev/hda5 235M ext2 /boot /dev/hda6 7.5G ext3 / /dev/hda7 1G ext3 /chroot/members /dev/hda8 1G ext3 /chroot/cvs /dev/hda9 1G ext3 /chroot/download /dev/hda10 6G ext3 /chroot/homepage /dev/hda11 27G ext3 /chroot/cvs/var/cvs /dev/hda12 27G ext3 /chroot/download/var/ftp /dev/hda13 372M ext3 /chroot/members/home It has been purchased, assembled and installed by the FSF France in the first week of january 2004. The second hard disk has been donated by Timothee Besset in 2004. 4.2 howto-associate-a-domain-name-with-a-group-homepage ======================================================= How to allow a group to use his domain name with his homepage at gna.org? 1. The domain name owner have to make his DNS entry for the www to the homepage.gna.org IP. We do not provide DNS. 2. We will add a specific configuration file in homepage:/etc/apache/other-domains.d/domaine.ext Example: www.livretdulibre.org In homepage:/etc/apache/other-domains.d/livretdulibre.org DocumentRoot /var/www/livretlibre ServerName home.gna.org ServerAlias livretdulibre.org ServerAlias *.livretdulibre.org In homepage:/etc/apache/httpd.conf, the first virtual host defined must be ServerName home.gna.org and at the end of the file Include /etc/apache/other-domains.d/livretdulibre.org ($Id: lisa.howto-associate-a-domain-name-with-a-group-homepage,v 1.1 2004/06/19 09:26:32 yeupou Exp $) 4.3 howto-install-arch-system ============================= The arch system is exactly similar to the download system. Do the same install, then: * Edit /etc/membersh-conf.pl: #!/usr/bin/perl $use_scp = "0"; $use_sftp = "1"; $use_rsync = "0"; $bin_sftp = "umask 002 && /usr/lib/sftp-server"; * Configure Savane so it runs cronjob related to accounts creation. * Adapt also /etc/membersh-errormsg * Edit /etc/cron.d/savane-members-shell # creates only arch repositories 30 */2 * * * root sv_groups --cron --only-arch * It got archzoom installed. Archzoom must be installed with apt-get, obviously. chroot /chroot/arch apt-get install archzoom enscript In /etc/archzoom/archzoom.conf, edit the following: library_archives = 0 debug_enabled = 0 globcats_enabled = 0 arch_ids_listing = 0 library_lookup = 0 run_limit_number = 10 run_limit_file = /var/cache/archzoom/archzoom-limit temp_dir = /var/depot/archzoom You must create /var/depot/archzoom, owned by www-data. A specific script of the gnapgnap package, ran hourly, will take care of registering arch repositories into /etc/archzoom/.arch-params/=locations as required by archzoom. This script will add shortcuts pages per project in /var/www-known-archives that we'll bind in Savane, so the link "browse repository" will actually point on something sensible for the given project. So the following must be added in /etc/apache/conf.d/know-archives.conf Alias /known-archives /var/www-known-archives Order Allow,Deny Allow from All Options Indexes FollowSymLinks MultiViews ErrorDocument 404 /known-archives/index.html (the index of known-archive should be meaningful, in case there no page because no arch repository exists, despite the fact the project activated it in Savane). ($Id: lisa.howto-install-arch-system,v 1.5 2005/09/20 15:46:44 yeupou Exp $) 4.4 howto-install-cvs-system ============================ * First, the download system should have /home + /etc/passwd + /etc/group from the members system. * User will able to - commit files with: cvs over ssh (rsync over ssh) - checkout files with: cvs over ssh or pserver - download trees anonymously with: cvs over ssh (rsync) - receive commit notifications via email * CVSROOTs are in /var/cvs, it is a specific partition mounted in noexec. * Every project has two repositories called /var/cvs/project and /var/cvs/project.homepage There is a symlink from /cvs to /var/cvs for user convenience. * We install cvs from a modified version packaged on Maggie. It includes a patch which simplifies the authorization scheme of pserver, allowing subexpression matchin in -allow-root. Since it is packaged as an upgrade from Debian upstream, it will be automatically installed from the Maggie repository (if a new release has not occured in Debian): chroot /chroot/cvs apt-get install cvs Make sure the cvs version ends up with 'gna' : dpkg -s cvs|grep Version: Version: 1.11.1p1debian-9woody4.1gnap Give no precisions about repositories. * We need ssh, we'll bind it on the default port chroot /chroot/cvs apt-get install ssh Edit /etc/ssh/sshd_config: ListenAddress 213.228.62.11 PermitRootLogin no PermitEmptyPasswords no PasswordAuthentication no DenyGroups root daemon bin sys adm tty disk lp mail news uucp proxy \ kmem postgres www-data backup operator list irc src gnats \ shadow utmp video staff games users IMPORTANT: DenyGroups list must be on one line, without \ ! IMPORTANT: you must update Lisa's /etc/ssh/sshd_config so Lisa uses a different IP. We also edited the /etc/motd, without giving any sensitive information about the server (no distribution version, no kernel version). * We also want cvsweb, we will bind it to the cvs.gna.org IP : apt-get install apache cvsweb In httpd.conf, ServerName cvs.gna.org BindAddress 213.228.62.11 * Configure apache to use mod_throttle and add the following # History of 1000 IP # Allow only 50 request per second per IP ThrottleClientIP 1000 Request 50 1 * Anonymous access: we create for that purpose the accounts anoncvs (historical name, password: anoncvs) and anonymous (more widely used, password: ). Note: useradd commands must be ran i1n the members system! chroot /chroot/members useradd -g nogroup -s /bin/false anonymous useradd -g nogroup -s /bin/false anoncvs It requires edition of Lisa's /etc/xinetd.conf (perl should use perlsuid, pserver.pl should be setuid) service cvs_pserver { socket_type = stream protocol = tcp wait = no user = anonymous port = 2401 bind = 213.228.62.11 server = /usr/bin/perl server_args = /usr/local/bin/pserver.pl cps = 50 10 instances = 100 max_load = 2 per_source = 3 } And in /etc/services cvs_pserver 2401/tcp gna pserver * MISSING: viewcvs: now we use cvsweb. There's a dedicated perl script to generate the list of cvsroot for him, there's just a "do thisconffile.pl;" to add in cvsweb conf itself. And afterthat, there are the usual cosmetics things to do. * Commit notifications: they are handled by cvsreport. The Savane backend automatically creates a dedicated ML (-cvs) and hooks to the CVSROOT/commitinfo script from both source and web CVS repositories from every project. Cvsreport is configured to send a default text+html report, with proper links to ViewCVS, and sends email using the local MTA facility. Content of /etc/cvsreport/conf: set mail { command = /usr/bin/mail } set html { cgi_links = yes cgi_urlbase = http://cvs.gna.org/viewcvs/$(sfproject) } One has to make sure that the /usr/bin/mail command supports the '-a' option (custom headers). == SAVANE INSTALL == IMPORTANT: all path mentioned are relatives to the chroot environment. Be sure to be logged as root *in* the chroot! Savane will be installed to provide the restricted shell and to create repositories (which type will be "basic download area" or something like that, as set up via the Savane interface for each group type). * Add in /etc/apt/sources.list of the db system # Savane stable releases deb http://dl.gna.org/savane/debian/ stable/ # yeupou packages deb http://dl.gna.org/savane/debian/ dangerous-yeupou/ * Get the required packages apt-get update && apt-get install savane-backend-members-shell savane-backend-cvs * Configure Savane so it runs cronjob related to accounts creation. * Edit /etc/membersh-conf.pl: #!/usr/bin/perl $use_cvs = "1"; * Edit /etc/cron.d/savane-members-shell # creates only cvs repositories 58 */2 * * * root sv_groups --cron --only-cvs --only-homepage # Build daily CVS 30 3 * * * nobody sv_daily_cvs_tarball --in /var/cvs --out /var/daily --cvs "-d:pserver:anonymous@cvs.gna.org:/cvs" * Add /etc/membersh-errormsg Error: You are not allowed to run the command you asked. Only cvs commands are accepted. Please double-check the command line you typed. Use our support tracker at http://gna.org/support/?group=admin if you cannot find a way to use this server as it is described. ($Id: lisa.howto-install-cvs-system,v 1.17 2005/09/08 13:31:48 yeupou Exp $) 4.5 howto-install-download-system ================================= * First, the download system should have /home + /etc/passwd + /etc/group from the members system, and /home obtained via NFS from members also. * Users will able to - upload files with: rsync over ssh, scp, sftp - donwload anonymously files with: http, ftp, rsync (currently ftp is not provided - no user request and issue with the proftpd setup) * Download area will be stored in /var/ftp chroot /chroot/download mkdir /var/ftp === DOWNLOAD / UPLOAD === * Install Apache with mod_gzip apt-get install apache libapache-mod-gzip In /etc/apache/conf/http.conf, configure it to make it handling the /var/ftp area, by changing the following: BindAddress 213.228.62.12 DocumentRoot /var/ftp # ... put in comment CGI related stuff * On Lisa, we need a startup file like /etc/init.d/download_chroot.sh Included in the gnapgnap package. * We need ssh, we'll bind it on the download.gna.org IP. chroot /chroot/download apt-get install ssh Edit /etc/ssh/sshd_config: ListenAddress 213.228.62.12 PermitRootLogin no PermitEmptyPasswords no PasswordAuthentication no DenyGroups root daemon bin sys adm tty disk lp mail news \ uucp proxy kmem postgres www-data backup operator \ list irc src gnats shadow utmp video staff games users IMPORTANT : DenyGroups list should be in one line only, without \ We also edited the /etc/motd, without giving any sensitive information about the server (no distribution version, no kernel version). Now people should be able to use scp/rsync over ssh. Sftp seems not able to run on a specific port. * Now rsync: apt-get install rsync Edit lisa:/etc/xinetd.conf, add: service rsync_download { socket_type = stream protocol = tcp wait = no user = root port = rsync server = /usr/sbin/chroot server_args = /chroot/download /usr/bin/rsync --daemon } Inside the chroot, add a /etc/rsyncd.conf similar to /usr/share/doc/rsync/sample-rsyncd.conf.gz, naming the module download. I tested with the following command, after creating a temp user: rsync rsync://download.gna.org/download --recursive For upload, we simply put a symlink: ln -s /var/ftp /upload Then we give a command line for usual rsync command (no server needed, user will go with ssh) - hum, that will require to provide the correct port. == SAVANE INSTALL == IMPORTANT: all path mentioned are relatives to the chroot environment. Be sure to be logged as root *in* the chroot! Savane will be installed to provide the restricted shell and to create repositories (which type will be "basic download area" or something like that, as set up via the Savane interface for each group type). * Add in /etc/apt/sources.list of the db system # Savane stable releases deb http://dl.gna.org/savane/debian/ stable/ # yeupou packages deb http://dl.gna.org/savane/debian/ dangerous-yeupou/ * Get the required packages apt-get update && apt-get install savane-backend-members-shell * Configure Savane so it runs cronjob related to accounts creation. * Edit /etc/membersh-conf.pl: #!/usr/bin/perl $use_scp = "1"; $use_sftp = "1"; $use_rsync = "1"; $bin_sftp = "umask 002 && /usr/lib/sftp-server"; * Edit /etc/cron.d/savane-members-shell # creates only arch repositories 58 */2 * * * root sv_groups --cron --only-download * Add /etc/membersh-errormsg Error: You are not allowed to run the command you asked. Only scp and rsync commands are accepted. Please double-check the command line you typed. Use our support tracker at http://gna.org/support/?group=admin if you cannot find a way to use this server as it is described. === GPG Checks === GPG signed files in the download area are checked using the savane integrated sv_gpgcheckfiles. The savane-backend-download package must be install on lisa main system, since we want the checks to be done outside of the chroot for obvious reason (if one can corrupt content of the download system, he may be able to corrupt programs on the same system). The command line is: sv_gpgcheckfiles --chroot=/chroot/members --dir=/chroot/download/var/depot This should be added in /etc/cron.d/savane-download ($Id: lisa.howto-install-download-system,v 1.12 2005/07/04 07:31:38 yeupou Exp $) 4.6 howto-install-homepage-system ================================= This system will only get anonymous copies of the cvs web repositories and make them available to rsync (for mirrorring) and http. apt-get install apache libapache-mod-gzip rsync Make sure Apache accepts 'index' as a valid index, in order to ease content (language) negociation (DirectoryIndex directive). It is also a good idea to active mod_includes (SSI) - it may have security implications, though. For now, it is activated ("AddType text/html .shtml" and "AddHandler server-parsed .shtml" must be uncommented, "XBitHack on" must be added for /var/www so executable files are parsed). For rsync, we create a /etc/rsyncd.conf almost exactly like the one for download, by adapting the path. Also we add an entry similar to the rsync for download in /etc/xinetd.conf (Lisa) one, by setting the port to 3000. NOTE: this is currently disabled in xinetd, because its usefulness remain to be demonstrated. * On Lisa, we need an init file like #! /bin/sh CHROOT=/chroot/homepage echo " In the $CHROOT jail:" echo " " chroot $CHROOT mount proc /proc -t proc chroot $CHROOT /etc/init.d/cron $1 chroot $CHROOT /etc/init.d/apache $1 chroot $CHROOT umount /proc echo " " * Every half hour, an anonymous update of the homepage cvs is made. The script bin/homepage-update.pl takes care of fetching the list of all available cvs repositories and updating its working copy. It is run from /etc/cron.d/homepage. ($Id: lisa.howto-install-homepage-system,v 1.7 2005/06/08 13:57:48 yeupou Exp $) 4.7 howto-install-members-system ================================ The members system is composed of a system and of a data partition. On the data partition are store users' home. Unix homes are required by the cvs and download system (for SSH keys, etc). Add in /etc/fstab: localhost:/chroot/members/home /chroot/cvs/home nfs ro,noexec,nodev,nosuid 0 2 localhost:/chroot/members/home /chroot/download/home nfs ro,noexec,nodev,nosuid 0 2 localhost:/chroot/members/home /chroot/arch/home nfs ro,noexec,nodev,nosuid 0 2 localhost:/chroot/members/home /chroot/subversion/home nfs ro,noexec,nodev,nosuid 0 2 The directory /home will be in read-only for user-accessible servers. This is achieved using NFS. So nfs must be installed on the main system apt-get install nfs-kernel-server And then configure it, by adding in /etc/exports: /chroot/members/home localhost(ro) Note that there's no fstab in /chroot/members. It should not change, there's no need to make this kind of things easy inside the chroot. * Reconfigure members, cvs and db not to use shadow passwd. No password will ever be given on these system, there no point bothering with the shadow file. Run on each system: dpkg-reconfigure passwd The system does not allows /etc/passwd and /etc/group to be symlink. The backend will take care to make copy of these files if they differ, every minute. That way, we make sure that nothing odd is happening. For that purpose, we wrote a simple script included in the gnapgnap CVS cron/savannah_sync-members-etc.lisa. == SAVANE INSTALL == IMPORTANT: all path mentioned are relatives to the chroot environment. Be sure to be logged as root *in* the chroot! Savane will be installed to create unix accounts for users and groups. * Add in /etc/apt/sources.list of the db system # Savane stable releases deb http://dl.gna.org/savane/debian/ stable/ # yeupou packages deb http://dl.gna.org/savane/debian/ dangerous-yeupou/ * Get the required packages apt-get install savane-backend-members-shell * Configure Savane so it runs cronjob related to accounts creation. Set the user shell to /usr/bin/sv_membersh, home to /home * Edit /etc/cron.d/savane-members-shell # Create groups and users accounts 30 */2 * * * root sv_groups --cron --only-etc && sv_users --cron --gpg-group-keyring >/dev/null 2>/dev/null ($Id: lisa.howto-install-members-system,v 1.10 2005/06/23 17:02:54 yeupou Exp $) 4.8 howto-install-savane-backend ================================ * The backend will be installed in the chrooted systems, but some actions will take place on Lisa. == MEMBERS PART == We have to get the member system users and group list synchronized with the system. Its home will be mounted on other systems via NFS. In the members system init file, there's a 'mount -a' for that purpose. * Also, we need it's list of users to copy synchronize very frequently on cvs and download. On Lisa, we add a cronjob in /etc/cron.d/savannah_sync-members-etc with the following content: */3 * * * * cp -pu /chroot/members/etc/passwd /chroot/download/etc/passwd && \ cp -pu /chroot/members/etc/group /chroot/download/etc/group && \ cp -pu /chroot/members/etc/passwd /chroot/cvs/etc/passwd && \ cp -pu /chroot/members/etc/group /chroot/cvs/etc/group We add add in /etc/exports (after installing the package nfs-kernel-server) /chroot/members/home localhost(ro) * We'll install the Savane backend and run sv_groups with options -one-group -no-cvs, -no-homepage, -no-download, in order to only update /home and /etc/passwd /etc/group, and to have only one group per project. cp -r /usr/src/savane /chroot/members/usr/src chroot /chroot/members apt-get install make perl modules libdbi-perl libdbd-mysql-perl cd /usr/src/savane rm configure.cache ./configure make conf make install Few configuration options must be set (if you need to use an editor not installed in the chroot, edit from Lisa): - anything related to database connection (note that on Bart, we must also add a user for connexion from lisa IP, by adding a user in the mysql.user table, an entry for the database, giving right for select/insert/delete, and running `mysqladmin flush-privileges`) - sys_shell, sys_homedir, sys_homedir_subdirs , $sys_cron_users , $sys_cron_groups Note that the sys_shell we want to use is the perl version of sv_cvssh, sv_cvssh2. * /etc/cron.d/savannah must be adapted too, by keeping only the sv_groups / sv_users line that should looks like: 30 */2 * * * root sv_groups --cron --one-group --no-cvs --no-homepage --no-download && \ sv_users --cron --one-group * There must be an entry in /chroot/members/etc/fstab for /home /dev/hda13 /chroot/members/home ext3 rw,noexec,nodev,nosuid 0 2 That should be it. It may be best to remove the 'savane' folder in /usr/src. == DOWNLOAD == We assume that download got the users and groups correctly from members. * We'll install the Savane backend and run sv_groups with options -no-etc, -no-homepage. cp -r /usr/src/savane /chroot/download/usr/src chroot /chroot/members apt-get install make perl modules libdbi-perl libdbd-mysql-perl cd /src/savane rm -f configure.cache make install * The conffiles can be copied from /chroot/members, it will be enough - only the active cronjob conf options should be changed. cp /chroot/members/etc/savannah /chroot/download/etc -r * The /etc/cron.d/savannah should contains: 58 */2 * * * root sv_groups --cron --no-cvs --no-homepage --no-etc Note that the time of this cronjob is 28 minutes after the cronjob in members. == CVS == Exactly the same method than for download, with one suble difference: the cronjob will get for options -no-download -no-etc. == Homepage == The backend has nothing to do there. ($Id: lisa.howto-install-savane-backend,v 1.6 2005/06/21 16:24:21 yeupou Exp $) 4.9 howto-install-svn-system ============================ * First, the download system should have /home + /etc/passwd + /etc/group from the members system. * User will able to - anonymous read via svn://svn.gna.org/svn/ (TCP 3690) - anonymous read via http://svn.gna.org/svn/ (TCP 80) - viewcvs for svn at http://svn.gna.org/viewcvs/ - authenticated read/write access for project members at svn+ssh://[@]svn.gna.org/svn/ (TCP 22) * Repositories are in /var/svn, it is a specific partition mounted with exec rights so that the commit hooks can work for email reports * The system is sarge: first woody was installed via debootstrap, later it was dist-upgraded. The following packages were installed: all subversion packages, including perl and python bindings apache2, libapache2-svn viewcvs. * We need ssh, we'll bind it on the default port chroot /chroot/cvs apt-get install ssh Edit /etc/ssh/sshd_config: ListenAddress 213.228.62.5 PermitRootLogin no PermitEmptyPasswords no PasswordAuthentication no DenyGroups root daemon bin sys adm tty disk lp mail news uucp proxy \ kmem postgres www-data backup operator list irc src gnats \ shadow utmp video staff games users IMPORTANT: DenyGroups list must be on one line, without \ ! IMPORTANT: you must update Lisa's /etc/ssh/sshd_config so Lisa uses a different IP. We also edited the /etc/motd, without giving any sensitive information about the server (no distribution version, no kernel version). * Setup /svn: Create an empty directory and in that directory create a symlink to the svn partition in /var: mkdir /svn && cd /svn && ln -s /var/svn ( unifies the various URL paths between the different access methods, and is additional security for svnserve usage ) * Apache2 configuration: edit /etc/apache2/ports.conf: Listen 213.228.62.5:80 edit and enable /etc/apache2/sites-available/default: ServerTokens Prod ScriptAlias /viewcvs/ /usr/lib/cgi-bin/viewcvs.cgi/ Alias /doc/viewcvs/ /usr/share/viewcvs/ DAV svn ErrorDocument 404 Default SVNParentPath /var/svn * ViewCVS for SVN configuration: edit /etc/viewcvs/viewcvs.conf: comment out cvs_roots/svn_roots and use root_parents: root_parents = /var/svn : svn default_root = savane address = main_title = SVN Repositories at Gna! use_enscript = 1 * /etc/savannah/savannah.conf.pl: our $use_svn=1; our $sys_default_domain="subversion.gna.org"; * svnmailer has been installed with the package from etch (not shipped with sarge). It's configuration file looks like: [general] sendmail_command = /usr/sbin/exim4 smtp_host = localhost [defaults] generate_diffs = none for_repos = /svn/svn/(?P[^/]+) to_addr = %(PROJECT)s-commits@gna.org from_addr = %(author)s@gna.org browser_base_url = viewcvs http://svn.gna.org/viewcvs/%(PROJECT)s == SAVANE INSTALL == IMPORTANT: all path mentioned are relatives to the chroot environment. Be sure to be logged as root *in* the chroot! Savane will be installed to provide the restricted shell and to create repositories (which type will be "basic download area" or something like that, as set up via the Savane interface for each group type). * Add in /etc/apt/sources.list of the db system # Savane stable releases deb http://dl.gna.org/savane/debian/ stable/ # yeupou packages deb http://dl.gna.org/savane/debian/ dangerous-yeupou/ * Get the required packages apt-get install savane-backend-members-shell * Configure Savane so it runs cronjob related to accounts creation. * Edit /etc/membersh-conf.pl: #!/usr/bin/perl $use_svn = "1"; * Edit /etc/cron.d/savane-members-shell # creates only svn repositories 58 */2 * * * root sv_groups --cron --only-svn # STILL EXPERIMENTAL build daily dumps of the subversion repositories # 0 4 * * * nobody sv_daily_svn_tarball --in /var/svn --out /var/daily * Add /etc/membersh-errormsg Error: You are not allowed to run the command you asked. Only svn over ssh commands are accepted. Please double-check the command line you typed. Use our support tracker at http://gna.org/support/?group=admin if you cannot find a way to use this server as it is described. ($Id: lisa.howto-install-svn-system,v 1.10 2005/08/23 16:57:32 yeupou Exp $) 4.10 projects-statistics ======================== We provide per projects statistics for the download areas and the homepages. Webalizer (the current statistics tool) is installed on lisa, the main system. It was an option to install it on homepage, but it would have been unsafe to install on download, since webalizer requires some stuff like xlibs and since download is one of the most crackable system, providing sftp, rsync and scp. And, anyway, on lisa, xlibs were already here for programs like Emacs. Statistics being pure html content, it make sense to get it served by the homepage system. So the output is stored in homepage:/var/www-stats, on a virtual domain name, stats.gna.org. This have been done following the procedure described in lisa.howto-associate-a-domain-name-with-a-group-homepage The default webalizer daily cronjob on lisa has been modified. First it runs two times, one with webalizer-download.conf, one with webalizer-homepage.conf, to generate general statistics in homepage:/var/www-stats (respectively in directories download.gna.org and homepage.gna.org). And then it runs homepage-webalizer.pl. This script process the list of projects that use download or homepage. It creates for each project a conffile in homepage:/etc/webalizer.d and finally it runs webalizer for each project download area or homepage, if using it. ($Id: lisa.projects-statistics,v 1.2 2004/10/07 09:03:14 yeupou Exp $) 5 Maggie Information ******************** 5.1 hardware.3 ============== This machine looks like the following : The disk layout is : Filesystem Size Type Comment /dev/hda1 2G swap will support an upgrade up to 1GB RAM /dev/hda5 235M ext2 /boot /dev/hda6 7.5G ext3 / /dev/hda7 110G ext3 /backup It has been purchased, assembled and installed by the FSF France in the first week of january 2004. 5.2 howto-make-gna-debian-packages ================================== gnapgnap is a set of Debian packages for Maggie, Lisa and Bart. A package is designed for each subsystem and machine, carrying only appropriate scripts for each. - -lisa, -bart, -maggie, -common and -kernel: installed on all master systems - -cvs, -download, -homepage, -mail, -www: installed in dedicated chrooted subsystems * To build them, get the admin module cvs -d user@lisa:/cvs/admin co admin And type the make command make package * To make them available to maggie, lisa and bart, the package must be added in maggie repository at /opt/apt-repos To update the package list, on maggie, type su www-data -c "apt-archive-update.sh" ($Id: maggie.howto-make-gna-debian-packages,v 1.2 2004/05/20 17:42:43 zerodeux Exp $) 5.3 howto-patch-cvs =================== Repackaging/recompiling CVS for Gna!, from maggie.gna.org: # cd /usr/src # apt-get source cvs From Woody, this will give a cvs-1.11.1p1debian folder. # cd cvs-1.11.1p1debian # cp ../cvs-cvsroot-substring-allow.patch debian/patches/99_cvsroot_substring_allow # vi debian/changelog Prepend a release block with last version suffixed by 'gnap1' or '.1gnap'. Example: -snip- cvs (1.11.1p1debian-10gnap1) stable-security; urgency=high * Repackaged security upgrade from Debian upstream with cvsroot-substring-allow patch - Vincent Caron Thu, 26 May 2005 14:20:00 +0200 cvs (1.11.1p1debian-10) stable-security; urgency=high [...] -snip- # debuild -uc -us # cd .. # ls -1 cvs*gnap cvs_1.11.1p1debian-10gnap1.diff.gz cvs_1.11.1p1debian-10gnap1.dsc cvs_1.11.1p1debian-10gnap1_i386.changes cvs_1.11.1p1debian-10gnap1_i386.deb # cp cvs*gnap*deb /opt/apt-repos/ # apt-archive-update.sh Then run apt-get update/apt-get dist-upgrade on selected subsytems. Example: # apt-get update [...] # apt-get -s dist-upgrade [...] 1 package upgraded, 0 newly installed, 0 to remove and 0 not upgraded. Inst cvs (1.11.1p1debian-10gnap1 localhost) Conf cvs (1.11.1p1debian-10gnap1 localhost)