Typo3 Winstaller is a free WAMP (which means Windows, Apache, MySQL and PHP) webserver that comes preinstalled with the Typo3 content manangement system. It basically offers everything needed to get started eliminating the need to install and configure the dependencies individually.

The installer sets up a full Typo3 environment on the system that can be used immediately without configuration. This can be helpful for developers, students, employees and everyone else who wants or needs to work with Typo3.

The main features of Typo3 Winstaller

• Download and Play – no configuration and no other manually intervention is required
• simple user interface
• includes preconfigured Quickstart, Testsite and Dummy packages of TYPO3 (demo pages)
• easy to try the full functionality of the CMS TYPO3
• TYPO3Winstaller runs from portable hardware (i.e. MemorySticks) and from CD/DVD

The package is offered as a zip file and executable. The executable handles the unpacking for the user, the remaining process remains the same.

The application offers a basic control panel that displays information about running services (Apache, MySQL), options, logs and the ability to start and stop the Typo3 content management system.

Typo3 runs on the local system. The control panel launches the web interface in the default browser after installation or manual activation. This is at the same time the final test that everything is up and running.

The welcome page links to several Typo3 related resources which is handy for beginners who want to learn Typo3.

Interested users can download Typo3 Winstaller from its project page over at Sourceforge.

But setting up a secure web server isn’t complete without the inclusion of SSL and certificates. If you are wanting to serve up sercure web pages you will certainly want your audience to be able to send them to https instead of http. So…with CentOS how do you do that? I will show you how.

Installing all of the packages

I will assume you already have CentOS installed as well as the Apache Web Server. Make sure you are able to go to the default Apache web page (or any web page on your CentOS web server), before you set up SSL. When you have all of that working you will need to install a couple of packages. This is done with the following steps:

1. Open up a terminal window.
2. Su to the root user.
3. Issue the command yum install mod_ssl openssl.
4. Let the installation complete.

With SSL installed and ready, it’s time to create your certificates for usage.

Creating your certificate

You will now have everything on your server to create CAs. You need to generate a private key, a csr, a self-signed key, and then you need to copy these files to the correct location. This is done with the following steps.

1. Open up a terminal window.
2. Su to the root user.
3. Generate the private key with the command openssl genrsa -out ca.key 1024.
4. Generate the csr with the command openssl req -new -key ca.key -out ca.csr.
5. Generate the self-signed key with the command openssl x509 -req -days 365 -in ca.csr -signkey ca.key -out ca.crt.
6. Move the self-signed key with the command cp ca.crt /etc/pki/tls/certs.
7. Move the private key with the command cp ca.key /etc/pki/tls/private/ca.key.
8. Move the csr with the command cp ca.csr /etc/pki/tls/private/ca.csr.

Edit the Apache SSL configuration

Open the file /etc/httpd/conf.d/ssl.conf and look for the section SSLCertificateFile. Make sure that line reads:

SSLCertificateFile /etc/pki/tls/certs/ca.crt

Now look for the SSLCertificateKeyFile and make sure that section reads:

SSLCertificateKeyFile /etc/pki/tls/private/ca.key

Save that file and you are ready to restart Apache.

Restart and test

Before you try to test Apache’s new SSL feature, you must restart the daemon. To do this issue the command /etc/rc.d/init.d/httpd restart. Hopefully you will see no warnings or errors. If not, then point your browser to https://ADDRESS_TO_SERVER Where ADDRESS_TO_SERVER is either the IP Address or the domain. You should then see a warning from your browser about the certificate for the site. If you see this warning congratulations, your Apache server is now ready for secure connections.

Remember, though, you created a self-signed certificate. To get the most out of SSL you might want to purchase a CA from a trusted name like Verisign (There are, of course, plenty of other places where you can purchase those certifiacates).

