| 1 |
hi, |
| 2 |
|
| 3 |
I agree, I was sloppy in my post... |
| 4 |
|
| 5 |
|
| 6 |
On 4/15/07, Andrew Ross <aross@g.o> wrote: |
| 7 |
> I just wanted to correct a few misconceptions in the parent post. |
| 8 |
> |
| 9 |
> Adam Lantos wrote: |
| 10 |
> |
| 11 |
> > I personally prefer Ldap over mysql because of its optimized |
| 12 |
> > performance, and scalability. |
| 13 |
> |
| 14 |
> LDAP-accessible directories (eg. OpenLDAP) tend to be heavily optimized |
| 15 |
> for read operations, with a corresponding performance hit for writes. |
| 16 |
> Compare this with Relational Database Management Systems (RDBMS), such |
| 17 |
> as MySQL, which are optimized for both reads and writes. The other main |
| 18 |
> difference is the data model - LDAP uses an object model, while RDBMS' |
| 19 |
> use a relational model (obviously). |
| 20 |
|
| 21 |
Yes, and this also implicates that you can alter an ldap scheme |
| 22 |
without problems (at least, in most cases), altering RDBMS table |
| 23 |
structures can cause a little more headache (especially many-to one |
| 24 |
relationships), and you must check the queries, indices, etc. too much |
| 25 |
point to get it lousy for me :) |
| 26 |
|
| 27 |
And when it comes to relationships, LDAP performs better. Not to |
| 28 |
mention, you don't have to write joined queries, and figure out |
| 29 |
multiple row indices to keep the read performance good using RDBMS. |
| 30 |
|
| 31 |
> Personally, I choose LDAP for user/group information, address books, |
| 32 |
> etc, while print accounting and other usage data goes in a relational |
| 33 |
> database. OpenLDAP supports a wide range of backends, including MySQL, |
| 34 |
> so it's possible to provide an LDAP-interface to your RDBMS. |
| 35 |
> > Ldap is stable enough, and it's much |
| 36 |
> > more secure than mysql (using TLS for connections, you can set ACLs). |
| 37 |
> |
| 38 |
> MySQL and most other RDMS' support TLS and/or SSL-secured connections, |
| 39 |
> as well as fine-grained permissions. |
| 40 |
|
| 41 |
thank you for correcting. I just wanted to point out that in LDAP you |
| 42 |
can write ACL to every entry and every attribute. With MySQL you can't |
| 43 |
reach this, or atleast I don't know the solution (apart of hack with |
| 44 |
stored procedures) - In RDBMS you can restrict some clients to access |
| 45 |
read-only to the users table, but that client still sees the hashed |
| 46 |
password. On the other hand, LDAP offers a great way to do |
| 47 |
authentication/authorization, and fine-grain RO/RW access to |
| 48 |
everything. |
| 49 |
|
| 50 |
> > You can store virtually anything related to users without bothering |
| 51 |
> > with database schemes - quotas, email accounts, database |
| 52 |
> > configurations, apache configuration and so on... |
| 53 |
> |
| 54 |
> LDAP has objectClasses and schema checking. |
| 55 |
> |
| 56 |
> > Ldap is faster too because of the binary database backend it uses. |
| 57 |
> |
| 58 |
> MySQL and most other RDBMS' use binary backends too. |
| 59 |
> |
| 60 |
> > And much more tools |
| 61 |
> > support Ldap, so you can use one password to sftp, one password to |
| 62 |
> > apache htaccess, ... easier than with mysql. |
| 63 |
> |
| 64 |
> As long as the services support PAM, it's just as easy to use an LDAP |
| 65 |
> backend as it is to use MySQL. |
| 66 |
|
| 67 |
agree. in a hosting environment you should use another instance of |
| 68 |
RDBMS to keep the user/group data apart from the customers data, and |
| 69 |
avoid availability/performance problems. |
| 70 |
|
| 71 |
> > -FTP is insecure, because it sends the password in plaintext. |
| 72 |
> |
| 73 |
> Newer FTP servers (eg. vsftpd) and clients support SSL. |
| 74 |
> Cheers |
| 75 |
> |
| 76 |
> Andrew |
| 77 |
> |
| 78 |
> |
| 79 |
> |
| 80 |
|
| 81 |
|
| 82 |
and once again sorry for my ambiguity in the previous post |
| 83 |
|
| 84 |
|
| 85 |
yours, |
| 86 |
Adam |
| 87 |
-- |
| 88 |
gentoo-hardened@g.o mailing list |
Archives