Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 29 replies
  • Subscribers 3 subscribers
  • Views 9403 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.
  • 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
    After applying the 7.102 update to my home firewall the DHCP server stopped working.  I use the Astaro box to hand out IP addresses.

    After installing the new release, and restarting the firewall, all of my computers lost network access and the network icon popped up in the taskbar with the yellow exclaimation mark saying that I had limited connectivity.

    After restarting the Astaro box, the computers would get an IP address but it would happen again every 15 minutes or so.  Restart Astaro, DHCP working again.

    I installed 7.100 and restored a backup.  DHCP still working since Friday.

    Anyone else have this happen?
  • 0 in reply to TXGARobert@Home
    Nope, DHCP still working fine on units configured with it.
  • 0 in reply to BrucekConvergent
    Maybe it was just some freaky thing.  Will take it back to 7.102 and see if it happens again.  It's why I have backups, I guess.
  • 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.
  • 0 in reply to towens
    And it turns out that all the wireless switches decided that it was 7 hours later then it really was, why I am not sure, as the are all synchronized using the same ntp server pool.  Why this occured at the same time as the ASG update I don't know yet either. 

    The client was grabbing this time and getting a DHCP lease that was expired, so it requested another one until it finally timeout and self assigned one.

    So this was completely unrelated to the ASG update, just a coincidence.