Curtis Larsen wrote:
>
> Well, I tried the SUEXEC_BIN compiler option, and it didn't work.  So, I
> took much harder and longer look at the code today, and I discovered
> that the lowercase "suexec" was hard-coded within the main Makefile.
> Grrr.
>
> So for grins I went through and changed every Makefile entry for
> "suexec" to "$(suexec_bin)", and made sure that this variable was set to
> "SUEXEC", allowing it to just replace the file name, while "suexec_sbin"
> would cover the path.  This worked, and I was the proud papa of an
> /APACHE/PUB/SUEXEC, which I cheerfully linkedited.
>
> I copied /APACHE/PUB/httpd to /APACHE/PUB/HTTPD, (could've made that
> uppercase too -- didn't mess with it though) linkedited it, linked
> /APACHE/PUB/bin/httpd to it, and tried the background job.  <Sigh> As
> always, everything works....but there is nothing in the log or #stdlist
> (per the docs, anyway) to suggest that HTTPD sees SUEXEC at all.

Apparently suexec uses its own log file defined by LOG_EXEC at compile time.

Have you checked 1) access_log, 2) error_log, and 3) the LOG_EXEC file?

> I'm thinking that perhaps I've gotten a little too close to this thing,
> and that I should start over -- both to sanity check my notes on the
> changes I've made thus far, and to start with a clean slate.  Someone
> (Lars?) suggested using the set of POSIX wrappers at the Jazz site --
> would this be a good thing to do?  Could it help alleviate some of the
> header changes need thus far, or are they required regardless?  (Mebbe I
> have 'em and don't know?)

I suspect the wrappers won't help much.  I think minor changes to the Apache
code are going to be needed that looks for the suexec binary and validates that
it's OK.

> Next time around I'll try making it for a set without modifying the
> Makefile at all.  If that needs to be done, then the "configure" file
> will also need to be changed, and together those aren't light changes.
> The resulting collection of modifications to the code -- including the
> small mods to the headers, etc. -- would be something almost impossible
> to document as a "1-2-3" sort of thing for someone else to follow.  At
> that point, it would probably be better to submit it back.

It is ALWAYS best to submit your port back to the official developers.  It
makes building future versions MUCH easier.

> The frustrating thing for me is that I don't really understand this
> code (and the whole process) enough to debug not only what I should see,
> but where I should look in the code itself to find it.  I've coded, but
> I'm not a C programmer, and this isn't an easy piece of code.  (In fact,
> you have to understand shell programming, make, AND C.)  It's like
> suddenly piloting a small plane -- I theoretically know how to work the
> rudders and the stick, but I don't know the instrumentation at all: I
> can intuit what to do, but I don't really know why (until it's explained
> to me).  Happily, I've had some wonderful "talk-thrus" by "pilots" far
> more advanced than I (THANKS Mark!) -- without that, I would've crashed
> this baby long ago.  (Shucks, I would've stuck to the road [pun
> intended].)

Sounds like you're somewhat similar to where I was when I first started porting
Apache.

I had only written one complete C program in my life.  I had to sit down with
an open C reference manual as I did the port, learning C as I went.

I had never written any Makefiles, and they were largely incomprehensible to
me.  Some Makefiles still are incomprehensible to me even today.  ;-)

When all else fails, brute force methods will work.  Recursively scan the
source tree for all references to SUEXEC_BIN:

cd apache_1.3.20
find . -type f | xargs grep SUEXEC_BIN

Then insert a bunch of fprintf() debugging lines into the code near the
references to SUEXEC_BIN in order to establish which code is being executed:

fprintf(stderr,"MPE DEBUG ...text...\n");

Or fancier:

fprintf(stderr,"MPE DEBUG string=%s, integer=%d\n",string_var,integer_var);

Depending on how much initialization Apache has done at this point, your
debugging text will either appear in the JHTTPD job's $STDLIST, or the
error_log.

And of course, read and re-read the Apache documentation on suexec to make sure
you understand it.  Porting is easier if you understand how the code you're
porting is supposed to work.  Porting is easier still if you have used the same
Apache functionality on Unix (i.e. you know how to configure and run it
properly for testing).
--
[log in to unmask]
Remainder of .sig suppressed to conserve scarce California electrons...

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *