Friday 16 September, vers 11h, Sylvain Beucler tapota : > Hello, > > What do you think is the best way to manage some "super-admins" for > webpages? I mean, users that can edit all the webpages in a group > type, like members of group 'www' can for GNU projects webpages at > Savannah? > > Currently this is done via a trick - editing each project root's > passwd file. However I would like to move that to the system > /etc/passwd. > > I still can do it after the cron job, but that means the system will > take forever userdel/useradd'ing those super-users. > > Another option would be include some kind of hook in the backend. > > Or last, to support this kind of usage directly. > > Last time we mentioned the issues, ACLs was suggested as a > solution. Since ACLs cannot usually be applied for more than ~30 > users (and group 'www' has ~100), this is not a good solution > eventually :/
(Did I reply to this mail already?) I'm not sure there's any good solution for that. If I'm right, the problem is that you have to give access to ~100 users that belongs to group www to all homepage repositories of groups of the GNU group type. I'm not sure to understand how works your stuff currently. I do not even know if the backend still permits to create add users of the www group to webpages groups, like it worked in the past. But that was an ugly solution, anyway, causing all www groups to have more than ~100 users. I cannot think of any good solution. I think that I would go with the solution of creating a special user for members of the www group, by hand. This user would be added by a stupid backend script wrote only for the installation (a 3 line script using Savane.pm) to all homepage groups of groups of the GNU group type. At the same time, another 3 line script using Savane.pm would get the SSH public keys of every members of the www group and put it in the user .ssh/authorized_keys (obviously, this user account would not be managed via savane in any way, and it would not be allowed to create an account with such name). - Advantage: easy to put in production, easy to maintain (two 3 lines scripts) - Drawback: all members of the www group committing to the area of another group do their commit with a common username, making harder to track who did what. So I admit this solution is not perfect, but that's the least ugly I can think of. And maybe, somehow, it is possible to link the used ssh key with the user, inserting in the commit message the proper name. Or easier, you can say, by policy, that people have to put their login in their commit message. That should not be too hard to have everyone starting his commit message by 'username - blah blah blah because blah blah'. Regards, -- Mathieu Roy +---------------------------------------------------------------------+ | General Homepage: http://yeupou.coleumes.org/ | | Computing Homepage: http://alberich.coleumes.org/ | | Not a native english speaker: | | http://stock.coleumes.org/doc.php?i=/misc-files/flawed-english | +---------------------------------------------------------------------+ _______________________________________________ Savane-dev mailing list Savane-dev@gna.org https://mail.gna.org/listinfo/savane-dev
