[SRU] Rampart's configuration on Ubuntu's package doesn't define a default ClockSkewBuffer

This issue was solved in Eucalyptus 2.0.3 (upstream) with the attached patch. It's just a 2 liners that ensure rampartC policy to be more lenient on the time difference.

Thanks for raising this graziano, and attaching a patch.. Am i correct in saying this should have been part of the security update?

Thanks.

Thanks for the quick answer! Yes it was part of our 2.0.3 release, which was a security release only. My understanding (which I can confirm if you want) is that with the addition of more stringent rules for rampartC, this second patch was needed to allow communication between components when the clocks were not perfectly synchronized.

Graziano

Will this effect eucalyptus 1.6 in lucid as well? or is it constrained to >= 2.0?

This bug was fixed in the package eucalyptus - 2.0.1+bzr1256-0ubuntu8

---------------
eucalyptus (2.0.1+bzr1256-0ubuntu8) oneiric; urgency=low

  * Fix compatibility issues with SSLv3 (LP: #851611):
    - d/patches/29-euca_conf-sslv3.patch: Use --secure-protocol=SSLv3
      with wget when communicating with CLC.
    - d/eucalyptus-cloud.upstart: Use --secure-protocol=SSLv3 with wget
      when checking for CLC startup complete.
  * d/patches/30-clock_drift.patch: Resolve issue with rampart blocking
    communication between CC and NC when time is fractionally in the
    future (LP: #854946):
 -- James Page <email address hidden> Wed, 21 Sep 2011 09:57:58 +0100

James,

for 1.6.2 (lucid) a similar set of patches were sent I think at about the same time, but I can be mistaken here. A cursory look seems to imply that they were not applied to Lucid. I am digging through my email graveyard to find them: I will forward them to you as soon as I find them.

Thanks for checking!

I stand corrected: Lucid has indeed all the correct patches applied.

Marking lucid task as invalid as this fix had already been applied.

Thanks for confirming that Graziano

Fixes for natty and maverick uploaded to -proposed queue and ready for ubuntu-sru team review.

Thanks

Hello Bfreis, or anyone else affected,

Accepted eucalyptus into natty-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

Hello.

I've just installed the update from natty-proposed on my 3 servers (2 NCs, 1 CC), and they seem to be fine. I will confirm if everything is still OK tomorrow, since the errors were intermittent.

It is the first time I use "-proposed", so I have a question: if everything goes smooth, and you publish this update to "main", will I have to do anything on my servers, like reinstall the packages, or somehow tell the system that the packages now come from "main" instead of "-proposed"? Will I be able to simply remove the "deb ... natty-proposed ..." line from /etc/apt/sources.list without destroying anything?

Thanks!

Excerpts from Bfreis's message of Mon Sep 26 19:55:40 UTC 2011:
> Hello.
>
> I've just installed the update from natty-proposed on my 3 servers (2
> NCs, 1 CC), and they seem to be fine. I will confirm if everything is
> still OK tomorrow, since the errors were intermittent.
>
> It is the first time I use "-proposed", so I have a question: if
> everything goes smooth, and you publish this update to "main", will I
> have to do anything on my servers, like reinstall the packages, or
> somehow tell the system that the packages now come from "main" instead
> of "-proposed"? Will I be able to simply remove the "deb ... natty-
> proposed ..." line from /etc/apt/sources.list without destroying
> anything?
>
> Thanks!

No, you won't have to do anything. Apt doesn't care where the latest
package comes from on upgrade, it just gets the latest package*.

* absent any apt-pinning or use of backports. ;)

Hello.

Just to inform that since yesterday after when I updated to the latest version available on natty-proposed the servers are running good, and have shown no symptoms of "messages from the future" being discarded (verified through the absence of the error logs I was seeing in /var/log/eucalytus/axis2c.log).

Thanks for all the support and promptitude on dealing with this issue!

Bruno

Hello Bfreis, or anyone else affected,

Accepted eucalyptus into maverick-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

This bug was fixed in the package eucalyptus - 2.0.1+bzr1256-0ubuntu4.2

---------------
eucalyptus (2.0.1+bzr1256-0ubuntu4.2) natty-proposed; urgency=low

  * d/patches/28-clock_drift.patch: Resolve issue with rampart blocking
    communication between CC and NC when time is fractionally in the
    future (LP: #854946).
 -- James Page <email address hidden> Mon, 26 Sep 2011 09:43:21 +0100