SCALE 9x Conference, Day 1
I wasn’t really sure what to expect when going to a Linux Conference. I’m not a Linux guru, although I’m learning and I like it a lot. But I don’t have that mentality – I’m not one of the open source fanatics. Don’t get me wrong, I don’t think it’s bad, I just like a little more established products and support for those products. Sure, I use open source products, but I don’t go out of my way to find them.
Linux has it’s own culture, so I was curious to meet the people who were at this conference. They were actually pretty normal (Or, maybe they weren’t and I’m just assimilating!) I did get a few laughs out of the day: As I’m driving in I see a car in the parking lot that has a bumper sticker that says Linux. The other sticker on the car says “There’s no place like 127.0.0.1” (For all of you non-nerds, 127.0.0.1 is the local address of the server, which is often called “home”; so “There’s no place like home”.)
Eric told me the first day I became a SysAdmin that in order to be a real SysAdmin, I needed to grow a beard and wear plaid. I told him that wasn’t going to happen. We were joking about wearing our plaid to the conference, and I recently actually got a plaid dress, so I told them I was going to wear it. They said no. They didn’t want to have to fend off all the guys from a young sysadmin girl wearing plaid. Haha. Anyways, the first guy that I’m talking to in line no joke is wearing plaid and has a beard! I almost started laughing right then!
Another funny thing that I noticed was that a guy was taking his notes from his mac on his Linux machine. He was ssh’d in to a server or somewhere and using “Vi” to type his notes from the session. (I know half of you won’t get what I’m talking about. You’ll just have to trust me that this is nerdy! 🙂 )
The session that I went to was really good. It was about security. A few things that caught my attention for our environment:
He talked about authorization and how technical controls should be set so that a user’s authorization is removed after the person no longer needs access. A procedural control (someone going down their checklist to make sure the person has been removed when they leave) isn’t as useful, because people will often forget to inform someone to remove the user. By creating technical controls that are automated, the users’ account could be closed if they don’t log in for 90 days, or something similar to that so that it’s automated. I’m all about automation!
Also, he talked about patching and making sure that it’s automated so you don’t have to manually have to do it.
Another thing that I’m interested in is configuration management. He discussed using Chef or Puppet to put a file on the Puppet Server and then that one file will be pushed out to all of your servers. This is wonderful because of the fact that you won’t have to go to every server and put the one changed file on them all. You can just have them all look to the server for specific files and then push changes to them. It’s like they’re all listening to the one server (I think).
I’m not too familiar with it, but Eric recently set up a Puppet server for us and has been testing it. I’m curious and want to try it out. Eric and I went to lunch and I had a really good salad and we had a good talk about security and our environment (We both went to the same session, so it was helpful to be able to go over it all and discuss what things would be good for us).
There’s always a risk if the data is stored somewhere. Unless you have it locked up in a safe in your house (and even then it might not be safe from theft) there’s the possibility of it being stolen if it’s on the network. If it’s stored somewhere, that means someone could access the repository. So if you don’t want anyone to know, keep it in your mind. Until they figure out a way to look at the contents of your mind while you’re sleeping, you’re probably safe.
The second session that I went to for the day was about “DevOps”. This is a new term talking about making sure the Developers and Operations teams work closely together. Normally they are very different. Ops is about not taking risks and keeping things up. Developers are to make new products, innovate, change the status quo. It’s risky.
A few good thoughts:
Make sure to have Ops team members in the meeting when starting a new project- even if the meeting will only be applicable and about Ops for 15%, as it will bring up important topics.
Don’t have people/developers who just ask for “6 boxes”; rather have them explain the problem they’re having and work together to find a solution.
Have Devs work with Ops after the product has launched to see what problems have happened on the Ops team due to the launch; then they’ll write better code when they see all the work that it causes the Ops team when there’s poorly written code.