Up2Date prefetch failed

Hi Peter,
print the commands, start up a console as root. Run those commands and that should fix your problem. Your issue was quite big a few versions ago, but for most people it has been resolved.

How did you get to v7.104, from a v7.100 and upgrades or from an older v7 version. If older I would recommend you do a fresh install with the v7.100 ISO and then the upgrades.

Ian M

i installed a fresh image at 7.103...and i got the update for 7.104 with no problem..
but now i get these errors all the time....and as i said...i have never startet or typed anything in the console...


is there some other way to resolve this issue...a downloadable bugfix or something??

peter

Yes, I can confirm it... I setup a new customer UTM yesterday, and it took about 12 hours to go get the updates the first time... started a case with Astaro, turns out they're updating their up2date servers in preparation for the 7.200 rollout, and the authentication servers apparently are acting a little slow... when I checked the customer's unit this morning it had finally gone out and gotten the updates and installed them.

Forgot to add:  They expect everything to return to normal later today.

I wish the up2date servers being temporarily down was my problem. We haven't been able to receive updates since upgrading from 7.101 to 7.104. I believe it's related to our configuration, which is passing all traffic through remote tunnels(spokes), out our 425(Hub). This was working with static routes in place out the default gateway from each remote prior to the update. 

I would have a better understanding if I could find the communication sequence, and port numbers used by the Astaros. I've opened 4433, 8080, 80, 443, 33000-34000(up2date group). What I'm seeing is our ACC requesting SYN with up2date servers over 443, but no response back. If it was a dropped or accepted packet I'd see it in the packet filter log correct?

Any tips or links for learning how to use tcpdump on these units to capture whats going on, I would appreciate it. I just can't seem to glean from the logs what is wrong here.

Thanks for the input guys.

Sounds like you aren't set up to directly contact the up2date servers... are you trying to use ACC as an up2date cache?  Try disabling that option in the affected astaro, it'll probably up2date on it's own.  If there's a firewall in between the affected Astaro and the Internet, only ports 80 and 443 are required for up2date traffic.  Not so sure about ACC traffic, we don't use the central cache, as it would flood our link with all our customers accessing it, we just let the devices get their own updates.

All of our Astaros(20+) were updating fine until 7.104. We updated from 7.101 to 7.104, then weren't able to receive updates for weeks. That is why we installed the ACC server. We hoped that since the ACC server was residing on the Local LAN behind the 425(Hub), we wouldn't have packet filtering or routing issues through our 425 where all traffic enters and exits, for all Astaros. 

Originally we had been receiving updates using static route to one of the update servers. The need for the static route was because all traffic is sent through the tunnel to the Central Hub Astaro for central management and reporting purposes. I've tried adding all the update servers as static routes, allowing all services without luck, prior to installing the ACC server and using it for up2date cache.

Thanks for the assistance.

Then you've really got me... we have at least that many customers that we monitor, and all have been pretty receiving update with no issues (with the occasional "burp" like we experienced last night)...

One thing.. are these astaros directly connected to the internet? If so, why forward their internet bound to the central site first?  If not... then there must be a NAT, Packet Filter, or IPS issue of some sort in play.

"One thing.. are these astaros directly connected to the internet? If so, why forward their internet bound to the central site first? If not... then there must be a NAT, Packet Filter, or IPS issue of some sort in play."

They have Internet, either FIOS, Cable or DSL. The IPSEC tunnels are configured for remote traffic set to ANY. This sends all traffic through the tunnel to the HUB 425 Astaro, which ahs our main servers behind it's Eth0 LAN interface. I believe your right 100% It's either NAT, PF, routing or IPS. Our reseller has scoured the logs and opened what I found was blocked. 

What surprised me was the up2date was working with a static route from each remote site to one of the up2date servers. After 7.104, this ceased to function. Even with the tunnel traffic sent to any, why wouldn't static routes to all update servers out the default gateway, with all ports open, allow the updates?


This configuration was put in place by our reseller. I believe the main goal of forwarding all internet traffic to the central site was a central traffic cop, where all filtering, Antivirus scanning, and reporting is managed. All 20 or so remote astaros are configured to send all traffic over the IPSEC tunnel, using Any as the remote network, with auto packet filter set. I can see advantages to it, but the disadvantages are revealing themselves lately.

Other than the recent up2date failure after the 7.104 upgrade, this configuration was working nicely. This is assuming my DSL secondary link failover issue isn't related... That's another thread:
http://astaro.org/showthread.php?t=21749

I have a feeling that if I was able to verbally communicate with an experienced Astaro support professional, this would be resolved quickly. This is assuming my problems are all configuration related issues. Most of my correspondence has via email. It's been very slow progress. Thank you for your help [:)]

Your reseller should be able to get results... while I've not had this particular issue, when a customer of mine has had a an issue that needed immediate attention I was able to get all the help I needed from Astaro... maybe get your reseller moving in that direction..

Our reseller has been making a good effort to resolve the issue. Unfortunately the issues remain unresolved at the moment. I appreciate the input very much Bruce. Thanks.

