" Would prefer if this ran on just dcufm.redbrick.dcu.ie so please suggest if any changes can be made in the config to fix this."

Can this not be reverse proxied and the host changed to something internally listening on a local port while the nginx/apache whatever proxies to this.

For the icecase piece, since the listening piece would return a different response, you can https://httpd.apache.org/docs/2.4/mod/mod_substitute.html and replace the response content.

have we confirmed with dcufm what port they connect to?
I've not touched icecast in a while but I do remember weirdness in apache proxy
there should already be an apache proxy though

http://lists.xiph.org/pipermail/icecast/2004-July/007384.html This email outlines the issue but no solution

Regarding reverse proxy @benmcmahon100 commented this on the issue a while back #6 (comment)

currently, dcufm appears to be on its own ip and bound to port 80 on that ip. i believe this is the better route to go

Name:   dcufm.redbrick.dcu.ie
Address: 136.206.15.74

Where can we put this?

Once it's done and I switch it to port 80 I can just switch the DNS and they should be okay. I'll still test it out though.

2 other things:

* Is it possible that we can test putting this behind a HTTPS proxy and seeing if butt handles the connection upgrade (ie connect on port 80) correctly?

I'm just getting around to reading this now - yes I can try this out and see if butt handles it.

* The problem with using lib.fileContents to read the password files is that the config for the service will be world readable inside the nix store, which is easy to find through `find /nix/store -name icecast`. The usual solution to this problem is to read the necessary secrets at runtime (ie with the SystemD service), and do part of the templating in the service init. This is usually covered by the module author but it seems the icecast module writer was lazy. For the sake of keeping things secure I'd like us to do something like this. I can't think of examples of this outside of gitea but I can certainly find one. Without this any user that can ssh to the box running icecast (admin or not) will be able to read the passwords in its config which is not ideal.

Yes I think we've had some conversation about this before. Could be best to introduce a vault service to write them before services start.

https://github.com/markuslindenberg/icecast_exporter <- lets get some metrics

Took longer than expected but I've tested this now. The central Icecast config works, I'll make all requested changes above to it.

I'll take care of anything related to apache. This will exist at dcufm.redbrick.dcu.ie on port 80 on it's own IP as it currently does, that way we just need to switch DNS and they should see no real difference.

Important point here - when this gets merged (whenever that is) leave the merge and subsequent redeploy to me, want to make sure all runs smoothly in FM on their side too.