Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 25 replies
  • Subscribers 2 subscribers
  • Views 12608 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

UTM 9.110 and 9.111 (Heartbleed Fix) Released

ebegoc
I'm pleased to announce that we today released two Up2Date versions:

UTM 9.110
This update merely adds support for new SSG line of hardware appliances
For details please visit UTM Up2Date 9.110 Released | Sophos Blog

UTM 9.111 - containing OpenSSL Heartbleed Vulnerability FIX
Most important fix in this release is for the formerly discovered vulnerability in OpenSSL. For details please visit UTM Up2Date 9.111 Released – FIX for OpenSSL vulnerability (Heartbleed) | Sophos Blog

And for a summary of all Sophos products affected by the OpenSSL vulnerability as well as some more details, make sure to check out our knowledge base: Advisory: Critical vulnerability found in OpenSSL affecting Sophos products

Last but not least: We are working hard to release a fix for UTM 9.2 - stay tuned...

Kind regards,
Eric


This thread was automatically locked due to age.
  • 0
    By BrucekConvergent

    Please pay attention:

    "If you choose to update to the latest version, with the UTM having downloaded 9.110 and 9.111, it fails [with] error.

    Gonna try installing 9.110 manually first, then 9.111 ... this really should work properly though."
  • 0 in reply to SmallAdmin
    By BrucekConvergent

    Please pay attention:

    "If you choose to update to the latest version, with the UTM having downloaded 9.110 and 9.111, it fails [with] error.

    Gonna try installing 9.110 manually first, then 9.111 ... this really should work properly though."


    Yes we saw the same thing. 9.109 boxes downloaded a useless 9.111. Trying the same thing as you and doing 9.110 first. Had to pull them from the Germany Mirror because the US one is not responding 

    We've got like 50 of these to do; here's hoping it works pushing from our SUM4 system.
  • 0 in reply to ratz
    Yes we saw the same thing. 9.109 boxes downloaded a useless 9.111. Trying the same thing as you and doing 9.110 first. Had to pull them from the Germany Mirror because the US one is not responding 

    We've got like 50 of these to do; here's hoping it works pushing from our SUM4 system.


    Interesting the failed unit; about 1 hour later re-downloaded the patch; automatically installed it and reboot without human intervention. That was odd on many levels. It worked; just started the users when it boot without warning.
  • 0
    Great job guys! 30+ UTM's patched and so far not 1 single issue.
  • 0
    My second node is stuck in state Up2Date after reboot:
    2014:04:09-19:57:35 fw01-1 ha_daemon[3764]: id="38A0" severity="info" sys="System" sub="ha" name="Access granted to remote node 2!"
    2014:04:09-19:57:38 fw01-1 ha_daemon[3764]: id="38A0" severity="info" sys="System" sub="ha" name="Node 2 joined with version 9.111007"
    2014:04:09-19:57:38 fw01-1 ha_daemon[3764]: id="38C0" severity="info" sys="System" sub="ha" name="Node 2 is alive!"
    2014:04:09-19:57:38 fw01-1 ha_daemon[3764]: id="38A0" severity="info" sys="System" sub="ha" name="Node 2 changed state: DEAD -> UP2DATE"

    So the first node won't start update. Any ideas?
  • 0 in reply to psturm
    Seconded.  I did two HA UTM425 clusters, and both had the second unit hang in Up2Date, but a reboot fixed it.  The third did what you describe, even after reboot and power cycle.  Platinum support ticket opened on it.

    My second node is stuck in state Up2Date after reboot:

    So the first node won't start update. Any ideas?
  • 0
    I have the same Problem as you two (slave stuck in up2date). We are using two utm 220 hot-standby. This is what i got from Support:


    Sorry for the inconvenience, we are aware of an issue with the automatic update, the current workaround is to manually update to 9.111 instead
    Please visit this link http://download.astaro.com/UTM/v9/up2date/ download this file located at the bottom of the page u2d-sys-9.110022-111007.tgz.gpg in order to manually update to 9.110 and then download  u2d-sys-9.111002-111007.tgz.gpg in order to manually update to 9.111...For bthe manual update you login to your webadmin -> Management -> Up2Date -> Advanced -> browse for the 9.110 file, start the upload, hit apply and then do the same for the 9.111 file.


    I have uploaded the two files but nothing changes on the master nor on the slave. The master shows 7 updates as before the upload. I also deleted the up2date package from /var/up2date/sys and reuploaded the two files. Same again only 7 updazes (i think there should be 8 isn't it?)
  • 0
    Here's the problem, the developers never had a situation where everyone wanted to Up2Date on an emergency basis.  The Up2Date had been downloaded by the Master, but the Master had yet to Up2Date the Slave.  The reboot only worked because the new master had had time to download the missing Up2Date.  

    There were other solutions. If you had gone to the command line of the Master and then to that of the Slave with ha_utils ssh, you could have done ls /var/up2dat/sys/* to check that both devices were ready to apply the Up2Date.   

    If you hadn't done that, you could use the instructions in the other thread to download the missing Up2Date to the current Master.  

    Cheers - Bob  

    Sorry for any short responses.  Posted from my iPhone.
  • 0
    Hi Bob

    The Master had the up2date packages at least 1 hour before i triggered the up2date process. At the moment the Master is at 9.104-17 with status ACTIVE and the Slave shows 9.111-7 with status UP2DATE.

    I can SSH into my slave with the ha_util but don't know what i can do. I've read the up2date log of the slave. There is nothing related to a failed installation. Everything seems to had worked perfectly, so why is the slave in the up2date state?
    up2date.zip
  • 0 in reply to solae
    The Master had the up2date packages at least 1 hour before i triggered the up2date process. At the moment the Master is at 9.104-17 with status ACTIVE and the Slave shows 9.111-7 with status UP2DATE.

    I can SSH into my slave with the ha_util but don't know what i can do. I've read the up2date log of the slave. There is nothing related to a failed installation. Everything seems to had worked perfectly, so why is the slave in the up2date state?


    Looks like the same issue I had with one of our clusters which has nothing to do with the failed updates mentioned here before.

    Is currently under investigation by the support team.