public inbox for [email protected]  
help / color / mirror / Atom feed
Community accounts
6+ messages / 4 participants
[nested] [flat]

* Community accounts
@ 2008-03-12 19:10  Peter Eisentraut <[email protected]>
  0 siblings, 1 reply; 6+ messages in thread

From: Peter Eisentraut @ 2008-03-12 19:10 UTC (permalink / raw)
  To: pgsql-www

Are the "community accounts" (used by the wiki, for example) available to 
authenticate against from remote services, for example via LDAP?  I might 
like to use them for the Git service, for example.

Also, is there a plan for keeping "community" accounts, PgFoundry accounts, 
and developer.postgresql.org shell accounts the same, lest we create a big 
mess?



^ permalink  raw  reply  [nested|flat] 6+ messages in thread

* Re: Community accounts
@ 2008-03-12 19:27  Dave Page <[email protected]>
  parent: Peter Eisentraut <[email protected]>
  0 siblings, 1 reply; 6+ messages in thread

From: Dave Page @ 2008-03-12 19:27 UTC (permalink / raw)
  To: Peter Eisentraut <[email protected]>; +Cc: pgsql-www

On Wed, Mar 12, 2008 at 7:10 PM, Peter Eisentraut <[email protected]> wrote:
> Are the "community accounts" (used by the wiki, for example) available to
> authenticate against from remote services, for example via LDAP?  I might
> like to use them for the Git service, for example.

Not yet - the Wiki is the fisrt truly external resource to be
integrated, and although we did consider LDAP and OpenID, in the end
we decided that a custom auth plugin for mediawiki using the backend
database API via SSL connection was the least painful option.

We could certainly look at LDAP/OpenID more closely though.

> Also, is there a plan for keeping "community" accounts, PgFoundry accounts,
> and developer.postgresql.org shell accounts the same, lest we create a big
> mess?

I'm certainly interested in doing so for pgFoundry if we can figure
out how given the interaction between the GForge and OS
authentication. I'm not so wild about the developer shell accounts as
we've actually only got a handful of those left anyway - and most are
for the sysadmin team who don't necessarily want centralised
authentication in case something goes horribly wrong leaving the
entire domain inaccessible.

-- 
Dave Page
EnterpriseDB UK Ltd: http://www.enterprisedb.com
PostgreSQL UK 2008 Conference: http://www.postgresql.org.uk



^ permalink  raw  reply  [nested|flat] 6+ messages in thread

* Re: Community accounts
@ 2008-03-12 21:03  Magnus Hagander <[email protected]>
  parent: Dave Page <[email protected]>
  0 siblings, 1 reply; 6+ messages in thread

From: Magnus Hagander @ 2008-03-12 21:03 UTC (permalink / raw)
  To: Dave Page <[email protected]>; +Cc: Peter Eisentraut <[email protected]>; pgsql-www


On Wed, 2008-03-12 at 19:27 +0000, Dave Page wrote:
> On Wed, Mar 12, 2008 at 7:10 PM, Peter Eisentraut <[email protected]> wrote:
> > Are the "community accounts" (used by the wiki, for example) available to
> > authenticate against from remote services, for example via LDAP?  I might
> > like to use them for the Git service, for example.
> 
> Not yet - the Wiki is the fisrt truly external resource to be
> integrated, and although we did consider LDAP and OpenID, in the end
> we decided that a custom auth plugin for mediawiki using the backend
> database API via SSL connection was the least painful option.
> 
> We could certainly look at LDAP/OpenID more closely though.

Absolutely. The idea is to make it available to all services that could
use them. What options are available for GIT?

LDAP is probably the most complex of available protocols for something
as simple as authentication, but if that's all it can do, we could
certainly look at the possibility.


> > Also, is there a plan for keeping "community" accounts, PgFoundry accounts,
> > and developer.postgresql.org shell accounts the same, lest we create a big
> > mess?
> 
> I'm certainly interested in doing so for pgFoundry if we can figure
> out how given the interaction between the GForge and OS
> authentication. I'm not so wild about the developer shell accounts as
> we've actually only got a handful of those left anyway - and most are
> for the sysadmin team who don't necessarily want centralised
> authentication in case something goes horribly wrong leaving the
> entire domain inaccessible.

