Re: how to simulate a user's crontab?

2008-07-21 Thread David Robillard
 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?

2008-07-19 Thread Karl Vogel
 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 ATT, 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 user [at] whatever [dot] com
#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 $lrevdate | sed -e $lsedscr
}

where 

re: how to simulate a user's crontab?

2008-07-17 Thread DA Forsyth
 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?

2008-07-17 Thread John Almberg


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?

2008-07-16 Thread Bill Moran
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]


Re: how to simulate a user's crontab?

2008-07-16 Thread John Almberg


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?

2008-07-16 Thread John Almberg


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]