Re: ****Re: openldap + kmail

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 2008-04-30 at 13:49 -0700, Craig White wrote:
> On Wed, 2008-04-30 at 15:27 -0430, Patrick O'Callaghan wrote:
> > On Wed, 2008-04-30 at 12:39 -0700, Craig White wrote:
> > > On Wed, 2008-04-30 at 14:53 -0430, Patrick O'Callaghan wrote:
> > > > On Tue, 2008-04-29 at 22:19 -0700, Craig White wrote:
> > > > > On Tue, 2008-04-29 at 23:49 -0430, Patrick O'Callaghan wrote:
> > > > > > On Tue, 2008-04-29 at 20:45 -0700, Craig White wrote:
> > > > > > > > If there had been a single example given in this case
> > > > > > > > it would have been obvious what the program was looking for.
> > > > > > > > One example is worth a thousand words.
> > > > > > > ----
> > > > > > > the issue with kaddressbook is the same issue with all ldap
> > > > > > > clients...once you understand how ldap works, setting up a client like
> > > > > > > kaddressbook is no big deal. Basically, everything is a client to LDAP
> > > > > > > whether it's postfix/sendmail/cyrus/kaddressbook/evolution/etc. There
> > > > > > > really is no functional difference because they all use LDAP protocol
> > > > > > > to
> > > > > > > access and get what they need.
> > > > > > > 
> > > > > > > What you are calling a lack of documentation suggests that you expect
> > > > > > > all the various LDAP client programs to tell you how LDAP works.
> > > > > > 
> > > > > > It's not unreasonable to ask for an example. The average user has zero
> > > > > > interest in finding out how LDAP works, and a lot of interest in getting
> > > > > > his contacts working.
> > > > > ----
> > > > > Yes - it actually is unreasonable since there is no standard way of
> > > > > setting up LDAP address books. 
> > > > > 
> > > > > Since we seem to keep having this discussion...let me restate so we are
> > > > > clear.
> > > > > 
> > > > > There simply is no standard for LDAP address books.
> > > > > 
> > > > > There simply is no standard way to set anything up in LDAP...it's an
> > > > > erector set.
> > > > 
> > > > I understand that perfectly well. However the question was not "how do I
> > > > set up a general-purpose address book" but "how do I set up an
> > > > address-book that Kmail will accept" and my suggestion of an example was
> > > > also specific to Kmail. Clearly the OP solved the problem by setting up
> > > > his address book in a certain way. Why can't what way be documented as
> > > > an example in the Kmail documentation (*not* the LDAP documentation)?
> > > ----
> > > What is the difference between a 'general-purpose address book' and a
> > > 'specific-purpose Kmail address book' that uses an LDAP backend?
> > > 
> > > I would submit that there is no difference but that they are one and the
> > > same. 
> > 
> > The OP's system didn't work with one configuration, and now does work
> > with a different configuration (apparently the trick is to have a field
> > "DN: Address Book" as part of the record). What is the problem with
> > simply stating this in the Kmail docs? Maybe the field has to be there
> > for every other address-book application out there, maybe not, but the
> > fact that it's a general recommendation doesn't take away from it also
> > being a specific recommendation.
> ----
> No - you misunderstood him

No doubt.

> It is not possible to have a 'DN: Address Book'
> 
> All you need is suitable 'ou' with ACL permissions to access that 'ou'
> and if that 'ou' were called 'People_I_Want_to_SPAM', Kaddressbook would
> be happy with that too. Of course, that gets into the nuts and bolts of
> LDAP. Having an 'ou' called 'Address Book' or 'AddressBook' has no
> meaning to Kaddressbook unless Kaddressbook is configured to use the DN
> like...
> ou=AddressBook,dc=xyz,dc=com
> 
> but if that DN doesn't exist in your LDAP DSA, it simply wouldn't work.

<rant>
Now why can't someone say exactly that in places where people are likely
to read it, such as the man pages or help docs or FAQ or tutorials or
whatever of user-facing applications rather than the spec documents of a
protocol that no-one but inveterate hackers want to try and understand?
I know it's not always possible to avoid RFCs and such, but that's not a
reason for making the user's life more difficult than it needs to be. I
consider myself a fairly technically-oriented person, but even I can't
be bothered researching this stuff just for the heck of it, and life is
too short to have to do so just to get a simple app such as an address
book to work properly. Always remember that laziness is a great
motivator!
</rant>

Thank heaven for lists such as this one, where one can piggyback on the
hard work of others :-)

poc

-- 
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [Fedora Magazine]     [Fedora News]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [SSH]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux