[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Report from the DSA Team Sprint 2013-06

On Sat, Jun 22, 2013 at 3:05 PM, Martin Zobel-Helas <zobel@ftbfs.de> wrote:
> Hi,
> On Fri Jun 21, 2013 at 14:57:09 -0400, Brian Gupta wrote:
>> > o) User and Group Management:
>> >    Last year we estimated the number of active shell accounts to be on
>> >    the order of 50.000 over all users/hosts.  We still would like to
>> >    disable unused accounts as described in last year's summary mail
>> >    but nothing has happened to actually implement that.  Help welcome.
>> What kind of skills are required to help with this?
> in general: python know-how.
> in detail: We need to track users over all hosts, collect that
> information somewhere and need to integrate that data into 'ud'.

Ahh. That is not me. My scripting skills are limited to classic shell
scripting and ruby, and limited time to learn python at the moment.

>> > o) Configuration Management:
>> >    The DSA team uses several tools to help them maintain and monitor
>> >    Debian's infrastructure and to keep track of what systems there
>> >    are, how to access them if things go wrong, when to purchase new
>> >    warranty contracts and so on.  Currently information is kept in a
>> >    large number of different and not cross-referenced systems,
>> >    including the puppet git repository, LDAP, the nagios
>> >    configuration, our password database and a spreadsheet file.
>> >
>> >    The distributed nature of this setup makes it difficult to get a
>> >    good, consistent overview and to give other teams like the
>> >    auditor/asset tracking folks the information they require to do
>> >    their job.
>> >
>> >    We agreed upon one desired solution:  We would like to have one
>> >    location, presumably a git repository, that has all the information
>> >    we have about a VM or piece of hardware.  Parts of that data would
>> >    have to be encrypted to privileged information, but the majority of
>> >    it should be available publicly.  Systems like LDAP, our nagios and
>> >    parts of the puppet configuration should then get the data they
>> >    need from this new single source of truth.  This is going to be a
>> >    lot of work and it will probably take a long time to get there.  If
>> >    you would like to help please contact us.
>> I am involved with a project called "theforeman" which might be useful
>> as it integrates tightly with Puppet. http://theforeman.org/ It's
>> currently not part of Debian, but the project does build nightly debs,
>> and there is a general will to get forman into Debian. (PPAMAIN will
>> be a real big help here, since it's a fairly fast moving project and
>> having multiple version support within a single stable lifetime would
>> be strongly desired.)
>> Although it also can handle full provisioning of baremetal, VMs, and
>> cloud instances, I think the big win will be its puppet integration.
>> It provides an inventory service (central database of facts),
>> customizable metadata, puppet ENC facilities, support for multiple
>> Datacenters, RBAC, option LDAP integration for authentication, a rich
>> query/search interface, and robust puppet reporting capabilities. (The
>> Foreman team impressed the audience last PuppetConf when they
>> announced that they were the first ENC to support parameterized
>> classes.)
>> Another nice thing about Foreman is that it supports all versions of
>> Puppet going back to Puppet 0.24.4.
>> It's also very automatable since it has a REST API and CLI.
>> Bonus for me is that even though RedHat is now funding much of the
>> ongoing development, there is no single copyright holder, and it is
>> licensed GPLv3+. (So clearly DFSG compliant.)
>> I'm not sure if a tool like this fits into your plans for a "single
>> source of truth" since you mentioned git. But I strongly encourage you
>> to consider it, and would be happy to answer any questions you might
>> have, or discuss offline in IRC (bgupta@oftc).
> As alreday disussed on IRC yesterday, we are open to it, if you help us
> deploying it and if you can send patches for our config management. I
> see the problem that foreman will only scale well four our big hosting
> locations, where we can use the full set of features of foreman.

I am interested in helping. I'll follow up on IRC.

> Cheers,
> Martin
> --
>  Martin Zobel-Helas <zobel@debian.org>    Debian System Administrator
>  Debian & GNU/Linux Developer                       Debian Listmaster
>  http://about.me/zobel                               Debian Webmaster
>  GPG Fingerprint:  6B18 5642 8E41 EC89 3D5D  BDBB 53B1 AC6D B11B 627B

Reply to: