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

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

• They put a real mess in your web site directories by creating additional folders and keeping old version of documents everywhere ;
  
• They define .htaccess files in all directories to support their security mechanism. This one is used both to restrict the access to administrative functions (update of the website) and to restrict browse access. It then becomes difficult to add your own security schema and be sure everything remains in place after FrontPage has been executed ;
  
• In some occasions, especially for sites with a huge amount of pages, they put a high load on the system (when they compute or verify hyperlinks for example). Since these actions are triggered by the user, I don't have any control on them...
  
• Finally, I don't like the way they are implemented. Apache provides us with a great interface to build custom made modules and Micro$oft guys didn't make any advantage of it. Instead, they preferred to use CGIs because such implementation would be suitable for other web servers. Fair enough, but I still don't like it.

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.

• The first solution is to install the complete package by hand and tweak the various configuration files where needed. That solution is described in this document. It might not be the most convenient way of doing things, but it works.
  
• A second solution, would be to create another version of your Apache configuration files that conforms to the *old* Apache version (prior to 1.3) and then run the FP installation script on them. I didn't try yet that solution although it might be the most convenient... (well, it came in mind after I completed the installation by hand).

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:

• Authoring FrontPage webs. For example, when an author moves a page from one folder to another in a FrontPage web, the Server Extensions automatically update all hyperlinks to that page from every other page and Microsoft Office document in the FrontPage web, directly on the Web server machine.
• Administering FrontPage webs. For example, a FrontPage web administrator can specify which users can administer, author or browse a FrontPage web.
• Browse-time FrontPage web functionality. For example, users of a FrontPage web can participate in a discussion group. The Server Extensions will maintain an index of hyperlinks to articles in the discussion, separate discussion threads, tables of contents, and search forms to locate pages of interest.

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:

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

• admin.exe for FrontPage web administration
• author.exe for FrontPage web authoring support
• shtml.exe for browse-time support
• so called active components like counter (fpcount.exe)

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, fp_install.sh and change_server.sh are the complete Server Extensions package. They can be found at RTR at the following location: http://www.rtr.com/fpsupport/download.htm

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

• the FP extensions core components in /usr/local/frontpage by default. If you want to install them elsewhere, there must be a link from /usr/local/frontpage to the actual location (hey, did you ever heard about flexibility in Micro$oft packages ?) ;
  
• a set of directories in the root of each FrontPage enabled web sites on your server ;
  
• proper configuration of Apache in order to allow execution of the FP components from their actual location within the web site's root.

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

 

6. The Apache Patch

Overview

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.

• The FP Apache module (formerly the Patch) intercepts requests from FrontPage client programs to the FP extensions CGI executables, performs security checks, and redirects the request to the fpexe suid-root stub program. By intercepting each request within the server itself, no script alias is required for the CGI execution.
  
• The fpexe program, which accepts authoring requests from the FrontPage Apache module, performs additional security validation, change the user id to the owner of the FrontPage web being authored, and the invokes the central copy of the FP extensions CGI executables.

For more information regarding the security checks being performed by the patch and the fpexe programs, have a look at http://www.rtr.com/fpsupport/SERK/install.htm#UNIX_ApachePatch.

 

What are the benefits ?

• Since the FP module intercepts every call to the FP CGIs, only a single copy of these executable is required. You don't need to have them placed in every FrontPage enable web-sites.
  