+1 on both those.

//Magnus



^ permalink  raw  reply  [nested|flat] 6+ messages in thread

* Re: Community accounts
@ 2008-03-12 21:39  Peter Eisentraut <[email protected]>
  parent: Magnus Hagander <[email protected]>
  0 siblings, 1 reply; 6+ messages in thread

From: Peter Eisentraut @ 2008-03-12 21:39 UTC (permalink / raw)
  To: pgsql-www; +Cc: Magnus Hagander <[email protected]>; Dave Page <[email protected]>

Magnus Hagander wrote:
> The idea is to make it available to all services that could
> use them. What options are available for GIT?

It's all shell accounts.  So something like PAM or whatever FreeBSD does would 
do the job.



^ permalink  raw  reply  [nested|flat] 6+ messages in thread

* Re: Community accounts
@ 2008-03-12 22:01  Magnus Hagander <[email protected]>
  parent: Peter Eisentraut <[email protected]>
  0 siblings, 1 reply; 6+ messages in thread

From: Magnus Hagander @ 2008-03-12 22:01 UTC (permalink / raw)
  To: Peter Eisentraut <[email protected]>; +Cc: pgsql-www; Dave Page <[email protected]>


On Wed, 2008-03-12 at 22:39 +0100, Peter Eisentraut wrote:
> Magnus Hagander wrote:
> > The idea is to make it available to all services that could
> > use them. What options are available for GIT?
> 
> It's all shell accounts.  So something like PAM or whatever FreeBSD does would 
> do the job.

Oh, yuck. You'd need some other level of authorization as well then,
because we certainly don't want to add all our community users as shell
users IMHO. In fact, I wouldn't add any users other than those that
absolutely need it...

//Magnus




^ permalink  raw  reply  [nested|flat] 6+ messages in thread

* Re: Community accounts
@ 2008-03-12 22:04  Joshua D. Drake <[email protected]>
  parent: Magnus Hagander <[email protected]>
  0 siblings, 0 replies; 6+ messages in thread

From: Joshua D. Drake @ 2008-03-12 22:04 UTC (permalink / raw)
  To: Magnus Hagander <[email protected]>; +Cc: Peter Eisentraut <[email protected]>; pgsql-www; Dave Page <[email protected]>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, 12 Mar 2008 23:01:49 +0100
Magnus Hagander <[email protected]> wrote:

> 
> On Wed, 2008-03-12 at 22:39 +0100, Peter Eisentraut wrote:
> > Magnus Hagander wrote:
> > > The idea is to make it available to all services that could
> > > use them. What options are available for GIT?
> > 
> > It's all shell accounts.  So something like PAM or whatever FreeBSD
> > does would do the job.
> 
> Oh, yuck. You'd need some other level of authorization as well then,
> because we certainly don't want to add all our community users as
> shell users IMHO. In fact, I wouldn't add any users other than those
> that absolutely need it...

Pam can auth off PG.

Joshua D. Drake


- -- 
The PostgreSQL Company since 1997: http://www.commandprompt.com/ 
PostgreSQL Community Conference: http://www.postgresqlconference.org/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
      PostgreSQL political pundit | Mocker of Dolphins

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFH2FN+ATb/zqfZUUQRAsiSAJ44jwXjIJfus3p6apZ3hgRhl2AxbACgo1OQ
hRhffrojQusVUXxjH0EnXfs=
=bn+C
-----END PGP SIGNATURE-----


^ permalink  raw  reply  [nested|flat] 6+ messages in thread


end of thread, other threads:[~2008-03-12 22:04 UTC | newest]

Thread overview: 6+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2008-03-12 19:10 Community accounts Peter Eisentraut <[email protected]>
2008-03-12 19:27 ` Dave Page <[email protected]>
2008-03-12 21:03   ` Magnus Hagander <[email protected]>
2008-03-12 21:39     ` Peter Eisentraut <[email protected]>
2008-03-12 22:01       ` Magnus Hagander <[email protected]>
2008-03-12 22:04         ` Joshua D. Drake <[email protected]>

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox