1. You're basically using SSH to communicate.  SSH is encrypted, and as such can be one of the most secure methods of communication available.
2. The setup is relatively simple, as you only need a few libraries on the client computers, and an SSH server running on the remote server.
3. Permissions, users, and groups are all preserved as they would be using normal SSH.
4. You can turn off in-secure, un-encrypted FTP completely.
5. Fast access to files via your file manager application as if they were stored locally on your computer.  For Linux Gnome users, your SSHFS mounted shares will show up in Nautilus and act accordingly.

HowTo:

For Ubuntu, simply install sshfs via the package manager.  You'll then need to add your Ubuntu user account to the Fuse group so that you'll have permission to use Fuse.  To do this, go to System -> Administration -> Users and Groups.  Click on your username and click the "Properties" button.  Make sure the checkbox for "fuse" is checked and save your settings.  You may need to log out and log back in for these changes to take effect.  Now you can mount an SSH server in the directory called "remote":

sshfs landon@holleygrove.com: remote

And to disconnect:

fusermount -u remote

It's great to be able to run a command to mount an SSH server, then pop open nautlius and have all the remote files and directories listed right there just as any other files!

So, how can you provide your multiple clients with Virtual Domains their own SSL and https:// address? You can:

• Let them share your server's SSL certificate, and server name (e.g. https://holleygrove.com/secure/CustomerName). This, unfortunately is a different domain name, so it may bring up a red flag to some shoppers, however, if you have a valid SSL certificate for your domain (holleygrove.com), the site will be valid and no security warnings will appear.
• Redirect them to the https version of their domain name even though there is not a valid SSL certificate for their domain (or there is, but because of the SSL protocol, Apache cannot access it). This will present the user with a domain name/ SSL certificate mis-match (which is bad), but the URL will read https://CustomerName.

Both of the above solutions have compromises. The best way to get around this is to use a separate IP address specifically for your VirtualDomain. This will allow you to setup Apache to listen for your VitrualDomain... SSL (port 443) and HTTP (port 80) on this particular IP address. Below is a working code excerpt from Apache 2.2 for a VirtualDomain listening on a separate IP address:

 # IP Based Virtual Host - Example.com - IP:  192.168.1.1
NameVirtualHost 192.168.1.1:80
<VirtualHost 192.168.1.1:80>
        ServerAdmin support@holleygrove.com
        DocumentRoot /home/example/public_html
        ServerName www.example.com
        ServerAlias example.com *.example.com
        ErrorLog /etc/httpd/groups/example/logs/error_log
        CustomLog /etc/httpd/groups/example/logs/access_log combined
        #TransferLog /etc/httpd/groups/example/logs/access_log
        <Directory "/home/example/public_html">
                AllowOverride All
                Order allow,deny
                Allow from all
        </Directory>
</VirtualHost>

Make sure to change the above directive to match your IP and system configuration, and place it in your Apache's configuration file. Any IP-based VirtaulHost directives, such as the one above, should be placed after any non-IP based (name based) VirtualHost directives.

To get started, simply go to http://google.com/a and sign up.  Google offers a basic edition, premier edition, and a pro-bono edition.  I've always used the basic edition and found it is more than adequate for smaller sites, but, if you're so inclined, you may want to spring for the premier edition.  Simply click on the signup button:

Fill out the required information.  In this example, I'm using a domain I've already registered with GoDaddy called theartisticweb.com.

Now you'll need to create and administrator email account.  This is the main mail account that will be associated with our domain example.com.  I'll create "admin".  This can later be changed through the dashboard if you ever need to by adding another administrator and deleting this account.

We've now signed up our domain with Google apps.  The first thing we need to do is to validate our domain:

If you've used Google webmaster tools before, you're familiar with the domain validation process.  Basically we just need to create an HTML file (in this case called googlehostedservice.html) on our webserver with the text from Google inside.  Just click domain validate:

Create a blank HTML file called googlehostedservice.html and add the required text to it, and upload it to your domain's root web folder.  Verify that you can read the link by clicking on it in your browser, then if all is good click verify.

The verification process is rather fast, so once you return to the dashboard, Google will probably have already verified your domain.  Now we can begin the email setup.

Click on the "Setup Email" link:

Here you can choose what instructions Google will show you based on your DNS provider.  Ours is GoDaddy, so I select GoDaddy from the list, and follow the instructions.  Note: you must be using the nameservers of the company that is hosting your domain name in order for these insturctions to work.  If not, you will need to contact your domain name's DNS provider to change these settings for you.  By default, domain names use the DNS servers of the company you purchased the domain name from, e.g. GoDaddy, so you should be ok unless you've changed the nameservers for your domain somewhere along the line.

Once you've entered the MX records exactly as shown (don't forget a trailing "." if applicable), click ok.  It should take anywhere from 10 minutes to a day or two to update the DNS settings for your domain and Google apps.  If you've done the steps correctly, then just be patient.  You can use dnstools.com to check the status of your MX records, or on a *NIX machine type

dig example.com MX

to get a reading on your MX records.  Once they've updated, you can then use Google's server to handle all of your company's email!  Presto!

With Fedora 6, logrotate comes installed automatically, but we could have installed it via yum as root:

yum install logrotate

Logrotate should have put an entry in /etc/cron.daily, and will then be run as a daily cron job automatically.  The Fedora package of logrotate will automatically rotate most of your system logs.  But, as we have some "unconventional" virtual host logs we'd also like to rotate, we'll have to set those up manually.

To setup the rotation of the virutal host logs, you can cd to /etc/logrotate.d.   There you should see a file for apahce's default logs called httpd.  Just copy or modify this file for each virtual host you have.  Any files in /etc/logrotate.d will be automatically read by logrotate when it runs.  That's it!