Juju model proxy settings and motd-news

We have recently found that after setting up all intended juju charms, snap packages, and apt repositories utilizing proxy settings when running a cloud behind a corporate firewall with a corporate http/https proxy, there is a core ubuntu service that is not proxied, which is https://motd.ubuntu.com referenced within /etc/default/motd-news and /etc/update-motd.d/50-motd-news (part of the base-files package).

We typically use the juju-http{,s}-proxy, apt-http{,s}-proxy, and snap-http{,s}-proxy settings along with the no-proxy settings for each to ensure that snaps, apt, and juju charming downloads happen through the proper proxies. This leaves any other processes happening on the servers that need to communicate with corporate DNS API (infoblox), network API (cisco aci), etc to be done without need for proxying or impossibly sized no-proxy statements.

Temporarily, in my example case where a security team didn’t want to see the traffic if it wasn’t proxied, even if the port were dropped at the firewall, we have removed the unwanted traffic from the firewall by modifying the /etc/default/motd-news file to set ENABLED=0.

This was simply done using a string replacement iterated through juju run --all.

It brought me to thinking about whether the proper fix is for juju-http{,s}-proxy to provide proxy wrapping around /etc/update-motd.d/50-motd-news, whether there should be a bug against update-motd.d to allow for an additional proxy setting in it’s default-config file that could be modified by juju-model settings, or whether juju model-settings should grow a “disable-motd-news” (or “motd-news-url”) option to handle redirecting internally or disablement of motd-news.

What are some thoughts from the juju community?

Thank you,

My vote is that in a juju controlled environment, juju should control the MOTD as it does with any other part of the user/service environment, and there should be a juju-model entity for the actual text of the “news” section of the motd and the module should call back to a running controller to update it’s news section.

I’m a bit -1 on growing a config option for Juju for folks to have to actively manage. We don’t manage this type of setup on any services from the base image and anything on top of that is the charm’s responsibility. It’s the type of problem that just doesn’t scale.

Ideally motd would respect proxy settings on the host if it was set by the operator. If you want to turn it off in some fashion we would look more at a subordinate that’s intended for providing customization to the images (in this case turning it off so you don’t see the traffic) as a subordinate charm.

The one issue here is that Juju doesn’t currently have an idea of a charm that can be deployed “once per machine” and you have to know how to set it up in your model to avoid duplication, but that’s an open feature request/roadmap item vs a model config hack.