Category Archives: Website hosting

Home / NAS / Website hosting
7 Posts

With the introduction of DSM 5 by Synology a lot of things seems to have changed. Many of them in the good way, some other needed attention from the owner. The changes in the Web server on your DiskStation is one of them.

In the beta of DSM 5 many users complained that some components of Apache (Web server) are removed. Especially the components regarding redirection, authentication and the account being used to run the Web service (http:http) causes a lot of headaches. With the release of DSM most of these components are available again. This article describes the things I have done to make my web services run again as supposed to run.

Force to HTTPS

Some of the services I run needs to be forced to HTTPS for obvious reasons: you don’t want to authenticate on a not secured connection. In the past I used the .htaccess file for this. With the changes made in the web service of the DiskStation I had to reconsider this ‘design’ and started reading some Apache documentation on different places. Soon it became clear to me that redirecting with an .htaccess file is more or less depreciated when you have admin access to the web server. A better place to do this is the virtual host configuration of your web server.

In the past I had an issue to overcome when redirecting an http connection to https to ensure that the username and password of the authentication are send on a secured connection. I was confronted with the fact that I had to authenticate twice when I redirected from http to https and have to authenticate with Basic Authentication. This phenomenon is due to the sequence of handling different tasks in the Web service. (authentication comes before redirecting.) There is a kind of hack to overcome this, but this is not a very clean way to do this. The hack uses SSLRequireSSL and ‘abuses’ ErrorDocument 403 https://www.example.com/ to redirect to https.

To start redirecting in a more clean way, I started to search for the configuration file to alter. In the folder /etc/httpd/conf I found the files I was looking for. After inspecting those files, I learned that the configuration includes external files from the sites-enabled-user/ folder as long as the files have .conf as an extension. this enables me to have all the modifications I’d like to make to the configuration of the Web service stored in separate files. This keeps the original configuration files clean and minimizes the risk of damaging the Web service. In the folder /etc/httpd/sites-enabled-user I created a file named force_https.conf.

There can be different approaches on how to determine what folder has to be forced to https. I choose to explicitly describe those folder. (You might want to conciser the opposite: describe witch folders not to force to https by using the ! in the regular expression of defining the folders.) In the image you see an example structure of a http-root. The yellow marked folders are supposed to be forced to https.

Syno-httpd-map-structure

With the following content of the file force_https.conf you force ‘secure1’ and ‘secure2’ to https:

RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteCond %{REQUEST_URI} ^(/secure1|/secure2) [NC]
RewriteRule .* https://%{SERVER_NAME}%{REQUEST_URI} [R=301,L]

The next thing to do is to restart the web service to activate these settings with:

/usr/syno/sbin/synoservicecfg --restart httpd-user

With this technique the redirection will be performed before starting Basic Authentication and avoids the double authentication when redirecting from http to https.

One of the beautiful things of our Diskstation is that Synology provided it with a plug-and-play feature to give your NAS even more functionality. It’s called Package Center. Synology offers a lot of packages out of the box. These packages have to be maintained by Synology. That is not a big issue if these packages are kept up-to-date within an acceptable period of time. However Synology (and probably other NAS-providers who are using these kinds of mechanisms to offer more functionality to their products) can’t always keep up the update pace of the software in their packages.

If you are using packages that has a large install base then you are more vulnerable to attacks of hackers. Especial when you use the software as a public internet service. It’s is critical you can update these packages as soon as the producer makes the (security) updates available. When you are using the Synology package, you have to wait until they update the package. Unfortunately this seems not to have any priority at Synology’s. I noticed this when using the WordPress package. WordPress kept updating but my installation stay’s on the version that was delivered by the Synology package.

