package-reporter doesn't get proxy settings from client.conf
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Landscape Client |
Fix Released
|
High
|
Simon Poirier | ||
landscape-client (Ubuntu) |
Fix Released
|
High
|
Andreas Hasenack | ||
Trusty |
Fix Released
|
High
|
Andreas Hasenack | ||
Xenial |
Fix Released
|
High
|
Andreas Hasenack | ||
Zesty |
Fix Released
|
High
|
Andreas Hasenack | ||
Artful |
Fix Released
|
High
|
Andreas Hasenack |
Bug Description
[Impact]
The package reporter is not getting the proxy settings set in /etc/landscape/
[Test Case]
Here we want to block direct access from a client to landscape.
DO NOT set proxy environment variables, as these will be picked up by the client when it's restarted and give a false good test result. We want to be sure the values are being grabbed from the config file, and not the environment.
DO NOT set proxy values in /etc/environment.
* Create an ubuntu container or VM, take note of its IP address, and install the proposed landscape-client package on it.
sudo apt install landscape-client
Also make sure dnsutils is installed:
sudo apt install dnsutils
* Enable debugging on the client. Edit /etc/landscape/
log_level = debug
* Block direct access to landscape.
for ip in $(dig +short landscape.
Do the same for your ubuntu archive or whatever mirror you are using (note: this won't work if you have ipv6 enabled):
for ip in $(dig +short archive.ubuntu.com; do sudo iptables -A OUTPUT -d $ip -j REJECT; done
* Confirm that this access is indeed blocked:
$ telnet landscape.
Trying 91.189.90.173...
Trying 91.189.89.90...
telnet: Unable to connect to remote host: Connection refused
$ telnet landscape.
Trying 91.189.89.90...
Trying 91.189.90.173...
telnet: Unable to connect to remote host: Connection refused
* Verify that apt-get update is blocked for the archive (your ips might differ, here I'm using a mirror):
$ sudo apt update
(...)
Err:2 http://
Cannot initiate the connection to br.archive.
* In a xenial container, install the squid proxy server:
sudo apt install squid3
* Take note of the IP of this container
* Edit /etc/squid/
- locate the "#acl localnet src" block of lines and add one for the network where the landscape-client container you created before has an IP. For example:
acl localnet src 10.0.0.0/8
- locate the "#http_access allow localnet" line and remove the comment:
http_access allow localnet
* Restart squid:
sudo service squid restart
* Keep tailing the squid access logs:
sudo tail -f /var/log/
* Go back to the landscape-client container
* Verify that the proxy is allowing your connections, and that without the proxy it fails:
ubuntu@
ds5:errors19:
ubuntu@
curl: (7) Failed to connect to landscape.
* Same for https:
ubuntu@
Landscape message server
ubuntu@
curl: (7) Failed to connect to landscape.
* in a terminal, tail the (still non existing) package-reporter logs:
sudo tail -F /var/log/
* in another terminal, tail the (still non existing) broker log:
sudo tail -F /var/log/
* register the client with a landscape server. In this example we are going to use landscape.
sudo landscape-config -a <youraccount> -u https:/
* the proxy access logs should show some activity already:
1511531199.415 1230 127.0.0.1 TCP_TUNNEL/200 4474 CONNECT landscape.
1511531229.909 485 127.0.0.1 TCP_MISS/200 357 POST http://
That's the registration request (port 443) and the ping (port 80)
* go to landscape.
* monitor package-
2017-11-24 14:31:24,203 INFO [MainThread] Downloaded hash=>id database from https:/
Since this is via https, it will be hard to match it to a proxy access log, but since we blocked direct access to landscape, we know this download happened via the proxy. That's one bug fix confirmed.
* also in package-
2017-11-24 14:35:17,736 DEBUG [MainThread] '/usr/lib/
Hit:2 http://
Hit:3 http://
Hit:4 http://
Reading package lists...
', err='')
i.e., no error reported
There should also be matching entries in the proxy access logs:
1511534116.438 27 10.0.100.95 TCP_MISS/304 251 GET http://
1511534116.442 3 10.0.100.95 TCP_MISS/304 251 GET http://
1511534116.445 3 10.0.100.95 TCP_MISS/304 251 GET http://
1511534116.449 3 10.0.100.95 TCP_MISS/304 251 GET http://
That confirms that apt-update was given the proxy information by landscape from the package-reporter, and confirms that the package-reporter got the proxy information.
These two verifications (hash-id download, and apt update run) confirm this bug is fixed.
[Regression Potential]
Regressions in this area will basically prevent the client from fetching package information from the ubuntu archive and whatever other repositories are configured. This situation would be obvious enough by checking the lack of updates available for the registered computers, which is the problem this patch is fixing. What's important is that communication with the server would remain unaffected.
Should a major regression creep in, something that prevents the client from communicating with the server, then the server would eventually issue a "computer offline" alert and the admin would have to investigate. What could be troublesome is if the only means of accessing the computer is via landscape. This should be rare, as ssh usage is widespread.
[Other Info]
* Upstream revision:
http://
This PPA has test packages built from the attached branches, using a ~ppaN suffix:
https:/
--- Original description ---
The package reporter is not getting the proxy settings set in /etc/landscape/
As a result, the following fails:
- fetching hash-id-database file
- running the SUID root /usr/lib/
Logs from a run on a test system which is prohibited from accessing the internet directly, but does have the proxy settings in client.conf:
2016-01-05 12:41:25,678 DEBUG [MainThread] '/usr/lib/
Err http://
Err http://
Err http://
Unable to connect to archive.
Err http://
Unable to connect to archive.
Err http://
Unable to connect to archive.
Reading package lists...
', err='W: Failed to fetch http://
W: Failed to fetch http://
W: Failed to fetch http://
W: Failed to fetch http://
W: Failed to fetch http://
W: Failed to fetch http://
W: Some index files failed to download. They have been ignored, or old ones used instead.
')
2016-01-05 12:41:27,861 WARNING [MainThread] Couldn't download hash=>id database: Error 7: Failed to connect to landscape.
2016-01-05 12:41:28,012 DEBUG [MainThread] Started firing stop.
2016-01-05 12:41:28,012 DEBUG [MainThread] Finished firing stop.
Broker exchanges work just fine, as do the client pings.
One has to be careful when trying to reproduce this bug, as there are many ways the environment values can leak into the process and invalidate the test.
For example, if you have the http_proxy and https_proxy variables in root's environment, and restart the client, it will inherit those, and invalidate the test.
Or let's say you have them in ubuntu's environment, and use sudo to restart the client. They won't be propagated to the daemon by default unless -E is used, and/or the proxy variables are whitelisted in /etc/sudoers.
Related branches
- Adam Collard (community): Approve
- 🤖 Landscape Builder: Approve (test results)
- Eric Snow (community): Approve
-
Diff: 247 lines (+121/-8)5 files modifiedapt-update/apt-update.c (+19/-1)
landscape/lib/fetch.py (+5/-1)
landscape/lib/tests/test_fetch.py (+8/-0)
landscape/package/reporter.py (+17/-2)
landscape/package/tests/test_reporter.py (+72/-4)
tags: | added: proxy theme-proxy |
tags: | added: bug-squad kanban |
tags: | removed: kanban |
tags: | added: lds-squad |
Changed in landscape-client: | |
status: | New → Triaged |
tags: | added: kanban |
tags: | removed: kanban |
Changed in landscape-client: | |
assignee: | nobody → Simon Poirier (simpoir) |
Changed in landscape-client: | |
status: | Triaged → In Progress |
Changed in landscape-client: | |
status: | In Progress → Fix Committed |
Changed in landscape-client: | |
status: | Fix Committed → Fix Released |
Changed in landscape-client (Ubuntu): | |
status: | New → In Progress |
assignee: | nobody → Andreas Hasenack (ahasenack) |
description: | updated |
description: | updated |
description: | updated |
description: | updated |
description: | updated |
description: | updated |
description: | updated |
description: | updated |
description: | updated |
description: | updated |
description: | updated |
description: | updated |
description: | updated |
Changed in landscape-client (Ubuntu Trusty): | |
status: | New → In Progress |
Changed in landscape-client (Ubuntu Xenial): | |
status: | New → In Progress |
Changed in landscape-client (Ubuntu Zesty): | |
status: | New → In Progress |
Changed in landscape-client (Ubuntu Artful): | |
status: | New → In Progress |
Changed in landscape-client (Ubuntu Trusty): | |
assignee: | nobody → Andreas Hasenack (ahasenack) |
Changed in landscape-client (Ubuntu Xenial): | |
assignee: | nobody → Andreas Hasenack (ahasenack) |
Changed in landscape-client (Ubuntu Zesty): | |
assignee: | nobody → Andreas Hasenack (ahasenack) |
Changed in landscape-client (Ubuntu Artful): | |
assignee: | nobody → Andreas Hasenack (ahasenack) |
Changed in landscape-client (Ubuntu): | |
importance: | Undecided → High |
Changed in landscape-client (Ubuntu Trusty): | |
importance: | Undecided → High |
Changed in landscape-client (Ubuntu Xenial): | |
importance: | Undecided → High |
Changed in landscape-client (Ubuntu Zesty): | |
importance: | Undecided → High |
Changed in landscape-client (Ubuntu Artful): | |
importance: | Undecided → High |
tags: |
added: verification-done-artful verification-done-trusty verification-done-xenial verification-done-zesty removed: verification-needed-artful verification-needed-trusty verification-needed-xenial verification-needed-zesty |
A workaround is two-fold:
a) add the proxy lines to /etc/default/ landscape- client; localhost, 127.0.0. 1,<others- if-needed>
export http_proxy=http://<your-proxy>/
export https_proxy=http://<your-proxy>/
export no_proxy=
Obviously replace <your-proxy> with your proxy IP/hostname, and port if needed.
That takes care of the hash-id download problem.
b) for the apt-get update suid root wrapper, create this file /etc/apt/ apt.conf. d/50-proxy: :http:: Proxy "http://<your-proxy>/"; :https: :Proxy "http://<your-proxy>/";
Acquire:
Acquire:
Again, replace <your-proxy> as before.