Differences between revisions 2 and 3
Revision 2 as of 2015-02-21 20:01:09
Size: 3137
Editor: ?DamyanIvanov
Comment: not set in stone
Revision 3 as of 2015-02-23 17:51:29
Size: 3136
Editor: ?GregorHerrmann
Comment: typos
Deletions are marked like this. Additions are marked like this.
Line 19: Line 19:
 * avoid clalshes between the configs of the different projects  * avoid clashes between the configs of the different projects
Line 42: Line 42:
We already keep projects' configuration in separate files (AFAIK). What we possibly miss is the maintainer keys. Perhaps personal mail archives cab help here. A mail to debian-devel-announce may be needed at some point. That could also help in making projects change their client configuration to refer to kgb.debian.org instead of the three servers currently used. DNS aliasing seems possible (as long as projects' client configuration refers to kgb.*) for KGB-0 and KGB-1, but not KGB-2. We already keep projects' configuration in separate files (AFAIK). What we possibly miss is the maintainer keys. Perhaps personal mail archives can help here. A mail to debian-devel-announce may be needed at some point. That could also help in making projects change their client configuration to refer to kgb.debian.org instead of the three servers currently used. DNS aliasing seems possible (as long as projects' client configuration refers to kgb.*) for KGB-0 and KGB-1, but not KGB-2.

Moving KGB to a DSA-hosted server

Here are some notes about a possible approach to moving the KGB service to a DSA-hosted server.

Why

  • High availability
  • No need to mail the service administrators

Why not

  • different organisation. changes can be hard

How

KGB already supports conf.d/-style config snippets which makes it possible to separate the configuration of different projects. The hard parts are:

  • make sure that only the original submitter can alter the configuration of her project
  • avoid clashes between the configs of the different projects

All requests for changes need to be signed by a key in the debian keyring. The requests are sent to control@kgb.debian.org. Non-signed mails are ignored.

A procmail receipe is created for the control@kgb.debian.org mail, which stores the requests using unique names in /var/lib/kgb/requests. A new daemon process is created on the server polling the directory and serving the requests in the order they have arrived. That process verifies request signature, checks for conflicts and ensures that requests come from project maintainers. Results are stored under /etc/kgb-bot/conf.d/, named $project.conf. That file has one or more comments # Maintainer: <key-id> in it , showing who can make changes to the project's configuration.

After each request is processed, results are sent back to the sender and the bot is reloaded.

A new tool is created, kgb-project-admin which helps create and sign requests. It supports the following operations:

  • add-project
    • Prompts interactively for project name, IRC channel name, IRC network (oftc/freenode), password and whether to mirror the notifications to #CIA on freenode. Maintainer is assumed to be the user running the helper (via $DEB_FULL_NAME and $DEB_EMAIL).

  • add-maintainer <project> <maintainer>

  • remove-maintainer <project> <maintainer>

  • change-password <project>

    • Prompts for the new password
  • remove-project <project>

  • get-config <project>

  • more…?

Migration

We already keep projects' configuration in separate files (AFAIK). What we possibly miss is the maintainer keys. Perhaps personal mail archives can help here. A mail to debian-devel-announce may be needed at some point. That could also help in making projects change their client configuration to refer to kgb.debian.org instead of the three servers currently used. DNS aliasing seems possible (as long as projects' client configuration refers to kgb.*) for KGB-0 and KGB-1, but not KGB-2.

Work plan

  • Get in touch with the DSA and have their input on the overall mechanics
  • Implement the new request-serving process
  • Implement kgb-project-admin

  • Update the kgb-bot package and make it available for the stable distribution via backports
  • Request a new server from the DSA and install/configure everything
  • Migrate existing projects' configuration
  • Mail debian-devel-announce, add an entry for the developer news
  • Wait for people to migrate their client configurations
  • Stop the current bot instances