----- Original Message ----- > On Mon, 1 Jul 2013, Corey Quinn wrote: > > > Agreed-- but the counterpoint is that ops folks have to get better > > at > > development than they currently are to continue to thrive in this > > kind > > of environment. > > As a former developer, I have this covered. I sometimes forget there > are > a number of sysadmins who aren't so good at writing code. >
I'm a former developer too...and been dabbling on the side again recently... > > Whether it's easier to train an ops person to be better at > > development, > > or to instill an ops mentality in a developer, is left as an > > exercise > > for the reader. > > I wound up being a sysadmin because I was always the guy on the team > making sure all the little details were covered. I was the guy who > made > sure ALL of the stanza in a Makefile worked correctly. I was the guy > who > made sure the sandbox setups were completely correct, etc. > I was detail oriented, etc...but there was also a void that led me to wear the sysadmin hat. Until I found myself doing just sysadmin (and wanting to do more, there was a time that I wanted to know all areas here.... still would like to get to know our SAN, which is back to only one person know it....the original person, who has moved up where he's both coach and player $boss...he's asked a few times whether the sysadmin position he had before he became manager is available or not.) > > …but you can butter my biscuits and call me Sally if you think I'm > > about > > to sit and quietly take criticism of LOPSA from the guy who brought > > us > > the trainwreck that is CFengine (at least through version 2, > > haven't > > looked into 3). The picture he paints of the uninvolved sysadmin > > who > > forms the "Department of No" is *exactly* the kind of admins I've > > known > > in my career who recommend CFengine for deployment. > > > > The folks who "get it," the folks who are more disciplined in their > > approach, who learned to adapt? They're all deploying > > Chef/Puppet/Salt/Ansible and run screaming from CFengine. I'm not > > saying > > it's a causal relationship, but the correlation is definitely > > there. > > Most of the environments I've worked in have refused to even look at > any > kind of configuration management systems, including CFengine. I've > been > fighting for something in many of my previous jobs. Those are are > where a > lot of sysadmins we need to convert are working. Ones who think > "I've got > some Perl scripts. Why change?" > Our previous $boss had taking this stand....kept saying it would destroy systems. Which sure enough, it has. But, though all of them could've been avoid if the $admin causing it had paid better attention to the details. IE: add existing servers to firewall class, should come after ensuring firewall definitions are on policy server for existing servers. Replacing everything with generic firewall (closes everything except enough to do initial configuration from our admin range.) Which we discovered years later that he had cleaned up by disabling firewalls on a lot of hosts...which in one case had a server exposed that shouldn't have been, and where somebody had developed an app in his private VPS somewhere based on it being exposed (which he continued to maintain after he had left)....which I then got into trouble for breaking because I fixed the firewall. They eventually granted a policy exception for it to continue to work...before it was moved into the datacenter. It should never have been externally hosted, though for HIPPA reasons.... > I'm most interested in Chef. Salt looks worth watching, but I > wouldn't > deploy it in production yet. On the other hand, many of the > developers I > know are going nuts over Salt since it's the new shiney... That was how our $boss sold that he's scraping all the work in upgrading from CF2 to CF3, to go with Chef....even though he said right away, that a couple of key features in CFEngine that we depend on heavily aren't available in Chef. He had looked at Salt, but guess he never got it to go on Solaris. -- Who: Lawrence K. Chen, P.Eng. - W0LKC - Senior Unix Systems Administrator For: Enterprise Server Technologies (EST) -- & SafeZone Ally Snail: Computing and Telecommunications Services (CTS) Kansas State University, 109 East Stadium, Manhattan, KS 66506-3102 Phone: (785) 532-4916 - Fax: (785) 532-3515 - Email: [email protected] Web: http://www-personal.ksu.edu/~lkchen - Where: 11 Hale Library _______________________________________________ Discuss mailing list [email protected] https://lists.lopsa.org/cgi-bin/mailman/listinfo/discuss This list provided by the League of Professional System Administrators http://lopsa.org/
