Command "zypper ref" returns an HTTP 400 error in SUSE Manager 3.0 or 3.1 client.

This document (7018748) is provided subject to the disclaimer at the end of this document.

Environment

SUSE Manager 3

SUSE Manager 3 Proxy

SUSE Manager 3.1

SUSE Manager 3.1 Proxy

Situation

Any "zypper" command in a client connected to SUSE Manager or SUSE Manager Proxy returns the following error:

# zypper ref

Refreshing service 'spacewalk'.

Download (curl) error for 'https://xxxx.domain.company.net/XMLRPC/GET-REQ/reponame_xxxx/repodata/repomd.xml?head_requests=no':

Error code: HTTP response: 400

Error message: The requested URL returned error: 400


Abort, retry, ignore? [a/r/i/? shows all options] (a):

In the rhn logs, the following can be seen:

2017/03/23 13:44:32 +02:00 3969 10.10.191.160: xmlrpc/registration.register_osad

2017/03/23 13:44:32 +02:00 3970 10.10.191.160: xmlrpc/registration.register_osad_jid

2017/03/23 13:45:17 +02:00 4705 10.10.191.90: xmlrpc/registration.welcome_message('lang: None',)

2017/03/23 13:45:17 +02:00 4706 10.10.191.90: xmlrpc/registration.register_osad

2017/03/23 13:45:17 +02:00 4706 10.10.191.90: rhnServer/server_certificate.valid('Server id ID-1000010060 not found in database',)

Resolution

For existing clients connected already the process involves 4 stages :

1. Downgrade Apache2 on the SUMA server:

In case there is a SUSE Manager Proxy, the same command will need to be run on it, to avoid the same error happening with the clients behind the SUSE Manager Proxy.

It is possible to verify the previous versions of apache2 using the command "zypper search -s apache2"

Run the following command for SLES12SP1 based SUSE Manager 3.0 (3.1 should NOT be running under SP1):

zypper in --oldpackage apache2-2.4.16-12.1 apache2-prefork-2.4.16-12.1 apache2-utils-2.4.16-12.1

For SLES12SP2 based SUSE Manager 3.0 and 3.1:

zypper in --oldpackage apache2-2.4.23-16.3 apache2-prefork-2.4.23-16.3 apache2-utils-2.4.23-16.3

SLES12SP3 based installation should not be affected. Otherwise check the optional solution proposed in the end of the article.

2. Download the patches on the SUSE Manager server which contains the fix for all the clients:

mgr-sync refresh --refresh-channels

3. Distribute the patches to the client:

On the clients that are connected, run

zypper up zypper

It is also possible to use the WebUI to install the patch using SSM on all clients.

For details see the SUSE Manager Documentation.

4. Patch Apache2 on the SUSE Manager server which was downgraded earlier with Step 1:

zypper up apache2 apache2-prefork apache2-utils

Optionally instead of the above steps the following workaround can be used, which is to set http to unsafe by running:

echo "HttpProtocolOptions Unsafe" > /etc/apache2/conf.d/zypp-fix.conf
rcapache2 restart

Further information can be found here:

https://httpd.apache.org/docs/2.4/en/mod/core.html#httpprotocoloptions

Quoting an excerpt from the above link:

> Security risks of Unsafe
>
> Users are strongly cautioned against toggling the Unsafe mode of operation,
> particularly on outward-facing, publicly accessible server deployments.
> If an interface is required for faulty monitoring or other custom service
> consumers running on an intranet, users should toggle the Unsafe option only
> on a specific virtual host configured to service their internal private
> network

NOTE: The explained procedure will not help for clients that are not registered with SUSE Manager yet. Any such clients will need an update of zypper/yum, but that will not be possible as the clients don't have any way to get updates.

In order to bypass this problem, recreate bootstrap repository with command "mgr-create-bootstrap-repo". The command "mgr-bootstrap" (after another maintenance update) now makes sure of that when it generates the bootstrap script. However, it means that all the bootstrap scripts will need to be regenerated to include this change (after the package spacewalk-cert-tools has been updated to version 2.5.1.9-20.1 or higher).

Cause

Apache2 received a security update which resulted in stricter header checking.

Unfortunately the headers sent from the zypp-plugin are now considered bad requests, so clients can no longer communicate with the server, resulting in the error (error 400).

Additional Information

Disclaimer

This Support Knowledgebase provides a valuable tool for SUSE customers and parties interested in our products and solutions to acquire information, ideas and learn from one another. Materials are provided for informational, personal or non-commercial use within your organization and are presented "AS IS" WITHOUT WARRANTY OF ANY KIND.