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,
-Drew