FAQ
Hi folks,

Aside from the Apache problem, I can't seem to get Mailman to create a
list. This is on Cygwin.

I give the command:

$ newlist friends
Enter the email of the person running the list: ben at ahualoa.net
Initial friends password:
Create a new, unpopulated mailing list.
Usage: /usr/local/mailman/bin/newlist [options] [listname
[listadmin-addr [admin- password]]]
Options: (...a whole bunch of explanation...)
Illegal list name: friends at LittleGuy

Now, "LittleGuy" is just the name of my local host; it's not the
fully-qualified domain. I don't know why Mailman is trying to use it,
but I figured that I could force it otherwise:

$ newlist --urlhost=ahualoa.net --emailhost=ahualoa.net
friends at ahualoa.net
Enter the email of the person running the list: ben at ahualoa.net
Initial friends password:
(....)
Illegal list name: friends at LittleGuy

This doesn't make any sense at all. I'm telling Mailman very explicitly
which domain to create the list on. Why is Mailman still trying to use
my local hostname?

Thanks,
Ben

Search Discussions

  • Ben at Dec 21, 2005 at 8:47 am
    Hi folks,

    Some more information. I tried to banish all knowledge of the local
    hostname by providing the --with-mailhost and --with-urlhost arguments
    at the time of configure:

    $ ./configure --with-mail-gid=mm --with-cgi-gid=Administrators
    --with-groupname=mm --with-cgi-ext=.exe --with-mailhost=ahualoa.net
    --with-urlhost=ahualoa.net

    Then I did the 'make' and 'make install' and 'check_perms'.

    Now, when I try to add a list, I get a python error!

    $ newlist --urlhost=ahualoa.net --emailhost=ahualoa.net friends
    ben at ahualoa.net
    Initial friends password:
    Traceback (most recent call last):
    File "/usr/local/mailman/bin/newlist", line 254, in ?
    main()
    File "/usr/local/mailman/bin/newlist", line 196, in main
    mlist.Create(listname, owner_mail, pw)
    File "/usr/local/mailman/Mailman/MailList.py", line 488, in Create
    self.__lock.lock()
    File "/usr/local/mailman/Mailman/LockFile.py", line 243, in lock
    self.__write()
    File "/usr/local/mailman/Mailman/LockFile.py", line 422, in __write
    fp = open(self.__tmpfname, 'w')
    IOError: [Errno 2] No such file or directory:
    '/usr/local/mailman/locks/<site>.lock.LittleGuy.2992.0'

    I have no idea why it is trying to create this lock file, nor why it
    would be unable to do so. The permissions are all normal:

    $ ls -al /usr/local/mailman
    total 0
    (...)
    drwxrwsrwx+ 2 mailman mm 0 Dec 20 20:55 icons
    drwxrwsrwx+ 3 mailman mm 0 Dec 20 22:32 lists
    drwxrwsrwx+ 2 mailman mm 0 Dec 20 12:00 locks

    The locks folder is empty. I tried running the 'newlist' command as
    user 'mailman', and as a user with Adminstrator priveleges. In both
    cases it gives that same IOError.

    Can anyone help? All I am trying to do is create a simple mailing list.

    Thanks,
    Ben
    -----Original Message-----
    From: Ben
    Sent: Tuesday, December 20, 2005 8:26 PM
    To: mailman-users at python.org

    Aside from the Apache problem, I can't seem to get Mailman to
    create a list. This is on Cygwin.

    I give the command:

    $ newlist friends
    Enter the email of the person running the list:
    ben at ahualoa.net Initial friends password: Create a new,
    unpopulated mailing list.
    Usage: /usr/local/mailman/bin/newlist [options] [listname
    [listadmin-addr [admin- password]]]
    Options: (...a whole bunch of explanation...)
    Illegal list name: friends at LittleGuy

    Now, "LittleGuy" is just the name of my local host; it's not
    the fully-qualified domain. I don't know why Mailman is
    trying to use it, but I figured that I could force it otherwise:

    $ newlist --urlhost=ahualoa.net --emailhost=ahualoa.net
    friends at ahualoa.net Enter the email of the person running
    the list: ben at ahualoa.net Initial friends password:
    (....)
    Illegal list name: friends at LittleGuy

    This doesn't make any sense at all. I'm telling Mailman very
    explicitly which domain to create the list on. Why is
    Mailman still trying to use my local hostname?
  • Mark Sapiro at Dec 21, 2005 at 2:57 pm

    Ben wrote:
    Now, when I try to add a list, I get a python error!

    $ newlist --urlhost=ahualoa.net --emailhost=ahualoa.net friends
    ben at ahualoa.net
    Initial friends password:
    Traceback (most recent call last):
    File "/usr/local/mailman/bin/newlist", line 254, in ?
    main()
    File "/usr/local/mailman/bin/newlist", line 196, in main
    mlist.Create(listname, owner_mail, pw)
    File "/usr/local/mailman/Mailman/MailList.py", line 488, in Create
    self.__lock.lock()
    File "/usr/local/mailman/Mailman/LockFile.py", line 243, in lock
    self.__write()
    File "/usr/local/mailman/Mailman/LockFile.py", line 422, in __write
    fp = open(self.__tmpfname, 'w')
    IOError: [Errno 2] No such file or directory:
    '/usr/local/mailman/locks/<site>.lock.LittleGuy.2992.0'

    I have no idea why it is trying to create this lock file, nor why it
    would be unable to do so. The permissions are all normal:
    The MailList.Create() method needs to obtain a lock for the create
    process. Unfortunately, the name of the 'site' lock is not a valid
    Windows name. Thus on Cygwin, you need to patch MailList.py similarly
    to

    --- mailman-2.1.6/Mailman/MailList.py 2005-02-15 16:21:41
    +++ mailman-mas/Mailman/MailList.py 2005-10-15 14:29:56
    @@ -267,7 +267,7 @@
    # need to reload, otherwise... we do.
    self.__timestamp = 0
    self.__lock = LockFile.LockFile(
    - os.path.join(mm_cfg.LOCK_DIR, name or '<site>') + '.lock',
    + os.path.join(mm_cfg.LOCK_DIR, name or '_site_') + '.lock',
    # TBD: is this a good choice of lifetime?
    lifetime = mm_cfg.LIST_LOCK_LIFETIME,
    withlogging = mm_cfg.LIST_LOCK_DEBUGGING)

    --
    Mark Sapiro <msapiro at value.net> The highway is for gamblers,
    San Francisco Bay Area, California better use your sense - B. Dylan
  • Ben at Dec 22, 2005 at 10:08 am
    Thanks Mark, the source code change you gave me made it work: I was able
    to use newlist, and it completed successfully! However, when I attempt
    to connect to the Admin page (http://localhost/mailman/admin.exe) it
    says:

    "Bug in Mailman version 2.1.6 We're sorry, we hit a bug! ... the
    webmaster can find this information in the Mailman error logs."

    The error log says:
    admin(428): File "/usr/local/mailman/Mailman/MailList.py", line 591,
    in __load
    admin(428): fp = open(dbfile)
    admin(428): IOError: [Errno 13] Permission denied:
    '/usr/local/mailman/lists/friends/config.pck'

    I looked, and found that the file exists, although the permissions look
    questionable:
    $ ls -l /usr/local/mailman/lists/friends
    total 4
    -rw-rw---- 1 Ben None 3607 Dec 21 23:22 config.pck

    I tried running the 'newlist' command as user 'mailman' instead, which
    produced the same "bug!" error, even though the user/group was now set
    as mailman.mm:
    -rw-rw---- 1 mailman mm 3605 Dec 21 23:29 config.pck

    I tried explicitly forcing permissions with 'chmod 777 config.pck', and
    that made the Admin page work. So, the "660" permissions are the
    problem, not the owner/group. However, when I tried the Admin page for
    the list, I got "We're sorry, we hit a bug!" again:

    admin(4088): File "/usr/local/mailman/Mailman/MailList.py", line 512,
    in __save
    admin(4088): fp = open(fname_tmp, 'w')
    admin(4088): IOError: [Errno 13] Permission denied:
    '/usr/local/mailman/lists/friends/config.pck.tmp.LittleGuy.4088'

    This seems to be a widespread issue with Mailman under Cygwin -
    permission don't behave as under Unix, so Mailman chokes easily. I
    don't blame Mailman, I'm sure it's reasonable for it to expect
    permissions to behave they way they should.

    However, at this point I'm wondering whether the Mailman + Cygwin
    combination is workable. The Mailman website, Manual and FAQ reasonably
    state that Mailman "does not currently work on Windows" and "some
    source-code level changes are currently necessary to get Mailman working
    under Cygwin" and "It probably does not work on Windows, although it's
    possible you could get it running on a Cygwin system."

    This makes me sad, as I had high hopes, as I cannot find any real
    alternative to Mailman in the Windows world, neither free nor
    commercial. All I wanted to do was to create a small mailing list on a
    plain XP box, but it's become a week-long ordeal ending in frustration.

    I'm wide open to advice, although I suspect "Get a Linux machine" is the
    likely response :( (I do have a Linux box, but this XP box is the
    quiet, low-power always-on server machine in our office which runs our
    website with Apache wonderfully, hence that's where I must install a
    mailing list.)

    Thanks,
    Ben
    -----Original Message-----
    From: Mark Sapiro [mailto:msapiro at value.net]

    Ben wrote:
    Now, when I try to add a list, I get a python error!
    IOError: [Errno 2] No such file or directory:
    '/usr/local/mailman/locks/<site>.lock.LittleGuy.2992.0'
    The MailList.Create() method needs to obtain a lock for the
    create process. Unfortunately, the name of the 'site' lock is
    not a valid Windows name. Thus on Cygwin, you need to patch
    MailList.py similarly to

    --- mailman-2.1.6/Mailman/MailList.py 2005-02-15 16:21:41
    +++ mailman-mas/Mailman/MailList.py 2005-10-15 14:29:56
    - os.path.join(mm_cfg.LOCK_DIR, name or '<site>') '.lock',
    + os.path.join(mm_cfg.LOCK_DIR, name or '_site_') '.lock',
  • Mark Sapiro at Dec 22, 2005 at 6:00 pm

    Ben wrote:
    I tried explicitly forcing permissions with 'chmod 777 config.pck', and
    that made the Admin page work. So, the "660" permissions are the
    problem, not the owner/group. However, when I tried the Admin page for
    the list, I got "We're sorry, we hit a bug!" again:

    admin(4088): File "/usr/local/mailman/Mailman/MailList.py", line 512,
    in __save
    admin(4088): fp = open(fname_tmp, 'w')
    admin(4088): IOError: [Errno 13] Permission denied:
    '/usr/local/mailman/lists/friends/config.pck.tmp.LittleGuy.4088'

    This seems to be a widespread issue with Mailman under Cygwin -
    permission don't behave as under Unix, so Mailman chokes easily. I
    don't blame Mailman, I'm sure it's reasonable for it to expect
    permissions to behave they way they should.

    However, at this point I'm wondering whether the Mailman + Cygwin
    combination is workable. The Mailman website, Manual and FAQ reasonably
    state that Mailman "does not currently work on Windows" and "some
    source-code level changes are currently necessary to get Mailman working
    under Cygwin" and "It probably does not work on Windows, although it's
    possible you could get it running on a Cygwin system."

    I think the above is a fair summary of the issue. I do have *test*
    mailman installs under Cygwin that work, but they are not accessable
    to the outside world. I don't know if it is possible to actually run
    Mailman in a secure way on a public server, because Mailman's security
    is based on SETGID wrappers, and I don't think SETGID actually works
    under Cygwin.

    This makes me sad, as I had high hopes, as I cannot find any real
    alternative to Mailman in the Windows world, neither free nor
    commercial. All I wanted to do was to create a small mailing list on a
    plain XP box, but it's become a week-long ordeal ending in frustration.

    I'm wide open to advice, although I suspect "Get a Linux machine" is the
    likely response :( (I do have a Linux box, but this XP box is the
    quiet, low-power always-on server machine in our office which runs our
    website with Apache wonderfully, hence that's where I must install a
    mailing list.)

    Here's how you can make it work.

    CAVEAT!! This will not be secure! (more below)
    From your previous posts, I think your web server runs in the
    Administrators group. What are you running as a mail server? I use
    Exim under Cygwin and that works well and integrates well with
    Mailman. Anyway, your mail server needs to run in the Administrators
    group too. Then you need to make your mailman user a member of the
    Administrators group, not mm, and reconfigure Mailman with
    --with-groupname, --with-cgi-gid and --with-mail-gid all equal to
    Administrators. Then reinstall with 'make install' and run
    'bin/check_perms -f' to make sure things are OK. You may need to
    change the group of your $prefix directory to Administrators before
    configure will run.

    Now everything will run in the Administrators group which will have
    permissions. The SETGID wrappers won't actually set group, but they
    will be run in the Administrators group anyway, so things will work.

    The problem is that Apache will now be able to access any Mailman files
    without going through the cgi-bin wrappers, so potentially, outside
    users can retrieve things like config.pck files that contain member
    lists and their passwords.

    You may be able to arrange the Apache config so that it is not possible
    to craft a URL that would retrieve files from Mailman directly. If so,
    you would be fairly safe, but I don't know much about this, so I don't
    know how easy or difficult this might be.

    Let us know how it works out. And if you have 'improvements' for FAQ
    5.2, please give us those too.

    --
    Mark Sapiro <msapiro at value.net> The highway is for gamblers,
    San Francisco Bay Area, California better use your sense - B. Dylan
  • Ben at Dec 22, 2005 at 10:28 pm
    Mark,

    Thanks very much for continuing to try to help..
    I tried explicitly forcing permissions with 'chmod 777
    config.pck', and that made the Admin page work. So, the
    "660" permissions are the problem, not the owner/group.
    This seems to be a widespread issue with Mailman under Cygwin -
    permission don't behave as under Unix, so Mailman chokes easily.
    Here's how you can make it work.
    From your previous posts, I think your web server runs in the
    Administrators group. What are you running as a mail server?
    I use Exim under Cygwin and that works well and integrates
    well with Mailman.
    I run exim too, and it works fine. Getting mailman to talk to exim is a
    step I haven't even gotten to yet, so far I am just trying to get
    Mailman to create a list.
    you need to make your
    mailman user a member of the Administrators group, not mm,
    and reconfigure Mailman with --with-groupname, --with-cgi-gid
    and --with-mail-gid all equal to Administrators. Then
    reinstall with 'make install' and run 'bin/check_perms -f' to
    make sure things are OK.
    I have tried this. However, I get the exact same error as before:

    admin(704): File "/usr/local/mailman/Mailman/MailList.py", line 591,
    in __load
    admin(704): fp = open(dbfile)
    admin(704): IOError: [Errno 13] Permission denied:
    '/usr/local/mailman/lists/friends/config.pck'

    I have attached the whole error log in case it helps.
    The "config.pck" file exists, and it has 660 permissions:
    -rw-rw---- 1 Ben None 3607 Dec 22 12:10 config.pck

    As before, it is the 660 permission bits, not the owner/group, which is
    causing Mailman to choke. I can't understand why Mailman's 'newlist'
    uses this permission mask to create files which Mailman will
    subsequently refuse to read.

    Any other ideas?

    Thanks,
    Ben
  • Mark Sapiro at Dec 22, 2005 at 10:55 pm

    Ben wrote:
    I have tried this. However, I get the exact same error as before:

    admin(704): File "/usr/local/mailman/Mailman/MailList.py", line 591,
    in __load
    admin(704): fp = open(dbfile)
    admin(704): IOError: [Errno 13] Permission denied:
    '/usr/local/mailman/lists/friends/config.pck'

    I have attached the whole error log in case it helps.
    I don't need it.
    The "config.pck" file exists, and it has 660 permissions:
    -rw-rw---- 1 Ben None 3607 Dec 22 12:10 config.pck

    You need to run bin/newlist as mailman or some user in the
    Administrators group, not as Ben in group None. Either that or do

    chown -R mailman:Administrators /usr/local/mailman/lists/friends

    after creating the list, or creat the list via the web create interface.
    As before, it is the 660 permission bits, not the owner/group, which is
    causing Mailman to choke. I can't understand why Mailman's 'newlist'
    uses this permission mask to create files which Mailman will
    subsequently refuse to read.
    Because it expects to be run as the mailman user. And because Mailman's
    security scheme is based on group permission and exclusion of other.

    The underlying problem here is Windows lack of support for setting
    effective user and group ids. This breaks all kinds of things that
    Mailman assumes about its environment.

    --
    Mark Sapiro <msapiro at value.net> The highway is for gamblers,
    San Francisco Bay Area, California better use your sense - B. Dylan
  • Ben at Dec 22, 2005 at 11:28 pm

    You need to run bin/newlist as mailman or some user in the
    Administrators group, not as Ben in group None.
    User 'Ben' and 'mailman' are both in the Administrators group. It is
    cygwin that decides to display "None" as the file's group owner. I
    assume this is just a limitation of Cygwin.

    On the Windows side (Manage: Users), I have users like this:
    Ben, member of Administrators
    mailman, member of Administrators

    In /etc/group, I have:
    Administrators:S-1-5-32-544:544:

    In /etc/passwd:
    Ben:unused_by_nt/2000/xp:1004:544:...
    mailman:unused_by_nt/2000/xp:1010:544:...

    So, as far as both Windows and Cygwin should be concerned, mailman _is_
    in the Administrators group.

    Next, I tried running bin/netlist as mailman, as you suggest. This
    gives the error:

    File "/usr/local/mailman/Mailman/Site.py", line 40, in _makedir
    os.makedirs(path, 02775)
    File "/usr/lib/python2.4/os.py", line 159, in makedirs
    mkdir(name, mode)
    OSError: [Errno 13] Permission denied:
    '/usr/local/mailman/lists/friends'

    Next I tried 'chown -R mailman:Administrators /usr/local/mailman/lists'
    then tried again to add the list as 'mailman', which gives a different
    error:

    File "/usr/local/mailman/Mailman/LockFile.py", line 422, in __write
    fp = open(self.__tmpfname, 'w')
    IOError: [Errno 13] Permission denied:
    '/usr/local/mailman/locks/_site_.lock.Lit
    tleGuy.4260.0'
    or create the list via the web create interface.
    Tried that too. I get an web page stating "Error: You are not
    authorized to create new mailing lists."
    As before, it is the 660 permission bits, not the
    owner/group, which is causing Mailman to choke.
    I can't understand why Mailman's 'newlist'
    uses this permission mask to create files which Mailman
    will subsequently refuse to read.
    Because it expects to be run as the mailman user.
    But, it won't be run as the 'mailman' user when it's invoked from
    Apache, so that assumption will surely fail, right?
    The underlying problem here is Windows lack of support for
    setting effective user and group ids. This breaks all kinds
    of things that Mailman assumes about its environment.
    Yes, that's clear :) The question remaining is, is there any hope of
    getting around it :(

    Thanks,
    Ben
  • Mark Sapiro at Dec 23, 2005 at 12:27 am

    Ben wrote:

    You need to run bin/newlist as mailman or some user in the
    Administrators group, not as Ben in group None.
    User 'Ben' and 'mailman' are both in the Administrators group. It is
    cygwin that decides to display "None" as the file's group owner. I
    assume this is just a limitation of Cygwin.

    Maybe it is. The point is that in order for this to work, everything
    must be in the same group that Apache is running as.

    On the Windows side (Manage: Users), I have users like this:
    Ben, member of Administrators
    mailman, member of Administrators

    In /etc/group, I have:
    Administrators:S-1-5-32-544:544:

    In /etc/passwd:
    Ben:unused_by_nt/2000/xp:1004:544:...
    mailman:unused_by_nt/2000/xp:1010:544:...

    So, as far as both Windows and Cygwin should be concerned, mailman _is_
    in the Administrators group.

    But that clearly isn't what's happening. What do you get from

    group Ben

    and

    group mailman

    If they are in more than one group, I think files they create will be
    assigned to the first group they belong to.

    Next, I tried running bin/netlist as mailman, as you suggest. This
    gives the error:

    File "/usr/local/mailman/Mailman/Site.py", line 40, in _makedir
    os.makedirs(path, 02775)
    File "/usr/lib/python2.4/os.py", line 159, in makedirs
    mkdir(name, mode)
    OSError: [Errno 13] Permission denied:
    '/usr/local/mailman/lists/friends'

    Next I tried 'chown -R mailman:Administrators /usr/local/mailman/lists'
    then tried again to add the list as 'mailman', which gives a different
    error:

    File "/usr/local/mailman/Mailman/LockFile.py", line 422, in __write
    fp = open(self.__tmpfname, 'w')
    IOError: [Errno 13] Permission denied:
    '/usr/local/mailman/locks/_site_.lock.Lit
    tleGuy.4260.0'

    So the locks/ directory doesn't have permission for user mailman and
    whatever group it runs as. See below

    or create the list via the web create interface.
    Tried that too. I get an web page stating "Error: You are not
    authorized to create new mailing lists."

    And what did you use for the password? It must be the site password or
    the list creator password set by bin/mmsitepass. If you used one of
    these, and it didn't work then it's probably permissions on
    data/adm.pw or data/creator.pw.

    As before, it is the 660 permission bits, not the
    owner/group, which is causing Mailman to choke.
    I can't understand why Mailman's 'newlist'
    uses this permission mask to create files which Mailman
    will subsequently refuse to read.
    Because it expects to be run as the mailman user.
    But, it won't be run as the 'mailman' user when it's invoked from
    Apache, so that assumption will surely fail, right?

    Well, actually it expects to be run in the mailman group which in your
    case is the Administrators group. Any files it creates have to be
    group owned by Administrators.

    The underlying problem here is Windows lack of support for
    setting effective user and group ids. This breaks all kinds
    of things that Mailman assumes about its environment.
    Yes, that's clear :) The question remaining is, is there any hope of
    getting around it :(

    Well, in my case, everything runs as user Mark and group None so
    everything is in the None group, and it works. In your case at least
    Apache is running as a service presumably in the Administrators group
    so everything has to be in the Administrators group for things to work.

    Try

    cd to the 'prefix' directory, and

    chgrp -R Administrators .

    or maybe better

    chown -R mailman:Administrators .

    Then the web stuff should work.

    BTW, did you run bin/check_perms after reconfiguring with
    --with-groupname=Administrators?

    --
    Mark Sapiro <msapiro at value.net> The highway is for gamblers,
    San Francisco Bay Area, California better use your sense - B. Dylan
  • Ben at Dec 23, 2005 at 1:01 am

    So, as far as both Windows and Cygwin should be concerned,
    mailman _is_ in the Administrators group.
    But that clearly isn't what's happening. What do you get from
    group Ben
    and
    group mailman
    I get "bash: group: command not found"
    If they are in more than one group, I think files they create
    will be assigned to the first group they belong to.
    Files they create are apparently assigned to group "None" in most cases.
    (I find that if I use "touch" to create a dummy file, it gets the right
    Group owner, but almost all other cases result in "None".)
    or create the list via the web create interface.
    Tried that too. I get an web page stating "Error: You are not
    authorized to create new mailing lists."
    And what did you use for the password? It must be the site
    password or the list creator password set by bin/mmsitepass.
    I tried everything I could think of: the passwords for 'Ben' account,
    for the 'mailman' account, for the 'Administrator' account, empty
    password, list password. No matter what I tried, it says "Error: You
    are not authorized."

    Now i tried setting mmsitepass, and giving the same value in the web
    create inteface. That got past the authorization message, and now says
    "Error: Unknown virtual host: localhost".
    But, it won't be run as the 'mailman' user when it's invoked from
    Apache, so that assumption will surely fail, right?
    Well, actually it expects to be run in the mailman group
    which in your case is the Administrators group. Any files it
    creates have to be group owned by Administrators.
    Since Cygwin regularly sets group to 'None', I think this isn't going to
    work. AFAICT there is no real "None" group, it is a pseudo-group
    created my Cygwin's "mkgroup" and "mkpasswd" commands. I had been
    getting around it by manually fixing the group IDs in the /etc/passwd
    file, to force user 'mailman' into the 'Administrators' group to match
    the reality in Windows, but apparently that is not sufficient to really
    convince Cygwin.
    Well, in my case, everything runs as user Mark and group None
    so everything is in the None group, and it works.
    Aha! Well, maybe that's the only functional workaround! I will try
    re-configure and re-install with "--with-mail-gid=None
    --with-cgi-gid=None --with-groupname=None" and see if it gets further.
    I suspect, though, that it will still create files with 660 permissions,
    which will cause other parts of the code to fail..
    Apache is running as a service presumably in
    the Administrators group so everything has to be in the
    Administrators group for things to work.
    Right, although Cygwin doesn't fully realize that the service is running
    in the Administrators group.
    BTW, did you run bin/check_perms after reconfiguring with
    --with-groupname=Administrators?
    I did, with -f so that it would fix everything up. Unfortunately it
    doesn't avoid the 660 and 'None' problems.

    If we finally get through this, I promise to make up a FAQ entry that
    really works, unlike the really wrong/outdated one in FAQ entry 5.2.

    -Ben
  • Mark Sapiro at Dec 23, 2005 at 1:28 am

    Ben wrote:

    But that clearly isn't what's happening. What do you get from
    group Ben
    and
    group mailman
    I get "bash: group: command not found"

    Sorry, that should have been groups, not group


    Now i tried setting mmsitepass, and giving the same value in the web
    create inteface. That got past the authorization message, and now says
    "Error: Unknown virtual host: localhost".

    So you either need to visit the web page using whatever your
    DEFAULT_URL_HOST is or set

    VIRTUAL_HOSTS_OVERVIEW = Off

    in mm_cfg.py.

    Since Cygwin regularly sets group to 'None', I think this isn't going to
    work. AFAICT there is no real "None" group, it is a pseudo-group
    created my Cygwin's "mkgroup" and "mkpasswd" commands. I had been
    getting around it by manually fixing the group IDs in the /etc/passwd
    file, to force user 'mailman' into the 'Administrators' group to match
    the reality in Windows, but apparently that is not sufficient to really
    convince Cygwin.


    Well, apparantly Apache runs as group Administrators, so I'm guessing
    that when Apache creates files, they will be created with group
    Administrators.

    Well, in my case, everything runs as user Mark and group None
    so everything is in the None group, and it works.
    Aha! Well, maybe that's the only functional workaround! I will try
    re-configure and re-install with "--with-mail-gid=None
    --with-cgi-gid=None --with-groupname=None" and see if it gets further.
    I suspect, though, that it will still create files with 660 permissions,
    which will cause other parts of the code to fail..
    Apache is running as a service presumably in
    the Administrators group so everything has to be in the
    Administrators group for things to work.
    Right, although Cygwin doesn't fully realize that the service is running
    in the Administrators group.

    Oh but I think it does, that's why it can't access the group None files.

    --
    Mark Sapiro <msapiro at value.net> The highway is for gamblers,
    San Francisco Bay Area, California better use your sense - B. Dylan
  • Ben at Dec 23, 2005 at 1:47 am
    Mark,
    Well, apparantly Apache runs as group Administrators, so I'm
    guessing that when Apache creates files, they will be created
    with group Administrators.
    Right. Perhaps the trouble is that Apache runs outside of Cygwin (or
    more precisely, the trouble is that Mailman runs inside it :) although
    Apache is simply executing a binary which is built and runs inside
    Cygwin, so that must not be it.

    Perhaps the only real solution here is to port (fork) Mailman from
    Cygwin to native Win32. I can't even imagine what kind of work that
    would entail. I'm have to become far more python-savvy before the end,
    no doubt.
    Apache is running as a service presumably in
    the Administrators group so everything has to be in the
    Administrators group for things to work.
    Right, although Cygwin doesn't fully realize that the service is
    running in the Administrators group.
    Oh but I think it does, that's why it can't access the group
    None files.
    I'm beginning to wonder how on earth Cygwin fakes the group id for
    files. Apparently there's nowhere to store it in Windows, so if Cygwin
    encounteres a file it didn't create, it must just guess.

    -Ben
  • Mark Sapiro at Dec 23, 2005 at 2:36 am

    Ben wrote:
    Right. Perhaps the trouble is that Apache runs outside of Cygwin (or
    more precisely, the trouble is that Mailman runs inside it :) although
    Apache is simply executing a binary which is built and runs inside
    Cygwin, so that must not be it.

    This is the first time you mentioned Apache doesn't run under Cygwin.
    I'm sure this adds a serious complication. Apache is executing Python
    under Cygwin and Cygwin is enforcing permissions on files based on
    user/group/other permissions. Mailman is designed to be run under a
    specific group and all access is based on that group. If you can make
    the mailman files all belong to the group that Cygwin sees Apache as
    (we think that's Administrators) it should work.

    So far, the problems I think you've had when you tried this are that
    when you use command line tools, files wind up in other groups, but I
    think you can get around this by either not using command line tools
    or possibly creating a user who is a member of ONLY the Administrators
    group to run them or by changing the group on files after the fact.

    Perhaps the only real solution here is to port (fork) Mailman from
    Cygwin to native Win32. I can't even imagine what kind of work that
    would entail. I'm have to become far more python-savvy before the end,
    no doubt.

    This would be difficult. Not the Python so much as the C wrappers which
    expect a Unix like environment, and you'd still have the security
    issues to deal with.

    Maybe the solution is to run Apache under Cygwin or run a mailman only
    version of Apache under Cygwin that listens on a different port.


    I'm beginning to wonder how on earth Cygwin fakes the group id for
    files. Apparently there's nowhere to store it in Windows, so if Cygwin
    encounteres a file it didn't create, it must just guess.

    I think that's right, but I don't know enough to be sure.

    --
    Mark Sapiro <msapiro at value.net> The highway is for gamblers,
    San Francisco Bay Area, California better use your sense - B. Dylan
  • Ben Discoe at Dec 23, 2005 at 7:41 am
    Hi Mark,
    Right. Perhaps the trouble is that Apache runs outside of
    Cygwin (or more precisely, the trouble is that Mailman runs
    inside it :)
    This is the first time you mentioned Apache doesn't run under
    Cygwin. I'm sure this adds a serious complication.
    Wow. I had no idea at all that it was possible to run Apache _inside_
    Cygwin. The Apache website directs Windows people to just install and
    run, so the alternate route is not well known.
    If you can make the mailman files all
    belong to the group that Cygwin sees Apache as (we
    think that's Administrators) it should work.
    Alas, experience seems to indicate that I cannot make them belong that
    way. Sometimes it's Adminstrators, but generally it's None.
    think you can get around this by either
    not using command line tools or possibly creating a user who
    is a member of ONLY the Administrators group to run them or
    by changing the group on files after the fact.
    I've tried several users (e.g. Ben) which is a member of ONLY the
    Administrators group (both in Windows and /etc/passwd), and yet it
    produces files with 660 permissions and e.g. Ben.None ownership. C'est
    la Cygwin.
    Maybe the solution is to run Apache under Cygwin or run a
    mailman only version of Apache under Cygwin that listens on a
    different port.
    Arrgh, it's hard to imagine that moving _closer_ to Cygwin is the right
    direction, when all the trouble seems to stem from Cygwin itself.

    In any case, I have found a solution of sorts! It requires giving up
    the web interface, which is unfortunate but I can live with it. It
    turns out that Exim itself is perfectly capable of processing simple
    mailing lists (http://www.exim.org/exim-html-4.10/doc/html/spec_41.html)
    including open, closed, and announcement-only lists. I basically pasted
    a few lines from that Exim documentation into my exim.conf, did some
    tweaking, and I've got several mailing lists functional!

    Someday, somebody will write a portable, open-source MLM that doesn't
    fundamentally require Unixy permissions, and ideally doesn't require
    command-line fiddling or hacks like Cygwin either. As much as I am
    drawn to the challenge, I fear it won't be me.

    I wish best of luck to y'all in the Mailman community, and thanks for
    helping out on my trip down this particular rabbit hole.

    -Ben
  • Stephen J. Turnbull at Dec 23, 2005 at 2:16 pm
    "Ben" == Ben Discoe <ben at ahualoa.net> writes:
    Ben> Wow. I had no idea at all that it was possible to run Apache
    Ben> _inside_ Cygwin. The Apache website directs Windows people
    Ben> to just install and run, so the alternate route is not well
    Ben> known.

    You might want to just take a look at the list of stuff that Cygwin's
    setup.exe supports. I imagine Apache (some version) is on the list.
    Maybe the solution is to run Apache under Cygwin or run a
    mailman only version of Apache under Cygwin that listens on a
    different port.
    Ben> Arrgh, it's hard to imagine that moving _closer_ to Cygwin is
    Ben> the right direction, when all the trouble seems to stem from
    Ben> Cygwin itself.

    No, the trouble stems from mixing different models of security and
    other OS services. While Cygwin is a big PIMA, too, there's no doubt
    in my mind that people who are using Cygwin for one app are better off
    using it for apps that cooperate with the first, too. I do know of a
    few exceptions, but they are all out-and-out bugs in the helper
    applications.


    --
    School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
    University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
    Ask not how you can "do" free software business;
    ask what your business can "do for" free software.
  • Mark Sapiro at Dec 23, 2005 at 3:08 pm

    Stephen J. Turnbull wrote:

    "Ben" == Ben Discoe <ben at ahualoa.net> writes:
    Ben> Wow. I had no idea at all that it was possible to run Apache
    Ben> _inside_ Cygwin. The Apache website directs Windows people
    Ben> to just install and run, so the alternate route is not well
    Ben> known.

    You might want to just take a look at the list of stuff that Cygwin's
    setup.exe supports. I imagine Apache (some version) is on the list.

    Absolutely. I run Cygwin Apache 1.3.29, and 1.3.33 and 2.0.54 are also
    available. As I said earlier, this is only for testing and only
    accessible locally. I don't think I'd want to run any MS-Windows
    server exposed to the world, Cygwin or native.

    Maybe the solution is to run Apache under Cygwin or run a
    mailman only version of Apache under Cygwin that listens on a
    different port.
    Ben> Arrgh, it's hard to imagine that moving _closer_ to Cygwin is
    Ben> the right direction, when all the trouble seems to stem from
    Ben> Cygwin itself.

    No, the trouble stems from mixing different models of security and
    other OS services. While Cygwin is a big PIMA, too, there's no doubt
    in my mind that people who are using Cygwin for one app are better off
    using it for apps that cooperate with the first, too. I do know of a
    few exceptions, but they are all out-and-out bugs in the helper
    applications.

    I totally agree with Stephen here.

    I'm surprised that Windows Apache can even execute the Cygwin compiled
    cgi-bin wrappers and Python at all. If I try to run a Cygwin compiled
    and linked program of any sort from a Windows command shell or even
    directly from Start->run, I get a fatal error dialog "The procedure
    entry point __getreent could not be located in the dynamic link
    library cygwin1.dll." Anyway, that part seems to work in your case,
    surprising or not.

    As Stephen says, mixing different security/protection models in one
    system is asking for trouble. Mailman is designed to run in a POSIX
    compliant or similar environment. Cygwin has its problems, but it is
    the closest thing to that environment that exists on Windows. Further,
    the only successful (albeit, perhaps limited) installations of Mailman
    on windows that we know of are under Cygwin.

    It may be possible to get Mailman to run in a Windows environment
    without Cygwin, and it may be valuable to you (Ben) and to others, but
    you're on your own in uncharted waters.

    --
    Mark Sapiro <msapiro at value.net> The highway is for gamblers,
    San Francisco Bay Area, California better use your sense - B. Dylan
  • Mark Sapiro at Dec 23, 2005 at 1:31 am

    Ben wrote:

    Well, in my case, everything runs as user Mark and group None
    so everything is in the None group, and it works.
    Aha! Well, maybe that's the only functional workaround! I will try
    re-configure and re-install with "--with-mail-gid=None
    --with-cgi-gid=None --with-groupname=None" and see if it gets further.
    I suspect, though, that it will still create files with 660 permissions,
    which will cause other parts of the code to fail..
    That's just going to put you back where you started with the wrapper
    being invoked as group Administrators and expecting group None.

    --
    Mark Sapiro <msapiro at value.net> The highway is for gamblers,
    San Francisco Bay Area, California better use your sense - B. Dylan
  • Ben at Dec 23, 2005 at 1:36 am
    Mark,
    Aha! Well, maybe that's the only functional workaround! I
    will try re-configure and re-install with
    "--with-mail-gid=None --with-cgi-gid=None
    --with-groupname=None" and see if it gets further.
    To continue the story. I tried this, and web access produced the error
    that Apache is running it from group "Administrators", not "None". So
    next, I tried:

    ./configure --with-mail-gid=None --with-cgi-gid=Administrators
    --with-groupname=None

    Not much better results. Using "addlist" does seem to succeed.
    Attempting the web interface now gives the classic:
    "We're sorry, we hit a bug! [...] the webmaster can find this
    information in the Mailman error logs."

    However, this time there is no error log; /usr/local/mailman/logs is
    empty.

    I don't know if we've exhausted all possible combinations of mail-gid,
    cgi-gid, and groupname, but it sure feels elusive.

    You mentioned that you _have_ seen it work with user 'Mark' and group
    'None'. Do you have any record of what you passed to ./configure in
    this case?

    Thanks,
    Ben
  • Mark Sapiro at Dec 23, 2005 at 2:19 am

    Ben wrote:
    You mentioned that you _have_ seen it work with user 'Mark' and group
    'None'. Do you have any record of what you passed to ./configure in
    this case?
    Yes, but it won't help you because I run Apache under Cygwin, also as
    user Mark and group None.

    This comes out of a shell script that sets $prefix earlier

    ./configure --prefix=$prefix --with-username=Mark --with-groupname=None
    --with-cgi-gid=None --with-mail-gid=None --with-mailhost=localhost
    --with-urlhost=localhost
    make install > make.log

    --
    Mark Sapiro <msapiro at value.net> The highway is for gamblers,
    San Francisco Bay Area, California better use your sense - B. Dylan
  • John Dennis at Dec 23, 2005 at 12:39 am

    Ben wrote:

    The underlying problem here is Windows lack of support for
    setting effective user and group ids. This breaks all kinds
    of things that Mailman assumes about its environment.
    Yes, that's clear :) The question remaining is, is there any hope of
    getting around it :(
    Yes, edit the file src/common.c and comment out the fatal returns in
    check_caller()

    However, you're on your own, defeating security checks, especially on
    windows, is an invitation to be a very unhappy camper someday.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupmailman-users @
categoriespython
postedDec 21, '05 at 6:26a
activeDec 23, '05 at 3:08p
posts20
users4
websitelist.org

People

Translate

site design / logo © 2021 Grokbase