What is the first 10 things I should do as a newbie with no real experience?

Find out how things work, and make sure they work properly. Remember, you'll be the one fixing stuff when it breaks.

I would:

1. Make sure the backups are running
2. Perform a restore to make sure the backups are working as well
3. Locate, study and verify all existing documentation (you'll probably find lots of errors and out-of-date information)
4. Locate all passwords for administrative accounts
5. Change all passwords for administrative accounts, one by one
6. Fix the stuff that broke when you did 5.
7. Verify that alerts are working (RAID errors, UPS alerts, drive space warnings etc)
8. Do a licensing audit
9. Study the disaster recovery procedure
10. Since step 9 probably meant studying a blank piece of paper, create said procedure from scratch

And at every step, consider whether it would make sense to hire outside help.

5 members found this post helpful.

I'd amend that with:

• Write your own documentation
  • Document EVERYTHING.

I have a terrible memory after 18 years of SysAdmin'ing, (the basics are never an issue) and have to write my "own documentation" in the form of my blog.


Prepare for the worst but Hope for the Best.
Find another seasoned SysAdmin or two that you can bounce stuff off of. Not the usual petty user-related stuff, but admin-related stuff.


Here's a GSE (Google Custom Search) that I maintain that searches 44 Linux-specific sites.


I hope you have the Linux basics. ("no real experience"). If you truly don't have any experience, then this will keep you awake at night, but this will allow you to sleep.

And good luck.

1 members found this post helpful.

thanks Ser Olmy and Habitual for your useful information.. Learned a lot from them.

When you write documentation/tickets be very detailed not only for others but also for yourself.

Usually what I do is write a summary up top for management/high level for myself and later on I put in the ugly technical details (ie commands, outputs, etc).

Generally, I find ticketing is mainly for my own memory rather than having to reinvent the wheel for what I've done.

Was always bad at that documentation thing, but one thing I learnt was to stop using scraps of paper. Use spiral bound notepads. Date them, so you at least know the order of the pads. One day, among the scribbles and the trivia, you will find the very thing you need to know and forgot.

however... I am about to start something that I tried to keep up to date back in working days. Ask yourself what information you need when your machine is down, and print it out. Keep it in an indexed folder.

The classic thing for me was the IBM RS-6000 flashing digit (888?) thing. The meanings should not be on the machine itself. Learnt the hard way.

These days, stuff like that is on the net. How to fix Grub? I just walk over to the other machine in the house and google it. But still I'm going to print it. When you are panicking, Google can get you deeper in trouble very quickly.

Network certification: Hmmm... I never had a certificate for anything...

I was never a network engineer, but I was a systems manager, and that includes networking. Here's an example of when to call someone in: I knew the LAN stuff and a little bit more; I could administer and even re-install (yes, my own stupidity!) the firewall. I was responsible for defining its rules anyway. But I didn't speak cisco. I knew a man that did, and his rates were reasonable. Where you start: google "TCP/IP basics" or "TCP/IP Tutorial."

Make sure your bosses understand what you are and are not qualified (on paper or by experience) to do. They should be supporting your learning experience, not blaming you for everything you got wrong.

Send real hard copy letter with email copy to each of your upper level managers. Tell them that you really require more training for this new task.

Do this only if your position in the company is secure and they are known to provide training.

I don't recommend the boot camp type deals. They only get you ready for the cert tests. You need real training at a place where you can learn, try and remember. A local school may be the best place if your company doesn't have in-house training.

Ok. do good documentation. Got it.

I did change the passwords very carefully.

I did tell upper management that my background is in software engineering.

I am backing data to the cloud as per the owners wishes.

As for the schooling part, what classes do you recommend I take from the local community college.?

Regarding classes, how much experience do you have with Linux in general and the distribution that you use in your office? If starting from utter zero, I'd say begin with something like the very lowest level Red Hat course (033 IIRC). Note that you can learn quite a lot yourself from books and self study, but if you go that route, don't turn the production systems into your personal testing playground -- establish your own test bed on your workstation or a spare machine. Fortunately, the wide availabiltiy of free virtualization software makes this very easily. Speaking of books, I'd recommend taking a long look through this classic.

Along with all the essential advice mentioned above, gather the following information about your site. For each computer at your site, maintain documenation such as the following:

- Computer name.
- IP address.
- Operating system and release level.
- Internally available services.
- Externally available services.
- List of users or groups permitted to login to the system.
- List of users or groups (including yourself) that have superuser privilege.

More general site-wide policies that should be documented:

- Is there a central directory service (NIS, LDAP, AD, etc.) for user accounts, or are accounts provisioned on an ad-hoc basis?
- How many users are there, total?
- Is there any configuration management (e.g. Puppet, CFEngine, Chef) deployed? Are there SOPs for deploying new machines?
- Likewise do you have monitoring software (e.g. Nagios) that can notify you if something goes wrong?
- Are there any other company regulations or laws/policies/regulations (such as PCI-DSS. SOX, HIPPA, etc.) that apply to your situation? If so, are you in compliance? How will you make sure you stay in compliance?

Finally, don't neglect security! Make sure you review the CERT checklist for Unix security and other trusted resources. I believe that if you mosey over to the security forum here at LQ, there's a sticky of resources put together by the real experts on this topic. I'd prepare to spend some serious time reading through them.

Finally, good luck. Don't worry about certs etc. I've been a professional sysadmin (as defined as someone else pays me to manage computer systems) for around a decade now and have never bothered to pick up a cert. Certs have their place in the world, but I don't think they're particularly necessary. That being said, if your company provides reimbursment for training expenses or will pay you to be certified, picking up a Red Hat or LPI cert probably wouldn't be a bad thing.

All good advice and some good links above.

I'd definitely start with documenting the current setup and keep those docs away from the machines they refer to ... not much help if the machine is down

Create your own test machine(s)

There's plenty of free to read manuals here http://www.linuxtopia.org/online_boo...ion_index.html.

Don't worry that there's an infinite amt of stuff you could know; concentrate the stuff that relates to your current setup.