Part 4: Using FrontPage extensions at an ISP.

In an Internet Service Provider setting, installing and maintaining FrontPage extensions and the mod_frontpage module can be quite tricky. In this section I will provide some methods for working around some of the limitations of the stock/standard FrontPage setup. Not all situations will be covered, but you should be able to pick up ideas off of what I provide here. Simply adjust those techniques to your own setup.

The most common situation that will probably come up at most ISPs is how to install the extensions for a user, whose web space is at http://www.isp.com/~username. Using the fpsrvadm.exe program as the root user you can do the following.

   umask 022 [6]
   cd /usr/local/frontpage/version4.0/bin
   ./fpsrvadm.exe -o install -p 80 -w '~' -s \
       /etc/httpd/conf/httpd.conf -xu  -xg  -u 

<primarygroup> is the user's main group id. This is usually either the same name as the username, 'users' or some value indicating what level of service the user has like business or vhttp.

The -xu and -xg options are for specifying what operating system level user and group should be used for owning the files. The -u option specifies what Apache user (through .htaccess) will be the initial author and administrator for the site.

I think that it's probably best to give the .htaccess user the same name as the OS level user so that there is no confusion to the end user (or the system administrator) as to who has access to publish to the site.

Many ISPs have expanded their system of user management beyond the use of the simple adduser program bundled with most Unices. Where I work, we have written modules to handle the management of users in an object oriented way. On top of that we use a program we wrote called mcfeely handle running commands unattended on multiple servers from a task initiated on another server. Unfortunately this kind of setup doesn't work well with the fpsrvadm.exe program because you can't have fine grained control over how and what is installed. Also, if you are counting on processing return codes from install programs you will have troubles working with fpsrvadm.exe.

What you should try doing instead is installing all of the files using your own install program. Fortunately, this isn't too difficult. As shown in Part 2-6 of this documentation there are some standard directories that all FrontPage extended webs use.

The first part of writing your own script is to install all the necessary files that make up a sub web using the fpsrvadm.exe program. Then copy those files that were created into /etc/skel, which is usually the place where standardized files for per-user installs are kept. The FrontPage files that you just copied also have some values in some of the files that should be generalized by replacing them with a string like %{username} or %{password}. These files include:

    web/.htaccess
    web/_vti_bin/.htaccess
    web/_vti_bin/_vti_aut/.htaccess
    web/_vti_bin/_vti_adm/.htaccess
    web/_vti_pvt/access.cnf
    web/_vti_pvt/service.pwd
    web/_vti_pvt/service.grp 
    web/postinfo.html

Then when you install script runs, it can replace those strings with their actual value for the user you are installing.

All the files installed as FrontPage extensions can be world readable without to much worry. Some of them have to be world readable anyways for the web server to be able to use them before it uses fpexec.

[6] - Unfortunately the program doesn't do this for you.