Simplifying hosting services (aka "breaking up the monolith")

Raymond Toy toy.raymond at
Wed Jan 12 05:13:01 UTC 2022

I support whatever changes you want to make that make your life easier.

I'll do whatever I need to do to make sure my stuff works with the new
scheme.  Just let me know (and give me a bit of time if it requires some
non-trivial effort on my part.)

On Tue, Jan 11, 2022 at 11:25 AM Erik Huelsmann <ehuels at> wrote:

> Hi,
> In 2021, has had two types of service interruptions:
> (1) mailing lists were not functioning correctly [while regular mail
> traffic seemed to be] an (2) deployment of project sites wasn't
> working. The latter only came to light recently, but seems to have
> existed for some time.
> Since I can remember (probably since the creation of the service) has
> hosted its project webpages on its main domain in a
> sub directory, which at times has been called /project/, or /projects/
> or even /p/. This setup mixes project hosting with hosting for the
> main site itself and restricts the tooling we can use to host the
> projects' websites. The reason for the sites not deploying well is
> that I've implemented a workaround in the past to be able to deploy
> projects using GitLab Pages while our deployment model (deploying to
> the /project/ subdirectory on the main domain) is out of line with
> what GitLab Pages were designed for.
> At the same time, our configuration is running with extensive sets of
> rewrite rules to keep historic URLs "working" and redirected to
> (hopefully) existing current URLs, which also extremely complicates
> our setup.
> In order to simplify our setup (and eliminate the deployment problems
> we're experiencing) and at the same time add support for requests like
> those from Marco who wants to be able to deploy sites for multiple
> projects under the same umbrella, I've decided I want to move
> projects' sites to their own (sub)domains. In the past I thought this
> would need to be subdomains along the lines of
> https://<project> Although that's a
> deployment model that would work with GitLab Pages, I've decided
> against it. I'll move the hosted projects to:
>    https://<project>
> (I acquired for this purpose this morning.)
> The setup I'm proposing is that we have a good look at the tons of
> rewrite rules we have currently in place and clean up the rewrite
> rules that we don't need anymore. Then, we create rewrite rules for
> the current project namespaces at
><project>/ to map to
> https://<project> There are a few projects which
> aren't using GitLab Pages to deploy their websites yet, mostly because
> they have no active maintainers. These projects will keep being served
> from their current locations on the filesystem of the
> host, but their content will be available through the new
> <project> URL space.
> Further change proposals in order to separate the mail flow for the
> mailing lists from the regular mail flow (and thereby further reducing
> integration between components) are upcoming, but I'll need to address
> one thing at a time (due to time constraints).
> Are there any comments, remarks, additions, things you want me to take
> into account with respect to the above?
> --
> Bye,
> Erik.
> -- Hosted accounting and ERP.
> Robust and Flexible. No vendor lock-in.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the clo-devel mailing list