|Version 5 (modified by moorman, 5 years ago)|
- Project Web and Developer Web Server Configuration Details
- Available software
- Disabling Project Web Service
- File management
- Service-specific terms of service
- Web Logs
- PHP Script Support
- CGI Script Support
- Server-Side Includes (SSI)
- Use of Third-Party Applications
- Getting Help
Project Web and Developer Web Server Configuration Details
SourceForge.net provides project web and developer web services based on a common platform. As follows are the technical details of that platform, provided to help you deploy pages and applications under these services.
Our web servers are configured with the following:
- Updated version of CentOS 5 distribution of Linux.
- Apache 2.2.3 web server
- PHP 5.2.6 under mod_php. View the full configuration by creating and accessing a PHP script containing: <?php phpinfo (); ?>
- Perl 5.8.8
- Python 2.4.3
- Ruby 1.8.5
- Tcl 8.4.13
It is the general policy of SourceForge.net that we will install additional software on the servers only when it is available from our software vendors. To request the install of additional software on our servers, please submit a feature request.
Data (i.e. files) served from the web servers may be throttled in order to optimize serving HTML and image content. As result, access to larger files in web space may be orders of magnitude slower than access to smaller files. Large file content belongs in the File Release System.
The traffic to and from the web servers is rate limited. Rate limits have been established to limit abuse of the web services and to reduce the possibility of traffic spikes which could greatly increase our bandwidth costs. The rate limits are not expected to impact common, acceptable project/developer web access.
Keepalive (HTTP 1.1 Pipelining)]] support is not enabled in our configuration.
Due to past abuse, outbound access to other hosts from the web servers is strictly prohibited, and is blocked by firewall rules. This includes access to other SourceForge.net hosts; the only exception to this policy is access to our our project database servers. CVS and Subversion server access is not available from the project web servers. Any content needed from other SourceForge.net hosts should be retrieved and stored as a file or database entry that may then be accessed from scripts on the project web servers.
While our PHP install (and other languages) include support for things like LDAP, IMAP and Postgres, we do not permit inbound or outbound connectivity using these protocols. These components are included so third-party code may be kept stock when being deployed on SourceForge.net web servers; and to support the testing of project code which requires these functions.
Disabling Project Web Service
Some projects wish to entirely disable the project web service and rely solely on the features provided on the SourceForge.net site. In these cases, we encourage the project to establish a simple redirect from the project web space back to their SourceForge.net project summary page. To set up this type of redirect, create an index.php file in the htdocs directory for the project, containing the following:
<?php //Get the information needed from the path to create the new URL $cwd = getcwd(); $unixname = substr($cwd, 18, (strpos($cwd,"/",19)-18)); $url = "http://sourceforge.net/projects/$unixname";// Send the HTTP Location header... should work for most browsers header("Location: $url"); //If we get this far the Location header wasn't processed...// Send a simple page with a link on it to the summary page ?> <html> <head><title><?php echo("SourceForge.net Project: $unixname"); ?></title></head> <body> <?php echo"You probably meant to go <a HREF=$url>here</a>."; ?> </body> </html>
File size limits
Large files should not be served from the project web service; alternatives are available. Files that are too large to be served from the project web services will generate a HTTP 403 error for the requester, based on a file size cap we have implemented. This cap, which prevents certain types of abuse, is set to reduce legitimate impact while encouraging use of the File Release System?.
Files uploaded to the project web servers from MS Windows-based workstations may require adjustments to their line endings. The 'dos2unix' program may be used to correct line feed style for uploaded files.
$ dos2unix filename_to_convert
Read-only web space
The web servers mount project group directories read-only. The following means are available for storing writable data (i.e. for project applications):
- Place the data in the MySQL database provided to your project. Projects are encouraged to make use of our project database service for application data storage.
- Persistent data is store in a location that is specific to your project. There is a symlink in your project's /home/groups/P/PR/PROJECT/ directory that points to this location.
- If you use this /home/groups/P/PR/PROJECT/persistent path for all your file references, you will be forward compatible with any future changes.
- Your user account has the ability to create files in that directory, but if you want to give your web application a place to write files, you'll need to create a subdirectory inside your persistent directory and set it with the permissions your application requires (since the top directory is kept obscure to non-project members, and the web server is not a member of your project).
- Projects using /tmp/persistent (prior to 09-18-2008) can find their old persistent data in /home/old-persistent via sftp. The /home/old-persistent data is not accessible via the shell service as these are different facilities.
Permissions and ownership
The project webserver runs as the user nobody and the group nobody (this may also appear as nfsnobody, due to our configuration across multiple hosts). All files must be readable by the webserver user, and that typically means the files must be world-readable (chmod o+r FILE). We recommend that the permissions be sed via sftp "chmod" or by modyifing a copy an rsync copying it back.
Web Environment Details
The following details of our web environment relate to script support, input and output on the web servers. These details are most often useful when testing web applications in project web space, setting up a project web site, or integrating third-party applications in project web space.
Index Page (start page): The index page for a website loads on default into a browser when no specific filename is specified (i.e. https://sourceforge.net and https://sourceforge.net/index.php are the same page, the index.php file loads by default). The project web servers support 3 default index pages (in this order of preference): index.php, index.html and index.shtml. No other filenames will load by default; this means that an index.htm file would need to be renamed to index.html to load. If there is an index.php and an index.html file in place at the same time, proper or expected access to the web page may be hindered.
Valid File Extensions: The filenames selected for files to be served by the project web servers can make a large difference on how a file is handled. The extension determines how a file is served to the end user and if any processing should be done on the file or if it should be served as-is to the requester. The three major file extensions supported for web files are .html for HTML pages, .php for PHP pages and .shtml for HTML with SSI. SSI will only be applied on files with an .shtml extension.
CGI Script Placement: CGI scripts are served only from the cgi-bin directory for the project; not from the htdocs directory space.
Shared Web Environment: SourceForge.net uses a shared environment for the project web services. This provides less-than-ideal file security for content, but as of yet there aren't any available solutions to this problem that scale large enough for the number of projects that we host (we are continually evaluating possible solutions for future use).
= Other Services=
We provide a Project database (MySQL) for all project web (not available for Developer Web space) instances which offer:
- Three pre-configured database users provide for admin, read-write, and read-only access.
- A centralized installation of phpMyAdmin.
Users may also take advantage of Custom VHOSTs services. SourceForge.net provides all projects with project web service at http://PROJECTNAME.sourceforge.net. Some projects elect to register vanity domains (such as PROJECTNAME.com, PROJECTNAME.net, etc.). SourceForge.net's project web servers may be configured to answer traffic for these domains through our Custom VHOSTs service.
Service-specific terms of service
Service Limitations (Unsupported Protocols)
SourceForge.net has deployed the web services using standard software loads based on the software packages made available by our OS vendors. In the course of providing a stock configuration, the libraries and functions to support various protocols may have been loaded on the system. A number of these libraries and functions pertain to data protocols that we do not directly support, and which are blocked by our outbound connectivity policies. These include:
- PostgreSQL (database; we only offer MySQL service at this time)
- LDAP (directory protocol)
- IMAP (mail server protocol)
- FTP (file transfer protocol)
- TELNET (interactive session protocol)
While SourceForge.net staff work to ensure the web services are comprehensive and useful service offering, we frequently receive requests to add support for various additional protocols, tools, and libraries. Requests of this nature may be submitted by submitting a Feature Request.
Based on past requests that were rejected, we have no immediate plans to offer the following as part of our web services:
- SSL (encryption)
- SF.net User Authentication
- JSP (programming language) support
- Per-User Web Space (we only provide web services to projects, not to users).
- Microsoft Front Page and Extensions
- WebDAV (file management protocol) support
- Dreamweaver Remote Admin support
Access Logs: We do not provide access to Apache access log data to projects. We do not support any means for projects to generate their own access logs. We do provide the means for projects to collect hit data to measure project activity. These policies have been established to protect the privacy of our end-users.
Error Logs: Error log data is an important tool for debugging problems with your project web site, particularly scripts you are testing, and third-party applications. Apache error logs may be found on the project server in /home/groups/e/er/error_logs. Logs are synchronized from the project web servers on a 15 minute interval.
PHP Script Support
PHP is a hypertext pre-processor. It takes the contents of a PHP file, processes the code contained within, and generates HTML to be passed on to the client on the other side. This allows for dynamic, interactive web sites. More information about PHP may be found at http://www.php.net or by reading the PHP documentation]].
PHP support is provided using Apache's mod_php. Files placed in the htdocs directory structure which have an extension of .php (such as index.php or filename.php) will be considered PHP scripts.
Many third-party applications require sessions support. Sessions are commonly implemented in PHP to track basic preference and authentication information about a user, as they browse pages on your project web site. We encourage you to store session data in your project database. If file-based session data storage is required, session data may be placed under the /home/groups/P/PR/PROJECT/persistent directory.
Our PHP configuration permits applications to use up to 8MB of memory. We strongly encourage you to optimize your application to run within this resource footprint. If your application requires more memory (it will return an out of memory error, stating that additional memory could not be allocated), and you have already optimized the memory usage of your application, contact SourceForge.net staff via Support Request. We may grant you permission to double the memory permitted for use by your application (to 16MB). If granted permission by SourceForge.net staff, you may create a .htaccess file in the directory of the PHP file that needs more memory. The .htaccess file should contain the following:
php_value memory_limit 16M
Alternately (and if granted permission by SourceForge.net staff), you may make the following change to the top of the PHP files that require more memory:
<?php ini_set("memory_limit", "16M"); ?>
In some cases, projects wish to display the contents of PHP files (i.e. their source code) rather than executing the code. PHP files given the .phps extension will be colorized and formatted for display by PHP, rather than being executed.
CGI Script Support
Common Gateway Interface, or CGI, is a method for executing binaries or interpreted scripts which generate HTML output, permitting the creation of dynamic web sites. CGI scripts may be written in a variety of programming languages. SourceForge.net supports the use of CGIs within the scope of our acceptable use policies for the web services.
In UNIX-based systems, CGI scripts must be run as a particular user. On our server, they are run as the user nobody, a member of the group nobody (the user nfsnobody may also appear, which, is effectively the same as the user nobody). Files that must be manipulated by scripts must be set to be world-writable. Writable files must be placed in the /home/groups/P/PR/PROJECT/persistent directory structure. The shared environment of our web service has significant security implications for file-writing applications; please program your scripts accordingly. You are encouraged to make frequent backups of all project data.
The project web services support the following CGI languages:
Compiled CGI scripts are not supported.
All CGI scripts must be located in the cgi-bin directory provided to the project. This directory is the only one that has the proper permissions to execute scripts for a project (ensuring that the scripts are secure is a must before placing them in the location for execution). The cgi-bin directory for a project is located at /home/groups/P/PR/PROJECTNAME/cgi-bin (where PROJECTNAME is the UNIX name of the project, P is the first character in the project UNIX name and PR are the first two characters in the project UNIX name).
Additionally, CGIs need to be world-readable and executable. You may set these permissions by executing the following command on the file:
$ chmod +rx FILENAME
All CGI scripts must return MIME type]] data as their first line of output (or an "Internal Server Error" will result). A CGI may generate any kind of content, including HTML or images. The MIME type of our output is defined by the Content-type line. Examples of two content type lines are:
Content-type: text/html Content-type: image/jpg
The following are a list of some sites that may be useful for each of the supported languages. Do note that not all of the information contained applies to SourceForge.net, specifically that of how to transfer files to SourceForge.net hosts and file permissions (covered above).
Server-Side Includes (SSI)
Server-Side Includes, or SSI, are supported on the project web servers. SSI provides another method of producing dynamic web content. SSI commands are put into an HTML comment, which is interpreted by the web server, resulting in dynamically-generated HTML. For help on how to use Server-Side Includes, please read the "Apache Tutorial: Introduction to Server Side Includes".
SourceForge.net project web servers will apply SSI to files ending in the .shtml file extension. The executable permissions bit has no impact on our SSI handling; SSI files must have a .shtml extension.
Use of Third-Party Applications
Projects may elect to install and use Open Source third-party applications, such as content management systems, template engines and discussion boards, within their project web space. SourceForge.net places no restrictions on the types of Open Source applications that may be hosted in project web space, provided they meet our other use requirements.
When using third-party applications, all installation, configuration and maintenance tasks fall to the project; SourceForge.net staff will not provide assistance related to third-party applications in project web space. If questions or concerns arise about deployment of software for your project team, please seek information from the software manual, the existing user community of that software, or the developers of that software.
Projects are responsible for ensuring all security fixes and version upgrades have been applied for software they deploy. It is important to keep in mind that the project web service is a shared environment; failure to apply security updates to your applications may impact the security of the project web service as a whole.
We encourage all projects to use the tools and features provided by SourceForge.net, rather than deploying similar software in project web space, whenever possible. This allows you to eliminate a large class of maintenance and update tasks that would otherwise consume project time, and allows you to take advantage of new innovations and enhancements made to the SourceForge.net site.
Projects are solely responsible for the backup and restoration of all data and software deployed in project web space.
In the event that we discover a vulnerable version of a third-party application has been deployed in your project web space, we may take this application offline without prior notice as to safeguard the security of the project web service for other users. Please take responsibility for all software you deploy in project web space.