Will try Puppet and Chef .

Thanks for the nice post.

“From Luke Kanies, Puppet’s author: I was a sysadmin by trade and had mostly developed in perl, but when I tried to write the prototype I had in mind, I couldn’t get the class relationships I wanted in perl. I tried Python, because this was around 2003 and Python was the next new thing and everyone was saying how great it is, but I just can’t seem to write in Python at all. A friend had said he’d heard Ruby was cool, so I gave it a try, and in four hours I went from never having seen a line of it to having a working prototype. I haven’t looked back since then, and haven’t regretted the choice.”

http://reductivelabs.com/trac/puppet/wiki/FrequentlyAskedQuestions#why-is-puppet-written-in-ruby

Thanks for the comment, and yeah, you’re not alone. It does sound like you’ve got a leg up on the non-developer sysadmins, though, and that’s great! Have you started implementing any of the configuration management solutions?

In the last couple of years, I’m doing more of compiling and fixing software that we buy or setting more open sources applications that “developers” used to setup. The developers of the past are now the “project managers” of projects, and usually have the development work outsourced or pushed to a UNIX sysadmin.

Lately I’ve been setting up Apache servers with Catalina and Derby and fixing some of the code that some Indian Developers are sending.

Consider aviation, automobiles, warfare, plumbing …. basically any other industry or technology. They didnt build the stealth bomber before they flew at kitty hawk. They didnt have water reclamation and desalination plants before they had basic plumbing.

IT is still a technical problem and will be for a long time – treating it as marketing, sales or some business centric division just creates a large competitive advantage for the other guy. Your people will spend months firefighting, filling out tickets, forms and performing data entry never getting to address the core problem – which is still a technical issue.

ITIL is perfect for non-technical IT shops, highly SLA centric IT shops and similar situations where the work being done should be minimal change and rigidly organized. Rapid change, engineering environments and reactive/adaptive environments either crash and burn (all productive work stops) or immediately trim the ITIL process down to a loose framework of “ITSM best practices” that are automated, but still make the business happy. (eg the svn/cvs/git repository is “release management” and similar concessions)

I’m not persuaded by the Ruby statement but the general premise of the article is interesting. I’ve found Infrastructures.org quite an interesting site that provides some starting points for system administrators to infrastructure administrators.

For me the truth is “I feel that any sysadmin today who isn’t learning ITIL will be unemployed in 5 years”.

So the tool (cfengine, puppet, …), is not the greatest part of the configuration management.

I should admit, I am VERY biased. My current position has been struggling with the fact that technically I am now a DBA but I know things their systems administrators don’t (previously I had shared responsibility for windows servers), I have a deep understanding on networking, I know some about security (I’m usually consulted on SQL injection issues), and I’ve successfully completed programming projects (primarily when its a non-.NET language which our official core competency). We’re currently in the process of a reorganization and no one is sure which pillar to put me in, since I do work in all three (my philosophy is they pay me, so while I’m there I do whatever is in their best interest assuming its legal and moral). I’m known as some one who can pick things up very quickly, and I honestly credit that to the fact that I have technological interests across the board and have been fortunate enough to be exposed to talented individuals in the various aspects of computers.

Matt S’s approach is an approach I’ve participated in in the past. Slowly but surely brought in new systems under the guise of ‘updating and improving’, which was a secondary gain next to getting a single consolidated and manageable way of doing things.

That does make it difficult. Especially when there’s already a “solution” that people trust. And honestly, if the solution works, maybe it’s not so bad.

But if you ever find yourself in the position of re-engineering the equipment, maybe you should make it a point to gradually edge in modern configuration management.

Good luck. I’d be interested in hearing more of your infrastructure (not to mention the trials you probably go through to get stuff to work)

@Matt
Point being is that I totally agree, if you are a good SysAdmin, you are actually a developer.

Besides, a question for all:
A product would usually contain not just compiled code, but also a handful of tightly coupled stuff that is also a part of an application, such as packaging the product, configuring the OS for the product, some support scripts for the product, etc. All of these are responsibilities of who? a SysAdmin in a development team? a developer? a SysAdeveloper?