[SAC] Download maintainers group

Hi,

I think it would be reasonable to create dedicated group of users who
have access to maintain /osgeo/download content. Currently, it's a bit
messed and some project members who want to maintain their downloads
have to use sudo or ask someone who can do it or fix
permissions for them. So, IMO it's reasonable to set things in order here.

My suggestion is to create a group and assign one person from each OSGeo
project to this group. Then /osgeo/download should be owned by root and
writable by the 'download' group. Read-only others.

Does it make sense?

Cheers
--
Mateusz Loskot
http://mateusz.loskot.net

Mateusz Loskot wrote:

I think it would be reasonable to create dedicated group of users who
have access to maintain /osgeo/download content. Currently, it's a bit
messed and some project members who want to maintain their downloads
have to use sudo or ask someone who can do it or fix
permissions for them. So, IMO it's reasonable to set things in order here.

My suggestion is to create a group and assign one person from each OSGeo
project to this group. Then /osgeo/download should be owned by root and
writable by the 'download' group. Read-only others.

Sounds like a good idea to me. Perhaps we could leave the flexibility of having more than one person per project in the downloads group (to act as backup if the main person is not available), but we should definitely not open that up to too many people either.

Daniel
--
Daniel Morissette
http://www.mapgears.com/

Daniel Morissette wrote:

Mateusz Loskot wrote:

I think it would be reasonable to create dedicated group of users who
have access to maintain /osgeo/download content. Currently, it's a bit
messed and some project members who want to maintain their downloads
have to use sudo or ask someone who can do it or fix
permissions for them. So, IMO it's reasonable to set things in order here.

My suggestion is to create a group and assign one person from each OSGeo
project to this group. Then /osgeo/download should be owned by root and
writable by the 'download' group. Read-only others.

Sounds like a good idea to me. Perhaps we could leave the flexibility of having more than one person per project in the downloads group (to act as backup if the main person is not available), but we should definitely not open that up to too many people either.

Folks,

Why not create a group per project if we want to manage this with local
(rather than ldap based) groups?

I'm not sure why we didn't do this sooner, other than we had a hope of
a more LDAP based approach.

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 | President OSGeo, http://osgeo.org

Frank Warmerdam wrote:

Daniel Morissette wrote:

Mateusz Loskot wrote:

I think it would be reasonable to create dedicated group of users who
have access to maintain /osgeo/download content. Currently, it's a bit
messed and some project members who want to maintain their downloads
have to use sudo or ask someone who can do it or fix
permissions for them. So, IMO it's reasonable to set things in order
here.

My suggestion is to create a group and assign one person from each OSGeo
project to this group. Then /osgeo/download should be owned by root and
writable by the 'download' group. Read-only others.

Sounds like a good idea to me. Perhaps we could leave the flexibility
of having more than one person per project in the downloads group (to
act as backup if the main person is not available), but we should
definitely not open that up to too many people either.

Folks,

Why not create a group per project if we want to manage this with local
(rather than ldap based) groups?

I'm not sure why we didn't do this sooner, other than we had a hope of
a more LDAP based approach.

Frank, Daniel,

I agree with keeping number of users limited or well controlled,
so I like the idea about group per project.

Cheers
--
Mateusz Loskot
http://mateusz.loskot.net