package squid3 3.3.8-1ubuntu6.1 failed to install/upgrade: Unterprozess installiertes post-installation-Skript gab den Fehlerwert 1 zurück

I had the same error.
The manager, localhost and to_localhost definitions are built-in in later squid-versions...
Simply restart your system after the relase-upgrade and remove the following lines from your squid.conf:

acl manager proto cache_object
acl localhost src 127.0.0.1/32 ::1
acl to_localhost dst 127.0.0.0/8 0.0.0.0/32 ::1

If that doesn't help, here are the steps I did before removing the lines in squid.conf but I don't think these are necessary:
apt-get remove squid3
apt-get autoremove
apt-get install squid3

Removing the lines and dpkg-reconfigure squid worked!

Thx!

Status changed to 'Confirmed' because the bug affects multiple users.

Thank you for your report.

This looks like a local configuration problem, rather than a bug in Ubuntu, since you had previously modified squid.conf and these customisations needed to be updated in the upgrade.

You can find pointers to get help for this sort of problem here: http://www.ubuntu.com/support/community

Since we use this bug tracker to track bugs in Ubuntu, rather than configuration problems, I'm marking this bug as Invalid. This helps us to focus on fixing bugs in Ubuntu.

If you believe that this is really a bug, then you may find it helpful to read "How to report bugs effectively" http://www.chiark.greenend.org.uk/~sgtatham/bugs.html. We'd be grateful if you would then provide a more complete description of the problem, explain why you believe this is a bug in Ubuntu rather than a problem specific to your system, and then change the bug status back to New.

If misconfiguration means adding additional ports to the config file, then you are right. This is another reason for switching to another distribution. Ubuntu is no distribution for productive environments!!!

There is currently no mechanism for a package maintainer script to automatically detect that you added additional ports and apply this change to the new configuration file in a major upstream release update.

If you have a customised configuration file, then when you upgrade you should get a prompt asking you to update your customisations to match the new configuration file. If you don't, or you upgrade non-interactively, then the old configuration file will remain because we don't want to overwrite your customisations. That will cause the daemon to fail to start.

When configuration file syntax changes between releases, there's no other real path that we can follow unless upstream provides some kind of automatic way to update previous configurations.

I'd love to know how other distributions solve this problem. Debian/Ubuntu make some use of ".d" directories to try and help with this, and specific improvements might be able to be made, but I'm not aware of any solution to the general problem.