I tried to find a solution for this without compromising my content.  The following steps describes how I did it.

  1. Make sure you have a fallback in case anything goes wrong. Don’t underestimate this. It’s like an insurance: You invest in something you hope never have to use. I use Duplicator to make a backup of my complete WordPress site. It’s a plugin for WordPress and makes it possible to rebuild the complete site even if the only thing left is an empty web server. I wrote a complete post how this work previously and can be found here.
    Another measure to minimize the risk of losing anything, is the possibility to test the modifications on a place where it can’t do any harm and comes as close as possible to the real world situation. Most of the time you have no spare Diskstation available to do your experiments. Modifications must be done in a ‘production’ environment without being sure the outcome doesn’t compromise your NAS. Scary Huh?. Fortunately there is a reasonable alternative: a virtual Diskstation.
    In a previous post here you can read how to get your own virtual Diskstation. These two measures gives you the opportunity to try anything you like without compromising your NAS. If you build your own virtual NAS and made a backup of your site, I encourage you to test your backup before you go further. (Having a backup is good, knowing the restoration of this backup works is better!)
    Now you have all the equipment to practice the upgrade procedure before you do this on your physical NAS. USE THIS! When anything goes wrong, you’ll be more than happy you did.
  2. Your WordPress installation is located in the web share of your Diskstation. In that share you’ll find a folder with the obvious name wordpress. There is the location your WordPress files are stored. However the best way is to use FTP or SSH to manage your WordPress files. In that case you have to look into /volume1/web/wordpress/ (or another volume where your website is stored.) Make sure you have write access here and you might have to set the owner of this folder to nobody:nobody. (DSM 5.x users have to use http:http)
  3. To update this you have to follow the exact description of a manually update of a WordPress installation described on the WordPress site: http://codex.wordpress.org/Updating_WordPress. Read the whole page and follow the manual update instructions carefully. (It isn’t hard)
  4. After visiting the wp-admin page as stated in the update instructions, the job is done. The next available update will come from WordPress and you have not to wait until Synology brings it’s update.
  5. You CAN NOT remove the WordPress Package form the package center. This will uninstall your WordPress and leaves you with an empty site.  The only thing you can probably do is to delete the package information on your NAS. You need SSH access to the filesystem of your Diskstation for this. Go to the /var/packages/ folder. There is a wordpress folder. When you delete this folder, the WordPress package disappears from your Package Center. Doing this is at your own risk. I don’t know what the consequences are for the stability of your Diskstation.

It is not complex to do. Just take your time and act carefully. With a good strategy and enough testing of your backup scenario’s, there is not much that can go wrong.

I dealt a long time with an issue in my WordPress installation, but didn’t trust me to experiment around and have a non working WordPress installation at the end. I decided to find a way to clone my whole WordPress installation and satisfy my experimental drift there. When I find a way to clone my WordPress installation, I also find a way to do something about disaster recovery of my WordPress blog.

