[SAC] LDAP server migration this Saturday evening

Hi folks,
I'm planning to migrate the OSGeo LDAP server over to the "secure" VM
this Saturday evening (night), whereas the time of day referrs to
GMT+2. This process will include:

1.) Making the current LDAP directory non-writeable;
2.) pulling an LDIF dump;
3.) pushing this dump into the LDAP server on the "secure" VM;
4.) running a couple of tests/diffs on the new LDAP server;
5.) Updating the 'ldap.osgeo.org' DNS entry.

I'll try to identify as many places as possible in the Apache config on
'osgeo1' which still refer to 'localhost' as LDAP server, but it would
be better if people switch over to 'ldap.osgeo.org' beforehand - if they
didn't already do so.

Cheers,
  Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--------------------------------------------------------------------------

On 11-05-21 06:16 AM, Martin Spott wrote:

Hi folks,
I'm planning to migrate the OSGeo LDAP server over to the "secure" VM
this Saturday evening (night), whereas the time of day referrs to
GMT+2. This process will include:

1.) Making the current LDAP directory non-writeable;
2.) pulling an LDIF dump;
3.) pushing this dump into the LDAP server on the "secure" VM;
4.) running a couple of tests/diffs on the new LDAP server;
5.) Updating the 'ldap.osgeo.org' DNS entry.

I'll try to identify as many places as possible in the Apache config on
'osgeo1' which still refer to 'localhost' as LDAP server, but it would
be better if people switch over to 'ldap.osgeo.org' beforehand - if they
didn't already do so.

Martin,

Will you be migrating the python scripts used to administer the LDAP server
or will we leave those on osgeo1 for the time being?

Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | Geospatial Programmer for Rent

On Sat, May 21, 2011 at 07:44:12AM -0400, Frank Warmerdam wrote:

Will you be migrating the python scripts used to administer the LDAP server
or will we leave those on osgeo1 for the time being?

For now I'm planning to migrate the LDAP server only - at least as a
first step. I assume the admin scripts should be migrated together
with the web server where they're hosted, since the "secure" VM doesn't
have a web server and I'd appreciate if this status remains unchanged.

Cheers,
  Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--------------------------------------------------------------------------

Does the ldap.osgeo.org DNS entry have a relatively low TTL? If not I
guess it's not a big deal; update scripts just won't work until that
server gets new entry. Degree of confusion would depend on error mode
:slight_smile:

On 2011-05-21, Martin Spott <Martin.Spott@mgras.net> wrote:

Hi folks,
I'm planning to migrate the OSGeo LDAP server over to the "secure" VM
this Saturday evening (night), whereas the time of day referrs to
GMT+2. This process will include:

1.) Making the current LDAP directory non-writeable;
2.) pulling an LDIF dump;
3.) pushing this dump into the LDAP server on the "secure" VM;
4.) running a couple of tests/diffs on the new LDAP server;
5.) Updating the 'ldap.osgeo.org' DNS entry.

I'll try to identify as many places as possible in the Apache config on
'osgeo1' which still refer to 'localhost' as LDAP server, but it would
be better if people switch over to 'ldap.osgeo.org' beforehand - if they
didn't already do so.

Cheers,
  Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--------------------------------------------------------------------------
_______________________________________________
Sac mailing list
Sac@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/sac

Hi Jason,

On Sat, May 21, 2011 at 09:57:01AM -0700, Jason Birch wrote:

Does the ldap.osgeo.org DNS entry have a relatively low TTL?

Last time I looked at it the entire osgeo.org domain was having a TTL
og just one hour .... see:

jive: 18:58:27 ~> nslookup -type=soa osgeo.org
[...]
  serial = 2011021366
  refresh = 3600

Cheers,
  Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--------------------------------------------------------------------------

On Sat, May 21, 2011 at 08:40:06PM +0200, Martin Spott wrote:

On Sat, May 21, 2011 at 12:16:36PM +0200, Martin Spott wrote:

> I'm planning to migrate the OSGeo LDAP server over to the "secure" VM
> this Saturday evening (night), [...]

Migration ist starting now,

Migration finished, DNS propagation is in progress.

Meanwhile I'll start searching for those 'clients' - scripts and/or
machines - who still didn't use SSL encryption for LDAP access, since
unencrypted access is forbidden on the new server.

Cheers,
  Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--------------------------------------------------------------------------

On Sat, May 21, 2011 at 08:52:11PM +0200, Martin Spott wrote:

Migration finished, DNS propagation is in progress.

Propagation should have been finished approx. 40 minutes ago. It looks
like there's a problem with 'hyperquad'. Any more complaints, services
not working ?

