Slashdot Mirror

First, read the PSNA if you haven't already, it features good ideas on documentation and especially process and how to deal with "layer 8" (management, users, whatever is the "real world" for you).

Next step is the wiki. You seem to already have that, good. People here have suggested SemanticWiki, but I'll point you towards Ikiwiki as it has the advantage of (a) being git based so completely decentralised (have a copy of your files on your laptop during a downtime!) and (b) written in perl so you can probably extend it.

Make sure people know where your wiki is and *use* it, so it doesn't become this rotten piece of outdated documentation out there. You have only started to understand how this is going to be a pain: documenting is hard long-term work. there's a (bad) reason why people don't do it effectively: it takes time and dedication.

Next you can consider using dedicated tools for certain things like inventory or issue tracking. We have used Request Tracker with good success. It's a very solid product that does a lot, also in Perl, coincidentally enough. It also has the Asset Tracker plugin to follow inventory, but i haven't personnally used that, although I had good feedback from peers that used it successfully in an heterogeneous environment. An alternative is OCS inventory, which I haven't used either.

So, just bite the bullet: you're going in the right direction. Just consider the right tool for the right job is your next step, i guess.

Well, good for Google. But no, they're not the Internet, just an important part of it. Less important, really, than all the network backbone providers and retail ISPs. Without them, Google's IPv6 interfaces are inaccessible.

The fact that Google has done this and almost nobody else has reflects the positive side of their unstructured organization: if somebody sees a problem that they think needs solving, they just go and solve it, no need to ask permission. Traditional organization tend to trip over their own bureaucracy on stuff like this. (Among other reasons.

But there is a downside: problems that don't catch anybody's imagination just never get solved. Which is why Google never gets around to cleaning up all the little glitches that prevent their products from transitioning out of Beta mode.

Seconded.

The authors (Limoncelli and Hogan) have a page about the book

First off, you can't go wrong with Essential System Administration, 3rd Edition by Aeleen Frisch. Really, really excellent book.

But just as important as the specifics of Unix, I'd argue, is the general question of how to be a good sysadmin. ("Start by installing Linux" is my usual smart-ass answer, but I'll skip that for right now...) The Practice of System and Network Administration, 2nd Edition, by Tom Limoncelli, Christine Hogan and Strata Chalup, is a truly excellent book about how to be a good sysadmin in the general case. I can't recommend it enough. (BTW, the link for the book comes from the authors' website, so I presume it throws them a few nickels if you buy it that way.)

Here is a video I made that is a summary of 7-8 tips from the book. More info on www.EverythingSysadmin.com

1) In most companies, the job of IS is to help the company make money. So I can see where you have a difference of opinion. Sometimes the job is to make it easier or possible for the company to make money.

2) IS (like security) is a cross functional group and is involved with every group in the company at some level. Because your job is to make their job easier. Computers are like a lever or other tool to make work easier, you help them figure out how to use this force multiplier or lever (or make it easier to use the lever).

3) If you are overloaded you need better time management goals and prioritization. Sometimes it has to get worse before it gets better. If you implement some things that save administration time with top priority, you may get more back logged at first, but the queue will clear as the time savers kick in. You need to switch from reactive mode to proactive.

Making the switch from reactive to proactive takes time, money, smarts and a smooth political hand.

Check out this book:

http://www.everythingsysadmin.com/

it has invaluable practical advice for all of these problems. It is not specifically a technical book.

-A

http://www.jetcafe.org/~npc/book/sendmail/

A good book on sendmail performance tuning, although a lot of it covers the OS.

Then get The Practice of System and Network Administration.

http://www.everythingsysadmin.com/

revision control, backups, security, servers,

Sounds like you need a book on systems administration. I recommend The Practice of System and Network Administration. The authors have a website.

An excellent book is "The Practice of System and Network Administration" by Thomas A. Limoncelli, Christine Hogan. (ISBN: 0201702711) It is theory not necessarily platform specific. It is focused at unix, but can be applied in a windoze environment. I wish I had read that book years ago. It really does a good job of summarizing all the best practices. It's all the things they don't teach in school. http://www.everythingsysadmin.com/aboutbook.html There are links to reviews there. The average customer review on amazon is 4.5/5.

As far as pulling cable and doing the physical grunt work..make sure you do structured wiring otherwise you end up with a rats nest of wire. Over plan everything. Don't forget the simple stuff, have a dedicated circuit or two for the server(s) and network equipment with adequate UPS protection. Make sure the room is adequately ventialated and physically secure. Make sure you have room to grow, so when you need more equipment you have room for it or can easily make room for it.

• http://www.iec.org/online/tutorials/scs/
• http://www.swhowto.com/ (Geared more a home, but for small office would be comparable)
• http://www.hometech.com/acrobat/structured.pdf
• http://electrical.bobvila.com/Article/540.html

The book The Practice of System and Network Administration has a few excelent chapters covering everything you need to think about when planning a data center. It's a great book.

In the category of "essential" books for whatever we are calling sysadmins these days, we must includeThe Practice of System and Network Administration. 'Nuff said.

In this article I write about some of the most common mistakes that I see on resumés, and how you can avoid them.

I proofread resumés for friends... a lot. With the economy heating up I'm getting asked to more frequently. I find that technical people often have difficulty "selling" themselves. While "The Practice of System and Network Administration" (co-authored with Christine Hogan) has tips on hiring sysadmins, we didn't include specific resumé-writing tips. Therefore, I thought it might be useful to write down the thoughts I have in this area. (Our negotiation section does have tips on how to negotiate your salary, but that's putting the cart ahead of the horse.) How do employers process resumés?It's important to write your resumé to be useful from the perspective of your potential employer. In writing they say, play to your audience.

That is, an action film is expected to have an explosion or something major in the first scene, a romance is expected to introduce at least one of the main people in the first 5 minutes, Steven King always includes the elements that his fans expect. A resumé has to be written for its audience too. What are the audiences of a resumé?What makes writing a resumé difficult is that there are two audiences.

First is the non-technical HR clerk that receives the resumé. If it gets past the clerk, it will arrive at the desk of the person that will be your future boss. Your resumé has to have the elements that will please both of these people: The HR clerk The first person to see your resumé, sadly, is a non-technical clerk who is handed 10,000 resumés a day and a list of positions that need to be filled. This person does the first level of sorting. Your job is to make sure you get through this person's selection criteria. The problem here is that this person doesn't know the difference between UNIX and Solaris, or that if someone knows Solaris 2.5 then they are hirable for a Solaris 2.6 job. Luckily, this person only reads the top part of every resumé, so you make make sure that you have "Objective" and "Skills" sections made just for him/her. Don't say "Solaris 2.6", say "Solaris 2.x" or just "Solaris" (people have forgotten about Solaris 1.x by now).

The Hiring Manager Each pile that the clerk created is handed to an appropriate "Hiring Manager." This person does understand the technology that you'll be working with, or at least they think they do. The rest of the resumé must be in their language. The most common mistake that I see is that people don't write anything for the clerk. Therefore, their resumé never gets to the hiring manager.

The "Objective Statement" and "Skills" section at the top of your resumé is what the clerk reads. Make sure your resumé has these sections and make them clear. Typically I see resumés without an "Objective Statement" at all! Tip 1: A good "Objective" statementA good objective statement tells a plainly-stated title you would like ("UNIX programmer", "CGI Developer", "Project Manager", etc.) and a couple skills that you have ("excellent writing skills", "experience with digital audio technology", "experience with large development projects", etc).

If you aren't sure what your title is called, look at a couple job advertising web sites to fill you in.

You can also specify what industry or department you want to be in ("financial services", "telecommunication", ".COM", etc.).

Here are some good ones that I've seen:

1. Objective: A position as a Senior UNIX/Linux Developer that lets me utilize my years of experience in the TDM cellular technology.
2. Objective: A position as a Project Manager in the EDA industry that lets me utilize my excellent communication and presentation skills.
3. Objective: A position as a Junior UNIX/Solaris Sysadmin (SAGE Level II) in the financial services industry that lets me utilize my superior Solaris knowledge.
4. Objective: An entry-level position as a HP-UX/UNIX Sysadmin that enables me to demonstrate my ability to learn on the job.

• Objective: I am an expert in building large, scalable services based on open protocols.

How could the clerk classify such a resumé?

A better statement would have been: "A senior architect of UNIX-based email and web services that lets me utilize my experience in building extremely scalable systems with high up-times." He did change his resumé to something similar, and soon started getting phone calls. Tip 2: A good "Skills" sectionUse buzzwords. There is a reason for them, it makes communication faster. I hate "buzzword compliant" presentations, but only when they aren't adding any value to the statement. When they appear on a resumé they do add value because the clerk undestands them. Better-trained clerks are given a list of synonyms. For example: they might be told "We need a Solaris sysadmin... but that means anyone that mentions Sun, SunOS, or UNIX should be considered. Oh, other synonyms for UNIX are: AIX, Linux, IRIX... a person that knows any of those but wants to learn Solaris is fine for this position." However, that doesn't always happen so it is ok to be a little redundent: I include the word UNIX in addition to the name the vendor uses (i.e. "Solaris/UNIX" or "Red Hat/Linux/UNIX").

List the best skills first. I see many "skills" sections that list 20 operating systems or 20 languages or 20 vendors and that's a fine way to show that you have a lot of experience over many years. However, the person reading your resumé is only going to read the first 3-4, so make sure those are the ones you want to work in.

A friend listed the languages she knew in the order she learned them. Which of the these two would a clerk find most useful if he/she was told to find a "Windows C++ programmer"?

BASIC, Pascal, C-64 BASIC, AppleBasic, Cobal, Fortran, C, awk, C++, Visual C++, Perl

Perl, Visual C++, C++, awk, C, Fortran, Cobal, AppleBasic, C-64 Basic, Pascal, BASIC.

While I'm at it, I believe one should delete the super-old technologies like Commodore 64 and Apple II unless, of course, you are applying to work someplace that still uses those technologies.

A concise way to list skills is to group them. The first example below is the most concise, the others are longer.

Skills:

Operating systems: Unix (FreeBSD, Solaris, Linux), Windows 95/98/2000/NT, and others.

Here are some other good examples of "Skills" listings that I've seen:

Skills:

Operating systems: Unix (FreeBSD, Solaris, Linux), Windows 95/98/2000/NT, Cisco IOS 7.x-12.x, plus some experience with AIX, HP-UX, OpenVMS, NetBSD, OpenBSD and others.

Programming Languages: Perl/CGI/mod_perl, C/C++, HTML, Unix shells and tools, awk/sed, SQL, Python, Pascal, BASIC.

Network Products: Cisco Routers, Cisco Switches, Cisco PIX Firewalls and Cisco IP Telephony equipment (ICS7750); Checkpoint FW-1; Linux/Unix firewalls (IPFilter, IPFW); Avaya Cajun products; Network General Sniffer, tcpdump, Ethereal, Snort.

Network Technologies: FastEthernet, Gigabit Ethernet, FDDI, OSPF, BGP, ATM.

Tip 3: ClassificationsIf you are a sysadmin, use the SAGE Job Classifications to describe yourself and/or the position you are looking for. More and more HR departments are using them, and certainly the cool companies that you want to work for are using them. However, explain enough so that someone that hasn't read http://sageweb.sage.org/resources/publications/8_j obs/ will understand what you mean. That's why the above example was redundant: "a Junior UNIX/Solaris Sysadmin (SAGE Level II)". Tip 4: Pick a good filenameNever use a filename like resume.doc when sending your resumé as an attachment. Name the file something like resume_tom_limoncelli.doc so that if the HR person saves it, he or she will be able to easily tell yours from someone else's...and your resumé won't be overwritten the next time someone else sends them a file called resume.doc. (Thanks to my friend Tina for this tip.) ConclusionA good resumé is your key to finding a new job. However, you'll never find a job if your resumé doesn't reach the right people. Making your "Objective" and "Skills" sections complete and accurate is how you make sure it reaches the right people. Tom Limoncelli is co-author of The Practice of System and Network Administration with Christine Hogan, Director of Network Operations at Lumeta Corp. and maintains www.EverythingSysadmin.com. He can be reached at talsagewire@whatexit.org.

In this article I write about some of the most common mistakes that I see on resumés, and how you can avoid them.

I proofread resumés for friends... a lot. With the economy heating up I'm getting asked to more frequently. I find that technical people often have difficulty "selling" themselves. While "The Practice of System and Network Administration" (co-authored with Christine Hogan) has tips on hiring sysadmins, we didn't include specific resumé-writing tips. Therefore, I thought it might be useful to write down the thoughts I have in this area. (Our negotiation section does have tips on how to negotiate your salary, but that's putting the cart ahead of the horse.) How do employers process resumés?It's important to write your resumé to be useful from the perspective of your potential employer. In writing they say, play to your audience.

That is, an action film is expected to have an explosion or something major in the first scene, a romance is expected to introduce at least one of the main people in the first 5 minutes, Steven King always includes the elements that his fans expect. A resumé has to be written for its audience too. What are the audiences of a resumé?What makes writing a resumé difficult is that there are two audiences.

First is the non-technical HR clerk that receives the resumé. If it gets past the clerk, it will arrive at the desk of the person that will be your future boss. Your resumé has to have the elements that will please both of these people: The HR clerk The first person to see your resumé, sadly, is a non-technical clerk who is handed 10,000 resumés a day and a list of positions that need to be filled. This person does the first level of sorting. Your job is to make sure you get through this person's selection criteria. The problem here is that this person doesn't know the difference between UNIX and Solaris, or that if someone knows Solaris 2.5 then they are hirable for a Solaris 2.6 job. Luckily, this person only reads the top part of every resumé, so you make make sure that you have "Objective" and "Skills" sections made just for him/her. Don't say "Solaris 2.6", say "Solaris 2.x" or just "Solaris" (people have forgotten about Solaris 1.x by now).

The Hiring Manager Each pile that the clerk created is handed to an appropriate "Hiring Manager." This person does understand the technology that you'll be working with, or at least they think they do. The rest of the resumé must be in their language. The most common mistake that I see is that people don't write anything for the clerk. Therefore, their resumé never gets to the hiring manager.

The "Objective Statement" and "Skills" section at the top of your resumé is what the clerk reads. Make sure your resumé has these sections and make them clear. Typically I see resumés without an "Objective Statement" at all! Tip 1: A good "Objective" statementA good objective statement tells a plainly-stated title you would like ("UNIX programmer", "CGI Developer", "Project Manager", etc.) and a couple skills that you have ("excellent writing skills", "experience with digital audio technology", "experience with large development projects", etc).

If you aren't sure what your title is called, look at a couple job advertising web sites to fill you in.

You can also specify what industry or department you want to be in ("financial services", "telecommunication", ".COM", etc.).

Here are some good ones that I've seen:

1. Objective: A position as a Senior UNIX/Linux Developer that lets me utilize my years of experience in the TDM cellular technology.
2. Objective: A position as a Project Manager in the EDA industry that lets me utilize my excellent communication and presentation skills.
3. Objective: A position as a Junior UNIX/Solaris Sysadmin (SAGE Level II) in the financial services industry that lets me utilize my superior Solaris knowledge.
4. Objective: An entry-level position as a HP-UX/UNIX Sysadmin that enables me to demonstrate my ability to learn on the job.

• Objective: I am an expert in building large, scalable services based on open protocols.

How could the clerk classify such a resumé?

A better statement would have been: "A senior architect of UNIX-based email and web services that lets me utilize my experience in building extremely scalable systems with high up-times." He did change his resumé to something similar, and soon started getting phone calls. Tip 2: A good "Skills" sectionUse buzzwords. There is a reason for them, it makes communication faster. I hate "buzzword compliant" presentations, but only when they aren't adding any value to the statement. When they appear on a resumé they do add value because the clerk undestands them. Better-trained clerks are given a list of synonyms. For example: they might be told "We need a Solaris sysadmin... but that means anyone that mentions Sun, SunOS, or UNIX should be considered. Oh, other synonyms for UNIX are: AIX, Linux, IRIX... a person that knows any of those but wants to learn Solaris is fine for this position." However, that doesn't always happen so it is ok to be a little redundent: I include the word UNIX in addition to the name the vendor uses (i.e. "Solaris/UNIX" or "Red Hat/Linux/UNIX").

List the best skills first. I see many "skills" sections that list 20 operating systems or 20 languages or 20 vendors and that's a fine way to show that you have a lot of experience over many years. However, the person reading your resumé is only going to read the first 3-4, so make sure those are the ones you want to work in.

A friend listed the languages she knew in the order she learned them. Which of the these two would a clerk find most useful if he/she was told to find a "Windows C++ programmer"?

BASIC, Pascal, C-64 BASIC, AppleBasic, Cobal, Fortran, C, awk, C++, Visual C++, Perl

Perl, Visual C++, C++, awk, C, Fortran, Cobal, AppleBasic, C-64 Basic, Pascal, BASIC.

While I'm at it, I believe one should delete the super-old technologies like Commodore 64 and Apple II unless, of course, you are applying to work someplace that still uses those technologies.

A concise way to list skills is to group them. The first example below is the most concise, the others are longer.

Skills:

Operating systems: Unix (FreeBSD, Solaris, Linux), Windows 95/98/2000/NT, and others.

Here are some other good examples of "Skills" listings that I've seen:

Skills:

Operating systems: Unix (FreeBSD, Solaris, Linux), Windows 95/98/2000/NT, Cisco IOS 7.x-12.x, plus some experience with AIX, HP-UX, OpenVMS, NetBSD, OpenBSD and others.

Programming Languages: Perl/CGI/mod_perl, C/C++, HTML, Unix shells and tools, awk/sed, SQL, Python, Pascal, BASIC.

Network Products: Cisco Routers, Cisco Switches, Cisco PIX Firewalls and Cisco IP Telephony equipment (ICS7750); Checkpoint FW-1; Linux/Unix firewalls (IPFilter, IPFW); Avaya Cajun products; Network General Sniffer, tcpdump, Ethereal, Snort.

Network Technologies: FastEthernet, Gigabit Ethernet, FDDI, OSPF, BGP, ATM.

Tip 3: ClassificationsIf you are a sysadmin, use the SAGE Job Classifications to describe yourself and/or the position you are looking for. More and more HR departments are using them, and certainly the cool companies that you want to work for are using them. However, explain enough so that someone that hasn't read http://sageweb.sage.org/resources/publications/8_j obs/ will understand what you mean. That's why the above example was redundant: "a Junior UNIX/Solaris Sysadmin (SAGE Level II)". Tip 4: Pick a good filenameNever use a filename like resume.doc when sending your resumé as an attachment. Name the file something like resume_tom_limoncelli.doc so that if the HR person saves it, he or she will be able to easily tell yours from someone else's...and your resumé won't be overwritten the next time someone else sends them a file called resume.doc. (Thanks to my friend Tina for this tip.) ConclusionA good resumé is your key to finding a new job. However, you'll never find a job if your resumé doesn't reach the right people. Making your "Objective" and "Skills" sections complete and accurate is how you make sure it reaches the right people. Tom Limoncelli is co-author of The Practice of System and Network Administration with Christine Hogan, Director of Network Operations at Lumeta Corp. and maintains www.EverythingSysadmin.com. He can be reached at talsagewire@whatexit.org.

We have a web site about the book called www.EverythingSysadmin.com which includes a free copy of Appendix B (which, by the way, is my favorite chapter). And I would be remiss if I didn't mention that Amazon sells it too.

I hope you enjoy it!