• Since the fpexe FP component is suid-root, it is able to modify itself the Apache configuration files when creating new web site (not needed anymore for sub-webs) (remark: I'm not sure about this... have to check).

 

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...

 

Conclusion

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: http://www.rtr.com/fpsupport/download.htm. 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/fp.www.domain.com. Here is an example of such config file:

# # Fake Apache configuration file for FrontPage extensions #
ServerName ServerAdmin User Group Port DocumentRoot ServerRoot	www.domain.com webmaster@domain.com Apache_user_for_this_vhost Apache_group_for_this_vhost 80 /home/www/fpsite /etc/httpd

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:

/usr/local/frontpage/<ServerName>:<Port>.cnf
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 :   

• /usr/local/frontpage/we80.cnf
  Tells FP where to look for information regarding the default web site associated by your server (you know, the config to handle requests that are not addressed to any of the virtual hosts)
  
• /usr/local/frontpage/www.domain.com:80.cnf
  Tells FP where to look for information regarding the named virtual host (www.domain.com on port 80 in this example).

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

vti_encoding:SR|utf8-nl frontpageroot:/usr/local/frontpage/version3.0 authoring:enabled servertype:apache serverconfig:/etc/httpd/fp.www.domain.com

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:

./_private ./_vti_bin ./_vti_bin/_vti_adm ./_vti_bin/_vti_aut ./_vti_cnf ./_vti_log ./_vti_pvt ./_vti_pvt/_vti_cnf ./_vti_txt

 

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.

./_private/.htaccess ./_vti_bin/_vti_adm/.htaccess ./_vti_bin/_vti_adm/admin.exe ./_vti_bin/_vti_aut/.htaccess ./_vti_bin/_vti_aut/author.exe ./_vti_bin/.htaccess ./_vti_bin/shtml.exe ./_vti_bin/fpcount.exe ./_vti_cnf/.htaccess ./_vti_log/.htaccess ./_vti_pvt/frontpg.lck ./_vti_pvt/services.cnf ./_vti_pvt/bots.cnf ./_vti_pvt/botinfs.cnf ./_vti_pvt/_vti_cnf/_x_todo.htm ./_vti_pvt/_vti_cnf/_x_todoh.htm ./_vti_pvt/.htaccess ./_vti_pvt/service.lck ./_vti_pvt/service.cnf ./_vti_pvt/service.pwd ./_vti_pvt/service.grp ./_vti_pvt/access.cnf ./_vti_pvt/svcacl.cnf ./_vti_pvt/doctodep.btr ./_vti_pvt/writeto.cnf ./_vti_pvt/linkinfo.cnf ./_vti_pvt/deptodoc.btr ./_vti_pvt/structure.cnf ./_vti_pvt/_x_todo.htm ./_vti_pvt/_x_todoh.htm ./_vti_txt/.htaccess ./.htaccess ./_vti_inf.html ./postinfo.html

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: http://www.itma.lu/howto/apache/download/fpdir.tgz. 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:

• .htaccess - they are used by FrontPage to control the access to various functionalities.
• postinfo.html - contains information for FrontPage explorer
• service.pwd, service.grp - Password files containing credentials (by default, user: webadmin, pwd: webadmin).

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

• $fp_authrealm - Authentification realm to be used when prompting for password
• $fp_docroot - The document root of the current web site (eg. /home/www/mysite/htdocs)
• $fp_baseurl - The URL used to access the root of your web site (eg. http://www.domain.com)

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, fp_install.sh and change_server.sh) at the following location: http://www.rtr.com/fpsupport/download.htm.

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:

• Redefine the virtual host directives ;
  
• ResourceConfig and AccessConfig directive should point to the new httpd.conf (the one you made conform to old version). I'm not sure about this... you may have a problem when FP will try to add the necessary ScriptAlias directives. If it fails, make them point to different files and put the necessary content inside.

For more information regarding the differences between Apache 1.3 and 1.2, have a quick look at the official Apache web site (http://www.apache.org/docs/upgrading_to_1_3.html).

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 http://www.rtr.com/fp98discuss (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 ftp://missinglink.darkorb.net/pub/frontpage 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 ]

Hello,

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:

• read the content of all files part of your web site root;
• execute their own scripts located in the _vti_bin directories in each FP enabled web sites;
• modify web files and create new files.

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 http://www.apache.org/docs/suexec.html 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...

• First solution:
  Allow write permissions for 'others'... But I don't think it is a good idea since everybody would be allowed to do so...
  
• Second solution:
  Include the Apache user in the owner group (the one defined in the ownership of web files) and allow write and execute permissions for the group. This is better approach, but still, CGIs of one web will be able to modify the content of another (because all CGIs will be executed under the same Apache account).
  Another issue is the ownership of web files created remotely by using FP extensions: they will be automatically owned by the Apache user and group (because of the account used for the CGI execution). This might be a problem if customers can access their web site content through FTP: they don't own the files anymore !
  
• Third and best solution:
  Make use of the SUEXEC wrapper (see below) !
  

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:

• reading files is done with the default Apache account and group (defined in the top part of httpd.conf)
• if a User/Group directive is present in the vhost definition, then Apache will change account when executing CGIs

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: http://www.apache.org/docs/suexec.html.

 

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:

• wrong permissions on the file (Ownership or Read/Execute rights) ;
• Apache has not been told to allow execution of CGIs in the /_vti_bin directory (ScriptAlias directives) ;
• if using SUEXEC, permissions and ownership might be wrong.

 

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:

• Read-to-Run Software Inc - FrontPage support.
• Read-to-Run Software Inc - FP98 Discussion
• Read-to-Run Software Inc - FrontPage 98 Server Extension Resource Kit
• Microsoft - FrontPage
• Another FP Howto - http://metalab.unc.edu/pub/Linux/docs/howto/mini/Apache+SSL+PHP+fp
• SUEXEC wrapper - http://www.apache.org/docs/suexec.html

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 itma.lu

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