Chapter 7. Konqueror

  • Personalized (first start) bookmarks, sidebar entries (for Network/FTP, Network/Web etc.). Configuring the default page

    NOTE: I don't know if konq reads the $KDEDIR/share/config/konquerorrc first, but it should. And then, there is opportunity to put centralized config in there.

  • Automatic proxy configuration, via a script on a server.

Automatic Proxy Discovery

Many networks allow access to the internet through a proxy server. Proxy servers allow the administrators to restrict access

Konqueror is capable of automatically discovering and using properly configured server on your network, which gives you certain advantages:

  • Users don't have to know about or configure proxy services in order to use them.

  • It's possible to change the proxy configuration of every browser from a single place.

  • You can have specific traffic going through specific proxy servers, based on who is accessing them.

  • Provide a list of local servers, that can be accessed directly without the proxy.

  • Automatically enable fallback services, in case the specified proxy server is unavailable.

Of course you can do most of those things in any case, but having the proxy information automatically discovered allows you to keep all these things transparent to the user.

Automatic proxy discovery works in two steps:

  1. Find a configuration script

  2. Determine a proxy to use by running that script

The configuration script is a PAC (JavaScript) file just as in plain Proxy Auto Configuration as described here: http://home.netscape.com/eng/mozilla/2.0/relnotes/demo/proxy-live.html.

The WPAD part of the process (#1 above) described here is about how to find this script without having the users enter its URL into the proxy settings. (All they have to do in a WPAD-enabled network is to select Automatically detected script file in KDE's proxy setup.

There are two alternative ways to discover the PAC script's URL implemented in KDE:

DHCP based autodiscovery

If you are running a DHCP server on your network anyway, you might want to use this approach; all you have to do is to add the WPAD option (numeric 252 or hex fc) as a string containing the URL to the PAC script.

To do so with older versions of ISC dhcpd, add this to /etc/dhcpd.conf, either globally or just for the subnets you want to enable WPAD for:

option option-252 "http://example.com/path/to/proxyconfig.pac";

Or, for newer ISC dhcpd versions, add this globally:

option wpad code 252 = text;

and this either globally or for the WPAD subnets:

option wpad "http://example.com/path/to/proxyconfig.pac";

For other DHCP servers, please consult the reference manual on how to add an option by number if WPAD support is not built-in.

DNS based autodiscovery

If you don't run a DHCP server or prefer DNS based discovery, you need to configure one of your hosts to have the name wpad.example.com and make sure the PAC script is available as http://wpad.example.com/wpad.dat

If your network consists of several subdomains, like a.example.com and b.example.com you can either provide both http://a.example.com/wpad.dat and http://b.example.com/wpad.dat or just http://example.com/wpad.dat When a client searches for that script, it will search for a host named wpad in its own domain, then in the next higher level domain until success or if only the TLD is left (i.e. wpad.com will never be tried.)

Note that DHCP is the preferred approach since it's more flexible than DNS as it doesn't require a well known host name nor a fixed location (/wpad.dat) for the PAC script. It is also the first method tried before resorting to DNS, so if you use DNS there will be a noticeable delay of 5 seconds while waiting for a DHCP reply.

However, DHCP requires a helper program, kpac_dhcp_helper to be installed suid root. If you consider this a security problem, just delete that program or remove its suid permissions and use DNS instead. If the helper cannot execute as root, the 5 seconds delay will also go away.