Where do you keep your home-grown scripts?

[Tim Medford]

The last sysadmin here stuffed all user related scripts in /usr/bin and most system related scripts (backups, monitoring, etc...) in /usr/sbin.

This scheme seems to work ok since root has /usr/sbin in his path and all developers have /usr/bin in theirs, but this has caused me grief a number of times. Locating all these scripts before a cold install is just one example.

Do most folks just create a custom folder and then add it to the path in /etc/profile? Suggestions?

Thanks,
Tim

[Cheryl Griffin]

/usr/contrib/bin

[Jean-Luc Oudart · Accepted solution]

We keep our own stuff in /usr/local/bin
(system wide)

Application related scripts are kept in a dedicated application directory (such as /appl01/scripts)

Rgds,
Jean-Luc

[Pete Randall]

Tim,

I've seen stuff put in /usr/local/bin (by me in the past), /usr/contrib/bin, even, as you point out, /usr/bin and /usr/sbin. I prefer to keep them completely separate so that an install doesn't wipe them out. We have a separate filesystem call /apps for all our programs, scripts, etc. After losing a couple of things in the past, I now put all my stuff in /apps as well.


Pete

[Steven E. Protter]

/usr/contrib/bin

User contributed scripts go there.

Thats how the last guy did it and it would have been too much of a pain to change it. Besides, I saw no reason to change it.

Our two database apps have their own script libraries under the binary filesystem. That makes sense for organizational purposes.

SEP

[Marco Santerre]

Most of our production scripts which have been written by us or by other SA are located in /usr/contrib/bin.

When we test, we have a separate file system exclusively for that purpose.

[Sridhar Bhaskarla]

Hi Tim,

Most of the SAs use /usr/local/bin for keeping their script. With these default directories, there is a chance that the names of the scripts may conflict with third party and other contributed software.

I personally go for a different directory (ex /usr/local/scripts) and only add that to the local .profile files instead of /etc/profile or /etc/PATH.

But this is just my opinion.

-Sri

[Chris Watkins_1]

I put admin/util/mon/clean scripts and such in /usr/local/bin.
I suppose if I had started out that way, /usr/contrib/bin
would have been just as good a place as any.
Either way, they get caught with the Ignite images and backups.
(As for permissions, /usr/local is more open than /usr/contrib by default...
but the majority of my scripts get set to r-x for root only anyhow.)

I also have /dev/current/old versions stashed on my workstation.
A simple "runonall" or "putonall" script keeps versions
current, once the latest "dev" script goes "prod".

As for application-related scripts, batch scripts, etc...
they're on a separate vg altogether, in various locations
mounted under /apps. We tend to keep things with the application
that actually needs them, for scripts like that.
It also makes life easier if/when you ever need to
install or upgrade... since they're not on the root vg.
As you've already seen... everybody has their own way :-)

[Kenneth Platz]

By convention we keep our sysadmin-related stuff in /root/scripts.

I keep my personal scripts in $HOME/bin

[Bill Hassell]

I think everyone will agree that /usr/bin is the wrong place...

I use /usr/contrib/bin for general scripts because /usr/local directory permissions have been badly broken for many years (try ll /usr/local and look at the terrible 777 permissions!) I like to keep sysadmin scripts in root's $HOME which of course is NEVER to be left at / (I use /root). I create /root/bin and then put all the custom root-only scripts there. Then propagate the /root/bin directory to other systems as needed.

I also try to keep $PATH under control. Some sysadmins have dozens of possible directories stored in /etc/PATH, most of which are never needed, or could be eliminated with symlinks in standard directories. /etc/PATH (and the individual user's $PATH) should be examined regularly to see if any 777 directories are present. These directories are often used for Trojan scripts like su...

[Mic V.]

I put them in /opt/local/* (full tree just like /). I version them with RCS and build SD-UX packages, which I keep in a depot on my Ignite server with other software.

I also insist that each application have its own local directory for home-grown stuff (under RCS/SD-UX if I can) or use the application owner's home dir.

For example, Oracle has /opt/oracle/local and Baan has /apps/Baan4b/bse/mchip. (I didn't name it all. :)

I agree /usr/bin is not good. I personally don't usually use /usr/local because I feel it's one of the first places a {h,cr}acker would look. On rare occasions I use it, I use it for stuff *not* under RCS/SD-UX control. I also avoid /usr/contrib because the OS install puts stuff there. I try to use a completely separate structure.

My $.02, no big deal.

Mic

[Michael Tully]

We use /techsupp/util for home grown scripts, primarily because of legacy systems. Scripts and programs supplied by outside sources (from the porting centre) for example we place into /usr/contrib/bin so we know the origin of them. Once scripts are about to be placed into production they are put into RCS.

[MarkSyder]

I always put them in /usr/sbin so I can run them from anywhere, but I always put mark at the beginning of the name. That way, if I go off long-term sick or move to another job, anyone else who works on the systems will know who created the script.

For example, I have sam configured to run as a gui on my PC in a script called marks_sam.ksh - the default is that it only runs as a gui on the console.

Mark Syder (like the drink but spelt different)

[Jeroen Peereboom]

L.S.

In addition to the answers of all the other colleagues:
I would choose a directory that is NOT used by others. So not /usr/bin and so on as these are system directories, but also not /usr/local/bin since many GNU software packages install in this directory. I want it separate from everything else.

Furthermore:
- I use RCS somewhere under root's homedir (which in my case is not '/') to keep track of versions
- The only modification I have in /etc/profile is to source /etc/porifle.local, if it exists. Since the /etc/profile is a systemwide profile, this is NOT the place to add things which are for root only.
But you have developers too, so maybe you want to add it there (with or without testing for the UID or even the GID from the developers).

For the PATH you would modify /etc/PATH, which is also systemwide but it is not really a shell script, so modifying it such that is has only impact on a group of users may be difficult. I never considered this an option.

On can also modify root's and developers' .profile or shell's rc file.

JP.

[Richard Darling]

Hi Tim,
When I first started writing scripts I used to keep scripts in /usr/bin; but learned a lesson when I deleted system files in error. Since then I ALWAYS put all custom scripts in a separate directory and add them to the path.
Richard

[Tim Hempstead]

We tend to use a custom area under /home for most of the scripts, this is broken down into seperate areas for different things.

/home/xx/cmdall - scripts available to anyone
/home/xx/cmddsg - scripts available only to root
/home/xx/dumps/sources - backup related
/home/xx/monitor - monitoring scripts
/home/xx/oracle - Oracle related scripts, (and likewise for other products)

(xx is customer specific but is not the name of a user on the system).

The cmdall area is added to the PATH and the cmddsg area is also in roots PATH.

The exception to this are scripts collecting information for DR purposes, these are found under /DISREC.

Personally, I would not put any user scripts into /usr/bin or /usr/sbin areas.

[Cole L.]

The admin before me put his stuff in the ..

/user/admin/bin

and added it to the path. I've continued

[Alzhy]

Admin Tools:
/usr/SM(bin,etc,share,man,lib,doc,,,)

Global 3P, OpenSource, GNU, etc.:
/usr/local

We keep the system-wide PATHS and MANPATHS, SHLIBS, etc. in /etc/profile, /etc/csh.login as pristine as possible with switches for the type of non-root user on what the default PATH,MANPATH,etc.. are to be.

[Bill Thorsteinson]

There has been work on a general
File Heirarchy Standard to resolve issues
such as this.

Generally accessable scripts should go in
/usr/local/bin, and admin scripts in
/usr/local/sbin.

I also create subdirectories bin, etc, and log
for various admin ids such as root, oracle, and
such which contain scripts that need to be run
as that user. I keep a copy of the crontab
for the user as bin/crontab. On systems
that support it the file is executable with
a "#!/usr/bin/crontab" header. Crontab
can be reloaed with the command
crontab bin/crontab
or
bin/crontab
depending on the system.