Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 29 replies
  • Subscribers 3 subscribers
  • Views 9382 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

7.102 up2date is out...

BrucekConvergent
Up2Date 7.102 package description:

Remarks:
 Middleware will be restarted
 HTTP daemon will be restarted
 Confd will be restarted
 AUA will be restarted

News:
 This is a bugfix release
 Added auditor role for WebAdmin for read only access of reports and logfiles
 Added new report for blocked websites by users, domains, categories, and more
 Improved High Availability functions regarding IPsec VPN, Up2Date and config sync
 Improved HTTP Proxy with lots of small fixes
 Improved IPsec Livelog viewer for resolving internal references to tunnel names
 Removed connection tracking helper for MMS from Advanced Packetfilter options.

Bugfixes:
 Fix [7097]: Nics listed twice in WebAdmin overview
 Fix [7314]: Bridge can not be disabled after importing a backup
 Fix [7475]: IPsec starting in wrong mode after restart of HA system
 Fix [7483]: Lots of config changes cause SMTP restarts
 Fix [7569]: Unresolved HTTP parent proxy kills the backend system

RPM packages contained:
 csync2-1.30-14.i686.rpm                           
 ctsyncd-0.9.1-3.i686.rpm                          
 chroot-dhcps-7.1-34.i686.rpm                      
 chroot-ha_proxy-2.5-42.i686.rpm                   
 chroot-ipsec-7.1-2.i686.rpm                       
 iftop-0.16-32.2.i686.rpm                          
 libnetfilter_log-0.0.13-13.i686.rpm               
 ulogd-2.0.0beta-47.i686.rpm                       
 krb5-1.6.2-6.i686.rpm                             
 ep-init-7.1-159.i686.rpm                          
 ep-libs-7.1-155.i686.rpm                          
 ep-mdw-7.1-294.i686.rpm                           
 ep-confd-7.1-342.i686.rpm                         
 ep-confd-tools-7.1-33.i686.rpm                    
 ep-webadmin-7.1-351.i686.rpm                      
 ep-backupconverter-7.1-30.i686.rpm                
 ep-toolbox-7.1-47.i686.rpm                        
 ep-aua-7.1-148.i686.rpm                           
 ep-selfmon-7.1-139.i686.rpm                       
 ep-up2date-7.1-108.i686.rpm                       
 ep-up2date-downloader-7.1-104.i686.rpm            
 ep-up2date-system-install-7.1-113.i686.rpm        
 ep-syslog-ng-7.1-92.i686.rpm                      
 ep-notifier-db-7.1-53.i686.rpm                    
 ep-ha-7.1-231.i686.rpm                            
 ep-ha-daemon-7.1-151.i686.rpm                     
 ep-chroot-ha_proxy-7.1-15.i686.rpm                
 ep-httpproxy-2.0-68.i686.rpm                      
 ep-webadmin-contentmanager-7.1-81.i686.rpm        
 ep-cffd-0.50-223.i686.rpm                         
 ep-cffd-selfmon-0.50-223.i686.rpm                 
 ep-ha-confd-7.1-49.i686.rpm


This thread was automatically locked due to age.
Parents
  • 0
    Yah0000, I'm downloading it now [;)]
  • 0 in reply to PabloDiablo
    After Update, i recieved an errorbox :

    Eval Error: Server returned error: Failed to execute method CallMethod: Can't use an undefined value as an ARRAY reference at /PerlApp/Role.pm line 173.

    Got this on 2 boxes, but it looks like 'cosmetic' bug.

    Gregor Kemter
  • 0 in reply to gkemter
    we had to wait almost two month for this so it must be a very good update..[:)]
  • 0 in reply to frufru
    After the update from V7.101 to V7.102, the mail quarantine system seems to be messed up.




  • 0 in reply to Copyright
    Hi,

    I updated my Astaro and it seems i don't have any issue.

    When will the ISO file being updated with new drivers? 
    I was waiting for an update to install Astaro on my new server... (NIC is not recognize by 7.100)

    Thanks,
  • 0 in reply to nda
    Well, we have applied the update to our ASG 320's and now we cannot log into the Web Frontend of the ASG.  Not good.  I've restarted the aua daemon / process and this doesn't seem to fix the issue.

    Ben
  • 0 in reply to Copyright
    After the update from V7.101 to V7.102, the mail quarantine system seems to be messed up.
    http://rapidshare.de/files/38581188/ASG320_V7.102_Quarantine_2.JPG.html


    Try to restart the smtp proxy.
  • 0 in reply to koma
    Try to restart the smtp proxy.


    Hello Manfred

    I did restarts of both ASG's after the update. Because of your hint I restarted the smtp proxy again, but no change. I still get the same two errors and no stats on the Quarantine Manager.

    Regards
    David
  • 0 in reply to Copyright
    Update is not finaly done! (ASG 220 V7.101 -> V7.102)
    Up2Date package installation failed!

    View log files:
    2008:02:15-14:28:10 (none) auisys[8043]: 4. main::top-level:34() auisys.pl
    2008:02:15-14:28:10 (none) auisys[8043]: |=========================================================================
    2008:02:15-14:28:10 (none) auisys[8043]: id="371O" severity="error" sys="system" sub="up2date" name="Fatal: Up2Date package installation failed: An error occured during the RPM pre-installation test (1)" status="failed" action="install" code="1" package="sys"
    2008:02:15-14:28:10 (none) auisys[8043]:
    2008:02:15-14:28:10 (none) auisys[8043]: 1. main::alf:72() auisys.pl
    2008:02:15-14:28:10 (none) auisys[8043]: 2. main:[:P]erform_work:1067() auisys.pl
    2008:02:15-14:28:10 (none) auisys[8043]: 3. main::auisys_prepare_and_work:519() auisys.pl
    2008:02:15-14:28:10 (none) auisys[8043]: 4. main::top-level:34() auisys.pl
    2008:02:15-14:28:12 (none) auisys[8043]: 
