Best location for sys admin scripts?

[Russ Hancock_1]

I'm currently setting up a new HPUX 11i system, decomissioning two other servers, my question is where ideally should our house applications and scripts reside?? We currently have them all under /usr, but is there a standard that says they should go elsewhere?

[Pete Randall]

Russ,

We put them in their own filesystem. In our case, we call it /apps. That way, a new install doesn't overwrite them (as with /usr/local/bin) - we just restore /apps.

Pete

[fg_1]

Hi there

Usually most in house/ad-hoc programs are loaded under the /opt filesystem. Also you
should ensure that this filesystem is large enough for sufficient growth of your log files for these applications, I tend to make my /opt
filesystems 1.5 to 2.0GB in size.

Good luck

Frank G.

[Stefan Farrelly]

If theyre local scripts they should go under /usr/local but instead of /usr/local/bin (for system wide local scripts that all users can run) you could put them under something like /usr/local/admin (root only can access).

[MANOJ SRIVASTAVA]

/usr/local/bin/subdirectory is where we keep all of our sysadmin scripts thsi is becasuse of 2 reasons

a. easier to specify in the path

b. the backups are taken with ignite , root fielsystems etc



Manoj Srivastava

[Jose Mosquera]

Hi,

If you have MC-ServiceGuard installed or you are planning, pls consider keep it in *shared* place!

Rgds.

[Rainer von Bongartz]

As these is otional software I put them under

/opt/sysadmin

Regards
Rainer

[Steven E. Protter]

Perhaps I'm old fashioned but.

Sysadmin scripts are in.

/usr/contrib/bin

Permissions in general are 700. That way when I decide users are allowed to use them, all I have to do is change permissions.

Nobody but root can write to /usr/contrib/bin on our system.

I'm a user right? root
I contributed the script right?
some of them came from this forum? cool

P

[James R. Ferguson]

Hi:

I like '/usr/local/' or '/usr/contrib/' for scripts used by root or scripts of general applicability. For scripts specific to database support, my preference is in a directory like '$HOME/oracle/'. For scripts specific to an application, I find a $HOME directory applicable.

Aside from standard file permissions, I'd make sure, too, that you set the sticky bit of the directory holding the scripts such that only the script's owner has the right to delete.

Most importantly, whatever you decide, be consistent.

Regards!

...JRF...

[Nigel Green]

I agree with JRF. Whatever the decision, stick to it, and make sure that everyone else knows that if a script is located elsewhere, it could well be moved/deleted.

I'm in the unpleasant situation of having some systems with scripts in up to 10 (yes ten) different locations. (including /usr/local, /usr/contrib, /home and application directories). What's worse is that some scripts from one location call scripts from others. Ah the joys of progressive development. Guess who's going to have to sort this out (eventually).

[Ian Dennison_1]

Here we have gone a slightly different route, by creating a 1GB lvol called /operations on all Servers, with subdirectories for bin, etc, log, and other directories for common data.

We found it better to create our own standard than try and re-organise the existing standards. It also gives is the ability to extend the filesystem without single-user mode, and protection of the OS lvols if scripts run over and fill up filesystems.

As long as you define a standard and stick to it, and cater for the most likely maintenance / disaster scenarios, you should be fine.

Share and Enjoy! Ian

[Mark Landin]

I usually try to keep "my" stuff (as opposed to HP's stuff) on separate volume groups so if I need to re-Ignite I don't automatically blow away all the non-HP stuff.

[Mark Greene_1]

All our "live" scripts on all our systems (HP, IBM, DG, RedHat) are in /usr/scripts. This standard started back in the day when this was a DG-only shop (before my time in IT, let alone here) and was done to avoid the unpleasantness found in losing them during an upgrade when /user/local/bin got overlayed.

Stuff for my own work and amusement sits in my home directory. The unwritten standard is that anything that goes into a crontab has to be moved to /usr/scripts. With only 3 admins, it's not too terribly difficult to deal with.

mark

[Dave La Mar]

Russ -
Our shop -

Oracle specific scripts:
/opt/apps/"specific subdirectory"

Root type scripts:

/usr/local/bin/"specific subdirectory"

In reading other responses, it appears one takes what is common to their shop and is consistent.

Best of luck.

dl

[John Bolene]

Our shop uses /usr/local/hertz for anything developed inhouse.

[Manju Kampli]

its been practice to put all the sysadmin scripts under /usr/local/bin directory..

few people put these scripts in a bundle and also install it using swinstall in /opt/ as well. (easy for administration of scripts across multiple systems)

HTH,
Manju

[Michael Tully]

You'll find a hundred different answers to this one. It purely will depend on the individual/admin team where it is best suited.
Some people place them in /usr/local/bin or somwhere else where it easily manageable. Some may have a standard bundle of tools deployed from sort of management server, where they could be developed. I have them (localised scripts) in a directory in /
The reason I do this is purely for convenience, where I may want to use them in single-user mode or doing some maintenance. Because of the small size of the number and size of the scripts in question, it does not pose a problem.

[Frank Slootweg]

See the hier(5) manual page (i.e. "man hier") for what should go where.

If this is purely local stuff, then it should probably go in /usr/local.