Brainbox configuration

Configuration issues

Using issues here to mean simply something that needs discussion and possibly some decision, not necessarily an active problem.

• GID coordination: We will probably need to figure out how to do GID coordination if we expect to mount shared storage, e.g., MSIS Blue, ARC Turbo, etc. In the past, even though people do not think they will, most labs have shared their machine(s) with people in other labs, and setting a lab GID and default umask of 770 can save many headaches later. (bennet)

• VNC configuration: In the past, I have always used assigned VNC port numbers. That makes VNC configuration consistent regardless of machine, prevents sporadic conflicts, etc. This also makes it possible to provide the vncstart and vncstop scripts as part of the default configuration for each user. (bennet)

• If we are going to use Git as a production deployment mechanism, shouldn't we figure out how to configure things such that, if we, say,

  $ cd /usr/local
  $ sudo git clone git@github.com:/UMPsychMethodsCore/MethodsCore
  

  that running git status shows a clean repo? It looks like, right now, /usr/local/MethodsCore shows about 15 modified files, all of which seem to change mcRoot to /usr/local/MethodsCore. Doing so would make it possible to update /usr/local/MethodsCore by using a git pull. If we don't, every update will included unnecessary deconfiguration followed by reconfiguration, which induces a race condition if an update is run while someone is using the system, no?

  • We have an update script distributed with the repo (.deploy/src/self_update.sh) that has some post-checkout scripts that run to make sure all the paths are correct for a given system (since in our current environment, we can't enforce the repository being installed to the same location on each server). Running the self update script is just as easy a git pull.

• We should really pick a distro to use. I am inclining now to trying to try to set up a CentOS 7 image, install the software including version numbers, and see how awful that is. I believe it will not be super-awful, and in the long run may be easier to maintain. Perhaps we should consider an NFS server inside YB that shares imaging software to BBs.

  • I suspect our main contenders are CentOS, Ubuntu, and Debian? I'm partial to the maintenance and interface of Ubuntu/Debian based systems. In terms of the user experience, I don't think there will be much difference so it's probably more about what we want to deal with for maintaining them. If we go Ubuntu/Debian we have the NeuroDebian repository to aid in getting packages, though most of the major tools include a RedHat/CentOS rpm so it's not too bad. Alternatively, how difficult is it to set up either a yum or apt repository for us to host internally with whatever software we need to distribute? (Mike)

  • The choices are Red Hat/CentOS on one side, then Debian/Ubuntu on the other, yes. I (bennet) haven't got a lot of experience maintaining the D/U machines. My suspicion on how this will devolve is that we -- Mark, me, possibly a couple of people from Psychology and/or MSIS will do the bulk of the OS maintenance and software installation trying to free Mike and Daniel (and successors and additons) to deal more the the imaging and statistical side of things.

    I would need to be convinced that any distribution's package manager will be up to the task. I think we will end up building software by hand or downloading binary distributions for most things, as I have not yet met a lab that can live with only one version of anything. There will be some, though not perfect, overlap between any software we put onto the Brainboxes and software we put onto Flux, and possibly also onto any physical hardware that remains in departments/labs. I think there are fewer labs in Psychiatry with local servers, but those are larger, whereas in Psychology there are more of them but typically single servers per lab. (bennet)

• Provisioning Brainbox: What goes into provisioning a brainbox for someone?

  • Each group is name according to PI or lab name, depending on original request. For example, when first requested, we created a panlab group for Daniel Kessler, but for Thad Polk, we created tpolk. Since panlab has multipe PIs, this is acceptable, so that should one of the PIs wish to start a brainbox group under their name, they can. Labs with a single director/PI should be named for the PI. (bennet)

• Maintaining a Brainbox: How do we push updates to them, what kinds of updates, etc?

  • Our group at ARC uses Ansible as the configuration manager, both at initial setup and for ongoing maintenance. It may or may not be the best, but I think it will do what we need it to, it's well documented, it's maintained, and it has packages in both distro camps we're likely to fall into. I suggest we use it.

  • I'd like to come up with some checklists for maintenance so that we and users will know what do expect and do when maintenance is needed.