RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 786822 - VAR_PREFIX problem
Summary: VAR_PREFIX problem
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: mailman
Version: 6.2
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: rc
: ---
Assignee: Jan Kaluža
QA Contact: qe-baseos-daemons
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-02-02 13:56 UTC by Zenon Panoussis
Modified: 2012-02-06 08:21 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-02-06 08:21:46 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Zenon Panoussis 2012-02-02 13:56:41 UTC 
When I updated to mailman-2.1.12-17.el6.x86_64, all my lists disappeared. The first symptom was "Starting mailman: Site list is missing: mailman" while restarting after the update. 

Defaults.py: VAR_PREFIX      = '/var/lib/mailman'
mm_cfg.py:   VAR_PREFIX      = '/vol/lib/mailman'

This was so both before and after the update. The list directories in /vol/lib/mailman still existed after the update, while /var/lib/mailman was empty. 

Running 'newlist mailman' created the list in /var/lib/mailman. Clearly, VAR_PREFIX was not being obeyed. I proceeded to delete mm_cfg.pyc and mm_cfg.pyo and restart mailman. The .pyc file was recompiled, but this did not fix the problem. The .pyo file was not re-created. 

Subsequently I edited VAR_PREFIX in Defaults.py and restarted mailman. This fixed the problem and all the lists are back. 

Obviously, something somewhere that should be reading VAR_PREFIX from mm_cfg isn't doing so. Interestingly though, the other non-default settings in mm_cfg are obeyed. Ownerships and permissions are good and selinux is off.

I tried to find the real cause of the problem, but have failed so far.
Comment 2 Zenon Panoussis 2012-02-02 14:24:48 UTC 
Aha, found it. Defaults.py actually says 

# Nothing below here is user configurable.  Most of these values are in this
# file for internal system convenience.  Don't change any of them or override
# any of them in your mm_cfg.py file!

just before VAR_PREFIX is set. So I have to assume that I had previously edited Defaults.py and that the file was overwritten by the update. As it should be. Hence, this is not a bug but a feature request: VAR_PREFIX should be configurable. Closing here and filing upstream instead.
Comment 3 Zenon Panoussis 2012-02-02 20:55:36 UTC 
This is now tracked at https://bugs.launchpad.net/mailman/+bug/925502 . 

Mark Sapiro left a solution/instruction there, which I'm copying here for the next man's convenience: 

==
VAR_PREFIX is configurable in mm_cfg.py. The problem is that 22 other
directories/files are defined directly or indirectly in Defaults.py
following the definition of VAR_PREFIX. mm_cfg.py imports everything
from Defaults and then allows you to override any of the imported
values. Simply changing VAR_PREFIX in mm_cfg.py doesn't change the
definitions of these other 22 variables already defined in Defaults.py.

If you redefine VAR_PREFIX in mm_cfg .py, you need to copy all the
dependent  definitions after that as follows:

VAR_PREFIX = 'new/value'

LIST_DATA_DIR   = os.path.join(VAR_PREFIX, 'lists')
LOG_DIR         = os.path.join(VAR_PREFIX, 'logs')
LOCK_DIR        = os.path.join(VAR_PREFIX, 'locks')
DATA_DIR        = os.path.join(VAR_PREFIX, 'data')
SPAM_DIR        = os.path.join(VAR_PREFIX, 'spam')

PUBLIC_ARCHIVE_FILE_DIR  = os.path.join(VAR_PREFIX, 'archives', 'public')
PRIVATE_ARCHIVE_FILE_DIR = os.path.join(VAR_PREFIX, 'archives', 'private')

QUEUE_DIR       = os.path.join(VAR_PREFIX, 'qfiles')
INQUEUE_DIR     = os.path.join(QUEUE_DIR, 'in')
OUTQUEUE_DIR    = os.path.join(QUEUE_DIR, 'out')
CMDQUEUE_DIR    = os.path.join(QUEUE_DIR, 'commands')
BOUNCEQUEUE_DIR = os.path.join(QUEUE_DIR, 'bounces')
NEWSQUEUE_DIR   = os.path.join(QUEUE_DIR, 'news')
ARCHQUEUE_DIR   = os.path.join(QUEUE_DIR, 'archive')
SHUNTQUEUE_DIR  = os.path.join(QUEUE_DIR, 'shunt')
VIRGINQUEUE_DIR = os.path.join(QUEUE_DIR, 'virgin')
BADQUEUE_DIR    = os.path.join(QUEUE_DIR, 'bad')
RETRYQUEUE_DIR  = os.path.join(QUEUE_DIR, 'retry')
MAILDIR_DIR     = os.path.join(QUEUE_DIR, 'maildir')

PIDFILE = os.path.join(DATA_DIR, 'master-qrunner.pid')
SITE_PW_FILE = os.path.join(DATA_DIR, 'adm.pw')
LISTCREATOR_PW_FILE = os.path.join(DATA_DIR, 'creator.pw')
Comment 4 Jan Kaluža 2012-02-06 08:21:46 UTC 
I don't think it's easy to change the VAR_DIRECTORY easily. Changing it in Defaults.py has never been supported, because it's not config file, but contains default variables. In mm_cfg.py it's not easy to change it (unless you do what Mark suggests).

With the way how config parsing works in Mailman (using the Python), it's not possible to change it significantly to improve the current situation.

What you could probably do is to create symlink '/var/lib/mailman' pointing to '/vol/lib/mailman', but I haven't tested whether it actually works.
Note You need to log in before you can comment on or make changes to this bug.