From Mandriva Community Wiki

Specs for a simple, packaged system to deploy on Mandriva private mirrors.

Contents 1 Definitions 1.1 Resource 1.2 User (and user groups) 1.3 Protocols 2 Authentication and access control 2.1 Authentication 2.2 Access control 2.2.1 HTTP(S) (Apache httpd) 2.2.2 FTP (proftpd) 2.2.3 rsync 3 To do

Currently, we distribute our software in several distinct ways that are not necessarily obvious, neither simple (several servers, several protocols, several ways of checking whether a mirror is in sync or not).

This is a valid statement for public (anonymous) downloads as for private ones (Club, Store purchases, etc.). Moreover, the need to have Mandriva-owned distribution servers all around the planet urges us to have a specified, unique way of distributing our content.

We need a very simple distribution workflow where we provide to a master distribution system, in input:

• the resource to be distributed (the ISO, a set of rpms, a whole directory structure, etc.),
• the list of people allowed to access it,
• when the resource should be available,
• the protocols the resource should be available through (http/s, ftp, rsync, bittorrent, etc.),

This is then defined as a distribution rule: who (user) has access to what (resource) in what way (protocol) and when (time frame).

This distribution rule is provided to a master system, which is then replicated to slave systems. This would allow us to set up several servers all around the globe, in a single distribution scheme (see related Web Mirrors API topic).

[edit] Definitions

[edit] Resource

The resource may be specified as a file, or a directory (in this case, the distribution rule applies to the whole directory content). It may be provided to the master system through a direct file upload or through one of the handled protocols below.

The resource may then be available through a set of supported protocols.

[edit] User (and user groups)

A user is identified with a (username, password) id tuple. The username may be an email address.

A user group is a set of users. A special user group "everyone" with no user. Granting this group an access to a resource means the resource is anonymously available (no username required).

A user (or user group) may access to one or several distinct resources, through one of several protocols.

Typically, in our case, this part will rely on the User API.

[edit] Protocols

Protocols that should be supported for resource submission, as for resource availability are:

• ftp (proftpd, ?),
• rsync (rsyncd, ?),
• scp (sshd, ?),
• http, https (apache httpd, ?),
• other?

[edit] Authentication and access control

All server protocols we want to handle are served by distinct pieces of software.

The user sends to the server a request: get_resource( resource_id, username, password ).

[edit] Authentication

This is provided by a remote server, and no duplicate of the users list is to be made in full on each mirror: users credentials are imported from the user db server only on the user explicit request (formally done through a query to the authentication service).

We have a local script that handles that (and caches the result for a short time span if needed).

[edit] Access control

This is provided by the local mirror (as this is part of the distribution rule).

In this local mirror, we first have a master access control table, that will state, for each resource available, what conditions the user has to meet to access to it. This table is actually a replication of the same table available on the main master mirror.

Conditions may be:

• valid member of a specific group,
• specific email domain,
• time frame,
• other?

This table is updated everytime a new resource is added to the distribution system (or updated). It will be the reference for all other local services:

• either we can have a plug in in the file serving app that allows us to directly query this master table; that means, patching proftpd, http/s, rsync, etc. to understand this particular table (looks tricky);
• either we can translate this table contents in the native format expected by each file serving app, where relevant (looks better and safer in the long run).

TODO find solutions to implement this, in detail, for every services.

[edit] HTTP(S) (Apache httpd)

For instance, for Apache httpd, a (still somewhat complex) option would be:

• to use mod_authnz_external to authenticate the user, so we can ask a script (problem, this is slow);
• to tweak the configuration to call this module for a specific resource.

Note: yes, using mod_authnz_external may be slow/bad/whatever. But we have to stick to a solution like this one, unless a better global scheme is proposed, in regard of these requirements from the user authentication service:

• no forced full replication of user db contents outside of it,
• user information may only be imported and used on user's consent (thus explicitly requires username/login).

[edit] FTP (proftpd)

TBD

[edit] rsync

TBD

[edit] To do

• think of this one along with the Mirrors API.
• test this.
• alternatively, find a content distribution platform/service that just fits this draft spec.