same problems here on 7.191
seems like up2date messes with the ips.
if i copy /etc/up2date/servers.sorted from an another astaro it works for a wile.
but after a few hours same problem again and old serverlist back there.

greets
florian


----------------------
EDIT:
Seems like i found the problem.
I use an Astraro Command Center.
If i use that as Up2Date Cache then auth fails.
Without updates run as normal.

same problems here on 7.191
seems like up2date messes with the ips.
if i copy /etc/up2date/servers.sorted from an another astaro it works for a wile.
but after a few hours same problem again and old serverlist back there.

greets
florian


----------------------
EDIT:
Seems like i found the problem.
I use an Astraro Command Center.
If i use that as Up2Date Cache then auth fails.
Without updates run as normal.

Somehow all of our sites which used to update with the static route, updated yesterday. It's working fine now, and we didn't make any changes. Also now all our sites that we configured for an ACC server are updated too!. The only sites that didn't update were the ones we had disabled the static route to 1 update server on. Something had to change on the configuration of the backend up2date servers. Whatever it was, it's fantastic!

We didn't change any configuration, no up2date server was touched. I'd rather think that something "in between" was changed to make things work again. Maybe a transparent proxy in between, used by the ISP? I can remember debugging one customer where an upstream proxy which they did not even know about made up2date impossible, maybe something like this.

Cheers,
 andreas

I confirmed with our Data Center that there is no transparent proxy. We are straight out to the internet. No configuration changes on our end, and nothing changed on the Up2date servers, but all of a sudden, 20+ astaro units are all receiving updates as of yesterday. Something had to change. How often are IPS patterns updated? Were they updated yesterday for the first time in a month or so? Ever since that update, we are receiving updates. Thanks for the help [:)]

If you're only using IPS, that would explain why you didn't get up2date packages for a couple of weeks as there just have been none. This should not produce any error messages though; if there are no new packages available, you'll just receive nothing new.

Cheers,
 andreas

hi all,
as in the title, this is the hardest up2date as I remember(ASL1.***x),
be quite and patient and try to do like me ;
download the package from the FTP site and try to reinstall it in manual mode and not in 
automatic.
I try in this way twice and after a very long reboot(5 minutes) ASG starts regulary in a normal way.
I hope this should be helpfull.

The miracle of all my astaro's updating on 5/19 seems to be due to the proxy crashing on my 425. I found an email sent from the 425 on 5/19 stating "http proxy not running - restarted" I've placed the up2date IP's in the transparent mode skiplist, along with the Interal IP of the remote astaros, but it still appears to be blocked. I seems simple fix now that I know it's the http proxy on the 425, but since the transparent mode skiplist doesn't seem to allow the traffic, I'm at a loss on what to configure to allow the up2date traffic to bypass the http proxy.

This should be the final post on this one for me. The transparent mode skiplist does work, but for some reason it only works if I have a static route to one of the up2date servers out the Default Gateway for authentication on port 443. The update will download over the tunnel via port 80. So it's actually working now. One interesting note is the static route needs to be toggled off/on after a reset on the unit for some reason, or the route isn't entered into the routing table properly. Thanks for all the input everyone.

After upgrading from 7.104 to 7.2, it no longer works. Did the up2date servers change? I dont' see the IP's in the up2date.log anymore. Here was my list for 7.104:


213.144.15.5 -I set static route to DG on Eth1(primary interface)
213.198.93.249 - added to http proxy skiplist
128.121.10.115 - added to http proxy skiplist
218.213.238.229 - added to http proxy skiplist
128.242.114.243 - added to http proxy skiplist
69.10.147.76 - added to http proxy skiplist

We're still using the same servers as before, running with the same configuration, on the same IP addresses:

[Server_1]
Host = v7up2date1.astaro.com
Ip   = 213.198.93.249
[Server_2]
Host = v7up2date2.astaro.com
Ip   = 69.10.147.76
[Server_3]
Host = v7up2date3.astaro.com
Ip   = 213.144.15.5
[Server_4]
Host = v7up2date4.astaro.com
Ip   = 128.242.114.243
[Server_5]
Host = v7up2date5.astaro.com
Ip   = 128.121.10.115
[Server_6]
Host = v7up2date6.astaro.com
Ip   = 218.213.238.229

The only change that has been done in the last weeks is that we took v7up2date1 from the regular server list and used it as a Beta-Up2date Server during the v7.200 beta phase, but in the meantime it has been added again.
I am puzzled; I know you've checked and re-checked everything, but I also know it works flawless for many thousands of machines out there, which leads me to think it is caused by a peculiarity of your network, or the way you connect to the internet. Can you maybe do some routing traces using a tcp traceroute, or try to use a dial-up internet access just for checking if it works this way?

Cheers,
 andreas

Thanks Andreas. It's definitely due to our configuration. We have a 425(Hub) with 20 other Astaro's(Spokes) All traffic on remotes are sent through the tunnel to the 425. I was working with a static route on the remotes, now after 7.2 it stopped working again. That info is helpful. Does the up2date process query DNS for those IP addresses?