Soft-Release v7.402

Today we soft-released v7.402 on our FTP-Servers (ftp.astaro.de for sure). The GA release will follow a few days later, if everything goes well. Use the easter holidays to find out [:D]

Please check intensively, if your NIC sorting stays as expected. We updated Intel e1000 driver and integrated e1000e so there is still a small possibility something may go wrong although we tested that thoroughly.

Are only the drivers have been updated?
[LEFT]Can you provide the full list of changes in 7.402 version?[/LEFT]

Hi WaMar,


Up2Date 7.402 package description:

Remarks:
 Configuration will be upgraded
 System will be rebooted

News:
 Updated Intel e1000 driver - NIC ordering should not be affected, nevertheless please check after installation
 Updated SIP support for better integration
 Improved database maintenance processing times
 Improved Multipath to handle more than 64 rules
 Improved ACC integration

Bugfixes:
 Fix [7900]: VLAN sometimes fails on LAG devices
 Fix [9376]: Ipsec VPN tunnel not coming up after takeover
 Fix [10108]: ASG 525-F eth8 and eth9 may loose link
 Fix [10147]: IPsec tunnels with remote network 'Any' will not work
 Fix [10158]: Multipath persistence by connection not working properly
 Fix [10189]: Usergroups with umlauts are not working in HTTP Proxy profiles
 Fix [10200]: Problem with auto packetfilter rules for outgoing traffic

RPM packages contained:
 ulogd-2.0.1-18.i686.rpm                           
 chroot-ipsec-7.4-33.i686.rpm                      
 ddclient-3.7.3-8.i686.rpm                         
 kernel-default-2.6.16.62-110.i686.rpm             
 kernel-smp-2.6.16.62-110.i686.rpm                 
 iptables-1.3.5-24.i686.rpm                        
 libnfnetlink-0.0.39-3.i686.rpm                    
 libnetfilter_conntrack-0.0.99-3.i686.rpm          
 conntrack-tools-0.9.6-4.i686.rpm                  
 ctsyncd-0.9.3-12.i686.rpm                         
 chroot-smtp-7.4-199.i686.rpm                      
 ethtool-3-15.2.2.i686.rpm                         
 ep-init-7.4-185.i686.rpm                          
 ep-libs-7.4-225.i686.rpm                          
 ep-mdw-7.4-474.i686.rpm                           
 ep-confd-7.4-607.i686.rpm                         
 ep-webadmin-contentmanager-7.4-227.i686.rpm       
 ep-aua-7.4-210.i686.rpm                           
 ep-syslog-ng-7.4-114.i686.rpm                     
 ep-notifier-db-7.4-80.i686.rpm                    
 ep-reporting-7.4-283.i686.rpm                     
 ep-chroot-ipsec-7.4-62.i686.rpm                   
 ep-chroot-smtp-7.4-220.i686.rpm                   
 cm-nextgen-agent-7.4-59.i686.rpm                  
 ep-chroot-pop3-7.4-109.i686.rpm                   
 ep-httpproxy-2.1-175.i686.rpm                     
 ep-webadmin-7.4-635.i686.rpm                      
 ep-webadmin-languages-7.4-41.i686.rpm             
 ep-up2date-7.4-130.i686.rpm                       
 ep-up2date-downloader-7.4-118.i686.rpm            
 ep-tools-7.4-106.i686.rpm                         
 u2d-mpfc-7-1.i686.rpm                             
 ep-toolbox-7.4-59.i686.rpm                        
 kernel-bigsmp-2.6.16.62-110.i686.rpm              
 ep-asg-7.4-33.i686.rpm                            


Ian M

Hi Barry,
thank you for the warning, my plan for tomorrow was to put the vlan in place.

Still might try just for the experience. Glutton for punishment and knowledge.

Ian M

I'm now back on 7.401.

Begin rant:

1. restoring backup from USB key does not work for me.
I put file 'me.dyndns.org_7.401_2009-04-09_01-15.abf' into the root of a 128MB USB stick, FAT32 format, empty except for one empty directory
During boot, Astaro said
:: Backup restore (pause) :: Starting Notification daemon   done

