Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 15 replies
  • Subscribers 4 subscribers
  • Views 5631 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.205 Soft-Release

AlanT_01
Hi Everyone, 

we've just soft-released 9.205-12, and it should be available now on our ftp servers. Have a read below, to see what's included in this update.

Version: UTM 9.205012

News

  • Maintenance Release
  • Add support for next generation of 1XX, 5XX, and 6XX appliances


Remarks

  • System will be rebooted
  • Configuration will be upgraded


Bugfixes

  • 31901 Not possible to activate MSP licenses on SG appliances
  • 32048 Using a Reverse Authentication profile requires the 'Path' to end with a /
  • 32114 Transparent AD SSO fails after redirect page with "cannot assign requested address"
  • 32158 Transparent mode AD SSO should redirect to the hostname of the UTM, not the FQDN
  • 32238 ulogd restarts (BUG at ipfix.c:313 / BUG at thread.c:33 ) and coredumps
  • 32359 Transparent SSO not applying proper policy when using defined groups
  • 32364 Syntax error on line 1 of /usr/apache/conf/waf/modsecurity_crs_sql_injection_attacks.skip
  • 32380 Httpproxy EpollWorker segfault in send_request_headers ()
  • 32381 Httpproxy EpollWorker segfault in kernel_vsyscall (dns_lookup_proto)


Up2Date link: ftp://ftp.astaro.de/UTM/v9/up2date/u2d-sys-9.204020-205012.tgz.gpg
Md5sum:  ae641aa3c8af532ba82f379dbdbcaab3
File size: ~49 MB


This thread was automatically locked due to age.
  • 0
    ooo what are the next generation 1xx units? any one have any details?
  • 0 in reply to stealthmatt_01
    They'll replace the existing UTM1x0 Apps.

    There is more horsepower for several services. Actually i cant find the techspecs from the webinar, sorry. :-(

    They'll be out from september till december.
  • 0 in reply to ManuelKarl
    the ulogd ipfix fix seems to have spawned a new error...

    system.log: 
    2014:08:06-19:02:29 ****** ulogd[18343]: timerfd: read: Bad file descriptor


    selfmon.log: 
    2014:08:06-19:02:37 kay-asg selfmonng[3908]: I check Failed increment ulogd_running counter 1 - 3

    2014:08:06-19:02:42 kay-asg selfmonng[3908]: I check Failed increment ulogd_running counter 2 - 3

    2014:08:06-19:02:47 kay-asg selfmonng[3908]: W check Failed increment ulogd_running counter 3 - 3

    2014:08:06-19:02:48 kay-asg selfmonng[3908]: [INFO-114] Ulogd not running - restarted


    ...and this is with ipfix off
  • 0
    Any word on the VOIP helper bug?
  • 0
    @KSeemann that might be related to mantis 32449, which is being investigated internally so if you contact support on this issue, be sure to reference that ID.

    @NewImage I guess you mean this thread.. mlenk posted this morning that he just reported it to dev, so there won't be any update until they have a chance to investigate.
  • 0 in reply to AlanT_01
    Can you elaborate on;
    32238 ulogd restarts (BUG at ipfix.c:313 / BUG at thread.c:33 ) and coredumps

    We might have experienced this issue;
    - in a 2 node cluster, one node updated and after updating our network services were down. On the console the active node was reporting ok health, but none of the services worked.
    - After shutting down the node everything worked as expected.
    - When investigating the issue with our supplier (contec isc in the netherlands) we found a coredump. As the units have 16Gb of memory and a complete coredump was made, this had used all available diskspace. 

    How can we tell the #32238 is applicable for our issue?
  • 0
    @360ict, #32238 affects systems with ipfix enabled. If you're running ipfix, and seeing ulogd restarts, then you might be affected by 32238. In that case, instlaling 9.205 should repair the issue.
  • 0
    Yeah, that made my day! I'll mark this day in my calendar. 
    It's 1 year, 5 months since the #32238 has been reported by us.

    Oh... reading @KSeemann - lets wait if it's really a fix.
  • 0
    I just updated to 9.205-12, and now have what looks like a time zone issue. I have the time zone set to "US/New York", which is correct, but the time displayed is 3.5 hours lower. I've been playing around with other time zones, and the closest I have been able to get it is about 40 minutes and 30 seconds fast, by setting the time zone to "Europe/Lisbon".
  • 0
    @RChadwick check your NTP server settings, and try syncing the time again. sounds like your system clock is just off. 

    I guess you meant "America / New York", or "US / Eastern"? I use US / Eastern on most of my UTMs, and all are showing the correct time on 9.205

    *** Update ***
    I just updated one of my demo systems to double check, and it looks like I'm seeing something similar there. Reporting to dev.
Unfiltered HTML