DO and DON'T for sys admin

[Printaporn_1]

Hi,
Easy points and for experience sharing.
What is DO and DON't for sys admin like this simple things:

1.every use rm -rf be sure that you're in right directory.
2.moving large file better use copy and delete in case system fail halfway.
3. Don't let /tmp file system full that cause lot of problem.

etc....

[steven Burgess_2]

Hi

Make sure you get proper labels for tapes - have had instance recently where they get stuck in drives because mgment won't buy correct labels

Steve

[Patrick Wallek]

The biggest as far as I am concerned:

DO be ethical. DON'T use your access to look at information you shouldn't.

If you make a mistake, DO admit to it. I would much rather work with someone that admits to making a mistake rather than covering it up.

[kish_1]

When you get error message read properlly and understand it, half of the problem will be solved

[Tom Geudens]

DO
- take backups
- test recovery (taking backups is fine, but knowing they're fine is better)
- communicate (with DBA's for example :-)
- know what your systems looks like "normally" (CPU/Memory/IO)
- trust in God, but make SURE of those backups

DONT
- trust a single source of information (especially not vendors)

[S.K. Chan]

DO
- Spend more time in detail planning before execution (eg: migration, upgrade, etc, etc)
- Lock screen at all time when not around.
- Document if you think you'll forget new tips and commands that you've just learnt.
- Keep history logging.
- Be nice, the last thing we need is and arrogant sysadmin.

DON'T
- Abuse root access.
- Use "kill -9" unless you have no choice.
- Always take shortcuts (eg: "reboot -q")
- Write your passwod down, keep it in your head.
- Assume !
- Be careless.

[Michael Tully]

Check 'root' mail
Check /var/adm/syslog/syslog.log
Check backup results
Check the /var/adm/su log
Use 'sudo' wherever possible
Always create an ignite tape before loading any patch.
Don't let a DBA have the 'root' password, unless you are the DBA...
Regularly check system performance.
Regularly check file system percentages.
Automate whatever you can into email or smtp traps.

[John Carr_2]

Hi

DONT

- create users with UID zero
- divulage root password
- leave terminals or console logged in as root.
- forget to place tapes in drive for backups

DO

- be nice to everyone
- be professional
- share your knowledge

John

[hpuxrox]

Always run a fresh Ignite image before any change.

-Yates

[Gnananandhan]

Do's
Document all resources.
Make a note all changes and updation.
Do Backup regularly.
Note down critical issue for future reference.
Verify log files and ensure it is enabled always.
Check for i/o and memory activity
Passwd aging, passwd and group checking.


DON'T
Sharing of resources without approval.
Ignoring error message in the console.
loose coupling file and directory permission.

[John Carr_2]

Hi

DO

ensure when you change the root password you make one other person aware. If you have a policy of standard root passwords on a series of servers which you change and you get killed in an accident without telling anyone a whole lot of people will be very upset for more than one reason.

DONT

forget to tell someone

cheers
John.

[Rainer von Bongartz]

DO:
keep you system up to date; install patches or quality packs on a regular basis.

DON'T
forget to make recovery tapes
after each change

[Prakash Achuthan]

DO's

1. Use Sudo for providing limited sysadmin rights to others.

DONts,

1. Never give the ROOT password to anybody unless you have sufficient confidence in his Unix knowledge.

[John Carr_2]

Hi

DONT

use production systems for testing or learning.

DO

buy a cheap workstaion and learn, B or C class will do just about everything in HPUX.

John.

[Stefan Schulz]

Hope this is a addition to the other posts.

DO
-use passwords
-use comments in scripts especially when changing system/standard scripts


DONT
-change the root shell
-just assume something, always check first to be sure


Regards Stefan

[U.SivaKumar_2]

hi,
Take a copy of any configuration file before editing the file for new configuration.

Have copies of output of commands like bdf , strings lvmtab , vgdisplay , kmtune , ioscan
stored in the same server and also in a different server for facilitating system recovery and helping support people.

regards,
U.SivaKumar

[steven Burgess_2]

Hi

DO

Always test any changes before applying them

DONT

Assume you have got it right

Steve

[Sebastian Galeski_1]

Hi
- write few scripts which will check main logs file
- do not share root password,
- do not create scripts with permision -s,
- everyday do backup of production data,
- before any changes in OS do full backup useing proper tools (fbackup),
- You should have at least one copy of make_recovery or make_tape_recovery tape
- You should check at least once if You can restore data from backup

[Alexander M. Ermes]

Hi there.
Just my two cent :

DO :

communicate with people.
Sometimes they point you in the right direction.
Try to be nice to people, who are not computer pro's like you.
You might speak a language, they do not understand.
Put an envelope with the most important passwords in a fireproof cabinet and tell your boss.
In case you are not available, boss may be happy to know.

BACKUPS BACKUPS BACKUPS
RECOVERY TAPES RECOVERY TYPES RECOVERY TAPES
might save your job.

In Germany you will be held responsible for the loss of data by law.

DON'T

transport tapes in a Volkswagen beetle on the right seat in the back.
Data loss will be the result.

hot backups of databases, if possible

Never share root password with dba's

run testjobs on a production application
( hard to explain to the boss )

with all respects to all of you, who have had the same hard experience mentioned in the postings before mine

Alexander M. Ermes

[Klaus Crusius]

DON'T
remove /etc/passwd and the log out.

DO
log all system changes you make
save major configuration files

[H.Merijn Brand (procura]

DO

- read the forum
- answer forum questions you know the answer to
- asign points to all answers
- read the answers *after* your problem is solved
- learn perl
- simplify your admin life by writing perl scripts
- put those scripts in cron
- check their status from mail
- have fun
- use open source software (GNU in particular)

DON'T

- Leave the forum
- stop reading the thread once your problem is solved
- learn python
- learn COBOL
- learn BASIC
- use M$ Windows
- spread viri
- drink and drive
- put your passwords on the net

[BFA6]

DO
Keep set of backups off site.

Make copies of config files before editing.

DONT
Use same tape, night after night, after night.

Leave backup tapes on the floor, next to leaky air con unit.

Hilary

[Bill McNAMARA_1]

If it works, don't try to make it work better.

If it doesn't work, copy and comment changes rather than delete/edit.

Later,
Bill

[Sukant Naik]

Hi,

DOs
Always maintain a log of all server information with you. I use the script below to do it.

NAME=abc.xyz.com
mkdir /user2/ignite/servers/$NAME
echo " Started on $NAME server"
cd /user2/ignite/servers/$NAME
remsh $NAME -l root -n /usr/sbin/ioscan -fn > ioscan.$NAME
remsh $NAME -l root -n cat /etc/lvmtab > lvmtab.$NAME
remsh $NAME -l root -n /usr/sbin/vgdisplay -v > vgdisplay.$NAME
remsh $NAME -l root -n cat /etc/passwd > passwd.$NAME
remsh $NAME -l root -n cat /etc/hosts > hosts.$NAME
remsh $NAME -l root -n cat /etc/group > group.$NAME
remsh $NAME -l root -n bdf > bdf.$NAME
remsh $NAME -l root -n cat /etc/fstab > fstab.$NAME
remsh $NAME -l root -n /usr/sbin/swlist > swlist.$NAME
remsh $NAME -l root -n cat /stand/system > system.$NAME
remsh $NAME -l root -n ll /dev/*/group > vggroup.$NAME
echo " Completed on $NAME server"


Donts,
Always check the syslog file for errors.
Be calm in panicky conditions and most of the problems can be solved.

-Sukant

[George_Dodds]

Dont think you know it all.
Dont be afraid to ask for help.

Do document your system's properly
Do have a DR plan.