Computer Club naming policy is simple.

Core concepts

Each machine has a unique "cute" name (like "whelk" or "labrador") as its hostname; the type of cute name is determined by the service the machine provides. There is also a DNS A record with that "cute" name pointing at that IP of that machine. Each service has a functional name (like "shell01" or "kerberos2"). This functional name is tied to the service, rather than the machine. There is therefore a DNS CNAME record pointing to the "cute" name of the machine currently providing that service.

Never refer to the machine's service by the machine's hostname. Always use the CNAME to refer to the service.

Never use the CNAME to refer to the specific machine/hardware/Debian install. Always use the hostname to refer to the specific machine.

Avoid ever reusing the "cute" names of machines; when making a new machine that provides the same service as an old machine, never use the same name as the machine currently providing that service.

Cute naming table

Machines with this purpose

Should have a name like (examples)

Shell machines

Shelled creatures (whelk, oyster, clam)

Kerberos KDCs

Dog breeds (labrador, collie)

Service naming table

Instances of this service

Should be represented by a CNAME like (examples)

Shell machines

shell## (shell01, shell02, shell03)

Kerberos KDCs

kerberos# (kerberos, kerberos1, kerberos2) (specified by protocol)

Example

"labrador" is the hostname of a machine that serves as a KDC.

"labrador.club.cc.cmu.edu" is an A record that points to that machine.

"kerberos2.club.cc.cmu.edu" is a CNAME record that points to "labrador.club.cc.cmu.edu".

Our Kerberos configuration refers to "kerberos2.club.cc.cmu.edu" (along with the other KDCs).

Building a new machine to replace a machine currently providing some service

  1. Find the purpose of the new machine in the first column of the naming table.
  2. Observe the second column in that row.
  3. Make up a new easily-spelled and easily-pronounced name in that category.
  4. Update the service CNAME to point to the new machine's name.

For example, Bob is building a new KDC to replace "labrador". He picks "shiba" as the hostname of the new KDC, and builds the machine. When he's done building and testing it, he looks up (in the DNS configuration) what CNAME points to "labrador.club.cc.cmu.edu". He sees that it's "kerberos2.club.cc.cmu.edu", so he points that CNAME at "shiba.club.cc.cmu.edu"; all our servers refer to the KDCs by CNAME, so this tells every server to use "shiba.club.cc.cmu.edu" instead of "labrador.club.cc.cmu.edu". After a few days with no problems, he shuts down "labrador".

Building a new machine to provide additional capacity for some service

  1. Find the purpose of the new machine in the first column of the naming table.
  2. Observe the second column in that row.
  3. Make up a new easily-spelled and easily-pronounced name in that category.
  4. Create a new service CNAME and point it at the new machine's name.

For example, Alice is building a new shell machine because shell machine load has increased recently. She picks "shiba" as the hostname of the new KDC, and builds the machine. When she's done building and testing it, she looks up (in the DNS configuration) what CNAME points to "labrador.club.cc.cmu.edu". She sees that it's "kerberos2.club.cc.cmu.edu", so she points that CNAME at "shiba.club.cc.cmu.edu"; all our servers refer to the KDCs by CNAME, so this tells every server to use "shiba.club.cc.cmu.edu" instead of "labrador.club.cc.cmu.edu". After a few days with no problems, she shuts down "labrador"; after a few more days, she removes the DNS records for "labrador".

Building a new service

Are you sure you're not just making a new machine that is providing some existing service?

  1. Make up a new service/category pair and put it in the naming table in the wiki
  2. Make up a new easily-spelled and easily-pronounced name in that category.
  3. Create a new service CNAME and point it at the new machine's name.