Open Hooverdan96 opened 1 year ago
Some more information:
OS package updates that are executed via zypper
(if I remember correctly, it is executed behind the scenes when triggered from the WebUI) seem to honor the /etc/sysconfig/proxy
entries, described here (albeit a 9 year old post):
https://www.claudiokuenzler.com/blog/515/use-opensuse-zypper-behind-with-http-proxy-authentication So, if that continues to be true (don't know why it wouldn't) then it's one less thing to worry about.
For the few remaining yum
commands that we have not been able to get rid of (yet), it seems to require a configuration file as described here:
https://www.linuxtechi.com/proxy-settings-yum-command-on-rhel-centos-servers/
I guess, since we're really using dnf-yum (or in OpenSUSE the dnf package), the proxy definition should be set up in a different configuration file under /etc/dnf/dnf.conf
(which incidentally already exists on the Rockstor image) as described here:
https://www.cyberciti.biz/faq/how-to-use-dnf-command-with-a-proxy-server-on-fedora/
I can do updates, what I can't do is install Rock-ons and activate license.
@paucorre Thanks. That confirms what I was thinking, that a proxy fix would be required for the Rock-on piece.
Thanks a lot for the find there, @Hooverdan96 ! Thanks @paucorre for the additional feedback and confirmation to @Hooverdan96.
@Hooverdan96, just a note from requests
's docs, it seems we would need to adjust these to make them work with HTTP basic auth that we use for the Stable updates:
https://requests.readthedocs.io/en/latest/user/advanced/#proxies
To use HTTP Basic Auth with your proxy, use the
http://user:password@host/
syntax in any of the above configuration entries:
@FroggyFlox, good point on the authentication, piece. In my "corporate" experience I have not encountered the requirement to maintain a user:password authentication, but maybe that was invisible to me (@paucorre's use case didn't seem to require one either). In any case, that would make it slightly more complicated (since the user/password combo should be stored encrypted somewhere in Rockstor and then be picked up) unless the proxy piece would be managed with explicit user/password in the config file (which we already know is not a good idea, therefore highly unlikely).
So maybe, baby steps, start just with an unauthenticated proxy and then progress to figuring out the other approaches? Or is it better to consider that in the design right away?
Forum member paulo.jncc raised this scenario here, where Rockstor does not respect global proxy settings, impacting the ability to activate a valid license and possibly other update scenarios (OS package and Rockon updates, which is still TBD).
https://forum.rockstor.com/t/cant-activate-license-behind-a-proxy/9011
If there is additional nginx configuration possible, this might be proposed as a configuration option via the Rockstor documentation (unless we find more users requiring a solve for this scenario), otherwise some other option (as described in the forum post could be explored.