Meanwhile I'll start searching for those 'clients' - scripts and/or
machines - who still didn't use SSL encryption for LDAP access, since
unencrypted access is forbidden on the new server.

Ok, I _think_ I've fixed everything in '/etc/httpd/' on 'osgeo1', most
notably the '/etc/httpd/conf.d/ldap_auth_url.inc', but also a couple of
other files which were still referring to unencrypted LDAP and/or
hardwired IP numbers.

Cheers,
  Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--------------------------------------------------------------------------

On Sat, May 21, 2011 at 10:48:14PM +0200, Martin Spott wrote:

On Sat, May 21, 2011 at 08:52:11PM +0200, Martin Spott wrote:

Propagation should have been finished approx. 40 minutes ago. It looks
like there's a problem with 'hyperquad'.

That's been a local LDAP configuration error on 'hyperquad': The OSGeo
SSL certificate wasn't updated to the new cert - which is now fixed.

> Meanwhile I'll start searching for those 'clients' - scripts and/or
> machines - who still didn't use SSL encryption for LDAP access, since
> unencrypted access is forbidden on the new server.

Ok, I _think_ I've fixed everything in '/etc/httpd/' on 'osgeo1', most
notably the '/etc/httpd/conf.d/ldap_auth_url.inc', but also a couple of
other files which were still referring to unencrypted LDAP and/or
hardwired IP numbers.

Ok, these should be working, Drupal appears to authenticate properly.

BUT: There's a couple of Python scripts in '/var/www/cgi-bin/' on
'osgeo1' which don't SSL-encrypt their LDAP connection. Does anyone
know from memory how to SSL-enable this Python stuff ?
I _seems_ to me that 'ldap.open(server)' works for unencrypted sessions
only and 'ldap.initialize("ldaps://+server)' is the way to go for
SSL-encryption - but I'm far from being certain .... mmmmh, seems that
'ldap.open' is deprecated anyway:

  http://www.python-ldap.org/doc/html/ldap.html

Anyone ?

I'll have to get up early on sunday (orchestra concert), thus I'll have
to go to bed now,

  Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--------------------------------------------------------------------------

On 11-05-21 05:43 PM, Martin Spott wrote:

BUT: There's a couple of Python scripts in '/var/www/cgi-bin/' on
'osgeo1' which don't SSL-encrypt their LDAP connection. Does anyone
know from memory how to SSL-enable this Python stuff ?
I _seems_ to me that 'ldap.open(server)' works for unencrypted sessions
only and 'ldap.initialize("ldaps://+server)' is the way to go for
SSL-encryption - but I'm far from being certain .... mmmmh, seems that
'ldap.open' is deprecated anyway:

   http://www.python-ldap.org/doc/html/ldap.html

Anyone ?

Martin,

I have check and _ldap.so is linked to SSL libraries which gives me hope.
I have tried tried:

>>> import ldap
>>> l = ldap.initialize( 'ldaps://ldap.osgeo.org' )
>>> print l
<ldap.ldapobject.SimpleLDAPObject instance at 0xb7ef4d4c>
>>> l.simple_bind_s('')
Traceback (most recent call last):
   File "<stdin>", line 1, in ?
   File "/usr/lib/python2.3/site-packages/ldap/ldapobject.py", line 175, in simple_bind_s
     msgid = self.simple_bind(who,cred,serverctrls,clientctrls)
   File "/usr/lib/python2.3/site-packages/ldap/ldapobject.py", line 169, in simple_bind
     return self._ldap_call(self._l.simple_bind,who,cred,serverctrls,clientctrls)
   File "/usr/lib/python2.3/site-packages/ldap/ldapobject.py", line 94, in _ldap_call
     result = func(*args,**kwargs)
ldap.SERVER_DOWN: {'info': 'error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed', 'desc': "Can't contact LDAP server"}
>>>

The comments about "SSL3_GET_SERVER_CERTIFICATE" is a mystery to me, but
perhaps you have an idea?

I also notice that the userid/password challenge implemented for all cgi's
in /var/www/cgi-bin/auth does not seem to work any more. For instance
try visiting:

   http://www.osgeo.org/cgi-bin/auth/ldap_web_search.py

This authentication is controlled by:

   /etc/httpd/conf.d/osgeouserid.conf

   <Directory /var/www/cgi-bin/auth>
       SSLRequireSSL
       AuthType Basic
       AuthName "OSGeo"
       AuthLDAPURL ldaps://ldap.osgeo.org:636/ou=people,dc=osgeo,dc=org?uid?sub?(objectClass=*)
       require valid-user
</Directory>

Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | Geospatial Programmer for Rent