FrontPage98 Extensions v3.0 and Apache 1.3+

Version 1.0.4 - 30 May 1999
Wanna be kept informed of the latest changes of this document ? Just subscribe to the mailing list (follow the same link to unsubscribe).


  1. Foreword
  2. Why this document
  3. What are FrontPage Server Extensions
  4. FrontPage Product Architecture
  5. What should get installed?
  6. The Apache patch
  7. Installation - First solution
  8. Installation - Second solution
  9. Installation - A Solution ??
  10. File Permission and Ownership
  11. Frequently Asked Questions
  12. Information
  13. Document history


1. Foreword

First of all, I have to say that I don't like the FrontPage Server Extensions for several reasons including the following :

Instead of using FP extensions, I would prefer my customers to use FTP to update their sites... even if it is less convenient. If I don't like them, why did I wrote this page ? Well, as usual, customers asked for it...

Something else, you have to know that FrontPage Server Extensions version 3.0 don't understand the Apache 1.3+ configuration files. Therefore, the installation script will fail. Conclusion, we have to do it by hand... Be ready for some tricky tasks, but at least it works !


2. Why this document

The FrontPage Server Extensions package comes with a *great* installation script that should take care about all dirty things for you. It should plug the extensions within your system, and you just have to play with them once installed. Well, you know the story about plug & play...

Apache configuration files have changed starting from Apache 1.3+ and FP extensions are no longer able to parse them. The main problem comes from the virtual host configuration where the new Apache version introduced the <NameVirtualHost> directive and changed the way the <VirtualHost> directive is used.

Conclusion, the FP installation script will fail when it comes to the setup of virtual hosts. Same for the administration utility and some other FP executables.

As you will see in the next sections, FP extensions are nothing more than common CGIs that get executed by request of a client. Therefore, there should be a way to make them run... I installed them with Apache 1.2.6 and started looking around to understand the whole thing.

Anyway, in both cases you will end-up with two sets of Apache config files: the actual for Apache itself and the adapted for FrontPage. Each time one is modified, you have better to replicate the changes to the other. Hey... I hear your question from here: how can the adapted Apache config files been modified? Well, depending on whether or not you apply the FP Patch for Apache, the extensions will be able to modify themselves the configuration files to allow remote users to create new web sites. See below for more information on the FP Patch for Apache.


3. What are FrontPage Server Extensions

[ Taken from the FrontPage98 Server Extensions Resource Kit ...

The FrontPage Server Extensions are a set of programs on the Web server that support:

A FrontPage web is a project containing all the pages, images, and other files that make up a Web site. For a full description of FrontPage webs, see FrontPage Webs.

The design of the FrontPage client and Server Extensions minimizes the need for costly file transfers over the Internet. When an author using the FrontPage Explorer opens a FrontPage web from a Web server containing the Server Extensions, information about the FrontPage web, such as its hyperlink map, is downloaded to the client machine so that the FrontPage Explorer can display the information. However, the full set of pages and other files that comprise the FrontPage web remain on the Web server machine. A page is only downloaded over the Internet when it is opened for editing in the FrontPage Editor. This is a very efficient mechanism: an entire Web site can be changed directly on a Web server at the cost of
downloading and editing a single file.

When a Web server machine has the FrontPage Server Extensions, FrontPage web authoring and administering functionality is available from a PC or Macintosh computer that has the FrontPage client program and that is on the Internet or an a local Intranet. The browse time functionality of the Server Extensions is available from any Web browser on the Internet or Intranet.

Communications between a client computer and a Web server containing the Server Extensions uses the same open, ubiquitous HTTP protocol that Web browsers on a client computer use to interact with a Web server. No file-sharing access on the Web server machine is needed, nor are FTP or telnet access required. No proprietary file system sharing calls are necessary.

The Server Extensions are designed to work with any standard Web server using the Common Gateway Interface (CGI), the near-universal Web server extension mechanism. This includes freeware and shareware servers such as those from Apache, CERN and NCSA, and commercial web servers from Netscape, Microsoft, and O’Reilly and Associates. The Server Extensions are designed to be easily ported to all popular hardware and software platforms for cross-platform Web server compatibility.

... ]


4. FrontPage Product Architecture

[ For more information, please refer to FrontPage98 Server Extensions Resource Kit ]

The FrontPage client tools communicate with the Server Extensions using HTTP, the same protocol used to communicate between Web browsers and Web servers. FrontPage implements a remote procedure call (RPC) mechanism on top of the HTTP "POST" request, so that the FrontPage client can request documents, update the Tasks list, add new authors, and so on. The Web server sees "POST" requests addressed to the Server Extensions CGI programs and directs those requests accordingly. FrontPage correctly communicates between client and server through firewalls (proxy servers).

FrontPage does not use or require the HTTP "PUT" request. As described in the HTTP specification, "PUT" sends a document to a Web server. However, few Web servers implement "PUT." Therefore, FrontPage uses the universally-implemented HTTP "POST" request for all communications with the Server Extensions.

The following schema illustrate the principle:

fp_architec.gif (3677 bytes)

The Server Extensions are divided into several libraries (which are executables on your web server):

These are called with a predefined URL like /_vti_bin/author.exe?parameters. This is why a special directory structure has to be setup in the root of each FrontPage enabled web site.

Conclusion: FrontPage Server Extensions are invoked by the client through normal HTTP requests and executed thanks to the CGI mechanism.


5. What should get installed

Well, I wrote what *should* get installed because the default installation script will fail with Apache 1.3 or above. Therefore, here is a first overview of what should normally get installed. You will find later a solution to get around the installation script and do everything by yourself.

The files fp30.linux.tar.gz, and are the complete Server Extensions package. They can be found at RTR at the following location:

Once the installation is completed (see further), you will get:

That's it. Nothing more ? You've been told about a patch for Apache ? Hmm... see below.


6. The Apache Patch


FrontPage extensions provide the user with the ability to remotely create new web sites or sub-web on the server. This of course requires access to the Apache configuration files.

Since the FrontPage Server Extensions runs as "www" (or whatever user your Apache uses) and the Apache configuration file is owned and modifiable only by "root", the Server Extensions cannot modify them and thus is unable to remote create new web/sub-web. Instead the FP administration utility as to be manually run as "root" on the host computer (... and it will even not succeed with Apache 1.3 or above since it doesn't understand its configuration file format).

This is where the patch appears... Because guys at Micro$oft believe that the power should be in the hand of users, they imagine a workaround. Then the patch is born... and it is more a Trojan than an actual patch !

Here is a short description of what it does.

For more information regarding the security checks being performed by the patch and the fpexe programs, have a look at


What are the benefits ?


What are the problems ?

1. fpexe is suid-root

As lot of administrators, I'm concerned about root suid programs. Especially if they are invoked through web requests that may come from everywhere in the world. You never know...

2. Apache config files

Thanks to this patch, FP components are executed with the web site owner (for normal operations). To know who is the owner, FP has to read (and understand) the Apache config files (looking for User/Group) directives.

As you know, the configuration files have changed from Apache 1.3.x to Apache 1.3. As result, FP extensions aren't able to parse them correctly anymore... So, it will not work properly (well... it will not work at all !)

3. SUEXEC CGI wrapper

Moreover, I was not able to make this patch run together with the SUEXEC CGI wrapper, though this one is required if you plan to use User/Group directives within virtual web sites. The problem is that these directives are required for the extensions to find the owner of the web site...



If you don't need your users to create new web sites remotely, then don't use this patch. It is not required and it will work perfectly without it.


7. Installation - First solution

As I mentioned here above, the current version of FrontPage Extensions (v3.0) doesn't support the configuration files of Apache 1.3 and above. Therefore, the installation script provided with the Micro$oft package will fail, so for the administration utility that comes with it (fpsrvadmin).

This first solution will tell you how to install all the components by yourself and how to tweak some configuration files in order to get everything in place. Be ready for some tricky tasks...

Step 1 - Download the package

Download the FrontPage Extensions from RTR (fp30.linux.tar.gz) at the following location: Note that you will only need that file, the others are not required for this installation.

Step 2 - Unpack the archive

Unpack this archive in /usr/local. This is the default installation directory. If you plan to install the FP extensions somewhere else, a link must be defined from /usr/local/frontpage to the actual location of the FP extensions.

This process will create a frontpage directory in /usr/local. I'm not sure about it but you may also have to create a link /usr/local/frontpage/currentversion that points to /usr/local/frontpage/version30.

Step 3 - Custom made Apache config files

Since the FP extensions v3.0 don't understand the Apache 1.3+ configuration files, we have to provide it with some fake configuration files in a format suitable for it to retrieve the information it needs.

For each FrontPage enabled web site, define a custom made configuration file where the extensions will look for information regarding the Apache settings. You can name it whatever you want, in my case, I went for /etc/httpd/ Here is an example of such config file:

# Fake Apache configuration file for FrontPage extensions

Step 4 - Custom made Apache config files (bis)

Don't ask me why, but FP extensions are also looking for the srm.conf Apache config file which disappeared starting from version 1.3. Moreover, it will look for this file under the ServerRoot/conf directory.

Therefore, depending of your own server root path (and what you defined in the above fake configuration file), you will have to create a conf directory containing the srm.conf file. Just create this file and leave it empty.

Step 5 - Custom made FP config files

FrontPage extensions also maintain some other private informations for each FP enabled web site. These are kept in the /usr/local/frontpage directory. The name of these files must be carefully chosen since it contains by itself some important informations (yes, the name contains some information...).

One config file is defined for the server, the others are for every virtual web site you want to give FrontPage support.

The name of these files must be of the following format:

where <ServerName> Is the ServerName you defined in the custom made configuration file (see above - step 3)
  <Port> Is the Port you defined in the custom made configuration file (see above - step 3)

One exception to this rule is the config file needed for the server itself: it should be named we80.cnf (where 80 is obviously the Port the server is listening). Conclusion, for the above hypothetical web site, you will have at least :   

I don't really know the exact content of these files, but the following would make it without any problem (at least for me):


The interesting point there is the serverconfig directive which should point to the custom made Apache configuration file (see Step 3) for virtual webs, and to the main Apache config file for the server itself (say /etc/httpd/httpd.conf).

Step 6 - Directory structure

Now, we have to setup the necessary directory structure under the root of each FP enabled web server. Just create the following directories for each web sites:



Be sure these directory are readable by both the web site owner (as defined in the Apache config files) and the user Apache is running ("www").

Step 7 - FP components

We have now to copy the necessary files within the FP directory structure we just setup within each web sites. Below is the list of all files that should be within the FP directories (yes, they are a lot... but don't worry). Entries in bold must be edited for each web site.




FrontPage executables in _vti_bin can be found in the FrontPage distribution under the /usr/local/frontpage/version3.0/_vti_bin directory.

The other files are normally generated by the FrontPage installation script. Since we don't use it, I made a tarball available for download at the following location: I got these from a previous installation under Apache 1.2.6 where everything went fine because the installation script understood the Apache config files...

The following files marked in bold in the above list must be edited for each web sites:

The files I gave you in the tarball contains several variables you have to edit for your particular configuration. These are:

Step 8 - Update Apache for CGI execution

Finally, you have to update the Apache configuration files to allow execution of CGIs in the following directories (and so for each virtual web sites):

ScriptAlias /_vti_bin/_vti_adm/   <DocumentRoot>/_vti_bin/_vti_adm
ScriptAlias /_vti_bin/_vti_aut/   <DocumentRoot>/_vti_bin/_vti_aut
ScriptAlias /_vti_bin/            <DocumentRoot>/_vti_bin

Step 9 - Permissions

This one is last... Don't forget to verify permissions on all files, specially in the document root. Take special care to the *.exe files, they might be suid-root by default (turn it off !!)... Remember that they should only be executable by the owner and the Apache user (only the owner if you are using the SUEXEC wrapper). On the other hand, FP extensions must also have write permissions to update your site's content...

See below for more information regarding the file permission and ownership.

Restart Apache and start test the extensions with the FrontPage explorer. Have a quick look at the error logs for CGI execution...


8. Installation - Second solution

As mentioned above, the FP installation script fails because of the Apache new configuration file format. A solution would be to create another Apache config file, containing the same information as your master but that conforms to the old format (Apache version prior 1.3). I didn't try yet that solution but the steps would be as follows:

Step 1 - Download the package

Download the complete FrontPage Extensions package from RTR (fp30.linux.tar.gz, and at the following location:

Step 2 - Create a custom Apache config file

Make a copy of your current Apache configuration file then modify it so that it conforms to the format of previous versions. As far as I know, take care of the following:

For more information regarding the differences between Apache 1.3 and 1.2, have a quick look at the official Apache web site (

Step 3 - Follow the normal installation procedure

The follow the normal installation procedure as described in the Unix installation of the FrontPage Server Extension Kit.
Remark: when prompted for the type of web server, enter APACHE and not APACHE-FP which is the patched version.

Step 4 - Tell me how it goes

At the end, tell me how it goes...

PS: I got some news from Armando who tried that solution... it works ! Here is what he told me:

It seems that the web administration forms and presumably the line command are happy to swallow a fake <virtualhost> in the 1.3.x configuration. It will install all the extra directories at the right places, and then one can change it back to the NameVirtualHost format after redirecting the configuration files to the substitutes fp.* you described.

9. Installation - A Solution ??

It seems that some people manage to get everything working fine out-of-the-box (as they claim). They used to patch the official Apache patch to make it compatible with new configuration files. Anyway, since that solution makes use of the SUID-root stuff... I would not go for it !

The following comes from a news-thread at (RTR):


Redhat 6.0 , Apache 1.3.6 & Frontpage Extension

Hello, Has anyone successfully install the frontpage extension on Redhat 6.0 with Apache 1.3.6?

Re: Redhat 6.0 , Apache 1.3.6 & Frontpage Extension

Yeppers here's how download apache-1.3.6 source rpm get the fp-patch-...1.3.6 from put it in /usr/src/redhat/SOURCES

The only real difference here is that it has the changes for http_request.c corrected for 1.3.6

  1. edit the patch to remove the Configuration stuff at the top, and change the path for the module to apache_1.3.6/mod_frontpage.c
  2. edit /usr/src/redhat/SPECS/apache.spec to add the fp-patch
  3. Add in the appropriate spots: Patch4: fp-patch-apache_1.3.6 %patch4 -p1
  4. --add-module=./mod_frontpage.c \ --disable-shared=frontpage
    (This absolutely doesn't work as a shared module)
  5. Now rebuild apache with rpm -bb apache.spec
  6. and install

This should work great. Now, if you're using mod_phtml, mod_php3, mod_perl, or anything else, be sure you install the apache-devel files and rebuild them as well. The changes to the structures in httpd.h will cause everything else to work screwy if you don't.

Note: To keep mine straight, I edit the name in each spec file to apache-fp, mod_php3-fp, etc... then add apache-fp to the provides of apache and requires of the rest....

Re: Redhat 6.0 , Apache 1.3.6 & Frontpage Extension

[ First comment ]

I am going insane here! I had already done exactly as you mentioned in your post. I recreated the rpm, realized it wouldn't work as a shared module, added the --disable-shared line. It finally compiled like I wanted, I see "mod_frontpage" listed in httpd -l. Now when I run frontpage from a client, I get a error 500 when it request _vti_bin/shtml.exe/_vti_rpc . I have tried everything. I have compared all the permissions on the /usr/local/frontpage tree to a working server (apache 1.3.3). The one thing I did notice, if I remove the /usr/local/frontpage directory all together I start getting 404 error's instead of 500 errors. SOOO this seems to indicate that mod_frontpage is redirecting the the fpexe program ok, but once it gets there it is dying for some reason. I turned on the scriptlog, and dont really get anything productive there, other than "no such file or directory: exec of /_vti_bin/shtml.exe/_vti_rpc failed" which isn't very helpful since I already know its been redirected to fpexe, which is definately there and has the right permissions.

[ Second comment ]


I have an intresting problem. I have installed FrontPage 98 Server Extentions and the Patched Apache Server. Now it creates the <Root Web> and I can connect from a remote client using FrontPage 98 and edit/creat/delete and all those things FP dose. But If i run the fpsrvadm.exe proggy it tells me there are no Front Page Server Extentions installed, and so do the Admin Forms. I have been tring o solve problem for several days now with no luck. I can also install virtual frontPage webs but still i can not admin them because the fpsrvadm.exe tells me that tere are no FP Server Extentions installed.

HELP! Re: Redhat 6.0 , Apache 1.3.6 & Frontpage Extension

I followed these instructions and fairly easily seemed to get things running correctly on my Linux server. However, when I run FrontPage on my Windows machine and attempt to ListWebs on the server, I get this:

404 Not Found Not Found The requested URL /_vti_bin/shtml.exe/_vti_rpc was not found on this server.

What am I doing wrong?

FIXED!! Re: HELP! Re: Redhat 6.0 , Apache 1.3.6 & Frontpage Extension

It appears as if you need to have AllowOverides All set for the directory in which the web is located. by default redhat 6.0 has <directory /> allowoverides none </directory>

this makes it so that by default it is not allowed. I changed this to All and everything seems to be peachy. Now I will just set it on a directory by directory basis.


10. File Permissions and Ownership

I've often been asked what should be the file permission and ownership for the web content. Well, the answer depends of your configuration... The explanation below is like a little story: go through it and you will understand the pro and cons of each solutions (I hope so...).

FP Extensions requirements

The FP extensions need to perform the following tasks:

This has, of course, influences the definition permissions and ownership of your web site content.

You don't use the SUEXEC wrapper...

The SUEXEC wrapper (part of the Apache distribution), allows Apache to change user when execution CGIs (instead of using the default 'www' or 'nobody' user defined in the main config file). See for more information.

Question: who will own the web files ? Chances are that you will setup a dedicated account for each web site in order to allow your customer to update them directly via FTP or Telnet. Same for the group, although they might all be in the same group...

Since the default umask is often 755, chances are that your permissions will be as follows:

owner : rwx
group : r-x
others : r-x

Suppose Apache is not the owner of the files, FP extensions will not be able to modify their content (no write permission for group and/or others). Remember, FP extensions are CGIs and, without the use of SUEXEC, they will be executed under the Apache account...

You make use of the SUEXEC wrapper ...

Thanks to this wrapper, you can tell Apache which user account and group to use when executing CGIs (thanks to the User and Group directives in the vhost Apache config file).

With the SUEXEC wrapper, the behavior of Apache is as follows:

You can now define a separate user and group for each web site you host and setup the ownership accordingly. Since the CGIs will be executed under the owner account (User and Group Apache directives), permissions could be defined as follows:

owner : rwx
group : r--
others : r--

A further improvement would be to define Apache as a member of the web site group and deny everything for 'others' (only the owner and Apache will be allowed to read files).

Important remark: the SUEXEC wrapper is a bit difficult to install: it has special requirements regarding the permissions associated with each CGIs. Please refer to the following web page for more information:


11. Frequently Asked Questions

From within FrontPage Explorer (the client), you get one of the the following error message:

403 Forbidden You don't have permission to access /_vti_bin/shtml.exe/_vti_rpc on this server.

404 Not Found The requested URL /_vti_bin/shtml.exe/_vti_rpc was not found on this server

Or from within the Apache error log:

script not found or unable to start: <DocumentRoot>/_vti_bin/shtml.exe__vti_rpc

First, don't worry, shtml.exe is not a directory and no _vti_rpc directory should exist. The problem here is that Apache has not been able to execute the shtml.exe script. Possible reasons:


Forms created with the FrontPage explorer cannot send email directly.

Add the following line in the /usr/local/frontpage/currentversion/frontpage.cnf file:

SendmailCommand:/usr/sbin/sendmail %r


FrontPage Explorer doesn't ask any Login/Password

Have a look at your .htaccess in all directories. Check if they point to the correct password file. Check also the Apache log, they might content some hints.


Unable to find _vti_binshtml.exe

Chances are that you miss a '/' at the end of each ScriptAlias directives. (thanks to Patric Fischer)


12. More Information

If you want more information on the subject, have a look at the following sources:

I also made several scripts to automate the configuration of FrontPage Server Extensions for Apache. If some of you are interested in these, send me a mail at bertrand.renuart at

Don't hesitate to contact me if something is going wrong... or even if everything works fine !
Good luck...


13. Document history

Wanna be kept informed of the latest changes of this document ?
Just subscribe to the mailing list (follow the same link to unsubscribe).

Version Date Changes
v1.0.0 13 March 1999 First release of the document
v1.0.1 15 March 1999 Add section "Why this document"
Add section "Second Solution"
Add section "Document History"
Refine "Step 5" in "Installation - First solution"
Some typo
v1.0.2 16 March 1999 Changed User/Group directives in Step 3, Installation - Fist solution section.
v1.0.3 23 March 1999 Add section "File Permission and Ownership"
Add section "Frequently Asked Questions"
Some typo
v1.0.4 30 May 1999 Add third installation procedure
Add some FAQ
Add Armondo's experience for solution 2
Add RTR's discussion list in More Information section

Last update: 30 May 1999 bertrand dot renuart at
This link is there just to drive google to this very cool web application