VMs on cube

From Netsoc Wiki
(Redirected from Cubeirc)
Jump to: navigation, search

The information on this page is out of date, and relates to when cube ran OpenVZ virtualization

VMs on cube

Cube runs on an OpenVZ kernel, dividing the machine up into a number of virtual machines ("containers" in openvz-land) for security, ease of administration, and so that the admins get to play with virtualisation. The virtual machines were allocated the IP range (that's for CIDR fans).

Currently all of these run Debian, with the server-type ones running mostly stable and the user-type ones running mostly testing. Sometimes non-Debian software is installed on these, see Installing software from source for the preferred install locations, etc.

The services provided by cube are partitioned into containers based mostly on security considerations: compromising a publicly-visible service should leave an attacker on a machine with an absolute minimum of access to the rest of netsoc's infrastructure.

Currently, some VMs on cube are not accessible outside the College network. So, shorewall is set up to route traffic from the login VM to services running on those VMs.


  • Has access to: User homedirs, User webspace
  • Shell logins by: All netsoc members, via SSH from anywhere
  • Runs services: SSH, NX logins for netsoc members

This is the login machine, and the only one that most people have access to. It's the one that has the cube.netsoc.tcd.ie hostname.


  • Has access to: Everything on cube, including all the VMs, the hardware and the kernel
  • Shell logins by: Admins only, logging into local (not LDAP) accounts from machines inside College only
  • Runs services: SSH for admins

The OpenVZ root, the machine with access to actual hardware. Admins only. This machine shouldn't be used for anything except setting up OpenVZ and things that require hardware access (RAID, firewalls, etc.). No network services except SSH and Munin run on this VM.


  • Has access to: User webspace
  • Shell logins by: Only admins, but users can run PHP, etc. websites from here
  • Runs services: Apache webhosting for users, MySQL for users.

Hosts users' websites. This machine is separated from cube.netsoc as users' websites are the service most likely to be compromised. Users can edit and upload their websites to cube.netsoc, but the files will be hosted and any scripts run from userweb.netsoc.

This is to ensure that compromising a website does not mean compromising the owner's shell account, and since the webspace is exposed to cube.netsoc as well it means that if a user's website is compromised or defaced it is possible for them to fix it by logging in to cube.netsoc.

Common 'login machine' software such as multiplexers, news clients, IDEs and so on are not installed on userweb to discourage people from using it for day-to-day work (cube should be used for that; it's much less vulnerable).

More information about userweb's apache configuration can be found at the page for User webspace.

Userweb also runs the user MySQL server. Login details for MySQL can be found by running mysql_details on Cube.


  • Has access to: No shared data, only local storage.
  • Shell logins by: Admins and web admins (members of group "webteam")
  • Runs services: Websites adminned by Netsoc rather than by users

Hosts websites adminned by Netsoc (including our own website, and the Intersocs QDB) It uses lighttpd for hosting (better performance than Apache, at the expense of less per-user-tweakability).


  • Has access to: User homedirs, User webspace
  • Shell logins by: Admins only
  • Runs services: File access via WebDAV, Samba, etc.

This machine hosts the publicly-facing file access software for users' home directories and webspace. Users do not have shell accounts on this machine.


  • Has access to: Local storage only
  • Shell logins by: Admins only, by first getting access to cuberoot
  • Runs services: LDAP

This VM runs the LDAP server that holds account information for netsoc members past and present. Security is very important on this machine as it's quite easy to compromise other machines from it. In the spirit of abject gibbering paranoia, there is no SSH access. To access this machine admins must first log into cuberoot and then use "vzctl enter ldap" to get a shell.

To get root access to LDAP (necessary for a lot of tasks), you must be logged into this machine as LDAP has no remote-root logins set up. On this machine, you'll probably want to use ND to manage accounts.

Backups of the LDAP DB are periodically taken and stored in a git repo in /srv/ldapbackups. "ldapbackup backup" should be run to take a backup before any major changes to LDAP are attempted.


  • Has access to: Local storage only
  • Shell logins by: Admins only
  • Runs services: IRC Daemon

This VM runs Netsoc's node on the Intersocs IRC network. It runs Hybrid-IRCD, with its configuration mostly ported from the old IRC daemon on Matrix. Note that this VM does not run Hybrid IRC Services; that service runs on a different VM (services.cubeirc.netsoc.tcd.ie/ to allow us to take down Netsoc's IRC server if needs be without all of Intersocs losing access to ChanServ, NickServ and OperServ.


  • Has access to: Local storage only
  • Shell logins by: Admins only
  • Runs services: IRC Services

This VM runs Hybrid IRC Services, which supplies the Intersocs IRC network with access to ChanServ, NickServ and OperServ. All the config files and databases are located in /etc/hybserv/.
Replaced by snark-irc-services.


  • Has access to: Local storage only
  • Shell logins by: Admins only
  • Runs services: Mail, sooner or later.

In theory, runs mail. In practice, mail hasn't been migrated over from Spoon and Matrix yet.


  • Has access to: Mostly-unprivileged account on other Netsoc machines
  • Shell logins by: Root on any Netsoc machine
  • Runs services: Tracks netsoc-wide scripts, utilities, etc. and distributes changes to other Netsoc machines

Still something of a work in progress, this VM will act as a repository for netsoc-specific software (which is currently copied around from machine to machine, and occasionally gets out of sync). It can be accessed without a password from root@ any netsoc machine, and can access an unprivileged account on any netsoc machine. For someone who knows the Netsoc root passwords, this will provide an alternative means of getting access in cases of oh-god-ldap-broke.

various others

There are a few VMs for netsoc members' personal projects (currently s4dd has one for a project last year, not sure if he still uses it), and one for admins to mess about with experimental software (hackery.netsoc.tcd.ie, not used for anything in particular).