March 2011 - clo-devel - mailman3.common-lisp.net

[clo-devel] upgrading: how do you (want to) use cl.net? [detected: very large home directories]
by Erik Huelsmann 03 Apr '11

03 Apr '11

As part of the upgrading process, I'm looking at the disk sizes, memory, etc to set up for new-cl.net. One of the things I found is that 30 or 40 user accounts together occupy the nearly the full size allocated to /home (14gb out of 15gb allocated). Which raises the question: what do people do with their /home dirs and is /home really the best way to do that (or the best place to store it)? At the same time, I'm wondering if you have possibly valid use-cases for common-lisp.net which you might have tried in the past, but did not succeed at, because cl.net wasn't sufficiently set up. As I'm now determining dimensions, it'd be a good time to take requests into account. Bye, Erik.

4 6

[clo-devel] common-lisp.net needs upgrading
by Erik Huelsmann 31 Mar '11

31 Mar '11

The server running common-lisp.net has been running in the current configuration for a number of years now. Its Debian distribution is still Etch, which has been moved to the archives June 20th last year. As a consequence, we're locked out of even the most basic of maintenance needs: security updates. Bottom line: common-lisp.net as it is today can't be maintained anymore. We need to upgrade the system. We have two options for the system upgrade: 1. Copy the VPS and run dist-upgrade; then fix whatever falls over. 2. Create a new VPS, and make a clean start, meaning that we identify all services currently running on cl-net and we arrange for the same or equivalent services to be running on the new system. Stelian has indicated his preference is for option (2), as too much has been customized or is installed in custom locations to make a standard dist-upgrade work. I concur. Another remark from Stelian is that we could migrate one service at a time, creating subdomains (svn.common-lisp.net, git.common-lisp.net, trac...., etc) which might help future migrations. So, from where we stand now, we need to: 1) Identify all services, users and data we need to migrate 2) Find people who want to help migrate the services 3) Per component, identify a migration plan - we can start migrating services with complete migration plans 4) Test the new clean setups as well as the combination of the new setup and the old data If it's an option, I'd like the full migration to take 2 months at max from the day we start. I'd be fine with starting immediately and taking Monday April 4th as the reference day. Services that I know we're running [without looking at the box]: * Mail [MTA] * Web * Ticket tracker (RT - internal use) * Mailing lists * Subversion * Repository browsing - Subversion - Git - Darcs - CVS (do we still want to support CVS ??) * Trac * spam detection * Git deamon * rsync (what for?) * sshd * ftpd * lisppaste (on sbcl-0.9.7??) * fast-cgi * custom administration scripts Drew and I want to replace RT by OTRS which is also standard in Debian and we have good experiences with - I set one up recently for ourselves. So, I guess for now, there are two questions to be answered: 1. Do you know of any additional services that we need to migrate? 2. Who wants to help out and which services can you help migrating with? So far, I have volunteered to coordinate the effort. Bye, Erik.

5 5

[clo-devel] cl.net FTP not useful?
by Erik Huelsmann 31 Mar '11

31 Mar '11

In my investigations, I found a running ftp daemon. However, it seems this ftp daemon requires authentication (through a password). Everybody receives ssh access, meaning you can use sftp to upload to cl.net anyway. Because of the required authorization, this service doesn't seem to support a general public service. Do we really need to configure an ftp service on our new host? Bye, Erik.

2 1

[clo-devel] change of add-trac setup script
by Erik Huelsmann 15 Mar '11

15 Mar '11

Some time ago, I optimized Trac performance. One of the ways I achieved it is by having Apache serve static files instead of Trac itself. This requires an extra step (trac-admin deploy) when creating new Trac directories for projects. Today, after Raymond Toy reported issues with Trac projects set up for him, I changed the add-trac.sh script to include the extra step. Just for your information. Bye, Erik.

1 0