[SAC] We are one (with the LDAP)

Committees SAC mailing list
1

Thanks to hard work by Martin, and some fat-fingered operations by myself, upload.osgeo.org and download.osgeo.org now use OSGeo's LDAP to do their authentication business.

We still need to work out a script to shell-enable regular OSGeo LDAP users similar to ldap_create_user.py, but the list of users that we did have at the telascience LDAP has been migrated over.

Please let us know if you're having any trouble. I will try to update our documentation on how to enable a blade to use this later today or tomorrow.

Howard

2

On Fri, Mar 27, 2009 at 04:24:21PM -0500, Howard Butler wrote:

Thanks to hard work by Martin, and some fat-fingered operations by
myself, upload.osgeo.org and download.osgeo.org now use OSGeo's LDAP to
do their authentication business.

.... in the meantime I've also synced the configuration to the .215
and .216 machines.

We still need to work out a script to shell-enable regular OSGeo LDAP
users similar to ldap_create_user.py, but the list of users that we did
have at the telascience LDAP has been migrated over.

I might take care for creating a little job that allows to shell-enable
an _individual_ user .... but for the sake of consistency I propose to
add the required attributes right on user creation on
'ldap_create_user.py'.

Please let us know if you're having any trouble. I will try to update
our documentation on how to enable a blade to use this later today or
tomorrow.

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

3

Hi,

2009/3/27 Howard Butler <hobu.inc@gmail.com>:

Thanks to hard work by Martin, and some fat-fingered operations by myself,
upload.osgeo.org and download.osgeo.org now use OSGeo's LDAP to do their
authentication business.

We still need to work out a script to shell-enable regular OSGeo LDAP users
similar to ldap_create_user.py, but the list of users that we did have at
the telascience LDAP has been migrated over.

Please let us know if you're having any trouble. I will try to update our
documentation on how to enable a blade to use this later today or tomorrow.

probably my account hasn't been migrated

martin@kacenka:~$ ssh martinl@grass.osgeo.org
martinl@grass.osgeo.org's password:
You must be a uniquemember of cn=telascience,ou=Shell,dc=osgeo,dc=org to login.
Connection closed by 198.202.74.219

Martin

--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa

4

Howard Butler wrote:

Thanks to hard work by Martin, and some fat-fingered operations by myself, upload.osgeo.org and download.osgeo.org now use OSGeo's LDAP to do their authentication business.

Howard / Martin,

I'm still quite confused by how all this is working now. I had manually
created many accounts on upload.osgeo.org. Are those no longer working?
Is sudo access still available to the folks who had it before? Any
thoughts on why cronjobs aren't working (noted by Markus and I)?

Please feel free to refer me to wiki docs on the new configuration if they
exist now.

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

5

Hi Frank,

On Sat, Mar 28, 2009 at 11:30:42AM -0400, Frank Warmerdam wrote:

I'm still quite confused by how all this is working now. I had manually
created many accounts on upload.osgeo.org.

That sounds a bit unfortunate as we've been recovering the numeric
UID's from Telascience LDAP and you apparently have been introducing
new ones. To which schema have you been referring while creating
accounts, which ones are new, how are we supposed to get them synced ?

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

6

Hi,

2009/3/28 Martin Landa <landa.martin@gmail.com>:

Please let us know if you're having any trouble. I will try to update our
documentation on how to enable a blade to use this later today or tomorrow.

probably my account hasn't been migrated

martin@kacenka:~$ ssh martinl@grass.osgeo.org
martinl@grass.osgeo.org's password:
You must be a uniquemember of cn=telascience,ou=Shell,dc=osgeo,dc=org to login.
Connection closed by 198.202.74.219

now I can login, thanks MartinS!

Martin

--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa

7

Hi,

On Sat, Mar 28, 2009 at 01:18:08PM +0100, Martin Landa wrote:

probably my account hasn't been migrated

martin@kacenka:~$ ssh martinl@grass.osgeo.org
martinl@grass.osgeo.org's password:
You must be a uniquemember of cn=telascience,ou=Shell,dc=osgeo,dc=org to login.
Connection closed by 198.202.74.219

Please check - added to OSGeo LDAP, removed from the local
passwd/shadow/group.

