>>>>> "CH" == Craig Hartnett <subs@niner.net> writes:
CH> So it would seem that as a virtual server user I am SOL.
It's too difficult to quote your self-quotes, so I'll just comment without
context.
Firstly, you'll have an easier time reaching the mj2 developers at
mj2-dev@csf.colorado.edu. That software is run by Mj2 and doesn't have the
same lag or limitations as this list. Plus, you get to try out the
software as a user.
Secondly, it's important to note that even though we want to help you get
the software going on your unconventional setup, we don't know enough about
how it works to help you. The problem with Perl modules can be overcome by
getting Perl to look somewhere else for additional modules. [1] You could
even build your own copy that looks only in your directories.
I don't know what MTA (mail transfer agent, i.e. Sendmail) your hosting
service uses; they probably have an unconventional setup there as well that
needs to be worked around. Many MTAs force us to install executables
setuid to get everything running as the proper user, and I really doubt
that they'd let you install setuid binaries. Even then, if certain
guarantees are met by the MTA (mainly that it _always_ calls our
executables as a single user that you have access to) then we can get by
without the setuid requirement. This is complicated by the web-based
components, because the web browser must also call them as the _same_ user.
In other words, everything must run as one user, regardless of whether it
is called from the command line (mj_shell), the MTA (mj_email) or the web
(mj_confirm, mj_wwwadm, mj_wwwusr).
The bottom line is that our software is designed to be installed _by your
hosting company_. You can be given a virtual domain from there and allowed
to run your own lists in it; the software supports an unlimited number of
completely separate virtual domains. But that doesn't mean it is
impossible to get it to work in your situation.
- J<
1) We already do this to get our executables do load in all of our special
modules. You could just install your modules in the same place that
Majordomo will install its own. Or you could help us hack the install
process a bit. Close to the beginning of any of the Majordomo
executables, just after the BEGIN block, you'll see:
use lib "$::LIBDIR";
Change that to
use lib "$::LIBDIR", "/path/to/your/modules"
and you're set. Getting this to happen automatically in the appropriate
circumstances requires more hacking, but isn't impossible.
References:
|
|
