Thanks to all who replied to my mail on this:
Robert Lau <rslau@usc.edu>
David L. Markowitz <David.Markowitz@litronic.com>
Rik Schneider <rik@netasset.com>
Bill.Sherman@bridge.bellsouth.com
Jaewan Kim <jaewan@u1.net>
Danny Johnson <djohnson@nbserv1.rsc.raytheon.com>
Yura Pismerov <yura@base4.com>
Paul.Teasdel@dresdnerkb.com
David Massey <dmassey@e-one.com>
Ralph Finch <rfinch@dop.water.ca.gov>
Reichert, Alan <aareichert@tasc.com>
Drew Watson <dwatson@ns.encore.com>
Matthew Stier <Matthew.Stier@tddny.fujitsu.com>
James Ford <jford@tusc.net>
Mark Noel <Mark_Noel@cch.com>
Salehi, Michael E <Mike.Salehi@usa.xerox.com>
Colin_Melville@mastercard.com
The answer for this issue is:
> crontab stuff runs as sh. It doesn't look for the users environment
> at all ( as I have lately learned to my chagrin ). You have to
> deliberately source the users environment if you need to use something
> from it.
>
> You can use an /etc/default/cron file to set defaults, but I've never
> used it.
>
> man pages do an OK job of explaining this, but it's near the bottom.
Checking the man page for crontab(1), I do see towards the bottom of
the page the following:
The shell is invoked from your $HOME directory with an arg0
of sh. Users who desire to have their .profile executed
must explicitly do so in the crontab file. cron supplies a
default environment for every shell, defining HOME, LOGNAME,
SHELL(=/bin/sh), TZ, and PATH. The default PATH for user
cron jobs is /usr/bin; while root cron jobs default to
/usr/sbin:/usr/bin. The default PATH can be set in
/etc/default/cron; see cron(1M).
One other warning I got was:
> You didn't say what OS you're running. Under Solaris 2.6, cron jobs
> won't run if the user's shell does not appear in /etc/shells.
Other suggestions included:
o Changing the passwd field containing the actual user account password
to something that would disable logins (like *, or a 14-character entry),
which we do automatically when someone leaves the company
o Migrate the cron jobs to a generic admin account, or an account that
will never change/leave (like root, lp, or some other generic system
level account), which we do as we come across the jobs. Unfortunately,
we don't have the time to spend checking out each system, and instead
have to check out things as we get a chance between various crises....
My original question was:
> This is kind of a brain-dead question, but I was wondering if there
> would be any problem with cron jobs running properly if I changed a
> user's shell to something like /bin/false. We've got a few admins
> that have since left our employ, but there are still the odd jobs
> that are running from cron that we don't want to break, so changing
> the /etc/passwd shell to /bin/false may allow us to disable the account
> for login purposes (such as the use of 'su'), but not break cron jobs
> and the like.
Again, thanks to all that replied to this.
-Mike
--
Michael Steeves, System and Network Administrator (msteeves@applix.com)
"I've got to start listening to those quiet, nagging doubts."
-- Calvin and Hobbes
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:13:20 CDT