On Mon, Jul 04, 2005 at 11:34:45AM -0300, Bruno Negrão wrote:
> 
> >>a) "THE BIG Qmail-LDAP PICTURE" says that auth_pop and auth_imap have 
> >>the
> >>same control files as qmail-lspawn: not true because qmail-lspawn does 
> >>not
> >>read "ldaprebind" while auth_imap and auth_pop do.
> >
> >Wrong qmail-lspawn reads ldaprebind. It does not use it but it reads the
> >file.
> But "THE BIG Qmail-LDAP PICTURE" does not say that neither. According to 
> "THE BIG Qmail-LDAP PICTURE", the ldaprebind file doesn't even exist.
> 
> >>b) "THE BIG Qmail-LDAP PICTURE" does not say which program reads the
> >>"cert.pem" control file. But qmail-control(5) will show that for you.
> >Cert.pem is not directly read by any qmail-ldap tool. qmail-smtpd reads
> >now smtpcert and decides from there which cert should be used.
> Thanks by introducing me to smtpcert, another control files not mentioned 
> on "THE BIG Qmail-LDAP PICTURE". qmail-control(5) will report its existence 
> for the mainstream.
> 

smtpcert is something introduced lately and is documented in QLDAPINSTALL.
We never said that "THE BIG Qmail-LDAP PICTURE" is complete and up to
date. QLDAPINSTALL ist the document where all control files are
documented (and there is a section about smtpcert in it).

> >Btw. there is also a ENV to override smtpcert.
> One more "complicateness" of qmail-ldap. This will fit smoothly on the 
> "overriden" column of "THE CONTROL FILES TABLE" in qmail-control(5)
> 

Once again have a look at QLDAPINSTALL. Btw. it is not "complicateness"
but more flexibility of qmail-ldap.

> 
> >"Furthermore, Qmail-ldap broke down stock Qmail's rule that 1 control 
> >file
> >is read by only 1 qmail-program."
> >Wrong. ~control/me is read by more than one qmail-program.
> I know that. But in Qmail, "me" is the default for almost everything. And 
> besides "me", no other control file is read by two different programs.
> 
> >There are a few more files that behave similar.
> Would you give me an example? I really cannot guess what.
> 

rcpthosts

> 
> >The documentation location table is plain worng and super ugly.
> Explain to me why is it wrong, please.
>

It is the wrong aporach.
 
> >It remebers me too much of unpleasant Solaris nightmares.
> Come on Claudio, this is bullshit. We're system administrators, not graphic 
> designers. Please evaluate the table for what it informs, not by how it 
> looks. Btw, that yellow flower on the upper left corner of the Main_Page is 
> also a nightmare. (hehehe)
> 

The information in that table is unintresting. If I'm intrested in the way
ldapserver is configured it would type "man ldapserver" and perhaps "man
-k ldapserver". Oh wait we're talking about a homepage here so man does
not work. So why not add links form the large table of files to their
explanation? Or why not do it in a different way -- instead of emulating a
system that does not work in the web.


> >Just make a page per config file. This is a web-page and even for 
> >manpages I would do it
> >like this. There is no need to save inodes.
> I'm not thinking in saving inodes when I'm grouping the control-files. By 
> creating a manpage for each control file my intention was not to polute the 
> Section 5 with 30 more manpages. And I believe that grouping those files 
> that way increases the awareness of the functionality of those files.
> 

I don't care how many files I have in section 5. I care about how to find
them.

> But if people think I should do that, I just have an idea: I could create 
> the manpages for the shared control files with a "qmail-control" radical. 
> Like this:
> 
> -  qmail-control-ldaprebind(5)
> -  qmail-control-ldapbasedn(5)
> -  qmail-control-ldappassword(5)
> -  qmail-control-dirmaker(5)
> -  qmail-control-etc(5)
> 

Iick, how should somebody guess these names.

> This won't be terrible.
> 

That's your opinion, definitively not mine.

-- 
:wq Claudio

Reply via email to