[rudder-users] Migration from Rudder 4.2 to 4.3

[Janos Mattyasovszky]

Hi,
You could also please check out "openssl s_client -connect ${rudder_policy_server}:5309 </dev/null" on both policy server and node you try to connect from to see if you can in general connect to the host and see what SSL-Session is negotiated?

I for example have something similar:

SSL-Session:
    Protocol  : TLSv1.2
...

Cheers,

--
Janos Mattyasovszky

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On July 18, 2018 10:02 AM, Nicolas Charles <nicolas.charles at normation.com> wrote:

> Le 13/07/2018 à 11:30, GALLET Tristan a écrit :
>
>> Hello everybody,
>>
>> I’ve just migrated from Rudder 4.2 to 4.3.2. (not 4.3.3, Debian has not yet this version in the repository).
>>
>> Server and client are on Debian 8.11, all updates from today.
>>
>> After upgrade, clients can not update their policies :
>>
>> From a client :
>>
>> rudder agent update
>>
>> R: *********************************************************************************
>>
>> * rudder-agent could not get an updated configuration from the policy server.   *
>>
>> * This can be caused by:                                                        *
>>
>> *   * an agent key that has been changed                                        *
>>
>> *   * if this node is not accepted or deleted node on the Rudder root server    *
>>
>> *   * if this node has changed policy server without sending a new inventory    *
>>
>> * Any existing configuration policy will continue to be applied without change. *
>>
>> *********************************************************************************
>>
>> ok: Rudder agent promises were updated.
>>
>> From the serveur :
>>
>> rudder server debug 10.X.X.X
>>
>> Logs from server :
>>
>> rudder  verbose: 10.X.X.X> Setting IDENTITY: USERNAME=root
>>
>> rudder  verbose: 10.X.X.X> Received public key compares equal to the one we have stored
>>
>> rudder  verbose: 10.X.X.X> MD5=70b5b4d90fa8c1176cd2c1a00deb9884: Client is TRUSTED, public key MATCHES stored one.
>>
>> rudder  verbose: 10.X.X.X>      Received:    STAT /var/rudder/share/02dfe0b6-fee5-491a-96bb-95ecf27b07bb/rules/cfengine-community/rudder_promises_generated
>>
>> rudder  verbose: 10.X.X.X> Translated to:    STAT /var/rudder/share/02dfe0b6-fee5-491a-96bb-95ecf27b07bb/rules/cfengine-community/rudder_promises_generated
>>
>> rudder     info: 10.X.X.X> access denied to STAT: /var/rudder/share/02dfe0b6-fee5-491a-96bb-95ecf27b07bb/rules/cfengine-community/rudder_promises_generated
>>
>> rudder  verbose: 10.X.X.X> REFUSAL to user='root' of request: SYNCH 1531473776 STAT /var/rudder/share/02dfe0b6-fee5-491a-96bb-95ecf27b07bb/rules/cfengine-community/rudder_promises_generated
>>
>> rudder  verbose: 10.X.X.X>      Received:    STAT /usr/share/ncf/tree/ncf_hash_file
>>
>> rudder  verbose: 10.X.X.X> Translated to:    STAT /usr/share/ncf/tree/ncf_hash_file
>>
>> rudder  verbose: 10.X.X.X>      Received:     MD5 /usr/share/ncf/tree/ncf_hash_file
>>
>> rudder  verbose: 10.X.X.X> Translated to:     MD5 /usr/share/ncf/tree/ncf_hash_file
>>
>> rudder  verbose: 10.X.X.X>      Received:    STAT /var/rudder/configuration-repository/ncf/ncf_hash_file
>>
>> rudder  verbose: 10.X.X.X> Translated to:    STAT /var/rudder/configuration-repository/ncf/ncf_hash_file
>>
>> rudder  verbose: 10.X.X.X>      Received:     MD5 /var/rudder/configuration-repository/ncf/ncf_hash_file
>>
>> rudder  verbose: 10.X.X.X> Translated to:     MD5 /var/rudder/configuration-repository/ncf/ncf_hash_file
>>
>> rudder  verbose: 10.X.X.X>      Received:    STAT /var/rudder/tools/rudder_tools_updated
>>
>> rudder  verbose: 10.X.X.X> Translated to:    STAT /var/rudder/tools/rudder_tools_updated
>>
>> rudder  verbose: 10.X.X.X>      Received:     MD5 /var/rudder/tools/rudder_tools_updated
>>
>> rudder  verbose: 10.X.X.X> Translated to:     MD5 /var/rudder/tools/rudder_tools_updated
>>
>> rudder  verbose: 10.X.X.X> Remote peer terminated TLS session (SSL_read)
>>
>> rudder     info: 10.X.X.X> Closing connection, terminating thread
>>
>> DNS is ok, server and client resolve each other.
>>
>> Is there something to do after migration ?
>>
>> Regards
>>
>> Cordialement,
>>
>> Tristan
>
> Hi Tristan,
>
> Thank you very much for the detailed explanation and debug logs, it is very useful. I'm sorry for the delay in the answer, the mail was caught in a moderation zone :/
>
> Normally, there shouldn't be anything to do after an upgrade, so you are hitting a bug.
> We've encountered a very rare bug where inventories or keys could be lost during an upgrade, due to cache issue - it may be related to that. Can you do the following:
>
> - On the failing node, can you run
>
> rudder agent inventory
>
> - then, on the server Rudder, run:
>
> rudder agent inventory && rudder agent run
> to be sure that the Rudder server inventory is there and up to date.
>
> - trigger a full policies generation, by clicking on "Status" in the menu bar of Rudder, then "Regenerate all policies"
>
> - then, on the node, once the policy generation is finished, run
>
> rudder agent run -u
>
> If it doesn't work, we'll have to investigate further: did you have any error during the upgrade ? Do you have any "ERROR" in you /var/log/rudder/webapp folder, post-upgrade ?
> Does the file /var/rudder/share/02dfe0b6-fee5-491a-96bb-95ecf27b07bb/rules/cfengine-community/rudder_promises_generated exist on the server ?
>
> Thank you,
> Nicolas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.rudder-project.org/pipermail/rudder-users/attachments/20180718/4a0dd0a3/attachment-0001.html>