* Wietse Venema <postfix-users@postfix.org>: > Patrick Ben Koetter: > > > Next, a few examples that are likely to be implemented: > > > > > > postconf -M# service-type ... > > > postconf -M# service-type.service-name ... > > > > > > postconf -MX service-type ... > > > postconf -MX service-type.service-name ... > > > > > > Delete (or comment) out the specified services. > > > > Would it make sense - differing from main.cf behaviour - to revert > > comments in master.cf? > > In both cases, I don't understand how that would work.
Neither do I. Here's the problem I'd like to solve: The submission service is commented out by default. Nowadays I enable it very often when I install Postfix. Issuing a command that removes/reverts the comments from e.g. the submission service sounds just like a feature that would solve my problem. Thus the investigation if it made sense to revert comments in master.cf. On a sidenote: At the moment "postconf -M ..." doesn't seem to list service types that are commented out. Unless I haven't missed a way it would probably make sense to list them if comments were to be reverted. > > > I am contemplating a new class of master.cf operations that operate > > > column-wise. These currently have no main.cf equivalent. > > > > > > postconf -Mu chroot=n inet unix fifo pass > > > > > > Update the "chroot" column to "n" for all services. > > > > Would the new class also allow to edit a _single_ service e.g.: > > > > postconf -Mu chroot=n inet.submission > > Of course. A pattern can match one entry or more. > > > Should postconf be able/offer to make backup copies before it acts a request > > out? > > Should it with main.cf? Should we enourage the use of version control? Somehow I fear that we will see more users having ruined their master.cf than others having done the same to main.cf. Resurrecting a master.cf seems to be more hard because of its higher inner complexity (columns etc.). I think the documentation should encourage the use of version control. The rest may remain every admins personal responsibility. > > > And finally, a more complicated example: > > > > > > postconf -Me 'text of complete master.cf entry' > > > > > > Replace the specified master.cf service or add a new service. > > > Each postconf(1) command-line argument contains the text > > > of a complete master.cf entry. The new entry is line-wrapped > > > as with "postconf -Mf". > > > > > > This command syntax is consistent with existing "postconf -e" > > > commands, where each postconf(1) command-line argument contains the > > > text of a complete main.cf entry. > > > > In postconf(1) you wrote "-e Edit the main.cf configuration file, and > > update > > parameter settings ..." > > The text is too vague and needs to be updated. What happens in > reality is "replace or add main.cf entry, using the complete entry > given on the postconf command line". > > If there is a command to implement THAT FUNCTION for master.cf (add > or replace entry, using the complete entry given on the postconf > command line) then it should use the same -e option. > > > I haven't thought this through - you probably have: Wouldn't it be more > > consistent to use only 'e' (as already for main.cf) instead of 'u' and 'e' > > as > > proposed for master.cf? > > "u" replaces a field in master.cf. It has no main.cf equivalent > (replace a word in the middle of a line?) therefore should not use > an option letter that is used for main.cf. Got it. Thanks p@rick -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer Aufsichtsratsvorsitzender: Joerg Heidrich
