|
Sambar Server Documentation
|
| Frequently Asked Questions |
The Sambar Server was created to test a three-tier communication infrastructure modeled after the Sybase Open Client/Open Server. Soon thereafter, the idea of leveraging the infrastructure for dynamic delivery of content on the WWW resulted in the addition of an HTTP protocol stack, and efforts in supporting the notion of presistent users via HTTP.
Originally developed on a Sun Workstation (UNIX), it was ported to the PC (Windows 32) and licensed for commercial purposes. After completely rewriting the base code at the end of 1996, and adding many new features, version 3.0 began shipping in February 1997. Version 4.0 began shipping in mid-May 1997. A Linux port was performed (and integrated into the core codebase) during the 4.4 release, but not subsequently released due to resource constraints. Version 5.0 began shipping in January 2001.
With the 4.2 release some features require a "Pro" license key to unlock additional functionality. There is no special software to download for the Pro server. The Pro license enables additional server functionality (e.g., mail server, DNS server, DHCP server). Pro license revenue helps offset the costs of maintaining the code and distributing the server.
The Sambar Server does not attempt to offer all of the features or configuration options of Apache or NCSA. The focus of the Sambar Server is on an extremely simple installation, turn-key packaging, and a programmer friendly interface for extending the underlying functionality.
Future releases will likely remain on this track, including extensions to the programmer interfaces, more sample source code, and improved configuration capabilities from the system administration forms.
While originally developed on a Sun Workstation (Solaris), the Sambar Server is now only available on Windows 95/98 and Windows NT (3.51, 4.0, and 2000). Availability on other non-Windows platforms is not planned at the present time as my hardware budget is limited to PC systems for the foreseeable future.
You can find the most recent release of the Sambar Server at http://www.sambar.com/.
When upgrading to a new release, you MUST install the new release in a new directory. There are no "smarts" in the installer to recognize previous versions and upgrade them. So if you install over a previous release, you will erase any common configuration and document files that you might wish to keep around. The How To documentation includes an overview of the steps used to upgrade Sambar Technology's servers.
Pro users have the option of upgrading the server from the System Administration console. This feature contacts www.sambar.com to retrieve the latest production or preview release and upgrades the server in-place.
The Sambar Server does support SSL. As of the 4.4 release cycle, I have received permission from the US Government to include the OpenSSL libraries necessary to provide full SSL2/3 functionality with the server. See the SSL help pages for configuration details.
No. It is my belief that the introduction of client-side image maps has rendered server-side maps obsolete. I recognize that there is legacy code requiring this feature but have not had a significant number of requests to implement it.
Map files for server-side image maps are not presently supported by the Sambar Server. The modules interface can be used to implement this functionality should an enterprising programmer wish to code this up.
Microsoft does not presently allow third-party developers to port the FrontPage Server Extensions. In 1999, Microsoft has stated that their Office 2000 suite will use the WebDAV (distributed authoring and versioning) HTTP extensions for authoring; presumably, this will replace the FrontPage extensions. The Sambar Server will be enhanced to support WebDAV; a date for providing full WebDAV support has not yet been determined.
According to some users, you don't actually need the FrontPage extensions to use FrontPage to design your site, or even to publish your site to the Sambar Server. When you hit the Publish button in FrontPage, it attempts to connect directly to your server through the extensions. However, if FrontPage does not find the extensions, it automatically launches the Microsoft Web Publishing Wizard instead, which transfers the file via FTP.
Ordinary web pages designed using FrontPage 98 should work fine against the Sambar Server (with FTP configured to run), even without the extensions. You should also be able to use elements of Active Elements since they're Java-based. However, you won't be able to use any of the FrontPage Components - such as search, e-mail, or discussion forums - on your site, nor will you be able to administer your site directly as if it were a FrontPage web located on your machine.
Lastly, you can use the FrontPage editor separately without the FrontPage Explorer. The editor is located in the \bin directory where FrontPage is installed and is called fpeditor.exe.
The Sambar Server supports Microsoft ISAPI functionality which should be enough to support Active Server Pages. Regrettably, Microsoft restricts ASP installation to their own web servers (PWS and IIS).
Halcyon Software Inc. provides an ASP implementation that can be configured for use with the SambarServer. In addition, the 5.0 Sambar Server provides similar functionality to ASPs via the CScript package. This package will continue to be enhanced in subsequent releases.
PHP4 is supported in 4.3 production and later releases on Windows using the ISAPI interface. See the ISAPI Applications documentation for installation instructions.
When the Sambar Server crashes, a crash debug file sambar.dbg is generated in the Sambar Server installation directory. This file provides a stack trace of the server crash that can be used by Sambar Technologies to diagnose (and hopefully) fix the server crash.
This problem has been reported by users running Sambar Server as an NT Service. Microsoft has a patch for this problem. You need to get a new version of AFD.SYS and put it in your WINNT\SYSTEM32\DRIVERS directory. You can get this file from ftp://ftp.microsoft.com/bussys/winnt/winnt-public/fixes/usa/nt40/hotfixes-postSP1/
ODBC32 may not be installed on your machine if you are running Windows 95/98 (see the Install documentation for the location of Microsoft's free download site. Otherwise, ODBC32 may be installed on your machine, but may not be in your path; the sambardb.dll library is linked with odbc32.dll and requires it be available. First, using Explorer, attempt to find the file ODBC32.DLL on your machine. If found, then add that directory to your path in the Control Panel. If that fails, you will need to reinstall your ODBC32 software.
This indicates a catastrophic failure of some feature during server startup. The server.log is located in the log directory where the Sambar Server is installed. The most common failure of a new server installation is a "Failure to bind to port 80"; this is most often the result of another server (i.e. IIS) running on the machine.
This indicates that you have another application, typically a mail server, running on your machine. In addition to mail servers, some antivirus software (specifically, Norton AntiVirus 2000) runs on this port to intercept POP3 traffic between your mail client and server. There is a workaround for proxy server users; those wishing to use the Sambar Mail Server must disable the application running on port 110.
The first place to look when something appears wrong with the server is in the log/server.log file. (Note: The unusual file names and line numbers that appear with error messages are part of the Sambar Server debugging environment).
The other option is to telnet to the server (which is on port 80 by default) and request the home page. Once connected via telnet (make sure to turn on local echo on your telnet client), type GET / and press return twice. The server should return the home page in response.
Many Java applets require that DNS be setup on your local area network in order to communicate back to the machine from which the applet was served.
The security.ini file is cached during the startup of the server to enhance performance. For this reason, when modifications are made to the security.ini file, the server must be restarted or the administrator must reload the security configuration entries from the System Administration console. In addition, the security.ini [restrict] settings are only used for HTTP requests; to restrict access for FTP clients, .htaccess files must be used.
Microsoft Support Online article Q238171 indicates that in some cases, RAS ports disappear after a client disconnects (when using the Sambar Server proxy, the RAS port is continuously being connected and disconnected). The RAS problem arises from a mismatch in two different RAS modules, rasman.exe and rassrv.exe. The free port never reinitializes, it just disappears. Microsoft corrected the port disappearance in a late 1999 patch to rassrv.exe which you can get from Microsoft Support. This bug applies to all versions of Windows NT, independent of service-pack level.
Regrettably, I do not yet have an answer for this problem. The conflict is only reported when the Sambar Server ODBC interface is enabled. The solution for NT users is to run the Sambar Server as an NT Service. (Make sure that the ODBC datasources are configured as System DSNs) Why do I get the FORBIDDEN form when "successfully" logging in to the sysadmin area?
There are two common causes for receiving the FORBIDDEN form when "successfully" logging into the system administration forms (that is, you get the login form and correctly put in the username/password).
The Sambar Server uses an RDBMS infrastructure that is common to several applications developed by Sambar Technologies. This infrastructure is capable of generating DDL such as schema and index creation unique to specific databases. The Sambar Server does not use these elements of the RDBMS infrastructure, so this error message can be ignored.
The browser caches the magic cookie associated with your administration login. After a server restart, this cookie is no longer valid, so you must re-login. Unfortunately, because the browser often caches pages, you may find it difficult to login without getting the Forbidden message once you have received it the first time. The solution is to clear your browser memory and disk cache and then re-login to the administration console. With Netscape browsers, you can use the shift-reload command sequence to force an /session/adminlogin after receiving the Forbidden page.
Important: To avoid getting cached pages when moving among the System Administration pages, you should configure your browser to "verify documents every time." This option is a setting in the Netscape Network Preferences panel's "Cache" tab.
Netscape 4.x Browsers have the ability to turn off cookies (this may in fact be the default). The system administration console requires cookies for user validation. You also must be connecting directly to the WWW server you are trying to administer; if your browser is setup to use the Sambar Server as a proxy, you need to configure the browser to not use the proxy when accessing the local WWW server.
Users also often receive the Forbidden page if they restart the server and then use the "back" menu to return to the System Administration pages. Because these pages are in cache (Netscape ignores pragma no-cache), you are free to view the pages, but as soon as you select an option that hits the server, you receive a Forbidden message because you have not logged in the server as the system administrator.
By default you must connect to the server via http://127.0.0.1/session/adminlogin?RCpage=index.stm to access the administration pages. Remote machines can be granted access by adding host IP addresses to the valid System Administrator IPs. Failure to have your IP address in the System Administrator IPs will result in an "Invalid Login" message.
Assuming you are logging in correctly, the three most common causes of the Forbidden message are:Some ISAPI-based processing engines such as PHP (and many CGI scripts) perform their own HTTP header generation. The PrependScript directive can only be generated when the server has control of the HTTP header code generation (to adjust content lengths and prepend the script or macro).
If you forget the administrator password, your only recourse is to edit the config/passwd file and remove the encoded password in the third field (colon separated fields) of the administrator account. Then login as the administrator, no password is required, and reset the account password.
For other user accounts, you can go in as the administrator user and use the User Management forms to select the user who forgot his/her password and reset their account password.
© 1998-2001 Sambar Technologies. All rights reserved. Terms of Use.