| 2016-01-05 12:43:39 |
Andreas Hasenack |
bug |
|
|
added bug |
| 2016-01-05 13:17:34 |
Andreas Hasenack |
tags |
|
proxy theme-proxy |
|
| 2016-01-05 18:25:16 |
Andreas Hasenack |
tags |
proxy theme-proxy |
bug-squad kanban proxy theme-proxy |
|
| 2016-01-06 20:56:02 |
Chad Smith |
tags |
bug-squad kanban proxy theme-proxy |
bug-squad proxy theme-proxy |
|
| 2016-01-07 11:39:00 |
Johannes Martin |
bug |
|
|
added subscriber Johannes Martin |
| 2016-01-08 07:19:09 |
Johannes Martin |
attachment added |
|
Proposed patch https://bugs.launchpad.net/landscape-client/+bug/1531150/+attachment/4546065/+files/1531150.patch |
|
| 2016-01-08 13:27:40 |
Johannes Martin |
bug watch added |
|
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=41053 |
|
| 2016-01-08 13:27:40 |
Johannes Martin |
bug watch added |
|
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=696335 |
|
| 2016-04-06 14:06:26 |
Alex Moldovan |
tags |
bug-squad proxy theme-proxy |
bug-squad lds-squad proxy theme-proxy |
|
| 2016-04-08 09:21:16 |
Adam Collard |
landscape-client: status |
New |
Triaged |
|
| 2016-07-19 21:05:43 |
David Britton |
tags |
bug-squad lds-squad proxy theme-proxy |
bug-squad kanban lds-squad proxy theme-proxy |
|
| 2016-07-19 21:21:23 |
🤖 Landscape Builder |
tags |
bug-squad kanban lds-squad proxy theme-proxy |
bug-squad lds-squad proxy theme-proxy |
|
| 2016-07-21 15:05:09 |
Simon Poirier |
landscape-client: assignee |
|
Simon Poirier (simpoir) |
|
| 2016-07-21 17:58:39 |
Simon Poirier |
branch linked |
|
lp:~simpoir/landscape-client/bug_1531150_package_reporter_proxy |
|
| 2016-07-21 18:07:45 |
Simon Poirier |
landscape-client: status |
Triaged |
In Progress |
|
| 2016-08-30 15:27:27 |
🤖 Landscape Builder |
landscape-client: status |
In Progress |
Fix Committed |
|
| 2017-09-13 21:41:42 |
Simon Poirier |
attachment added |
|
trusty.debdiff https://bugs.launchpad.net/landscape-client/+bug/1531150/+attachment/4949712/+files/trusty.debdiff |
|
| 2017-09-13 21:42:46 |
Simon Poirier |
attachment added |
|
xenial.debdiff https://bugs.launchpad.net/landscape-client/+bug/1531150/+attachment/4949713/+files/xenial.debdiff |
|
| 2017-09-14 20:47:41 |
Kellen Renshaw |
bug |
|
|
added subscriber Kellen Renshaw |
| 2017-09-28 20:53:06 |
Simon Poirier |
landscape-client: status |
Fix Committed |
Fix Released |
|
| 2017-11-10 15:47:41 |
Andreas Hasenack |
bug task added |
|
landscape-client (Ubuntu) |
|
| 2017-11-10 15:50:54 |
Andreas Hasenack |
nominated for series |
|
Ubuntu Artful |
|
| 2017-11-10 15:50:54 |
Andreas Hasenack |
bug task added |
|
landscape-client (Ubuntu Artful) |
|
| 2017-11-10 15:50:54 |
Andreas Hasenack |
nominated for series |
|
Ubuntu Trusty |
|
| 2017-11-10 15:50:54 |
Andreas Hasenack |
bug task added |
|
landscape-client (Ubuntu Trusty) |
|
| 2017-11-10 15:50:54 |
Andreas Hasenack |
nominated for series |
|
Ubuntu Zesty |
|
| 2017-11-10 15:50:54 |
Andreas Hasenack |
bug task added |
|
landscape-client (Ubuntu Zesty) |
|
| 2017-11-10 15:50:54 |
Andreas Hasenack |
nominated for series |
|
Ubuntu Xenial |
|
| 2017-11-10 15:50:54 |
Andreas Hasenack |
bug task added |
|
landscape-client (Ubuntu Xenial) |
|
| 2017-11-10 16:12:19 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~ahasenack/ubuntu/+source/landscape-client/+git/landscape-client/+merge/333548 |
|
| 2017-11-10 16:20:53 |
Ubuntu Foundations Team Bug Bot |
tags |
bug-squad lds-squad proxy theme-proxy |
bug-squad lds-squad patch proxy theme-proxy |
|
| 2017-11-10 16:21:00 |
Ubuntu Foundations Team Bug Bot |
bug |
|
|
added subscriber Ubuntu Review Team |
| 2017-11-10 17:17:58 |
Andreas Hasenack |
landscape-client (Ubuntu): status |
New |
In Progress |
|
| 2017-11-10 17:18:01 |
Andreas Hasenack |
landscape-client (Ubuntu): assignee |
|
Andreas Hasenack (ahasenack) |
|
| 2017-11-20 17:21:35 |
Launchpad Janitor |
landscape-client (Ubuntu): status |
In Progress |
Fix Released |
|
| 2017-11-23 18:11:21 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~ahasenack/ubuntu/+source/landscape-client/+git/landscape-client/+merge/334203 |
|
| 2017-11-23 18:11:33 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~ahasenack/ubuntu/+source/landscape-client/+git/landscape-client/+merge/334204 |
|
| 2017-11-23 18:11:45 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~ahasenack/ubuntu/+source/landscape-client/+git/landscape-client/+merge/334205 |
|
| 2017-11-23 18:11:56 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~ahasenack/ubuntu/+source/landscape-client/+git/landscape-client/+merge/334206 |
|
| 2017-11-23 18:26:18 |
Eric Desrochers |
description |
The package reporter is not getting the proxy settings set in /etc/landscape/client.conf. It will honor the environment variables if they are somehow set when landscape-client is started, but not if the values are just defined in that configuration file.
As a result, the following fails:
- fetching hash-id-database file
- running the SUID root /usr/lib/landscape/apt-update helper. Even though the binary it calls in turn fails (apt-get itself), the exit code is 0. It's only seen in the logs if using debug mode.
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/landscape/apt-update' exited with status 0 (out='Err http://archive.ubuntu.com trusty InRelease
Err http://archive.ubuntu.com trusty-updates InRelease
Err http://archive.ubuntu.com trusty-security InRelease
Err http://archive.ubuntu.com trusty Release.gpg
Unable to connect to archive.ubuntu.com:http:
Err http://archive.ubuntu.com trusty-updates Release.gpg
Unable to connect to archive.ubuntu.com:http:
Err http://archive.ubuntu.com trusty-security Release.gpg
Unable to connect to archive.ubuntu.com:http:
Reading package lists...
', err='W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty/InRelease
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty-updates/InRelease
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty-security/InRelease
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty/Release.gpg Unable to connect to archive.ubuntu.com:http:
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty-updates/Release.gpg Unable to connect to archive.ubuntu.com:http:
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty-security/Release.gpg Unable to connect to archive.ubuntu.com: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.canonical.com port 443: Connection refused
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. |
[Impact]
The package reporter is not getting the proxy settings set in /etc/landscape/client.conf:
http_proxy = <your-proxy>
https_proxy = <your-proxy>
It will respect the environment variables if they are somehow set when landscape-client is started, but not if the values are just defined in that configuration file.
Clients can ping and broker exchanges work. There are 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.
[Test Case]
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.
[Regression Potential]
[Other Info]
[Original Description]
The package reporter is not getting the proxy settings set in /etc/landscape/client.conf. It will honor the environment variables if they are somehow set when landscape-client is started, but not if the values are just defined in that configuration file.
As a result, the following fails:
- fetching hash-id-database file
- running the SUID root /usr/lib/landscape/apt-update helper. Even though the binary it calls in turn fails (apt-get itself), the exit code is 0. It's only seen in the logs if using debug mode.
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/landscape/apt-update' exited with status 0 (out='Err http://archive.ubuntu.com trusty InRelease
Err http://archive.ubuntu.com trusty-updates InRelease
Err http://archive.ubuntu.com trusty-security InRelease
Err http://archive.ubuntu.com trusty Release.gpg
Unable to connect to archive.ubuntu.com:http:
Err http://archive.ubuntu.com trusty-updates Release.gpg
Unable to connect to archive.ubuntu.com:http:
Err http://archive.ubuntu.com trusty-security Release.gpg
Unable to connect to archive.ubuntu.com:http:
Reading package lists...
', err='W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty/InRelease
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty-updates/InRelease
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty-security/InRelease
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty/Release.gpg Unable to connect to archive.ubuntu.com:http:
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty-updates/Release.gpg Unable to connect to archive.ubuntu.com:http:
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty-security/Release.gpg Unable to connect to archive.ubuntu.com: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.canonical.com port 443: Connection refused
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. |
|
| 2017-11-23 18:34:11 |
Eric Desrochers |
description |
[Impact]
The package reporter is not getting the proxy settings set in /etc/landscape/client.conf:
http_proxy = <your-proxy>
https_proxy = <your-proxy>
It will respect the environment variables if they are somehow set when landscape-client is started, but not if the values are just defined in that configuration file.
Clients can ping and broker exchanges work. There are 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.
[Test Case]
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.
[Regression Potential]
[Other Info]
[Original Description]
The package reporter is not getting the proxy settings set in /etc/landscape/client.conf. It will honor the environment variables if they are somehow set when landscape-client is started, but not if the values are just defined in that configuration file.
As a result, the following fails:
- fetching hash-id-database file
- running the SUID root /usr/lib/landscape/apt-update helper. Even though the binary it calls in turn fails (apt-get itself), the exit code is 0. It's only seen in the logs if using debug mode.
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/landscape/apt-update' exited with status 0 (out='Err http://archive.ubuntu.com trusty InRelease
Err http://archive.ubuntu.com trusty-updates InRelease
Err http://archive.ubuntu.com trusty-security InRelease
Err http://archive.ubuntu.com trusty Release.gpg
Unable to connect to archive.ubuntu.com:http:
Err http://archive.ubuntu.com trusty-updates Release.gpg
Unable to connect to archive.ubuntu.com:http:
Err http://archive.ubuntu.com trusty-security Release.gpg
Unable to connect to archive.ubuntu.com:http:
Reading package lists...
', err='W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty/InRelease
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty-updates/InRelease
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty-security/InRelease
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty/Release.gpg Unable to connect to archive.ubuntu.com:http:
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty-updates/Release.gpg Unable to connect to archive.ubuntu.com:http:
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty-security/Release.gpg Unable to connect to archive.ubuntu.com: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.canonical.com port 443: Connection refused
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. |
[Impact]
The package reporter is not getting the proxy settings set in /etc/landscape/client.conf:
http_proxy = <your-proxy>
https_proxy = <your-proxy>
It will respect the environment variables if they are somehow set when landscape-client is started, but not if the values are just defined in that configuration file.
Clients can ping and broker exchanges work. There are 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.
[Test Case]
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.
[Regression Potential]
[Other Info]
* Upstream revision:
http://bazaar.launchpad.net/~landscape/landscape-client/trunk/revision/919
[Original Description]
The package reporter is not getting the proxy settings set in /etc/landscape/client.conf. It will honor the environment variables if they are somehow set when landscape-client is started, but not if the values are just defined in that configuration file.
As a result, the following fails:
- fetching hash-id-database file
- running the SUID root /usr/lib/landscape/apt-update helper. Even though the binary it calls in turn fails (apt-get itself), the exit code is 0. It's only seen in the logs if using debug mode.
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/landscape/apt-update' exited with status 0 (out='Err http://archive.ubuntu.com trusty InRelease
Err http://archive.ubuntu.com trusty-updates InRelease
Err http://archive.ubuntu.com trusty-security InRelease
Err http://archive.ubuntu.com trusty Release.gpg
Unable to connect to archive.ubuntu.com:http:
Err http://archive.ubuntu.com trusty-updates Release.gpg
Unable to connect to archive.ubuntu.com:http:
Err http://archive.ubuntu.com trusty-security Release.gpg
Unable to connect to archive.ubuntu.com:http:
Reading package lists...
', err='W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty/InRelease
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty-updates/InRelease
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty-security/InRelease
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty/Release.gpg Unable to connect to archive.ubuntu.com:http:
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty-updates/Release.gpg Unable to connect to archive.ubuntu.com:http:
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty-security/Release.gpg Unable to connect to archive.ubuntu.com: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.canonical.com port 443: Connection refused
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. |
|
| 2017-11-23 18:52:02 |
Alex Moldovan |
description |
[Impact]
The package reporter is not getting the proxy settings set in /etc/landscape/client.conf:
http_proxy = <your-proxy>
https_proxy = <your-proxy>
It will respect the environment variables if they are somehow set when landscape-client is started, but not if the values are just defined in that configuration file.
Clients can ping and broker exchanges work. There are 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.
[Test Case]
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.
[Regression Potential]
[Other Info]
* Upstream revision:
http://bazaar.launchpad.net/~landscape/landscape-client/trunk/revision/919
[Original Description]
The package reporter is not getting the proxy settings set in /etc/landscape/client.conf. It will honor the environment variables if they are somehow set when landscape-client is started, but not if the values are just defined in that configuration file.
As a result, the following fails:
- fetching hash-id-database file
- running the SUID root /usr/lib/landscape/apt-update helper. Even though the binary it calls in turn fails (apt-get itself), the exit code is 0. It's only seen in the logs if using debug mode.
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/landscape/apt-update' exited with status 0 (out='Err http://archive.ubuntu.com trusty InRelease
Err http://archive.ubuntu.com trusty-updates InRelease
Err http://archive.ubuntu.com trusty-security InRelease
Err http://archive.ubuntu.com trusty Release.gpg
Unable to connect to archive.ubuntu.com:http:
Err http://archive.ubuntu.com trusty-updates Release.gpg
Unable to connect to archive.ubuntu.com:http:
Err http://archive.ubuntu.com trusty-security Release.gpg
Unable to connect to archive.ubuntu.com:http:
Reading package lists...
', err='W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty/InRelease
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty-updates/InRelease
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty-security/InRelease
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty/Release.gpg Unable to connect to archive.ubuntu.com:http:
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty-updates/Release.gpg Unable to connect to archive.ubuntu.com:http:
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty-security/Release.gpg Unable to connect to archive.ubuntu.com: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.canonical.com port 443: Connection refused
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. |
[Impact]
The package reporter is not getting the proxy settings set in /etc/landscape/client.conf. As a result, fetching hash-id-database file and running the SUID root /usr/lib/landscape/apt-update helper fail. Even though the binary it calls in turn fails (apt-get itself), the exit code is 0. It's only seen in the logs if using debug mode.
[Test Case]
Edit the /etc/landscape/client.conf with the proxy configuration:
http_proxy = <your-proxy>
https_proxy = <your-proxy>
It will respect the environment variables if they are somehow set when landscape-client is started, but not if the values are just defined in that configuration file.
Clients can ping and broker exchanges work. There are 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.
[Regression Potential]
[Other Info]
* Upstream revision:
http://bazaar.launchpad.net/~landscape/landscape-client/trunk/revision/919
[Original Description]
The package reporter is not getting the proxy settings set in /etc/landscape/client.conf. It will honor the environment variables if they are somehow set when landscape-client is started, but not if the values are just defined in that configuration file.
As a result, the following fails:
- fetching hash-id-database file
- running the SUID root /usr/lib/landscape/apt-update helper. Even though the binary it calls in turn fails (apt-get itself), the exit code is 0. It's only seen in the logs if using debug mode.
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/landscape/apt-update' exited with status 0 (out='Err http://archive.ubuntu.com trusty InRelease
Err http://archive.ubuntu.com trusty-updates InRelease
Err http://archive.ubuntu.com trusty-security InRelease
Err http://archive.ubuntu.com trusty Release.gpg
Unable to connect to archive.ubuntu.com:http:
Err http://archive.ubuntu.com trusty-updates Release.gpg
Unable to connect to archive.ubuntu.com:http:
Err http://archive.ubuntu.com trusty-security Release.gpg
Unable to connect to archive.ubuntu.com:http:
Reading package lists...
', err='W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty/InRelease
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty-updates/InRelease
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty-security/InRelease
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty/Release.gpg Unable to connect to archive.ubuntu.com:http:
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty-updates/Release.gpg Unable to connect to archive.ubuntu.com:http:
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty-security/Release.gpg Unable to connect to archive.ubuntu.com: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.canonical.com port 443: Connection refused
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. |
|
| 2017-11-24 13:00:34 |
Andreas Hasenack |
description |
[Impact]
The package reporter is not getting the proxy settings set in /etc/landscape/client.conf. As a result, fetching hash-id-database file and running the SUID root /usr/lib/landscape/apt-update helper fail. Even though the binary it calls in turn fails (apt-get itself), the exit code is 0. It's only seen in the logs if using debug mode.
[Test Case]
Edit the /etc/landscape/client.conf with the proxy configuration:
http_proxy = <your-proxy>
https_proxy = <your-proxy>
It will respect the environment variables if they are somehow set when landscape-client is started, but not if the values are just defined in that configuration file.
Clients can ping and broker exchanges work. There are 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.
[Regression Potential]
[Other Info]
* Upstream revision:
http://bazaar.launchpad.net/~landscape/landscape-client/trunk/revision/919
[Original Description]
The package reporter is not getting the proxy settings set in /etc/landscape/client.conf. It will honor the environment variables if they are somehow set when landscape-client is started, but not if the values are just defined in that configuration file.
As a result, the following fails:
- fetching hash-id-database file
- running the SUID root /usr/lib/landscape/apt-update helper. Even though the binary it calls in turn fails (apt-get itself), the exit code is 0. It's only seen in the logs if using debug mode.
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/landscape/apt-update' exited with status 0 (out='Err http://archive.ubuntu.com trusty InRelease
Err http://archive.ubuntu.com trusty-updates InRelease
Err http://archive.ubuntu.com trusty-security InRelease
Err http://archive.ubuntu.com trusty Release.gpg
Unable to connect to archive.ubuntu.com:http:
Err http://archive.ubuntu.com trusty-updates Release.gpg
Unable to connect to archive.ubuntu.com:http:
Err http://archive.ubuntu.com trusty-security Release.gpg
Unable to connect to archive.ubuntu.com:http:
Reading package lists...
', err='W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty/InRelease
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty-updates/InRelease
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty-security/InRelease
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty/Release.gpg Unable to connect to archive.ubuntu.com:http:
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty-updates/Release.gpg Unable to connect to archive.ubuntu.com:http:
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty-security/Release.gpg Unable to connect to archive.ubuntu.com: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.canonical.com port 443: Connection refused
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. |
[Impact]
The package reporter is not getting the proxy settings set in /etc/landscape/client.conf. As a result, fetching hash-id-database file and running the SUID root /usr/lib/landscape/apt-update helper fail. Even though the binary it calls in turn fails (apt-get itself), the exit code is 0. It's only seen in the logs if using debug mode.
[Test Case]
Edit the /etc/landscape/client.conf with the proxy configuration:
http_proxy = <your-proxy>
https_proxy = <your-proxy>
It will respect the environment variables if they are somehow set when landscape-client is started, but not if the values are just defined in that configuration file.
Clients can ping and broker exchanges work. There are 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.
[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://bazaar.launchpad.net/~landscape/landscape-client/trunk/revision/919
This PPA has test packages built from these branches, using a ~ppaN suffix:
https://launchpad.net/~ahasenack/+archive/ubuntu/lsclient-sru-1721383
--- Original description ---
The package reporter is not getting the proxy settings set in /etc/landscape/client.conf. It will honor the environment variables if they are somehow set when landscape-client is started, but not if the values are just defined in that configuration file.
As a result, the following fails:
- fetching hash-id-database file
- running the SUID root /usr/lib/landscape/apt-update helper. Even though the binary it calls in turn fails (apt-get itself), the exit code is 0. It's only seen in the logs if using debug mode.
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/landscape/apt-update' exited with status 0 (out='Err http://archive.ubuntu.com trusty InRelease
Err http://archive.ubuntu.com trusty-updates InRelease
Err http://archive.ubuntu.com trusty-security InRelease
Err http://archive.ubuntu.com trusty Release.gpg
Unable to connect to archive.ubuntu.com:http:
Err http://archive.ubuntu.com trusty-updates Release.gpg
Unable to connect to archive.ubuntu.com:http:
Err http://archive.ubuntu.com trusty-security Release.gpg
Unable to connect to archive.ubuntu.com:http:
Reading package lists...
', err='W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty/InRelease
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty-updates/InRelease
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty-security/InRelease
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty/Release.gpg Unable to connect to archive.ubuntu.com:http:
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty-updates/Release.gpg Unable to connect to archive.ubuntu.com:http:
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty-security/Release.gpg Unable to connect to archive.ubuntu.com: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.canonical.com port 443: Connection refused
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. |
|
| 2017-11-24 14:15:18 |
Andreas Hasenack |
description |
[Impact]
The package reporter is not getting the proxy settings set in /etc/landscape/client.conf. As a result, fetching hash-id-database file and running the SUID root /usr/lib/landscape/apt-update helper fail. Even though the binary it calls in turn fails (apt-get itself), the exit code is 0. It's only seen in the logs if using debug mode.
[Test Case]
Edit the /etc/landscape/client.conf with the proxy configuration:
http_proxy = <your-proxy>
https_proxy = <your-proxy>
It will respect the environment variables if they are somehow set when landscape-client is started, but not if the values are just defined in that configuration file.
Clients can ping and broker exchanges work. There are 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.
[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://bazaar.launchpad.net/~landscape/landscape-client/trunk/revision/919
This PPA has test packages built from these branches, using a ~ppaN suffix:
https://launchpad.net/~ahasenack/+archive/ubuntu/lsclient-sru-1721383
--- Original description ---
The package reporter is not getting the proxy settings set in /etc/landscape/client.conf. It will honor the environment variables if they are somehow set when landscape-client is started, but not if the values are just defined in that configuration file.
As a result, the following fails:
- fetching hash-id-database file
- running the SUID root /usr/lib/landscape/apt-update helper. Even though the binary it calls in turn fails (apt-get itself), the exit code is 0. It's only seen in the logs if using debug mode.
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/landscape/apt-update' exited with status 0 (out='Err http://archive.ubuntu.com trusty InRelease
Err http://archive.ubuntu.com trusty-updates InRelease
Err http://archive.ubuntu.com trusty-security InRelease
Err http://archive.ubuntu.com trusty Release.gpg
Unable to connect to archive.ubuntu.com:http:
Err http://archive.ubuntu.com trusty-updates Release.gpg
Unable to connect to archive.ubuntu.com:http:
Err http://archive.ubuntu.com trusty-security Release.gpg
Unable to connect to archive.ubuntu.com:http:
Reading package lists...
', err='W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty/InRelease
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty-updates/InRelease
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty-security/InRelease
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty/Release.gpg Unable to connect to archive.ubuntu.com:http:
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty-updates/Release.gpg Unable to connect to archive.ubuntu.com:http:
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty-security/Release.gpg Unable to connect to archive.ubuntu.com: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.canonical.com port 443: Connection refused
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. |
[Impact]
The package reporter is not getting the proxy settings set in /etc/landscape/client.conf. As a result, fetching hash-id-database file and running the SUID root /usr/lib/landscape/apt-update helper fail. Even though the binary it calls in turn fails (apt-get itself), the exit code is 0. It's only seen in the logs if using debug mode.
[Test Case]
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
* Block direct access to landscape.canonical.com:
for ip in $(dig +short landscape.canonical.com); do sudo iptables -A OUTPUT -d $ip -j REJECT; done
* Confirm that this access is indeed blocked:
$ telnet landscape.canonical.com 80
Trying 91.189.90.173...
Trying 91.189.89.90...
telnet: Unable to connect to remote host: Connection refused
$ telnet landscape.canonical.com 443
Trying 91.189.89.90...
Trying 91.189.90.173...
telnet: Unable to connect to remote host: Connection refused
* In a xenial container, install the squid proxy server:
sudo apt install squid3
* Take note of the IP of this container
* Edit /etc/squid/squid.conf and make these changes:
- 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/squid/access.log
* Go back to the landscape-client container
* Verify that the proxy is allowing your connections, and that without the proxy it fails:
ubuntu@xenial-client-sru:~$ http_proxy=http://xenial-proxy.lxd:3128/ curl http://landscape.canonical.com/ping ;echo
ds5:errors19:provide insecure_id;
ubuntu@xenial-client-sru:~$ curl http://landscape.canonical.com/ping ;echo
curl: (7) Failed to connect to landscape.canonical.com port 80: Connection refused
ubuntu@xenial-client-sru:~$
* in a terminal, tail the (still non existing) package-reporter logs:
sudo tail -F /var/log/landscape/package-reporter.log
* in another terminal, tail the (still non existing) broker log:
sudo tail -F /var/log/landscape/broker.log
* register the client with a landscape server. In this example we are going to use landscape.canonical.com and the proxy we just configured (replace <proxy> with the IP of the squid container we created above):
sudo landscape-config -a <youraccount> -u https://landscape.canonical.com/message-system --ping-url http://landscape.canonical.com/ping -t sru-proxy-test --silent --http-proxy=http://<proxy>:3128/ --https-proxy=http://<proxy>:3128/
* the proxy access logs should show some activity already:
1511531199.415 1230 127.0.0.1 TCP_TUNNEL/200 4474 CONNECT landscape.canonical.com:443 - HIER_DIRECT/91.189.89.90 -
1511531229.909 485 127.0.0.1 TCP_MISS/200 357 POST http://landscape.canonical.com/ping - HIER_DIRECT/91.189.89.90 text/html
That's the registration request (port 443) and the ping (port 80)
* go to landscape.canonical.com, login and accept the new pending computer we just created
[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://bazaar.launchpad.net/~landscape/landscape-client/trunk/revision/919
This PPA has test packages built from these branches, using a ~ppaN suffix:
https://launchpad.net/~ahasenack/+archive/ubuntu/lsclient-sru-1721383
--- Original description ---
The package reporter is not getting the proxy settings set in /etc/landscape/client.conf. It will honor the environment variables if they are somehow set when landscape-client is started, but not if the values are just defined in that configuration file.
As a result, the following fails:
- fetching hash-id-database file
- running the SUID root /usr/lib/landscape/apt-update helper. Even though the binary it calls in turn fails (apt-get itself), the exit code is 0. It's only seen in the logs if using debug mode.
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/landscape/apt-update' exited with status 0 (out='Err http://archive.ubuntu.com trusty InRelease
Err http://archive.ubuntu.com trusty-updates InRelease
Err http://archive.ubuntu.com trusty-security InRelease
Err http://archive.ubuntu.com trusty Release.gpg
Unable to connect to archive.ubuntu.com:http:
Err http://archive.ubuntu.com trusty-updates Release.gpg
Unable to connect to archive.ubuntu.com:http:
Err http://archive.ubuntu.com trusty-security Release.gpg
Unable to connect to archive.ubuntu.com:http:
Reading package lists...
', err='W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty/InRelease
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty-updates/InRelease
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty-security/InRelease
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty/Release.gpg Unable to connect to archive.ubuntu.com:http:
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty-updates/Release.gpg Unable to connect to archive.ubuntu.com:http:
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty-security/Release.gpg Unable to connect to archive.ubuntu.com: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.canonical.com port 443: Connection refused
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. |
|
| 2017-11-24 14:17:16 |
Andreas Hasenack |
description |
[Impact]
The package reporter is not getting the proxy settings set in /etc/landscape/client.conf. As a result, fetching hash-id-database file and running the SUID root /usr/lib/landscape/apt-update helper fail. Even though the binary it calls in turn fails (apt-get itself), the exit code is 0. It's only seen in the logs if using debug mode.
[Test Case]
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
* Block direct access to landscape.canonical.com:
for ip in $(dig +short landscape.canonical.com); do sudo iptables -A OUTPUT -d $ip -j REJECT; done
* Confirm that this access is indeed blocked:
$ telnet landscape.canonical.com 80
Trying 91.189.90.173...
Trying 91.189.89.90...
telnet: Unable to connect to remote host: Connection refused
$ telnet landscape.canonical.com 443
Trying 91.189.89.90...
Trying 91.189.90.173...
telnet: Unable to connect to remote host: Connection refused
* In a xenial container, install the squid proxy server:
sudo apt install squid3
* Take note of the IP of this container
* Edit /etc/squid/squid.conf and make these changes:
- 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/squid/access.log
* Go back to the landscape-client container
* Verify that the proxy is allowing your connections, and that without the proxy it fails:
ubuntu@xenial-client-sru:~$ http_proxy=http://xenial-proxy.lxd:3128/ curl http://landscape.canonical.com/ping ;echo
ds5:errors19:provide insecure_id;
ubuntu@xenial-client-sru:~$ curl http://landscape.canonical.com/ping ;echo
curl: (7) Failed to connect to landscape.canonical.com port 80: Connection refused
ubuntu@xenial-client-sru:~$
* in a terminal, tail the (still non existing) package-reporter logs:
sudo tail -F /var/log/landscape/package-reporter.log
* in another terminal, tail the (still non existing) broker log:
sudo tail -F /var/log/landscape/broker.log
* register the client with a landscape server. In this example we are going to use landscape.canonical.com and the proxy we just configured (replace <proxy> with the IP of the squid container we created above):
sudo landscape-config -a <youraccount> -u https://landscape.canonical.com/message-system --ping-url http://landscape.canonical.com/ping -t sru-proxy-test --silent --http-proxy=http://<proxy>:3128/ --https-proxy=http://<proxy>:3128/
* the proxy access logs should show some activity already:
1511531199.415 1230 127.0.0.1 TCP_TUNNEL/200 4474 CONNECT landscape.canonical.com:443 - HIER_DIRECT/91.189.89.90 -
1511531229.909 485 127.0.0.1 TCP_MISS/200 357 POST http://landscape.canonical.com/ping - HIER_DIRECT/91.189.89.90 text/html
That's the registration request (port 443) and the ping (port 80)
* go to landscape.canonical.com, login and accept the new pending computer we just created
[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://bazaar.launchpad.net/~landscape/landscape-client/trunk/revision/919
This PPA has test packages built from these branches, using a ~ppaN suffix:
https://launchpad.net/~ahasenack/+archive/ubuntu/lsclient-sru-1721383
--- Original description ---
The package reporter is not getting the proxy settings set in /etc/landscape/client.conf. It will honor the environment variables if they are somehow set when landscape-client is started, but not if the values are just defined in that configuration file.
As a result, the following fails:
- fetching hash-id-database file
- running the SUID root /usr/lib/landscape/apt-update helper. Even though the binary it calls in turn fails (apt-get itself), the exit code is 0. It's only seen in the logs if using debug mode.
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/landscape/apt-update' exited with status 0 (out='Err http://archive.ubuntu.com trusty InRelease
Err http://archive.ubuntu.com trusty-updates InRelease
Err http://archive.ubuntu.com trusty-security InRelease
Err http://archive.ubuntu.com trusty Release.gpg
Unable to connect to archive.ubuntu.com:http:
Err http://archive.ubuntu.com trusty-updates Release.gpg
Unable to connect to archive.ubuntu.com:http:
Err http://archive.ubuntu.com trusty-security Release.gpg
Unable to connect to archive.ubuntu.com:http:
Reading package lists...
', err='W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty/InRelease
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty-updates/InRelease
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty-security/InRelease
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty/Release.gpg Unable to connect to archive.ubuntu.com:http:
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty-updates/Release.gpg Unable to connect to archive.ubuntu.com:http:
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty-security/Release.gpg Unable to connect to archive.ubuntu.com: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.canonical.com port 443: Connection refused
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. |
[Impact]
The package reporter is not getting the proxy settings set in /etc/landscape/client.conf. As a result, fetching hash-id-database file and running the SUID root /usr/lib/landscape/apt-update helper fail. Even though the binary it calls in turn fails (apt-get itself), the exit code is 0. It's only seen in the logs if using debug mode.
[Test Case]
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
* Block direct access to landscape.canonical.com:
for ip in $(dig +short landscape.canonical.com); do sudo iptables -A OUTPUT -d $ip -j REJECT; done
* Confirm that this access is indeed blocked:
$ telnet landscape.canonical.com 80
Trying 91.189.90.173...
Trying 91.189.89.90...
telnet: Unable to connect to remote host: Connection refused
$ telnet landscape.canonical.com 443
Trying 91.189.89.90...
Trying 91.189.90.173...
telnet: Unable to connect to remote host: Connection refused
* In a xenial container, install the squid proxy server:
sudo apt install squid3
* Take note of the IP of this container
* Edit /etc/squid/squid.conf and make these changes:
- 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/squid/access.log
* Go back to the landscape-client container
* Verify that the proxy is allowing your connections, and that without the proxy it fails:
ubuntu@xenial-client-sru:~$ http_proxy=http://xenial-proxy.lxd:3128/ curl http://landscape.canonical.com/ping ;echo
ds5:errors19:provide insecure_id;
ubuntu@xenial-client-sru:~$ curl http://landscape.canonical.com/ping ;echo
curl: (7) Failed to connect to landscape.canonical.com port 80: Connection refused
* Same for https:
ubuntu@xenial-client-sru:~$ https_proxy=http://xenial-proxy.lxd:3128 curl https://landscape.canonical.com/message-system;echo
Landscape message server
ubuntu@xenial-client-sru:~$ curl https://landscape.canonical.com/message-system;echo
curl: (7) Failed to connect to landscape.canonical.com port 443: Connection refused
* in a terminal, tail the (still non existing) package-reporter logs:
sudo tail -F /var/log/landscape/package-reporter.log
* in another terminal, tail the (still non existing) broker log:
sudo tail -F /var/log/landscape/broker.log
* register the client with a landscape server. In this example we are going to use landscape.canonical.com and the proxy we just configured (replace <proxy> with the IP of the squid container we created above):
sudo landscape-config -a <youraccount> -u https://landscape.canonical.com/message-system --ping-url http://landscape.canonical.com/ping -t sru-proxy-test --silent --http-proxy=http://<proxy>:3128/ --https-proxy=http://<proxy>:3128/
* the proxy access logs should show some activity already:
1511531199.415 1230 127.0.0.1 TCP_TUNNEL/200 4474 CONNECT landscape.canonical.com:443 - HIER_DIRECT/91.189.89.90 -
1511531229.909 485 127.0.0.1 TCP_MISS/200 357 POST http://landscape.canonical.com/ping - HIER_DIRECT/91.189.89.90 text/html
That's the registration request (port 443) and the ping (port 80)
* go to landscape.canonical.com, login and accept the new pending computer we just created
[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://bazaar.launchpad.net/~landscape/landscape-client/trunk/revision/919
This PPA has test packages built from these branches, using a ~ppaN suffix:
https://launchpad.net/~ahasenack/+archive/ubuntu/lsclient-sru-1721383
--- Original description ---
The package reporter is not getting the proxy settings set in /etc/landscape/client.conf. It will honor the environment variables if they are somehow set when landscape-client is started, but not if the values are just defined in that configuration file.
As a result, the following fails:
- fetching hash-id-database file
- running the SUID root /usr/lib/landscape/apt-update helper. Even though the binary it calls in turn fails (apt-get itself), the exit code is 0. It's only seen in the logs if using debug mode.
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/landscape/apt-update' exited with status 0 (out='Err http://archive.ubuntu.com trusty InRelease
Err http://archive.ubuntu.com trusty-updates InRelease
Err http://archive.ubuntu.com trusty-security InRelease
Err http://archive.ubuntu.com trusty Release.gpg
Unable to connect to archive.ubuntu.com:http:
Err http://archive.ubuntu.com trusty-updates Release.gpg
Unable to connect to archive.ubuntu.com:http:
Err http://archive.ubuntu.com trusty-security Release.gpg
Unable to connect to archive.ubuntu.com:http:
Reading package lists...
', err='W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty/InRelease
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty-updates/InRelease
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty-security/InRelease
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty/Release.gpg Unable to connect to archive.ubuntu.com:http:
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty-updates/Release.gpg Unable to connect to archive.ubuntu.com:http:
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty-security/Release.gpg Unable to connect to archive.ubuntu.com: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.canonical.com port 443: Connection refused
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. |
|
| 2017-11-24 14:28:09 |
Andreas Hasenack |
description |
[Impact]
The package reporter is not getting the proxy settings set in /etc/landscape/client.conf. As a result, fetching hash-id-database file and running the SUID root /usr/lib/landscape/apt-update helper fail. Even though the binary it calls in turn fails (apt-get itself), the exit code is 0. It's only seen in the logs if using debug mode.
[Test Case]
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
* Block direct access to landscape.canonical.com:
for ip in $(dig +short landscape.canonical.com); do sudo iptables -A OUTPUT -d $ip -j REJECT; done
* Confirm that this access is indeed blocked:
$ telnet landscape.canonical.com 80
Trying 91.189.90.173...
Trying 91.189.89.90...
telnet: Unable to connect to remote host: Connection refused
$ telnet landscape.canonical.com 443
Trying 91.189.89.90...
Trying 91.189.90.173...
telnet: Unable to connect to remote host: Connection refused
* In a xenial container, install the squid proxy server:
sudo apt install squid3
* Take note of the IP of this container
* Edit /etc/squid/squid.conf and make these changes:
- 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/squid/access.log
* Go back to the landscape-client container
* Verify that the proxy is allowing your connections, and that without the proxy it fails:
ubuntu@xenial-client-sru:~$ http_proxy=http://xenial-proxy.lxd:3128/ curl http://landscape.canonical.com/ping ;echo
ds5:errors19:provide insecure_id;
ubuntu@xenial-client-sru:~$ curl http://landscape.canonical.com/ping ;echo
curl: (7) Failed to connect to landscape.canonical.com port 80: Connection refused
* Same for https:
ubuntu@xenial-client-sru:~$ https_proxy=http://xenial-proxy.lxd:3128 curl https://landscape.canonical.com/message-system;echo
Landscape message server
ubuntu@xenial-client-sru:~$ curl https://landscape.canonical.com/message-system;echo
curl: (7) Failed to connect to landscape.canonical.com port 443: Connection refused
* in a terminal, tail the (still non existing) package-reporter logs:
sudo tail -F /var/log/landscape/package-reporter.log
* in another terminal, tail the (still non existing) broker log:
sudo tail -F /var/log/landscape/broker.log
* register the client with a landscape server. In this example we are going to use landscape.canonical.com and the proxy we just configured (replace <proxy> with the IP of the squid container we created above):
sudo landscape-config -a <youraccount> -u https://landscape.canonical.com/message-system --ping-url http://landscape.canonical.com/ping -t sru-proxy-test --silent --http-proxy=http://<proxy>:3128/ --https-proxy=http://<proxy>:3128/
* the proxy access logs should show some activity already:
1511531199.415 1230 127.0.0.1 TCP_TUNNEL/200 4474 CONNECT landscape.canonical.com:443 - HIER_DIRECT/91.189.89.90 -
1511531229.909 485 127.0.0.1 TCP_MISS/200 357 POST http://landscape.canonical.com/ping - HIER_DIRECT/91.189.89.90 text/html
That's the registration request (port 443) and the ping (port 80)
* go to landscape.canonical.com, login and accept the new pending computer we just created
[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://bazaar.launchpad.net/~landscape/landscape-client/trunk/revision/919
This PPA has test packages built from these branches, using a ~ppaN suffix:
https://launchpad.net/~ahasenack/+archive/ubuntu/lsclient-sru-1721383
--- Original description ---
The package reporter is not getting the proxy settings set in /etc/landscape/client.conf. It will honor the environment variables if they are somehow set when landscape-client is started, but not if the values are just defined in that configuration file.
As a result, the following fails:
- fetching hash-id-database file
- running the SUID root /usr/lib/landscape/apt-update helper. Even though the binary it calls in turn fails (apt-get itself), the exit code is 0. It's only seen in the logs if using debug mode.
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/landscape/apt-update' exited with status 0 (out='Err http://archive.ubuntu.com trusty InRelease
Err http://archive.ubuntu.com trusty-updates InRelease
Err http://archive.ubuntu.com trusty-security InRelease
Err http://archive.ubuntu.com trusty Release.gpg
Unable to connect to archive.ubuntu.com:http:
Err http://archive.ubuntu.com trusty-updates Release.gpg
Unable to connect to archive.ubuntu.com:http:
Err http://archive.ubuntu.com trusty-security Release.gpg
Unable to connect to archive.ubuntu.com:http:
Reading package lists...
', err='W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty/InRelease
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty-updates/InRelease
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty-security/InRelease
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty/Release.gpg Unable to connect to archive.ubuntu.com:http:
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty-updates/Release.gpg Unable to connect to archive.ubuntu.com:http:
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty-security/Release.gpg Unable to connect to archive.ubuntu.com: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.canonical.com port 443: Connection refused
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. |
[Impact]
The package reporter is not getting the proxy settings set in /etc/landscape/client.conf. As a result, fetching hash-id-database file and running the SUID root /usr/lib/landscape/apt-update helper fail. Even though the binary it calls in turn fails (apt-get itself), the exit code is 0. It's only seen in the logs if using debug mode.
[Test Case]
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
* Block direct access to landscape.canonical.com:
for ip in $(dig +short landscape.canonical.com); do sudo iptables -A OUTPUT -d $ip -j REJECT; done
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.canonical.com 80
Trying 91.189.90.173...
Trying 91.189.89.90...
telnet: Unable to connect to remote host: Connection refused
$ telnet landscape.canonical.com 443
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://br.archive.ubuntu.com/ubuntu xenial InRelease
Cannot initiate the connection to br.archive.ubuntu.com:80 (2801:82:80ff:8000::5). - connect (101: Network is unreachable) [IP: 2801:82:80ff:8000::5 80]
* In a xenial container, install the squid proxy server:
sudo apt install squid3
* Take note of the IP of this container
* Edit /etc/squid/squid.conf and make these changes:
- 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/squid/access.log
* Go back to the landscape-client container
* Verify that the proxy is allowing your connections, and that without the proxy it fails:
ubuntu@xenial-client-sru:~$ http_proxy=http://xenial-proxy.lxd:3128/ curl http://landscape.canonical.com/ping ;echo
ds5:errors19:provide insecure_id;
ubuntu@xenial-client-sru:~$ curl http://landscape.canonical.com/ping ;echo
curl: (7) Failed to connect to landscape.canonical.com port 80: Connection refused
* Same for https:
ubuntu@xenial-client-sru:~$ https_proxy=http://xenial-proxy.lxd:3128 curl https://landscape.canonical.com/message-system;echo
Landscape message server
ubuntu@xenial-client-sru:~$ curl https://landscape.canonical.com/message-system;echo
curl: (7) Failed to connect to landscape.canonical.com port 443: Connection refused
* in a terminal, tail the (still non existing) package-reporter logs:
sudo tail -F /var/log/landscape/package-reporter.log
* in another terminal, tail the (still non existing) broker log:
sudo tail -F /var/log/landscape/broker.log
* register the client with a landscape server. In this example we are going to use landscape.canonical.com and the proxy we just configured (replace <proxy> with the IP of the squid container we created above):
sudo landscape-config -a <youraccount> -u https://landscape.canonical.com/message-system --ping-url http://landscape.canonical.com/ping -t sru-proxy-test --silent --http-proxy=http://<proxy>:3128/ --https-proxy=http://<proxy>:3128/
* the proxy access logs should show some activity already:
1511531199.415 1230 127.0.0.1 TCP_TUNNEL/200 4474 CONNECT landscape.canonical.com:443 - HIER_DIRECT/91.189.89.90 -
1511531229.909 485 127.0.0.1 TCP_MISS/200 357 POST http://landscape.canonical.com/ping - HIER_DIRECT/91.189.89.90 text/html
That's the registration request (port 443) and the ping (port 80)
* go to landscape.canonical.com, login and accept the new pending computer we just created
[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://bazaar.launchpad.net/~landscape/landscape-client/trunk/revision/919
This PPA has test packages built from these branches, using a ~ppaN suffix:
https://launchpad.net/~ahasenack/+archive/ubuntu/lsclient-sru-1721383
--- Original description ---
The package reporter is not getting the proxy settings set in /etc/landscape/client.conf. It will honor the environment variables if they are somehow set when landscape-client is started, but not if the values are just defined in that configuration file.
As a result, the following fails:
- fetching hash-id-database file
- running the SUID root /usr/lib/landscape/apt-update helper. Even though the binary it calls in turn fails (apt-get itself), the exit code is 0. It's only seen in the logs if using debug mode.
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/landscape/apt-update' exited with status 0 (out='Err http://archive.ubuntu.com trusty InRelease
Err http://archive.ubuntu.com trusty-updates InRelease
Err http://archive.ubuntu.com trusty-security InRelease
Err http://archive.ubuntu.com trusty Release.gpg
Unable to connect to archive.ubuntu.com:http:
Err http://archive.ubuntu.com trusty-updates Release.gpg
Unable to connect to archive.ubuntu.com:http:
Err http://archive.ubuntu.com trusty-security Release.gpg
Unable to connect to archive.ubuntu.com:http:
Reading package lists...
', err='W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty/InRelease
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty-updates/InRelease
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty-security/InRelease
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty/Release.gpg Unable to connect to archive.ubuntu.com:http:
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty-updates/Release.gpg Unable to connect to archive.ubuntu.com:http:
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty-security/Release.gpg Unable to connect to archive.ubuntu.com: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.canonical.com port 443: Connection refused
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. |
|
| 2017-11-24 14:29:06 |
Andreas Hasenack |
description |
[Impact]
The package reporter is not getting the proxy settings set in /etc/landscape/client.conf. As a result, fetching hash-id-database file and running the SUID root /usr/lib/landscape/apt-update helper fail. Even though the binary it calls in turn fails (apt-get itself), the exit code is 0. It's only seen in the logs if using debug mode.
[Test Case]
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
* Block direct access to landscape.canonical.com:
for ip in $(dig +short landscape.canonical.com); do sudo iptables -A OUTPUT -d $ip -j REJECT; done
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.canonical.com 80
Trying 91.189.90.173...
Trying 91.189.89.90...
telnet: Unable to connect to remote host: Connection refused
$ telnet landscape.canonical.com 443
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://br.archive.ubuntu.com/ubuntu xenial InRelease
Cannot initiate the connection to br.archive.ubuntu.com:80 (2801:82:80ff:8000::5). - connect (101: Network is unreachable) [IP: 2801:82:80ff:8000::5 80]
* In a xenial container, install the squid proxy server:
sudo apt install squid3
* Take note of the IP of this container
* Edit /etc/squid/squid.conf and make these changes:
- 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/squid/access.log
* Go back to the landscape-client container
* Verify that the proxy is allowing your connections, and that without the proxy it fails:
ubuntu@xenial-client-sru:~$ http_proxy=http://xenial-proxy.lxd:3128/ curl http://landscape.canonical.com/ping ;echo
ds5:errors19:provide insecure_id;
ubuntu@xenial-client-sru:~$ curl http://landscape.canonical.com/ping ;echo
curl: (7) Failed to connect to landscape.canonical.com port 80: Connection refused
* Same for https:
ubuntu@xenial-client-sru:~$ https_proxy=http://xenial-proxy.lxd:3128 curl https://landscape.canonical.com/message-system;echo
Landscape message server
ubuntu@xenial-client-sru:~$ curl https://landscape.canonical.com/message-system;echo
curl: (7) Failed to connect to landscape.canonical.com port 443: Connection refused
* in a terminal, tail the (still non existing) package-reporter logs:
sudo tail -F /var/log/landscape/package-reporter.log
* in another terminal, tail the (still non existing) broker log:
sudo tail -F /var/log/landscape/broker.log
* register the client with a landscape server. In this example we are going to use landscape.canonical.com and the proxy we just configured (replace <proxy> with the IP of the squid container we created above):
sudo landscape-config -a <youraccount> -u https://landscape.canonical.com/message-system --ping-url http://landscape.canonical.com/ping -t sru-proxy-test --silent --http-proxy=http://<proxy>:3128/ --https-proxy=http://<proxy>:3128/
* the proxy access logs should show some activity already:
1511531199.415 1230 127.0.0.1 TCP_TUNNEL/200 4474 CONNECT landscape.canonical.com:443 - HIER_DIRECT/91.189.89.90 -
1511531229.909 485 127.0.0.1 TCP_MISS/200 357 POST http://landscape.canonical.com/ping - HIER_DIRECT/91.189.89.90 text/html
That's the registration request (port 443) and the ping (port 80)
* go to landscape.canonical.com, login and accept the new pending computer we just created
[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://bazaar.launchpad.net/~landscape/landscape-client/trunk/revision/919
This PPA has test packages built from these branches, using a ~ppaN suffix:
https://launchpad.net/~ahasenack/+archive/ubuntu/lsclient-sru-1721383
--- Original description ---
The package reporter is not getting the proxy settings set in /etc/landscape/client.conf. It will honor the environment variables if they are somehow set when landscape-client is started, but not if the values are just defined in that configuration file.
As a result, the following fails:
- fetching hash-id-database file
- running the SUID root /usr/lib/landscape/apt-update helper. Even though the binary it calls in turn fails (apt-get itself), the exit code is 0. It's only seen in the logs if using debug mode.
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/landscape/apt-update' exited with status 0 (out='Err http://archive.ubuntu.com trusty InRelease
Err http://archive.ubuntu.com trusty-updates InRelease
Err http://archive.ubuntu.com trusty-security InRelease
Err http://archive.ubuntu.com trusty Release.gpg
Unable to connect to archive.ubuntu.com:http:
Err http://archive.ubuntu.com trusty-updates Release.gpg
Unable to connect to archive.ubuntu.com:http:
Err http://archive.ubuntu.com trusty-security Release.gpg
Unable to connect to archive.ubuntu.com:http:
Reading package lists...
', err='W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty/InRelease
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty-updates/InRelease
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty-security/InRelease
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty/Release.gpg Unable to connect to archive.ubuntu.com:http:
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty-updates/Release.gpg Unable to connect to archive.ubuntu.com:http:
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty-security/Release.gpg Unable to connect to archive.ubuntu.com: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.canonical.com port 443: Connection refused
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. |
[Impact]
The package reporter is not getting the proxy settings set in /etc/landscape/client.conf. As a result, fetching hash-id-database file and running the SUID root /usr/lib/landscape/apt-update helper fail. Even though the binary it calls in turn fails (apt-get itself), the exit code is 0. It's only seen in the logs if using debug mode.
[Test Case]
Here we want to block direct access from a client to landscape.canonical.com and the ubuntu archive, forcing it to use a proxy we will setup. That's how we will determine that the bug is fixed.
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
* Block direct access to landscape.canonical.com:
for ip in $(dig +short landscape.canonical.com); do sudo iptables -A OUTPUT -d $ip -j REJECT; done
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.canonical.com 80
Trying 91.189.90.173...
Trying 91.189.89.90...
telnet: Unable to connect to remote host: Connection refused
$ telnet landscape.canonical.com 443
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://br.archive.ubuntu.com/ubuntu xenial InRelease
Cannot initiate the connection to br.archive.ubuntu.com:80 (2801:82:80ff:8000::5). - connect (101: Network is unreachable) [IP: 2801:82:80ff:8000::5 80]
* In a xenial container, install the squid proxy server:
sudo apt install squid3
* Take note of the IP of this container
* Edit /etc/squid/squid.conf and make these changes:
- 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/squid/access.log
* Go back to the landscape-client container
* Verify that the proxy is allowing your connections, and that without the proxy it fails:
ubuntu@xenial-client-sru:~$ http_proxy=http://xenial-proxy.lxd:3128/ curl http://landscape.canonical.com/ping ;echo
ds5:errors19:provide insecure_id;
ubuntu@xenial-client-sru:~$ curl http://landscape.canonical.com/ping ;echo
curl: (7) Failed to connect to landscape.canonical.com port 80: Connection refused
* Same for https:
ubuntu@xenial-client-sru:~$ https_proxy=http://xenial-proxy.lxd:3128 curl https://landscape.canonical.com/message-system;echo
Landscape message server
ubuntu@xenial-client-sru:~$ curl https://landscape.canonical.com/message-system;echo
curl: (7) Failed to connect to landscape.canonical.com port 443: Connection refused
* in a terminal, tail the (still non existing) package-reporter logs:
sudo tail -F /var/log/landscape/package-reporter.log
* in another terminal, tail the (still non existing) broker log:
sudo tail -F /var/log/landscape/broker.log
* register the client with a landscape server. In this example we are going to use landscape.canonical.com and the proxy we just configured (replace <proxy> with the IP of the squid container we created above):
sudo landscape-config -a <youraccount> -u https://landscape.canonical.com/message-system --ping-url http://landscape.canonical.com/ping -t sru-proxy-test --silent --http-proxy=http://<proxy>:3128/ --https-proxy=http://<proxy>:3128/
* the proxy access logs should show some activity already:
1511531199.415 1230 127.0.0.1 TCP_TUNNEL/200 4474 CONNECT landscape.canonical.com:443 - HIER_DIRECT/91.189.89.90 -
1511531229.909 485 127.0.0.1 TCP_MISS/200 357 POST http://landscape.canonical.com/ping - HIER_DIRECT/91.189.89.90 text/html
That's the registration request (port 443) and the ping (port 80)
* go to landscape.canonical.com, login and accept the new pending computer we just created
[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://bazaar.launchpad.net/~landscape/landscape-client/trunk/revision/919
This PPA has test packages built from these branches, using a ~ppaN suffix:
https://launchpad.net/~ahasenack/+archive/ubuntu/lsclient-sru-1721383
--- Original description ---
The package reporter is not getting the proxy settings set in /etc/landscape/client.conf. It will honor the environment variables if they are somehow set when landscape-client is started, but not if the values are just defined in that configuration file.
As a result, the following fails:
- fetching hash-id-database file
- running the SUID root /usr/lib/landscape/apt-update helper. Even though the binary it calls in turn fails (apt-get itself), the exit code is 0. It's only seen in the logs if using debug mode.
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/landscape/apt-update' exited with status 0 (out='Err http://archive.ubuntu.com trusty InRelease
Err http://archive.ubuntu.com trusty-updates InRelease
Err http://archive.ubuntu.com trusty-security InRelease
Err http://archive.ubuntu.com trusty Release.gpg
Unable to connect to archive.ubuntu.com:http:
Err http://archive.ubuntu.com trusty-updates Release.gpg
Unable to connect to archive.ubuntu.com:http:
Err http://archive.ubuntu.com trusty-security Release.gpg
Unable to connect to archive.ubuntu.com:http:
Reading package lists...
', err='W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty/InRelease
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty-updates/InRelease
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty-security/InRelease
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty/Release.gpg Unable to connect to archive.ubuntu.com:http:
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty-updates/Release.gpg Unable to connect to archive.ubuntu.com:http:
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty-security/Release.gpg Unable to connect to archive.ubuntu.com: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.canonical.com port 443: Connection refused
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. |
|
| 2017-11-24 14:30:39 |
Andreas Hasenack |
description |
[Impact]
The package reporter is not getting the proxy settings set in /etc/landscape/client.conf. As a result, fetching hash-id-database file and running the SUID root /usr/lib/landscape/apt-update helper fail. Even though the binary it calls in turn fails (apt-get itself), the exit code is 0. It's only seen in the logs if using debug mode.
[Test Case]
Here we want to block direct access from a client to landscape.canonical.com and the ubuntu archive, forcing it to use a proxy we will setup. That's how we will determine that the bug is fixed.
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
* Block direct access to landscape.canonical.com:
for ip in $(dig +short landscape.canonical.com); do sudo iptables -A OUTPUT -d $ip -j REJECT; done
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.canonical.com 80
Trying 91.189.90.173...
Trying 91.189.89.90...
telnet: Unable to connect to remote host: Connection refused
$ telnet landscape.canonical.com 443
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://br.archive.ubuntu.com/ubuntu xenial InRelease
Cannot initiate the connection to br.archive.ubuntu.com:80 (2801:82:80ff:8000::5). - connect (101: Network is unreachable) [IP: 2801:82:80ff:8000::5 80]
* In a xenial container, install the squid proxy server:
sudo apt install squid3
* Take note of the IP of this container
* Edit /etc/squid/squid.conf and make these changes:
- 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/squid/access.log
* Go back to the landscape-client container
* Verify that the proxy is allowing your connections, and that without the proxy it fails:
ubuntu@xenial-client-sru:~$ http_proxy=http://xenial-proxy.lxd:3128/ curl http://landscape.canonical.com/ping ;echo
ds5:errors19:provide insecure_id;
ubuntu@xenial-client-sru:~$ curl http://landscape.canonical.com/ping ;echo
curl: (7) Failed to connect to landscape.canonical.com port 80: Connection refused
* Same for https:
ubuntu@xenial-client-sru:~$ https_proxy=http://xenial-proxy.lxd:3128 curl https://landscape.canonical.com/message-system;echo
Landscape message server
ubuntu@xenial-client-sru:~$ curl https://landscape.canonical.com/message-system;echo
curl: (7) Failed to connect to landscape.canonical.com port 443: Connection refused
* in a terminal, tail the (still non existing) package-reporter logs:
sudo tail -F /var/log/landscape/package-reporter.log
* in another terminal, tail the (still non existing) broker log:
sudo tail -F /var/log/landscape/broker.log
* register the client with a landscape server. In this example we are going to use landscape.canonical.com and the proxy we just configured (replace <proxy> with the IP of the squid container we created above):
sudo landscape-config -a <youraccount> -u https://landscape.canonical.com/message-system --ping-url http://landscape.canonical.com/ping -t sru-proxy-test --silent --http-proxy=http://<proxy>:3128/ --https-proxy=http://<proxy>:3128/
* the proxy access logs should show some activity already:
1511531199.415 1230 127.0.0.1 TCP_TUNNEL/200 4474 CONNECT landscape.canonical.com:443 - HIER_DIRECT/91.189.89.90 -
1511531229.909 485 127.0.0.1 TCP_MISS/200 357 POST http://landscape.canonical.com/ping - HIER_DIRECT/91.189.89.90 text/html
That's the registration request (port 443) and the ping (port 80)
* go to landscape.canonical.com, login and accept the new pending computer we just created
[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://bazaar.launchpad.net/~landscape/landscape-client/trunk/revision/919
This PPA has test packages built from these branches, using a ~ppaN suffix:
https://launchpad.net/~ahasenack/+archive/ubuntu/lsclient-sru-1721383
--- Original description ---
The package reporter is not getting the proxy settings set in /etc/landscape/client.conf. It will honor the environment variables if they are somehow set when landscape-client is started, but not if the values are just defined in that configuration file.
As a result, the following fails:
- fetching hash-id-database file
- running the SUID root /usr/lib/landscape/apt-update helper. Even though the binary it calls in turn fails (apt-get itself), the exit code is 0. It's only seen in the logs if using debug mode.
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/landscape/apt-update' exited with status 0 (out='Err http://archive.ubuntu.com trusty InRelease
Err http://archive.ubuntu.com trusty-updates InRelease
Err http://archive.ubuntu.com trusty-security InRelease
Err http://archive.ubuntu.com trusty Release.gpg
Unable to connect to archive.ubuntu.com:http:
Err http://archive.ubuntu.com trusty-updates Release.gpg
Unable to connect to archive.ubuntu.com:http:
Err http://archive.ubuntu.com trusty-security Release.gpg
Unable to connect to archive.ubuntu.com:http:
Reading package lists...
', err='W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty/InRelease
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty-updates/InRelease
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty-security/InRelease
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty/Release.gpg Unable to connect to archive.ubuntu.com:http:
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty-updates/Release.gpg Unable to connect to archive.ubuntu.com:http:
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty-security/Release.gpg Unable to connect to archive.ubuntu.com: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.canonical.com port 443: Connection refused
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. |
[Impact]
The package reporter is not getting the proxy settings set in /etc/landscape/client.conf. As a result, fetching hash-id-database file and running the SUID root /usr/lib/landscape/apt-update helper fail. Even though the binary it calls in turn fails (apt-get itself), the exit code is 0. It's only seen in the logs if using debug mode.
[Test Case]
Here we want to block direct access from a client to landscape.canonical.com and the ubuntu archive, forcing it to use a proxy we will setup. That's how we will determine that the bug is fixed.
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/client.conf and make sure this line is there:
log_level = debug
* Block direct access to landscape.canonical.com:
for ip in $(dig +short landscape.canonical.com); do sudo iptables -A OUTPUT -d $ip -j REJECT; done
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.canonical.com 80
Trying 91.189.90.173...
Trying 91.189.89.90...
telnet: Unable to connect to remote host: Connection refused
$ telnet landscape.canonical.com 443
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://br.archive.ubuntu.com/ubuntu xenial InRelease
Cannot initiate the connection to br.archive.ubuntu.com:80 (2801:82:80ff:8000::5). - connect (101: Network is unreachable) [IP: 2801:82:80ff:8000::5 80]
* In a xenial container, install the squid proxy server:
sudo apt install squid3
* Take note of the IP of this container
* Edit /etc/squid/squid.conf and make these changes:
- 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/squid/access.log
* Go back to the landscape-client container
* Verify that the proxy is allowing your connections, and that without the proxy it fails:
ubuntu@xenial-client-sru:~$ http_proxy=http://xenial-proxy.lxd:3128/ curl http://landscape.canonical.com/ping ;echo
ds5:errors19:provide insecure_id;
ubuntu@xenial-client-sru:~$ curl http://landscape.canonical.com/ping ;echo
curl: (7) Failed to connect to landscape.canonical.com port 80: Connection refused
* Same for https:
ubuntu@xenial-client-sru:~$ https_proxy=http://xenial-proxy.lxd:3128 curl https://landscape.canonical.com/message-system;echo
Landscape message server
ubuntu@xenial-client-sru:~$ curl https://landscape.canonical.com/message-system;echo
curl: (7) Failed to connect to landscape.canonical.com port 443: Connection refused
* in a terminal, tail the (still non existing) package-reporter logs:
sudo tail -F /var/log/landscape/package-reporter.log
* in another terminal, tail the (still non existing) broker log:
sudo tail -F /var/log/landscape/broker.log
* register the client with a landscape server. In this example we are going to use landscape.canonical.com and the proxy we just configured (replace <proxy> with the IP of the squid container we created above):
sudo landscape-config -a <youraccount> -u https://landscape.canonical.com/message-system --ping-url http://landscape.canonical.com/ping -t sru-proxy-test --silent --http-proxy=http://<proxy>:3128/ --https-proxy=http://<proxy>:3128/
* the proxy access logs should show some activity already:
1511531199.415 1230 127.0.0.1 TCP_TUNNEL/200 4474 CONNECT landscape.canonical.com:443 - HIER_DIRECT/91.189.89.90 -
1511531229.909 485 127.0.0.1 TCP_MISS/200 357 POST http://landscape.canonical.com/ping - HIER_DIRECT/91.189.89.90 text/html
That's the registration request (port 443) and the ping (port 80)
* go to landscape.canonical.com, login and accept the new pending computer we just created
[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://bazaar.launchpad.net/~landscape/landscape-client/trunk/revision/919
This PPA has test packages built from these branches, using a ~ppaN suffix:
https://launchpad.net/~ahasenack/+archive/ubuntu/lsclient-sru-1721383
--- Original description ---
The package reporter is not getting the proxy settings set in /etc/landscape/client.conf. It will honor the environment variables if they are somehow set when landscape-client is started, but not if the values are just defined in that configuration file.
As a result, the following fails:
- fetching hash-id-database file
- running the SUID root /usr/lib/landscape/apt-update helper. Even though the binary it calls in turn fails (apt-get itself), the exit code is 0. It's only seen in the logs if using debug mode.
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/landscape/apt-update' exited with status 0 (out='Err http://archive.ubuntu.com trusty InRelease
Err http://archive.ubuntu.com trusty-updates InRelease
Err http://archive.ubuntu.com trusty-security InRelease
Err http://archive.ubuntu.com trusty Release.gpg
Unable to connect to archive.ubuntu.com:http:
Err http://archive.ubuntu.com trusty-updates Release.gpg
Unable to connect to archive.ubuntu.com:http:
Err http://archive.ubuntu.com trusty-security Release.gpg
Unable to connect to archive.ubuntu.com:http:
Reading package lists...
', err='W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty/InRelease
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty-updates/InRelease
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty-security/InRelease
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty/Release.gpg Unable to connect to archive.ubuntu.com:http:
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty-updates/Release.gpg Unable to connect to archive.ubuntu.com:http:
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty-security/Release.gpg Unable to connect to archive.ubuntu.com: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.canonical.com port 443: Connection refused
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. |
|
| 2017-11-24 14:32:28 |
Andreas Hasenack |
description |
[Impact]
The package reporter is not getting the proxy settings set in /etc/landscape/client.conf. As a result, fetching hash-id-database file and running the SUID root /usr/lib/landscape/apt-update helper fail. Even though the binary it calls in turn fails (apt-get itself), the exit code is 0. It's only seen in the logs if using debug mode.
[Test Case]
Here we want to block direct access from a client to landscape.canonical.com and the ubuntu archive, forcing it to use a proxy we will setup. That's how we will determine that the bug is fixed.
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/client.conf and make sure this line is there:
log_level = debug
* Block direct access to landscape.canonical.com:
for ip in $(dig +short landscape.canonical.com); do sudo iptables -A OUTPUT -d $ip -j REJECT; done
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.canonical.com 80
Trying 91.189.90.173...
Trying 91.189.89.90...
telnet: Unable to connect to remote host: Connection refused
$ telnet landscape.canonical.com 443
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://br.archive.ubuntu.com/ubuntu xenial InRelease
Cannot initiate the connection to br.archive.ubuntu.com:80 (2801:82:80ff:8000::5). - connect (101: Network is unreachable) [IP: 2801:82:80ff:8000::5 80]
* In a xenial container, install the squid proxy server:
sudo apt install squid3
* Take note of the IP of this container
* Edit /etc/squid/squid.conf and make these changes:
- 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/squid/access.log
* Go back to the landscape-client container
* Verify that the proxy is allowing your connections, and that without the proxy it fails:
ubuntu@xenial-client-sru:~$ http_proxy=http://xenial-proxy.lxd:3128/ curl http://landscape.canonical.com/ping ;echo
ds5:errors19:provide insecure_id;
ubuntu@xenial-client-sru:~$ curl http://landscape.canonical.com/ping ;echo
curl: (7) Failed to connect to landscape.canonical.com port 80: Connection refused
* Same for https:
ubuntu@xenial-client-sru:~$ https_proxy=http://xenial-proxy.lxd:3128 curl https://landscape.canonical.com/message-system;echo
Landscape message server
ubuntu@xenial-client-sru:~$ curl https://landscape.canonical.com/message-system;echo
curl: (7) Failed to connect to landscape.canonical.com port 443: Connection refused
* in a terminal, tail the (still non existing) package-reporter logs:
sudo tail -F /var/log/landscape/package-reporter.log
* in another terminal, tail the (still non existing) broker log:
sudo tail -F /var/log/landscape/broker.log
* register the client with a landscape server. In this example we are going to use landscape.canonical.com and the proxy we just configured (replace <proxy> with the IP of the squid container we created above):
sudo landscape-config -a <youraccount> -u https://landscape.canonical.com/message-system --ping-url http://landscape.canonical.com/ping -t sru-proxy-test --silent --http-proxy=http://<proxy>:3128/ --https-proxy=http://<proxy>:3128/
* the proxy access logs should show some activity already:
1511531199.415 1230 127.0.0.1 TCP_TUNNEL/200 4474 CONNECT landscape.canonical.com:443 - HIER_DIRECT/91.189.89.90 -
1511531229.909 485 127.0.0.1 TCP_MISS/200 357 POST http://landscape.canonical.com/ping - HIER_DIRECT/91.189.89.90 text/html
That's the registration request (port 443) and the ping (port 80)
* go to landscape.canonical.com, login and accept the new pending computer we just created
[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://bazaar.launchpad.net/~landscape/landscape-client/trunk/revision/919
This PPA has test packages built from these branches, using a ~ppaN suffix:
https://launchpad.net/~ahasenack/+archive/ubuntu/lsclient-sru-1721383
--- Original description ---
The package reporter is not getting the proxy settings set in /etc/landscape/client.conf. It will honor the environment variables if they are somehow set when landscape-client is started, but not if the values are just defined in that configuration file.
As a result, the following fails:
- fetching hash-id-database file
- running the SUID root /usr/lib/landscape/apt-update helper. Even though the binary it calls in turn fails (apt-get itself), the exit code is 0. It's only seen in the logs if using debug mode.
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/landscape/apt-update' exited with status 0 (out='Err http://archive.ubuntu.com trusty InRelease
Err http://archive.ubuntu.com trusty-updates InRelease
Err http://archive.ubuntu.com trusty-security InRelease
Err http://archive.ubuntu.com trusty Release.gpg
Unable to connect to archive.ubuntu.com:http:
Err http://archive.ubuntu.com trusty-updates Release.gpg
Unable to connect to archive.ubuntu.com:http:
Err http://archive.ubuntu.com trusty-security Release.gpg
Unable to connect to archive.ubuntu.com:http:
Reading package lists...
', err='W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty/InRelease
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty-updates/InRelease
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty-security/InRelease
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty/Release.gpg Unable to connect to archive.ubuntu.com:http:
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty-updates/Release.gpg Unable to connect to archive.ubuntu.com:http:
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty-security/Release.gpg Unable to connect to archive.ubuntu.com: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.canonical.com port 443: Connection refused
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. |
[Impact]
The package reporter is not getting the proxy settings set in /etc/landscape/client.conf. As a result, fetching hash-id-database file and running the SUID root /usr/lib/landscape/apt-update helper fail. Even though the binary it calls in turn fails (apt-get itself), the exit code is 0. It's only seen in the logs if using debug mode.
[Test Case]
Here we want to block direct access from a client to landscape.canonical.com and the ubuntu archive, forcing it to use a proxy we will setup. That's how we will determine that the bug is fixed.
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/client.conf and make sure this line is there:
log_level = debug
* Block direct access to landscape.canonical.com:
for ip in $(dig +short landscape.canonical.com); do sudo iptables -A OUTPUT -d $ip -j REJECT; done
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.canonical.com 80
Trying 91.189.90.173...
Trying 91.189.89.90...
telnet: Unable to connect to remote host: Connection refused
$ telnet landscape.canonical.com 443
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://br.archive.ubuntu.com/ubuntu xenial InRelease
Cannot initiate the connection to br.archive.ubuntu.com:80 (2801:82:80ff:8000::5). - connect (101: Network is unreachable) [IP: 2801:82:80ff:8000::5 80]
* In a xenial container, install the squid proxy server:
sudo apt install squid3
* Take note of the IP of this container
* Edit /etc/squid/squid.conf and make these changes:
- 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/squid/access.log
* Go back to the landscape-client container
* Verify that the proxy is allowing your connections, and that without the proxy it fails:
ubuntu@xenial-client-sru:~$ http_proxy=http://xenial-proxy.lxd:3128/ curl http://landscape.canonical.com/ping ;echo
ds5:errors19:provide insecure_id;
ubuntu@xenial-client-sru:~$ curl http://landscape.canonical.com/ping ;echo
curl: (7) Failed to connect to landscape.canonical.com port 80: Connection refused
* Same for https:
ubuntu@xenial-client-sru:~$ https_proxy=http://xenial-proxy.lxd:3128 curl https://landscape.canonical.com/message-system;echo
Landscape message server
ubuntu@xenial-client-sru:~$ curl https://landscape.canonical.com/message-system;echo
curl: (7) Failed to connect to landscape.canonical.com port 443: Connection refused
* in a terminal, tail the (still non existing) package-reporter logs:
sudo tail -F /var/log/landscape/package-reporter.log
* in another terminal, tail the (still non existing) broker log:
sudo tail -F /var/log/landscape/broker.log
* register the client with a landscape server. In this example we are going to use landscape.canonical.com and the proxy we just configured (replace <proxy> with the IP of the squid container we created above):
sudo landscape-config -a <youraccount> -u https://landscape.canonical.com/message-system --ping-url http://landscape.canonical.com/ping -t sru-proxy-test --silent --http-proxy=http://<proxy>:3128/ --https-proxy=http://<proxy>:3128/
* the proxy access logs should show some activity already:
1511531199.415 1230 127.0.0.1 TCP_TUNNEL/200 4474 CONNECT landscape.canonical.com:443 - HIER_DIRECT/91.189.89.90 -
1511531229.909 485 127.0.0.1 TCP_MISS/200 357 POST http://landscape.canonical.com/ping - HIER_DIRECT/91.189.89.90 text/html
That's the registration request (port 443) and the ping (port 80)
* go to landscape.canonical.com, login and accept the new pending computer we just created
* monitor package-reporter.log. At some point it should log that it downloaded the hash-id-database:
2017-11-24 14:31:24,203 INFO [MainThread] Downloaded hash=>id database from https://landscape.canonical.com/hash-id-databases/af6f2dcf-1967-11de-8dd0-001a4b4d8d10_xenial_amd64
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.
[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://bazaar.launchpad.net/~landscape/landscape-client/trunk/revision/919
This PPA has test packages built from these branches, using a ~ppaN suffix:
https://launchpad.net/~ahasenack/+archive/ubuntu/lsclient-sru-1721383
--- Original description ---
The package reporter is not getting the proxy settings set in /etc/landscape/client.conf. It will honor the environment variables if they are somehow set when landscape-client is started, but not if the values are just defined in that configuration file.
As a result, the following fails:
- fetching hash-id-database file
- running the SUID root /usr/lib/landscape/apt-update helper. Even though the binary it calls in turn fails (apt-get itself), the exit code is 0. It's only seen in the logs if using debug mode.
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/landscape/apt-update' exited with status 0 (out='Err http://archive.ubuntu.com trusty InRelease
Err http://archive.ubuntu.com trusty-updates InRelease
Err http://archive.ubuntu.com trusty-security InRelease
Err http://archive.ubuntu.com trusty Release.gpg
Unable to connect to archive.ubuntu.com:http:
Err http://archive.ubuntu.com trusty-updates Release.gpg
Unable to connect to archive.ubuntu.com:http:
Err http://archive.ubuntu.com trusty-security Release.gpg
Unable to connect to archive.ubuntu.com:http:
Reading package lists...
', err='W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty/InRelease
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty-updates/InRelease
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty-security/InRelease
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty/Release.gpg Unable to connect to archive.ubuntu.com:http:
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty-updates/Release.gpg Unable to connect to archive.ubuntu.com:http:
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty-security/Release.gpg Unable to connect to archive.ubuntu.com: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.canonical.com port 443: Connection refused
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. |
|
| 2017-11-24 14:35:32 |
Andreas Hasenack |
description |
[Impact]
The package reporter is not getting the proxy settings set in /etc/landscape/client.conf. As a result, fetching hash-id-database file and running the SUID root /usr/lib/landscape/apt-update helper fail. Even though the binary it calls in turn fails (apt-get itself), the exit code is 0. It's only seen in the logs if using debug mode.
[Test Case]
Here we want to block direct access from a client to landscape.canonical.com and the ubuntu archive, forcing it to use a proxy we will setup. That's how we will determine that the bug is fixed.
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/client.conf and make sure this line is there:
log_level = debug
* Block direct access to landscape.canonical.com:
for ip in $(dig +short landscape.canonical.com); do sudo iptables -A OUTPUT -d $ip -j REJECT; done
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.canonical.com 80
Trying 91.189.90.173...
Trying 91.189.89.90...
telnet: Unable to connect to remote host: Connection refused
$ telnet landscape.canonical.com 443
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://br.archive.ubuntu.com/ubuntu xenial InRelease
Cannot initiate the connection to br.archive.ubuntu.com:80 (2801:82:80ff:8000::5). - connect (101: Network is unreachable) [IP: 2801:82:80ff:8000::5 80]
* In a xenial container, install the squid proxy server:
sudo apt install squid3
* Take note of the IP of this container
* Edit /etc/squid/squid.conf and make these changes:
- 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/squid/access.log
* Go back to the landscape-client container
* Verify that the proxy is allowing your connections, and that without the proxy it fails:
ubuntu@xenial-client-sru:~$ http_proxy=http://xenial-proxy.lxd:3128/ curl http://landscape.canonical.com/ping ;echo
ds5:errors19:provide insecure_id;
ubuntu@xenial-client-sru:~$ curl http://landscape.canonical.com/ping ;echo
curl: (7) Failed to connect to landscape.canonical.com port 80: Connection refused
* Same for https:
ubuntu@xenial-client-sru:~$ https_proxy=http://xenial-proxy.lxd:3128 curl https://landscape.canonical.com/message-system;echo
Landscape message server
ubuntu@xenial-client-sru:~$ curl https://landscape.canonical.com/message-system;echo
curl: (7) Failed to connect to landscape.canonical.com port 443: Connection refused
* in a terminal, tail the (still non existing) package-reporter logs:
sudo tail -F /var/log/landscape/package-reporter.log
* in another terminal, tail the (still non existing) broker log:
sudo tail -F /var/log/landscape/broker.log
* register the client with a landscape server. In this example we are going to use landscape.canonical.com and the proxy we just configured (replace <proxy> with the IP of the squid container we created above):
sudo landscape-config -a <youraccount> -u https://landscape.canonical.com/message-system --ping-url http://landscape.canonical.com/ping -t sru-proxy-test --silent --http-proxy=http://<proxy>:3128/ --https-proxy=http://<proxy>:3128/
* the proxy access logs should show some activity already:
1511531199.415 1230 127.0.0.1 TCP_TUNNEL/200 4474 CONNECT landscape.canonical.com:443 - HIER_DIRECT/91.189.89.90 -
1511531229.909 485 127.0.0.1 TCP_MISS/200 357 POST http://landscape.canonical.com/ping - HIER_DIRECT/91.189.89.90 text/html
That's the registration request (port 443) and the ping (port 80)
* go to landscape.canonical.com, login and accept the new pending computer we just created
* monitor package-reporter.log. At some point it should log that it downloaded the hash-id-database:
2017-11-24 14:31:24,203 INFO [MainThread] Downloaded hash=>id database from https://landscape.canonical.com/hash-id-databases/af6f2dcf-1967-11de-8dd0-001a4b4d8d10_xenial_amd64
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.
[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://bazaar.launchpad.net/~landscape/landscape-client/trunk/revision/919
This PPA has test packages built from these branches, using a ~ppaN suffix:
https://launchpad.net/~ahasenack/+archive/ubuntu/lsclient-sru-1721383
--- Original description ---
The package reporter is not getting the proxy settings set in /etc/landscape/client.conf. It will honor the environment variables if they are somehow set when landscape-client is started, but not if the values are just defined in that configuration file.
As a result, the following fails:
- fetching hash-id-database file
- running the SUID root /usr/lib/landscape/apt-update helper. Even though the binary it calls in turn fails (apt-get itself), the exit code is 0. It's only seen in the logs if using debug mode.
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/landscape/apt-update' exited with status 0 (out='Err http://archive.ubuntu.com trusty InRelease
Err http://archive.ubuntu.com trusty-updates InRelease
Err http://archive.ubuntu.com trusty-security InRelease
Err http://archive.ubuntu.com trusty Release.gpg
Unable to connect to archive.ubuntu.com:http:
Err http://archive.ubuntu.com trusty-updates Release.gpg
Unable to connect to archive.ubuntu.com:http:
Err http://archive.ubuntu.com trusty-security Release.gpg
Unable to connect to archive.ubuntu.com:http:
Reading package lists...
', err='W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty/InRelease
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty-updates/InRelease
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty-security/InRelease
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty/Release.gpg Unable to connect to archive.ubuntu.com:http:
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty-updates/Release.gpg Unable to connect to archive.ubuntu.com:http:
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty-security/Release.gpg Unable to connect to archive.ubuntu.com: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.canonical.com port 443: Connection refused
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. |
[Impact]
The package reporter is not getting the proxy settings set in /etc/landscape/client.conf. As a result, fetching hash-id-database file and running the SUID root /usr/lib/landscape/apt-update helper fail. Even though the binary it calls in turn fails (apt-get itself), the exit code is 0. It's only seen in the logs if using debug mode.
[Test Case]
Here we want to block direct access from a client to landscape.canonical.com and the ubuntu archive, forcing it to use a proxy we will setup. That's how we will determine that the bug is fixed.
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/client.conf and make sure this line is there:
log_level = debug
* Block direct access to landscape.canonical.com:
for ip in $(dig +short landscape.canonical.com); do sudo iptables -A OUTPUT -d $ip -j REJECT; done
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.canonical.com 80
Trying 91.189.90.173...
Trying 91.189.89.90...
telnet: Unable to connect to remote host: Connection refused
$ telnet landscape.canonical.com 443
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://br.archive.ubuntu.com/ubuntu xenial InRelease
Cannot initiate the connection to br.archive.ubuntu.com:80 (2801:82:80ff:8000::5). - connect (101: Network is unreachable) [IP: 2801:82:80ff:8000::5 80]
* In a xenial container, install the squid proxy server:
sudo apt install squid3
* Take note of the IP of this container
* Edit /etc/squid/squid.conf and make these changes:
- 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/squid/access.log
* Go back to the landscape-client container
* Verify that the proxy is allowing your connections, and that without the proxy it fails:
ubuntu@xenial-client-sru:~$ http_proxy=http://xenial-proxy.lxd:3128/ curl http://landscape.canonical.com/ping ;echo
ds5:errors19:provide insecure_id;
ubuntu@xenial-client-sru:~$ curl http://landscape.canonical.com/ping ;echo
curl: (7) Failed to connect to landscape.canonical.com port 80: Connection refused
* Same for https:
ubuntu@xenial-client-sru:~$ https_proxy=http://xenial-proxy.lxd:3128 curl https://landscape.canonical.com/message-system;echo
Landscape message server
ubuntu@xenial-client-sru:~$ curl https://landscape.canonical.com/message-system;echo
curl: (7) Failed to connect to landscape.canonical.com port 443: Connection refused
* in a terminal, tail the (still non existing) package-reporter logs:
sudo tail -F /var/log/landscape/package-reporter.log
* in another terminal, tail the (still non existing) broker log:
sudo tail -F /var/log/landscape/broker.log
* register the client with a landscape server. In this example we are going to use landscape.canonical.com and the proxy we just configured (replace <proxy> with the IP of the squid container we created above):
sudo landscape-config -a <youraccount> -u https://landscape.canonical.com/message-system --ping-url http://landscape.canonical.com/ping -t sru-proxy-test --silent --http-proxy=http://<proxy>:3128/ --https-proxy=http://<proxy>:3128/ --apt-update-interval=300
* the proxy access logs should show some activity already:
1511531199.415 1230 127.0.0.1 TCP_TUNNEL/200 4474 CONNECT landscape.canonical.com:443 - HIER_DIRECT/91.189.89.90 -
1511531229.909 485 127.0.0.1 TCP_MISS/200 357 POST http://landscape.canonical.com/ping - HIER_DIRECT/91.189.89.90 text/html
That's the registration request (port 443) and the ping (port 80)
* go to landscape.canonical.com, login and accept the new pending computer we just created
* monitor package-reporter.log. At some point it should log that it downloaded the hash-id-database:
2017-11-24 14:31:24,203 INFO [MainThread] Downloaded hash=>id database from https://landscape.canonical.com/hash-id-databases/af6f2dcf-1967-11de-8dd0-001a4b4d8d10_xenial_amd64
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.
[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://bazaar.launchpad.net/~landscape/landscape-client/trunk/revision/919
This PPA has test packages built from these branches, using a ~ppaN suffix:
https://launchpad.net/~ahasenack/+archive/ubuntu/lsclient-sru-1721383
--- Original description ---
The package reporter is not getting the proxy settings set in /etc/landscape/client.conf. It will honor the environment variables if they are somehow set when landscape-client is started, but not if the values are just defined in that configuration file.
As a result, the following fails:
- fetching hash-id-database file
- running the SUID root /usr/lib/landscape/apt-update helper. Even though the binary it calls in turn fails (apt-get itself), the exit code is 0. It's only seen in the logs if using debug mode.
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/landscape/apt-update' exited with status 0 (out='Err http://archive.ubuntu.com trusty InRelease
Err http://archive.ubuntu.com trusty-updates InRelease
Err http://archive.ubuntu.com trusty-security InRelease
Err http://archive.ubuntu.com trusty Release.gpg
Unable to connect to archive.ubuntu.com:http:
Err http://archive.ubuntu.com trusty-updates Release.gpg
Unable to connect to archive.ubuntu.com:http:
Err http://archive.ubuntu.com trusty-security Release.gpg
Unable to connect to archive.ubuntu.com:http:
Reading package lists...
', err='W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty/InRelease
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty-updates/InRelease
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty-security/InRelease
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty/Release.gpg Unable to connect to archive.ubuntu.com:http:
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty-updates/Release.gpg Unable to connect to archive.ubuntu.com:http:
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty-security/Release.gpg Unable to connect to archive.ubuntu.com: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.canonical.com port 443: Connection refused
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. |
|
| 2017-11-24 14:37:52 |
Andreas Hasenack |
description |
[Impact]
The package reporter is not getting the proxy settings set in /etc/landscape/client.conf. As a result, fetching hash-id-database file and running the SUID root /usr/lib/landscape/apt-update helper fail. Even though the binary it calls in turn fails (apt-get itself), the exit code is 0. It's only seen in the logs if using debug mode.
[Test Case]
Here we want to block direct access from a client to landscape.canonical.com and the ubuntu archive, forcing it to use a proxy we will setup. That's how we will determine that the bug is fixed.
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/client.conf and make sure this line is there:
log_level = debug
* Block direct access to landscape.canonical.com:
for ip in $(dig +short landscape.canonical.com); do sudo iptables -A OUTPUT -d $ip -j REJECT; done
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.canonical.com 80
Trying 91.189.90.173...
Trying 91.189.89.90...
telnet: Unable to connect to remote host: Connection refused
$ telnet landscape.canonical.com 443
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://br.archive.ubuntu.com/ubuntu xenial InRelease
Cannot initiate the connection to br.archive.ubuntu.com:80 (2801:82:80ff:8000::5). - connect (101: Network is unreachable) [IP: 2801:82:80ff:8000::5 80]
* In a xenial container, install the squid proxy server:
sudo apt install squid3
* Take note of the IP of this container
* Edit /etc/squid/squid.conf and make these changes:
- 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/squid/access.log
* Go back to the landscape-client container
* Verify that the proxy is allowing your connections, and that without the proxy it fails:
ubuntu@xenial-client-sru:~$ http_proxy=http://xenial-proxy.lxd:3128/ curl http://landscape.canonical.com/ping ;echo
ds5:errors19:provide insecure_id;
ubuntu@xenial-client-sru:~$ curl http://landscape.canonical.com/ping ;echo
curl: (7) Failed to connect to landscape.canonical.com port 80: Connection refused
* Same for https:
ubuntu@xenial-client-sru:~$ https_proxy=http://xenial-proxy.lxd:3128 curl https://landscape.canonical.com/message-system;echo
Landscape message server
ubuntu@xenial-client-sru:~$ curl https://landscape.canonical.com/message-system;echo
curl: (7) Failed to connect to landscape.canonical.com port 443: Connection refused
* in a terminal, tail the (still non existing) package-reporter logs:
sudo tail -F /var/log/landscape/package-reporter.log
* in another terminal, tail the (still non existing) broker log:
sudo tail -F /var/log/landscape/broker.log
* register the client with a landscape server. In this example we are going to use landscape.canonical.com and the proxy we just configured (replace <proxy> with the IP of the squid container we created above):
sudo landscape-config -a <youraccount> -u https://landscape.canonical.com/message-system --ping-url http://landscape.canonical.com/ping -t sru-proxy-test --silent --http-proxy=http://<proxy>:3128/ --https-proxy=http://<proxy>:3128/ --apt-update-interval=300
* the proxy access logs should show some activity already:
1511531199.415 1230 127.0.0.1 TCP_TUNNEL/200 4474 CONNECT landscape.canonical.com:443 - HIER_DIRECT/91.189.89.90 -
1511531229.909 485 127.0.0.1 TCP_MISS/200 357 POST http://landscape.canonical.com/ping - HIER_DIRECT/91.189.89.90 text/html
That's the registration request (port 443) and the ping (port 80)
* go to landscape.canonical.com, login and accept the new pending computer we just created
* monitor package-reporter.log. At some point it should log that it downloaded the hash-id-database:
2017-11-24 14:31:24,203 INFO [MainThread] Downloaded hash=>id database from https://landscape.canonical.com/hash-id-databases/af6f2dcf-1967-11de-8dd0-001a4b4d8d10_xenial_amd64
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.
[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://bazaar.launchpad.net/~landscape/landscape-client/trunk/revision/919
This PPA has test packages built from these branches, using a ~ppaN suffix:
https://launchpad.net/~ahasenack/+archive/ubuntu/lsclient-sru-1721383
--- Original description ---
The package reporter is not getting the proxy settings set in /etc/landscape/client.conf. It will honor the environment variables if they are somehow set when landscape-client is started, but not if the values are just defined in that configuration file.
As a result, the following fails:
- fetching hash-id-database file
- running the SUID root /usr/lib/landscape/apt-update helper. Even though the binary it calls in turn fails (apt-get itself), the exit code is 0. It's only seen in the logs if using debug mode.
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/landscape/apt-update' exited with status 0 (out='Err http://archive.ubuntu.com trusty InRelease
Err http://archive.ubuntu.com trusty-updates InRelease
Err http://archive.ubuntu.com trusty-security InRelease
Err http://archive.ubuntu.com trusty Release.gpg
Unable to connect to archive.ubuntu.com:http:
Err http://archive.ubuntu.com trusty-updates Release.gpg
Unable to connect to archive.ubuntu.com:http:
Err http://archive.ubuntu.com trusty-security Release.gpg
Unable to connect to archive.ubuntu.com:http:
Reading package lists...
', err='W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty/InRelease
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty-updates/InRelease
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty-security/InRelease
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty/Release.gpg Unable to connect to archive.ubuntu.com:http:
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty-updates/Release.gpg Unable to connect to archive.ubuntu.com:http:
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty-security/Release.gpg Unable to connect to archive.ubuntu.com: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.canonical.com port 443: Connection refused
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. |
[Impact]
The package reporter is not getting the proxy settings set in /etc/landscape/client.conf. As a result, fetching hash-id-database file and running the SUID root /usr/lib/landscape/apt-update helper fail. Even though the binary it calls in turn fails (apt-get itself), the exit code is 0. It's only seen in the logs if using debug mode.
[Test Case]
Here we want to block direct access from a client to landscape.canonical.com and the ubuntu archive, forcing it to use a proxy we will setup. That's how we will determine that the bug is fixed.
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/client.conf and make sure this line is there:
log_level = debug
* Block direct access to landscape.canonical.com:
for ip in $(dig +short landscape.canonical.com); do sudo iptables -A OUTPUT -d $ip -j REJECT; done
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.canonical.com 80
Trying 91.189.90.173...
Trying 91.189.89.90...
telnet: Unable to connect to remote host: Connection refused
$ telnet landscape.canonical.com 443
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://br.archive.ubuntu.com/ubuntu xenial InRelease
Cannot initiate the connection to br.archive.ubuntu.com:80 (2801:82:80ff:8000::5). - connect (101: Network is unreachable) [IP: 2801:82:80ff:8000::5 80]
* In a xenial container, install the squid proxy server:
sudo apt install squid3
* Take note of the IP of this container
* Edit /etc/squid/squid.conf and make these changes:
- 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/squid/access.log
* Go back to the landscape-client container
* Verify that the proxy is allowing your connections, and that without the proxy it fails:
ubuntu@xenial-client-sru:~$ http_proxy=http://xenial-proxy.lxd:3128/ curl http://landscape.canonical.com/ping ;echo
ds5:errors19:provide insecure_id;
ubuntu@xenial-client-sru:~$ curl http://landscape.canonical.com/ping ;echo
curl: (7) Failed to connect to landscape.canonical.com port 80: Connection refused
* Same for https:
ubuntu@xenial-client-sru:~$ https_proxy=http://xenial-proxy.lxd:3128 curl https://landscape.canonical.com/message-system;echo
Landscape message server
ubuntu@xenial-client-sru:~$ curl https://landscape.canonical.com/message-system;echo
curl: (7) Failed to connect to landscape.canonical.com port 443: Connection refused
* in a terminal, tail the (still non existing) package-reporter logs:
sudo tail -F /var/log/landscape/package-reporter.log
* in another terminal, tail the (still non existing) broker log:
sudo tail -F /var/log/landscape/broker.log
* register the client with a landscape server. In this example we are going to use landscape.canonical.com and the proxy we just configured (replace <proxy> with the IP of the squid container we created above):
sudo landscape-config -a <youraccount> -u https://landscape.canonical.com/message-system --ping-url http://landscape.canonical.com/ping -t sru-proxy-test --silent --http-proxy=http://<proxy>:3128/ --https-proxy=http://<proxy>:3128/ --apt-update-interval=300
* the proxy access logs should show some activity already:
1511531199.415 1230 127.0.0.1 TCP_TUNNEL/200 4474 CONNECT landscape.canonical.com:443 - HIER_DIRECT/91.189.89.90 -
1511531229.909 485 127.0.0.1 TCP_MISS/200 357 POST http://landscape.canonical.com/ping - HIER_DIRECT/91.189.89.90 text/html
That's the registration request (port 443) and the ping (port 80)
* go to landscape.canonical.com, login and accept the new pending computer we just created
* monitor package-reporter.log. At some point it should log that it downloaded the hash-id-database:
2017-11-24 14:31:24,203 INFO [MainThread] Downloaded hash=>id database from https://landscape.canonical.com/hash-id-databases/af6f2dcf-1967-11de-8dd0-001a4b4d8d10_xenial_amd64
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-reporter.log, keep an eye out for the apt run. Something like this indicates it worked:
2017-11-24 14:35:17,736 DEBUG [MainThread] '/usr/lib/landscape/apt-update' exited with status 0 (out='Hit:1 http://br.archive.ubuntu.com/ubuntu xenial InRelease
Hit:2 http://br.archive.ubuntu.com/ubuntu xenial-updates InRelease
Hit:3 http://br.archive.ubuntu.com/ubuntu xenial-backports InRelease
Hit:4 http://br.archive.ubuntu.com/ubuntu xenial-security InRelease
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://br.archive.ubuntu.com/ubuntu/dists/xenial/InRelease - HIER_DIRECT/200.236.31.4 -
1511534116.442 3 10.0.100.95 TCP_MISS/304 251 GET http://br.archive.ubuntu.com/ubuntu/dists/xenial-updates/InRelease - HIER_DIRECT/200.236.31.4 -
1511534116.445 3 10.0.100.95 TCP_MISS/304 251 GET http://br.archive.ubuntu.com/ubuntu/dists/xenial-backports/InRelease - HIER_DIRECT/200.236.31.4 -
1511534116.449 3 10.0.100.95 TCP_MISS/304 251 GET http://br.archive.ubuntu.com/ubuntu/dists/xenial-security/InRelease - HIER_DIRECT/200.236.31.4 -
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://bazaar.launchpad.net/~landscape/landscape-client/trunk/revision/919
This PPA has test packages built from these branches, using a ~ppaN suffix:
https://launchpad.net/~ahasenack/+archive/ubuntu/lsclient-sru-1721383
--- Original description ---
The package reporter is not getting the proxy settings set in /etc/landscape/client.conf. It will honor the environment variables if they are somehow set when landscape-client is started, but not if the values are just defined in that configuration file.
As a result, the following fails:
- fetching hash-id-database file
- running the SUID root /usr/lib/landscape/apt-update helper. Even though the binary it calls in turn fails (apt-get itself), the exit code is 0. It's only seen in the logs if using debug mode.
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/landscape/apt-update' exited with status 0 (out='Err http://archive.ubuntu.com trusty InRelease
Err http://archive.ubuntu.com trusty-updates InRelease
Err http://archive.ubuntu.com trusty-security InRelease
Err http://archive.ubuntu.com trusty Release.gpg
Unable to connect to archive.ubuntu.com:http:
Err http://archive.ubuntu.com trusty-updates Release.gpg
Unable to connect to archive.ubuntu.com:http:
Err http://archive.ubuntu.com trusty-security Release.gpg
Unable to connect to archive.ubuntu.com:http:
Reading package lists...
', err='W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty/InRelease
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty-updates/InRelease
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty-security/InRelease
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty/Release.gpg Unable to connect to archive.ubuntu.com:http:
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty-updates/Release.gpg Unable to connect to archive.ubuntu.com:http:
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty-security/Release.gpg Unable to connect to archive.ubuntu.com: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.canonical.com port 443: Connection refused
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. |
|
| 2017-11-24 15:37:10 |
Andreas Hasenack |
description |
[Impact]
The package reporter is not getting the proxy settings set in /etc/landscape/client.conf. As a result, fetching hash-id-database file and running the SUID root /usr/lib/landscape/apt-update helper fail. Even though the binary it calls in turn fails (apt-get itself), the exit code is 0. It's only seen in the logs if using debug mode.
[Test Case]
Here we want to block direct access from a client to landscape.canonical.com and the ubuntu archive, forcing it to use a proxy we will setup. That's how we will determine that the bug is fixed.
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/client.conf and make sure this line is there:
log_level = debug
* Block direct access to landscape.canonical.com:
for ip in $(dig +short landscape.canonical.com); do sudo iptables -A OUTPUT -d $ip -j REJECT; done
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.canonical.com 80
Trying 91.189.90.173...
Trying 91.189.89.90...
telnet: Unable to connect to remote host: Connection refused
$ telnet landscape.canonical.com 443
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://br.archive.ubuntu.com/ubuntu xenial InRelease
Cannot initiate the connection to br.archive.ubuntu.com:80 (2801:82:80ff:8000::5). - connect (101: Network is unreachable) [IP: 2801:82:80ff:8000::5 80]
* In a xenial container, install the squid proxy server:
sudo apt install squid3
* Take note of the IP of this container
* Edit /etc/squid/squid.conf and make these changes:
- 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/squid/access.log
* Go back to the landscape-client container
* Verify that the proxy is allowing your connections, and that without the proxy it fails:
ubuntu@xenial-client-sru:~$ http_proxy=http://xenial-proxy.lxd:3128/ curl http://landscape.canonical.com/ping ;echo
ds5:errors19:provide insecure_id;
ubuntu@xenial-client-sru:~$ curl http://landscape.canonical.com/ping ;echo
curl: (7) Failed to connect to landscape.canonical.com port 80: Connection refused
* Same for https:
ubuntu@xenial-client-sru:~$ https_proxy=http://xenial-proxy.lxd:3128 curl https://landscape.canonical.com/message-system;echo
Landscape message server
ubuntu@xenial-client-sru:~$ curl https://landscape.canonical.com/message-system;echo
curl: (7) Failed to connect to landscape.canonical.com port 443: Connection refused
* in a terminal, tail the (still non existing) package-reporter logs:
sudo tail -F /var/log/landscape/package-reporter.log
* in another terminal, tail the (still non existing) broker log:
sudo tail -F /var/log/landscape/broker.log
* register the client with a landscape server. In this example we are going to use landscape.canonical.com and the proxy we just configured (replace <proxy> with the IP of the squid container we created above):
sudo landscape-config -a <youraccount> -u https://landscape.canonical.com/message-system --ping-url http://landscape.canonical.com/ping -t sru-proxy-test --silent --http-proxy=http://<proxy>:3128/ --https-proxy=http://<proxy>:3128/ --apt-update-interval=300
* the proxy access logs should show some activity already:
1511531199.415 1230 127.0.0.1 TCP_TUNNEL/200 4474 CONNECT landscape.canonical.com:443 - HIER_DIRECT/91.189.89.90 -
1511531229.909 485 127.0.0.1 TCP_MISS/200 357 POST http://landscape.canonical.com/ping - HIER_DIRECT/91.189.89.90 text/html
That's the registration request (port 443) and the ping (port 80)
* go to landscape.canonical.com, login and accept the new pending computer we just created
* monitor package-reporter.log. At some point it should log that it downloaded the hash-id-database:
2017-11-24 14:31:24,203 INFO [MainThread] Downloaded hash=>id database from https://landscape.canonical.com/hash-id-databases/af6f2dcf-1967-11de-8dd0-001a4b4d8d10_xenial_amd64
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-reporter.log, keep an eye out for the apt run. Something like this indicates it worked:
2017-11-24 14:35:17,736 DEBUG [MainThread] '/usr/lib/landscape/apt-update' exited with status 0 (out='Hit:1 http://br.archive.ubuntu.com/ubuntu xenial InRelease
Hit:2 http://br.archive.ubuntu.com/ubuntu xenial-updates InRelease
Hit:3 http://br.archive.ubuntu.com/ubuntu xenial-backports InRelease
Hit:4 http://br.archive.ubuntu.com/ubuntu xenial-security InRelease
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://br.archive.ubuntu.com/ubuntu/dists/xenial/InRelease - HIER_DIRECT/200.236.31.4 -
1511534116.442 3 10.0.100.95 TCP_MISS/304 251 GET http://br.archive.ubuntu.com/ubuntu/dists/xenial-updates/InRelease - HIER_DIRECT/200.236.31.4 -
1511534116.445 3 10.0.100.95 TCP_MISS/304 251 GET http://br.archive.ubuntu.com/ubuntu/dists/xenial-backports/InRelease - HIER_DIRECT/200.236.31.4 -
1511534116.449 3 10.0.100.95 TCP_MISS/304 251 GET http://br.archive.ubuntu.com/ubuntu/dists/xenial-security/InRelease - HIER_DIRECT/200.236.31.4 -
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://bazaar.launchpad.net/~landscape/landscape-client/trunk/revision/919
This PPA has test packages built from these branches, using a ~ppaN suffix:
https://launchpad.net/~ahasenack/+archive/ubuntu/lsclient-sru-1721383
--- Original description ---
The package reporter is not getting the proxy settings set in /etc/landscape/client.conf. It will honor the environment variables if they are somehow set when landscape-client is started, but not if the values are just defined in that configuration file.
As a result, the following fails:
- fetching hash-id-database file
- running the SUID root /usr/lib/landscape/apt-update helper. Even though the binary it calls in turn fails (apt-get itself), the exit code is 0. It's only seen in the logs if using debug mode.
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/landscape/apt-update' exited with status 0 (out='Err http://archive.ubuntu.com trusty InRelease
Err http://archive.ubuntu.com trusty-updates InRelease
Err http://archive.ubuntu.com trusty-security InRelease
Err http://archive.ubuntu.com trusty Release.gpg
Unable to connect to archive.ubuntu.com:http:
Err http://archive.ubuntu.com trusty-updates Release.gpg
Unable to connect to archive.ubuntu.com:http:
Err http://archive.ubuntu.com trusty-security Release.gpg
Unable to connect to archive.ubuntu.com:http:
Reading package lists...
', err='W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty/InRelease
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty-updates/InRelease
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty-security/InRelease
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty/Release.gpg Unable to connect to archive.ubuntu.com:http:
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty-updates/Release.gpg Unable to connect to archive.ubuntu.com:http:
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty-security/Release.gpg Unable to connect to archive.ubuntu.com: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.canonical.com port 443: Connection refused
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. |
[Impact]
The package reporter is not getting the proxy settings set in /etc/landscape/client.conf. As a result, fetching hash-id-database file and running the SUID root /usr/lib/landscape/apt-update helper fail. Even though the binary it calls in turn fails (apt-get itself), the exit code is 0. It's only seen in the logs if using debug mode.
[Test Case]
Here we want to block direct access from a client to landscape.canonical.com and the ubuntu archive, forcing it to use a proxy we will setup. That's how we will determine that the bug is fixed.
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/client.conf and make sure this line is there:
log_level = debug
* Block direct access to landscape.canonical.com:
for ip in $(dig +short landscape.canonical.com); do sudo iptables -A OUTPUT -d $ip -j REJECT; done
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.canonical.com 80
Trying 91.189.90.173...
Trying 91.189.89.90...
telnet: Unable to connect to remote host: Connection refused
$ telnet landscape.canonical.com 443
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://br.archive.ubuntu.com/ubuntu xenial InRelease
Cannot initiate the connection to br.archive.ubuntu.com:80 (2801:82:80ff:8000::5). - connect (101: Network is unreachable) [IP: 2801:82:80ff:8000::5 80]
* In a xenial container, install the squid proxy server:
sudo apt install squid3
* Take note of the IP of this container
* Edit /etc/squid/squid.conf and make these changes:
- 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/squid/access.log
* Go back to the landscape-client container
* Verify that the proxy is allowing your connections, and that without the proxy it fails:
ubuntu@xenial-client-sru:~$ http_proxy=http://xenial-proxy.lxd:3128/ curl http://landscape.canonical.com/ping ;echo
ds5:errors19:provide insecure_id;
ubuntu@xenial-client-sru:~$ curl http://landscape.canonical.com/ping ;echo
curl: (7) Failed to connect to landscape.canonical.com port 80: Connection refused
* Same for https:
ubuntu@xenial-client-sru:~$ https_proxy=http://xenial-proxy.lxd:3128 curl https://landscape.canonical.com/message-system;echo
Landscape message server
ubuntu@xenial-client-sru:~$ curl https://landscape.canonical.com/message-system;echo
curl: (7) Failed to connect to landscape.canonical.com port 443: Connection refused
* in a terminal, tail the (still non existing) package-reporter logs:
sudo tail -F /var/log/landscape/package-reporter.log
* in another terminal, tail the (still non existing) broker log:
sudo tail -F /var/log/landscape/broker.log
* register the client with a landscape server. In this example we are going to use landscape.canonical.com and the proxy we just configured (replace <proxy> with the IP of the squid container we created above):
sudo landscape-config -a <youraccount> -u https://landscape.canonical.com/message-system --ping-url http://landscape.canonical.com/ping -t sru-proxy-test --silent --http-proxy=http://<proxy>:3128/ --https-proxy=http://<proxy>:3128/ --apt-update-interval=300
* the proxy access logs should show some activity already:
1511531199.415 1230 127.0.0.1 TCP_TUNNEL/200 4474 CONNECT landscape.canonical.com:443 - HIER_DIRECT/91.189.89.90 -
1511531229.909 485 127.0.0.1 TCP_MISS/200 357 POST http://landscape.canonical.com/ping - HIER_DIRECT/91.189.89.90 text/html
That's the registration request (port 443) and the ping (port 80)
* go to landscape.canonical.com, login and accept the new pending computer we just created
* monitor package-reporter.log. At some point it should log that it downloaded the hash-id-database:
2017-11-24 14:31:24,203 INFO [MainThread] Downloaded hash=>id database from https://landscape.canonical.com/hash-id-databases/af6f2dcf-1967-11de-8dd0-001a4b4d8d10_xenial_amd64
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-reporter.log, keep an eye out for the apt run. Something like this indicates it worked:
2017-11-24 14:35:17,736 DEBUG [MainThread] '/usr/lib/landscape/apt-update' exited with status 0 (out='Hit:1 http://br.archive.ubuntu.com/ubuntu xenial InRelease
Hit:2 http://br.archive.ubuntu.com/ubuntu xenial-updates InRelease
Hit:3 http://br.archive.ubuntu.com/ubuntu xenial-backports InRelease
Hit:4 http://br.archive.ubuntu.com/ubuntu xenial-security InRelease
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://br.archive.ubuntu.com/ubuntu/dists/xenial/InRelease - HIER_DIRECT/200.236.31.4 -
1511534116.442 3 10.0.100.95 TCP_MISS/304 251 GET http://br.archive.ubuntu.com/ubuntu/dists/xenial-updates/InRelease - HIER_DIRECT/200.236.31.4 -
1511534116.445 3 10.0.100.95 TCP_MISS/304 251 GET http://br.archive.ubuntu.com/ubuntu/dists/xenial-backports/InRelease - HIER_DIRECT/200.236.31.4 -
1511534116.449 3 10.0.100.95 TCP_MISS/304 251 GET http://br.archive.ubuntu.com/ubuntu/dists/xenial-security/InRelease - HIER_DIRECT/200.236.31.4 -
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://bazaar.launchpad.net/~landscape/landscape-client/trunk/revision/919
This PPA has test packages built from the attached branches, using a ~ppaN suffix:
https://launchpad.net/~ahasenack/+archive/ubuntu/lsclient-sru-1721383
--- Original description ---
The package reporter is not getting the proxy settings set in /etc/landscape/client.conf. It will honor the environment variables if they are somehow set when landscape-client is started, but not if the values are just defined in that configuration file.
As a result, the following fails:
- fetching hash-id-database file
- running the SUID root /usr/lib/landscape/apt-update helper. Even though the binary it calls in turn fails (apt-get itself), the exit code is 0. It's only seen in the logs if using debug mode.
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/landscape/apt-update' exited with status 0 (out='Err http://archive.ubuntu.com trusty InRelease
Err http://archive.ubuntu.com trusty-updates InRelease
Err http://archive.ubuntu.com trusty-security InRelease
Err http://archive.ubuntu.com trusty Release.gpg
Unable to connect to archive.ubuntu.com:http:
Err http://archive.ubuntu.com trusty-updates Release.gpg
Unable to connect to archive.ubuntu.com:http:
Err http://archive.ubuntu.com trusty-security Release.gpg
Unable to connect to archive.ubuntu.com:http:
Reading package lists...
', err='W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty/InRelease
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty-updates/InRelease
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty-security/InRelease
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty/Release.gpg Unable to connect to archive.ubuntu.com:http:
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty-updates/Release.gpg Unable to connect to archive.ubuntu.com:http:
W: Failed to fetch http://archive.ubuntu.com//ubuntu/dists/trusty-security/Release.gpg Unable to connect to archive.ubuntu.com: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.canonical.com port 443: Connection refused
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. |
|
| 2017-11-24 18:19:59 |
Andreas Hasenack |
landscape-client (Ubuntu Trusty): status |
New |
In Progress |
|
| 2017-11-24 18:20:02 |
Andreas Hasenack |
landscape-client (Ubuntu Xenial): status |
New |
In Progress |
|
| 2017-11-24 18:20:05 |
Andreas Hasenack |
landscape-client (Ubuntu Zesty): status |
New |
In Progress |
|
| 2017-11-24 18:20:08 |
Andreas Hasenack |
landscape-client (Ubuntu Artful): status |
New |
In Progress |
|
| 2017-11-24 18:20:11 |
Andreas Hasenack |
landscape-client (Ubuntu Trusty): assignee |
|
Andreas Hasenack (ahasenack) |
|
| 2017-11-24 18:20:13 |
Andreas Hasenack |
landscape-client (Ubuntu Xenial): assignee |
|
Andreas Hasenack (ahasenack) |
|
| 2017-11-24 18:20:15 |
Andreas Hasenack |
landscape-client (Ubuntu Zesty): assignee |
|
Andreas Hasenack (ahasenack) |
|
| 2017-11-24 18:20:17 |
Andreas Hasenack |
landscape-client (Ubuntu Artful): assignee |
|
Andreas Hasenack (ahasenack) |
|
| 2017-11-27 16:17:23 |
Łukasz Zemczak |
landscape-client (Ubuntu Artful): status |
In Progress |
Fix Committed |
|
| 2017-11-27 16:17:25 |
Łukasz Zemczak |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2017-11-27 16:17:28 |
Łukasz Zemczak |
bug |
|
|
added subscriber SRU Verification |
| 2017-11-27 16:17:32 |
Łukasz Zemczak |
tags |
bug-squad lds-squad patch proxy theme-proxy |
bug-squad lds-squad patch proxy theme-proxy verification-needed verification-needed-artful |
|
| 2017-11-27 16:27:12 |
Łukasz Zemczak |
landscape-client (Ubuntu Zesty): status |
In Progress |
Fix Committed |
|
| 2017-11-27 16:27:18 |
Łukasz Zemczak |
tags |
bug-squad lds-squad patch proxy theme-proxy verification-needed verification-needed-artful |
bug-squad lds-squad patch proxy theme-proxy verification-needed verification-needed-artful verification-needed-zesty |
|
| 2017-11-27 16:32:19 |
Łukasz Zemczak |
landscape-client (Ubuntu Xenial): status |
In Progress |
Fix Committed |
|
| 2017-11-27 16:32:25 |
Łukasz Zemczak |
tags |
bug-squad lds-squad patch proxy theme-proxy verification-needed verification-needed-artful verification-needed-zesty |
bug-squad lds-squad patch proxy theme-proxy verification-needed verification-needed-artful verification-needed-xenial verification-needed-zesty |
|
| 2017-11-27 16:38:38 |
Łukasz Zemczak |
landscape-client (Ubuntu Trusty): status |
In Progress |
Fix Committed |
|
| 2017-11-27 16:38:44 |
Łukasz Zemczak |
tags |
bug-squad lds-squad patch proxy theme-proxy verification-needed verification-needed-artful verification-needed-xenial verification-needed-zesty |
bug-squad lds-squad patch proxy theme-proxy verification-needed verification-needed-artful verification-needed-trusty verification-needed-xenial verification-needed-zesty |
|
| 2017-12-01 21:20:24 |
Mathew Hodson |
landscape-client (Ubuntu): importance |
Undecided |
High |
|
| 2017-12-01 21:20:27 |
Mathew Hodson |
landscape-client (Ubuntu Trusty): importance |
Undecided |
High |
|
| 2017-12-01 21:20:29 |
Mathew Hodson |
landscape-client (Ubuntu Xenial): importance |
Undecided |
High |
|
| 2017-12-01 21:20:31 |
Mathew Hodson |
landscape-client (Ubuntu Zesty): importance |
Undecided |
High |
|
| 2017-12-01 21:20:33 |
Mathew Hodson |
landscape-client (Ubuntu Artful): importance |
Undecided |
High |
|
| 2017-12-04 14:55:04 |
David Coronel |
attachment added |
|
Screenshot bug 1531150.png https://bugs.launchpad.net/landscape-client/+bug/1531150/+attachment/5018292/+files/Screenshot%20bug%201531150.png |
|
| 2017-12-04 19:20:50 |
Eric Desrochers |
tags |
bug-squad lds-squad patch proxy theme-proxy verification-needed verification-needed-artful verification-needed-trusty verification-needed-xenial verification-needed-zesty |
bug-squad lds-squad patch proxy theme-proxy verification-done-artful verification-done-trusty verification-done-xenial verification-done-zesty verification-needed |
|
| 2017-12-05 15:18:11 |
Launchpad Janitor |
landscape-client (Ubuntu Artful): status |
Fix Committed |
Fix Released |
|
| 2017-12-05 15:18:22 |
Łukasz Zemczak |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
| 2017-12-05 15:19:19 |
Launchpad Janitor |
landscape-client (Ubuntu Zesty): status |
Fix Committed |
Fix Released |
|
| 2017-12-05 15:20:11 |
Launchpad Janitor |
landscape-client (Ubuntu Xenial): status |
Fix Committed |
Fix Released |
|
| 2017-12-05 15:20:30 |
Launchpad Janitor |
landscape-client (Ubuntu Trusty): status |
Fix Committed |
Fix Released |
|
