Suitable Naming Conventions For Workstations?
spectre_240sx writes "We've discussed server naming a fair amount in the past, but I haven't seen much about workstations. Where I currently work, we embed a lot of information in our workstation names: site, warranty end date, machine type, etc. I'm of the opinion that this is too much information to overload in the machine name when it can more suitably be stored in the computer description. I'd love to hear how others are naming their workstations and some pros and cons for different naming schemes. Should computers be logically tied to the person that they're currently assigned to, or does that just cause unnecessary work when a machine changes hands? Do the management tools in use make a difference in how workstations are named?"
And that's saying something.
Honestly, can you even think of a stupider question? How is this even an issue? Just name each machine with an ID and put the information in a spreadsheet somewhere. It's not a complicated problem.
A computer name should not be a database. If you want to store information such as site, warranty end date, machine type, ... use a database.
I laughed out loud. Using the IP address as the hostname? Genius.
Exactly. We have an 'asset tag' - a number written on the case with a sharpie. (Works perfectly fine for us!) The computer's name is just "PC" followed by the (zero padded to three digits) computer number. Thus, I'm on PC079.
(With us, when a person changes department or office, their computer follows them. Thus there's no sane reason for us to encode the office or department name into the computer's name.)
Use asset tags. They are unique (at least should be) all other data are stored in database else where, sub-records keeping rest of the information like software loaded, key#, ...
*IF* BIG IF,you have more than 1 company under the same roof, add a simple company id, but really not needed, that is really a column in database.
Watch out for asset tags greater than 8 or 10 characters, depending. Can be problem with secondary machines and naming issues, like workstation ids IBM equipment (10 char unique / 8 char local machine plus 2 auto-assigned characters to insure uniqueness). This way tracking a machine "foot print" on a foreign location machine will be easier, instead of random assigned ids.
The machine should be reimaged when it changes hands, so resetting the name will add about 5 seconds to the setup process. Not a big deal.
In the tightest companies I have worked for, they name workstations and servers with meaningless random generated alphanumeric sequences.
I guess they consider it more secure, making it harder to figure out the network topology. Also, since the names are meaningless, there is never a need to rename the machine really, unless they would want to confuse even more want to be hackers.
Everything I write is lies, read between the lines.
I suspect that it was much more common back when computers were much less common. At home, I certainly indulge in evocative naming(mostly Cthulhu mythos, by preference); but at work there are over 1,000 machines. Until somebody lists the names of all Shub-Niggurath's offspring, I'm out of luck.(Well, that and the fact that users might not like dealing with unpronounceable machine names that reek of ancient and terrifying evil...)
Service tag for the win.
Pre-fixing or post-fixing the name with something significant to it's location (such as department number) can be a lazy-man's replacement for a spreadsheet, but may require a rename when the computer's re-purposed.
Store the owner's name in the database (if one exists) if it's valid to the location. Even if the person leaves or gets fired, half of the department may know his name better than his job description.
One word: TinyURL.
"It's the height of ridiculousness to say for those 9 lines you get hundreds of millions."
That's a lot of work when someone changes a cubicle.
You have to rename it.
Which is silly.
As with people, machines should have a unique name, all the rest of the information about the machine should be in a database of some kind (a list in a text file would do).
Then when you move the machine, assuming that your DHCP, DNS and WIntel servers are up to scratch, yo have to do precious little but relocate the machine (and update your database).
With your naming scheme you have to rename the machine in addition to updating any database you may have.
IANAL but write like a drunk one.
It is a common mistake, but do not attempt to insert descriptions into identifiers. You wouldn't name your child "Dribble-gums-nursery-2" and expect then to be still comfortable about it when they reach their teens. But call then something meaningless like "Kevin" and there's no problem. Computers are no different.
If you create an identifier that attempts to describe the computer, rather than just give it a unique name, you can be sure that by the time it comes to decommissioning it the identifier will be misleading. Things will have changed. It will have a different location, a different OS, a different owner, or a different spec.
Come on guys, it's possible to understand a joke and then make a serious comment about some aspect of it.
I wish to remain anomalous
I seriously can't believe that it took this far down the comments to see what I thought any sane person in the world already did. The service tag is the answer. The fact that it's printed and your reimaging can pull from BIOS being the main benefits. In my experience they are unique even if you use multiple manufacturers - certainly Dell, HP/COmpaq and IBM are all different styles and in 15 years I've got no overlaps. There are some fairly funny replies elsewhere, pity so many are unintentional...
Only big ligs use sigs.
because if you're going to rename a server, you might as well rebuild it
What, "hostname $new_name" is too hard to type? I mean, you don't hardcode the machine name in application config files and rc scripts, do you?
Do you?