Add the equivalent of postconf(1)

Bug #518517 reported by Barry Warsaw
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
GNU Mailman
Status tracked in 3.0
3.0
Low
Barry Warsaw

Bug Description

Postfix has a very handy command called postconf(1) which lets you dump all or one Postfix configuration variable. It would be very handy for Mailman 3 to have something similar.

Related branches

Barry Warsaw (barry)
tags: added: mailman3
Revision history for this message
Barry Warsaw (barry) wrote :

This one would be relatively easy for someone wanting to start contributing to Mailman.

tags: added: easy
Revision history for this message
bernard Keimel (bernie-bill) wrote :

please around unstructions, thanks!

Revision history for this message
Barry Warsaw (barry) wrote :

bernard, why did you attach that image? It looks like you're spamming us. :(

Revision history for this message
Barry Warsaw (barry) wrote :

Bernard, I'm really glad you're so enthusiastic about helping out the Mailman project, but please don't assign the issue to yourself until you've contacted the Mailman developers and introduced yourself. Assignment of the bug is not necessary to *work* on the bug.

The preferred workflow is for you to upload a branch to Launchpad and link it to this bug. Then you can do a merge proposal for your branch, at which point, one of the core developers will review your branch and help you land it, if appropriate.

Also, please explain what the image is supposed to be in comment #3.

Revision history for this message
David Soto (david-soto) wrote :

I would like to work on this. I was wondering whether it would be a good approach to return the results as I'll explain below and to pass the section and key names to the command by the use of options:

/bin/mailconf -s section -k key

Both options would be optional. If you don't specify a key you would get a list of all the keys and their values of a given section and, if you don't specify a section, you would get a list of all the keys and values matching the given key name.
If both options are provided, it would just print the value and if only one of the two is provided, it would return the "full path" of the keys, as suggested by Barry (http://mail.python.org/pipermail/mailman-developers/2012-February/021725.html).

Some examples of usage:

>> /bin/mailconf -s mailman -k site_owner
> <email address hidden>

>> /bin/mailconf -s shell
> [shell] prompt : >>>
> [shell] banner : Welcome to the GNU Mailman shell
> [shell] use_ipython : no

>> /bin/mailconf -k path
> [runner.master] path: $QUEUE_DIR/$name
> [logging.template] path : mailman.log
> etc.
>

Revision history for this message
Barry Warsaw (barry) wrote : Re: [Bug 518517] Re: Add the equivalent of postconf(1)

On Jan 22, 2013, at 05:25 PM, David Soto wrote:

>I would like to work on this. I was wondering whether it would be a good
>approach to return the results as I'll explain below and to pass the
>section and key names to the command by the use of options:
>
>/bin/mailconf -s section -k key
>
>Both options would be optional. If you don't specify a key you would get a
>list of all the keys and their values of a given section and, if you don't
>specify a section, you would get a list of all the keys and values matching
>the given key name. If both options are provided, it would just print the
>value and if only one of the two is provided, it would return the "full path"
>of the keys, as suggested by Barry
>(http://mail.python.org/pipermail/mailman-developers/2012-February/021725.html).
>
>Some examples of usage:
>
>>> /bin/mailconf -s mailman -k site_owner
>> <email address hidden>
>
>>> /bin/mailconf -s shell
>> [shell] prompt : >>>
>> [shell] banner : Welcome to the GNU Mailman shell
>> [shell] use_ipython : no
>
>>> /bin/mailconf -k path
>> [runner.master] path: $QUEUE_DIR/$name
>> [logging.template] path : mailman.log
>> etc.

I like this. The alternative is to accept the `[section]variable` syntax for
the key, so that the retrieval syntax would match a hypothetical (i.e. not
part of this bug) setting syntax. postconf can set values too, but I propose
we don't worry about that for mailmanconf now.

Of course the extended syntax can always be added later, so the -s and -k
semantics you describe above seem reasonable.

(Note that these days, this would be implemented as a bin/mailman subcommand,
probably `config`.)

Feel free to follow up on mailman-developers if you have further questions.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers