Subscribe: A Day in the Life of a Senior Linux Admin & Infrastructure Architect
http://rss.ittoolbox.com/rss/linux-architect.xml
Preview: A Day in the Life of a Senior Linux Admin & Infrastructure Architect

A Day in the Life of a Senior Linux Admin & Infrastructure Architect



Follow along with one industry expert as he confronts the daily challenges that arise from various Linux implementations and infrastructure development opportunities within his company. With several years experience, this Senior Linux Admin & Infrastruct



Published: Sun, 20 Aug 2017 17:05:04 +0000

 



Sendmail on Solaris

Tue, 10 Aug 2004 04:55:09 GMT

One of the parts of my job that I enjoy least is nursing the few remaining Solaris boxes through the last few months of their life. Fortunately, a couple of my team members know a bit more Solaris than I do, so I can generally delegate tasks to them. Once in a while, however, something comes up that has them stumped; When that happens, I have to try and step up to the plate. This happened just the other day.



SuSE? Maybe...

Thu, 29 Jul 2004 06:09:32 GMT

I had a few comments and emails on my last post. Every single one was well reasoned, and defending SuSE against my unwarranted accusations. I'll be honest - I haven't seen SuSE in action for years, and one respondent is right - with Novell and IBM working together to promote it, it's definitely worth another look. I've taken that information on board, and will be taking a good look at it myself in the coming weeks.



Why Distribution reviews don't tell you enough.

Fri, 25 Jun 2004 07:01:43 GMT

Linux reviews are all flawed. I've never come across a good review of Debian, but somehow, despite this, all of the people I consider Linux professionals either use it or thoroughly respect it (while having made the decision to not use it for some reason that is valid for their purposes). Unfortunately most Linux reviews seem to focus on the installation process - the very early stages of your relationship with a product. And this simply isn't enough.



Challenges

Sun, 23 May 2004 00:00:44 GMT

I've been burned. Worst of all, I did it to myself. So, we've put this new application in. All singing and dancing - it's the first big project I've been involved with where I did the Infrastructure Architecture. In summary, if you only really learn from your mistakes then I've done a lot of on-the-job-learning in the last few months. The biggest, broadest lesson is "Challenge your Assumptions". I should have gone to great efforts to think very carefully about where I was working on assume



Managing 'your' time, when you have 200+ hours a week to watch

Sat, 08 May 2004 23:02:22 GMT

When you're leading a team, you're organising a lot more than 40 hours a week. You're also organising entities which aren't as communicative as your internal systems are. You need some sort of todo list system, you need you personal time management systems up to scratch, and you need to expand how you use them to cover your team. I'm not saying you need to manage time for the whole team like you do for yourself, but you do need to know what you've aked people to do, when you've asked them to



Linux is more than Redhat.

Fri, 09 Apr 2004 23:14:29 GMT

This article is (broadly) a response to Linux Loyalists Leery as posted on the Forbes website 31/03/2004. You may like to read that first, then come on back.



Development knowledge handy

Sat, 03 Apr 2004 19:43:34 GMT

In my current role, I don't do any real development work - a bit of shell scripting or Perl, maybe a little php coming up, but no real development. Despite this, the development knowledge I've picked up on previous roles has proven itself once again.



Geek->Manager

Wed, 24 Mar 2004 04:35:16 GMT

If you've had good managers, think back to what made them good - think about things that you liked about them, that made them a good manager for you. Try and adopt certain of their traits.



Testing documentation.

Sat, 13 Mar 2004 01:21:50 GMT

Writing documentation is the first hurdle, but it's one we all know we need to do. But has your documentation been tested? For a recent project, my team has been building a bunch of servers, and installing middleware applications of various types on them. We've gone the whole hog on source control - both config files and installation documentation are in SubVersion. What we haven't done so far is to test those config files and that documentation.



Documentation Woes

Thu, 04 Mar 2004 22:59:49 GMT

One of the benefits of working with open source is the "release early, release often" principle - we get new software quickly. One of the founding principles of Unix applications is that they do one thing, and they do it well - if you want an application that combines the two, well, then you have the tools to do it.This leads to a problem - when you're using three quite new applications in conjunction, instructions on how to combine them to best effect can be rather lacking - you spend a lot of