Naturally, what is nice about phpldapadmin is that it allows you to manage your LDAP server from anywhere you have access to a browser (so long as your LDAP server can be reached form anywhere. In this article I am going to show you how to install, configure, and begin to use the phpldapadmin tool.

Installation

Before you install phpLDAPAdmin (also known as PLA), you will need to have your LDAP server up and running. Once that is achieved you can then proceed with your installation of this management tool. You will also need to have a web server installed and running (it is a web-based tool after all).  If you do not already have php5-ldap installed, install that package now.

The first step for installation is to download the source from Sourceforge. You can install from a pre-compiled binary, but I recommend you do the installation from source.

Once you have the .tgz file downloaded move that file to your web servers’ document root. In Fedora this will be /var/www/html and in Ubuntu this will be /var/www. The next step is to unpack the tar file and then rename the newly created directory. You will need administrative privileges for these tasks. Follow these steps:

1. Open up a terminal window.
2. Change to your document root.
3. Su to root (if using Fedora or a Fedora-like distribution).
4. Issue the command tar xvfz phpldapadmin-XXX.tgz (If using a Ubuntu-like distribution you will have to add sudo to the beginning of that command) Where XXX is the release number.
5. Rename the directory with the command mv phpldapadmin-XXX phpldapadmin (If using Ubuntu-like distribution you will have to add sudo to the beginning of that command) Where XXX is the release number.
6. Change into the phpldapadmin/config and rename the config file with the command mv config.php.sample config.php (If using Ubuntu-like distribution you will have to add sudo to the beginning of that command).

Now it’s time to fire up your web browser and head to your installation. Point your browser to http://ADDRESS_TO_SERVER/phpldapadmin/ and you will see a page similar to that in Figure 1.

The first thing you need to do is click on the Login link (in the left navigation tree). The credentials you need will be those that were created to administer your LDAP server. But don’t think you can just log in with a username of “admin” and a password. You have to use the standard format of LDAP. So a typical administrator login username will look like cn=admin,dc=wallen,dc=local.

Once you have logged in, the main page will look like that shown in Figure 2. Expand the navigation tree on the left nav and you can see where you can start creating new entries.

Final thoughts

You are now ready to rock your LDAP server from anywhere you can access a web browser. The phpLDAPAdmin tool makes LDAP as easy as phpMyAdmin makes MySQL. This is one of the best LDAP admin tools you will find.

Here is how it works. Weezo will run a configuration script on the first startup. The script will start the core services and perform connection checks to ensure that the server is accessible from a local network and the Internet.

weezo

A free Weezo account can be created during setup of the server. The account offers the advantage that a permanent url is associated with it which can be used to access the server. This is similar to a service that offers a permanent domain name for dynamic IPs. It is possible to use the program anonymously, but this means that users connected to the computer need the right IP address to do so.

The Weezo server interface is then started on the computer, providing the means to configure the the shared contents and users as well as core configuration options and an activity monitor that displays information about logged in users and server status changes.

All resorts around user groups and resources. Groups are used to allow or block access to resources. The administrator for instance has access to all resources by default while the public group does not.

Groups are protected with passwords and can be further protected by adding allowed IPs. Options to provide a distinct website theme, sounds and sticky notes are provided as well.

Resources are the core of the server. Here it is possible to enable file access and sharing, blog and websites, communication modules like chat or webcam, bookmarks, web TV, a web proxy routing traffic through the Weezo website and additional modules.

Some interesting resources are the following:

• Photos Album: Share photos with anyone connecting to the server.
• Music and Videos: Listen to music or watch videos remotely, great for sharing music and videos with friends.
• RSS Reader, bookmarks: Access and share RSS feeds and bookmarks easily wherever you are

music player

One click install / download options are provided for popular web scripts such as WordPress, Joomla or phpBB even though they are not always offered in the latest version. MySQL can be installed as well as it is a requirement for several of the scripts.

remote access server

Some modules were not completely translated into English, only offered in French. WordPress for instance was available in French. It was however no problem to change the configuration files on the local system to change the language to English. This is also the way to update scripts to their latest versions.

Admins have direct access to MySQL, phpMyAdmin, the Apache configuration and pretty much every other server configuration file. Helpful for instance to import a database or make modifications to the remote server.

Ports can be changed in the configuration, the default port is 80. It is furthermore possible to use a secure connection (SSL) to connect to the server.

Screenshots:

remote access server

remote desktop

remote file explorer

rss feed sharing

server login

Weezo offers a one-click installation server for web scripts, file sharing and remote file access. It provides rights management and an easy to understand admin interface that can be used to configure most, but not all, of the options of the server.

Some operations require manual configuration changes, which definitely will be a problem for inexperienced users. There is for instance no option to update WordPress to the latest version from within the admin interface.

Weezo is available for download at the developer’s website.

Recently I revisited the installation of eGroupware and thought I should give a bit more detail on the procedure of installing this rather challenging tool. So in this article I will walk you through the steps on installing eGroupware.

Download and unpack and prerequisites

I will assume you have a working Apache and MySQL installation, on your Linux server,  ready to go. If not, go ahead and take care of that major prerequisite first. Once you have completed that task you are ready to being. Almost. There are still a few other prerequisites to get out of the way. You will want to fire up Synaptic (or whatever package manager you use) and make sure you have the following installed:

• PHP
• php-pear
• An SMTP server (Postfix is a good choice)
• IMAP server (Dovecot is a good choice)

There will also be a LOT of pear extensions to install – we will deal with those in a moment. Before going any further create the database you intend on using (let’s stick with the name egroupware). If you’re not sure how to create the database give my article “Complete database administration with MySQL Workbench” a read.

Now it’s time. move the the downloaded tar file for eGroupware into the /var/www/ directory and then unpack it with the commands:

bunzip2 eGroupware-XXX.tar.bz2

Where XXX is the release number.

tar xvzf eGroupware-XXX.tar

Where XXX is the release number.

You will now have a newly created directory /var/www/egroupware. Point your browser to http://ADDRESS_TO_SERVER/egroupware and you will begin the installation process. This is where it gets fun. On the first page you will have a link that allows you to run the installation tests. Click that and you will be presented with a long list of items. Each of these items will be preceded by either a green check, a yellow lightning bolt, or a red X. Anything marked with a red X MUST be resolved. Yellow lightning bolts are only warnings. Some of these you can ignore (for instance features you know you won’t use). The green checks – those are all right.

Most likely you will need to deal with some php issues and some Pear modules. Let’s examine each.

PHP

In the directory /etc/php5/apache2/ is the main php configuration file (php.ini). You will need to make some modifications to this file in order for the installation to work. Typically the modifications you will need to deal with are:

upload_max_filesize >= 8M By default PHP has a 2MB upload limit. You will need to change that.

mbstring.func_overload = 7 By default this is set to 0. You will need to change this.

Pear

Now you will enjoy quite a few pear module installations. This is hit or miss on how many your system will have installed by default. What you need is the following:

• HTTP_WebDAV_Server
• Net_Socket
• Auth_SASL
• Net_IMAP
• Net_Sieve
• XML_Feed_Parser
• Log

Some of these modules can be found in Synaptic. The best way to locate them is do a search for “pear” (No quotes) and then mark the necessary modules for installation (and then, of course, install them). Those that you do not find you will have to install from the command line, like so:

sudo pear install MODULE_NAME

Typically these install very quickly.

You should now be at the point where all of the X’s are gone and all of the necessary warnings have been replaced with green checks as well. The next step is to click Continue with the Header Admin. That we will deal with in our next article.

Final thoughts

It may seem like eGroupware is a pain to install. It’s not really as bad as some I have tried to work with. But it is, most certainly, worth the effort.

In this article we will take a look at the necessary configurations to get osTicket up to speed for your help desk needs. You should find, upon completion of these configurations, osTicket is quite the useful help desk tool.

Assumptions

This article will assume your support staff is not terribly large and that you already have the necessary tools setup to take advantage of osTicket’s features. Such tools include an SMTP server for the outgoing alerts responses and a POP or IMAP server for incoming mail. And, of course, this will assume you have osTicket up and running. Finally, I will assume you took care of the initial configurations upon installation. These configurations are handled in the Settings tab and should be completed when you bring the site online after installation. NOTE: If, after you fill out the web-based installer, you get a blank screen – most likely you do not have php5-mysql installed. Install that and re-run the web install and you should be fine.

First things first

Figure 1

The first thing you will want to do is set up your departments. By default osTicket has two departments: Billing and Support. You may find this plenty. But for some consulting firms there may be more necessary. For example, you might need Residential Support and Commercial Support. Or you might want Remote and On Site. To set these up click on the Departments tab and then click the Add New Dept link.

If this department wants to have its very own email address, you will need to first create an email address for it. That includes both on your email server and in the Emails tab in osTicket (this is why it’s important to understand the flow of configuration for osTicket).  If the department just needs to use the same email addy as another, umbrella, department you can select it here. This is, after all, just the outgoing email address (which will probably want to be something like support@yourdomain.com.)

Figure 2

Once you have finished creating all the necessary departments you will want to the Staff tab and create the necessary elements here. In the Staff tab (see Figure 2)  you can set up both groups and staff members. Again, this will depend upon your needs. You might, for example, have certain staff that only do one particular type of work (say Residential vs. Commercial). Before you create those staff members, make sure you create any (if needed) groups they would belong to.

You will also notice there are groups. By default there are three groups: Admins, Managers, and Staff. These groups determine the permissions a staff member has. Use caution when you give a staff member Admin rights. You can, of course, add a new group and give that group specific permissions. Take a look at each group to see what their permissions are before you do this.

Finally you will want to take a look at the Help Topics tab. This is a very nice feature added to osTicket. What you can do with Help Topics is create a particular topic that has a specific Priority. Say you have a few clients that always get top priority. You can create a VIP (or such) category that has Emergency priority. This will always bump them to the top of the list. Is it fair? Not really. But when you have VIP-type clients, they expect VIP-type treatment.

Final thoughts

I hope that, upon setting up osTicket, you come to the same conclusion that I have drawn – this tool is the equal to some Help Desk tools costing quite a bit of your IT dollars. If you find a tip or trick that takes osTicket to the next level, share it with your fellow Ghacks readers.

But during this process I thought I would share with you some of the tools I have tried. This one in particular is an open source trouble ticket tool called osTicket. osTicket has a fair amount of features – especially for a free system. It’s not ideal, but it’s far from the bottom of the barrel. The installation is fairly simple and straight-forward. And, it requires a database, so you know your tickets will scale better than your average ticket system using a flat file.

In this article I will show you how to get osTicket up and running.

Requirements

osTickets has few requirements:

• PHP >= 4.3
• MySQL >= 4.1
• php5-mysql

That’s it. Of course you will have to be able to create a database for the tool. I prefer to use MySQL Workbench (read my article “Complete database administration with MySQL Workbench” for more information.)

Once you have all the requirements met, it’s time to download the file and start the installation. The beginning steps are:

1. Move the osticket-XXX.tar.gz (Where XXX is the release number.)
2. Create a directory for osTicket to live (let’s call it /var/www/support) with the command sudo mkdir /var/www/support.
3. Unpack the osticket package with the command sudo tar xvzf osticket-XXX.tar.gz.
4. Move the necessary files from the newly created /var/www/osticket-XXX/uploads into /var/www/support with the command mv /var/www/osticket-XXX/uploads/* /var/www/support.
5. Change the name of the ost-config.sample.php file with the command mv /var/www/support/include/ost-config.sample.php /var/www/support/include/ost-config.php.
6. Give the ost-config.php file write permissions with the command chmod 777 /var/www/support/include/ost-config.php.
7. Finally, point your browser to http://ADDRESS_TO_SERVER/support/setup to start the installation process.

Figure 1

When you start up the web interface you will find a few simple configuration options. Fill those out and click the Install button. After this runs you will be instructed to remove write access to the ost-config.php file. Do this with the command sudo chmod ugo-w /var/www/support/include/ost-config.php. Now you can log into the admin panel with the username/password combination you created in the web setup.

Figure 2

By default the system is set to off-line mode. This means the interface is only accessible to admins. You will see, at the top of the interface, a small link that allows you to Enable the interface for clients (see Figure 2). When you click that link you will open up the settings panel and, at the top of that page, you can mark your osTicket installation to be online. From this same page you can also configure the rest of your osTicket installation.

Final thoughts

Although osTicket doesn’t have every feature needed for a consulting firm, it does offer more features than most of the free offerings. If you’re looking for a help desk system, and your budget practically demands open source, you would be remiss to neglect osTicket.

http://192.168.1.100/rewrite.php?link=1

Your users would only have to type:

http://192.168.1.100/link2.html

Of course the rewrite engine serves as much more than just a means for your users to more easily remember addresses. Many server softwares (such as the social networking server Elgg) depending upon the rewrite engine in order to function. Because of this, the rewrite engine is almost a necessity to have working. By default Apache does not have the rewrite engine on, so you have to configure it to work. The goal of this tutorial is to show you how to enable the rewrite engine in a Ubuntu server installation. This article will assume you already have your Ubuntu server as well as Apache up and running.

What this involves

In order to get the rewrite engine working for your web site you will have to take care of the following steps:

1. Instruct Apache to load the mod_rewrite module.
2. Edit the document root entry so that the rewrite engine is allowed.
3. Create an .htaccess file to rewrite urls for you.

Creating a simple test

Before we get to the actual configuration, the first thing to do is to set up a little rewrite test. Open up a terminal window (or log into your GUI-less server) and change to the /var/www directory. In that directory create a file, named rewrite.php, with the following contents. NOTE: Code is located on pastebin.com for ease of use.

Copy and paste the contents of that file into your rewrite.php file. If you visit that page, in a browser, without the rewrite engine working, you will quickly see that it will not work. So, let’s get rewrite working.

Now you will have to create an .htaccess file in the /var/www/ directory with the following contents:

RewriteEngine On
RewriteRule ^link([^/]*).html$ rewrite.php?link=$1 [L]

Enabling the module

In order to enable the mod_rewrite module in the Ubuntu server issue the following command:

sudo a2enmod rewrite

The above Apache2 Enable Module command will add the correct line in the /etc/apache2/apache2.conf file. That is the only change you need to make with the apache2.conf file. Now it’s time to make a change to the document root.

In older versions of Apache all virtual host directory directives were managed in the /etc/apache2/apache2.conf file. This has changed. Now these alterations are handled within the /etc/apache2/sites-enabled/ directory. Within that directory you will find, by default, a single file called 000-default. If you open that file up for editing you will see, at the top, the two sections you need to edit in order to enable the rewrite engine for the document root of your Apache server.

First look in the <Directory /> section and change the line:

AllowOverride None

to

AllowOverride All

Do the same for the <Directory /var/www/> section.

Once you have the file edited, restart Apache with the command:

sudo /etc/init.d/apache2 restart

Now revisit the rewrite.php page in your browser and you should see that rewriting is now working. Congratulations, you have just taken on step forward in opening up an entire world for your Apache needs.

Final thoughts

The rewrite engine is used by so many web-based tools. Upon installation of Apache, this should be one of the first tasks you tackle.

There are a hundred and one thousand things that can go wrong with any web server installation. From a fresh installation to an installation that has been running for a long time, you never know when something is going to cause your web server to go astray. When it does happen, it’s always nice to know that, usually, Occam’s Razor applies.

In this tutorial you will find some advice that will help you through some of the more common issues that can pop up with an Apache web server.

Is your server actually running?

Believe it or not, this has happened to plenty of administrators. You take the server down, do some maintenance, and when you go to check out the server you’re getting errors. The first thing you do, naturally, is check out that /etc/apache2/apache.conf file to make sure your syntax is correct. But it’s perfect! What’s up? The first thing you might want to check is to make sure the server is running. But you don’t want to just issue the command to start the server or reload the server. Instead, issue the command:

sudo /etc/init.d/apache2 status

Which should return something like:

* apache is running (pid 9751).

If not, start the server with either:

sudo /etc/init.d/apache2 start

or

sudo apache2ctl start

NOTE: If you are using a distribution like Fedora, SuSE, or Mandriva you will need to first su to the root user and issue the above commands WITHOUT using sudo.

It’s not running and it won’t start

Did you just make changes to your Apache configuration file? Are the changes correct? If you’re not sure, you can use the apache2ctl command to check the syntax of your configuration file. This is done with the command:

sudo apache2ctl configtext

The above command should report:

Syntax OK

If you don’t get an OK, you will get information that points to the errors in your configuration file.

Apache wants to download .php files!

This is another common issue. When you add a new tool on your web server (such as Drupal), if your configuration file is set up properly, any .php file might not be displayed. Instead any attempt to view a .php file will instead have your browser trying to download the file. Why is this? Apache must be informed that certain extensions are to be displayed, not downloaded. This is done from within the Apache configuration file. Open up that file (in the Ubuntu server it will be /etc/apache2/apache2.conf) and first look for the following line:

DirectoryIndex index.html

If that file doesn’t include index.php nearly all sites that use php will be rendered useless.

The second line to look for is:

AddHandler application/x-httpd-php .php

If you find this line, and it is commented out, make sure you uncomment it by removing the “#” character. If it is not there add it to the bottom of the configuration file.

And, as always, when you make a change to the configuration file, restart Apache.

Know where to look for problems

Finally, it is crucial that you know where to first turn when the above doesn’t help you out. Any time I have an issue with Apache where Occam’s Razor does not apply, the first place I turn is the log files.

If you look in /var/log/apache2 you will find, at least, the following files:

• access.log: This keeps track of any connection made to your server.
• error.log: This keeps track of any errors that occur with Apache.
• other_vhosts_access.log: This is where virtual hosts will log when the virtual host has not been prescribed its own log file.

Of course, as your site evolves so will your available log files. Regardless of what you find in /var/log/apache2, that is where you should always first turn when you have problems. Even before you google.

Final thoughts

Now you should be able to handle some of the more common issues with the Apache server. And if your problem isn’t common, you also know where to turn to find clues that will lead you down the right path to correction.

Wampserver is an Apache web server for the Windows operating system. It provides in many regards the same functionality of other web server solutions like XAMPP or Home Web Server which we have reviewed in the past. The latest version of the local web server package will install Apache 2.2.11, MySQL 5.1.36 and PHP 5.3.0 on the local computer system.

One interesting unique feature is the ability to add different versions of Apache, MySQL and PHP to the installation in the form of add-ons. This can be very handy to test a website locally under multiple different Apache, MySQL or PHP release versions.

The installation of Wampserver will always install the latest versions of Apache, MySQL and PHP. One interesting security feature is the ability to limit access to the web server to localhost. It is required to click on the “put online” option to make it available to other computer systems as well.

Additional Apache, MySQL and PHP versions can be installed from the Wamp add-ons page. All add-ons are provided as executables that can be installed easily on the operating system.

Webmasters who need to test code offline can use Wampserver to do so. It is especially useful to test code against multiple versions of Apache, MySQL and PHP. Something that the other home server solutions do not provide.

Wampserver is Open Source and can be downloaded from the developer’s website.

• Linux
• Apache
• MySQL
• P (can mean PHP or PERL – depends upon your needs)

LAMP servers are very popular, cheap, effective, flexible, and reliable servers. But how are they installed? Actually, it’s not that hard. In this tutorial I am going to show you how to install a LAMP in two different ways: From the command line (using separate tools) and using the tasksel tool.

Hardware needed

Fortunately a LAMP server can be installed on lower-end hardware and still serve as a fairly efficient server. Naturally if you are going to be using your LAMP server for high traffic, you will want to select your hardware wisely.

Install prerequisite

Before you begin the installation of your server you will need to have your operating system installed. This is the “L” of LAMP. So find your favorite Linux distribution and install the operating system. For the purposes of this installation I am going to be installing on a Ubuntu 9.04 server installation. This will be a console only server (no GUI desktop) which is fine because the installation is done via command line only.

Once you have your operating system installed you are ready to install your server.

Apache

This is the easiest portion to install. Either log in to your console or open up a terminal window (if you are working from a GUI desktop) and enter the following command:
sudo apt-get install apache2

You will have to enter your sudo user password for this installation to continue. Once this installation is complete check it by pointing a browser to that server IP address. You should instantly know if Apache is up and running.

PHP

For the purposes of this article we will assume the “P” stands for PHP. To install PHP (and all of its requirements) issue the command:

sudo apt-get install php5 libapache2-mod-php5

Once this installation is complete restart Apache with the command:

sudo /etc/init.d/apache2 restart

Let’s make sure this portion works properly. To test this create a file in the Apache document root (for this install it will be /var/www) called test.php. The contents of this file will be:
< ?php phpinfo(); ?>

Save that file and then point your browser to http://IP_ADDRESS/test.php

Where IP_ADDRESS is the actual IP address of your server.

You should see “Test PHP Page” written on your browsers page. If so, you’re good to go.

MySQL

Now to install MySQL. To do this issue the command:

sudo apt-get install mysql-server

Once this is done you then need to set a password for MySQL. To do this issue the command:

mysql -u root

which will put you in the MySQL prompt. From this prompt (which looks like mysql> ) enter the command:
SET PASSWORD FOR 'root'@'localhost' = PASSWORD('YOURPASSWORD');

Where YOURPASSWORD is the password you want to use for the mysql user.

Now start your MySQL server with the command:

/etc/init.d/mysql start

That’s it. Your LAMP server is up and running.

The quick version

You can actually install a full-on LAMP server on a (Ubuntu server install) with a single command:

sudo tasksel

You will need to select LAMP from the list and you will eventually be prompted for a MySQL password. That’s it.

Final thoughts

Getting a powerful, flexible web server up and running will take you less time and effort than you think. LAMP servers are an outstanding choice for your web servers’ needs.

What is mod_security?

The mod_security addition to Apache is a modular way to add or remove various security features to your Apache server. You can add or remove these modules by simply adding or removing (or commenting out) lines to your httpd.conf file and restarting the httpd daemon. And installing mod_rewrite is as easy as it is to install.

Getting and installing

I am going to take you through the installation of mod_security on a CentOS distribution. There will be a combination of using yum and installing from source. I will assume Apache is already installed.

There are a few ways to install this package. You can install from source, but that will require you install numerous dependencies just for the compilation alone. Since we’re looking at CentOS (and this will apply to Red Hat and Fedora as well) you can use Yum for easy installation. But if you fire Yum up you will find that mod_security is not in the standard repositories. Fortunately there is an easy way to add a repo for this installation. The command to add the repostority is:
su -c 'rpm -Uvh http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-3.noarch.rpm'

You will have to answer ‘Y’ to a couple of questions to finish the installation. Once you have added the repository issue the command:

yum install mod_security

to install the system. You will have to accept any dependencies needed for your system to complete the installation. Once mod_security is installed you are ready to get it up and running on your Apache server.

Basic configuration

Issue the command:

grep -n security2_module httpd.conf

from within the /etc/httpd/conf/ directory. If you do not see any output that means you have to add the directive to your httpd.conf file. This is simple. At the end of your module loading section add the following line:

LoadModule security2_module modules/mod_security2.so

Now save the file and restart Apache with the command:

/etc/rc.d/init.d/httpd restart

You should not receive any errors at this point.

The most difficult aspect of using mod_security is the the IfModule section in the httpd.conf file. The reason this section is so complex is because there are so many possible options. The best chance you have of getting familar with this is by taking a glance at the Configuration Directives page on the mod_security web site. To give you an example of a configuration directive section take a look at the following sample in Figure 1.

Figure 1

As you can see this section seems fairly complex. But this is mostly a basic sample of what mod_security can do. In this sample we do the following:

• SecFilterEngine On: Start the engine
• SecFilterDefaultAction: Set the default action for the module. Notice in the sample code i have the default action set to “allow”. For higher security you will want to set this to “deny”.
• SecFilterScanPOST: Tell mod_security to scan Payloads as well as Get requests.
• SecFilterCheckURLEncoding: Check for valid hex values in requests.
• SecFilterCheckUnicoding: Set this to off if your web site does not use unicoding.
• SecFilterForceByteRange: Set allowable ascii values in GET request and in FORM data posts.
• SecUploadDir: Set the upload directory.
• SecUploadKeepFiles: This must be set to On for the above to be used. For security’s sake you want to set it to  Off so upload files are not saved.
• SecAuditEngine: Enables the logging facility. This value is set to either RelevantOnly or DynamicOrRelevant.
• SecAuditLog: The location of the log file.
• SecFilterDebugLog: Set the debug log file.
• SecFilterDebugLevel: Set the debug level.

That is the minimum directives I would employ for your mod_security configuration.

Once you finish this section, restart Apache again and enjoy a much more secure Apache server.

Final thoughts

Of course this just scratches the surface of mod_security. To really get the most of this powerful feature you will want to really comb through the directives section on the mod_security site.

In this article I will show you five simple ways to make your Linux Apache installation more secure. And of course you should always know that even with five new means of making your install more secure, that doesn’t mean it is perfectly safe from attack. Even after securing your installation, you should always keep watch over your server by checking log files and using standard security tools.

With that said, let’s get our Apache security on!

1. Update, update, update! One of the biggest no nos Linux administrators make is to “set it and forget it”. This should not be your standard policy. There are always updates that close new holes and patch security flaws. This holds true for Apache as much as it does any other system or application. Keep watch, using your normal means of update, for any security update for Apache or any constituent component you have installed. By doing this you will ensure your web server is safe from any new known issues.

2. Disable modules you do not use. If you check the Apache configuration file. Most often this file is called httpd.conf and its location will depend upon what distribution you are running (For example CentOS has this file in /etc/httpd/conf/ whereas Ubuntu locates it in /etc/apache2). If you examine that file you will see quite a few modules listed. These modules will look like:

LoadModule auth_basic_module modules/mod_auth_basic.so
LoadModule auth_digest_module modules/mod_auth_digest.so
LoadModule authn_file_module modules/mod_authn_file.so
LoadModule authn_alias_module modules/mod_authn_alias.so
LoadModule authn_anon_module modules/mod_authn_anon.so

You might have to look up what some of these modules do to know if you need them or not. But there is no reason to load a module if you are not going to use it. To keep a module from loading place a comment in front of the line. You will have to restart Apache for this change to take effect.

3. Limit the request sizes allowed. Denial of Service attacks remain one of the most popular attacks on web sites because they are the easiest to pull off. One way to protect your site from DoS attacks is to use the following directives wisely: LimitRequestBody, LimitRequestFields, LimitRequestFieldSize, LimitRequestLine, and LimitXMLRequestBody within a Directory tag (the document root is probably the best place for this). By default Apache sets these directives to unlimited which means any size of request can be made. You will want to investigate these directives and configure them to suit your web sites needs. Unless it is absolutely necessary, do not set them to unlimited.

4. Use mod_security. This is the most important module you can use. This one module handles such tasks as: Simple filtering, regular expression filtering, server identity masking, and URL encoding validation. It is likely you will have to install mod_security, because the default Apache install does not include this module. Once installed you will want to make sure you at least add the “unique_id” and “security2″ directives in your Apache module section and then restart Apache. I will deal with this module in its own tutorial coming up very soon.

Figure 1

5. Restrict browsing to your document root. The last thing you want is to allow browser to peek outside of the Apache document root (Such as /var/www/html or /var/www/). To do this you will want to configure your document root directory entry as shown in Figure 1. This will

Of course if you want to add options to any directory inside of the document root you will have to give that directory its own Directory entry.

Final thoughts

There are plenty more ways to secure your Apache installation, but these will get you started. Can you think of other ways to secure an Apache installation? If so, share them with your fellow ghacks readers.

• Get course information
• Contact the instructor
• Read or download lecture notes
• Get assignments
• Ask questions and get answers
• Communicate with other students

CourseForum is incredibly easy to “install” on Linux, Windows, Mac,? FreeBSD, or Solaris and can be accessed from any web browser. Let’s take a look at this classroom software from the Linux point of view.

Getting and Installing

Since CourseForum even has its own server built in you can install CourseForum anywhere on a Linux machine. CourseForum comes in a single executable binary that starts and runs CourseForum on port 3455. So after you download the demo follow these steps (as either the root user or using sudo):

Untar the package into your servers’ document root (i.e. /var/www/html for Fedora /var/www in Ubuntu)

Change into the newly created directory (courseforum-linux) and issue the command:

./courseforum &

The CourseForum daemon will start and you can now point your browser to:

http://IP_OR_DOMAIN:3445

Where IP_OR_DOMAIN is either the IP address or domain the server is on.

CourseForum Admin Page

This address will take you to the front page of CourseForum. The first thing you will need to do (before you can do anything else) is set an administrative password. Once you do that you can access the administration page and start building your course. NOTE: The demo is restricted to only a single course. If you purchase the full version you can create unlimited courses.

As you can see (in the image to the left) all administration tasks are taken care of in one window. There isn’t a lot of admin work to do with this software which makes it an even better solution for busy instructors.

Some of the more important tasks your instructors will want to do are:

• Messages: This is really just the welcome message displayed on the front page of CourseForum.
• Custom Links: This isn’t really what it sounds like. What this feature does is allow you to create custom? commands that can do any number of things like formatting or integrating third-party content. There is a good how-to page on the CourseForum site to illustrate how these are created.
• RSS/Email Notification: If you want to enable RSS feeds and/or email notification on your CourseForum site you will have to enter the information for your SMTP server here.
• Web Views: This allows you to create a read-only version of the CourseForum. Since the basis of CourseForum is a wiki, any registered user will be able to edit pages, so you will want to be ablel to serve up versions of pages (such as Syllaubus, lectures, etc) that are read-only for the public to view.

There is one administrative task I would highly recommend. When you create a new course you will have to administer that course independently of the site administration (In other words it has its own admin page). Within the course administration page you will want to take care of at least two things:

• Check the “Only course administrator can create projects” check box.
• Under the Require Password dropdown select “To edit pages” otherwise any registered user can edit your course pages.

And that’s pretty much it. The rest of the tool works like a standard Wiki page.

Final Thoughts

If you have been looking for a tool to allow students (of any type) to not only stay current in your classroom but also be able to interact, CourseForum might very well be the solution for you. I have deployed it for a few teachers who have been very pleased with the results. It’s remarkably seasy to install, simple to use, reliable, and it’s a fairly cheap solution ($119.00 USD).

In this article I will show you how to add name-based virtual hosts in your Apache web server. This will require you to edit the /etc/httpd/conf/httpd.conf file so be prepared for some command-line action. NOTE: This file can be located in various locations

If you’ve never edited your httpd.conf file don’t worry, it’s not that difficult. Just make sure you use good comments so you know what you did and where you did it. Otherwise your virtual host section could get lost in the other sections.

The section of Apache where your virtual hosts will go is called, aptly, Virtual Hosts. The format of an entry looks like this:

<VirtualHost *:80>
ServerAdmin admin@dummy-host.example.com
DocumentRoot /www/docs/dummy-host.example.com
ServerName dummy-host.example.com
ErrorLog logs/dummy-host.example.com-error_log
CustomLog logs/dummy-host.example.com-access_log common
</VirtualHost>

Before you actually start configuring your virtual host you need to make sure you have the NameVirtualHosts line uncommented out. The line will look like:

NameVirtualHosts *

You can find the line by using the grep command like so:

grep -n NameVirtualHosts /etc/httpd/conf/httpd.conf

(NOTE: Edit the path to your httpd.conf file to reflect your setup.)

The grep command will return to you which line the NameVirtualHost entry is on. Now open up the Nano editor and scroll down a bit. You can hit the key combination Ctrl-c to find out what line you are on. Once you find the line you will remove the “#” character (no quotes).

With that out of the way you are ready.

To illustrate how this is done I will show you how to create a virtual server for mail. The following assumes the doc root is /var/www/. Add the following entries to your httpd.conf file:

<VirtualHost *:80>
DocumentRoot /www/yourcompany
ServerName www.yourcompany.com
# Other directives here
</VirtualHost>

<VirtualHost *:80>
DocumentRoot /www/mail
ServerName mail.yourcompany.com
# Other directives here
</VirtualHost>

NOTE: Where yourcompany.com is the actual FQDN you use.

NOTE: If you need to change your port you can change it to suit your needs from the default port 80.

The above is the bare minimum configuration for your virtual servers. There are a LOT of possible directives you can use. For example, you might want to add error logging to these virtual hosts for debugging purposes. To add error logs to your virtual mail host? you would add the lines:

ErrorLog /var/log/httpd/mail-error_log common
CustomLog /var/log/httpd/mail-access_log common

To your mail virtual host entry (above the </VirtualHost> line.)

Once you have these entries complete you will need to save the httpd.conf file and restart Apache. To restart Apache issue one of the following commands:

/etc/rc.d/init.d/httpd restart

or

/etc/init.d/apache2 restart

You’re done. You should now be able to hit the new virtual hosts.

Final Thoughts

Creating virtual hosts is a quick way to expand the capabilities of your Apache server, cut costs, and save IP addreses. Have you ever deployed virtual hosts with Apache? If so, share your experiences.

The web server can be downloaded in various configurations. The various configurations range from a bare-bone Apache web server to a web server supporting MySQL, SQLite, Pearl and PHP. The configuration only has an effect on the type of applications that can be run on the web server. Most users will probably need at least MySQL and PHP support to run their websites locally.

The web server can be started by double-clicking on the Server2Go.exe executable file in the root directory of the server. This will load the various web server modules and display a start page in the web browser. The pms_config.ini file can be used to change various settings of the web server including the default web browser, the port and whether the modules like MySQL or PHP should be started as well.

The actual files of a website are placed in the htdocs directory of the web server. Loading them can be as easy as pointing your browser to 127.0.0.1:4001 or some subdirectory of it depending on the type of site.

MySQL comes with phpMyAdmin which is accessible from the main interface of the web server. Server2Go offers an uncomplicated way to run a web server, it is especially helpful in environments where software installations are restricted.

I use it mainly to secure certain directories on my websites from being accessed without the proper authorization. This is the admin directory in the case of WordPress for instance but could also be used to secure a directory that hosts some valuable files.

I would like to point out two possibilities that secure a directory with .htacess. The first is to protect the directory by only allowing users with a certain IP or IP range access to it. Everyone else would receive an access denied error message.

The second possibility would be to create usernames and passwords that have to be supplied before accessing the content.

IP Protection:

Create a .htaccess file and add the following code to it:

AuthName "Protected Content"
AuthType Basic

order deny,allow
deny from all
#Comment
allow from 255.255.255.255


Change the IP address in the last line to the one used by the user / users. You can use wildcards * if the user is receiving dynamic IPs from his ISP. It is possible to add as many allow from lines to the .htaccess file as you want. Place that htaccess file in the directory that you want to protect. (all subdirectories are affected as well.

The problem with this kind of protection is twofold. If your IP changes, say you are on holiday or accessing from a different location, you need to add or change the IPs in the htaccess code. Users who happen to have a IP of that range can access the content without problems. This is usually a user from the same ISP.

A more secure protection is the basic auth protection.

Password Protection:

Whenever a user tries to access a directory or file a popup will appear asking the user for a username and password. This method requires two files, a htaccess file and a htpasswd file. The htpasswd file stores the usernames and encrypted passwords and should be placed outside of the root directory of the website.

AuthName "Restricted Area"
AuthType Basic
AuthUserFile /path/to/.htpasswd
AuthGroupFile /dev/null
require valid-user

Since the passwords are encrypted you need to use a script to do that. A working one is the htpasswd Content Generator. Just enter a username and password and click on encrypt. Paste the line on the results page into the htpasswd file and place it exactly in the path that you specified in AuthUserFile.

It is possible to combine both protections for added security. I would begin by evaluating if your webhost is allowing those kind of files.

The only disadvantage that I can think of is that you will not use the latest version on their website and that you have to update the database to keep up to date. The English database file has a size of more than 3 Gigabytes – packed that is – and it can take some time to download it depending on your Internet connection.

I did use a download manager to make sure that the download does not get interrupted and I have to start over again. Here is the list of files that you do need, I walk you through the installation afterwards:

• Wikipedia Database Snapshot – the file needed is currently called enwiki-latest-pages-articles.xml.bz2
• An Apache server. I did use the free XAMPP to install it on my Windows system.
• Wikifilter – the script that makes Wikipedia available in the Apache server.

I suggest you start by downloading the files needed. The Wikipedia database download will naturally take longer than the other two downloads which is excellent for our purpose. Once XAMPP has been downloaded install it. You are asked if you want to add services to your system during installation, this is not needed. Make sure you start the XAMPP control panel afterwards.

Keep this open and wait for the downloads to finish. Now unpack the file that contains the Wikipedia articles and wait for it to finish. The unpacked file has a size of more than 13 Gigabytes so make sure you have enough free hard drive space on that drive.
Now add the date of the release in the format YYYYMMDD to the file name. I added it at the end before the .xml.

Now run WikiIndex.exe and drag and drop the XML file in the program window. It starts indexing the database file which should take a while as well (5 minutes on my system). We are almost done now.

You need to locate the httpd.conf file in the XAMPP directory and add an entry to it. The file is located in xampp\apache\conf. Just open it with a normal text editor and add the following line at the end:

LoadModule WikiFilter_module “C:/Program Files/WikiFilter/WikiFilter.so”

Please replace the path to the WikiFilter.so file with the path on your system. You should also note that the file path uses “/” instead of the usual “\” to separate directories.

Start Apache using the XAMPP control panel and point your browser to the url http://localhost/wiki/.

Download Xampp for Windows and install it on your system. It does not matter if you install the modules as services, you can activate them as well by opening the control panel. (start apache) Once installed the webserver should be accessible by typing in http://localhost or http://yourdynamicip; You can look up your dynamic ip using my ip lookup script. Hosting files is as easy, just upload all the files that you want to share into the subfolder htdocs or create a subfolder and add the files to it.

Access the subfolder by appending /subfolder/ to the url that you want to access. You can add html and php files as well and those can be accessed as well similar to those files on other websites. It is easy to secure folders or the complete server using so called .htaccess files. Use the htaccess generator and add the generated files to your directories that you want to protect.

There is one last thing that can be optimized. It is difficulty for others to access your webserver if you have dynamic IPs. To counter this you could use a free service like DynDNS which adds a static dns to your IP. Friends and everyone else who should access the webserver can then use the dynamic dns which looks something like subdomain.dyndns.bz instead of the dynamic IP address.

Now i don’t know how many readers work with websites, but maybe some of you can use this link. It’s an article on how to speed up sites using .htaccess file. It is quite a read but it looks promising, and the comment discussion there can also prove to be quite useful.