Cron Problems

2012-04-23 Thread Tim Gustafson
I've recently installed a FreeBSD 9.0 jail server, and inside each of
my jails I am getting the following errors in my log about every 5
minutes:

cron[7635]: NSSWITCH(_nsdispatch): ldap, group, setgrent, not found,
and no fallback provided
cron[7635]: NSSWITCH(_nsdispatch): ldap, group, getgrent_r, not found,
and no fallback provided
cron[7635]: NSSWITCH(_nsdispatch): ldap, group, endgrent, not found,
and no fallback provided
cron[7635]: NSSWITCH(_nsdispatch): ldap, passwd, endpwent, not found,
and no fallback provided
/usr/sbin/cron[7673]: (CRON) WARNING (madvise() failed)

I'm using nss_ldap and pam_ldap on these systems, so I suspect and
error in my /etc/pam.d configuration or my nsswitch.conf
configuration.  I've added some configuration to /etc/pam.d/sshd and
/etc/pam.d/other but have left the other files unmolested.

Now, this seems like an nsswitch problem, but my nsswitch.conf is
fairly straightforward:

group: files ldap
hosts: files dns
networks: files
passwd: files ldap
shells: files
services: files
protocols: files
rpc: files

I'm able to get user ID information without a problem using id or
finger.  Authentication is working.  LDAP groups are working.
Pretty much everything seems like it ought to work, except for those
error messages.  I don't think this is a PAM issue, but just in case,
here's my /etc/pam.d/sshd:

authsufficient  /usr/local/lib/pam_ldap.so
authrequiredpam_unix.so
account requiredpam_nologin.so
account requiredpam_login_access.so
account requiredpam_unix.so
session requiredpam_permit.so
passwordrequiredpam_unix.so no_warn try_first_pass

And here is /etc/pam.d/other:

authsufficient  /usr/local/lib/pam_ldap.so
authrequiredpam_unix.so no_warn try_first_pass
account requiredpam_nologin.so
account requiredpam_login_access.so
account requiredpam_unix.so
session requiredpam_permit.so
passwordrequiredpam_permit.so

I note that there is an /etc/pam.d/cron but it's not clear to me what
I might add to this file, as it is quite different than the others:

account requiredpam_nologin.so
account requiredpam_unix.so

So, what am I missing?

-- 

Tim Gustafson
t...@tgustafson.com
http://tgustafson.com/
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org


Re: Cron problems

2010-08-28 Thread Thomas Keusch
On Sat, Aug 28, 2010 at 01:49:18PM +0200, Bernt Hansson wrote:

Hell Bernt,

 I'm having problems with lines like this in cron, works on the command  
 line, but not in cron.

 /sbin/dump -0uan -f - /usr | gzip -2 | ssh -c blowfish \
 targetu...@targetmachine.example.com dd  
 of=/mybigfiles/dump-usr-l0-`date +%Y-%m-%d--%H-%M-%S`.gz

you need to escape the percent-signs like that: \%

For why see man 5 crontab

Regards
Thomas
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org


Trouble-shooting Cron Problems FreeBSD5.4

2006-10-31 Thread Martin McCormick
After building a new FreeBSD5.4 system, I have done
something bad to it.

When cron runs jobs in /etc/crontab as operator, it seems
as if that 6TH field in /etc/crontab is being interpreted as a
command rather than the user ID it is supposed to run under.  I
keep getting messages like:

From:[EMAIL PROTECTED] (Cron Daemon)
Subject: Cron [EMAIL PROTECTED] root  newsyslog


root: not found


Comparing this system with another properly-functioning
5.4 system has, as of yet, shown nothing unusual.  If I become
root and manually run the job in question, it runs without a
complaint.

The crontab file on the problem system is an exact copy
of the crontab file on the working system.  Both crons appear to
be running with the same flags as in

  465  ??  Ss 3:24.39 /usr/sbin/cron -s

Any suggestions as to what I should look at next?  Both
systems' crons are showing the same environments if I make them
run the env command.  Many thanks.

