[7.004] HTTP Proxy doesn't work anymore in Standard Mode

https://community.sophos.com/products/unified-threat-management/astaroorg/f/53/t/32078

Let's just link ourselves up, shall we.

Good to know its not just me.

Hallo,

the same at my machine. Updated to 7.004. The proxy-port was the 8080. Then I have changed the port 3128. Now I can see notifications, that the proxy-server is not running and will be restarted. I can't connect to the web.

Whats wrong with 7.004 ?

Best regards from
Egbert

I was advised by Astaro Tech Support of this today. It would _appear_ Astaro is aware of the problem.

It looks like they may be, reducing the memory utilization of squid and letting the OS handle more of the caching duties should improve the performance of the system over a wider variety of system loads.

Anyone have the contents of /var/storage/chroot-squid/etc/squid.conf from 7.003 handy???? Would love to see what the old settings were.

Well, my 6.304 system has the same ratio of disk space, max object sizes and cache_mem settings allocated to it based on the size of the /var/storage system and amount of memory in the systems, so I doubt that those have changed unless they reduced one of those settings early in V7 for some reason.

This is hot off the press from Cameron:

James,

We can certainly try setting these to a lower value, however it may be overwritten with the new 7.005, which really shouldn't be an issue as it should do this to help correct the storage issue.

The settings to modify this cache are:
joe /var/storage/chroot-squid/etc/squid.conf

Under the Cache tuning section:

maximum_object_size_in_memory 25711 KB
maximum_object_size 108 MB

Change these to a 5 MB max memory file and only a 20 MB object size:

maximum_object_size_in_memory 5120 KB
maximum_object_size 20 MB

Too bad they are reducing the maximum_object_size. [:(]

That value should be proportioned related to the amount of disk space used for the cache, where the maximum_object_size_in_memory should be proportioned slightly according to the cache_mem setting.

All IMO and IME, of course. [;)]

Upgraded 2 firewalls here yesterday to 7.004.  Had no issues prior, but now the HTTP proxy stops serving requests every few hours on each of them.  No config changes were made other than the update.

Disable and re-enable HTTP proxy will make it work for a while.. and then it stops again.  

I do not think the problem is actually the HTTP proxy but rather the AUTO_INPUT packet filter table that the middleware manages.  For some reason, the firewalls just start dropping packets to its own http proxy after a while.

We also have other strange things due to packets being dropped by the middleware managed INPUT filter, such as we sometimes cannot access the Webmin interface from external networks.

We also are getting trouble tickets on PPTP VPN problems, their sessions seem to stop passing traffic after several minutes, not sure if its related.  Using L2TP seems to help with or resolve these.

This is not good for us, and rolling back to 7.003 is going to be a real PITA, with management types upset.   Thank god its a three day weekend.. at least for everyone else [[[:(]]] [[[:(]]] [[[:(]]]

I never update production firewalls without waiting for at least a week and scanning the forums for issues, first.

I never update production firewalls without waiting for at least a week and scanning the forums for issues, first.

Is this because Astaro has a history of releasing junk updates?  It isn't my responsibility to bug test their product.  How about Astaro should never release an update without waiting for a week and running it on their own production firewalls.

Is this because Astaro has a history of releasing junk updates?

Yes. I can't remember the last time an update was rolled out without significant issues. It seems that nearly every update to the v6.3xx series has been "re-rolled" to fix some error. Do a search, you'll find more information about them.

The whole v7 series has been a bit of a cluster-. It seems that most people are avoiding v7 unless they really need some new feature in v7. It definitely seems to be very unstable compared to the v4 -> v5 -> v6 migration.

It isn't my responsibility to bug test their product.  How about Astaro should never release an update without waiting for a week and running it on their own production firewalls.

I agree, but I think you will find that with any product with this amount of complexity in it will always have some sort of bug. Just look at all the major software manufacturers. That said, it still seems to me that Astaro has some basic QA issues which fail to find basic functionality issues in new releases and new releases have a nasty habit of introducing regressions.

This is hot off the press from Cameron:

James,

We can certainly try setting these to a lower value, however it may be overwritten with the new 7.005, which really shouldn't be an issue as it should do this to help correct the storage issue.

The settings to modify this cache are:
joe /var/storage/chroot-squid/etc/squid.conf

Under the Cache tuning section:

maximum_object_size_in_memory 25711 KB
maximum_object_size 108 MB

Change these to a 5 MB max memory file and only a 20 MB object size:

maximum_object_size_in_memory 5120 KB
maximum_object_size 20 MB

Want to know some really good settings for squid?  I have been using these for a looong time.  IF you have the disk space then this will drastiically chop ram usage and increase your cache usage(only for static content obviously)


 maximum_object_size_in_memory 0 KB
maximum_object_size 250 MB
cache_mem size is 0KB

This will remove about 50-70% of squid's memory usage, increase your disk cache and remove squid as one of your ram hogging apps.

If you are a bit short on disk space like i am max the max object size 125 megs or a bit smaller.  That way one or two large files won't wipe out your other cached files.

An Astaro 7.004 webproxy at a customers network fails about 5 times a day and we can only switch it off and on! 
Has somebody found a workaround or is there any information if Astaro is going to fix this?

MatthiasD; Astaro is aware of the problem in 7.004 that you describe, and I thnk a fix is coming soon for it.

MatthiasD; Astaro is aware of the problem in 7.004 that you describe, and I thnk a fix is coming soon for it.