As I may have mentioned a while ago, I am “upgrading” from perl to python. Took me a while to adjust but I’m getting there.
The biggest problem with learning a new language is finding something to write in it and this is where project Euler comes in handy.
So, by way of reference for me, I am posting my solutions to the first four project Euler puzzles.
Recently I’ve been very busy experimenting with vCloud Director in the office lab. It’s a complex beastie and many thanks to Duncan Epping for his excellent turorials. When I get more experience, I may blog on it but as I have a dozen things to do on my ever growing list, it seems unlikely. One quick note to self though: the strange error I got about a host already being controlled was due to agent confusion and I had to run vslad-uninstall.sh and re-install to fix.
Now, on to the subject. Alastair Lumsden introduced this months UKOUG/LOSUG speakers Tom Kranz and Peter Tribble attended by the usual suspects in the audience. Tom talked about “Exploring Solaris Auto Registration” – that part of Solaris in Update 9 which sends all your machine details to Oracle over the internet, oh yes. Now in 99% of cases you don’t want it to do this so he explained how to disable it and some of the commands involved: stclient, stlisten, stdiscover. All worth reading up on for the professional Solaris Admin.
Peter Tribble’s talk was titled “Sar – past present and future” and, lets face it, “past” is the key word here. No-one was arguing with that point of view but Peter showed a good, simple idea to allow people to keep historical data and use it to assist in problem diagnosis and as a source of graphs for management. Keeping historical data was/is one of sar’s useful aspects. Peter simply keeps kstat -p output and stores it in compressed format for future use. The storage required is not that large and you can quite easily keep a couple of years worth. He has written some tools to scan the compessed logs and mimic the output of stat commands so you can see what “mpstat 10” would have produced at midnight on February 20th last year, if you want.
Perhaps we’ll get a talk on sar’s older brother, process accounting one month 🙂 No, please, just joking.
Next month Alastair is planning workshops, running from late afternoon which could be interesting and in January Jim Mauro is in the country promoting the new dtrace book and we can look forward to a talk from him!
Yes! It’s time for another post on naming conventions! Specifically, naming servers but there are many many objects to be named when setting up layered systems since vSphere, vCloud director etc. But lets stick to servers.
I may have stated the (obvious) requirements before but no harm to do it again. The most important rule is that names need to be:
a) unique
thats the really only hard and fast rule and is pretty obvious since you don’t want to end up with six servers all called “fred”.
Of course even that simple statement leads to my meta rule: even if the name is unique, it should also
b) sound unique.
Unless it sounds unique then when people (or alarmpoint) use the name to communicate there’s no point in it being unique. For example “unipro1” and “unibro1” are unique but rubbish since they sound the same.
The implicit assumption is that the names will be communicated orally, and I’ve never come across an organisation where that is not the case. It implies my next rule which is the word must be:
c) sayable
Now uniqueness can be got pretty easily with numbers but as mentioned before you should only use a given number once in any name. For example prodserver0001 and devserver0001 are unique and sound different but both use 0001, which to me adds a level of risk.
What information can you encode in your name? Well, it depends. On personal taste and the priorities of an organisation. Consequently no two systems will be the same. What you need to do is decide the three most important things for you or your organisation and use codes for that. If three bits of information compromises “sayability” then go back to two and use your CMDB to hold information on your server (you do have one, right?)
As an aside, one popular system is to use proper nouns. We used Scottish Islands when I was at Uni and people use things like Simpsons characters. These systems have several drawbacks. Typically you run out of names. Some may sound the same. Most of all it is a wasted opportunity because even if you put one piece of information in a name, that’s better than nothing.
Back to codes. Popular ones are location, operating system, function, support level. If you are a virtualisation company, say, it might be important to know if a server is physical or virtual. This is an example of a scenario when two totally different naming conventions might be useful. There’s no need to squeeze everything into one size of shoe, provided there’s no danger of overlap. I would be wary of more than three systems in one org though.
Personally I like location and OS in a physical server, and whether it is Unix or Windows. Consequently I would end up with:
lonuni0001
lonuni0002
lonuni0003
lonwin0004
lonwin0005
lonwin0006
sanuni0007
sanwin0008
It would be nice to get in prod/dev/qa but it makes it unsayable but you could get creative and carve ranges out of 0001-9999.
Location is not as important in a VM so we could sneak in prod, dev, qa:
uniprod0001
unidev0002
uniqa0003
winprod0004
windev0005
wintest0006
Now you might find it hard to remember what server does what but I would always advocate creating a CNAME (without any rules) which makes sense to you; that’s what they’re for! e.g:
speeddb -> uniprod0001
vclouddir -> unidev0002
fred -> wintest003
virtualcenter -> winprod0004
dnsserver -> winprod0005
paulsserver -> windtest0006
But enough rambling from me. I really should do some proper work as the list grows longer and the solutions do not. But don’t cop out and say names are not important. They are.
If names are not correct, language will not be in accordance with the truth of things. ~Confucius
Names are not always what they seem. The common Welsh name BZJXXLLWCP is pronounced Jackson. ~ Mark Twain.
Brian Madden was speaking at a Quest Desktop Virtualisation event at the Landmark Hotel in London on Tuesday so I went along to listen. (Nice hotel by the way). Brian is as entertaining and thought provoking as ever and here are a few extracts from notes I jotted down.
One set of slides that stuck in my mind were the “Shit!” and “Yay!” ones. People saying “Shit!” are users (mostly) and VMware, Citrix. People saying “Yay!” are Microsoft (and virtualisation consultants). This is because you cannot get away from Microsoft apps and Microsoft apps need a Microsoft O/S to run. And that O/S has a built in registry which makes turns the whole package into a “brick”. This is the historical legacy we live with. The technology has, and does, evolve rapidly making many new architectures possible. But the inertia of big business and the desire to keep doing the tried and tested method (operations people hate change) means we have to carry around a large ball and chain (like we read a scroll of punishment).
There is of course a new breed of app which lives in the cloud, (dropbox was mentioned) and it is impossible for corporations to stop people using that stuff. Ultimately it is all about the apps and I am sure that a tipping point will occur when there is sufficient functionality in “cloud” on demand apps to run a business with. The younger generation, it was pointed out, are the first to have grown up with computers and this technically savvy generation will be a force for change.
In the meantime, to realise the benefits of the technologies now at our disposal, we have to continue designing and implementing extremely complex systems to bridge the software generations. There are lots of 16 bit dependencies out there, which in itself is a case for virtualisation because the latest operating systems won’t run them and they won’t die.
So, the best way to run new apps is in a virtual environment and the best way to run old apps is in a virtual environment.