[Dune-devel] Future of the Heidelberg-hosted Dune infrastructure

Markus Blatt markus at dr-blatt.de
Fri Nov 22 08:03:20 CET 2019


Hi,

I could help with DNS. I am hoping to be around for a few years.

On Thu, Nov 21, 2019 at 09:04:49PM +0100, Oliver Sander wrote:
> Hi,
> 
> > gitlab.dune-project.org <http://gitlab.dune-project.org>
> > -----------------------
> 
> we (the TU Dresden School of Science) may be able to host and maintain a dedicated
> gitlab instance for Dune.  Give me a few days to check this.
>

I think the old URLs could be used in that case. The DNS entry needs to point to my server
and I configure my webserver to tell browers to redirect permanently. Of course going to
gitlab means that if we ever want to self host again, then there is probably no way of
redirecting to us.

I do not have strong opinions against gitlab.com if it suffices, at least if we get the
Enterprise edition for free (could you check that?). Selfhosting sounds nice but currently
I lack the manpower and am still wondering whether it is worth to increase it, how hard that
would be and how costly. if Dresde does it, perfect.

> 
> > Mailserver for @dune-project.org <http://dune-project.org>
> > --------------------------------
> > The mailserver that receives mail addressed to @dune-project.org <http://dune-project.org> is running on our webserver.
> > This is mainly used for admin mails from Gitlab and signups at services like Let's encrypt, Cloudflare etc.
> > Personalized email addresses @dune-project.org <http://dune-project.org> have been given out in the past, but are rarely used.
> >

If that helps I can setup my mailserver to redirect the non-personal emails and some of the others. That should not be to hard.

> > Heidelberg opinion:
> > Those email addresses seem to be rarely used and could be removed without harm. 
>

Cheers,

Markus

> That sounds like a good idea to me.
> 
> Best regards,
> Oliver
> 
> 
> Alternatively, we could move the
> > mail services to some external, cloud-hosted platform if there is someone willing to take care of it.
> > 
> > Website dune-project.org <http://dune-project.org>
> > ------------------------
> > The website is currently hosted on the group webserver and the deployment process is managed by Gitlab CI.
> > 
> > Heidelberg opinion:
> > We can continue hosting the website, but it might also be a good idea to offload that task to an external service
> > to improve reliability and uptime.
> > 
> > One idea (if moving to gitlab.com <http://gitlab.com>) would be to use Gitlab pages, which allows to serve static websites
> > (cf. https://about.gitlab.com/blog/2016/04/07/gitlab-pages-setup) and is free.
> > The deployment process could stay in Gitlab CI and we can continue to provide the runner that
> > performs this specific task (we need it anyway because our group website works similar).
> > 
> > Continuous Integration
> > ----------------------
> > Currently, several groups contribute hardware to the Dune CI system by registering runners to our Gitlab instance.
> > The Heidelberg group also contributes 4 servers to this system.
> > 
> > Heidelberg opinion:
> > The distributed nature of the CI system is well-suited for the future.
> > We will continue to provide this hardware but restructure our servers to remove some moving parts.
> > 
> > Docker in Docker Continuous Integration
> > ---------------------------------------
> > The build process for Docker images from the repository https://gitlab.dune-project.org/docker/ci
> > is a very special CI job, as it requires a Docker in Docker setup on the runner side.
> > Such setups are prone to security issues as malicious code could escape the Docker sandbox.
> > We currently provide this runner in Heidelberg.
> > 
> > Heidelberg opinion:
> > While we can continue to provide this service for the immediate future, we would love to not have to maintain
> > the DinD-setup anymore.
> > We consider it worthwhile to move the building of Docker images to a dedicated service. There are multiple options
> > here that would work and that would need discussing. Using external services at the Dune scale is not free,
> > but neither is maintaining the process at university.
> > 
> > DNS for dune-project.org <http://dune-project.org>
> > ------------------------
> > The domain dune-project.org <http://dune-project.org> is registered to Peter with the registrar domaindiscount24.de <http://domaindiscount24.de>. The
> > actual DNS servers are delegated to Cloudflare. This was done to use DNS validation for obtaining
> > Let's Encrypt certificates, but could be moved back to domaindiscount24.com <http://domaindiscount24.com> again. Peter will continue
> > to provide the domain and pay the yearly fee, but we would like to have an additional person with a bit
> > of knowledge about DNS available when there are problems like the recent mailing list outage, which required
> > changes to the DNS server.
> > 
> > 
> > We hope that this email serves as a basis for fruitful discussion.
> > If discussion becomes unwieldy, we propose to have a telephone conference to resolve these issues more easily.
> > 
> > Best regards from Heidelberg,
> > Peter, Steffen and Dominic
> > 
> > 
> > _______________________________________________
> > Dune-devel mailing list
> > Dune-devel at lists.dune-project.org
> > https://lists.dune-project.org/mailman/listinfo/dune-devel
> > 
> 
> _______________________________________________
> Dune-devel mailing list
> Dune-devel at lists.dune-project.org
> https://lists.dune-project.org/mailman/listinfo/dune-devel

-- 
Dr. Markus Blatt - HPC-Simulation-Software & Services http://www.dr-blatt.de
Pedettistr. 38, 85072 Eichstätt, Germany,  USt-Id: DE279960836
Tel.: +49 (0) 160 97590858
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.dune-project.org/pipermail/dune-devel/attachments/20191122/e337c368/attachment.sig>


More information about the Dune-devel mailing list