Note both of those items were on the same line.
I tried rebooting twice with the key installed.
This isn't the best-quality USB key I have, but it was the only one that was empty. It's possible it's the key's fault, but a little more info from the firewall would have been nice.

2. must go through "Basic System Setup" before restoring backup from webmin
This is a nuisance and slows down restoring by a couple of minutes.

3. difficult to tell when backup reconfig is completed (beeps would be nice)

4. My IPSEC Site-to-Site VPNs did NOT reconnect after the restore. [:(]
The Site-to-Site VPN status page showed them as down.
I had to disable and re-enable the Connection, and now it works.

/rant

going back to bed...

Barry

I had forgotten that uploading via a browser is broken, at least for me.  When I left the office yesterday, I left my PC uploading into a test unit.  Just VPN'd into my desktop, logged into the test unit and confirmed that I still get no joy with manual uploads.

Given Barry's experience, it appears that I'm a lucky guy!

Hi Bob,

In reading some comments, with manual uploads you can't really just upload it and walk away. You navigate to the file and click save, and then the upload process begins. What is mistaken at times is you then have to click "apply" to finalize the application of dumping the up2date into the ASG.  So if you just walk away during the upload, the process will then timeout eventually.

Finally, once the upload has been done and "applied", you then will have anywhere from 15s to 1-2 minutes before the upload will show up in the up2date section to be applied, as it is extracted/verified/made ready for installation. 

The manual up2date process does not require the .md5 file at anytime in the process, we provide it simply for verification or troubleshooting.

Hope this is of use!

Right, Angelo, that is the way it's supposed to work.

What happens is that the file is apparently uploaded after you click [Save], but the process never completes.  My guess is that linux can't write the final directory entry that would allow it to close the new file in the Astaro.

odd, ive never seen that. I just tried now from 7.401 to 7.402 on an asg 120 and it worked as outlined...

This is a test machine, an ASG220 model 1.  Email me if you'd like to login and try it from there.

Bob, manual uploads of large up2date files (around 100MB or bigger) to a machine with less than 1GB of RAM has been a problem for quite a while (I believe it's on the KIL); I imagine that's the source of the problem you're having.  I have the same problems with older 110 / 220 units.  Any unit that I manage or use for testing that has 768 or 1GB works fine -- and, of course, the older units do download the up2date packages OK using the automatic up2date process, so they do eventually get updated as well.

What does concern me is the issue that Barry had with the VLANs... I'd like to hear more about this (I do have a few customers that use the VLAN feature).

Dear friends ,
 i have two asg installed at home 1st machine is intel 845 gvsr 512 mb share (video) and other is intel D945gclf  (with 2gb ram )on 1st system i am not able to update but with other (intel945) it work fine /update without any issues with manual update !


Thanks

Ahhh, yes, I remember that now.  I'll go hit my head against a different wall now.

Thanks very much Bruce - Bob

Ahhh, yes, I remember that now.  I'll go hit my head against a different wall now.

Thanks very much Bruce - Bob

utm_kid, see my last post; manual update of large up2date packages will fail on systems with low memory resources, and it is a known issue.  The automatic up2date process does still work fine, though.

Bruce, is there a work-around with ACC?  That might be a stimulus for me to get started on that installation.

utm_kid, see my last post; manual update of large up2date packages will fail on systems with low memory resources, and it is a known issue.  The automatic up2date process does still work fine, though.

Yes Sir , i tryed that also i stuck with error 512 i follow up2date troubleshooting also even send ticket to astaro also but no luck,some time back i tryed to update 7.4 to 7.401 ,

Thanks,

Bruce, is there a work-around with ACC?  That might be a stimulus for me to get started on that installation.

You know, you could try using the up2date cache on ACC and point the troublesome ASG units at it for up2dates.  However, as I have not used that feature (I have many remote managed customers, and sucking up my bandwidth on our circuits to give them an up2date that is downloaded rather quickly via the automatic process over the public internet is something I opt not to do), I don't know if you can manually upload up2date packages into the cache or not... might be a good question for the ACC forum.