Tom,
>On Mon, 2007-07-09 at 17:00 -0700, Collins, Kevin [MindWorks] wrote:
>> Tom,
>>
>> this works great for "login" sessions, but it doesn't work for
>> crond and rshd so I still have the problem!
>
>Well, like I said, I hadn't really found a way to do this globally with
>no exceptions, although I hadn't tried very hard. I'm curious, why is
>cron a problem? Why can't you just put the _UNIV_DEFAULT
>setting in the
>crontab file itself? Does it have to work for everybody without them
>knowing to do anything special? Is that the issue?
It would be nice, but it isn't a requirement... and, yes, I can add the
_AST_FEATURES variable to root's crontab (no other users have cron
access).
>> Actually, I found /etc/security/pam_env.conf which should
>work for all
>> pam-enabled services, but it doesn't seem to work for either crond or
>> rshd.
>
>Yeah, that looks like it should work. Both cron and rsh appear to
>properly call pam_env. It's interesting that it didn't. I'll try to
>set it up on our test server tomorrow just to verify your results.
I actually found a report of a bugfix in FC6 for rshd NOT correctly
loading the pam_env and the revision of rshd is one higher than what is
in RHEL5 (rsh-server-0.17-38 vs rsh-server-0.17-37).
>> I tried re-building the RPM from SRPM and defining
>_UNIV_DEFAULT=att in
>> the CCFLAGS, but it still defaults to ucb.
>
>Yeah, I don't think that would do it. In a quick glance at the source
>it would appear that you would have to patch one of the files.
> It looks
>like the script which builds libast decides if /bin/echo exist, and
>doesn't support escaped backslashes by default, to default to ucb.
>
>Here is a small snippet from ksh-20060214/src/lib/libast/features/lib:
>
>tst cross{
> u=att
> case `/bin/cat -s /dev/null/foo 2>&1` in
> '') ;;
> *) case `/bin/echo '\\t'` in
> '\t') u=ucb ;;
> esac
> ;;
> esac
> echo "#define _UNIV_DEFAULT \"$u\" /* default
>universe name
>*/"
>}end
>
>A simple patch to this file to force the 'u' variable to att
>is probably
>all that's required.
I found that too - I was hoping that the define might override it. Maybe
I'll figure out how to patch the SRPM.
>> *Sigh* - I really just want a solution that works...
>
>What's wrong with the symlink in /usr/local/bin? Is it the
>concern over
>scripts messing with the path? If so, the next best thing is probably
>the echo wrapper scripts, although that will be a support annoyance.
The symlink doesn't work when someone uses rsh to execute a script,
because there is no "login" so the path is only set to /bin:/usr/bin...
This is actually my biggest concern because most of our scripts are
executed via rsh.
Kevin
_______________________________________________
rhelv5-list mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/rhelv5-list
