Trinity Hall Computer Society

Minutes of the meeting held on 25th October 2004

Intent of meeting: to decide what to do with old hal, a.k.a. ito

Minutes taken by Malcolm Scott.

• The last minutes were approved.
• Previously decided: ito will be put on the Redstone DSL link so as to provide services we can't provide over the CUDN; in particular, services for alumni who are no longer permitted to use the CUDN.
• Matt suggests that traffic to/from ito should be minimised due to its low-capacity link and the fact that college is charged for bandwidth.
• Matt also suggests that we should run nstx on it, and put it on the SRCF VPN, to allow access to useful machines without allowing unsecured access to the whole CUDN.
• It was noted that Matt appears to have a private agenda - notably, he wants free internet access in the Pickerel; Jeff posed the question of whether THCS should be advocating the theft of wireless bandwidth through its services.
• Domain names:
  • To do nstx, we need a domain name; it was agreed that THCS could purchase a domain name for more general use not restricted to nstx.
  • The wonders of Bluetooth and GPRS were used to investigate possible domain names.
    • thcs.{org,net,com} are all taken. thcs.com is cybersquatted; we should watch for this expiring on 21st June 2005 :-)
    • the possibility of a th.cx domain was suggested and ridiculed
    • thcs.org.uk is available; it was agreed that this is a good domain name, and was purchased by Malcolm on behalf of the society during the meeting
    • The subdomain for nstx was suggested as mattstopplayingsillybuggers.thcs.org.uk, but was decided as nstx.thcs.org.uk.
    • ito will be www.alumni.thcs.org.uk; hal will be www.thcs.org.uk
  • DNS:
    • The possibility of hosting our own DNS, as well as offering to host secondary DNS for the SRCF, was suggested.
    • However, running a "real" DNS server simultaneously with an nstx server on the same box is impossible without (possibly extensive and nasty) custom coding.
    • Malcolm offered to host DNS for THCS on his non-CUDN server; after discussing alternatives, Malcolm's offer was accepted unanimously.
    • Reverse DNS: this must be handled by Redstone; it was postulated that Redstone are incompetent as none of their own servers appear to have working reverse DNS records, but that we should investigate the possibility of prodding them to set this up.
  • nstx security, and providing access to the internet / CUDN:
    • As mentioned above, nstx will only provide access to the SRCF VPN. From there it is already possible to get onto the internet via SSH port forwarding on hal, kern, etc.. But a VPN would be a nicer solution.
    • Possibly we should put THCS non-CUDN traffic in a separate VLAN for security.
    • This VPN should not be the existing CSG-run one on diamond, as THCS is not the CSG.
    • Any new VPN system would only need to work on Linux, as nstx only works on Linux.
    • Suggestions of Tinc, OpenVPN, FreeSWAN; Ian and Jeff agreed that FreeSWAN was a pain in the arse to configure, and Ian stated that he never wanted to do FreeSWAN configuration again.
    • As an aside, it was noted that the University VPN currently in development uses DES and is therefore crap.
  • How to handle users on ito and hal:
    • The same users should exist on hal and ito (with the same uids); some users would have their accounts on hal disabled where appropriate.
    • There should be some method of synchronising users' passwords between the machines; NIS was suggested, but agreement was that this would be over-complicated and a small hacky perl script would be better. Ian was nominated to write the small hacky perl script.
    • Users' home directories would be shared between the machines using NFS; after discussing various possibilities it was agreed that all data (for users of both hal and ito) should be kept on hal as it has a better disk setup (with RAID etc.) and simplifies the setup; i.e. ito should mount hal's /home via NFS (but not /societies as these should never be on ito).
    • It was agreed that a key issue is that users whose hal accounts are disabled must not be able to execute their own processes on hal via any means. Suggested tricky points in achieving this were:
      • cron - not a problem so long as crontabs are kept on the machine on which they are created; this is the default anyway
      • CGI - websites on hal should not cause CGIs belonging to non-CUDN users to be run
        • Possible solution: the visible URL for all websites is hal/~user, and hal does mod_rewrite proxying to ito if necessary; this makes use of CUDN bandwidth to serve websites, but may cause policy issues: it would be possible for non-CUDN users to put a website on a trinhall.cam.ac.uk address. This solution was rejected as too risky.
        • Better solution (accepted): run Apache on both hal and ito, and if people access a website via the wrong machine, send a HTTP redirect to the correct one. (Note redirection from ito to hal for hal users, to save bandwidth on the Redstone link.)
          • Use "foo magic apache config" (autogenerated) to handle the automatic redirection
          • The autogeneration script should check each user's shell; if /bin/false, set up redirection on hal to ito, else set up redirection on ito to hal
          • We would have to ensure that users' .htaccess files could not override our redirection
  • What needs doing first:
    1. Wipe ito
    2. Install sarge
    3. Synchronise user list (and uids of system accounts if they differ)
    4. Install Apache with the setup agreed above
  • The meeting was closed.