For network security it is desirable to have lab controllers which are on a private network shared with the test systems, but not exposed to wider networks (like the public internet). Currently Beaker expects to serve logs for in-progress jobs from the LC itself directly. That doesn't work if the Beaker users are on the public internet, since that requires the LC to also be exposed to the public internet for serving logs. As a short term solution Beaker should allow the admin to configure a "public" or "external" URL prefix for a lab controller, to be used when Beaker is generating a URL for serving LC logs. Then the admin can set up an alternate network interface/hostname/reverse proxy for their LC.
We should also do a quick audit to make sure there is nowhere else Beaker is using the LC FQDN to generate URLs shown to users (as opposed to test systems, which is of course expected).
Since it is needed to get beaker.fedoraproject.org fully up and running, perhaps it would be worth pulling into Beaker 19? Otherwise we can pencil it in for Beaker 20, and propose getting beaker.fedoraproject.org fully up and running as an upstream QA automation goal for the Fedora 22 release cycle.
Matt missed the original discussions with Fedora QA around this feature, so adding some additional details and context: * the Fedora Beaker lab systems aren't going to be accessible from the public internet * the Fedora Beaker lab controller hosts logs while a recipe is still running, so it *does* need to be accessible from the public internet * this means the Fedora LC(s) will need dual interfaces, one for communicating with the lab machines, one for communicating with the main Beaker server and serving up logs for in-progress recipes This doesn't currently work properly, as Beaker will render the URLs for in-progress recipe logs based on the internal interface that the LC uses to communicate with the lab machines. Those links will be broken, as that interface isn't generally accessible. The change needed on the Beaker side is to store an optional "external FQDN" for each lab controller, and use that to render the recipe log links if it is set (rather than the default behaviour of using the lab internal FQDN that test systems access).
I forgot that we already have URL_DOMAIN in /etc/beaker/labcontroller.conf, which lets you override the FQDN of the lab controller for the purpose of generating log URLs. It looks like that would be sufficient here (for the "short term" solution mentioned in comment 0... the long term solution is use Swift or similar) unless I have missed something?
Changing this to a docs bug, as not only did Tim miss it when first setting up beaker.fedoraproject.org, we did as well. Since there isn't a great place for this, my proposal is that we do a literal include of the default configuration files into the main docs, with some surrounding commentary explaining the conventions used to indicate defaults, etc.
http://gerrit.beaker-project.org/3986 I'm not really convinced that the literal-include'd config files will be at all useful or discoverable, but I don't have any better suggestions.
I(In reply to Dan Callaghan from comment #4) > I forgot that we already have URL_DOMAIN in /etc/beaker/labcontroller.conf, > which lets you override the FQDN of the lab controller for the purpose of > generating log URLs. > > It looks like that would be sufficient here (for the "short term" solution > mentioned in comment 0... the long term solution is use Swift or similar) > unless I have missed something? I'm pretty sure we tried that years ago and it didn't work but I'll give it a try. IIRC, that setting makes the difference between being able to access log URLS without manual URL changes and the clients being able to communicate with the lab controller. Will report back once I've given it a try
(In reply to Tim Flink from comment #7) > Will report back once I've given it a try Tim, did you have a chance to try this out yet? Are there some Ansible playbooks for the production beaker.fedoraproject.org which I could submit a patch for?
Converting this bug to be about including the shipped configs in the docs to make config options more discoverable, as per comment 5.
Visible in the development version of the docs here: https://beaker-project.org/docs-develop/admin-guide/config-files.html
Content looks good to me, but there's a display issue due to the narrow maximum viewport width in the beaker-project.org CSS - you have to scroll sideways to read the full descriptions of the configuration settings.
(In reply to Nick Coghlan from comment #11) Yeah, it's really because our monospace font is much fatter at the same size than the body font. I don't really want to bump up the body width in the Sphinx theme just for this one page. We could re-flow the comments in the config files to be narrow than 80 chars. I already re-wrote the entire file for Beaker 20 (so from an admin's PoV there will be an .rpmnew that is basically undiffable against the old one) so it won't hurt much to re-flow all the comments now...
It looks to me like reflowing at 70 chars would eliminate the sidescrolling, so that's probably worth doing.
I tried it at 70 chars but even that is not narrow enough! I think we should just leave this as is for now, I will look into updating the stylesheet for beaker-project.org because I think it is overdue. In particular using a different body font that is more legible and more closely matches the monospace font.
Beaker 20.0 has been released.