How To Set Up Debian Linux Internet Servers
The material on this page was prepared using
Jessie 8.5 which only includes Apache 2.4.
For our page which covers configuring Apache 1.3
on Etch or Sarge, click here.
While Linux/UNIX can be used as a workstation OS it's real power shows itself when used as a server. The lean structure of Debian allows even old Pentium systems to operate as servers. And the fact that Web (Apache) and e-mail (Sendmail) server applications are free and included with Debian, once you've set up a Debian system all you have to do is install the Apache and Sendmail packages and you're in business.
On this page we'll show you how to set up the two most common types of Internet servers. A server running Apache to act as an external (Internet) or internal (Intranet) Web Server, and an e-mail server running Sendmail which is the most widely used e-mail server software on the Internet. Note that this is not an either/or proposition. You can run Web and e-mail server services simultaneously on the same system.
It's not really accurate to categorize Web and e-mail servers as "Internet servers". Web servers are often used for internal intranet sites and most organizations have internal mail servers so that co-workers can e-mail each other. So while these servers could also be categorized as "LAN servers", we have them on this page because they are the two most common types of Internet servers.Setting up the Web and e-mail servers is only half of it. Without DNS services no one will be able to get to them. On our DNS page we show you how to set up DNS services using either your own server or a third-party DNS provider.
If you want to set up a serious Web server you'll want some kind of scripting capability. The Apache install sets up CGI (Common Gateway Interface) automatically. With CGI the code that gets executed are stored in separate files on the server in a cgi-bin directory. With CGI you can run plain-text scripts that get compiled into an executable each time they are run, such as with Perl scripts, or they can be pre-compiled executables written in a language like C. The big advantage of CGI scripts is that, because they're stored in individual files, there are literally thousands of free CGI scripts available on the Internet that you can download and use on your Web sites. You don't have to learn how to program in a given scripting language to take advantage of scripts. For more information on CGI and Perl, see our CGI/Perl tutorial page.
Another approach to Web scripting is to embed the script code in the HTML documents. This is the approach taken with PHP, Microsoft's ASP, and ColdFusion and you have to learn how to program in these languages to use them. (When you're surfing the Web you'll often see Web pages in your browser's location line with extensions like .php, .asp, and .cfm which indicates the pages were written with this scripting approach.) The Web server parses pages with these extensions, picks out the embedded script code, and executes the script code before sending the page to the browser. Any results of the script execution are displayed in the page at the same location the script code is located in the HTML document. This scripting approach is the desired approach for Web developers who wish to have their Web pages access back-end databases.
Installing Apache on a system and not associating it with a domain name can also be valuable. Such a system can serve as a development or test platform when you're writing new Web pages or scripts so you're not testing these things out on your production Web server.
A Note About Windows Web Servers
Back on the Linux Basics page we outlined the cost differences in setting up a Linux Web/E-mail server vs a Windows Web/E-mail server ($20 vs $11,400 for 100 users). Some may feel they're tied to the Windows platform because they have a significant investment in ASP Web page development.
Good news! There's a project called Mono ASP.NET which will allow you to run ASP pages on Apache Web servers. Apache now has a mod_mono2 module and there's a Debian package called mono-apache-server2
Back on the Networking page we mentioned that if you plan to set up a serious, high traffic (read "thousands of page views a day") Web server you'll want to have a symetrical broadband connection to the Internet with a static IP address. However, if you just want to set up a Web server to host one (or even several) small Web sites you can do so using your home broadband connection and a dynamic DNS service (which we show you how to do on the DNS page). Just keep in mind that when you do this you open up your system to traffic from all over the world and there are a lot of hackers out there, so be sure to harden your Web server before going live (see the Security page for more information).
Most of the applications that run on servers are "daemons" (pronounced dee-mons). Daemons are applications that run in the background, waiting for some specific event to trigger them, such as an incoming request for a Web page from a Web browser. Don't confuse daemons with "processes". Processes are "instances" of an application running in memory. For example, the Apache Web server daemon can kick off multiple Apache processes to handle simultaneous requests from multiple browsers. You can see what processes are currently running in your system's memory by typing in the command:
The number of initial processes is configurable, and if requests from more Web browsers come in than there are processes running, the Apache daemon will kick off more. Other programs will never have more than a single instance (process) running. The number of processes an application will kick off (single or multiple) to handle the load will depend on the design of the application.
Your Home Web Server
If you are currently using a Web hosting service to host a Web site that doesn't get a lot of traffic you may want to consider using your home broadband connection to bring your Web site "in house" to save money. The EasyDNS service is only $35 per year ($55/year if you want to receive e-mail at your domain name) vs whatever you're paying per month to the Web hosting provider. Not only will you be saving money, but you won't have any disk storage limitations and you can set up your server with CGI or PHP scripts or whatever else you want. Just be sure your site can handle the down-time you'll have when your home cable service or power goes out.
We're going to assume you already have a broadband connection and a cable/DSL router which allows multiple computers on your home network to share the connection, and that your Debian system is configured to access the Internet through the router. The cable/DSL router may act as a DHCP server dishing out IP addresses to systems on your home network (Linksys typically dishes out addresses from 192.168.1.101 and higher). However, your Debian server needs to have a static IP address (something like 192.168.1.12).
With a broadband router in place and your Debian system configured with a static address and able to access the Internet through the router, the steps to setting up a home Web server are fairly simple:
- Install and configure Apache (next section).
- Create your HTML and graphics files for your Web pages and FTP them onto your server (they go into the /var/www directory). If you're not a Web developer you can just Google for "free html templates" to get a kick start on creating your HTML pages.
- Set up an account with an organization like EasyDNS to register your domain name and provide DNS resolution services for your domain name (we show you how on the DNS page).
- Configure EasyDNS to use Dynamic DNS for your domain (also on the DNS page).
- Install the ddclient package on your Debian system and configure it to send updates to your EasyDNS account (also on the DNS page).
- Set your cable/DSL router to route all incoming (from the Internet) TCP traffic destined for
port 80(Web traffic) to your Debian system.
That's all there is to it. Complete these steps and your Web site is live on the 'Net! Actually, it'll take a few hours for your DNS information (the information ddclient is sending to EasyDNS) to get propogated to the DNS servers of ISPs, but anyone anywhere should be able to browse to your Web server using your domain name by the next day.
Setting the cable/DSL router to forward all incoming
port 80TCP traffic to your Debian system depends on what type of router you have. On a Linksys router, the port forwarding is found under the "Applications and Gaming" section of the router configuration.
Note that in this example we're assuming your Debian server's static IP address is 192.168.1.12. Be sure to click on the "Save Settings" button at the bottom of this page after entering your port forwarding numbers.
The port forwarding feature of a router can also be used to forward different types of Internet traffic to your server or to different devices. For example, if you were going to set up your Debian server as an e-mail server, you'd want to put in a second entry to forward port 25 (the SMTP port) traffic to your Debian server.
Setting Up An IP Cam
Another example would be to set up an IP camera (also referred to as a network camera) at your home that could be viewed from anywhere on the Internet (or made a part of the Web pages on your Web server). Note that an IP camera is not the same as a typical "Web cam" that connects to a computer via a USB cable. An IP camera is a stand-alone device with a network (RJ-45 or wireless) connection that contains it's own internal Web server. As such it acts like a stand-alone server.
IP cameras used to costs hundreds of dollars (and the high-end models still do). However, you can now get a low-end IP cam like the
Trendnet TV-IP110for around $80. Setting up one of these units for Internet viewing is pretty easy.
Because these cameras are self-contained Web servers, they are set to "listen" for requests on port 80 by default. However, port 80 is already being used by our Web server so we need to change that. This is easy to do because we have to go into the Configuration/Network setup menu in the camera in order to change the IP address anyway.
Note that in the above camera configuration page we set the IP address to 192.168.1.40 and set the port the camera should listen on to 8080. (You can use your own values of course.) Also note that this camera supports EasyDNS dynamic DNS registrations if you have an account with them. (More on dynamic DNS on the on the DNS page.)
Next, we set the cable/DSL router to route port 8080 traffic to the IP camera.
You can browse to your camera from your internal network by using it's IP address and port number as so:
In order to browse to the camera from the Internet you'll either need to know the external IP address of your router (the IP address assigned to you by your broadband provider) or you'll want to use your own domain name with a dynamic DNS service (see our DNS page for information on how to set that up). If you have this set up already for your Web server, then the URL would be something like:
If you want to set up multiple cameras, you'd just set each camera to use a different port, and put a corresponding entry in the router for each camera.
Setting Up An Apache Web Server
With the release of Lenny Debian no longer supports Apache 1.x. The default version is the newest major version (2.4). From our perspective the main differences between 1.x and 2.x are primarily in how configuration files are organized, focusing on virtual hosts.
In Apache-land a virtual host equates to a Web site. Virtual hosts are what allows a single Apache Web server to serve up multiple Web sites which is why there are so many Web hosting companies out there. You set up one Linux (free software) server and install Apache (free software) on it and you can host hundreds of Web sites, charging each Web site owner a monthly fee to have their site on the server. If you go through the trouble of setting up a home Web server to host your Web site(s), there's not a lot of work involved in also hosting sites for your friends and family members.
All we need to do to install Apache is enter the command:
apt-get install apache2
The will install the Apache application and all dependent files. After the installation Apache starts automatically and is set to start automatically when the system is booted.
If you just want to play around with a Web server and not have a domain name associated with it (like with a test Web server) you're pretty much done. You can verify Apache is working by going to another system on the same network as your Debian server and entering the address of your Debian server in the browser's address line, something like:
A page should appear with the words "It works!" at the top of the page. This is the default /var/www/html/index.html file that comes with the apache2 package. (This page actually contains some very useful information about your Apache installation so you may want to print it out.) You can add your own pages and images into the /var/www/html directory.
The main configuration file for Apache is the /etc/apache2/apache2.conf file. Like just about every Linux/UNIX configuration file, it is a plain old ASCII text file so you just use a text editor to make changes to it. Luckily, the defaults in the configuration file are pretty much what we need.
The way Debian's Apache 2.4 package sets things up makes it easy to add (and remove) Web sites (virtual hosts) to your server. The two directories you need to focus on are
/etc/apache2/sites-availableand /etc/apache2/sites-enabledand these two directories are specific to Debian (and Debian derivatives such as Ubuntu). Actually, the /etc/apache2/sites-enableddirectory just contains sym links to the configuration files in the /etc/apache2/sites-availabledirectory. That's how you enable and disable sites, just add and remove sym links in the "-enabled" directory. (Sym links are like shortcuts in Windows.)
There's a default configuration file calledDebian uses this available/enabled directory and sym link scheme for configuration options and Apache modules as well. To see what Apache modules are available to you by default simply look in the modules available directory with the command:
However, this is only a small number of the many modules, which are like plug-ins, available for Apache. To see what is included with Debian enter the command:
apt-cache search apache2 module | more
Pressing the Enter key will advance the display one line at a time. Pressing the space bar will advance it one screen at a time. Press q to quit the display.
000-default.confin the /etc/apache2/sites-availabledirectory. And there's a sym link to it in the /etc/apache2/sites-enableddirectory called 000-default.confwhich is a special name. The link name ensures it is read first at startup by Apache even when other sym links (for additional Web sites) are added to the directory.
Remember, you only want to edit the configuration files in the
A Single Web Site
If you want to set up a real Web server that hosts one Web site (one domain name) then you don't have to do much. That's because only one domain name will have a 'www' DNS record which points to this server's IP address. You may want to edit the default configuration file with the command:
and you'll notice that the few configuration settings contained in this file are enclosed in a set of VirtualHost tags. That's because these files simply become a part of the main configuration file when Apache starts up. Enter your e-mail address in place of 'webmaster@localhost' on the line:
Then press Ctrl-X to exit the editor and save the file. Now you can just load your HTML files and images into the /var/www/html directory and your Web server and site is up and running and accessible to anyone on your network by using the Debian system's IP address as we did above immediately after the install.
Multiple Web Sites
If you want to host multiple Web sites on your server (i.e. use the Virtual Hosts feature of Apache) you'll need to set things up a little differently. In the following examples we're going to set up the following three Web sites: moe.com, larry.com, and curly.com. Because the 'www' DNS records for each of these domains are all going to point to the same IP address (and all use the same port 80) we'll be using Apache's name-based virtual hosts. With name-based virtual hosts, the browser includes the domain name in the HTTP request it sends to the IP address of the Web server. This is how Apache knows which Web site is being requested. Very early browsers didn't support name-based virtual hosts but all current browsers do.
The first thing you need to do is create a "document root" sub-directory for each Web site under the /var/www directory. In our example you would enter the following commands to do this:
The sub-directory names don't have to match the domain names. It just makes it easier to manage the sites if they do.
You also have to do the same for the CGI sub-directories.
As mentioned, each Web site needs it's own file in the
/etc/apache2/sites-availabledirectory and, to be enabled, it's own sym link in the /etc/apache2/sites-enableddirectory. In each file you enter that site's "virtual host block."
We want to keep the current '000-default.conf' file so that we can go back to a clean slate later if we want to so we'll save original file by renaming it with the command:
mv /etc/apache2/sites-available/000-default.conf /etc/apache2/sites-available/_default.conf
and delete the sym link with the command:
Now we'll use a text editor to create our first site's configuration file with the commands:
and enter the following statements into it:
<VirtualHost *:80> ServerAdmin email@example.com ServerName www.moe.com ServerAlias moe.com DocumentRoot /var/www/moe/ # Set Document Root directory options <Directory /var/www/moe> Options +FollowSymLinks -Indexes +Includes # Allow use of .htaccess file AllowOverride Limit FileInfo </Directory> ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/moe/ # Set CGI-BIN directory options <Directory /cgi-bin> AllowOverride None Options +ExecCGI -Multiviews +SymLinksIfOwnerMatch Order allow,deny Allow from all </Directory> CustomLog /var/log/apache2/moe-access.log common ErrorLog /var/log/apache2/moe-error.log </VirtualHost>
Press Ctrl-X to exit the editor saving the file. Create a copy of this file for our second site with the commands:
cp moe.conf larry.conf
Then open the newly-created file in a text editor with the command:
and make the relevant changes:
<VirtualHost *:80> ServerAdmin firstname.lastname@example.org ServerName www.larry.com ServerAlias larry.com DocumentRoot /var/www/larry/ # Set Document Root directory options <Directory /var/www/larry> Options +FollowSymLinks -Indexes +Includes # Allow use of .htaccess file AllowOverride Limit FileInfo </Directory> ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/larry/ # Set CGI-BIN directory options <Directory /cgi-bin> AllowOverride None Options +ExecCGI -Multiviews +SymLinksIfOwnerMatch Order allow,deny Allow from all </Directory> CustomLog /var/log/apache2/larry-access.log common ErrorLog /var/log/apache2/larry-error.log </VirtualHost>
Press Ctrl-X to exit the editor saving the file. Then create another copy of the original file for our third site with the command:
cp moe.conf curly.conf
Then open the newly-created file in a text editor with the command:
and make the relevant changes:
<VirtualHost *:80> ServerAdmin email@example.com ServerName www.curly.com ServerAlias curly.com DocumentRoot /var/www/curly/ # Set Document Root directory options <Directory /var/www/curly> Options +FollowSymLinks -Indexes +Includes # Allow use of .htaccess file AllowOverride Limit FileInfo </Directory> ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/curly/ # Set CGI-BIN directory options <Directory /cgi-bin> AllowOverride None Options +ExecCGI -Multiviews +SymLinksIfOwnerMatch Order allow,deny Allow from all </Directory> CustomLog /var/log/apache2/curly-access.log common ErrorLog /var/log/apache2/curly-error.log </VirtualHost>
Press Ctrl-X to exit the editor saving the file.
Now that we have the necessary files in the /etc/apache2/sites-available directory we need to create the sym links to them in the /etc/apache2/sites-enabled directory. Debian has a utility that makes this easy for us. Enter the following commands to enable the three sites:
Note that you can use a2dissite to disable a site once it's been enabled.
Now restart Apache so it reads our new configuration files with the command:
Your Web server is all set up but your name resolution isn't. If you want to test your server you'll need to modify the hosts file on your PC entering the IP address of your server for each of the domains like so:
This will force your PC to access the above domains on your Debian server even though those domains exist on the Internet and DNS would have taken you to those Internet sites. On a Windows system the hosts file is located in the following directory:
Assuming you've changed the port forwarding in your cable/DSL router to forward port 80 traffic to your Web server, in order for people on the Internet to access your Web server you'll need to update the DNS records for the domains. We cover this on the DNS page. (Be sure to remove the above entries from your hosts file once you've got the DNS updated.)
Note that in our example above you'd need to register each of these domain names and get DNS services for them. If you get all your domain names from a provider like EasyDNS you can update the dynamic DNS information for all of them simultaneously. We show you how to update multiple domains simultaneously on our DNS page.
SSI - Server Side Includes
SSI is just what the name implies. When Apache is serving up a Web page (HTML file) it can look through ("parse" the HTML code looking for SSI statements (called 'directives') embedded in the HTML code of Web pages. These directives retreive certain information, such as date or time or even the contents of other files and Apache includes this information in the page it sends to the browser. For instance, a common usage of SSI is to have one header or footer file for all Web pages and have them included in every page. That way if you need to change the HTML in the header or footer you don't have to change every page, just the one or two files that get included. Some CGI scripts can only be run via an SSI directive. Apache finds the SSI directive instructing it to run the script, runs the script, and then takes the output of the script and includes it in the Web page where the directive is located. Apache won't look through ('parse') HTML pages looking for SSI directives by default. We have to do two things to enable it:As mentioned earlier, the Debian implementation of Apache handles modules like it handles sites. There's a1. Add the Includes option to the configuration file (we did this above)
2. Have Apache load the includes module when it starts (we'll do this below)
3. Give HTML files a .shtml extension
/etc/apache2/mods-availabledirectory that has 'load' statements for a lot of modules and a /etc/apache2/mods-enableddirectory that you create sym links in to enable modules. To have Apache load the includes module we enter the following commands:
Now we have to restart Apache with the command:
That's all there is to it! You're now ready to start serving up SSI-enabled Web pages.
If you want to test the SSI functionality use the text editor to create this simple Web page (replace the html directory below with one of the site directory names if you set up a multi-site configuration):
and enter the following HTML code into it:
<html> <body> <pre> <!--#printenv --> </pre> </body> </html>
Note that the only content of our Web page is an SSI directive to get the system environment information. Exit the editor saving the file. Now go to a different system on the network, fire up a Web browser, and enter the URL using the server's IP address like so:
You'll have to use one the site name that corresponds to the directory name above if you set up a multi-site configuration.
There are numerous ways to harden an Apache installation. If your firewall is properly configured the only traffic that should get to your Web server would be traffic going to port 80 (i.e. HTTP traffic). However, HTTP traffic can still be malicious.
Many of Apache's error pages have a footer with a horizontal line and the text:
Apache/2.4.10 (Debian) Server at www.moe.com Port 80
Often times hackers will send bogus HTTP requests to get the server to generate these error pages because the information about the server OS and Apache version can be useful to them. We can reduce the information given out in such instances by making a couple simple changes to a security file. Open the file in a text editor with the command:
Look for the lines:
# ServerTokens Minimal
# ServerSignature Off
and reverse the comment character on these two pairs of commands so they read:
# ServerTokens Full
# ServerSignature On
Exit the editor saving the file and restart Apache.
While the above changes will cut down on the information given out about our server it won't do anything for malicious HTTP requests. Luckily there's an Apache module called mod_security that acts like an IDS (Intrusion Detection System) monitoring incoming HTTP requests and denying access to any requests that look suspicious. For instructions on how to set up mod_security see the "Securing Apache" section of our Security page.
The important file locations for Apache on a Debian system are:
Configuration files directory (aka "ServerRoot") - /etc/apache2
- Web page files directory (aka "DocumentRoot") - /var/www
- CGI scripts directory (aka "cgi-bin") - /usr/lib/cgi-bin
- Log files directory - /var/log/apache2
- The Apache executable file - /usr/sbin
You can tell which version of Apache you're running using the command:
Where to learn more - The best of our bookshelves:
Trust me, Linux Apache Web Server Administration is the only Apache book you'll need. It thoroughly covers Apache and all the goodies including both IP-based and name-based virtual hosting, advanced directives, CGI, SSI, SSL, redirection, and using modules. If you want to set up a Web server that requires someone to log in to view the site's contents there's an entire chapter on options for how to do this. He also gives some sample Web pages (the HTML code for them) that you can use to securely monitor your Apache server over the Web and test out SSI. It's written in a manner that's easy for Apache newbies to understand while not boring those with some experience with it. The file locations given in the book are for a vanilla Apache installation and most Linux distributions tend to rearrange things a bit. However, that's an easy adjustment to make. (See our list of file locations above.)
You can use telnet to act like a browser to test out Apache. You can use any computer on the same local network to run telnet and connect to port 80 (that's the port HTTP listens on) on the server to issue the commands. Assuming your Debian system's IP address is 192.168.1.12 the following command will connect you to the HTTP service. On a Windows system, open a command prompt and enter this command:
telnet 192.168.1.12 80
If you don't have another system to try this from you can get on the Debian system and enter the above command using localhost in place of the IP address. Once you're connected (you won't see anything appear on the screen upon connection), type in the following command being sure to use the upper-case syntax as shown (the characters will not echo when you type them):
GET / HTTP/1.0
and press Enter twice. You should see the HTML code of the Debian placeholder page go flying by. The first slash in the command is the Web page specification and we didn't specify any. When no page is specified the home page (i.e. index.htm) is returned. To specify a page, enter the page name after the slash (i.e. /test.shtml).
Above the page's HTML code is the HTTP "header" which looks something like this:HTTP/1.1 200 OKYou can also see this information by entering this command while still telneted into port 80 of the server:
Date: Wed, 31 Aug 2016 22:18:37 GMT
Server: Apache/2.4.10 (Debian)
Vary: Accept-Encoding Connection: close
HEAD / HTTP/1.0
(Be sure to press Enter twice after entering it.) Why would you want to do this? For troubleshooting and testing mainly. Some times you'll try and pull up a Web page and get nothing but a blank white background. The above GET command will show you what, if anything, the Web server is sending the browser.
You can also see the output generated by certain CGI scripts (scripts that generate output intended to be displayed on Web pages) that you may have installed. Simply specify the path and name of the script in the GET command:
GET /cgi-bin/hitcount.cgi HTTP/1.0
Another reason is automation. Do you check certain Web pages on a daily basis (or would you if you had time)? Once you get good at script writing you could probably write a script that would retreive a page, parse it for desired information and extract it when it finds it, and then e-mail just that information to you.
Secure Web servers, the type that use SSL for https-type connections (the type that give the closed-lock symbol on your browser's location bar), are not for the casual server administrator. Having a secure Web server not only involves having the SSL software added to your Apache installation but requires that the operating system be hardened to prevent unauthorized access. Then there's the issue of obtaining an SSL "certificate" from an outfit like Verisign or Thawte and installing that on the server (and they have to be renewed annually for a fee). If you're collecting or serving data that requires a secure connection, chances are the sources of that data would sue you if it ever got into the wrong hands. These types of secure servers are best left to professional hosting companies, whether they be for e-commerce or other functions. That's not to say you should never try and set up an SSL Web server. Just be prepared to do a considerable amount of studying and work. You'll need to be knowledgable not only in the areas of SSL software for Apache and server certificates, but quite a student in the area of overall Linux OS security as well.
Light the LAMP
For those who are in, or are looking to learn, the Web development area then setting up a development or "learning" server can be very valuable.
It's so common these days to use PHP Web pages to access back-end data in MySQL on an Apache server that such servers are referred to simply as LAMP servers (Linux, Apache, MySQL, PHP). Whereas installing Apache alone allows you to serve up static "brochure" type Web pages, CGI, PHP, and MySQL can turn you Web server into an Internet application server.
Adding PHP support to your Web server may be a good idea even if you don't plan on using MySQL. Like Perl CGI sripts, there are a ton of freely downloadable PHP scripts available on the Web. (Whereas Perl scripts are contained in their own separate file, PHP scripts are contained in Web (html) pages which are given a .php extension.)
NOTE: There is a downside to installing PHP on your Web server. I can tell you from personal experience that hacking attempts against your Web server will increase dramatically once you install PHP because hackers will probe for insecure legacy files and scripts. Unless you need the functionality provided by a PHP script, err on the side of security and don't install PHP.Naturally, if you're just playing around with this stuff or are setting up an off-line development platform then security isn't an issue so you can load it up. You can install PHP support with the command:
apt-get install php5
There's a lot you can do with PHP that doesn't have anything to do with databases. However, if you want to use your PHP pages to access MySQL databases, you'll have to install MySQL and a libraries package. To install the MySQL package, enter:
apt-get install mysql-server
This is a "meta package" that will install the latest version of MySQL that you have a package for. During the installation you'll need to enter a password for MySQL's root administrative user. This is not the same user as the root user you created for Debian but you can use the same password for both users.
Now we install the library files with the command:
apt-get install php5-mysql
That's it! All we have to do is restart Apache so the PHP module gets loaded with the command:
You can verify that Apache is now supporting PHP by creating an HTML file with the command:
and add the following lines to it:
<?php phpinfo(); ?>
Exit the editor saving the file and get on a system that's on the same network as your Debian system and fire up the Web browser and see if you can pull up the PHP page. If your Debian system has an IP address of 192.168.1.12 then you'd enter the following URL in your browser:
While the above HTML code doesn't look like much, you'll get a LONG page with all kinds of system and environment information as a result of the phpinfo() function embedded in the HTML. If you're planning on playing around with LAMP functionality you may want to print this page out as well.
As with any programming language, scripting languages included, it's always good to have a test server to test out new pages and code development. One error in the code can crash a server or cause an endless loop bringing a server to its knees. As you can see, setting up a test PHP server is easy so there's no reason to risk bringing down a production Web server if you plan to do any PHP development.
When using PHP pages to access a MySQL (or any other) database, you can have the Web server hosting the PHP pages be on a separate system from the database server running MySQL. In this case you'd want to put both the Web server and database server in the DMZ. However, for smaller deployments there's no reason why both PHP and MySQL can't be set up on the same system. One exception to this may be if the data you collect on via a Web site and store in the database is of a sensitive or private nature. In this case, the data may be more secure if it was stored on a separate database server that's not located in the DMZ.On the Database Server page we'll show you how to use MySQL to create a database and try a test to make sure the Debian system is indeed acting as a database server.Just as you looked at all the Apache modules available earlier, you can use the same command to see how many additional packages there are for PHP or MySQL by entering:
apt-cache search php | more
apt-cache search mysql | more
Setting Up A Sendmail E-mail Server
Debian installs the Exim mail server software by default when you do even a basic installation. Sendmail is much more widely used and much more powerful. It's sendmail.cf configuration file is legendary in it's complexity. But due to its complexity, if you ever need any special configuration features, there's likely a way to set up exactly what you want.
Also included with Debian is a package called MailScanner that you can use on your e-mail server to scan incoming attachments for viruses. A link to the MailScanner Web site is given on the Resources page.
There's actually two server services involved with a mail server. First, you have an MTA (Mail Transport Agent) that is responsible for exchanging mail with other mail servers and forwarding mail that is being sent by clients. This is the part that Sendmail handles (i.e. Sendmail is an MTA).
Then there's the service which allows POP clients to log in and retrieve their mail from the server. The mail messages are transferred from the user's "mailbox" (a file) on the server to their "inbox" (a file) on the user's local hard-drive. Sendmail doesn't do POP so we need to install that separately. (IMAP is another protocol clients use to "retrieve" messages but in IMAP's case the client is more of a viewer as the messages stay on the server.)
The MTA service uses the SMTP (Simple Mail Transfer Protocol) protocol to transfer and forward mail. The POP service uses the POP3 (Post Office Protocol v3) to send messages from the server to the client. You'll see examples of both of these protocols in action later in this page.Terminology:Unfortunately spammers have caused everyone to lock down their mail servers so it's virutally impossible to play around with Sendmail to send Internet e-mails from a non-existant domain (assuming that's what you used when you installed Debian). If you have your own real domain name and are using a dynamic or static DNS service like the ones we outline on the
- MTA - Mail Transport Agent The server-based application that routes mail from MUAs (clients) to other MTAs and accepts mail from other MTAs. Sendmail is the most popular MTA. Exim and Microsoft Exchange are others. MTAs use the SMTP protocol to accept and route mail from MUAs and to send/receive messages to/from other MTAs.
- MUA - Mail User Agent This is the nerd term for the e-mail reader client software run on most PCs. Common MUAs are pine and elm on UNIX/Linux consoles and Microsoft Outlook and Thunderbird on Windows. They use the SMTP protocol to send messages and the POP or protocol to retreive messages.
- SMTP - Simple Mail Transport Protocol "Protocol" is just a fancy term for "a set of rules that you have to follow". With SMTP (and many other communications protocols) the "rules" are the commands and their syntax (which you will see in action below). The SMTP protocol is a set of commands used to communicate with/between MTAs and with sending MUAs. SMTP listens on port 25.
- POP - Post Office Protocol A message retrieval protocol (commands) used to communicate with a POP service running on a mail server. The most commonly-used versions are POP2 and POP3. An MUA uses POP commands to communicate with the POP service (daemon) to retreive any messages stored in a mailbox file. While IMAP (Internet Message Access Protocol) is another common mail client protocol which leaves the messages on the server, you can configure your POP client to also leave the messages on the server. POP listens for clients on port 110.
- IMAP - Internet Messaging Access Protocol IMAP is the preferred client-to-server protocol if you need to access your messages from multiple devices as the messages are not downloaded to the client but rather stay on the server. The downside of IMAP is that most servers have a limit as to the number of messages you can keep (disk space limitations) and if your e-mail account is hacked all of your messages are visible to a hacker and they can all be deleted by a hacker. (With POP only the messages that have arrived since the last time you retrieved/viewed your e-mail would be accessible to a hacker - provided your POP client isn't configured to leave messages on the server.) The IMAP server process listens on port 143.
DNS Servicespage you can manipulate your DNS records so that you'll be able to actually send and receive Internet e-mails using your Sendmail server. Otherwise you're limited to sending local e-mails between user accounts on the Debian system. For example, during the installation you created a user account. While logged in as root, you could send an e-mail to this user and then view it the next time you log in as that user. To do this you enter only the user name in the "To:" field (which we'll show you in a bit).
The first thing you have to do is install a package that the Sendmail installation needs to already be there.
apt-get install make
Next is installing the Sendmail package. (When you install Sendmail, apt will remove Exim.) To install it you simply enter the command:
apt-get install sendmail sendmail-bin
We specify three package names here only because the Sendamil package in Jessis is a bit of a mess with some dpendency issues and this is a way around that.
During the installation you may see some error messages in addition to the typical multi-disc dpkg errors particular pertaining to FEATURE() and MAILER(). We're going to take care of that now by editing one of Sendmail's configuration files.
And as long as we're editing the configuration file we'll take care of another problem. For security reasons Sendmail defaults to only listening to port 25 on the loopback address (127.0.0.1). As a result you can only send mail between users on the Debian server. We'll change that so it listens on whatever IP address your Debian system has.
As you'll see below, we can reconfigure Sendmail at any time. When we run the sendmailconfig utility it inputs the sendmail.mc file and outputs the sendmail.cf file. To clear those FEATURE() and MAILER() errors we have to edit the sendmail.mc file with the command:
Arrow down and near the bottom of the file you'll see three lines that start with MAILER and a comment line above those. These need to be moved to near the top of the file by doing the following:Now we can reconfigure Sendmail with the new file by typing in the following at the shell prompt:
- Put the cursor at the beginning of the comment line that reads:
dnl # Default Mailer setupand press Ctrl-^ to start a highlight block.
- Press the down arrow key four times to highlight the comment line and the three MAILER lines.
- Press Ctrl-K to cut the lines to the clipboard.
- Arrow doown to the bottom blank line of the file.
- Press Ctrl-U to paste the contents of the clipboard.
- Now arrow to a line near the beginning of the file (after all the comment statements) to a line that looks like this:
DAEMON_OPTIONS('Family=inet, Name=MTA-v4, Port=smtp, Addr=127.0.0.1')dnland remove the Addr=127.0.0.1 clause so the line looks like this: DAEMON_OPTIONS('Family=inet, Name=MTA-v4, Port=smtp')dnl
- Press Ctrl-X to exit the editor, answer Y to save the changes and Enter to confirm.
and pressing Enter. You'll be asked a series of questions. Answer them as follows:
- Accept the default Yes to the prompt about using the existing sendmail.conf file by pressing Enter.
- Accept the default Yes to the prompt about using the exiting sendmail.mc file by pressing Enter.
- Accept the default Yes to the prompt about reloading Sendmail by pressing Enter.
That takes care of Sendmail. Now you'll also want to edit the /etc/hosts file.
and make sure the line for the local system contains the following:
- the IP address of your system followed by a Tab character
- the host name of your system followed by a Tab character
- the FQDN (Fully Qualified Domain Name) of your system followed by a Tab character
- the words loghost and mailhost separated by a space
When you make the changes the top of the file should look like this:
127.0.0.1 localhost.localdomain localhost 192.168.10.10 debian.your-last-name.net debian loghost mailhost
Exit the editor saving the file.
We want to test out our Sendmail installation by sending e-mails to/from the root user. However, by default root can't receive any e-mail. Root e-mail is sent to another user. (It's a security thing so root doesn't have to log in just to check e-mail.) We want to undo that so we can use the root acount for our testing. Enter the command:
and lookd for the line like:
where billgates is the name of the user account you created when you installed Debian. Comment out this line like so:
and save exit the editor saving the file (Ctl-X,y,Enter).
At this point you have to restart Sendmail because it only reads the configuration file when it starts. However, given the file edits we've made it may be wiser to just reboot the system.
The important file locations for Sendmail on a Debian system are:
- Configuration files directory - /etc/mail
- Incoming mail queue directory - /var/spool/mail
Messages are stored in files with names that match each username. These are the user "mailbox" files that are kept on the server. Each mailbox is a single file that contains all e-mail messages. This file is usually cleared out when a user's POP client downloads their messages to their inbox (unless the POP client is set to "leave messages on server").
The above is a known as the "Mbox" format of mailbox files. Another common format is called "Maildir" in which is each user has a subdirectory named Maildir in their home directory. In addition, each e-mail message is stored in a separate file.
- Outgoing mail queue directory - /var/spool/mqueue
With a full time Internet connection this directory should be empty because the messages will get sent out as soon as the recipient's domain name is resolved via DNS (i.e. almost immediately).
- The Sendmail executable file - /usr/sbin
To find out what version of Sendmail you're running, as well as some other information which will allow you to verify your Sendmail configuration, use the command:
/usr/sbin/sendmail -d0.4 -bv root
The version number is one of the first lines to be displayed. Also note the Canonical name just a few lines underneath the version number. Near the bottom you'll see a list of users that can receive mail. If you haven't created any other user accounts there'll only be the one user you created during the Debian installation. Take note of this user name and the canonical name. You'll need these in a bit for a test.
Where to learn more - The best of our bookshelves:
O'Reilly's book Sendmail, commonly referred to is "the bat book", is the industry bible when it comes to Sendmail. However, it's definitely not the first book on Sendmail you want to read. Linux Sendmail Administration is the companion to the above Apache book and is just as well written (enjoyable for both Sendmail newbies and those with some experience) and just as wide in it's coverage of the application. In addition to installation and configuration (both m4 and manual), chapters address implementing anti-spam measures and application security. It also covers all of the technical goodies of Sendmail such as uing databases and rewrite rules. However, this isn't until after the first two chapters show how Internet e-mail works and present a high-level overview of the functional parts of Sendmail. Having wrestled with Sendmail a few times in the past I can tell you that a book like this was sorely needed.
Note that the Sendmail people only support using the 'm4' processor to configure Sendmail (not the sendmailconfig utility provided by Debian). The usage of of m4 is covered in the above book.
Testing Sendmail (SMTP)
If you read through our
DNS Servicespage and you're using a DNS service like EasyDNS because you have a real domain name you'll want to update your MX (Mail eXchange) DNS record to point to your server. (You may need to rerun the ddclient program as detailed on the DNS Servicespage after doing so.)
If you're setting up a real mail server you'll have to tell your ISP (or whoever is hosting your DNS records) to change the MX record for your domain so that it points to the IP address of the Internet-connected interface of your Debian system (or of the firewall that's doing a static address translation to the mail server).
Once your DNS records are updated and the changes have propogated you should be able to send Internet e-mails using the Linux mail utility as follows:
- At the shell prompt type in the word mail followed by the e-mail address of the recipient
(ex: mail firstname.lastname@example.org )and press Enter.
- The Subject: line will appear so just enter an appropriate subject and press Enter.
- Type in the text of your message. You can hit Enter to insert line-feeds in your message if you want. Ask the recipient of the message to forward this message onto your regular e-mail address so you can take a look at it. If you're using a fictitious domain name you may also want to add a note telling them not to reply to the message. If they did, their reply would just get bounced back to them because their mail server would be unable to resolve your ficticious domain name.
- When you're done typing your message press Enter to put the cursor at the beginning of a blank line and press the Ctrl-D key sequence.
- The Cc: line will appear where you can enter another address if you want. Otherwise just press Enter and the e-mail will be sent.
With a real domain name and updated DNS records you should also be able to receive Internet e-mails on your Debian server. You'll want to use a different system, such as a Windows PC, with either a mail client configured for another SMTP server or using a Web-mail account to try and send an e-mail to your Debian server.
Using the user name and canonical name you noted earlier (when you looked at your Sendmail version) simply send to that e-mail address. For example, if you created a user named 'gates' during the Debian installation and the canonical name displayed above was 'debian.your-last-name.net' then send an e-mail to:
Also try sending a second e-mail to the same address but with omitting the host name ('debian' in our exmaple).
If you don't have a real domain name you can, while logged into your Debian system as the root user, use the procedure above to send a local e-mail to the same user as above. However, in this case just enter the user name in the "To:" field, not the "@" symbol or anything after it.
After a minute or so log into your Debian system with the user account you sent the e-mail to and it should tell you that you have new mail. Type in mail on the command-line by itself (i.e. no e-mail address after it). It will list the e-mail messages in your mailbox followed by a "&" prompt. You can type the message number to display the contents of the e-mail or you can just type a q at the prompt to quit the program.
If you don't have any mail take a look at the Troubleshooting section below.
Don't forget to lot out of the user account and log back in as root otherwise you won't be able to install any more packages.
The POP Server
Now we have to set up the POP server. There's a basic GNU POP server included in the Debian packages called mailutils-pop3d. (There's also a mailutils IMAP package if you prefer to go that route.) To install the POP3 package type in:
apt-get install mailutils-pop3d
You weren't ask to configure anything but if you type in:
netstat -an | more
You'll see that TCP port 110 is now open. If you want to test it, just get on a different system on your local network, fire up the e-mail client, and change the POP server settings to point to the IP address of your Debian box. You'll need to change the user name and password in the client to match the user account you created during the Debian OS install. A POP server will automatically see any user on the Debian system as an e-mail user and it will use the Debian user name and password.
In the next section we'll show you how to telnet into your Debian system pretending to be a POP client so you can test out software installation.
Because of Sendmail's complexity there are a myriad of error messages you could see in mail that gets returned to you. The Sendmail Web site has extensive FAQs which list most of these errors and what to do about them.
If you run into a situation where your network clients are having problems sending e-mail you can pretend to be an e-mail client sending an e-mail by using telnet to issue SMTP commands to the server. You can use any computer on the same local network to run telnet and connect to port 25 (that's the port SMTP listens on) on the server to issue the commands.
Assuming your Debian system's IP address is 192.168.1.12 the following command will connect you to the SMTP service. On a Windows system, click on the Start button and select Run and enter the command in the input field.
telnet 192.168.1.12 25
If you don't have another system to try this from you can get on the Debian system and enter the above command using localhost in place of the IP address. However, running telnet on the local server system won't tell you if you have a network connection problem with the e-mail server.
In the following example, the lines in bold are the commands you enter to pretend you're a mail client sending an e-mail message through the server. The lines in italics are the responses you should see from your server.
The your-id is the username of the user account your created during the Debian installation.
(telnet connection established) 220 debian.your-last-name.net ESMTP Sendmail 8.14.4/8.14.4/Debian-8; Mon, 31 Jun 2016 20:34:10 -0600 (No UCE/UBE) logging access from: helo your-last-name.net 250 debian.your-last-name.net Hello solarisi [192.168.10.30], pleased to meet you mail from: email@example.com 250 2.1.0 firstname.lastname@example.org... Sender OK rcpt to: email@example.com 250 2.1.5 firstname.lastname@example.org... Recipient OK data 354 Enter mail, end with "." on a line by itself This is a test mail message sent to root . 250 2.0.0 Message accepted for delivery quit 221 2.0.0 email@example.com closing connection
In the above example we were sending mail from a non-root user to the root user in the same domain (but using different systems). If you tried to use a
rcpt to:address that was not in the same domain you'd likely get a relaying denied error.
The most common SMTP return codes are as follows:
220 - Service ready
221 - Service closing transmission channel
250 - Requested mail action okay, completed
354 - Start mail input; end with <CRLF>.<CRLF>
421 - Service not available, closing transmission channel
450 - Requested mail action not taken: mailbox unavailable
500 - Command unrecognized (mis-spelled command or wrong syntax)
501 - Syntax error in parameters or arguments
502 - Command not implemented (valid SMTP command but not available)
550 - Requested action not taken: mailbox unavailable
551 - User not local; please try <forward-path>
554 - Transaction failed
Now you can log in as root on your Debian system and see if you have new mail waiting. If you're already logged in as root just type in mail at the shell prompt.
You can also use telnet to pretend to be a POP client as well. This time you connect to port 110 which is the port POP listens on. Again, using 192.168.1.10 as an example address for the server, enter the following command:
telnet 192.168.1.10 110
As above, you can also use the following command on the local system:
telnet localhost 110
In the following example, the lines in bold are the commands you enter to pretend you're a mail client checking for e-mail messages. The lines in italics are the responses you should see from your server. After you connect via telnet the server will respond and wait for your commands.
Note that you CANNOT try this using the root mail account because the password is sent in clear text. Use the name of the user account you created during the Debian installation.
(telnet connection established) +OK POP3 Ready <debian.your-last-name.net> user keith +OK pass penguin +OK opened mailbox for keth list +OK 1 2050 2 4213 3 928 . retr 1 +OK (header and message text gets typed to the screen) . dele 1 +OK Message 1 marked quit +OK
The dele dialog in blue is optional. You don't need to enter the dele command if you want to keep the message in your mailbox file on the server. It normally is used because POP clients transfer the mail from the mailbox on the server to an "inbox" on the client's hard-drive. In most POP client software (Thunderbird, Outlook, etc.) you'll see an option to "leave messages on server". If this option is selected, the dele command isn't executed.
Internet SuperServer and TCP Wrappers
If you issue the command:
ps -aux | more
to list all of the processes running on your system you'll see Sendmail and Apache listed but you won't see anything about POP or telnet even though we installed these programs. Yet, if you issue the netstat command earlier you would have seen that ports 110 and 23 are open. So how can the ports be open if the programs that monitor them aren't running? They are run using a thing called the "Internet superserver" that allows us to free up memory run these programs with more security.
inetd is the Internet superserver daemon that idles in the background listening to the ports that certain Internet-based service requests come in on. When it detects a request on a specific port, it calls the appropriate process (server software program) to handle the request.
If any Internet-based programs are set to run using the Internet superserver you'll see the
process running when you issued the ps command above.
The benefit of inetd is it allows you to offer the services of many different programs without having them all running 24/7 as daemons. (It was developed to reduce memory usage back when RAM memory was expensive.) Services that you may only use occasionally like telnet are good candidates for use with the Internet superserver.
You control which ports inetd listens on by editing the /etc/inetd.conf file. A typical line in this file could look like this:
telnet stream tcp nowait root /usr/sbin/telnetd
A line like this was added to the file when you installed the telnet package above. It is simply telling the inetd daemon to run the /usr/sbin/telnetd program when a request comes in on the telnet port (port 23). Note that I said the line could look like this. It likely doesn't. It probably looks more like this:
telnet stream tcp nowait root /usr/sbin/tcpd /usr/sbin/telnetd
Note the additional part in blue. This tells the inetd daemon to run the tcpd program when a request comes in on the telnet port. The /usr/sbin/telnetd path to the telnet daemon is used as a command line parameter to the tcpd program. The tcpd program is run first and it "calls" the telnetd program.
What is tcpd? It's called a TCP "wrapper" because it runs the actual program within itself. It wraps itself around the execution of the actual program so it can watch the traffic that goes in and out of the program. It's a security tool.
When you use the tcpd wrapper program you can control it using the /etc/hosts.allow and /etc/hosts.deny files. Just as the file names imply, the TCP wrapper allows you to control who can access these services.
For example, you can allow only a specific computer to telnet into your server by specifying that computer's IP address in the /etc/hosts.allow file. If you enter only the first two or three octets of an IP address, only the machines that have addresses that start with those octets will have access.
The format of the statements in the two hosts files, and how the two files interact, are beyond the scope of this page. We just wanted to make you aware of what TCP wrappers are because you'll often see it mentioned in Web documents. It's a very useful and valuable security tool and it would be well worth your time to learn how to use it.
For example, you could set up a server at work to only allow telnet from systems on your home ISP's subnet so you can get at it from home. Yes, others on your ISP's subnet would also be able to telnet in if they were able to crack a username and password, but this is a lot more restrictive than the entire Internet. The reason you'd have to use your ISP's subnet is because your home computer is assigned a dynamic (changing) address each time you connect to your ISP so you wouldn't be able to use a specific IP address in the /etc/hosts.allow file.
In addition to controlling access through the use of the two hosts files, TCP wrappers also help to prevent spoofing attacks. Setting your system up to use SSH (Secure SHell) access instead of telnet is also another good security measure as login information (username and password) are sent as clear text when using telnet. The unsername and password are encrypted with SSH.
There are other ways to help secure a server also. We give you more security options specifically for Apache on our Security page.
Do NOT plan to use the system you will create using these guide pages as a "production" (real) server. It will NOT be secure!
There are many steps involved in creating a secure Internet or LAN server. While we do refer to some things you can do to make your system more secure, there are many other measures related to system security that also need to be taken into consideration and they are not covered on these pages.
These guide pages are meant as a learning tool only. The knowledge gained on these pages will help you understand the material covered in security-related publications when you are ready to consider setting up a production server.
Did you find this page helpful ?
If so, please help keep this site operating
by using our DVD or book pages.
Site, content, documents, original images Copyright © 2003-2016 Keith Parkansky All rights reserved
Duplication of any portion of this site or the material contained herein without
the express written consent of Keith Parkansky, USA is strictly prohibited.
This site is in no way affiliated with the Debian Project, the debian.org Web site, or
Software In The Public Interest, Inc. No endorsement of this site by the Debian Project
or Software In the Public Interest is expressed or implied. Debian and the Debian logo
are registered trademarks of Software In The Public Interest, Inc. Linux is a registered
trademark of Linus Torvalds. The Tux penguin graphic is the creation of Larry Ewing.
IN NO EVENT WILL KEITH PARKANSKY OR BLUEHOST INCORPORATED OR ANY OF ITS' SUBSIDIARIES BE LIABLE TO ANY PARTY (i) FOR ANY DIRECT, INDIRECT, SPECIAL, PUNITIVE OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, DAMAGES FOR LOSS OF BUSINESS PROFITS, BUSINESS INTERRUPTION, LOSS OF PROGRAMS OR INFORMATION, AND THE LIKE), OR ANY OTHER DAMAGES ARISING IN ANY WAY OUT OF THE AVAILABILITY, USE, RELIANCE ON, OR INABILITY TO USE THE INFORMATION, METHODS, HTML OR COMPUTER CODE, OR "KNOWLEDGE" PROVIDED ON OR THROUGH THIS WEBSITE, COMMONLY REFERRED TO AS THE "ABOUT DEBIAN" WEBSITE, OR ANY OF ITS' ASSOCIATED DOCUMENTS, DIAGRAMS, IMAGES, REPRODUCTIONS, COMPUTER EXECUTED CODE, OR ELECTRONICALLY STORED OR TRANSMITTED FILES OR GENERATED COMMUNICATIONS OR DATA EVEN IF KEITH PARKANSKY OR BLUEHOST INCORPORATED OR ANY OF ITS' SUBSIDIARIES SHALL HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES, AND REGARDLESS OF THE FORM OF ACTION, WHETHER IN CONTRACT, TORT, OR OTHERWISE; OR (ii) FOR ANY CLAIM ATTRIBUTABLE TO ERRORS, OMISSIONS, OR OTHER INACCURACIES IN, OR DESTRUCTIVE PROPERTIES OF ANY INFORMATION, METHODS, HTML OR COMPUTER CODE, OR "KNOWLEDGE" PROVIDED ON OR THROUGH THIS WEBSITE, COMMONLY REFERRED TO AS THE "ABOUT DEBIAN" WEBSITE, OR ANY OF ITS' ASSOCIATED DOCUMENTS, DIAGRAMS, IMAGES, REPRODUCTIONS, COMPUTER EXECUTED CODE, OR ELECTRONICALLY STORED, TRANSMITTED, OR GENERATED FILES, COMMUNICATIONS, OR DATA. ALL INFORMATION, METHODS, HTML OR COMPUTER CODE IS PROVIDED STRICTLY "AS IS" WITH NO GUARANTY OF ACCURACY AND/OR COMPLETENESS. USE OF THIS SITE CONSTITUTES ACCEPTANCE OF ALL STATED TERMS AND CONDITIONS.