Re: new feature: LDAP database name resolution
От | Albe Laurenz |
---|---|
Тема | Re: new feature: LDAP database name resolution |
Дата | |
Msg-id | 52EF20B2E3209443BC37736D00C3C1380718A6A5@EXADV1.host.magwien.gv.at обсуждение исходный текст |
Ответ на | new feature: LDAP database name resolution ("Albe Laurenz" <all@adv.magwien.gv.at>) |
Ответы |
Re: new feature: LDAP database name resolution
Re: new feature: LDAP database name resolution Re: new feature: LDAP database name resolution |
Список | pgsql-hackers |
I am now in the process of writing a patch against CVS HEAD that changes fe-connect.c as follows: - If there is a 'service' option or PGSERVICE is set, AND the environment PGLDAPSERVERS is set to a comma separated list of LDAP server URIs, LDAP name resolution cuts in. - Before pg_services.conf is examined, the LDAP servers are contacted in order until a connection can be established. - The server is queried for an entry whose distinguished name is the value of 'service'. A certain attribute is retrieved. - The resulting string is parsed for options. - If that fails, pg_services.conf is read as fallback. I have added a configure option --with-openldap to enable the code. Does that make sense to you? Should I try to polish and test the code and submit it as a patch or is this a lost effort? Do you have ideas for improvement? >>> Thank you also for drawing my attention to pg_service.conf - I have not >>> been aware of it. >>> There are two 'shortcomings': >>> - It still means that you have to change the config file on every client. >> >> Well yes. However, you could generate the config file automatically >> from another source, either LDAP or something else. > > this is definitely the best way of doing it. in fact some folks out > there use similar configurations to manager large scale systems > efficiently. Having to update configuration files on all clients is always a hassle. Of course it can be done, but isn't it much nicer to have the client query a configuration server at connection time? Yours, Laurenz Albe
В списке pgsql-hackers по дате отправления: