Re: how to simulate a user's crontab?
> Actually, I highly recommend a Mac program called Yojimbo, that is a > kind of general purpose memory tool. You can throw all sorts of > information into it, and find it very easily when you need it. > Fantastic program and I don't know of anything like it on other > platforms. If you're looking for the same type of "Remember everything" functionality as Yojimbo, but platform independent, then you might want to take a look at http://www.evernote.com. It's web based (but .Mac free) plus it also has a MacOS X and a Windows client if you need them. HTH, David -- David Robillard UNIX systems administrator & Oracle DBA CISSP, RHCE & Sun Certified Security Administrator Montreal: +1 514 966 0122 If you receive something that says "Send this to everyone you know", then please pretend you don't know me. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: how to simulate a user's crontab?
>> On Thu, 17 Jul 2008 09:27:51 +0200,
>> "DA Forsyth" <[EMAIL PROTECTED]> said:
D> John, it is not a permissions issue, but rather a path issue. Do as the
D> other poster suggested and run a cron job to dump the environment and you
D> will see that the PATH inside a cron job is very rudimentary. Either add
D> what you need to it in the crontab or cron job, or always use absolute
D> paths for everything in a cron entry.
D> alternatively, set up an AT job as the user, then find the script generated
D> by at and grab a copy (/var/spool/cron ???). You can use that copy as the
D> basis for all cron scripts for that user, and always have the 'user'
D> environment set up correctly.
I use templates for most of the things I write, so I don't end up making
the same stupid off-by-one mistakes for things like handling command-line
arguments. My template for a production shell script is below.
* Why use the Korn shell instead of bash? "size" prints out the size of
the text, data, and uninitialized data segments and their total for
a given program. On Solaris:
me% size /bin/ksh /bin/bash
/bin/ksh: 166555 + 2022 + 6438 = 175015
/bin/bash: 535476 + 74216 + 13712 = 623404
BSD numbers have the same general idea. Bash is >3 times heavier than
KSH in terms of memory use; if you need all that, fine, but if not,
consider something lighter. David Korn is one of the brightest minds
at AT&T, and any shell he writes to correct deficiencies in the original
Bourne shell deserves a serious look.
* Always set your PATH and umask to something safe. This way, you avoid
unpleasant surprises if someone else runs your script, or if it's run
from cron.
* It should be easy to do things you do frequently. I use short functions
like "logmsg" to write to the system log for long-running scripts,
and "die" to print a useful error message and exit. This way, sanity
checking becomes much less tedious, and if you want to change the format
or destination of log messages, the change is made in *one* place.
* Using a template makes it easier to be consistent when choosing things
like command-line options; in just about everything I write, "-d"
turns on debugging output, "-h" prints help, etc.
This might not be a big deal if you're the only user, but if you work
a help desk and you need to know why a script barfed all over itself
when a customer's on the phone, it's a blessing.
* It should be easy to find out what version is being run and where the
source code is. The "-v" option prints the version and date, and the
"-w" option prints the source location from the revision system I use:
me% ./doit -v
doit v1.1 2008/02/24 13:02:35
me% ./doit -w
/src/script/RCS/doit,v
--
Karl Vogel I don't speak for the USAF or my company
I remember when sex was safe and flying was dangerous.
---
#!/bin/ksh
#
# NAME:
#doit
#
# SYNOPSIS:
#doit [-dhuvw] [-o outfile] [infile ...]
#
# DESCRIPTION:
#program to ...
#
# OPTIONS:
#"-d" turns debug output on.
#"-h" prints help and exits.
#"-o outfile" specifies the optional output file.
#"-u" prints the UUID and exits.
#"-v" prints the version and exits.
#"-w" prints the location of the source code and exits.
#
# AUTHOR:
#Your name
#Your organization
PATH=/usr/local/bin:/bin:/usr/bin:/usr/sbin
export PATH
umask 022
tag=`basename $0`
# FUNCTIONS =
# logmsg: prints a string to the system log.
logmsg () {
logger -t $tag "$*"
}
# die: prints an optional argument to stderr and exits.
# This works in subshells and loops, but may not exit with
# a code other than 0.
die () {
echo "$tag: ERROR -- $*" >& 2
exit 1
}
# usage: prints an optional string plus part of the comment
# header (if any) to stderr, and exits with code 1.
usage () {
lines=`egrep -n '^# (NAME|AUTHOR)' $0 | cut -f1 -d:`
(
case "$#" in
0) ;;
*) echo "usage error: $*"; echo ;;
esac
case "$lines" in
"") ;;
*) set `echo $lines | sed -e 's/ /,/'`
sed -n ${1}p $0 | sed -e 's/^#//g' |
egrep -v AUTHOR:
;;
esac
) >& 2
exit 1
}
# Print the UUID for this script. Should be based on
# something unique, like date-time-hostname.
myuuid () {
lsedscr='s/UUID: //
s/\$//g'
lid='$UUID: ee96ec96-5bab-3443-b0d4-e0d2c96a4ffd $'
echo "$lid" | sed -e "$lsedscr"
}
# Print the current version and source location.
version () {
lsedscr='s/RCSfile: //
s/.Date: //
s/,v . .Revision: / v/
s/\$//g'
lrevno='$RCSfile: doit,v $ $Revision: 1.1 $'
lrevdate='$Date: 2008/02/24 13:02:35 $'
echo "$lrevno
Re: how to simulate a user's crontab?
John, it is not a permissions issue, but rather a path issue. Do as the other poster suggested and run a cron job to dump the environment and you will see that the PATH inside a cron job is very rudimentary. Either add what you need to it in the crontab or cron job, or always use absolute paths for everything in a cron entry. alternatively, set up an AT job as the user, then find the script generated by at and grab a copy (/var/spool/cron ???). You can use that copy as the basis for all cron scripts for that user, and always have the 'user' environment set up correctly. Yes, I finally figured this out. I had the problem completely backwards... I assumed that when I ran 'su user', I was logged in as the user. Since the command worked when I was 'logged in' and didn't work for crontab, I figured crontab must be different. It never occured to me that *I* was running in a different environment :-) If I had realized, a quick read of the su man page would have solved my problem. As it was, I had been shown su long ago by another admin, and just assumed I knew how it worked. Wrong! Well, that's the joys of being of newbie administrator... So little time, so many man pages to read! Thanks: John ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
re: how to simulate a user's crontab?
> Date: Wed, 16 Jul 2008 11:26:19 -0400 > From: John Almberg <[EMAIL PROTECTED]> > I often run into permission problems with user crontabs. That is, a > crontab run under a user's permissions. > First of all, it seems to me that a user's crontab doesn't have > exactly the same permission as the user himself. Is this true? > If so, what permissions does a user's crontab have? > Is there anyway I can simulate these permissions on the command line, > so I can test things before putting them in a crontab? > What I'd like to avoid is the frustrating cycle of putting a line in > a user's crontab (a few minutes ahead), waiting for it to fire off, > have it fail, check error logs, try again... > It would be much simpler if I could simulate the crontab's > environment, and just run the thing from the command line. > Any hope? I'm running FreeBSD 6.3 John, it is not a permissions issue, but rather a path issue. Do as the other poster suggested and run a cron job to dump the environment and you will see that the PATH inside a cron job is very rudimentary. Either add what you need to it in the crontab or cron job, or always use absolute paths for everything in a cron entry. alternatively, set up an AT job as the user, then find the script generated by at and grab a copy (/var/spool/cron ???). You can use that copy as the basis for all cron scripts for that user, and always have the 'user' environment set up correctly. -- DA Fo rsythNetwork Supervisor Principal Technical Officer -- Institute for Water Research http://www.ru.ac.za/institutes/iwr/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: how to simulate a user's crontab?
On Jul 16, 2008, at 10:03 PM, John Almberg wrote: I'm guessing you're having problems with environment settings, although the vagaries of the question don't give me much to go on (something along the lines of, "when I try to do x in cron, I get the error y; but it works fine when the user runs it outside of cron" would be more informative.) Well, this got me thinking and I had to do some playing around to figure out what was wrong... The difference was that I was testing the command by su-ing into the user, rather than logging in as that user. What I didn't know was su does not change your environment, only permissions (as far as I can tell) So I was testing with my environment, but crontab was running under the other user's environment. I always thought that su user and login user were equivalent. Now I know better :-) Ah! Further digging led me to the - option for su... I am adding this note in case anyone else runs into this problem... Normal su does not change most of your environment... you retain the environment you had before typing 'su user'. However, typing 'su - user' simulates a full login. Amazing what you can find once you know what to look for! -- John ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: how to simulate a user's crontab?
I'm guessing you're having problems with environment settings, although the vagaries of the question don't give me much to go on (something along the lines of, "when I try to do x in cron, I get the error y; but it works fine when the user runs it outside of cron" would be more informative.) Well, this got me thinking and I had to do some playing around to figure out what was wrong... The difference was that I was testing the command by su-ing into the user, rather than logging in as that user. What I didn't know was su does not change your environment, only permissions (as far as I can tell) So I was testing with my environment, but crontab was running under the other user's environment. I always thought that su user and login user were equivalent. Now I know better :-) Anyway, thanks for putting me on the right path. -- John ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: how to simulate a user's crontab?
In response to John Almberg <[EMAIL PROTECTED]>: > I often run into permission problems with user crontabs. That is, a > crontab run under a user's permissions. > > First of all, it seems to me that a user's crontab doesn't have > exactly the same permission as the user himself. Is this true? The crontab runs as the user, and thus has the exact same permissions. > Is there anyway I can simulate these permissions on the command line, > so I can test things before putting them in a crontab? > > What I'd like to avoid is the frustrating cycle of putting a line in > a user's crontab (a few minutes ahead), waiting for it to fire off, > have it fail, check error logs, try again... > > It would be much simpler if I could simulate the crontab's > environment, and just run the thing from the command line. > > Any hope? I'm running FreeBSD 6.3 I'm guessing you're having problems with environment settings, although the vagaries of the question don't give me much to go on (something along the lines of, "when I try to do x in cron, I get the error y; but it works fine when the user runs it outside of cron" would be more informative.) Write a cron job to dump the cron environment via echo, you can then set those environment variables when testing your scripts. -- Bill Moran http://www.potentialtech.com ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
