>>>>> "VS" == Vince Skahan <vds@bcstec.ca.boeing.com> writes:
VS> It would be a BIG help if you could do a 'find . -exec ls -alg {} \';
VS> or equivalent on an installed mj2.0 tree plus the list tree to show
VS> what it should all look like at the end (plus the associated aliases).
Well, I don't know what it should look like when finished; the final
installation is auto-generated by the Perl install tools.
VS> I grabbed the aliases from the TASKS file at the bottom, but when I
VS> mail 'help' to that majordomo alias (edited to fit here), I get a MIME
VS> message back with no content. I also see no traces of logging
VS> whatsoever, so info on how to turn logging on would help lots.
It logs to syslog and to $::TMPDIR/mj_email.debug if you ask it to (use the
-v flag). It also logs directly into the reply email if you use a subject
with "DEBUG" in it. Of course, you should test using the shell interface
anyway so you can get better debug info with -D.
This is why I'm trying to get folks to help write documentation...
VS> 2. On 'make postinstall' it could not open files/* for the items listed
VS> in the %files hash in the postinstall program.
Crap; I accidentally had that directory in MANIFEST.SKIP. I'll cut another
complete snapshot later today.
VS> 3. On 'make postinstall' if you've set the master password before, it
VS> doesn't like it if you rerun the postinstall with 'yes' for the answer
VS> for everything.
Fixed in my sources.
VS> 4. Why use setuid perl instead of a wrapper ?
Because that's the way I want to do it. It's much easier to do that than
to require compiling C. Besides, it will work if someone writes a wrapper;
I'm just not going to do so.
VS> It seems that many people will have trouble with the o/s-specific stuff
VS> needed to get perl installed properly to support it (won't some o/s's
VS> not support it and have Majordomo portability suffer as a result ?)
No, if you can have a setuid C program, you can have setuid perl scripts
even if you don't have setuid scripts. They are emulated. This is
documented in the perlsec manpage.
VS> 5. make should fail if tmp dir isn't there
You have to explicitly confirm a nonexistent temp directory; I don't see
the point in doing anything else.
VS> 6. postinstall looks like it wants to make the bin dir contents mode
VS> 6555, but it doesn't. What should the bin permissions and owner/group
VS> be ?
06555. Does the chmod fail?
VS> 7. what is the minimum set of majordomo 'administrative' aliases and
VS> the aliases needed for a VERY simple list be plus what would the
VS> required permissions for an unaltered installation plus the same list's
VS> dirs and files look like?
Aliases will be created automatically in the next version. The required
aliases are given in README, though you can probably add owner aliases.
You don't need anything else.
VS> 8. logging blows up from the perl lib tree if you didn't run h2ph It
VS> might be nice for the new config-test to check that.
I don't see a need for a new config-test. If your configuration is wrong,
it won't even install because it bootstraps itself. The config setting and
file installation is all done by running actual Majordomo code. I suppose
I could check to see if you installed perl correctly (and thus have all of
the ph files) but that seems overkill.
- J<
Follow-Ups:
References:
|
|
