[rudder-users] Migration from Rudder 4.2 to 4.3
Janos Mattyasovszky
mail at matya.eu
Wed Jul 18 08:24:49 UTC 2018
Ah sorry, I did not read this correctly, never mind my email, the TLS session is already established, the problem lies somewhere at permissions.
It could be that the node somehow lost it's identity and the cf-served does not allow it to download some files of it.
You might have to reset the node's public key and re-upload the inventory.
Janos
--
Janos Mattyasovszky
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On July 18, 2018 10:21 AM, Janos Mattyasovszky <mail at matya.eu> wrote:
> 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/89d722ba/attachment.html>
More information about the rudder-users
mailing list