CentOS Web Infrastructre

1. Predictable Navigation

Web application links (like bugs, download, docs, forums ...) need to be always visible.

A section for relevant links (like Donate, HowTos, TipsAndTricks, Repositories ...) would be always visible at the end of each page.

Error messages coming from web server would be customized to provide, a common design, main web application links at page beginning, the error message itself, and the relevant links at page bottom.

Google Ads could be horizontally located over the logo and mainlinks.

2. Predictable URLs

Virtual domains are nice, and sometimes absolutely needed, but what about aliases ? For example:

• http://centos.org/

• http://centos.org/download/

• http://centos.org/doc/

• http://centos.org/wiki/

• http://centos.org/projects/

• http://centos.org/lists/

• http://centos.org/forum/

• ...

The above structure is for English site only. Sites in languages other than English would be in their own space, apart from English one. For example Spanish site urls would look like the following:

• http://centos.org/es/

• http://centos.org/es/download/

• http://centos.org/es/doc/

• http://centos.org/es/wiki/

• http://centos.org/es/lists/

• http://centos.org/es/forum/

• ...

Note: Aliases may give the possibility of using TLS through https:// in the whole centos.org domain and all web applications used under it.

Other combination to manage different languages could be to use both virtual domains and aliases together.

For example:

• http://es.centos.org/

• http://es.centos.org/download/

• http://es.centos.org/doc/

• http://es.centos.org/wiki/

• http://es.centos.org/lists/

• http://es.centos.org/forum/

• ...

In this case virtual domains are used to identify the site language and aliases to identify the application used.

3. Blueprint Structure

Specific language sites could be seen as an instance of a blueprint. The blueprint would be a set of customized software (and its dependencies [customized or not]).

Because each instance is built from the blueprint, any blueprint update may be propagated to each instance of it.

Software installed in each blueprint's instance may vary.

When you are installing the customization, customized software would have a higher priority than non-customized one.

4. Repository for customized packages

Our customizations could be backported into new released packages (or changes in new upstream packages could be backported into our customized packages) and then, the final packages, customized and updated, could be stored in a new repository that could be created for that specific purpose. That repository would be used as installation and update source for applications used in our web infrastructure. That repository would have customized packages from base, updates and RPMForge repositories.

Different customizations could be managed through a directory inside the repository. For example:

[artwork]
   |
   +--Mettle                           <-- customization tree #1
   |  `--mailman-2.1.9-4.el5
   |  `--moin-1.5.7-1.el5.rf
   |  `--httpd-2.2.3-11.el5_1.centos.3
   |
   +--TreeFlower                       <-- customization tree #2
   |  `--mailman-2.1.9-4.el5
   |  `--moin-1.5.7-1.el5.rf
   |  `--httpd-2.2.3-11.el5_1.centos.3
   |
   +-- ...                             <-- customization tree #n

This way it may be possible to handle which customization is installed or updated to via yum.

All this process will surely introduce more delay after upstream release, which my be not convenient. Some time will be needed to backport updates.

Even there aren't updates in our customizations for CentOS web infrastructure, packages in this repository will need to be updated as new releases come from upstream. Now it won't only be needed to rebuild and maintain the CentOS distribution itself but also the customized packages used in the web infrastructure.

It is also necessary to take special care with the stability of that new repository where customized packages will lay on. The whole CentOS web environment will be based on it. Quality Assurance is critical here too.

It would be nice if that repository is opened for RO world wide for anyone to use, study, test, ... and report bugs too. But this also permits discernment of an unpatched and exploitable version more easily, and mandates close scrutiny when a forked version from upstream tools _is_ used, or updates lag, as security may be compromised

This repository may be useful for all the free software community. Here we'll modify a few upstream packages (like httpd and mailman) and others from third party repos (like moin, and trac).

QUERY: This sounds like scope creep, and the wrong venue for such other than as demonstration projects ... and production infrastructure is not the place to be bleeding edge daring. -- Russ herrold

This is a common repository with specific common visual presentation. No matter what application from that repo you install, it will have a visual design that gears with other applications in the same repository.

Customizations should be in the user interface area mainly, just to archive a common design among all applications. Something similar to what CentOS does removing every upstream artwork or brand in the rebuild process. In this case it will be added a common design for all web applications used only. Of course, if you are completely sure of a bug while you are redesigning the user interface, it may no hurt anyone if you test it, and fix it and report it to the upstream application issue tracker.

The general idea would be to build a repository with a customized set of web applications that share a common visual design.

Additionally, an application could be provided to help in the process of making decisions like: I need a bug tracker but not a wiki, nor a project management. And also manipulate that things to activate/deactivate those options (included the web presentation of them) as needed.

5. Next Actions