FAQ
Hello,

We are using Mailman 2.1.10. For digests, how would I set which day of the
week, month, year, etc. that a digest is sent out? For example, if I choose
Weekly digest, how do I set it to send with the week starting on Wednesday? Or
if monthly, how do I choose the 15th? The options listed in the GUI aren't very
specific. What are the defaults? Is there a way to setup a digest list that
does not send out ANY digests automatically but can be
generated/started/kicked-off through a cron job?

Regards,

Alan Rubin
Technician Unix
DCS Midrange Services
Phone: +61 (08) 8999 6814
Fax: +61 (08) 8999 7493
e-Mail: alan.rubin at nt.gov.au

Search Discussions

  • Mark Sapiro at Aug 6, 2008 at 1:45 am

    Alan.Rubin at nt.gov.au wrote:
    We are using Mailman 2.1.10. For digests, how would I set which day of the
    week, month, year, etc. that a digest is sent out? For example, if I choose
    Weekly digest, how do I set it to send with the week starting on Wednesday? Or
    if monthly, how do I choose the 15th? The options listed in the GUI aren't very
    specific. What are the defaults?

    You misunderstand what those settings are for. They have nothing to do
    with when digests are sent. Wach digest has a volume number and an
    issue number. The issue number increments with each digest. The
    digest_volume_frequency setting controls how often the issue number
    resets to 1 and the volume number increments instead.

    The things that control when digests are sent are first of all,
    digest_size_threshhold. When the size of the mailbox file holding the
    messages accummulated for the digest reaches that size, a digest will
    be produced immediately regardless of when that is. The digest itself
    may be a little smaller (or bigger if the triggering post was large)
    due to removal of some headers and scrubbing of attachments.

    In addition, if digest_send_periodic is set to Yes, the periodic
    cron/senddigests will send a digest when it runs if there are any
    messages for the digest at that time. Mailman's default crontab runs
    cron/senddigests daily at noon local time.

    Is there a way to setup a digest list that
    does not send out ANY digests automatically but can be
    generated/started/kicked-off through a cron job?

    That is effectively what happens if you set digest_size_threshhold
    large enough so that you never trigger a digest on size before
    cron/senddigests runs.

    --
    Mark Sapiro <mark at msapiro.net> The highway is for gamblers,
    San Francisco Bay Area, California better use your sense - B. Dylan
  • Alan Rubin at Aug 6, 2008 at 2:11 am
    Mark,

    Thanks for your answer. It is very enlightening.

    This is a bit of a tangent, but also has to do with 'interpretation' of
    Mailman's configuration. If you read/work with the list configuration from the
    command line, using ~mailman/bin/config_list, you will see many descriptions
    that say something such as:

    # legal values are:
    # 0 = "No"
    # 1 = "Yes"

    But then the current/default value will be listed as True or False, literally.
    Which is it? Are both 0/False and 1/True acceptable?

    Regards,

    Alan Rubin
    Technician Unix
    DCS Midrange Services
    Phone: +61 (08) 8999 6814
    Fax: +61 (08) 8999 7493
    e-Mail: alan.rubin at nt.gov.au



    Mark Sapiro
    <mark at msapiro.net>
    To
    06/08/2008 11:15 AM Alan.Rubin at nt.gov.au,
    mailman-users at python.org
    cc

    Subject
    Re: [Mailman-Users] Digest options










    Alan.Rubin at nt.gov.au wrote:
    We are using Mailman 2.1.10. For digests, how would I set which day of the
    week, month, year, etc. that a digest is sent out? For example, if I choose
    Weekly digest, how do I set it to send with the week starting on Wednesday? Or
    if monthly, how do I choose the 15th? The options listed in the GUI aren't very
    specific. What are the defaults?

    You misunderstand what those settings are for. They have nothing to do
    with when digests are sent. Wach digest has a volume number and an
    issue number. The issue number increments with each digest. The
    digest_volume_frequency setting controls how often the issue number
    resets to 1 and the volume number increments instead.

    The things that control when digests are sent are first of all,
    digest_size_threshhold. When the size of the mailbox file holding the
    messages accummulated for the digest reaches that size, a digest will
    be produced immediately regardless of when that is. The digest itself
    may be a little smaller (or bigger if the triggering post was large)
    due to removal of some headers and scrubbing of attachments.

    In addition, if digest_send_periodic is set to Yes, the periodic
    cron/senddigests will send a digest when it runs if there are any
    messages for the digest at that time. Mailman's default crontab runs
    cron/senddigests daily at noon local time.

    Is there a way to setup a digest list that
    does not send out ANY digests automatically but can be
    generated/started/kicked-off through a cron job?

    That is effectively what happens if you set digest_size_threshhold
    large enough so that you never trigger a digest on size before
    cron/senddigests runs.

    --
    Mark Sapiro <mark at msapiro.net> The highway is for gamblers,
    San Francisco Bay Area, California better use your sense - B. Dylan
  • Mark Sapiro at Aug 6, 2008 at 2:58 am

    Alan.Rubin at nt.gov.au wrote:
    Thanks for your answer. It is very enlightening.

    This is a bit of a tangent, but also has to do with 'interpretation' of
    Mailman's configuration. If you read/work with the list configuration from the
    command line, using ~mailman/bin/config_list, you will see many descriptions
    that say something such as:

    # legal values are:
    # 0 = "No"
    # 1 = "Yes"

    But then the current/default value will be listed as True or False, literally.
    Which is it? Are both 0/False and 1/True acceptable?

    Yes they are. At least assuming your Python is 2.3 or later, and
    assuming the attribute is one with only "Yes" or "No" possibilities.
    Prior to 2.3 there were no built-in constants True and False. Since
    Mailman through 2.1.8 was compatible with Python back to 2.1, we used
    0 and 1 instead of False and True as values or we used a kludge like

    try:
    True, False
    except NameError:
    True = 1
    False = 0

    to define True and False if they weren't built in. Eventually, Mailman
    will move to using True and False everywhere to represent truth value
    constants, but even then, some old lists will still have 1 or 0 as the
    value of some list attributes just because they were set that way at
    one time and never changed.

    However, all the above has to do with the actual attribute value shown
    by config_list -o or set by config_list -i.

    In the actual text

    # legal values are:
    # 0 = "No"
    # 1 = "Yes"

    the 0 and 1 are the index of the radio button in the GUI for that
    attribute

    in the same way as, e.g.

    # legal values are:
    # 0 = "Accept"
    # 1 = "Hold"
    # 2 = "Reject"
    # 3 = "Discard"

    are the possible settings for generic_nonmember_action and

    # legal values are:
    # 0 = "No"
    # 1 = "Yes"
    # 2 = "Full Personalization"

    are the possible settings for personalize.

    The bottom line is if you see a setting reported as True or False, it's
    OK to set it to False or True with config_list, but if the setting is
    reported as 0 or 1, you can't be sure that the code doesn't somewhere
    treat it as a number, so it is best to set it to a number.

    --
    Mark Sapiro <mark at msapiro.net> The highway is for gamblers,
    San Francisco Bay Area, California better use your sense - B. Dylan
  • Alan Rubin at Aug 6, 2008 at 4:29 am
    Mark,

    Back to Digests...

    If these lines occur in mailman's crontab -

    # Noon, mail digests for lists that do periodic as well as threshhold delivery.
    0 12 * * * /opt/csw/bin/python -S /export/home/mailman/cron/senddigests

    how will lists with digests enabled be affected? If the list has a high
    threshold, will it still have the contents of its digest sent? Do options in
    the configuration take precedence over the script? If the intention is to
    schedule sending of digests from cron for a particular list on specific days
    only, will the script send the digest regardless of the threshold? And, if you
    disable the cronjob above, how will that affect any other lists on the mail
    server where users arbitrarily choose to receive digests and list owners allow
    this?

    Thanks for your help,

    Alan Rubin
    Technician Unix
    DCS Midrange Services
    Phone: +61 (08) 8999 6814
    Fax: +61 (08) 8999 7493
    e-Mail: alan.rubin at nt.gov.au



    Mark Sapiro
    <mark at msapiro.net>
    To
    06/08/2008 12:28 PM Alan.Rubin at nt.gov.au,
    mailman-users at python.org
    cc

    Subject
    Re: [Mailman-Users] Digest options ->
    list configuration










    Alan.Rubin at nt.gov.au wrote:
    Thanks for your answer. It is very enlightening.

    This is a bit of a tangent, but also has to do with 'interpretation' of
    Mailman's configuration. If you read/work with the list configuration from the
    command line, using ~mailman/bin/config_list, you will see many descriptions
    that say something such as:

    # legal values are:
    # 0 = "No"
    # 1 = "Yes"

    But then the current/default value will be listed as True or False, literally.
    Which is it? Are both 0/False and 1/True acceptable?

    Yes they are. At least assuming your Python is 2.3 or later, and
    assuming the attribute is one with only "Yes" or "No" possibilities.
    Prior to 2.3 there were no built-in constants True and False. Since
    Mailman through 2.1.8 was compatible with Python back to 2.1, we used
    0 and 1 instead of False and True as values or we used a kludge like

    try:
    True, False
    except NameError:
    True = 1
    False = 0

    to define True and False if they weren't built in. Eventually, Mailman
    will move to using True and False everywhere to represent truth value
    constants, but even then, some old lists will still have 1 or 0 as the
    value of some list attributes just because they were set that way at
    one time and never changed.

    However, all the above has to do with the actual attribute value shown
    by config_list -o or set by config_list -i.

    In the actual text

    # legal values are:
    # 0 = "No"
    # 1 = "Yes"

    the 0 and 1 are the index of the radio button in the GUI for that
    attribute

    in the same way as, e.g.

    # legal values are:
    # 0 = "Accept"
    # 1 = "Hold"
    # 2 = "Reject"
    # 3 = "Discard"

    are the possible settings for generic_nonmember_action and

    # legal values are:
    # 0 = "No"
    # 1 = "Yes"
    # 2 = "Full Personalization"

    are the possible settings for personalize.

    The bottom line is if you see a setting reported as True or False, it's
    OK to set it to False or True with config_list, but if the setting is
    reported as 0 or 1, you can't be sure that the code doesn't somewhere
    treat it as a number, so it is best to set it to a number.

    --
    Mark Sapiro <mark at msapiro.net> The highway is for gamblers,
    San Francisco Bay Area, California better use your sense - B. Dylan
  • Mark Sapiro at Aug 6, 2008 at 2:48 pm

    Alan.Rubin at nt.gov.au wrote:
    If these lines occur in mailman's crontab -

    # Noon, mail digests for lists that do periodic as well as threshhold delivery.
    0 12 * * * /opt/csw/bin/python -S /export/home/mailman/cron/senddigests

    how will lists with digests enabled be affected? If the list has a high
    threshold, will it still have the contents of its digest sent?

    If digest_send_periodic is Yes, and the list has had at least one post
    since the last digest, a digest will be sent when cron/senddigests
    runs.

    Do options in
    the configuration take precedence over the script?

    The only configuration option that affects cron/senddigests is
    digest_send_periodic which controls whether or not cron/senddigests
    will send a digest for this list.

    If the intention is to
    schedule sending of digests from cron for a particular list on specific days
    only, will the script send the digest regardless of the threshold?

    Yes

    And, if you
    disable the cronjob above, how will that affect any other lists on the mail
    server where users arbitrarily choose to receive digests and list owners allow
    this?

    If you disable cron/senddigests, no periodic digests will be sent for
    any list. If you change the schedule, it will affect all lists.

    You can run cron/senddigests for specific lists with a "-l listname"
    option (run 'cron/senddigests -h' for info) so you could set up your
    crontab to run 'cron/senddigests -l list1' on one schedule and
    'cron/senddigests -l list2' on another, but the problem is there's no
    "all lists except ..." option, so it becomes cumbersome.

    --
    Mark Sapiro <mark at msapiro.net> The highway is for gamblers,
    San Francisco Bay Area, California better use your sense - B. Dylan
  • Alan Rubin at Aug 6, 2008 at 10:40 pm
    Mark/All,

    So, if digest_send_periodic is No (so that digests are not sent every day as
    indicated by the default senddigests cron entry), senddigests will not force the
    list to send a new digest even with the -l option? If you host many lists and
    one list/customer wants messages sent only on a specific schedule, and you don't
    want to degrade the ability for the entire list server, then the only real
    option is to cook up some recipe which keeps mail intended for the list in a
    separate queue and only gets added to the list at the time that you want a
    digest created and sent?

    To be more specific about my scenario, we are attempting to migrate from
    Majordomo to Mailman. We have a list that sends out change control
    notifications on a twice weekly basis. In the majordomo configuration,
    individual messages are collected in a work folder and when a Perl script called
    'digests', written for majordomo, is run from cron, the messages in the work
    folder are gathered into a single digest message and sent to the list
    subscribers.

    Perhaps I am taking the wrong approach with Mailman? Is there another way to
    deliver a similar service without cooking up my own scheme, or has someone
    already contributed such a tool/scheme?

    Regards,

    Alan Rubin
    Technician Unix
    DCS Midrange Services
    Phone: +61 (08) 8999 6814
    Fax: +61 (08) 8999 7493
    e-Mail: alan.rubin at nt.gov.au



    Mark Sapiro
    <mark at msapiro.net>
    To
    07/08/2008 12:18 AM Alan.Rubin at nt.gov.au,
    mailman-users at python.org
    cc

    Subject
    Re: [Mailman-Users] Digest options ->
    list configuration










    Alan.Rubin at nt.gov.au wrote:
    If these lines occur in mailman's crontab -

    # Noon, mail digests for lists that do periodic as well as threshhold delivery.
    0 12 * * * /opt/csw/bin/python -S /export/home/mailman/cron/senddigests

    how will lists with digests enabled be affected? If the list has a high
    threshold, will it still have the contents of its digest sent?

    If digest_send_periodic is Yes, and the list has had at least one post
    since the last digest, a digest will be sent when cron/senddigests
    runs.

    Do options in
    the configuration take precedence over the script?

    The only configuration option that affects cron/senddigests is
    digest_send_periodic which controls whether or not cron/senddigests
    will send a digest for this list.

    If the intention is to
    schedule sending of digests from cron for a particular list on specific days
    only, will the script send the digest regardless of the threshold?

    Yes

    And, if you
    disable the cronjob above, how will that affect any other lists on the mail
    server where users arbitrarily choose to receive digests and list owners allow
    this?

    If you disable cron/senddigests, no periodic digests will be sent for
    any list. If you change the schedule, it will affect all lists.

    You can run cron/senddigests for specific lists with a "-l listname"
    option (run 'cron/senddigests -h' for info) so you could set up your
    crontab to run 'cron/senddigests -l list1' on one schedule and
    'cron/senddigests -l list2' on another, but the problem is there's no
    "all lists except ..." option, so it becomes cumbersome.

    --
    Mark Sapiro <mark at msapiro.net> The highway is for gamblers,
    San Francisco Bay Area, California better use your sense - B. Dylan
  • Mark Sapiro at Aug 6, 2008 at 11:43 pm

    Alan.Rubin at nt.gov.au wrote:
    So, if digest_send_periodic is No (so that digests are not sent every day as
    indicated by the default senddigests cron entry), senddigests will not force the
    list to send a new digest even with the -l option?

    Correct.

    If you host many lists and
    one list/customer wants messages sent only on a specific schedule, and you don't
    want to degrade the ability for the entire list server, then the only real
    option is to cook up some recipe which keeps mail intended for the list in a
    separate queue and only gets added to the list at the time that you want a
    digest created and sent?

    There are other ways to address this. See below.

    To be more specific about my scenario, we are attempting to migrate from
    Majordomo to Mailman. We have a list that sends out change control
    notifications on a twice weekly basis. In the majordomo configuration,
    individual messages are collected in a work folder and when a Perl script called
    'digests', written for majordomo, is run from cron, the messages in the work
    folder are gathered into a single digest message and sent to the list
    subscribers.

    Perhaps I am taking the wrong approach with Mailman? Is there another way to
    deliver a similar service without cooking up my own scheme, or has someone
    already contributed such a tool/scheme?

    Here are a couple of possible approaches.

    First the kludgy approach.

    Set the crontab to run a script instead of cron/senddigests.

    The script would be something like (warning! may have syntax errors)

    #!/bin/sh
    prefix=/path/to/mailman
    special=the_special_listname
    for list in `$prefix/bin/list_lists --bare`; do
    if [[ $list != $special ]] ; then
    $prefix/cron/senddigests -l $list
    fi
    done

    Then have a separate crontab entry to run
    cron/senddigests -l the_special_listname

    The more elegant IMO approach.

    Set the list in question digest_send_periodic = No

    Copy cron/senddigests to cron/senddigests2 or whatever name you like
    and make sure the copy is chmod +x

    Change line 85 in the copy from

    if mlist.digest_send_periodic:

    to

    if True:

    Then add a separate crontab entry to run
    cron/senddigests2 -l the_special_listname

    --
    Mark Sapiro <mark at msapiro.net> The highway is for gamblers,
    San Francisco Bay Area, California better use your sense - B. Dylan
  • Alan Rubin at Aug 7, 2008 at 1:40 am
    Mark,

    I chose option two, but it didn't seem to work. I am not a python programmer.
    Is there a general switch to turn on simple debugging (a la -x in sh scripting).

    I ran this:

    su mailman -c "/opt/csw/bin/python -S /export/home/mailman/cron/senddigests_mod
    -l change_notification"

    and I got no errors or log messages that I can find, but the digest.mbox is
    still full and I never received a digest in my mailbox.

    Here is the edit to the copy, senddigests_mod:

    for listname in listnames:
    mlist = MailList.MailList(listname, lock=0)
    #if mlist.digest_send_periodic:
    if True:
    mlist.Lock()
    try:
    try:
    mlist.send_digest_now()
    mlist.Save()
    # We are unable to predict what exception may occur in digest
    # processing and we don't want to lose the other digests, so
    # we catch everything.
    except Exception, errmsg:
    print >> sys.stderr, \
    'List: %s: problem processing %s:\n%s' % \
    (listname,
    os.path.join(mlist.fullpath(), 'digest.mbox'),
    errmsg)
    finally:
    mlist.Unlock()

    The executable bit is set and the permission is the same as the original. It is
    owned by root with the executable bit set for all and in the group mailman.
    Perhaps it needs to be owned by root as well? The original cronjob was set in
    mailman's crontab.

    The list is also set correctly:
    ~mailman/bin/config_list -o - change_notification
    <snip>
    # Should a digest be dispatched daily when the size threshold isn't
    # reached?
    #
    # legal values are:
    # 0 = "No"
    # 1 = "Yes"
    digest_send_periodic = 0
    <snip>

    Regards,

    Alan Rubin
    Technician Unix
    DCS Midrange Services
    Phone: +61 (08) 8999 6814
    Fax: +61 (08) 8999 7493
    e-Mail: alan.rubin at nt.gov.au




    Mark Sapiro
    <mark at msapiro.net>
    To
    07/08/2008 09:13 AM Alan.Rubin at nt.gov.au,
    mailman-users at python.org
    cc

    Subject
    Re: [Mailman-Users] Digest options ->
    list configuration










    Alan.Rubin at nt.gov.au wrote:
    So, if digest_send_periodic is No (so that digests are not sent every day as
    indicated by the default senddigests cron entry), senddigests will not force the
    list to send a new digest even with the -l option?

    Correct.

    If you host many lists and
    one list/customer wants messages sent only on a specific schedule, and you don't
    want to degrade the ability for the entire list server, then the only real
    option is to cook up some recipe which keeps mail intended for the list in a
    separate queue and only gets added to the list at the time that you want a
    digest created and sent?

    There are other ways to address this. See below.

    To be more specific about my scenario, we are attempting to migrate from
    Majordomo to Mailman. We have a list that sends out change control
    notifications on a twice weekly basis. In the majordomo configuration,
    individual messages are collected in a work folder and when a Perl script called
    'digests', written for majordomo, is run from cron, the messages in the work
    folder are gathered into a single digest message and sent to the list
    subscribers.

    Perhaps I am taking the wrong approach with Mailman? Is there another way to
    deliver a similar service without cooking up my own scheme, or has someone
    already contributed such a tool/scheme?

    Here are a couple of possible approaches.

    First the kludgy approach.

    Set the crontab to run a script instead of cron/senddigests.

    The script would be something like (warning! may have syntax errors)

    #!/bin/sh
    prefix=/path/to/mailman
    special=the_special_listname
    for list in `$prefix/bin/list_lists --bare`; do
    if [[ $list != $special ]] ; then
    $prefix/cron/senddigests -l $list
    fi
    done

    Then have a separate crontab entry to run
    cron/senddigests -l the_special_listname

    The more elegant IMO approach.

    Set the list in question digest_send_periodic = No

    Copy cron/senddigests to cron/senddigests2 or whatever name you like
    and make sure the copy is chmod +x

    Change line 85 in the copy from

    if mlist.digest_send_periodic:

    to

    if True:

    Then add a separate crontab entry to run
    cron/senddigests2 -l the_special_listname

    --
    Mark Sapiro <mark at msapiro.net> The highway is for gamblers,
    San Francisco Bay Area, California better use your sense - B. Dylan
  • Mark Sapiro at Aug 7, 2008 at 2:49 am

    Alan.Rubin at nt.gov.au wrote:
    I chose option two, but it didn't seem to work. I am not a python programmer.
    Is there a general switch to turn on simple debugging (a la -x in sh scripting).

    No.

    I ran this:

    su mailman -c "/opt/csw/bin/python -S /export/home/mailman/cron/senddigests_mod
    -l change_notification"

    and I got no errors or log messages that I can find, but the digest.mbox is
    still full and I never received a digest in my mailbox.

    Had it actually worked, lists/change_notification/digest.mbox would
    have been removed.

    I can't begin to guess what was wrong. You seem to have done everything
    right. If there were some problem, there should have been something
    written to your terminal/console.

    Here is the edit to the copy, senddigests_mod:

    for listname in listnames:
    mlist = MailList.MailList(listname, lock=0)
    #if mlist.digest_send_periodic:
    if True:
    mlist.Lock()
    try:
    try:
    mlist.send_digest_now()
    mlist.Save()
    # We are unable to predict what exception may occur in digest
    # processing and we don't want to lose the other digests, so
    # we catch everything.
    except Exception, errmsg:
    print >> sys.stderr, \
    'List: %s: problem processing %s:\n%s' % \
    (listname,
    os.path.join(mlist.fullpath(), 'digest.mbox'),
    errmsg)
    finally:
    mlist.Unlock()

    The executable bit is set and the permission is the same as the original. It is
    owned by root with the executable bit set for all and in the group mailman.
    Perhaps it needs to be owned by root as well? The original cronjob was set in
    mailman's crontab.

    It needs to actually run as group mailman, and if you run it as you
    did, the execute bit is not needed. Everything looks fine for running
    it as you did, and if the permissions weren't adequate, you would have
    gotten an error.

    The list is also set correctly:
    ~mailman/bin/config_list -o - change_notification
    <snip>
    # Should a digest be dispatched daily when the size threshold isn't
    # reached?
    #
    # legal values are:
    # 0 = "No"
    # 1 = "Yes"
    digest_send_periodic = 0

    This shouldn't matter for senddigests_mod at all. It only affects
    whether the normal senddigests will send a digest for this list, which
    it won't with the above setting.

    You could try adding a print so

    if True:
    mlist.Lock()
    try:

    becomes

    if True:
    print 'Processing' + listname
    mlist.Lock()
    try:

    just to be sure it's getting there. It should print

    Processing change_notification

    when you run it.

    --
    Mark Sapiro <mark at msapiro.net> The highway is for gamblers,
    San Francisco Bay Area, California better use your sense - B. Dylan
  • Alan Rubin at Aug 7, 2008 at 4:22 am
    Mark,

    I put in the print line and there was no output when I ran the script. And no
    success either.

    Regards,

    Alan Rubin
    Technician Unix
    DCS Midrange Services
    Phone: +61 (08) 8999 6814
    Fax: +61 (08) 8999 7493
    e-Mail: alan.rubin at nt.gov.au



    Mark Sapiro
    <mark at msapiro.net>
    Sent by: To
    mailman-users-bounc Alan.Rubin at nt.gov.au,
    es+alan.rubin=nt.go mailman-users at python.org
    v.au at python.org cc

    Subject
    07/08/2008 12:19 PM Re: [Mailman-Users] Digest options ->
    list configuration










    Alan.Rubin at nt.gov.au wrote:
    I chose option two, but it didn't seem to work. I am not a python programmer.
    Is there a general switch to turn on simple debugging (a la -x in sh
    scripting).


    No.

    I ran this:

    su mailman -c "/opt/csw/bin/python -S /export/home/mailman/cron/senddigests_mod
    -l change_notification"

    and I got no errors or log messages that I can find, but the digest.mbox is
    still full and I never received a digest in my mailbox.

    Had it actually worked, lists/change_notification/digest.mbox would
    have been removed.

    I can't begin to guess what was wrong. You seem to have done everything
    right. If there were some problem, there should have been something
    written to your terminal/console.

    Here is the edit to the copy, senddigests_mod:

    for listname in listnames:
    mlist = MailList.MailList(listname, lock=0)
    #if mlist.digest_send_periodic:
    if True:
    mlist.Lock()
    try:
    try:
    mlist.send_digest_now()
    mlist.Save()
    # We are unable to predict what exception may occur in digest
    # processing and we don't want to lose the other digests, so
    # we catch everything.
    except Exception, errmsg:
    print >> sys.stderr, \
    'List: %s: problem processing %s:\n%s' % \
    (listname,
    os.path.join(mlist.fullpath(), 'digest.mbox'),
    errmsg)
    finally:
    mlist.Unlock()

    The executable bit is set and the permission is the same as the original. It is
    owned by root with the executable bit set for all and in the group mailman.
    Perhaps it needs to be owned by root as well? The original cronjob was set in
    mailman's crontab.

    It needs to actually run as group mailman, and if you run it as you
    did, the execute bit is not needed. Everything looks fine for running
    it as you did, and if the permissions weren't adequate, you would have
    gotten an error.

    The list is also set correctly:
    ~mailman/bin/config_list -o - change_notification
    <snip>
    # Should a digest be dispatched daily when the size threshold isn't
    # reached?
    #
    # legal values are:
    # 0 = "No"
    # 1 = "Yes"
    digest_send_periodic = 0

    This shouldn't matter for senddigests_mod at all. It only affects
    whether the normal senddigests will send a digest for this list, which
    it won't with the above setting.

    You could try adding a print so

    if True:
    mlist.Lock()
    try:

    becomes

    if True:
    print 'Processing' + listname
    mlist.Lock()
    try:

    just to be sure it's getting there. It should print

    Processing change_notification

    when you run it.

    --
    Mark Sapiro <mark at msapiro.net> The highway is for gamblers,
    San Francisco Bay Area, California better use your sense - B. Dylan

    ------------------------------------------------------
    Mailman-Users mailing list
    Mailman-Users at python.org
    http://mail.python.org/mailman/listinfo/mailman-users
    Mailman FAQ: http://wiki.list.org/x/AgA3
    Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
    Unsubscribe:
    http://mail.python.org/mailman/options/mailman-users/alan.rubin%40nt.gov.au

    Security Policy: http://wiki.list.org/x/QIA9
  • Mark Sapiro at Aug 8, 2008 at 1:50 am

    Alan.Rubin at nt.gov.au wrote:

    I put in the print line and there was no output when I ran the
    script. And no success either.

    After some off list back and forth, Alan determined that the problem was
    that the mailman user had /bin/false as a login shell. Once that was
    changed, the script worked as expected.

    --
    Mark Sapiro <mark at msapiro.net> The highway is for gamblers,
    San Francisco Bay Area, California better use your sense - B. Dylan
  • Brad Knowles at Aug 8, 2008 at 4:48 am

    On 8/7/08, Mark Sapiro wrote:

    After some off list back and forth, Alan determined that the problem was
    that the mailman user had /bin/false as a login shell. Once that was
    changed, the script worked as expected.
    Was this on a Solaris box? I've had problems with them lately not
    allowing cron jobs to run under a specific userid, even if they were
    in the /etc/cron.allow list, unless the user had a valid password
    hash and a valid shell.

    One of the more screwed-up things I've seen from a Solaris box
    lately, I tell you....

    --
    Brad Knowles <brad at shub-internet.org>
    LinkedIn Profile: <http://tinyurl.com/y8kpxu>
  • Mark Sapiro at Aug 8, 2008 at 2:30 pm

    Brad Knowles wrote:
    On 8/7/08, Mark Sapiro wrote:

    After some off list back and forth, Alan determined that the problem was
    that the mailman user had /bin/false as a login shell. Once that was
    changed, the script worked as expected.
    Was this on a Solaris box? I've had problems with them lately not
    allowing cron jobs to run under a specific userid, even if they were
    in the /etc/cron.allow list, unless the user had a valid password
    hash and a valid shell.

    No, I don't think this was Solaris, but the problem is that bin/false
    is a 'valid' shell except that all it does is return an error without
    running any commands.

    So when the user tested with

    su mailman -c "path_to_python -S path_to_script args"

    or

    su mailman -c "path_to_script args"

    su passed the command to bin/false which happily exited with a failure
    status that the user never saw and the command was never run.

    Also, after the fact, he discovered entries in the cron log indicating
    mailman's crons were failing, but this was a new installation, and he
    hadn't yet noticed the symptoms of this.

    --
    Mark Sapiro <mark at msapiro.net> The highway is for gamblers,
    San Francisco Bay Area, California better use your sense - B. Dylan
  • Hank van Cleef at Aug 8, 2008 at 3:59 pm
    The esteemed Brad Knowles has said:
    On 8/7/08, Mark Sapiro wrote:

    After some off list back and forth, Alan determined that the problem was
    that the mailman user had /bin/false as a login shell. Once that was
    changed, the script worked as expected.
    Was this on a Solaris box? I've had problems with them lately not
    allowing cron jobs to run under a specific userid, even if they were
    in the /etc/cron.allow list, unless the user had a valid password
    hash and a valid shell.

    One of the more screwed-up things I've seen from a Solaris box
    lately, I tell you....
    Nothing particularly "screwed up" about Solaris as a platform for
    mailman. When setting up the mailman account, set up the account as a
    normal account, then use vipw to edit /etc/passwd and /etc/shadow.
    Just delete specification of any shell from the passwd line.

    Shadow line should look like:
    mailman:NP:::::::

    The letters "NP" in the password hash field are important. But there
    are already plenty of examples in the file for you to follow.

    When setting up the crontab, and changing it, su from root to mailman,
    and follow the Solaris instructions. They are in the man pages.

    You don't need to fuss with cron.allow and cron.deny to get cron to
    process the mailman crontab.

    Just because:
    Solaris isn't Linux, and sendmail isn't Postfix, isn't a reason to
    call either one of them "screwed up." The Mailman build-install
    instructions work just fine on Solaris/sendmail, if you pay attention
    to doing things the Solaris way, and treat Mailman as "just another
    sendmail user" on an existing and functioning sendmail installation.

    julie:vancleef:$ uptime
    9:54am up 194 day(s), 17:24, 3 users, load average: 0.00, 0.01,
    0.02

    It would be longer than that if we hadn't had a power outage shutown
    last winter.

    Hank
  • Brad Knowles at Aug 8, 2008 at 6:22 pm

    Hank van Cleef wrote:

    Just because:
    Solaris isn't Linux, and sendmail isn't Postfix, isn't a reason to
    call either one of them "screwed up."
    You picked a really bad analogy to make with me.


    I've been administering Suns for almost twenty years, since the SunOS 4.0.2
    days. I still vividly remember the dreckage and bletchery that was called
    Solaris when 2.0 was shipped. Back in the day, 2.5.1 was the first version
    that was even minimally acceptable, although it has long since been
    overtaken by events. I've got four Ultra 10 clones sitting in a room at a
    storage facility, because I haven't had space for them since my wife and I
    moved back to the US in 2006.

    Likewise, I was the Sendmail FAQ maintainer in 1995, and I was materially
    involved in the very early days of what was originally called IBM VMailer in
    1998, back before Wietse decided to rename it "postfix" and make the
    official launch at the SANE'98 conference where he and I spoke back-to-back
    on the same stage. There are a number of features in each program that I
    can proudly claim that I was the first to strongly advocate them, or I was
    the first to report their malfunctioning. You can check the source code if
    you don't believe me. Just search for my name.

    I've been administering Linux since the kernel 2.0.x days, and of all of the
    above mentioned subjects, it's actually the thing I know the least about.


    Just because you think you hear me saying things that you've heard from
    other people who have been making snap judgements without adequate
    information, is not necessarily a valid reason to assume that I'm actually
    doing the same.

    You admonish me to do my homework on the OSes or MTAs in question before I
    pass judgement, and I admonish you to do your homework before you pass
    judgement on me without adequate information.


    When I say that Solaris is screwed-up, I have two decades of experience that
    tells me that it is actually, really, honestly, well and truly screwed-up.
    At least with regards to this particular area. They may have made
    improvements in lots of other areas, but this is one area where they have
    gone way backwards.
    julie:vancleef:$ uptime
    9:54am up 194 day(s), 17:24, 3 users, load average: 0.00, 0.01,
    0.02
    And I've had machines with an uptime over 1000 days. Big deal.

    --
    Brad Knowles <brad at shub-internet.org>
    LinkedIn Profile: <http://tinyurl.com/y8kpxu>

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupmailman-users @
categoriespython
postedAug 6, '08 at 1:16a
activeAug 8, '08 at 6:22p
posts16
users4
websitelist.org

People

Translate

site design / logo © 2022 Grokbase