apachetoolbox-devel — Developers Mailing list

[Apachetoolbox-devel] ATB 1.5.59: mod_auth_mysql

[Toni M. <su...@oe...>]

Hello,


[ resent, since I didn't notice where this was lost ]

I've stumbled over adding mod_auth_mysql to a local Apache
(on Debian...). The problem is with detecting the lib.
The context suggests that libmysqlclient.so is needed, and
under Debian this is installed in /usr/lib. So I hacked a
patch for bin/mod_auth_mysql which you find attached. Hope
this helps ;) If not, please let me know...

The patch was against 1.5.59, but it didn't seem to have made it
into 1.5.61.


Best,
--Toni++


--- mod_auth_mysql	2002/09/08 21:47:34	1.1
+++ mod_auth_mysql	2002/09/08 21:52:34
@@ -27,6 +27,10 @@
   test -d $LOCAL_PATH/lib/mysql && MYSQLLIB=$LOCAL_PATH/lib/mysql
   test -d $LOCAL_PATH/mysql/lib/mysql && MYSQLLIB=$LOCAL_PATH/mysql/lib/mysql
   test -d /usr/lib/mysql && MYSQLLIB=/usr/lib/mysql
+  CNT=`ls /usr/lib/libmysqlclient*|wc -l`
+  if [ ${CNT} -ne 0 ]; then
+	  MYSQLLIB=/usr/lib
+  fi
  if [ $MYSQLLIB ]; then echo " [DONE]"; else echo " [FAILED]"; exit; fi

[Apachetoolbox-devel] ATB 1.5.61: install-item doesn't create leading paths

[Toni M. <su...@oe...>]

Hi,

I tend to compile Apaches using the ATB like this:

path = /usr/local/stow/something, or:
path = /usr/local/stow/something/apache-<version>-<subversion>
Apache install-path = /usr/local/stow/something/apache-<version>-<subversion>

with subversion being a number that should mean something to me, like
which config file I selected when building, or so, to be able to
generate completely independent versions of Apache along with their
individual environments. (later on: tar the whole tree up and move it
to a production box...)

However, the install script fails to generate any directories in
between. Eg if /usr/local/stow/something/apache-<version>-<subversion>
exists and it wants to install <path>/include/gd.h (as an example),
it barfs if .../include doesn't already exist. Perhaps you can
use the system's install program for that and/or automatically
create all required paths in between that are below, say, "path"
(someone is always the first to step on unclaimed grounds).

The X11R6 contains the script "mkdirhier" that could be useful, and
most "modern" BSD-style "mkdir"s understand -p which would then
create intermediate directories as required. There are also some
other scripts floating around fixing this...

What's the consensus about this?


Best,
--Toni++

Re: [Apachetoolbox-devel] Re: General: logging revisited...

[<io...@ap...>]

> 
> On Wed, Jul 24, 2002 at 10:44:42AM -0400, Kevin J. Menard, Jr. wrote:
> > TM> Yes. MD5 and SHA1 sums are a good way of suggesting that the tarball
> > TM> on the server hasn't been tampered with, even if it comes from
> > TM> evilbryansoftware.com. PGP signatures are another way of asserting
> > TM> that.
> > PGP signatures don't seem to be so prevalent, at least from my experience.

I wouldn't go with an option like PGP unless I was positive all linux 
distro's and BSD distro's came with it by default.  solaris comming up as 
3rd.

