[Labs-l] RFC: Webtools setup

[Platonides]

On 15/02/13 02:56, Tim Landscheidt wrote:
>>> Dependencies of tools on other software are specified ex-
>>> plicitely so that tools can be moved to other servers or
>>> servers can be split by other software needed (i. e., a
>>> server that only handles PHP, Ruby on Rails, etc.).  Depen-
>>> dencies can be different for development (command line) and
>>> deployment (web).
> 
>> This could be more complex to organise, since cli and web may still need
>> to be grouped in the same tool.
> 
> Hmmm.  What do you mean?

You talk about different prerequisites for parts of a tool, but both
would belong to the same tool.



>> This looks good, although I wonder if it's practical to ask users to add
>> puppet configuration for each tool. Maybe it could be templated to the
>> point where you only provide the tool name as a parameter to get all
>> those points.
> 
> I had imagined a workflow where a user asks an admin: "I
> want to create PHP tool TOOL!", and the admin then uses a
> template (or maybe even freehands).  This has the added
> bonus that the admin doesn't have to check whether the user-
> supplied puppet module is correct, but can rely on the cor-
> rectness of his own template.
> 
> It should be pretty easy to write a script that takes a tool
> name and submits a change of the puppet configuration to
> Gerrit, but I would wait with that until we're handling,
> say, dozens of new tools per day :-).

I would prefer not to require an admin in the process of creating a
tool. It should be possible to do through eg. a privileged helper.
Although if it's a standarised change, maybe it could be merged
automatically by jenkins.
Probably, most projects wouldn't need to be in puppet.


>>> My (first :-)) questions are:
> 
>>> - Can glusterfs handle local users and groups on
>>>   /data/project, or do we need to synchronize uids/gids?
> 
>> I'm not sure about what you mean. The tools uids should not collision
>> with the LDAP users, and we should have a central store of them. We
>> talked about this in irc some time ago, with no clear results. Although
>> I think it would be safe to start tool uids with eg. 50000.
> 
> The problem I see is that user TOOL on instance A creates a
> file on /data/project, and on instance B it must appear that
> this file belongs to user TOOL on that machine.  So either
> glusterfs must somehow handle this with some magic, or we
> have to synchronize users and groups project-wide so that
> user TOOL has uid 50000 on all instances.  The latter should
> be possible by changing the puppet module to check that
> "user TOOL exists with uid 50000", but if glusterfs had some
> automatic mapping that would be even greater.

Yes, of course it should be the same. But that's not the responsability
of the filesystem. That's why your mention of glusterfs confused me.


Ryan Lane wrote:
> Note that project groups are 50000+ right now. 
Seems you also thought it was a good range for `projects` :)
40000 or 60000 would work, too.

> Maybe we should have some ranges defined somewhere in puppet?

Please do.

Currently group ids seem to be:
wikidev: 500
General groups (svnadm, ops, wmf): 1001-1005
labs projects: 50062-50376

And user ids go 500-582, 1005-2878


Tim Landscheidt wrote:
> I think LDAP accounts would open up lots of new security
> questions.  The users only need to exist on the instances of
> the Webtools project, and so local accounts should be
> enough.

Those are not local accounts, since they should be shared through the
several instances of the webtools project.
I thought about setting up nis for that, but it would be better if those
uids were also handled by ldap.
Not being on that project group, those 'users' couldn't join to other
projects. Maybe a problem would appear if we created an project with the
same name as used later by an ubuntu package. We could prefix with
"tool-" the tool names to avoid that, although that'd be uglier IMHO.