Martin McCormick WB5AGZ  Stillwater, OK 
Systems Engineer
OSU Information Technology Department Network Operations Group
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Trouble-shooting Cron Problems FreeBSD5.4

2006-10-31 Thread Lane
On Tuesday 31 October 2006 12:08, Martin McCormick wrote:
   After building a new FreeBSD5.4 system, I have done
 something bad to it.

   When cron runs jobs in /etc/crontab as operator, it seems
 as if that 6TH field in /etc/crontab is being interpreted as a
 command rather than the user ID it is supposed to run under.  I
 keep getting messages like:

 From:[EMAIL PROTECTED] (Cron Daemon)
 Subject: Cron [EMAIL PROTECTED] rootnewsyslog


 root: not found


   Comparing this system with another properly-functioning
 5.4 system has, as of yet, shown nothing unusual.  If I become
 root and manually run the job in question, it runs without a
 complaint.

   The crontab file on the problem system is an exact copy
 of the crontab file on the working system.  Both crons appear to
 be running with the same flags as in

   465  ??  Ss 3:24.39 /usr/sbin/cron -s

   Any suggestions as to what I should look at next?  Both
 systems' crons are showing the same environments if I make them
 run the env command.  Many thanks.

 Martin McCormick WB5AGZ  Stillwater, OK
 Systems Engineer
 OSU Information Technology Department Network Operations Group
 ___
 freebsd-questions@freebsd.org mailing list
Martin,

Post the offending line or even all of /etc/crontab

lane
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Trouble-shooting Cron Problems FreeBSD5.4

2006-10-31 Thread Dan Nelson
In the last episode (Oct 31), Martin McCormick said:
   After building a new FreeBSD5.4 system, I have done
 something bad to it.
 
   When cron runs jobs in /etc/crontab as operator, it seems
 as if that 6TH field in /etc/crontab is being interpreted as a
 command rather than the user ID it is supposed to run under.  I
 keep getting messages like:

The operator user has no access to /etc/crontab.  You have probably
copied entries from the system crontab (i.e. /etc/crontab) into a
user's crontab.  The system crontab has the extra user column, where
user crontabs don't (since they always run as the user).

 From:[EMAIL PROTECTED] (Cron Daemon)
 Subject: Cron [EMAIL PROTECTED] rootnewsyslog

operator won't be able to run newsyslog anyway, since it can't write to
/var/log and can't send signals to syslogd (which runs as root). 

You'll probably want to move those lines back to the system crontab.
 
-- 
Dan Nelson
[EMAIL PROTECTED]
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Trouble-shooting Cron Problems FreeBSD5.4

2006-10-31 Thread Martin McCormick
Dan Nelson writes:
 The operator user has no access to /etc/crontab.  You have probably
 copied entries from the system crontab (i.e. /etc/crontab) into a
 user's crontab.  The system crontab has the extra user column, where
 user crontabs don't (since they always run as the user).
 

Thank you.  That is exactly what happened.  I checked the
working system by doing

crontab -e -u operator

and there was no crontab there at all.  I then went to the ailing
system and, voila, there was the copy of /etc/crontab complete
with all its comment lines.  I remember being confused at one
stage about /etc/crontab because of the line

\# /etc/crontab - root's crontab for FreeBSD

After all, the root user also has a crontab file with the
normal user fields (minus the special 6TH field).

Somewhere along the way, I probably typed either

crontab -u operator crontab

from /etc or did a crontab -e -u operator and joined /etc/crontab
in to the new table.

Remember the saying that goes, Nothing can be made
foolproof because fools are so ingenious?  That pretty well says
it all.  I am not sure how I figured it might need to go in the
operator account, but that's where it wound up.  I am sure that
solves the problem.  I'll know in 15 minutes when the next
newsyslog command fires and I don't get the squawk.:-)

Martin McCormick WB5AGZ  Stillwater, OK 
Systems Engineer
OSU Information Technology Department Network Operations Group
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]