It has to be a reliable method and must be more or less foolproof, because I wouldn’t like to spend much of the time repairing if it is not nesessary. I think I’ve found a solution that ticks all the boxes: a plugin called Duplicator (http://wordpress.org/extend/plugins/duplicator/)

Duplicator can be installed as a regular WordPress plugin. The interface is simple but effective. A complete manual can be found here at LifeInTheGrid website.

The first time you are getting acquainted with Duplicator is with the screen above wihout the list of packages. Once you have created a backup of your WordPress site, the list with packages will grow. To create a backup simply press the Create Package button witch is located in the red circled area in the image above. Just give it a logical name and press the Create Package Set button , sit back and wait. When the backup is finished, a package set will appear.

To transport your site to another location you just press the two buttons (in the green area) behind your package. These buttons start two downloads. One of a zip-file containing your WordPress site and another to download the installer (installer.php). Save these files on your computer.

To rebuild your site on another location (or in case of a disaster on your original location) you have to make sure that you have created an empty wordpress rootfolder and an empty wordpressblog database schema on your target location. Make sure you have the appropiate rights on the database schema and the wordpress rootfolder. (I assume you have a working Apache and MySQL on your targetsystem.)

copy the zipfile and the installer.php to the WordPress rootfolder on your target system and open installer.php in your favorite browser (ie. http://myaddress/wordpress/installer.php) and follow the instructions on the screen.

If you met the requirements, the installer has three steps to follow:

  1. The first one is the step that asks you for your MySQL credentials. (This is also the last opportunity to drop all the tables in the wordpressblog schema by ticking the box before Table Removal.) Enter here your MySql credentials to let the installer create the database and tables.

  2. The second step lets you changing the url and the physical location of your WordPress rootfolder. Hardcoded locations in the pages and posts will not be changed. It also allowes you to decide witch plugins should be started or not. Disable all plugins during the installation but not the login redirectors. Enable the plugins after the installation in the Admin page of your WordPress site.

  3. This last step will give you directions to follow to make sure your WordPress is able to run again. Make sure you remove the following files from the WordPress rootfolder: installer.php, installer-log.txt, installer-data.sql

You now must be able to open your working WordPress site from the new location.

This post assumes you have installed a valid SSL certificate on your web server. You can obtain a certificate from CACert.org. If you use this certificate provider, make sure you import their class 1 and class 3 root certificates in your Trusted Root Certification Authorities store.

You don’t want your users to access their Zarafa webmail over a plain HTTP connection. Instead of that you want to force them to use a HTTPS. You can accomplish this by altering the .htaccess file of /webapp/ and /webaccess/. Just add the following lines to .htacces:

SSLOptions +StrictRequire
SSLRequireSSL
ErrorDocument 403 "https://yourhost/webaccess/"

Make sure you alter ‘yourhost’ to your own domain and make sure you change webbaccess into webapp if you alter the .htaccess in the webapp folder.

 

Introduction

In this tutorial you will find out about the .htaccess file and the power it has to improve your website. Although .htaccess is only a file, it can change settings on the servers and allow you to do many different things, the most popular being able to have your own custom 404 error pages. .htaccess isn’t difficult to use and is really just made up of a few simple instructions in a text file.

Will My Host Support It?

This is probably the hardest question to give a simple answer to. Many hosts support .htaccess but don’t actually publicize it and many other hosts have the capability but do not allow their users to have a .htaccess file. As a general rule, if your server runs Unix or Linux, or any version of the Apache web server it will support .htaccess, although your host may not allow you to use it.

A good sign of whether your host allows .htaccess files is if they support password protection of folders. To do this they will need to offer .htaccess (although in a few cases they will offer password protection but not let you use .htaccess). The best thing to do if you are unsure is to either upload your own .htaccess file and see if it works or e-mail your web host and ask them.

What can I do?

You may be wondering what .htaccess can do, or you may have read about some of its uses but don’t realize how many things you can actually do with it.

There is a huge range of things .htaccess can do including: password protecting folders, redirecting users automatically, custom error pages, changing your file extensions, banning users with certain IP addresses, only allowing users with certain IP addresses, stopping directory listings and using a different file as the index file.

Creating A .htaccess File

Creating a .htaccess file may cause you a few problems. Writing the file is easy, you just need enter the appropriate code into a text editor (like notepad). You may run into problems with saving the file. Because .htaccess is a strange file name (the file actually has no name but a 8 letter file extension) it may not be accepted on certain systems (e.g. Windows 3.1). With most operating systems, though, all you need to do is to save the file by entering the name as:

".htaccess"

(including the quotes). If this doesn’t work, you will need to name it something else (e.g. htaccess.txt) and then upload it to the server. Once you have uploaded the file you can then rename it using an FTP program.

Warning

Before beginning using .htaccess, I should give you one warning. Although using .htaccess on your server is extremely unlikely to cause you any problems (if something is wrong it simply won’t work), you should be wary if you are using the Microsoft FrontPage Extensions. The FrontPage extensions use the .htaccess file so you should not really edit it to add your own information. If you do want to (this is not recommended, but possible) you should download the .htaccess file from your server first (if it exists) and then add your code to the beginning.

Custom Error Pages

The first use of the .htaccess file which I will cover is custom error pages. These will allow you to have your own, personal error pages (for example when a file is not found) instead of using your host’s error pages or having no page. This will make your site seem much more professional in the unlikely event of an error. It will also allow you to create scripts to notify you if there is an error (for example I use a PHP script on Free Webmaster Help to automatically e- mail me when a page is not found).

You can use custom error pages for any error as long as you know its number (like 404 for page not found) by adding the following to your .htaccess file:

ErrorDocument errornumber /file.html

For example if I had the file notfound.html in the root direct ory of my site and I wanted to use it for a 404 error I would use:

ErrorDocument 404 /notfound.html

If the file is not in the root directory of your site, you just need to put the path to it:

ErrorDocument 500 /errorpages/500.html

These are some of the most common errors:

401 - Authorization Required 
400 - Bad request 
403 - Forbidden 
500 - Internal Server Error 
404 - Wrong page

Then, all you need to do is to create a file to display when the error happens and upload it and the .htaccess file.

Stop A Directory Index From Being Shown

Sometimes, for one reason or another, you will have no index file in your directory. This will, of course, mean that if someone types the directory name into their browser, a full listing of all the files in that directory will be shown. This could be a security risk for your site.

To prevent against this (without creating lots of new ‘index’ files, you can enter a command into your .htaccess file to stop the directory list from being shown:

Options -Indexes

Deny/Allow Certian IP Addresses

In some situations, you may want to only allow people with specific IP addresses to access your site (for example, only allowing people using a particular ISP to get into a certain directory) or you may want to ban certain IP addresses (for example, keeping disruptive members out of your message boards). Of course, this will only work if you know the IP addresses you want to ban and, as most people on the internet now have a dynamic IP address, so this is not always the best way to limit usage. You can block an IP address by using:

deny from 000.000.000.000

where 000.000.000.000 is the IP address. If you only specify 1 or 2 of the groups of numbers, you will block a whole range.

You can allow an IP address by using:

allow from 000.000.000.000

where 000.000.000.000 is the IP address. If you only specify 1 or 2 of the groups of numbers, you will allow a whole range.

If you want to deny everyone from accessing a directory, you can use:

deny from all

but this will still allow scripts to use the files in the directory.

Alternative Index Files

You may not always want to use index.htm or index.html as your index file for a directory, for example if you are using PHP files in your site, you may want index.php to be the index file for a directory. You are not limited to ‘index’ files though. Using .htaccess you can set foofoo.blah to be your index file if you want to!

Alternate index files are entered in a list. The server will work from left to right, checking to see if each file exists, if none of them exisit it will display a directory listing (unless, of course, you have turned this off).

DirectoryIndex index.php index.php3 messagebrd.pl index.html index.htm

Redirection

One of the most useful functions of the .htaccess file is to redirect requests to different files, either on the same server, or on a completely different web site. It can be extremely useful if you change the name of one of your files but allow users to still find it. Another use (which I find very useful) is to redirect to a longer URL, for example in my newsletters I can use a very short URL for my affiliate links. The following can be done to redirect a specific file:

Redirect /location/from/root/file.ext http://www.othersite.com/new/file/location.xyz

In this above example, a file in the root directory called oldfile.html would be entered as:

/oldfile.html

and a file in the old subdirectory would be entered as:

/old/oldfile.html

You can also redirect whole directories of your site using the .htaccess file, for example if you had a directory called olddirectory on your site and you had set up the same files on a new site at: http://www.newsite.com/newdirectory/ you could redirect all the files in that directory without having to specify each one:

Redirect /olddirectory http://www.newsite.com/newdirectory

Then, any request to your site below /olddirectory will bee redirected to the new site, with the extra information in the URL added on, for example if someone typed in:

http://www.youroldsite.com/olddirecotry/oldfiles/images/image.gif

They would be redirected to:

http://www.newsite.com/newdirectory/oldfiles/images/image.gif

This can prove to be extremely powerful if used correctly.

Although there are many uses of the .htaccess file, by far the most popular, and probably most useful, is being able to reliably password protect directories on websites. Although JavaScript etc. can also be used to do this, only .htaccess has total security (as someone must know the password to get into the directory, there are no ‘back doors’)

The .htaccess File

Adding password protection to a directory using .htaccess takes two stages. The first part is to add the appropriate lines to your .htaccess file in the directory you would like to protect. Everything below this directory will be password protected:

AuthName "Section Name" 
AuthType Basic 
AuthUserFile /full/path/to/.htpasswd 
Require valid-user

There are a few parts of this which you will need to change for your site. You should replace “Section Name” with the name of the part of the site you are protecting e.g. “Members Area”.

The /full/parth/to/.htpasswd should be changed to reflect the full server path to the .htpasswd file (more on this later). If you do not know what the full path to your web space is, contact your system administrator for details.

The .htpasswd File

Password protecting a directory takes a little more work than any of the other .htaccess functions because you must also create a file to contain the usernames and passwords which are allowed to access the site. These should be placed in a file which (by default) should be called .htpasswd. Like the .htaccess file, this is a file with no name and an 8 letter extension. This can be placed anywhere within you website (as the passwords are encrypted) but it is advisable to store it outside the web root so that it is impossible to access it from the web.

Entering Usernames And Passwords

Once you have created your .htpasswd file (you can do this in a standard text editor) you must enter the usernames and passwords to access the site. They should be entered as follows:

username:password

where the password is the encrypted format of the password. To encrypt the password you will either need to use one of the premade scripts available on the web or write your own. There is a good username/password service at the KxS site which will allow you to enter the user name and password and will output it in the correct format.

For multiple users, just add extra lines to your .htpasswd file in the same format as the first. There are even scripts available for free which will manage the .htpasswd file and will allow automatic adding/removing of users etc.

Accessing The Site

When you try to access a site which has been protected by .htaccess your browser will pop up a standard username/password dialog box. If you don’t like this, there are certain scripts available which allow you to embed a username/password box in a website to do the authentication. You can also send the username and password (unencrypted) in the URL as follows:

http://username:password@www.website.com/directory/

Summary

.htaccess is one of the most useful files a webmaster can use. There are a wide variety of different uses for it which can save time and increase security on your website.

If this is all to complex to type yourself, you might want to take a peek at http://www.htaccesseditor.com/en. This happens to be an online .htaccess generator.

Source: Free webmaster help