Reply
  • 0 in reply to Copyright
    Update is not finaly done! (ASG 220 V7.101 -> V7.102)
    Up2Date package installation failed!

    View log files:
    2008:02:15-14:28:10 (none) auisys[8043]: 4. main::top-level:34() auisys.pl
    2008:02:15-14:28:10 (none) auisys[8043]: |=========================================================================
    2008:02:15-14:28:10 (none) auisys[8043]: id="371O" severity="error" sys="system" sub="up2date" name="Fatal: Up2Date package installation failed: An error occured during the RPM pre-installation test (1)" status="failed" action="install" code="1" package="sys"
    2008:02:15-14:28:10 (none) auisys[8043]:
    2008:02:15-14:28:10 (none) auisys[8043]: 1. main::alf:72() auisys.pl
    2008:02:15-14:28:10 (none) auisys[8043]: 2. main:[:P]erform_work:1067() auisys.pl
    2008:02:15-14:28:10 (none) auisys[8043]: 3. main::auisys_prepare_and_work:519() auisys.pl
    2008:02:15-14:28:10 (none) auisys[8043]: 4. main::top-level:34() auisys.pl
    2008:02:15-14:28:12 (none) auisys[8043]: 
Children
  • 0 in reply to KDS
    V7.102 went smooth and easy for me as well...
  • 0 in reply to Jayson
    I think will update will update my ASG220 as well
  • 0 in reply to n0c9
    After some checks through Astaro support (but no changes as far as I know) and one more reboot, due to an external power failure, the mail quarantine system seems to go back to normal and works as expected again.

    Thanks to Astaro support for your fast help.

    David
  • 0 in reply to KDS
    Update is not finaly done! (ASG 220 V7.101 -> V7.102)
    Up2Date package installation failed!

    View log files:
    2008:02:15-14:28:10 (none) auisys[8043]: 4. main::top-level:34() auisys.pl
    2008:02:15-14:28:10 (none) auisys[8043]: |=========================================================================
    2008:02:15-14:28:10 (none) auisys[8043]: id="371O" severity="error" sys="system" sub="up2date" name="Fatal: Up2Date package installation failed: An error occured during the RPM pre-installation test (1)" status="failed" action="install" code="1" package="sys"
    2008:02:15-14:28:10 (none) auisys[8043]:
    2008:02:15-14:28:10 (none) auisys[8043]: 1. main::alf:72() auisys.pl
    2008:02:15-14:28:10 (none) auisys[8043]: 2. main:[:P]erform_work:1067() auisys.pl
    2008:02:15-14:28:10 (none) auisys[8043]: 3. main::auisys_prepare_and_work:519() auisys.pl
    2008:02:15-14:28:10 (none) auisys[8043]: 4. main::top-level:34() auisys.pl
    2008:02:15-14:28:12 (none) auisys[8043]: 


    try auisys.plx --rpmargs --force
  • 0 in reply to cotto
    Upgraded tonight and no probs. Tomorrow will be the test, when the staff horde is in and belting the server.
  • 0 in reply to cotto
    try auisys.plx --rpmargs --force


    This didn't work for me, I had to use auisys.plx --rpmargs --force,--nodeps .

    Something to do with mdw-devel rpm file conflict.
  • 0 in reply to ReD-MaN
    This didn't work for me, I had to use auisys.plx --rpmargs --force,--nodeps .

    Something to do with mdw-devel rpm file conflict.


    The ep-mdw-devel rpm only is installed when a script is run by support to install additional packages for debugging. You can safely remove it, it is not necessary and will conflict with any upcoming up2date containing a new middleware rpm. 

    Cheers,
     andreas
  • 0 in reply to andreas
    I have also had the DHCP service fail (v7.102 and v7.103)

    From what i have able to determine the dhcpd service is attempting to hand the  client an address but is getting an ICMP response indicating the IP is in use so it marks the IP as in use and abandons it.  It then moves on to the next IP.

    From my DHCP log:
    2008:02:19-13:53:32 (none) dhcpd: Abandoning IP address 10.10.0.115: pinged before offer
    2008:02:19-13:53:37 (none) dhcpd: DHCPDISCOVER from 00:1e:4c:73:21:7f via eth2
    2008:02:19-13:53:37 (none) dhcpd: ICMP Echo reply while lease 10.10.0.114 valid.
    2008:02:19-13:53:37 (none) dhcpd: Abandoning IP address 10.10.0.114: pinged before offer
    2008:02:19-13:53:45 (none) dhcpd: DHCPDISCOVER from 00:1e:4c:73:21:7f via eth2
    2008:02:19-13:53:45 (none) dhcpd: ICMP Echo reply while lease 10.10.0.113 valid.
    2008:02:19-13:53:45 (none) dhcpd: Abandoning IP address 10.10.0.113: pinged before offer
    2008:02:19-13:54:02 (none) dhcpd: DHCPDISCOVER from 00:1e:4c:73:21:7f via eth2
    2008:02:19-13:54:02 (none) dhcpd: ICMP Echo reply while lease 10.10.0.112 valid.
    2008:02:19-13:54:02 (none) dhcpd: Abandoning IP address 10.10.0.112: pinged before offer 

    My dhcp lease table has each IP attempted assigned to the machine but without a mac address and the lease expires immediately.  So the whole table looks like this:

    [computer name a]  [unknown]  10.10.0.150  2008/02/19 21:40:42 UTC  2008/02/19 21:40:42 UTC
    [computer name a]  [unknown]  10.10.0.149  2008/02/19 21:40:50 UTC  2008/02/19 21:40:50 UTC

    So the dhcp server is receiving the request, but it isn't sending back a confirmation.  There are no devices on this network that would have any of the IP addresses it is attempting to hand out as this is a wireless network with only one other physical connection.  A reboot allowed me to connect one computer to it shortly after it came back up, but that was it.  Other devices set up the exact same way, but running v7.101 have no problem.
  • 0 in reply to towens
    Hmm. Interesting however, one thing I note. 

    DHCPDISCOVER from 00:1e:4c:73:21:7f via eth2
    2008:02:19-13:53:37 (none) dhcpd: ICMP Echo reply while lease 10.10.0.114 valid.
    2008:02:19-13:53:37 (none) dhcpd: Abandoning IP address 10.10.0.114: pinged before offer

    It looks like the client  is sending a discover from it's old IP, rather than doing a DHCPREQUEST for a new ip. IF you release the ip on the client machine, can it get a new ip then.

    This error: Abandoning IP address 10.10.0.114: pinged before offer
    Usually is harmless in of itself. As that is the dhcp server pinging that address to ensure no one is using it already, which in this case appears that it it either assigned statically to another machine in the network, and so the server abandons that IP, and attempts to find a new one.
  • 0 in reply to Wikked
    No a IP release/renew doesn't do anything other then a few more requests and then it self assigns an IP.

    While the Abandoning IP error is usually harmless it is a bit bizarre in this case.

    No clients are connected to this network.  I have the Astaro Port, assigned 10.10.0.1 and the wireless switch port 10.10.0.2 and that is it.  Nothing else is connected to it.  If I self assign a ip I can use the network as it was intended, but that isn't very useful for my wireless users.

    The lease table shows the IPs it is abandoning as assigned to the client attempting to get an address.  So for each of those DCHPDISCOVER requests and subsequent abandon message I get a record in the lease table showing that lease is assigned to the client that attempted to connect.

    Using wireshark on the the client machine shows me the DHCP Discover Packets, which aren't including a DHCPREQUEST and in the Astaro logs I see the corresponding response.

    On further investigation I have noticed that on the wireless switch a ping to a random address in the subnet returns nothing, but a ping on the firewall gives a response.  So I think this is more a Packet Filter rule gone wild, rather then a DHCP problem.  So I am currently looking in that direction.