Part of the problem with Linux systems is the diverse and varied ways in which user data is stored. Because of a long legacy with POSIX standards, data ends up being placed in varied locations. As an example, take a look at following table which provides the data locations for some ClearOS apps:

To help describe the bind mount concepts, we are going to walk through an example. We have installed ClearOS on a system with a 50 GB solid state drive and 6 TB RAID array. ClearOS is only installed on the solid state drive while the RAID array is mounted to /store as an empty data drive. This particular system is a dedicated Web Proxy and Content Filter gateway for a school.

The Web Proxy requires data storage for its cache, and since this system is running in a school a large cache is desired. The underlying software (Squid) uses the /var/spool/squid directory to store all the cached files. Through mount bind, this /var/spool/squid cache directory can also be mapped to /store/web_proxy/spool. This mapping is done by specifying the following entry in /etc/fstab:

/store/web_proxy/spool /var/spool/squid none bind,rw 0 0

The actual data for the web proxy cache now lives on the RAID disk, but the mount bind configuration in /etc/fstab also makes the data available in /var/spool/squid. The web proxy system is unaware that the actual cache data exists elsewhere on the file system. Linux magic.

Though this example only covered the web proxy cache, any ClearOS app that needs storage can automatically create a mount bind entry in /etc/fstab. The mechanism for storage mappings is described in the next section.

The $base variable is taken from the primary configuration file (default: /store).

If you want to override the defaults here, please do not overwrite the default file! Instead, copy the default web_proxy_default.conf to web_proxy.conf and edit the parameters in the new file. For example, you might want to put the web proxy cache on a separate solid state disk to increase throughput, so your configuration file would look something like:

Starting with ClearOS 6.4.0, the Storage Manager became available for the Amazon EC2 ClearOS builds. However, you can install the app on any ClearOS system, but it requires moving data around on the command line. To install the software, run:

yum install app-storage

Point your web browser over to System Storage Storage Manager in the web-based interface. You will see something similar to the screenshot below.

In the above screenshot, you can see that ClearOS is installed on the 9 GB /dev/sda drive. The /dev/sdb and /dev/sdc drives are unformatted and available. If you are using hard disks from a previous install, the Storage Manager may chicken out and set the In Use status. Only disks without partitions will show up in the web-based interface at this time. If you want blow away the data on a disk, you can use the dd command with extreme caution:

Now that /store is ready, you can enable Storage Manager by changing the enabled parameter in /etc/clearos/storage.conf. Now run the following to notify the storage manager to check the mappings. Don't worry, nothing destructive happens here:

storage

Go back to ClearOS web interface to see if any of the storage mappings are enabled. In our example shown in the screenshot below, both the Web Proxy and Users apps are now mapped to our new storage locations:

:

The Storage Manager was able to create these mappings because the target directories were still empty and unused. In other words, no users existed and the Web Proxy had never been started. Do not be surprised if none of the mappings are enabled on your system since there is a good chance that data already exists for all the apps.

In our example, the System Database was already in use by the reports engine, so the storage system refused to perform the mapping. To get the mapping working, we need to migrate the data from the old directory - /var/lib/system-mysql/ - to the new storage directory.

At this point, the System Database storage mapping should be happy. Check the /etc/fstab file and output from mount as a sanity check. If there's a problem, check the status in the ClearOS web-based interface.

The next step is to move the database data from the old location to the new storage location. Feel free to copy the files instead of moving, but remember to delete the old /var/tmp files once you are comfortable with the new storage location. The following command may look like you are moving the files back the old location, but in fact the actual data is now going to the /store disk. Since this is a disk-to-disk move, this move can take some time.

mv /var/tmp/system-mysql/* /var/lib/system-mysql

And finally, restart the system database:

service system-mysqld start

This same procedure can be used to migrate data from an old location to the new /store location. Please do not feel the need to migrate all the data, it is completely up to you.