> 
> yes. I was only trying to enumerate the most common options.
> 
> > And I simply don't have enough experience with gnupg to be able to perform
> > this checking (though I could learn, I just haven't had the need).  As far
> 
> Imho a sig would give the most trust to the package's integrity, with
> SHA1 second and MD5 third.

I went with MD5's because they're the most commonly posted from the 
upstream author.  It's also a safe bet all *nix clones will have the md5 
utility.

> 
> > as SHA1, I really haven't seen that being used outside the realm of LDAP
> > password storage, but I'm sure it's because most people are still using MD5.
> 
> Yes - MD5 is the most popular method of these. SHA1 should be as easy
> as MD5 and is the preferred method to determine a checksum on OpenBSD
> (you type "sha1" instead of "md5" and get a different value).
> 
> > This is true, but the md5sum shouldn't change just because it's on a
> > different host.  Of course, unless the user goes to the original author's
> 
> Yes, they don't change. That's what i wanted to say, too - as long as
> people trust (or independently verify) the checksums for the provided
> packages, it doesn't really matter that much if the script goes to
> his website and downloads software from there.
> 
> > page to check, he'll just have to trust that the md5sums in etc/md5sum.conf
> > are accurate (which almost negates the purpose in the first place, but
> > that's besides the point :-P).
> 
> Yes. Imho it works the other way round: Bryan collects the "original"
> checksums and then downloads the packages mostly from their original
> sites and checks if the download succeeded, using his canned list
> of checksums (etc/md5sum.conf).

Correct. Not all original authors provide MD5's however. In which case i 
just make one myself and trust that the authors package has no trojens or 
anything of that nature.

> 
> > See above.  I would think that this would be enough.  As far as I know,
> > there haven't been any proven real-world collisions with md5sums given
> > different inputs.  But I'm no security expert either.  Actually, as a home
> 
> That theoretical possibility of a clash, or rather, that someone could
> fake a file for a given MD5 sum, made OpenBSD switch to SHA1 where no
> such method appears to be currently known.
> 
> > user, I'm naive.  I figure if someone was able to hack into apache.org and
> > change the tarball, or otherwise hijack my session to get me to download the
> > wrong one, then it just wasn't my day and I'd chock it up as a lost.  Hasn't
> 
> Hacking into apache.org is very evil indeed. Hijacking the session could
> easily be prevented by offering HTTPS or SSH (RSYNC) or SFTP downloads.

I'm limited to the services I can run on sf.net.  HTTPS/SFTP/SSH(RSYNC) 
are not an option right now. I don't take security lightly but it gets to 
a point where if you're that paranoid about it, maybe you shouldn't be 
useing a canned script like ATB.  Where do we draw the line?

> 
> > I don't build much from source these days.
> 
> For me, it depends. If you have a number of different platforms, but the
> need/want to have similar packages installed on each, possibly with
> slightly different options, you may reach a point where building stuff
> yourself is easier than downloading several flavours of canned packages
> for each platform.
> 
> > Btw, did Bryan fix your forum account and/or set up your SF access?
> 
> Ooops - at least I never tried again, but I also have not received
> anything from him, too. You also don't list me as a developer
> (which is ok with me).

Give me your login name on SF and I'll add you as a developer if you'd
like.  As far as the (broken) forum goes, thats a different problem.  I
can't even find the original author's website now. And the admin feature
lists users by page, I can't shift through 1000 pages for you of course.  
I can however just edit your sql record.  Whats your login name on the
forum so i can find the sql record manually?

> 

Logs:

ATB logs everything 2 seperate ways.

*.log 
*.iw

checkinstall is just a wrapper for an older C program called installwatch
that was dropped by the old author and picked up by a new one recently.  
installwatch itself is just a wrapper for 'make' (actaully anything at
all) that records all file access done by the daughter program.  When a
system (linux, freebsd) is detected that installwatch will compile on, ATB
compiles and uses installwatch. So if there was a trojen in one of my BASH
scripts or even in a makefile in any package it will be recorded in
logs/*.iw.  The RPM creation system currently built into ATB requires the
*.iw log files. checkinstall also uses the installwatch logs to create the 
debian packages i believe.

*.log's are simply redirecting the output of make's and what not
throughout all the scripts.

another packaging option: use the rpm script in contrib/ .  This creates 
an RPM using the ATB script+sources package and your previously saved ATB 
settings file.  It only works with RPM packages though. and recompiles 
everything on the host system using "./install -f".  Not a viable option 
for most. 

-Bryan

[Apachetoolbox-devel] Re: General: logging revisited...

[Toni M. <su...@oe...>]

Hi Kevin,

On Wed, Jul 24, 2002 at 10:44:42AM -0400, Kevin J. Menard, Jr. wrote:
> TM> Yes. MD5 and SHA1 sums are a good way of suggesting that the tarball
> TM> on the server hasn't been tampered with, even if it comes from
> TM> evilbryansoftware.com. PGP signatures are another way of asserting
> TM> that.
> PGP signatures don't seem to be so prevalent, at least from my experience.

yes. I was only trying to enumerate the most common options.

> And I simply don't have enough experience with gnupg to be able to perform
> this checking (though I could learn, I just haven't had the need).  As far

Imho a sig would give the most trust to the package's integrity, with
SHA1 second and MD5 third.

> as SHA1, I really haven't seen that being used outside the realm of LDAP
> password storage, but I'm sure it's because most people are still using MD5.

Yes - MD5 is the most popular method of these. SHA1 should be as easy
as MD5 and is the preferred method to determine a checksum on OpenBSD
(you type "sha1" instead of "md5" and get a different value).

> This is true, but the md5sum shouldn't change just because it's on a
> different host.  Of course, unless the user goes to the original author's

Yes, they don't change. That's what i wanted to say, too - as long as
people trust (or independently verify) the checksums for the provided
packages, it doesn't really matter that much if the script goes to
his website and downloads software from there.

> page to check, he'll just have to trust that the md5sums in etc/md5sum.conf
> are accurate (which almost negates the purpose in the first place, but
> that's besides the point :-P).

Yes. Imho it works the other way round: Bryan collects the "original"
checksums and then downloads the packages mostly from their original
sites and checks if the download succeeded, using his canned list
of checksums (etc/md5sum.conf).

> See above.  I would think that this would be enough.  As far as I know,
> there haven't been any proven real-world collisions with md5sums given
> different inputs.  But I'm no security expert either.  Actually, as a home

That theoretical possibility of a clash, or rather, that someone could
fake a file for a given MD5 sum, made OpenBSD switch to SHA1 where no
such method appears to be currently known.

> user, I'm naive.  I figure if someone was able to hack into apache.org and
> change the tarball, or otherwise hijack my session to get me to download the
> wrong one, then it just wasn't my day and I'd chock it up as a lost.  Hasn't

Hacking into apache.org is very evil indeed. Hijacking the session could
easily be prevented by offering HTTPS or SSH (RSYNC) or SFTP downloads.

> I don't build much from source these days.

For me, it depends. If you have a number of different platforms, but the
need/want to have similar packages installed on each, possibly with
slightly different options, you may reach a point where building stuff
yourself is easier than downloading several flavours of canned packages
for each platform.

> Btw, did Bryan fix your forum account and/or set up your SF access?

Ooops - at least I never tried again, but I also have not received
anything from him, too. You also don't list me as a developer
(which is ok with me).


Best,
--Toni++

Re: [Apachetoolbox-devel] Re: General: logging revisited...

[Kevin J. M. Jr. <km...@WP...>]

Hey Toni,


Wednesday, July 24, 2002, 10:12:24 AM, you wrote:

>> KJMJ> granted. As said, the thing to do - imho - is to at least just
TM>   ^^^^ ?!?

This misquote is most likely due to the fact that I forwarded the message to
de...@ap..., so mutt must have thought I was the author.

TM> Yes. MD5 and SHA1 sums are a good way of suggesting that the tarball
TM> on the server hasn't been tampered with, even if it comes from
TM> evilbryansoftware.com. PGP signatures are another way of asserting
TM> that.

PGP signatures don't seem to be so prevalent, at least from my experience.
And I simply don't have enough experience with gnupg to be able to perform
this checking (though I could learn, I just haven't had the need).  As far
as SHA1, I really haven't seen that being used outside the realm of LDAP
password storage, but I'm sure it's because most people are still using MD5.

TM> Hmmm? I don't exactly understand this one, and _if_ I get the complete
TM> tarball, this _is_ from evilbryansoftware.com, or rather,
TM> apachetoolbox.com. But that's not a fundamental difference in the
TM> way it works, or could work.

The point I was trying to make is that if the package on his server were not
the same, but something he patched, then repackaged, and then conned people
into downloading.  He was trying to avoid people thinking this.

TM> I was also under the impression that Bryan - for some packages - has a
TM> kind of backup server to download from when the original source is
TM> unavailable, unreliable, or the owner can't afford to have all people
TM> download his software.

This is true, but the md5sum shouldn't change just because it's on a
different host.  Of course, unless the user goes to the original author's
page to check, he'll just have to trust that the md5sums in etc/md5sum.conf
are accurate (which almost negates the purpose in the first place, but
that's besides the point :-P).

TM> Hmmm... Other than looking at the checksums and the patches, and
TM> possibly the original sources, what should the paranoid user do?

See above.  I would think that this would be enough.  As far as I know,
there haven't been any proven real-world collisions with md5sums given
different inputs.  But I'm no security expert either.  Actually, as a home
user, I'm naive.  I figure if someone was able to hack into apache.org and
change the tarball, or otherwise hijack my session to get me to download the
wrong one, then it just wasn't my day and I'd chock it up as a lost.  Hasn't
happened yet :)  For production machines (which I really don't own), I would
check the md5sum, but normally I just apt-get my packages anyway.  I don't
build much from source these days.

TM> There is a point where it's easier to program it all onself instead
TM> of trying to find out if a foreign package is trojaned or not. But
TM> then I don't think I understood what you said.

Yeah, it does get a little overkill.  Security experts will push this, but
hardly anyone else cares (or knows enough to care).

TM> No way since my desktop is *nix, too.

I dual boot my machines.  Linux hasn't gotten where it merits me tossing my
whole Windows system, and unfortunately, of all the *nixes out there, it has
the best hardware support (which isn't all that great).

>> filtering, templates, macros, etc. goes, I haven't used anything else as
TM>   ^^^^^^^^^  ^^^^^^^^^
TM>   procmail?  vi?

Heh.  Yeah, I use that stuff, but it's just not worth it.  I wanted
something fast and easy.  I like the CLI just as much as the next guy, but I
like the GUI too.

TM> In mutt you could do this with a hook that sets the header according
TM> to various criteria. I just have a std setting for all mails and use
TM> vi(m) to manipulate them as needed.

I could do it with a macro in the bat! (which has regexp support), but like
I said, I typically like to be CC'ed on list responses.  To each his own.

Btw, did Bryan fix your forum account and/or set up your SF access?

-- 
Kevin

[Apachetoolbox-devel] Re: General: logging revisited...

[Toni M. <su...@oe...>]

Hi Kevin,

[ just carved out about 4 out of 5 "Re:" and Co. ]

On Wed, Jul 24, 2002 at 09:37:38AM -0400, Kevin J. Menard, Jr. wrote:
> Wednesday, July 24, 2002, 9:23:12 AM, you wrote:
> KJMJ> granted. As said, the thing to do - imho - is to at least just
  ^^^^ ?!?
> KJMJ> echo the actual install commands for the record, so someone or
> KJMJ> some program can pick the files up at a later date _again_ and
> KJMJ> eg. create a tarball to install on a different box.
> This would work too.  Unfortunately, we can only try to convince one
> upstream author at a time :-/

yes - that's what I suggested in my first post.

> KJMJ> Well, the first thing to know is where the files go before I can
> KJMJ> start and modify them in the first place. I was also under the
> KJMJ> impression that it is a generally accepted systems (and package)
> KJMJ> management principle to record which files go where at installation
> KJMJ> time.
> Where is this record usually kept?  I don't think I've run across such a
> package.  About the nicest thing I've come across is that a package (such as
> Apache), will install everything into it's own subdir, so you know where
> everything is.

For ATB, the record is usually kept in logs/package-install.log. For
package managers, the logs are kept in system dependent locations.
But your question suggests that you asked something different than
what I tried to answer :(

> True.  I was thinking more along the lines of something automated, but a
> default value would cure that.

Yes.

> KJMJ> That's a good idea anyway, although these are different problems to
> KJMJ> be solved: One is to make sure we don't get bogus source packages,
> KJMJ> and one is (after compiling Apache) to generate Apache packages for
> KJMJ> (local) distribution. installwatch seems to solve the former problem,
> KJMJ> but the solution to the latter problem is unclear.
> Well, installwatch doesn't do anything in the way of making sure the package
> on the server itself is not trojaned (though the md5sums should verify
> this).

Yes. MD5 and SHA1 sums are a good way of suggesting that the tarball
on the server hasn't been tampered with, even if it comes from
evilbryansoftware.com. PGP signatures are another way of asserting
that.

> I think his concern was, with something as crucial as a web server,
> he didn't want people to be paranoid about installing it and thinking his
> script goes to http://www.evilbryansoftware.com or something and grabs a

Hmmm? I don't exactly understand this one, and _if_ I get the complete
tarball, this _is_ from evilbryansoftware.com, or rather,
apachetoolbox.com. But that's not a fundamental difference in the
way it works, or could work. I was also under the impression that
Bryan - for some packages - has a kind of backup server to download
from when the original source is unavailable, unreliable, or the
owner can't afford to have all people download his software.

> tarball that will give him a backdoor into all their machines (at least
> that's my somewhat exaggerated understanding of it).

Hmmm... Other than looking at the checksums and the patches, and
possibly the original sources, what should the paranoid user do?

There is a point where it's easier to program it all onself instead
of trying to find out if a foreign package is trojaned or not. But
then I don't think I understood what you said.

> Shouldn't be any problems, just a pain in the neck.  I haven't had any
> experience with Slackware myself, but I know the Debian way of doing things
> is very different from the RedHat/Mandrake way of doing things.  But the
> package holds promise.

I don't know Slackware either, and am also not too engaged with RPM,
but Debian has a well designed system to handle packages although
their system isn't exactly easy to handle...


[ OT stuff ahead ]

> I only used mutt once or twice, and it seemed nice.  I personally use "The
> Bat!" on Win2k Pro on my laptop.  It's the best MUA I've come across, though

No way since my desktop is *nix, too.

> filtering, templates, macros, etc. goes, I haven't used anything else as
  ^^^^^^^^^  ^^^^^^^^^
  procmail?  vi?

> nice.  Speaking of which, I just set up a template to set the "Reply-to:" to
> de...@ap....  Normally I just let the Reply-to-all button do the

In mutt you could do this with a hook that sets the header according
to various criteria. I just have a std setting for all mails and use
vi(m) to manipulate them as needed.


Best,
--Toni++

[Apachetoolbox-devel] Fwd: Re: General: logging revisited...

[Kevin J. M. Jr. <km...@WP...>]

This is a forwarded message
From: Toni Mueller <su...@oe...>
To: "Kevin J. Menard, Jr." <km...@WP...>
Date: Wednesday, July 24, 2002, 9:08:09 AM
Subject: General: logging revisited...

===8<==============Original message text===============

Hi Kevin,

On Wed, Jul 24, 2002 at 08:10:50AM -0400, Kevin J. Menard, Jr. wrote:
> would imagine most upstream authors spend a lot of time coding their
> software, and thus have no reason/need to uninstall it.  Another thing that

granted. As said, the thing to do - imho - is to at least just
echo the actual install commands for the record, so someone or
some program can pick the files up at a later date _again_ and
eg. create a tarball to install on a different box.

(That's what I do with ATB: Compile and test on one box, then tar
up and move to another, unpack &test again before going live. If
I don't know which files end up where, I've got a problem...).

> comes to mind is that just because the "install" target picks a path to put
> the files into, that does nothing if the user decides to modify those files
> (and save those changes) or if he moves the files to another path (of
> course, this should obviously fail).  Maybe a better way would be to make a

Well, the first thing to know is where the files go before I can
start and modify them in the first place. I was also under the
impression that it is a generally accepted systems (and package)
management principle to record which files go where at installation
time.

> checksum of the installed files and compare them before a delete.  If the
> checksums don't match, the file was modified, and shouldn't be removed.

Ok... (or: ask).

> The source tarball for this package also contains installwatch.  Last time I
> talked to Bryan about it, he wanted to keep installwatch in, so people could
> see that the ATB wasn't grabbing trojaned tarballs or something.

That's a good idea anyway, although these are different problems to
be solved: One is to make sure we don't get bogus source packages,
and one is (after compiling Apache) to generate Apache packages for
(local) distribution. installwatch seems to solve the former problem,
but the solution to the latter problem is unclear. Your first (?)
reply suggested that this checkinstall-package also contains software
to solve this latter problem and, on top of that, be able to generate
packages conforming to certain standards so that they integrate with
already-existing package management tools. I don't see the conflict,
but also didn't look at the package yet.

> http://asic-linux.com.mx/~izto/checkinstall/
> 
> Have fun :)

Well, I guess I'll do.

> TOFU?  If that means I included all of your email at the bottom for no

I didn't say "for no good reason", but otherwise that's what i meant.

> reason, it's just because I typed that from an ssh session late last night,

That's my usual operating mode for writing just about any mail, except
that I'm not always doing it late at night.

> and was just too lazy to delete the lines from pine :-P  But, if you have a
> decent mail client, it should ignore or otherwise indicate, that anything
> after the "-- <CR><LF>" is superfluous :)

Hmm... I have mutt and vim as my editor. That should be
decent enough...


Best,
--Toni++

===8<===========End of original message text===========



-- 
Best regards,
 Kevin                            mailto:km...@wp...

Re: [Apachetoolbox-devel] Re: General: logging revisited...

[Kevin J. M. Jr. <km...@WP...>]

Hey Toni,


Wednesday, July 24, 2002, 4:42:14 AM, you wrote:

TM> unfortunately upstream authors appear not to think about such
TM> problems... and I'd like to know why.

There are two reasons I can think of, though one is just laziness.  But I
would imagine most upstream authors spend a lot of time coding their
software, and thus have no reason/need to uninstall it.  Another thing that
comes to mind is that just because the "install" target picks a path to put
the files into, that does nothing if the user decides to modify those files
(and save those changes) or if he moves the files to another path (of
course, this should obviously fail).  Maybe a better way would be to make a
checksum of the installed files and compare them before a delete.  If the
checksums don't match, the file was modified, and shouldn't be removed.

TM> That would be *really* great - only that I've never heard about it.
TM> Would gladly take any pointers :)

The source tarball for this package also contains installwatch.  Last time I
talked to Bryan about it, he wanted to keep installwatch in, so people could
see that the ATB wasn't grabbing trojaned tarballs or something.

TM> Do you have any links, please?

http://asic-linux.com.mx/~izto/checkinstall/

Have fun :)

TM> PS: You're posting TOFU style...

TOFU?  If that means I included all of your email at the bottom for no
reason, it's just because I typed that from an ssh session late last night,
and was just too lazy to delete the lines from pine :-P  But, if you have a
decent mail client, it should ignore or otherwise indicate, that anything
after the "-- <CR><LF>" is superfluous :)

--
 Kevin

[Apachetoolbox-devel] Re: General: logging revisited...

[Toni M. <su...@oe...>]

Hi Kevin,

On Tue, Jul 23, 2002 at 10:42:28PM -0400, Kevin J Menard wrote:
> Best thing I can think of is to examine the Makefile and look at the
> "install" target.

unfortunately upstream authors appear not to think about such
problems... and I'd like to know why.

> However, one of my projects I have on the backburner right now is to
> integrate "checkinstall" into ATB.  This program claims to cure just this
> problem, while also allowing the building of RPMs, debs, & Slack packages
> from the source.

That would be *really* great - only that I've never heard about it.
Would gladly take any pointers :)

Btw, when upgrading from ATB 1.5.58 to 1.5.59 I noticed that several
libs didn't get upgraded since ATB assumes that the result will run
on the same machine than the one where it's compiled. This should
generally be a wrong assumption, but may be induced by upstream
author's package mechanisms. Further investigation required...

> Dunno.  Started working on it, but it requires a number of changes (at
> least at initial examination).

Do you have any links, please?


Best,
--Toni++

PS: You're posting TOFU style...

Re: [Apachetoolbox-devel] General: logging revisited...

[Kevin J M. <km...@WP...>]

Best thing I can think of is to examine the Makefile and look at the
"install" target.

However, one of my projects I have on the backburner right now is to
integrate "checkinstall" into ATB.  This program claims to cure just this
problem, while also allowing the building of RPMs, debs, & Slack packages
from the source.

Dunno.  Started working on it, but it requires a number of changes (at
least at initial examination).

-- 
Kevin

On Wed, 24 Jul 2002, Toni Mueller wrote:

>
>
> Hi,
>
> while I acknowledge that mostly the respective upstream authors are
> guilty, is there an easy way to generate useful logs from the
> install script so as to get a complete list of files (target files,
> that is) that get installed?
>
> Stupid logging like "Installing F-Word/Junk.php" only underlines the
> need for heavy swearing, but doesn't solve any problem, like finding
> out where the heck some obscure library wound up :(
>
> No, constantly running "find" on the system to see these is not
> an option when precise info could be as cheap as not suppressing
> the echoing of commands in a Makefile.
>
>
> Best,
> --Toni++
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Apachetoolbox-devel mailing list
> Apa...@li...
> https://lists.sourceforge.net/lists/listinfo/apachetoolbox-devel
>

[Apachetoolbox-devel] General: logging revisited...

[Toni M. <su...@oe...>]

Hi,

while I acknowledge that mostly the respective upstream authors are
guilty, is there an easy way to generate useful logs from the
install script so as to get a complete list of files (target files,
that is) that get installed?

Stupid logging like "Installing F-Word/Junk.php" only underlines the
need for heavy swearing, but doesn't solve any problem, like finding
out where the heck some obscure library wound up :(

No, constantly running "find" on the system to see these is not
an option when precise info could be as cheap as not suppressing
the echoing of commands in a Makefile.


Best,
--Toni++

[Apachetoolbox-devel] 1.5.59 quick release

[<io...@ap...>]

added a quick little bugfix in PDFLib that was sent in.  changed PHP to 
v4.2.2 because of the nasty security bug.  Not cool for the php crew.  I 
think some people might be loosing faith in php's security department :(

-Bryan

Re: [Apachetoolbox-devel] paging revisited

[Kevin J. M. Jr. <km...@WP...>]

I changed my mind again.  Since less and more should already be found by 
etc/external, I decided to make use of that (why duplicate the work?). 
Check it out in the new beta release I slapped up.  Read the 
announcements section.

Kevin J. Menard, Jr. wrote:
> Toni Mueller wrote:
> 
>>                   for i in /usr/bin/less /usr/local/bin/less \
>>                         /bin/less /usr/bin/more /bin/more ; do
> 
> 
> I added a couple more search paths, so it's:
> 
> for i in /usr/bin/less /usr/local/bin/less \
> /bin/less $LOCAL_PATH/bin/less /usr/bin/more \
> /usr/local/bin/more /bin/more $LOCAL_PATH/bin/more ; do
> 
> But it works all fine for me.
> 
> Thanks a lot for the cool patch.
> 

Re: [Apachetoolbox-devel] paging revisited

[Kevin J. M. Jr. <km...@WP...>]

Toni Mueller wrote:
>                   for i in /usr/bin/less /usr/local/bin/less \
>                         /bin/less /usr/bin/more /bin/more ; do

I added a couple more search paths, so it's:

for i in /usr/bin/less /usr/local/bin/less \
/bin/less $LOCAL_PATH/bin/less /usr/bin/more \
/usr/local/bin/more /bin/more $LOCAL_PATH/bin/more ; do

But it works all fine for me.

Thanks a lot for the cool patch.

-- 
Kevin

Re: [Apachetoolbox-devel] paging revisited

[Toni M. <su...@oe...>]

Hi,

On Fri, Jul 12, 2002 at 08:43:34PM +0200, Toni Mueller wrote:
> well, i've just hacked something non-functional on etc/functions.conf
> which should enable paging. Somehow it doesn't work, only I don't
> know why...

I still don't understand the problem, but I've fixed it. The
modified function reads like this (tested only with my std
setting of PAGER=/bin/less plus some LESSxxx vars):


#shows the help file for all the mods
print_descriptions()
        {
                ### find pager if possible:
                P=cat
                if [ X"${PAGER}" != X ]; then
                        P=${PAGER}
                else
                  for i in /usr/bin/less /usr/local/bin/less \
                        /bin/less /usr/bin/more /bin/more ; do
                        if [ -x $i ]; then
                                P=$i
                                break
                        fi
                  done
                fi

                T=${TERM}

                env - TERM=$T $P $root/etc/help
                echo "See $root/etc/help for more info."
        }



Best,
--Toni++

[Apachetoolbox-devel] paging revisited

[Toni M. <su...@oe...>]

Hi,

well, i've just hacked something non-functional on etc/functions.conf
which should enable paging. Somehow it doesn't work, only I don't
know why...

here goes:

+ print_descriptions
+ P=cat
+ '[' X/bin/less '!=' X ']'
+ P=/bin/less
+ eval '/bin/less /home/toni/mnt/web/ATB/Apachetoolbox-1.5.58/etc/help'
++ /bin/less /home/toni/mnt/web/ATB/Apachetoolbox-1.5.58/etc/help
There is no -/ option ("less --help" for help)
+ echo 'See /home/toni/mnt/web/ATB/Apachetoolbox-1.5.58/etc/help for more info.'
See /home/toni/mnt/web/ATB/Apachetoolbox-1.5.58/etc/help for more info.
+ HitAnyKey



The function print_descriptions reads like this:

#shows the help file for all the mods
print_descriptions()
        {
                ### find pager if possible:
                P=cat
                if [ X"${PAGER}" != X ]; then
                        P=${PAGER}
                else
                  for i in /usr/bin/less /usr/local/bin/less \
                        /bin/less /usr/bin/more /bin/more ; do
                        if [ -x $i ]; then
                                P=$i
                                break
                        fi
                  done
                fi

                eval "$P $root/etc/help"
                echo "See $root/etc/help for more info."
        }




The intention was to check for some common pagers in common locations
if the variable PAGER is empty, and default to 'cat' if nothing is
found/present. Where on earth less gets that '-/' idea from, I have
no idea :(


Best,
--Toni++

Re: [Apachetoolbox-devel] Re: mod_watch in .58: improved (bin attached)

[Kevin J. M. Jr. <km...@WP...>]

Toni Mueller wrote:

> ugh - I thought that one should deduce the location from the other
> path settings instead. IFF apxs really needs to be there before
> "real" compilation starts, then I'm out of ideas. Btw, before trying
> "find", trying "locate" could be MUCH MUCH faster to be sure.

The problem with "locate" is if the user doesn't run "updatedb" for a 
long time, it's out of date, and will return false-positives.  "find" 
will work every time.

> When using Debian, I'm currently only running potato for some systems
> I don't want to/cannot touch, and sid otherwise. But woody is not bad,
> too. Nice to hear someone using Debian at all!

I used to run sid, until I got burnt bad with a messed up dpkg.  The 
problem is, I like woody as a stable sid.  But with the freeze and all, 
I find myself apt-pinning packages, and I really don't want to be doing 
that.

> He sounded like he wouldn't invest any significant personal work for
> this in the near future to include features other people might like
> to see. I can dig out what he really said, but a patch could be ok.
> OTOH I don't feel able to code this, so I need to get on with what
> I already have.

I could take a look some time, when I have a chance.  I've never coded 
an apache module, but if his code is decent, it shouldn't be hard to follow.


> I didn't intend to yell, but you sound like fixing this should be
> easy. We'll see.

The way it works in my code is that each module is an object of a module 
class, and each has a description attribute.  So, when you ask for a 
description, it just grabs it for the module you're looking for.  Still 
just prints to STDOUT, but it works, and much easier to follow :)

-- 
Kevin

Re: [Apachetoolbox-devel] Re: mod_watch in .58: improved (bin attached)

[Toni M. <su...@oe...>]

Hi,

On Fri, Jul 12, 2002 at 11:38:53AM -0700, Kevin J. Menard, Jr. wrote:
> Well this requires the person to install it in a semi-standard location 
> (like most of them other modules).  I could do a `find / -name apxs`, 
> but that'd be rather time consuming.

ugh - I thought that one should deduce the location from the other
path settings instead. IFF apxs really needs to be there before
"real" compilation starts, then I'm out of ideas. Btw, before trying
"find", trying "locate" could be MUCH MUCH faster to be sure.

> > Which platform?
> Debian woody.

   8)))

When using Debian, I'm currently only running potato for some systems
I don't want to/cannot touch, and sid otherwise. But woody is not bad,
too. Nice to hear someone using Debian at all!

> I've noticed this, and was reluctant to hard code the values like you 
> did in the patch, but those are sane locations, so I just let it pass. 

The "default" paths were much more ill-designed, therefore I felt
the need to patch that.

> Hmm . . . So he's completely reluctant to update it?  Maybe if someone 
> produced a patch for it, he'd accept it.  Dunno what to say.

He sounded like he wouldn't invest any significant personal work for
this in the near future to include features other people might like
to see. I can dig out what he really said, but a patch could be ok.
OTOH I don't feel able to code this, so I need to get on with what
I already have.

> Yell at Bryan.  I was accounting for this in my new code though . . . :)

I didn't intend to yell, but you sound like fixing this should be
easy. We'll see.


Best,
--Toni++

Re: [Apachetoolbox-devel] Re: mod_watch in .58: improved (bin attached)

[Kevin J. M. Jr. <km...@WP...>]

Toni Mueller wrote:

> well, after feeling the need for different Apache versions I started
> out with something like /usr/local/stow/apache-1.3.26 as the root of
> the tree, but quickly found that I'd rather have made this
> /usr/local/stow/apache-1.3.26.<n> with n = 1, 2, 3, ... or something
> else explaining the difference (ie, module&option selections).

Well this requires the person to install it in a semi-standard location 
(like most of them other modules).  I could do a `find / -name apxs`, 
but that'd be rather time consuming.

> Which platform?

Debian woody.


> AFAIR this module still has a severe problem (imho) which is that it
> needs to place the collected statistics in a file or directory (don't
> remember which) that is determined at compile time instead of having
> run time configuration directives.

I've noticed this, and was reluctant to hard code the values like you 
did in the patch, but those are sane locations, so I just let it pass. 
Someone who needs to tweak that, can.

> Unfortunately this precludes running
> several instances of Apache which use this module on the same machine
> (bummer #1). Problem #2 is that the locations in question tend to be
> writable only by root. I'd very much prefer to have full configurability
> on all modules so as to be able to have self-contained trees which
> might eg. contain one Apache instance each, and without the need to
> reconfigure and recompile the whole thing for each instance. Just
> in case the module's author rejected the idea of spiffing up his
> module since he said it had cost him too much time already, and does
> what he needs as-is.

Hmm . . . So he's completely reluctant to update it?  Maybe if someone 
produced a patch for it, he'd accept it.  Dunno what to say.

> 
> 
> Btw, reading it with "99"
> never made sense to me - it just scrolls through despite having set
> PAGER.

Yell at Bryan.  I was accounting for this in my new code though . . . :)

Re: [Apachetoolbox-devel] Re: mod_watch in .58: improved (bin attached)

[Toni M. <su...@oe...>]

Hi Kevin,

On Fri, Jul 12, 2002 at 11:14:17AM -0700, Kevin J. Menard, Jr. wrote:
> Ok, I got mod_watch all working now.  It looks for apxs in a bunch of 
> different spots (mine is always in /usr/local/apache/bin, but I don't 
> know if someone might put it in /usr/bin or something).

well, after feeling the need for different Apache versions I started
out with something like /usr/local/stow/apache-1.3.26 as the root of
the tree, but quickly found that I'd rather have made this
/usr/local/stow/apache-1.3.26.<n> with n = 1, 2, 3, ... or something
else explaining the difference (ie, module&option selections).

> Mine worked fine without the ranlib thing.  So, in the beta I plan on 

Which platform?

> throwing up some time this weekend, I'll leave it commented out so I can 
> see what other people are experiencing.  If it's a problem, just remove 

Ok.

> never even notice this mod, and now that I see it, it looks pretty cool. 
>   I was looking for per virt host mrtg output :)

AFAIR this module still has a severe problem (imho) which is that it
needs to place the collected statistics in a file or directory (don't
remember which) that is determined at compile time instead of having
run time configuration directives. Unfortunately this precludes running
several instances of Apache which use this module on the same machine
(bummer #1). Problem #2 is that the locations in question tend to be
writable only by root. I'd very much prefer to have full configurability
on all modules so as to be able to have self-contained trees which
might eg. contain one Apache instance each, and without the need to
reconfigure and recompile the whole thing for each instance. Just
in case the module's author rejected the idea of spiffing up his
module since he said it had cost him too much time already, and does
what he needs as-is.


When I started to tinker with the Apachetoolbox, I just explored the
forest of modules out there, most of which are unknown to me. There
are still modules who have slightly different names, but very similar
descriptions, and there is no hint on when to use which, or what
would happen should one include two of them. :)   At least, the
"help" file (which thankfully can be read w/o having the script
open) contains some nice information. Btw, reading it with "99"
never made sense to me - it just scrolls through despite having set
PAGER.


Best,
--Toni++

Re: [Apachetoolbox-devel] Re: mod_watch in .58: improved (bin attached)

[Kevin J. M. Jr. <km...@WP...>]

Toni Mueller wrote:

> You don't have to take my word for it. Better test it yourself. I
> had my version of the mod_watch script from .../bin included in
> my first mail today, so you should have no problem.

Ok, I got mod_watch all working now.  It looks for apxs in a bunch of 
different spots (mine is always in /usr/local/apache/bin, but I don't 
know if someone might put it in /usr/bin or something).

Mine worked fine without the ranlib thing.  So, in the beta I plan on 
throwing up some time this weekend, I'll leave it commented out so I can 
see what other people are experiencing.  If it's a problem, just remove 
the comment, and it it should work.  Thanks for the patch.  Actually, I 
never even notice this mod, and now that I see it, it looks pretty cool. 
  I was looking for per virt host mrtg output :)

-- 
Kevin

Re: [Apachetoolbox-devel] Re: mod_watch in .58: improved (bin attached)

[Kevin J. M. Jr. <km...@WP...>]

Toni Mueller wrote:

> oh - I don't even know what apxs or EAPI is to begin with, but just
> hacked on the existing build script to get the paths and flags for
> the Apache Makefile right.

Unfortunately, it looks like this requires apxs to build.  I can make a 
work around (just look for the file), but the problem is that one must 
have an existing Apache install to build this.

More on what each does specifically can be had at apache.org, but like i 
said, i'm pretty sure one is for building dynamic modules and one for 
static.


> 
> The problem is that requiring people to install Perl should preclude
> using Apachetoolbox in quite a few corporate environments. OTOH I'm
> not sure that I would mind doing so ;)

More on this below.


> Hmmm... if you could mail me the whole thing? Without sources,
> please... then I'll take a look, but no promises.

I can mail it, but if you have a sf account, i'm sure bryan wouldn't 
mind adding you to the list of developers.  You could then just ssh in 
and do whatever (that's what I do now).

> I think you are overly optimistic, or it may be just your and my
> regional views. Whatever... We'll only know it if we try.

I don't know of a modern OS suite that doesn't install Perl.  Perhaps 
older systems would not have Perl, and be reluctant to install, but 
these are typically the types of groups that won't mess around with 
their httpd . . .  But a lot of software has prereqs for installation. 
Making ATB 2.0 require perl isn't too much to ask I think :)


> Hmmm... requiring to install modules into system locations using CPAN
> would be BAD (imho), but installing into a local path should be ok,
> especially when most Perl modules are only a few KB in size, compared
> to several hundred KB or some megs for the "real thing".

It's something to evaluate.  I actually use some of the LWP modules 
currently, and I was reluctant to do that.  But we can see.  Like I 
said, I didn't look into it too much.

Re: [Apachetoolbox-devel] Re: mod_watch in .58: improved (bin attached)

[Toni M. <su...@oe...>]

Hi,

On Fri, Jul 12, 2002 at 10:15:40AM -0700, Kevin J. Menard, Jr. wrote:
> Well, it needs to check for where apxs is.  I don't know why it needs 
> this for a static library (I was under the impression static modules 
> used EAPI), but oh well.

oh - I don't even know what apxs or EAPI is to begin with, but just
hacked on the existing build script to get the paths and flags for
the Apache Makefile right.

> Personally, I think doing this in shell programmin is a PITA.  It works 

Yes. Shell script portability is a well-known problem.

> great on my platform, but ATB has been riddled with hacks to work on 

 :/

The problem is that requiring people to install Perl should preclude
using Apachetoolbox in quite a few corporate environments. OTOH I'm
not sure that I would mind doing so ;)

> the only programmer on it, and getting good grades took precedent over 
> getting that out.  Every now and then I get ambitious and go back to it. 

Oh - I understand.

>   It's in a rather buggy state, but a somewhat workable one too.  If 
> you'd like to help out, we can start it up again.  It's just adding 
> patches to this existing version is much easier than rewriting the whole 
> thing.

Hmmm... if you could mail me the whole thing? Without sources,
please... then I'll take a look, but no promises.

> I think you'll find that more machines have perl than bash, for 

I think you are overly optimistic, or it may be just your and my
regional views. Whatever... We'll only know it if we try.

> instance.  The issue then becomes versions.  IIRC, I couldn't use all 
> the scope keywords (like "our") because they were Perl 5.6 specific, and 
> I'm sure there are many machines out there running 5.00x still.  The 

Yes.

> other thing I was trying to avoid was making people install modules (and 
> I didn't want to just include them in the script, because that would 
> terribly bloat things, while making the coding easier).  So, all in all, 

Hmmm... requiring to install modules into system locations using CPAN
would be BAD (imho), but installing into a local path should be ok,
especially when most Perl modules are only a few KB in size, compared
to several hundred KB or some megs for the "real thing".


Best,
--Toni++

Re: [Apachetoolbox-devel] Re: mod_watch in .58: improved (bin attached)

[Kevin J. M. Jr. <km...@WP...>]

Toni Mueller wrote:

> 
> Sorry, what exactly didn't you get to compile or not?
>

Well, it needs to check for where apxs is.  I don't know why it needs 
this for a static library (I was under the impression static modules 
used EAPI), but oh well.


> Well (oh - I wrote the snippet above before reading this) I thought
> touching Perl was a no-no, and the idea of porting Apachetoolbox to
> Perl was already cancelled.

Personally, I think doing this in shell programmin is a PITA.  It works 
great on my platform, but ATB has been riddled with hacks to work on 
others.  The perl version of ATB was never canceled.  It was just I was 
the only programmer on it, and getting good grades took precedent over 
getting that out.  Every now and then I get ambitious and go back to it. 
  It's in a rather buggy state, but a somewhat workable one too.  If 
you'd like to help out, we can start it up again.  It's just adding 
patches to this existing version is much easier than rewriting the whole 
thing.

> Otherwise I'm a big fan of Perl and would
> generally like to see the Apachetoolbox in Perl. The only problem
> is maybe that Perl could be available on fewer systems out there
> because of admin ignorance or company policy.

I think you'll find that more machines have perl than bash, for 
instance.  The issue then becomes versions.  IIRC, I couldn't use all 
the scope keywords (like "our") because they were Perl 5.6 specific, and 
I'm sure there are many machines out there running 5.00x still.  The 
other thing I was trying to avoid was making people install modules (and 
I didn't want to just include them in the script, because that would 
terribly bloat things, while making the coding easier).  So, all in all, 
it's a bit ugly right now . . . :-/

-- 
Kevin

Re: [Apachetoolbox-devel] Re: mod_watch in .58: improved (bin attached)

[Toni M. <su...@oe...>]

Hi Kevin,

On Fri, Jul 12, 2002 at 09:28:44AM -0700, Kevin J. Menard, Jr. wrote:
> Toni Mueller wrote:
> > Then I contacted the author of that
> > module who suggested using ranlib on the generated library, which
> > made it work.
> Ok.  I just never heard of it, so I was trying to learn a bit more about it.

well, ranlib makes some kind of index into the archive where a linker
can look. Apparently the linker doesn't look elsewhere.

> > So I regard the ranlib command as mandatory...
> Ok, then it stays :)

You don't have to take my word for it. Better test it yourself. I
had my version of the mod_watch script from .../bin included in
my first mail today, so you should have no problem.

> Done.  Man, I'm not a big fan of this Mozilla mail client.  I can't wait 
> until my laptop gets back.  I'm only using this now for the IMAP support 
> so I can download my mail when it gets back.

I also only use the Mozilla mail client when accessing my freemail
accounts. For the rest of it I use mutt :-)
But I have not tried to get mutt to work with IMAP+SSL+LDAP yet
which I should in the long run.

> So far I haven't had much luck getting this to compile, but I'm sure 

Sorry, what exactly didn't you get to compile or not?

> it's something minor.  Also, I really don't use sed but I could figure 
> out what you were doing just fine.  But do you know if there's any 
> differences between gnu sed and perhaps the stock hp-ux or solaris sed? 

Not really. I figured it out on both a Linux and an OpenBSD box.
There may well be differences, but I'm not a SED programmer, either.
Only that I wanted to stay within the shell paradigma of the package,
or I'd have programmed it in Perl in the first place. But doing so
would have broken it for many purposes.

>   I just want to make sure this works cross-platform.  Otherwise, I can 
> just change it to a perl call just as easily.

Well (oh - I wrote the snippet above before reading this) I thought
touching Perl was a no-no, and the idea of porting Apachetoolbox to
Perl was already cancelled. Otherwise I'm a big fan of Perl and would
generally like to see the Apachetoolbox in Perl. The only problem
is maybe that Perl could be available on fewer systems out there
because of admin ignorance or company policy. I also have no access to
a HP or Solaris (or AIX) box, so I can't test this.


Best,
--Toni++