Okay, I gave Majordomo 2 a shot, and have given up on it for the time
being as being not close enough to finished for me to manage to get it to
work on the limited time that I have available. In the hope that the time
spent on it won't go to waste, here are the things that I ran into.
I do realize that a lot of this is probably explained somewhere, and I'm
suffering badly from the fact that I only had about three hours to spend
on this, which wasn't enough time to find all the nooks and crannies.
Unfortunately, that's really all the time I have period right now. :/ So
I'm throwing out this message in the hope that some of the observations
will be useful; please feel free to ignore any points that were just the
result of me overlooking the obvious or not RTFMing thoroughly enough.
* The documentation is *really* sparse, and it's very inobvious where
things get put and what things are called. I mostly found
configuration commands by doing an ls | grep in the files/en/config
directory of the source tree; I'm not sure where all those files ended
up after installation (admittedly, I didn't look overly hard since I
had them available in the source tree).
* The code is hard to follow in the case of any errors. I wish I had
something more specific criticism than that, but it's mostly the "lost
in a twisty little maze of modules" problem. It takes quite a bit of
code browsing to figure out what does what, and it takes a lot of
tracing of functions. On the plus side, the debug output is quite nice
for tracking problems.
* The install system just totally didn't work for me. First off, when
installing on a qmail system, there's no need at all for the setuid
wrappers, but while the rest of Majordomo 2 runs fine without them, the
installation fails because mj_shell requires that it be running as the
list user. Second, while it said it was supposed to create a
.qmail-default file, it didn't. There was no error messages of any
sort (once I just did the postinstall as the lists user), but there was
also no .qmail-default file created in the directory I told it to use
(or anywhere else that I could find).
* I spent a lot of time trying to figure out how to set an info message
before realizing that newinfo *did* still work despite all of this
funky file put management stuff. For some reason, that wasn't clear to
me.
* The welcome message is sent as a multipart MIME message. Er. And I
couldn't find a way to turn that off. Er. This is definitely not what
I want. This may just be a matter of me not happening upon the right
piece of configuration.
* The help interface in mj_shell for administrative commands is mostly
unhelpful because help admin commands is over a thousand lines long and
mj_shell doesn't use a pager. So unless you've got a really long
scrollback buffer, all the help just scrolls away.
* It'd be nice if mj_shell could handle heredocs, but I realize that's
probably pretty difficult.
* It wasn't particularly clear to me how to set global defaults. Again,
this may have just been a matter of not stumbling across the right
piece of documentation.
* Pretty much any command entered into mj_shell spewed *tons* of Perl
warnings, mostly in various places in IO::*. The first time. The next
time one entered the same command, it was fine. (I'm running 5.005_02
on Linux; the warnings were mostly undefined value warnings, but with
occasional instances of the "ambiguous open resolved to CORE::open"
warning that was introduced with 5.005.)
* It's *really* slow. (Yeah, I know, there isn't much you can do about
that.)
* (This is the one that killed it for me.) I can't figure out how to get
Majordomo to send mail via a means other than SMTP. There's the whole
qmail-queue support (which btw appears to require qmail-queue be on the
path, although I may be reading that wrong), but I absolutely could not
get it to work. Any time majordomo tried to send mail to a non-local
address, it would die badly deep in Deliver with a can't create
envelope error, which incidentally causes the shell to just die
completely in the middle of what it was doing. I'm not sure what state
that left my lists in each time it happened. I know the reason for
that; qmail was refusing to accept the mail because it thought it was a
relay attempt. But nicer error handling there would probably be good.
Anyway, I tried to set the @qmail thing in delivery_rules, but couldn't
figure out how to do it. I tried to set it in various default places,
to no avail. Looking at the files stored on disk, it had that in the
configuration files, but it wasn't working. I even tried editing
Mj::Deliver::Dest directly and removed the whole branch of code to
handle stuff other than @qmail, and it still wasn't working.
Not the best bug report, I know. :/
On any qmail system, the qmail-queue delivery method really *needs* to
be the default, since a qmail system won't relay for localhost by
default. (It's actually kind of a pain to get it to do that, and I'd
rather not unless I really have to for something.)
Anyway, I hope this is helpful criticism. I realize that the package is
still in alpha, and I'm not griping about it; it looks like it's going to
be really impressive when it's finished. I just unfortunately don't have
the time for the learning curve at the moment, or to help out much more
than trying to point out things that made it seem difficult to configure
for me.
Oh, and this was against a current copy of the CVS tree, updated just
tonight.
--
Russ Allbery (rra@stanford.edu) <URL:http://www.eyrie.org/~eagle/>
Follow-Ups:
|
|