BTW, while looking at the '/etc/sudoers' file on 'upload', it looks to
me that the most convenient solution would be to remove all the user
accounts and have everyone use the 'root' login .... Is this
consistent with "The Plan" ?

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

8

Hi,

2009/3/28 Martin Spott <Martin.Spott@mgras.net>:

martin@kacenka:~$ ssh martinl@grass.osgeo.org
martinl@grass.osgeo.org's password:
You must be a uniquemember of cn=telascience,ou=Shell,dc=osgeo,dc=org to login.
Connection closed by 198.202.74.219

Please check - added to OSGeo LDAP, removed from the local
passwd/shadow/group.

yes, works. Thanks! Martin

--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa

9

Martin Spott wrote:

Hi Frank,

On Sat, Mar 28, 2009 at 11:30:42AM -0400, Frank Warmerdam wrote:

I'm still quite confused by how all this is working now. I had manually
created many accounts on upload.osgeo.org.

That sounds a bit unfortunate as we've been recovering the numeric
UID's from Telascience LDAP and you apparently have been introducing
new ones.

Martin,

I'm speaking of the accounts created over the last 24 months or so,
not since the recent LDAP breakdown.

To which schema have you been referring while creating
accounts, which ones are new, how are we supposed to get them synced ?

I do not refer to any schema. I never asked for them to be synced or
added to LDAP. In fact, I had come to the conclusion that there was
really little need for LDAP on the telascience blades, and if I had
been more available when this recent crisis struck I would have advised
against use of LDAP for blade accounts.

However, given that lots of good work has been done, I would like to understand
how it works, and how to bring things that were functioning fine (ie. local
accounts, cron jobs) back into operation.

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

10

On Sat, Mar 28, 2009 at 5:30 PM, Frank Warmerdam <warmerdam@pobox.com> wrote:
...

I'm still quite confused by how all this is working now. I had manually
created many accounts on upload.osgeo.org. Are those no longer working?
Is sudo access still available to the folks who had it before?

Looks like yes (ous work).

Any thoughts on why cronjobs aren't working (noted by Markus and I)?

Upon hint from MartinS in IRC I have tried them locally and discovered
that a target directory had changed owner. Changing that back to
the right owner made the cronjobs working again.

Markus

11

Frank,

On Sat, Mar 28, 2009 at 09:01:23PM -0400, Frank Warmerdam wrote:

Martin Spott wrote:

On Sat, Mar 28, 2009 at 11:30:42AM -0400, Frank Warmerdam wrote:

I'm still quite confused by how all this is working now. I had manually
created many accounts on upload.osgeo.org.

That sounds a bit unfortunate as we've been recovering the numeric
UID's from Telascience LDAP and you apparently have been introducing
new ones.

I'm speaking of the accounts created over the last 24 months or so,
not since the recent LDAP breakdown.

Ah, well. I had seen traces of different numerical UID's referring to
the same login on 'upload' ('martinl' being one example), therefore I
was under the assumption that new logins had also been added after the
Telascience LDAP crash. Please excuse me if I was wrong.

I do not refer to any schema. I never asked for them to be synced or
added to LDAP. In fact, I had come to the conclusion that there was
really little need for LDAP on the telascience blades, and if I had
been more available when this recent crisis struck I would have advised
against use of LDAP for blade accounts.

However, given that lots of good work has been done, I would like to understand
how it works, and how to bring things that were functioning fine (ie. local
accounts, cron jobs) back into operation.

Well, some of these machines (personally I know of four of them) had,
apparently, been configured to use a mix of local accounts _plus_
Telascience LDAP for a while, so there's nothing basically new we've
been introducing here.
"The work" that had been done recently was solely related to recovering
the Telascience LDAP accounts (at least most of them, I hope) from a
corrupt LDAP database and to merge their UID's, home directories and
login shells into OSGeo LDAP. This merge involved removal of approx.
half a dozend duplicates where users had a login name in Telascience
LDAP which differed from their login at OSGeo LDAP. OSGeo login names
had been choosen as a preference here.

That's all and does, in no way, affect the obvious disagreement over
how logins on the blade machines are supposed to be handled. I'll
happily stay out of the related discussion :slight_smile:

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