SSL Lab Policies

• Every machine installed into the SSL must be catalogued on the wiki page associated with one of the lab's racks.
• Every cable must be labelled on both ends with the machine(s) it is associated with. If a cable is associated with two machines, both ends of the cables should have both machine names on it.
• All cables should be bound (zip-tied/velcroed) with related cables. Please do not leave a tangle of cables around.
• Unused cables should be stored in appropriate boxes/drawers with like cables, not left hanging loose.

• All machines should configure their IP setup using DHCP and DDNS from Apu.
• Users are encouraged but not required to use LDAP authentication and NFS file service from Apu when being configured so that other SSL members can use the machines when necessary.
• Do not add guest users to any lab machine (e.g. with useradd or similar) unless absolutely necessary. We will accomodate guests as needed without doing local useradds.
• No scheduled backups are to be performed. Users are responsible for the safety of their own data.

This reservation policy applies to the phoenix and uter clusters. These are guidelines for using shared resources so that everyone gets a chance to get their research done. Good-faith cooperation is all that is required.

• Exclusive block reservation requests are made via email to the SSL mailing list. Please specify when your reservation will start, how long it will last, and if there are specific nodes you will not need.
• You may reserve up to 12 hours of exclusive access at a time.
• Reservations must be made at least 48 hours in advance. If someone needs more lead time than that, negotiate.
• If you hold a reservation and discover that you can't or don't want to use your time, announce to the list that you're cancelling the reservation so that others may resume their work.
• Reservations may be extended if nobody objects. Ask on the mailing list.
• Designated administrators (e.g Philip for phoenix) may take machines down for emergency maintenance/management if necessary, and may refuse reservations on that basis when necessary.
• Individuals may “own” particular cluster nodes unless/until an exclusive reservation is made. Just remember that you should be prepared to give the node away for a while on 48 hours notice.
• There (will be/is) a Current Reservations wiki page which should be updated once reservations are confirmed by email, and when reservations expire or are canceled. This is the responsibility of the reserver.