[Fosshost] Project overview

In the last developer meeting, we decided to move most of our current web infrastructure to the recently sponsored Fosshost machine.

Documentation at https://github.com/gnu-octave/doc.

:checkered_flag: Finished :tada: :

:gear: In Progress:

:sweat: ToDo:

  • done :desert:

:x: Won’t Do:

  • planet.octave.org ? Really used by anyone anymore? Only the aggregator is turned off, the original blogs remain untouched.


Most of this work can only be done by @jwe :

  • [dreamhost] =
  • [fosshost] =
  • [unknown1] =

A records

X.octave.org points to plan state
agora [unknown1] keep :white_check_mark:
fosshost [fosshost] keep :white_check_mark:
planet [dreamhost] delete :white_check_mark:

CNAME records

X.octave.org points to plan state
agora-new agora.octave.org delete :white_check_mark:
buildbot agora.octave.org keep :white_check_mark:
bugs A record fosshost.octave.org :white_check_mark:
docs A record fosshost.octave.org :white_check_mark:
ftp ftp.gnu.org fosshost.octave.org :white_check_mark:
hg agora.octave.org fosshost.octave.org :white_check_mark:
hg-new agora.octave.org delete :white_check_mark:
packages A record fosshost.octave.org :white_check_mark:
wiki A record fosshost.octave.org :white_check_mark:
www A record fosshost.octave.org :white_check_mark:

I can see that you are making a lot of changes. Best wishes.

@jwe I updated the plan for what to do with all those subdomains around octave.org.

If you agree, you can start deleting all rows with “plan delete”.

The next candidate which is ready to move is the wiki. Please redirect it from now, whenever you have time. If this project succeeds, I would like to progress with hg.

1 Like

@jwe can you clarify how do you manage push permissions to hg.octave.org? The official guide PublishingRepositories - Mercurial looks different to what is used to me :thinking:

Are there any cronjobs for updating the Octave repository mirror I have to apply?

I started editing the DNS records. Some can’t be edited (autoconfig, *.jabber, www.*, ssh, ssh.*), so I guess they are automatically provided by dreamhost. Some of those appear to be created because things like wiki.octave.org were set up as separate subdomains for hosting purposes so when those are converted to A records, the corresponding www.wiki and ssh.wiki DNS records will go away.

The one significant change I’ve made so far is to change wiki.octave.org from a subdomain hosted at dreamhost to an A record (, the fosshost site). I’m now seeing the new DNS record and connecting appears to work. I saw a certificate error when I first connected, but I assume that is temporary.

Is there some reason to prefer using A records for the bugs, docs, hg, wiki, etc. subdomains instead of using CNAME records that point to a single A record for fosshost.octave.org?

1 Like

We don’t allow write access to the hg archives with https. You have to use ssh. I think Jordi set it up. It appears to have all the archives under a single user ID and access is controlled with the hg-ssh script and using a command= option in the shared user’s ~/.ssh/authorized_keys file. If there is a better way, now would be a good time to switch, so I’d say set it up in whatever way is best.

Yes, there is a cron job running every 10 minutes that executes a script to update hg.octave.org/octave from http://hg.savannah.gnu.org/hgweb/octave. Brute force, but I guess it usually works. Again, if there is a better way, we can do whatever is needed.

1 Like

Thank you for those many updates :slightly_smiling_face:

Yes, this should be resolved now if you close and reopen your browser.

To my humble knowledge, CNAMEs can only refer to subdomains of the same IP address. As we are currently stuck between two servers with different IP addresses, I thought this is the safest option and does not really hurt in praxis. But feel free to convert subdomains of the same IP address to CNAME records. Please edit my first post accordingly.

Thanks, I will take a look at the hg pushing and setup a cronjob.

Further, are docs and bugs already available at FossHost?

Other than the wiki, I didn’t know which services were ready on fosshost. If docs and bugs are ready now, I can switch them.

I made bugs.octave.org, docs.octave.org, and wiki.octave.org CNAME records pointing to fosshost.octave.org. The fosshost.octave.org name is still an A record. This way, if we move the entire collection of services to some new place or the IP address of our machine on FossHost changes, we only have to update the one A record.

Let me know when you are ready for any other DNS changes.

I’m also uploading the script used on the current hg.octave.org to mirror the Octave sources from savannah. It looks like we used to have the Mercurial archives on Dreamhost and some parts of the script might not be needed now.

hg-update (1.2 KB)

1 Like

I’m getting a problem accessing bugs.octave.org: it either redirects to wiki.octave.org or it gives me a warning about a security certificate which is not valid for bugs.octave.org:

Websites prove their identity via certificates. Firefox does not trust this site because it uses a certificate that is not valid for bugs.octave.org. The certificate is only valid for the following names: fosshost.octave.org, hg.octave.space, wiki.octave.org

How to trigger: Visit this page: Bugs and click the link at the top that says “browse recent bugs”.

Yes this is unfortunate, but expected. I work on getting bugs.octave.org ready today as it is not a big project. In the meantime please visit GNU Octave - Bugs: Browse Items [Savannah] directly.

For docs.octave.org will be the new address for the User Manual and doxygen and current links will redirect there soon. As this address never existed before, there is no need for quick action :innocent:

1 Like

Both bugs.octave.org and docs.octave.org (empty) should work now without certificate errors.

@jwe can you confirm that the state of the first post now reflects what A and CNAME records shall become?

1 Like

Yes, both bugs and docs now go the intended place. Thanks, @siko1056!

I updated the table.

I’d like to move the buildbot server to fosshost. I can help with that configuration. hg.octave.org is also moving to fosshost. Once those things are done, agora.octave.org can be deleted and I’ll probably close my Digital Ocean account since I don’t have anything else hosted there.

What is needed to move packages.octave.org to fosshost? On dreamhost, it is just a couple of small .htaccess files. Once it is moved, I’ll delete the subdomain and make packages.octave.org a CNAME for fosshost.octave.org.

Two questions:

  • Will the buildbots be on the same VPS as the webserver? There was some initial reluctance to have them be on the same virtual machine but is that still the case?

  • I have it on my todo list to ask Fosshost for more vCPUs (News from octave.org: sponsors, code of conduct, and project governance - #15 by arungiridhar) but I didn’t want to do that while the services were being actively moved, and it’s also safer to do that after both of you get hypervisor access to the VM, not just me. What would be a good time to do that, wrt the buildbots?

I’m not planning to move the buildbot workers. The master server doesn’t require a lot of resources.

1 Like

Great I updated the top post.

Another question is agora.octave.org points to your home server where the buildbots are running? This address will remain in other words?

Some of the buildbot workers run on my personal systems but the buildbot master server (the part of buildbot that provides the web interface and scheduler) runs on a Digital Ocean system (primary name is agora.octave.org). The only thing I want to move to the fosshost server is what is running on the Digital Ocean system. The workers will remain as they are now.


Ready to move. After the move for a short time there will be again certificate errors. I hope this will affect users only for a short time.