getting started

[khilari]

Hi people, i wanted to ask from ur experience that if u start a new contract what the first thing u would do. How would u blend into the organization. Lets say the environment is 20 hp servers 5 sun servers. On every hp server one application is running. So, now as a unix system admin how would u get started. What are the steps u would take to get accostomed to the systems.

[Rick Garland]

Get the tool 'cfg2html' (if not already is use). Gp throught the putput and note LVM, networking, backups, Oracle, MC/SG, etc.

Know what the systems are and their capabilities and roles and their available resources. Who is the user community that is impacted by a server? What app is on what server?

Just a start. A lot of these answers will depend on your environment.

[Jeff_Traigle]

I'm partial to the method of simply poking around the systems and seeing how things are configured. What cron jobs are running, how authentication and security are configured, where they have custom scripts and programs, etc. And, of course, digging into the areas specific to assignments/requests/tickets as they come your way. It also helps to be nosy in what other members of the group are working on to help you get a somewhat bigger picture view of happenings and changes in the environment beyond what you are specifically working on. It's a lengthy and ongoing process.

[Sundar_7 · Accepted solution]

I guess approach will differ. But here is what I would do

1) Understand what the systems are used for. Have your teamlead/colleague walk you through the setup. Take notes

2) Understand change/problem management process. This is especially important if you are not working on internal systems

3) Browse the work instructions/tech docs. This is typically maintained in a centralized location electronically

4) Login to set of servers each day. See what is running in the system and their dependencies

5) develop a high level understanding of the highly visible critical systems/applications in the setup. Explore them.

6) You can establish a good rapport easily if you can suggest some improvements to existing process from what you learned in your previous assignments. But just be sure not to hurt anyone's ego who is already working there. Be friendly to them, atleast till you establish yourself in the new place :-).

7) dig, dig and dig around deep and wide.


Good luck

Sundar.

[jamesps]

1. First of all get a network diagram and see what's where and get the traffic map. That would include the physical location, wiring, etc.

2. Get credentials (user/pass) to access the servers, check on who else has access (admin rights) to those servers. You would want to know who are you interferring with.

3. Get the security information, policies, VPN accounts, emergency procedures if something goes bad, etc.

4. Log into each one of them, netstat, ps them and see what they're running. Put this info on the network diagram created at the first step.

5. It would be nice to get (if it's not already available) a hardware inventory as well, disk space avail, etc.

6. Determine the requirements, availability, redundancy, see what they expect from you.

7. Determine the risks, where are they, what can you do to fix them, etc. You don't want to assume fault for somebody else's :)

hth,
james

[A. Clay Stephenson]

Unless they are well-documented, by far, the most difficult and most dangerous things to identify are "unused" disks. It is very easy to find "unused" devices via ioscan and only discover after you have built a file system on them that they were in use by Oracle. Note the use of the past tense "were" because you just crashed the database. Even more difficult to identify than raw disk usage by databases (because that is more or less expected) is raw disk usage by some other application. Don't over look swap usage and don't assume that just because a fisk (or LUN) is not under LVM or VxVM that it is not being used directly as a raw disk. Sadly, there is no "Magic Bullet" that will identify these "unused" disks. Elmer Fudd would say "Be vewwy, vewwy careful."