[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++