I haven't summarized the response since I think each one has unique
ideas that may help some people do their jobs.
Thanks for all of the responses
art hebert
>From mgh@bihobl2.bih.harvard.edu Tue Oct 5 13:19 PDT 1993
1. backups
2. Meet with supervisor and get HIS/HER top 10 tasks
2. Meet with user base and get THEIR top 10 tasks
3. solve all printing issues
4. upgrade existing software
5. Clean up maintenance of hardware/software
6. Clean up disk space/usage
7. Prepare "state of the system" report - outline your agenda to supervisor/users
8. Order all books needs, get on needed (this one!) mailing lists
9. Get overall picture of network (schema)
10. Have fun!
>From pln@egret1.Stanford.EDU Tue Oct 5 14:41 PDT 1993
Your idea about backups is certainly a good one.
I think you should devote a big chunk of time to study, even if
you can't show a measurable goal that will come out of it.
There are two things you should study in parallel:
1. Theory. Read the nasty Novell manuals and other stuff.
2. How it's set up now. Look at all the files in /etc on your
unix machines until you understand why things are set up as they
are.
>From hushing@gdwest.gd.com Tue Oct 5 15:00 PDT 1993
1st thing I would do is understand and document the existing setup.
That could take weeks, depending on network size, and available
documentation left over from the last sysadmin. Preserving what's
there, with regular backups, is part of this process.
2nd: Put together a written near-term (1993-94) plan for your activities.
Item 1 above is in there, but don't wait for the plan to start it.
Polling the net was a good idea for this.
3rd: Follow your plan. :-)
Find out what hardware/software upgrades, routine maintenance, etc, was
already planned, or should be in the near-term plan. Find out who your
vendors are, and what replacement costs are. Have it all ready for
that first failure or upgrade request.
>From fetrow@biostat.washington.edu Tue Oct 5 15:17 PDT 1993
Talk to previous admin.
Find the previous admins. notes and logs.
Make sure backups are functioning.
Find gurus for major systems, bribe heavily. (This is no joke,
system administration was once a completely oral tradition and
while this is less so now, Gurus are necessary)
Find the manuals, buy new ones if necessary plus a couple
good books on sys admin for Unix and Novell.
Read the books.
Make sure backups and restores are functioning.
Talk to major users and find out what they are doing and
what they want to be doing.
Familiarize self with major apps..at least a little.
Make sure backups and restores are functioning and some are
kept offsite.
Familiarize self with the local culture. You don't want to
play politics but you do want to know what is expected of
you. Trades are possible: e.g. a pager in trade for flextime.
Make sure licenses are up to date and software is legit.
Whatever you do: Don't go update happy until you know how
everything fits together.
>From burdick@eagle.mcclellan.af.mil Tue Oct 5 15:34 PDT 1993
>From Day 1, practice Configuration Mgt and try to get a _GOOD_ baseline -
then document all changes.
When possible, get a cadre of 'techies' to use as alpha testers of planned
changes. (Should there be any other kind of changes?)
>From jkays@msc.edu Tue Oct 5 17:01 PDT 1993
Well, here's a small list. I don't know much about Novell, so i can't
help you there, but these are things I'd probably check (not necessarily
in any particular order).
1. Compile a list of server configurations - dkinfo information,
partitioning scheme, defect lists, etc.
2. Do some security checks. check for the big holes, like NFS setup,
exported file systems, rhost files. Perhaps run a security checker
program like cops. maybe even change root and other passwords.
3. Verify any networking security mechanisms that should be in place,
like firewalls.
4. Make sure you have properly functioning backups.
5. Understand any maintenance contracts you have, make sure they're up
to date.
6. Finally, talk to people there, find out what they think need to be
done or what's lacking.
>From drew@mtu.edu Tue Oct 5 17:51 PDT 1993
Hi art. well, I should probably give a bit more thought to this,
but here's my llist, not in any particular order.
make sure backups are functioning :) (given)
take inventory of all hardware and software, and find out which
things work and which don't.
find out what THEY want of you (specific duties, along with general)
take time to understand network layout and topology.
learn the current filesystem / network /server / client configuration
to see if you can figure out what strategy is being used in
the setup, if any.
find out what policies they have in place regarding computing
determine 'plan of attack' and what future plans they have,
how well things are working for them now, and so on.
Find out what they like and don't like, and what works
well and what works poorly, about the current system.
Well, that's only seven things, but these are the thoughts that first
came to my mind. When I began my job as admin for this department,
they had no idea what was going on, and the guy who was here before me
had left without notice, without a word, and didn't leave any sort of
documentation around as to how things were running and stuff. Document
ALL. :) Seriously though, my biggest stumbling block was in figuring
out what was going on already. Also, you can't rely on management to
give you priorities all the time, as they often don't know.
>From rackow@mcs.anl.gov Tue Oct 5 18:04 PDT 1993
0. Determine where your responsibilites lie. This should have happened
before you took the job, but sometimes in the interview process, etc
things get foggy. What can you do vs what are you expected to do. Are
they giving you the power to take care of the machines properly, or are
they making you a straw-man for when the world falls apart. If you are
going to be responsible for when things break, get the power and authority
to piss some of the users off if you think it is necessary. If you don't
get the authority to do things the way you think is needed, your going to
be fighting a battle all the time.
Now once that is done...
1. make sure backups are working, complete with restore capabilities.
many times people will do backups, but fail to see that they are readable.
2. determine who has and who needs root access to the system. take it
away from people that don't have good reason to have it. politics are
not a reason to have root access. The president does not need root unless
he is technically capable of using it. Remeber that if someone else
has root, they may (read will) mess up what you have done.
3. Check the system for security problems. get copies of Cops and the news
ISS scanner.
4. Install security patches as needed.
5. Check out your network. Do you knwo who and what is on your network?
6. Verify your user base. Are the people using the accounts the ones you
expect. This goes beyond root access. Ex-employees still having accounts,
some developers girl friend, etc.
7. Get email working properly. Once you have this in place, make sure that
people in the company know how to and that they are expected to use it for
support related functions. The biggest problem I've had with users is they
will catch me in the hall between meetings or something and tell me something
is wrong. Once back in the office I have no clue as to what they wanted.
If they send email, I can get to it.
8. get to know your users and what they want. Stop in and see as many as
possible, get below the dept heads and talk to the users. Find out what
problems they have needing fixes or time applied. It's amazing how many
allies you can get by installing a few things like perl, tcl, and other
freely available tools.
9. check backup schedule AGAIN. never hurts to retest things.
10. recheck security, are things still as they were, did someone change things
out from under you before you had complete control or understanding.
11. Go back to the top. Recheck to see that what yuo are doing matches
expectations. Run through the rest of the list as well.
12. Once you get to know who some of the key players are, attempt to
schedule time with them for planning and expectation sessions. What do
they want and were would they really like to be vs what is real. Sometimes
is best to do this as 2 meeting formats.
1 "over beers" where it is really friendly, loose, and people can air
their gripes without fear of retribution, This is more the "ideal world"
time. What would I do IF ...
2 "somewhat formal" where people are living within current reality
and politics. This is for the more urgent needs and where things really
stand.
>From vasey@issi.com Tue Oct 5 20:19 PDT 1993
The job is never-ending in terms of tasks to be done ... and redone.
Two things I'd suggest from the outset, however:
1) Clarify what is expected from you, starting with your PRIMARY boss
-- even though in practice you may have several. This will both help
establish some lines of authority/support when the going gets tough,
and also help you delineate a reasonable working environment (or not,
but it's better to find that out sooner rather than later). In many
cases s/he won't know what to tell you, either, so INSIST on having
a weekly sit-down meeting to review and set/agree on work priorities.
Doesn't have to be long -- 30 minutes will do wonders for both of you.
2) Schedule and publicize a weekly "open meeting" (same time/place/etc.)
for anyone to request job status, present new work requests, generally
discuss future needs and directions and learn from you how things work.
There's nothing better than open communications to keep you accountable
and help both users and managers understand how complex -- and busy! --
your job can become at times -- and they WILL understand if you're honest
AND doing your job. Also, users often make GOOD suggestions on schedule
changes or workarounds they can accept, and there's nothing like face-
to-face meetings to clarify (usually simplify!) fuzzy requirements fast!
After ~15 years in the business, I can flatly state these "things to do"
have consistently reaped the biggest rewards -- and even appreciation --
of anything else I've done. I hope they work for you also. Good luck!
>From cross@engfs.med.ge.com Tue Oct 5 23:45 PDT 1993
1) Make sure all backups are OK, ie
that they are being done
That you can recover any or all of the data required.
(it is no ggod having a backup if you can not recover the
file, either because it a physical copy and you must copy all or none
or that you do have have a emergancy boot system to recover startup
files etc).
2) Understand exactly is on the network and how they are configured
without this you dont stand a chance at finding problems
and can not make any changes
3) Ask the users which extra facilities they want,
you may need to make some changes so complete (2) above
4) Ask the managers what they want from the system
They pay the bills so they need to see any changes you make
helping them/the company.
5) MAke sure that the system is secure, and define the interfaces to the
outside world, you may not have any external connections yet, but its best
to plan for some and make sure you are secure.
5s not exactly 10 but its a good start, completing 1,2,5 will make your life
easier, 3 and 4 will make you look good to the users/managers and
give you some hints as to where you will be expected to change the system
One good plan is to carry out a business review of the companys IT
aiming to follow the data flow and the needs of each department, its
amazing just how many managers will go without and not complain/ask
for very simple tools which make life so much easier. And adding them
normally takes very little time and you get mega browny points.
Mike
>From ajw@ansa.co.uk Wed Oct 6 01:38 PDT 1993
I'd give a high priority to finding all the distribution media for the software
you're running, esp operating systems, and putting them all in a Safe Place, so
that you can find them quickly when disaster strikes. For Suns, make sure that
you know how to boot from the distribution media and do all the disk-massaging
(formatting, partitioning, building and fsck'ing file systems, installing boot
sectors) that might be necessary after a really bad disk disaster. This sort of
thing invariably happens when someone is in a tearing hurry, and it's always
difficult to find the right section of the manual when your office is full of
panicing users shouting about their deadlines :-).
If your people are internetted, getting to know your router is a high priority.
If you are the sole administrator, you are the only person who knows anything
about it at all - it's transparent to the users, who just believe they are "on
the net". Make sure that your defences against attack from malicious intruders
coming in over the net are secure.
Other than that - work on developing a thick skin. Support people get no thanks
when it goes right, but find themselves in the spotlight when things go wrong!
>From pbrunk@ai.uga.edu Wed Oct 6 02:24 PDT 1993
Check out anti-virus software for your PCs!!
I recently inherited a network which had virtually none. I put it on my
list of things to do but most of my time is spent troubleshooting and I
didn't get to install any. You can guess what happened.
If your network is homogeneous it shouldn't be too bad to keep things up to
date. I use F-PROT from Frisk in Iceland. There's also scan from McAfee.
Both are cheap (something like a dollar per machine) and regularly updated.
McAfee posts weekly updates, they say. I haven't confirmed this. F-Prot
has a new version every couple of months. (Upgrades are free after the
original site license.) Both are FTPable; just lurk on comp.virus if you
have newsreader access.
Something else coming to mind is check out what kind of maintenance
contract your hardware is under, if any. I'm not saying you must be under
one, just that it's something you definitely want to know either way.
Make sure everyone knows policies. Etc. Enjoy.
>From barney@sgi50.wwb.noaa.gov Wed Oct 6 04:28 PDT 1993
Establish a good and close rapport with your new user community.
Without that you don't have much. FInd out where they are and
what they need.
>From rae@nvg_troy.nvg.com Wed Oct 6 05:22 PDT 1993
There is no standard "Top 10" list for systems and network
administration but, this is my personal "Top 10":
1. Backups of all critical database and user data
2. efficient network utilization (watch for excessive NFS mounting,etc)
3. Security (passwords on all user accounts)
4. Preventive Maintenance on Hardware
5. Preventive Maintenance on Software (disks, OS, etc)
6. SA management scripts (a great timesaver,ie: adduser, setup new seat) 7. New user training guide (procedures)
8. Learn about Novell (if you really have to)
>From admin@gilligan.UCSD.EDU Wed Oct 6 08:28 PDT 1993
Good Question! As a network administrator myself, one thing I've found indispensible is keeping a LOG BOOK of all system modifications/settings. This should be something you implement from the onset, and remember to update every time you modify ANYTHING on your network.
For example:
- LOG all DMA and IRQ settings for new devices, as well as
port addresses.
- LOG all mods to network software (like NFS and NIS files)
- LOG any strange messages, errors, or other system activity
which might appear on the network...remember to include info
about dates and times of first incidence!
In a sense, log evrything you do! It may take a little bit more time, but the first time you come to work Monday morning to find the network crashed, and you don't know why, you'll thank yourself for having that record - I know I have...
>From everling@iis.fhg.de Wed Oct 6 08:46 PDT 1993
Make in inventory of what kind of hardware lies where,
which software is installed where, Operating System,
Userlists, Operation areas, Licenses for software,
hardware possible improvements, Printers, Servers, Disks.
Do write some nice letters of whax 2 do when You're on holiday.
Backup, Rebooting procedures.
Look after mail systems.
Customize User requirements (installing, deleting, editing).
Power fail systems attending.
Room layout structures regarding overheating of computers.
Connection layouts, possible faults, improvements.
Updating of software.
>From etnibsd!vsh@uunet.UU.NET Wed Oct 6 08:48 PDT 1993
Top ten:
Make sure backups are functioning
Make sure backups are functioning
Make sure backups are functioning
Make sure backups are functioning
Make sure backups are functioning
Make sure backups are functioning
Make sure backups are functioning
Make sure backups are functioning
Make sure backups are functioning
Make sure backups are functioning
Others:
Change superuser password on all machines
Install sudo and establish superuser access policy
Run cops
If on internet, evaluate firewall security
>From bern@kleopatra.Uni-Trier.DE Wed Oct 6 09:30 PDT 1993
Depends heavily on the Kind of Work done on these Computers. Ours here
(University, i.e., Research and Text and SOME Data Crunching every now
and then) require me to make the following really sure:
1) Backups
2) EMail, especially no lost Mails
3) Keep common Applications runnable (OW, LaTeX, Printer Stuff) so that
Users won't get lost by having to print on "lp" where they used to
print to "lw" ;-)
4) Have Hardware Backups ready to go
5) Some reasonable Quota Stuff to prevent sudden Overfilling of the FSes
If, e.g., the Computers in Question control CNC Machines and cause some
real $$$ of Loss whenever they go down, you might have these Priorities:
1) Hot Hardware Backups
2) Intruder Prevention
3) Reliability Tests of Software
4) Have regular Hard- & Software Tests (swapping in the Backup Hardware
for the Time)
5) Define fixed, secure Access Mechanisms for Software Uploads (e.g., a
new Program composed by the CAD Staff)
>From ekurgpol@Law.USC.EDU Wed Oct 6 09:44 PDT 1993
Art, I have the same type of position now. Here's my suggestions:
1. Map out the network.
2. Print off all disk and partition info on _paper_.
3. Yes, make sure backups are working.
4. Become familiar with all systems, if not already (in your case, get
some Novell training-- I don't know Novell either :-)
5. Develop emergency shutdown procedures.
6. Figure out a way to monitor problems, ie disk space and
network traffic-- management loves to hear about traffic. Use something
like SunNet Mangler.
7. Find out what the staff needs out of their network, and not just the
management.
8. Develop a filing system to track problems on a per-system basis.
9. Get a set of O'Reilly books.
10. Hire an assistant to do all the mundane stuff, and ask for more
money.
>From rogerio@jessica.bvl.pt Wed Oct 6 12:39 PDT 1993
Another one is get a MAP of the network AND CHECK IT !
Find out where are the originals of the operating systems
and applications.
Locate the maintenance contracts (iff there are any) and inform them
of the new contact.
Dump of scripts in use....
Do your first GLOBAL backup (use belt and suspenders).
>From ju@compwr.com Wed Oct 6 15:22 PDT 1993
1. Make sure backups are done consistently and are readable.
2. Find out what software (and version) is loaded on each system.
3. Make sure all software is available and in-house.
4. Make sure all systems are secure, or as secure as company policy requires.
5. Make sure you can rebuild all systems from backups, system software,
including any tuning or configuration changes.
6. Find out who has and uses root access and whether they know what they are
doing (helpers!) or are dangerous (yikes, there goes another file...).
Thanks go to:
>From mgh@bihobl2.bih.harvard.edu Tue Oct 5 13:19 PDT 1993
>From pln@egret1.Stanford.EDU Tue Oct 5 14:41 PDT 1993
>From hushing@gdwest.gd.com Tue Oct 5 15:00 PDT 1993
>From fetrow@biostat.washington.edu Tue Oct 5 15:17 PDT 1993
>From burdick@eagle.mcclellan.af.mil Tue Oct 5 15:34 PDT 1993
>From jkays@msc.edu Tue Oct 5 17:01 PDT 1993
>From drew@mtu.edu Tue Oct 5 17:51 PDT 1993
>From rackow@mcs.anl.gov Tue Oct 5 18:04 PDT 1993
>From vasey@issi.com Tue Oct 5 20:19 PDT 1993
>From cross@engfs.med.ge.com Tue Oct 5 23:45 PDT 1993
>From ajw@ansa.co.uk Wed Oct 6 01:38 PDT 1993
>From pbrunk@ai.uga.edu Wed Oct 6 02:24 PDT 1993
>From barney@sgi50.wwb.noaa.gov Wed Oct 6 04:28 PDT 1993
>From rae@nvg_troy.nvg.com Wed Oct 6 05:22 PDT 1993
>From admin@gilligan.UCSD.EDU Wed Oct 6 08:28 PDT 1993
>From everling@iis.fhg.de Wed Oct 6 08:46 PDT 1993
>From etnibsd!vsh@uunet.UU.NET Wed Oct 6 08:48 PDT 1993
>From bern@kleopatra.Uni-Trier.DE Wed Oct 6 09:30 PDT 1993
>From ekurgpol@Law.USC.EDU Wed Oct 6 09:44 PDT 1993
>From rogerio@jessica.bvl.pt Wed Oct 6 12:39 PDT 1993
>From ju@compwr.com Wed Oct 6 15:22 PDT 1993
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:08:23 CDT