> 05. Technical Services Committee is looking for Volunteers > > 1) Infra Team > The Infra Team is responsible for the ongoing day-to-day operations of > LOPSA's infrastructure. This team does things like set up mailing lists, > email accounts/aliases, set up Apache vhosts, respond to monitoring > alerts, and handle any tickets that come in from other LOPSA committees. > LOPSA's infrastructure is made up of Linux (CentOS), Drupal, CiviCRM, > Apache, Mailman, check_mk, and RT. > > Bonus points: We don't currently use any config management, but absolutely > should be. If you have experience retrofitting CM into a legacy > environment and want to do it, send us an email! > > Experience in any of these is awesome. Ideal volunteers have at least 2 > years experience as a Linux admin. Commitment time is about 2-3 hours a > month. You should also be awesome at documentation. >
So, I was mulling this LOPSAGram item.... Don't most site deploying a CM, start with a legacy environment? Or sites with long running/legacy servers considered an outside case for CM deployments. Well...we did have huge problems cause by other SAs when we were plunged into CFEngine. The SA that set it up, had started that a friend at where he was looking to leave us for told him that CFEngine experience would be a huge benefit... And, at first he would break legacy systems, including systems that he shouldn't be touching (or especially...) While another SA it was routine for him to destroy all the systems he was responsible for with it. Like putting his entire group into the firewall policy class, without check any of his Solaris servers to get handled correctly. They all got generic firewalls - install access only, which existed because he got our datacenter botted once by jumping a new server and then forgetting about it....so by default it was open to the world and had telnet, which had a well known exploit, enabled..... So, installing cfengine and a first run was part of the completion of a jumpstart, where the first run does some generic things like setup a very basic firewall and turn off unnecessary services like telnet. Though we also stopped doing jumpstarts in the open range in the datacenter that is outside of its firewall (and we didn't get a border firewall until a year or two ago.) Our previous manager had been against such things, because she kept saying it would destroy everything....last year it nearly did. A trivial programming error written by some one that proclaimed he was a god of python programming, and had friends that backed him on it. Resulted in every system getting 0 byte passwd files. Since execution was cron driven....things stayed broken until we could intervene....suspect cfexecd scheduled would've allowed us to recover faster/easier....since many systems continued to run, just couldn't log into them or make changes. Including a production system for a couple of months before there were configuration changes we couldn't put off any longer. There's at least a size check on the copy now.... Meanwhile...when I decided it was time to learn CFengine 3...since the latest upgrade attempt from 2.x to 3.x seemed imminent....and because I was in the process of setting up two new servers at home (FreeBSD 9.x based, to replace a pair of Ubuntu LTS that will be EOL next month). At first, it was because I wanted something better than the cron/rsync scripts I was using to synchronize configurations on Ubuntu and work on breaking some of the bad habits I had picked up from some of my now former colleagues. As well as learn other things on my own. But, turned out to be pretty legacy-ish, as I was starting from scratch with CFEngine, and had already done quite a big of stuff by hand on the new servers. Things continue to evolve....and the much more legacy (my Ubuntu servers) has been much slower going...as those are mainly using CFEngine to address current issues....like needing to fix permissions for a nagios plugin, everytime the package is updated (by unattended-upgrades.) And, I don't interact with these (wired) systems directly as much...so not finding myself add/modifying things in CFEngine for them. Where sometimes I'll blow a whole weekend in CFEngine because I decide that I going to have CFEngine promise it now and in the future....which has nothing to do with the projects I had planned to tackle that weekend :) Sometimes I don't even end up addressing the problem that I dove in for.... Though I have been thinking about how to manage my Ubuntu laptop with CFEngine... And, I've decided continue with CFEngine 3.x at home, even though as the SA working on our CFEngine 3 upgrade at work was about to go live....it got the axe, in favor of Chef. The initial big reason was that there's no reporting/dashboard in community edition CFEngine. So boss decided that we'll go Chef. Though the Chef is for new servers going forward....where everything under CFEngine will eventually go away....(which may happen sooner than later....) Knife was also a factor...since with one group...we had been managing the servers with CFEngine, and they had been managing their applications with Puppet...and they've been pushing that they be enabled to become like devops with their systems. So we share a Chef server with them, and there's plans to do the same with one or two other groups. Though both managers that were behind the Chef/Devops move have left us for greener jobs elsewhere. Though there has also been a surprise that we have since purchased Enterprise Chef. Now, I'd be lying if I said I wasn't curious about helping with these things at LOPSA...but unfortunately, I'm barely handling my life now.... _______________________________________________ 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/
