Re: complete example configs for the MULTI_INSTANCE_README tutorial?
Enough.
Re: complete example configs for the MULTI_INSTANCE_README tutorial?
> I don't remember asking for your judgement on my motives or thought processes. And I don't recall asking you for anything at all. > But I'm done with it I'm sure that makes us both happy. Feel free to prattle on at will. That's what bit-buckets are for. --- On Wed, 06 Apr 2011 23:58 +0200, "Jeroen Geilman" wrote: > On 04/06/2011 07:31 PM, dchil...@bestmail.us wrote: > > > > On Wed, 06 Apr 2011 19:06 +0200, "Jeroen Geilman" > > wrote: > > > >> As the documentation for -o stress= explains > >> > > There's that persistent presumption that message sent = message > > received. > > > > I don't remember asking for your judgement on my motives or thought > processes. > > What you stated was incorrect - I corrected it. > > > I read the documentation. Lots of it. And clearly, as you've taken the > > time to point out, still managed to get it wrong. > > > > Thanks for amplifying my point. > > > > I merely answered the implied question in your incorrect assumption on > how -o stress works. > > > >> You probably haven't calculated the absurd number of possible > >> configurations. > >> > > No, I haven't done any such calculation. That in itself would be > > absurd. > > > > To do what I suggest -- simply suggest, as requested by Wietse -- is > > pick *one*. A rich, complex one. > > > > Just because you can't reasonably cover ALL possible scenarios, is your > > point/argument that one shouldn't attempt to do ONE thing? > > No. > > >> What IS clear from the docs, since it is referred to multiple times > >> > > There's that presumption again. > > > > Really, my response to Wietse's request was NOT a commentary on *your* > > clear grasp of Postfix. I'm glad everything is so clear to you; I'm > > envious. > > > > No, you're arrogant and supercilious. > > But I'm done with it - I am sorry I corrected your misassumptions. > > > >> My advice is to read the man pages for each daemon carefully, and refer > >> back to them whenever you have questions such as these, since the man > >> page will tell you exactly what function each program performs, and > >> which configuration options apply to it. > >> > > Thanks for that. RTFM never crossed my mind ... > > > > Add "sarcastic" to the list. > > > And my advice would be to read MY post, note that I've stated that I > > *have* read and re-read the docs, > > And yet failed to interpret the simpler cases you mentioned above. > What hope would you have of grokking a complex setup ? > > > I know, I am being nasty. > > Your attitude richly deserves it. > > > -- > J. > >
Re: complete example configs for the MULTI_INSTANCE_README tutorial?
On Wed, 06 Apr 2011 17:03 -0400, "Wietse Venema" wrote: > I have a suggestion. If you're not familiar with Postfix, don't > try to use all the bells and whistles the first time. Use the > basic features first, and add advanced features over time as > you become more familiar with the system. Already did that. Enough that I found it trivial to have a working system 'without the bells and whistles'. As I hope I've managed to communicate, for *that* the docs have been great. But the advice is nonetheless appreciated, thanks. It's specifically understanding, adding & weaving-together those bells & whistles to get to a system that does what I've had previously, and would now like to implement in Postfix is where my current challenge is. That fact that our goals, approaches and requirements are different should come as no surprise. And most certainly not be the reason for you to waste any more of your time! :-) Thanks. DChil
Re: complete example configs for the MULTI_INSTANCE_README tutorial?
dchil...@bestmail.us: > Hi Wietse, > > On Wed, 06 Apr 2011 14:07 -0400, "Wietse Venema" > wrote: > > I find that Postfix documentation can always be improved. Despite > > a lot of review there are still inaccuracies and omissions. > ... > > Indeed. The current documentation focuses on the basics: being > > precise (no errors or omissions). It's like an illustrated > > encyclopedia. This does not help people who don't know what they > > are looking for, or what solutions may exist for a problem that > > may not be well understood. > > Well stated. My challenge is likely self-imposed. I'm trying to > implement/deploy Postfix as a > "(my) real-world solution" that's a replacement for very functional, > though still limited and somewhat opaque, solutions such Zimbra & > CommuniGate. For me it is NOT an issue of free vs not; rather one of > fully capable & flexible ... or not. > > To your point, I *do* know what capabilities I'm looking for. Simply > not in the context of Postfix, or more precisely, within the context of > its documentation. > > Yet. I have a suggestion. If you're not familiar with Postfix, don't try to use all the bells and whistles the first time. Use the basic features first, and add advanced features over time as you become more familiar with the system. Wietse
Re: complete example configs for the MULTI_INSTANCE_README tutorial?
Hi Wietse, On Wed, 06 Apr 2011 14:07 -0400, "Wietse Venema" wrote: > I find that Postfix documentation can always be improved. Despite > a lot of review there are still inaccuracies and omissions. ... > Indeed. The current documentation focuses on the basics: being > precise (no errors or omissions). It's like an illustrated > encyclopedia. This does not help people who don't know what they > are looking for, or what solutions may exist for a problem that > may not be well understood. Well stated. My challenge is likely self-imposed. I'm trying to implement/deploy Postfix as a "(my) real-world solution" that's a replacement for very functional, though still limited and somewhat opaque, solutions such Zimbra & CommuniGate. For me it is NOT an issue of free vs not; rather one of fully capable & flexible ... or not. To your point, I *do* know what capabilities I'm looking for. Simply not in the context of Postfix, or more precisely, within the context of its documentation. Yet. > Unfortunately, it's not practical for me to maintain lots of > ready-to-run examples beyond the examples in the README files. Certainly understood. Although, as counterpoint, One might argue that you'd "waste" less time kindly talking to the likes of "me" :-) > All the steps to turn on/off postscreen are documented in > POSTSCREEN_README examples at the end of the document. If the > description of any step is incorrect, or if a step is missing, then > a concrete suggestion for improvement is welcome. Again, I can't/won't argue that any particulary step is incorrect or missing. As others have already undertaken to point out, the documentation is 'clear', fulfilling nicely your goal of accurate/precise, and that I should simply RTFM. Again. All I can comment on is I took the time to read as much as I could lay hands on, and still ended up adding "-o screen=yes" to the 'smtp ... postscreen' line in that instance's master.cf. Wrong? Yes, apparently. Precisely stated in the docs? Must be. Everyone says it is. What's left? My own misunderstanding. The best solution, imo? For me, and simply in my opinion, as stated and requested ... a good, single working example config. Will it be done here? No, and I ACK your argument why not. > When you configure TLS for receiving email, then you configure TLS > for smtpd as documented in TLS_README. > > These settings for smtpd become the default settings for postscreen > and tlsproxy, as documented in their respective manpages. Because > of these default settings, postscreen and tlsproxy will use 100% > identical TLS settings as smtpd. The idea is to make it easier > than having to configure each program separately to do the same > thing. Again, I'm completely off base in what I gleaned from my reading. My (mis)understanding was that, especially in a multi-instance setup, the TLS config for tlsproxy needed to be in the main.cf for the specific instance that used it. I understood *no* inheritance from the primary config in /etc/postfix to any other instance. > I suppose you can recommend some changes for the examples at the end > of POSTSCREEN_README. Can't recommend what I don't understand. And adding specific changes for specific changes to individual component does two thing wrong, imo, (1) it unnecessarily 'fattens' already well written docs (2) completely misses the opportunity to 'tie it all together' in a/any single, rich context. which is, after all, what I believe to be my current challenge. > I would not recommend burdening TLS_README with explicit configuration > examples for postscreen and tlsproxy, because there is no good > reason why those daemons should use TLS configuration that is > different. To my earlier point. Your "don't burden" ~ my "don't fatten". We're in 'violent agreement'. > Someone would have to invest a huge amount of time not only writing > up "complete" examples, but also keeping them up to date on Postfix > development. !examples. example. !them. it. just one. chosen using your expertise, experienc, and discretion. Imo, building on Viktor's MultiInstance example would be a great start. As for maintaining it, that's where a wiki serves nicely. One can certainly argue 'just create it and post something yourself'. Unfortunately, that's kind of like walking into a room of 10 people and asking "what should we do"? 10 people, 20 opinions. i'm simply proposing that those with "guru status" (you know who you are) plant the seed of a good start. > That is the biggest problem with all the Postfix howtos on the web. > They often have errors, and they almost always lag years of Postfix > development. agreed. even in my short-term, limited, experience, that much is clear. books are outdated, howtos are wrong, 'shrines' have vanished or crumbled, etc. which is why i'm attempting to learn 'here' and with the latest, up to date, docs. > More practical, Postfix documentation is unlikely to evolve beyond > the examples in th
Re: complete example configs for the MULTI_INSTANCE_README tutorial?
dchil...@bestmail.us: > Hi Wietse > > > > On Tue, 05 Apr 2011 22:07 -0400, "Wietse Venema" > > For more, see: > > > > http://www.postfix.org/POSTSCREEN_README.html > > http://www.postfix.org/postscreen.8.html > > > > If any text in there is not 100% clear, send suggestions for > > improvement. > > Since you asked about clarity in documentation and suggestions ... I > hope the following perspective will be of some help. It includes 'a > suggestion for improvement'; just my $0.02. I find that Postfix documentation can always be improved. Despite a lot of review there are still inaccuracies and omissions. > In some instances, although I'm reading and re-reading the docs, I'm not > finding it an efficient process to get the info I need out. Indeed. The current documentation focuses on the basics: being precise (no errors or omissions). It's like an illustrated encyclopedia. This does not help people who don't know what they are looking for, or what solutions may exist for a problem that may not be well understood. Unfortunately, it's not practical for me to maintain lots of ready-to-run examples beyond the examples in the README files. > I'm finding > I have to dig in a lot of different places to ferret out a single answer > in the context of a 'real world' setup. And, I'm not being very > successful at it. I'll shoulder my part of the bargain, and admit to > lack of experience & understanding at this point. > > Two current examples. > > postscreen & stress support. I see in the postscreen docs that certain > paramaters support stress parameters. To find out how to turn it on, I > have to go to the stress docs, and find the "-o stress=yes" param, then > surmise that it need to be added to the master.cf entry that contains > postscreen, only in the postfix instance that invokes it, and not in the > 'primary' config that's declared to be "more equal than others" ... > > In retrospect, or to the experienced user, the answer may be obvious. > To me it wasn't. It could've been made much simpler, imo, without > really changing the docs, but rather by having a commented set of config > files from a single, working, 'complex' example -- where I could SEE > what was done. There is no documentation about how to configure postscreen stress with master.cf, because that is not possible :-) All the steps to turn on/off postscreen are documented in POSTSCREEN_README examples at the end of the document. If the description of any step is incorrect, or if a step is missing, then a concrete suggestion for improvement is welcome. > as a 2nd example, TLS, which I'd mentioned in another message. again, > I've found the docs & man pages, and read through them. I'm still not > sure in how many places I'm supposed to add my key definitions, for > example. Only in the postscreen containing postfix instance's main.cf? > as "tls_" params for tlsproxy? Do I also need to add key defs in other > instances' configs? And if so, as "tls_" params for tlsproxy or as > "smtpd_" params? (this, e.g., "tlsproxy_tls_CAfile ($smtpd_tls_CAfile)" > is not clear as usage from the docs ...). When you configure TLS for receiving email, then you configure TLS for smtpd as documented in TLS_README. These settings for smtpd become the default settings for postscreen and tlsproxy, as documented in their respective manpages. Because of these default settings, postscreen and tlsproxy will use 100% identical TLS settings as smtpd. The idea is to make it easier than having to configure each program separately to do the same thing. > to have made this clearer, again, no change to the docs really required, > rather that same "single, working, 'complex' example" would do ... I suppose you can recommend some changes for the examples at the end of POSTSCREEN_README. I would not recommend burdening TLS_README with explicit configuration examples for postscreen and tlsproxy, because there is no good reason why those daemons should use TLS configuration that is different. > Among the better examples I can reference of what, for me, has worked > well in deploying a complex/dense product is 'Shorewall' documentation. > That it's a different product, topic, application is acknowledged and of > little relevance to my point ... > > If you take a look here: > http://www.shorewall.net/Documentation_Index.html, you'll note an > extensive list of 'use case' articles, tutorials, and documentation. In > addition to its similarly exhaustive documentation on parameters and > usage, I find these to be invaluable in actually getting a complex > conifg up and running. Someone would have to invest a huge amount of time not only writing up "complete" examples, but also keeping them up to date on Postfix development. That is the biggest problem with all the Postfix howtos on the web. They often have errors, and they almost always lag years of Postfix development. More practical, Postfix documentation is unlikely to evolve beyond the examples in t
Re: complete example configs for the MULTI_INSTANCE_README tutorial?
On Wed, 06 Apr 2011 19:06 +0200, "Jeroen Geilman" wrote: > As the documentation for -o stress= explains There's that persistent presumption that message sent = message received. I read the documentation. Lots of it. And clearly, as you've taken the time to point out, still managed to get it wrong. Thanks for amplifying my point. > You probably haven't calculated the absurd number of possible > configurations. No, I haven't done any such calculation. That in itself would be absurd. To do what I suggest -- simply suggest, as requested by Wietse -- is pick *one*. A rich, complex one. Just because you can't reasonably cover ALL possible scenarios, is your point/argument that one shouldn't attempt to do ONE thing? The very 'good example' that I referenced, Shorewall, does exactly that. Picks one (at a time), and thoroughly fleshes it out, in single consistent context -- a an invaluable *complement* to the rigorous detailed documentation. Seriously, why then bother ever having any examples of anything, as more often than not they won't be directly applicable to "your" specific case -- one of the many *other* "absurd number of possible configurations". > What IS clear from the docs, since it is referred to multiple times There's that presumption again. Really, my response to Wietse's request was NOT a commentary on *your* clear grasp of Postfix. I'm glad everything is so clear to you; I'm envious. > My advice is to read the man pages for each daemon carefully, and refer > back to them whenever you have questions such as these, since the man > page will tell you exactly what function each program performs, and > which configuration options apply to it. Thanks for that. RTFM never crossed my mind ... And my advice would be to read MY post, note that I've stated that I *have* read and re-read the docs, and refer back to the *stated* context of my comments -- as a new user's first impressions -- and the reason that I'm making the comments -- namely, I was asked by the app's author. Who, imo, has done a great job of putting together some excellent documentation -- and was open enough to ask for further feedback from an obviously new user.
Re: complete example configs for the MULTI_INSTANCE_README tutorial?
On 04/06/2011 06:15 PM, dchil...@bestmail.us wrote: postscreen& stress support. I see in the postscreen docs that certain paramaters support stress parameters. To find out how to turn it on, I have to go to the stress docs, and find the "-o stress=yes" param, then surmise that it need to be added to the master.cf entry that contains postscreen, only in the postfix instance that invokes it, and not in the 'primary' config that's declared to be "more equal than others" ... As the documentation for -o stress= explains, this is not an option that YOU enable. Rather, specific postfix configuration settings either support it, or not. If they support it, when (any of) the limits defined for stress-dependent configuration options are exceeded, *postfix* turns on the stress-adaptive option: http://www.postfix.org/STRESS_README.html#adapt In retrospect, or to the experienced user, the answer may be obvious. To me it wasn't. It could've been made much simpler, imo, without really changing the docs, but rather by having a commented set of config files from a single, working, 'complex' example -- where I could SEE what was done. You probably haven't calculated the absurd number of possible configurations. as a 2nd example, TLS, which I'd mentioned in another message. again, I've found the docs& man pages, and read through them. I'm still not sure in how many places I'm supposed to add my key definitions, for example. Only in the postscreen containing postfix instance's main.cf? as "tls_" params for tlsproxy? Do I also need to add key defs in other instances' configs? And if so, as "tls_" params for tlsproxy or as "smtpd_" params? (this, e.g., "tlsproxy_tls_CAfile ($smtpd_tls_CAfile)" is not clear as usage from the docs ...). What IS clear from the docs, since it is referred to multiple times, is that in general, the settings in main.cf are the defaults for the daemon that uses each particular setting. You can override most of the per-daemon settings in master.cf in their respective service definitions - and in some cases, it only makes sense to do so in master.cf (think of syslog_name for separate smtpd listeners, for example.) When using multiple instances, this applies to each instances' main.cf and respective master.cf services. Multiple instances do not share any configuration that's not directly related to multi-instance management. My advice is to read the man pages for each daemon carefully, and refer back to them whenever you have questions such as these, since the man page will tell you exactly what function each program performs, and which configuration options apply to it. -- J.
Re: complete example configs for the MULTI_INSTANCE_README tutorial?
Hi Wietse > > On Tue, 05 Apr 2011 22:07 -0400, "Wietse Venema" > For more, see: > > http://www.postfix.org/POSTSCREEN_README.html > http://www.postfix.org/postscreen.8.html > > If any text in there is not 100% clear, send suggestions for > improvement. Since you asked about clarity in documentation and suggestions ... I hope the following perspective will be of some help. It includes 'a suggestion for improvement'; just my $0.02. As a *new* Postfix user (retreating, or better, re-locating from Zimbra ...), I find the text of the online docs to be mostly thorough and exhaustive. I've of course read those docs & man pages, as well as relevant material from the two available, old books I've been able to find on Postfix, *before* posting my questions here. I have so much Postfix material printed out, I can't see the surface of my desk anymore ;-) I certainly do understand the typical response of simply providing links to existing docs, and suggesting to 'rtfm'. The presumption that materials have NOT been _read_, however, is not always a valid one. In some instances, although I'm reading and re-reading the docs, I'm not finding it an efficient process to get the info I need out. I'm finding I have to dig in a lot of different places to ferret out a single answer in the context of a 'real world' setup. And, I'm not being very successful at it. I'll shoulder my part of the bargain, and admit to lack of experience & understanding at this point. Two current examples. postscreen & stress support. I see in the postscreen docs that certain paramaters support stress parameters. To find out how to turn it on, I have to go to the stress docs, and find the "-o stress=yes" param, then surmise that it need to be added to the master.cf entry that contains postscreen, only in the postfix instance that invokes it, and not in the 'primary' config that's declared to be "more equal than others" ... In retrospect, or to the experienced user, the answer may be obvious. To me it wasn't. It could've been made much simpler, imo, without really changing the docs, but rather by having a commented set of config files from a single, working, 'complex' example -- where I could SEE what was done. as a 2nd example, TLS, which I'd mentioned in another message. again, I've found the docs & man pages, and read through them. I'm still not sure in how many places I'm supposed to add my key definitions, for example. Only in the postscreen containing postfix instance's main.cf? as "tls_" params for tlsproxy? Do I also need to add key defs in other instances' configs? And if so, as "tls_" params for tlsproxy or as "smtpd_" params? (this, e.g., "tlsproxy_tls_CAfile ($smtpd_tls_CAfile)" is not clear as usage from the docs ...). to have made this clearer, again, no change to the docs really required, rather that same "single, working, 'complex' example" would do ... Among the better examples I can reference of what, for me, has worked well in deploying a complex/dense product is 'Shorewall' documentation. That it's a different product, topic, application is acknowledged and of little relevance to my point ... If you take a look here: http://www.shorewall.net/Documentation_Index.html, you'll note an extensive list of 'use case' articles, tutorials, and documentation. In addition to its similarly exhaustive documentation on parameters and usage, I find these to be invaluable in actually getting a complex conifg up and running. I'm not suggesting getting to that point in one giant leap, and to attempt to cover all scenarios. rather, as a first step, pick/define _one_ more-or-less complex setup ***, using the tools-&-toys modern/latest postfix provides, and provide a known working set of configs for it. It would provide single, consistent context within which to understand and apply the individually well-documented componenets. With my luck, this already exists and I just haven't found it ... yet. HTH! DChil *** e.g., multiple instance, across multiple servers, listening at multiple IPs, servicing multiple domains, using TLS, stress management, etc. yes, i recognize it's challenging and requires effort to put something like that together. that's the point ...
Re: complete example configs for the MULTI_INSTANCE_README tutorial?
dchil...@bestmail.us: > Hi Wietse > > On Tue, 05 Apr 2011 22:07 -0400, "Wietse Venema" > wrote: > > Postscreen is an additional line of defense. It does not replace > > the other Postfix features, but rather, it aims to reduce the > > pressure on those features. > > Okay. > > Is that "doesn't replace" true for all its functions? Yes. Postscreen is not "in the loop" when Postfix receives email. For more, see: http://www.postfix.org/POSTSCREEN_README.html http://www.postfix.org/postscreen.8.html If any text in there is not 100% clear, send suggestions for improvement. Wietse
Re: complete example configs for the MULTI_INSTANCE_README tutorial?
Hi Wietse On Tue, 05 Apr 2011 22:07 -0400, "Wietse Venema" wrote: > Postscreen is an additional line of defense. It does not replace > the other Postfix features, but rather, it aims to reduce the > pressure on those features. Okay. Is that "doesn't replace" true for all its functions? Specifically, re: TLS, I see that postscreen supports STARTTLS connections. Is that TLS handshake 'sufficient' then for other step in the mail delivery path, or will subsequent Postfix instances (e.g., inbound pre-filter, outbound post-filter), each also need TLS configuration paramaters? I like the concept of the MultiInstance setup -- each piece of the puzzle being cleanly configured to do "its thing" well, but I'm still a bit foggy on how much config needs to be replicated. Thanks DChil
Re: complete example configs for the MULTI_INSTANCE_README tutorial?
dchil...@bestmail.us: > Also, if I'm going to deploy postscreen, am I correct in understanding > that. in this example's case, I'd deploy it @ each of the two inbound > pre-filter instances? in lieu of a separate filter stage? Postscreen is an additional line of defense. It does not replace the other Postfix features, but rather, it aims to reduce the pressure on those features. I'll leave it up to other people to review your examples. Wietse
complete example configs for the MULTI_INSTANCE_README tutorial?
Hi,
I've built & installed Postfix 2.8.2 from src, and followed the installs
steps & examples:
http://www.postfix.org/BASIC_CONFIGURATION_README.html
http://www.postfix.org/STANDARD_CONFIGURATION_README.html
http://www.postfix.org/MULTI_INSTANCE_README.html
I've ended up with a 4-instance edge setup,
2 inbound pre-filter
1 null client
1 outbound post-filter
with which I can actually send & receive email. I have not yet done
'production level' testing (reading about XCLIENT now ...)
The instructions refer often to 'stock' main.cf, and make various
changes in the examples. I *think* I got most of it right. I'd like to
read-thru and compare to a full-blown config.
Do examples of full/final configs for all of these examples exist for
download & review? Ideally, the listings
/etc/{postfix,postfix-out,postfix-in} from the MULTI_INSTANCE_README
would be really helpful.
Also, if I'm going to deploy postscreen, am I correct in understanding
that. in this example's case, I'd deploy it @ each of the two inbound
pre-filter instances? in lieu of a separate filter stage?
DChil
