Two of my tweets , sorry dents, earlier today caused some people to ask me what on earth I was doing :)

You don't exist, go away!

Was the first one, indeed .. it was a long time since I had actually seen that one.. this actually happens when you delete the user you are logged in with on a host, when the host notices you don't exist anymore it will tell you.

Now that is exactly what happend .. We were busy reordening the uid's on some hosts , so I modified the puppet config for that host and changed the uid values, a couple of minutes later I was told that I don't exist ..

The last time I saw that , was about 10 years ago when I was trying to fool some collegues :)

Now the second tweet that tracked some people's attention was the one about a very lengthy catalog run

Apr 20 05:12:42 sipx-a puppet-agent[22384]: Finished catalog run in 4158.09 seconds

The reason for this lengthy catalog run was the above uid reordering , combined with

       "/var/sipxdata/":
                        owner => "sipxchange", group => "sipxchange",
                        recurse => true,
                        ensure => directory;

And about 5K files in that directory .. apparently recurse doesn't translate to chown -R yet :)

That's the question Xavier asks in his blog entry titled
Security: DIY or Plug’n'Play

To me the answer is simple, most of the appliances I ran into so far have no way of configuring them apart from the ugly webgui they ship with their device. That means that I can't integrate them with the configuration management framework I have in place for the rest of the infrastructure. There is no way to automatically modify e.g firewall rules together with the relocation of a service which does happen automatically, and there is always some kind of manual interaction required. Applicances tend to sit on a island, either stay un managed ( be honest when's the last time you upgraded the firmware of that terminal server ? ) , or take a lot of additional efort to manage manually. They require yet another set of tools than the set you are already using to manage your network.
They don't integrate with your backup strategy, and don't tell me they all come with perfect MIB's.

There's other arguments one could bring up against appliances, obviously people can spread fud about some organisation alledgedly paying people to put backdoors in certain operation systems.. so why would they not pay people to put backdoors in appliances , they don't even need to hide them in there .. but my main concern is manageability .. and only a web gui to manage the box to me just means that the vendor hates me and dooesn't want my business

A good Appliance (either security or other type) needs to provide me an API that I can use to configure it, in all other cases I prefer a DIY platform, as I can keep it in line with all my other tools, config mgmtn, deployment, upgrade strategies etc.

Mabye a last question for Xavier to finish my reply ... I`m wondering how Xavier thinks he kan achieve High-availability by using a Virtual environment for Virtual Appliances that are not cluster aware using the virtual environment. A fake comfortable feeling of higher availability , maybe.. but High Availability that I'd like to see.

Johan from Sizing Servers asked me if I could talk about my experiences on building (virtual) appliances at their Advanced Virtualization and Hybrid Cloud seminar . Off course I said yes ..

Slides are below ... Enjoy ..

Larry, I`m glad you asked ..

With the risk of receiving a flood of comments pointing me to already existing tools here's my go at what I as a sysadmin of often large deployments am looking for in Drupalland .

You suggest LDAP and syslog integration .. guess we already have that don't we ?

But what I haven't found yet ..
An rpm/deb repository of Drupal modules So we can do an apt-get install drupal-package , yes I know about Drush, but I want the files on my system to be in a package and clearly identified, it helps me keeping my system uncluttered.

apt-get update drupal-package , or yum install drupal-package would be a luxury, same for themes btw.

It would be lovely if the postinstalls of those package also trigger a database upgrade if needed.

Which brings me to the next issue. If I have a multisite setup and I update a module in sites/all/modules, I usually have to go trough each and every site hosted there to update the databases. No really something I like to do for 10+ euh 3+ sites.

Also think big, don't waste your time on desktop apps or guis .since as long as you only have 1 site to manage point an click is fine, for you , Think in terms of what if you have 10 sites, 100 sites, or more .. do you really want to do that kind of administration via a browser or gui ? Some wise man once said If your computer can't install it the installer is broken. A script should or automation tool should be able to interact with the sites, not a human operating a mouse ;) It's not just the RSI , but also the fact that to err is human, and if the computer fails a script you can patch it :)

In his CloudCafe 18 Podcast John talks about Puppet to Luke and they coin the idea of Devministration

I really like the terminology, so I`m a devministrator, and probably the bigger part of Inuits are Devministrators.

The first stage in becoming a devministrator is using version control, then bugtracking .. etc.
Coming from an era where I was the sysadmin pushing the developers to use version control this sounds really strange to me..
Yes I had to convince developers to use version control, while Luke thinks he needs to convince sysadmins to use version control.
Weird.. other continent, other habits, but the important part is we all use it.

But the big part is that we don't spend our time managing servers, but rather scripting the automation of the management. Learning machines how they should manage our configs and automate.

Like the old Google saying, you have to automate yourself out of a job every 18 months.

Guess that's also what ad Devministrator is.

Twice in one day I was pointed to The Mantra .. the vision , the good practices on how to run an infrastructure. And because I fully agree with this way of runing an infrastructure I`ll highlight some of them again .

• Design For Change , the google way.. everything will be different the next time you look around
• Be reproducable , you have to be able to survive the 10th floor test .. yes even when building stuff
• Design Redundancy upfront , don't try to squeeze it in later .. it will be more expensive and you will be less flexible
• ...

Dormando has some more reading material.
And when you are done reading Go watch the video of Randy Shoups presentation on Amazon's infrastructure, because also at Amazon we can find 4 repeatedly discussed points in the Architectural strategy

• Partition Everything
• Automate Everything
• Async Everything
• Prepare for Failure

It's a repeating theme , with variations based on your specific problem domain.. but the central toughts stay the same.

Automate Everything




Expect Failure