[news.software.b] NNTP 1.5.10 / Cnews 15-Dec-1990 / Stupid UNIX exec

warlock@ecst.csuchico.edu (John Kennedy) (01/30/91)

  I'm setting up a system with these beasties, and I've run into a hurdle
that someone may have delt with already or have a clever solution to.

  When a remote Pnews batches up an article, it is received by NNTP, tossed
into a temporary file in /usr/tmp, and it forks/execs inews.  Fine and dandy,
expect that inews is a shell script and I can't do any sort of an exec() on
anything but a a.out-format file.  It seems to be happy by execing ksh and
passing along the arguments to inews for ksh to deal with.  (Seemingly solved
-- I only mention it because it isn't stock behavior).

  Inside inews, our pal anne.jones is called.  Anne decides she must call "who
am I" for some reason.  (Lack of $USER being set?  What should it be set to?)
This is EVIL -- who yacks because the user isn't on a terminal and it can't
find the name.  The decent into darkness has begun.

  It makes two other attempts to find a user's name, and probably with no name
to look with, either, since the "who" failed.  It looks in /etc/passwd, which
fails because the machine doesn't have user accounts and then ypmatch, which
the machine doesn't have at all.

  Burp, regurgitate, error, nothing posted.

  Now:
	(A)  What is our little Anne trying to look up?  The name that NNTP
		runs under, or the user's name?
	(B)  Can I just write something to do what "who am i" should?  (If so,
		I presume it should return the info for (A).)
	(C)  Is there a more clever way to do this whole thing?

  Thanks.

-- 
			+----------------------------------------------------
Warlock, AKA		| internet:	warlock@ecst.csuchico.edu
John Kennedy		+----------------------------------------------------
CSU Chico			IBM, You BM, We All BM for IBM!

palkovic@linac.fnal.gov (John A. Palkovic) (01/31/91)

In article <1991Jan30.062800.15853@ecst.csuchico.edu> warlock@ecst.csuchico.edu
	(John Kennedy) writes:

>  Burp, regurgitate, error, nothing posted.
>
>  Now:
>	(A)  What is our little Anne trying to look up?  The name that NNTP
>		runs under, or the user's name?

(What is the story about Anne Jones? Is she still around?)

Did you have a line like the following in nntp/common/conf.h:

   #define	POSTER		"daemon"

when you compiled nntp? "Daemon" should correspond to an entry in your
passwd file.

-- 
palkovic@linac.fnal.gov, tellab5!linac!palkovic
... one of the first things I do when installing a Sun is throw Sun's
sendmail away and replace it with "real" sendmail... - Dave Curry

bruce@balilly.UUCP (Bruce Lilly) (01/31/91)

In article <1991Jan30.062800.15853@ecst.csuchico.edu> warlock@ecst.csuchico.edu (John Kennedy) writes:
>
>  I'm setting up a system with these beasties, and I've run into a hurdle
>that someone may have delt with already or have a clever solution to.
>
>  When a remote Pnews batches up an article, it is received by NNTP, tossed
>into a temporary file in /usr/tmp, and it forks/execs inews.  Fine and dandy,
>expect that inews is a shell script and I can't do any sort of an exec() on
>anything but a a.out-format file.  It seems to be happy by execing ksh and
>passing along the arguments to inews for ksh to deal with.  (Seemingly solved
>-- I only mention it because it isn't stock behavior).

I also ran into this, but I don't recall exactly how I solved it.  I'll
just note in passing that one possible solution is contained in the
exec(2) man page -- two members of the exec family will work with scripts
(Hint: read the description of the ENOEXEC error return).

>  Inside inews, our pal anne.jones is called.  Anne decides she must call "who
>am I" for some reason.  (Lack of $USER being set?  What should it be set to?)
>This is EVIL -- who yacks because the user isn't on a terminal and it can't
>find the name.  The decent into darkness has begun.
>
>  It makes two other attempts to find a user's name, and probably with no name
>to look with, either, since the "who" failed.  It looks in /etc/passwd, which
>fails because the machine doesn't have user accounts and then ypmatch, which
>the machine doesn't have at all.
>
>  Burp, regurgitate, error, nothing posted.
>
>  Now:
>	(A)  What is our little Anne trying to look up?  The name that NNTP
>		runs under, or the user's name?

The latter.

>	(B)  Can I just write something to do what "who am i" should?  (If so,
>		I presume it should return the info for (A).)

Here's an excerpt from the anne.jones I use (it works for me, but your
mileage may vary):

# dig up user's name (a simple task, you'd think, but you'd be wrong)
case "$LOGNAME" in
"")
	# "who am i" on many Unixes does "ttyname(0)" and "getpwuid(getuid())"
	# if that fails - it can be confused by empty utmp entries (per jerqs);
	# "who am i </dev/null" yields your userid, not your login name.
	# "tty" does "ttyname(0)"; also fallible.
	# So, emulate a slightly-modified V7 getlogin(3) (actually ttyslot(3)):
	# look for tty on /dev/tty, stdin, stdout, stderr (actually via ttyname(3)).
	for fd in 3 0 1 2			# 3 is /dev/tty on V8
	do
		if test -t $fd; then
			case "$USER" in
			"")	USER="`who am i <&$fd |
				    sed -e 's/[	 ].*//' -e '/!/s/^.*!//' `" ;;
			esac
		fi
	done
	case "$USER" in
	"")	USER="`logname`";;	# last resort: use userid
	esac
	;;
*)	USER="$LOGNAME" ;;


Good luck.
--
	Bruce Lilly		blilly!balilly!bruce@sonyd1.Broadcast.Sony.COM

warlock@ecst.csuchico.edu (John Kennedy) (02/02/91)

In article <1991Jan31.023944.19068@blilly.UUCP> Bruce Lilly writes:
>
>I also ran into this, but I don't recall exactly how I solved it.  I'll
>just note in passing that one possible solution is contained in the
>exec(2) man page -- two members of the exec family will work with scripts
>(Hint: read the description of the ENOEXEC error return).

  Maybe it's a suble RTFM, maybe it's not.  (-:  In any case, one of the things
execle() *does* do is pass the environment, which is not one of the standard
things that the new process inherits from the process that called execle().
NNTP makes a small exercise in copying it's environment, and I'll just assume
they did it for a reason and try not to get too far out to pasture.  (-:{

  For reference:  The exec(2) call "... transforms the calling process into a
new process ... constructed from an ordinary, executable file ... [that]
consists of a header [see a.out(4)], a text segment, and a data segment."
Shell scripts don't meet the a.out header requirement, but under the possible
errors that can be returned, it kind of goes back on itself.  Under ENOEXEC,
it says:  "The exec is not an execlp or execvp, and the new process file has ...
an invalid magic number in it's header."
-- 
Warlock, AKA		+-----------------------------------------------+
John Kennedy		|    internet:	   warlock@ecst.csuchico.edu	|
 CSU Chico		+-----------------------------------------------+
   KC6RCK			 IBM, You BM, We All BM for IBM!