
Dear software developers, or Microsoft, whichever of you is responsible for this irrational behaviour: please stop grabbing the proxy settings from Internet Explorer and silently applying them to other applications. Thus far I've had unexplained errors with MSN Messenger (which has its own proxy settings) and just now with F-Prot anti-virus, which refused to update. All this boils down to me having a proxy set in Internet Explorer (which was required for testing on a customer site, weeks ago.)
Any applications which have their own proxy settings should use them - and only those settings. If you must insist on grabbing settings from a completely separate application (as debated through at least one large court system), at least provide some clue to the user that your application is also grabbing proxy settings set in Internet Explorer, so that they don't have to spend a day trying to figure out why certain applications won't connect to the internet, despite having a tested, good connection.
Here's a good clue (for F-Prot Updater at least): if you have a checkbox that says, "Use proxy for HTTP connections" - and the user leaves it unchecked, it does not mean to use some arbitrary settings for another application. It probably means to not use a proxy, at all.
posted at: 11:00 | path: /technical | permanent link to this entry
Note that to make gcc actually work on Ubuntu, you might want to try installing build-essential.
Some kind of
sudo aptitude install build-essential
should do the job nicely. If you're building kernel related stuff, and/or require the kernel headers for any purposes,
sudo aptitude install linux-headers-`uname -r`
should grab the appropriate package(s) for your requirements.
posted at: 09:26 | path: /technical | permanent link to this entry
I've been trying to aggregate a number of back-end application servers and provide a single (well, resilient pair) web server as a front end, using Apache Reverse Proxy and specifically ProxyPass and ProxyPassReverse directives. I also wanted to lock down access to the various different reverse proxied applications using IP addresses. You can do this using the <Proxy *|URL> directive, with the subtle requirement that the URL must match the proxied URL, not the requested one.
Example:
A user requests https://my.server.example.com/someapp/foo and without even realising it, gets data and interacts with the application hosted on the backend server, http://app1.example.local/foo. Furthermore, access should only be granted to this application from the IP address 4.3.2.1. Note that app1.example.local is not routeable from the internet, but has a connection to my.server.example.com.
Break out the appropriate SSL vhost configuration file in your Apache front-end server (running on my.server.example.com) and configure something like this:
<Proxy "http://app1.example.local/*"> Order Deny,Allow Deny from All Allow from 4.3.2.1 </Proxy> <Directory "/someapp"> ProxyPass http://app1.example.local/ PRoxyPassReverse http://app1.example.local/ </Directory>
I would have been there, but I have been cruelly summoned to far off Romania to provide useful information to a customer in far off parts.Work. Sheesh! :-)
I'll certainly be at the next PHPUG PotD. I would provide links in this blog posting but I am actually just too lazy. Sorry. It's late her and I need sleep. nightio...
posted at: 00:39 | path: /technical | permanent link to this entry
If you have problems making the apache_ family of process monitors work under munin, you might want to check that you have libperl-www (LWP) installed. Despite some attempt at error trapping, apache_volume fails silently when the LWP::UserAgent->new() call is made. Installing LWP makes it all better.
apt-get install libwww-perl (On any debian / debian-alike / Ubuntu system)
posted at: 23:23 | path: /technical | permanent link to this entry
![[IPv6 Ready]](http://9-badges.ipv6ready.ie/9/94/2f/05/9942f05fd76ad162164ae4abe1b094cd49d0d070-m.png)
