At this point, you should be able to access your server through your local network. You won’t be able to access it from the Internet, but don’t worry about that just yet. There are a couple of important security steps before your server goes public that we’ll get to later. In the meantime, let’s focus on the real reason you’re here: hosting your own file sync and music streaming services locally.
Web Hosting
As mentioned earlier, services and daemons are processes that run in the background. Websites work through services known as web servers, which listen for and respond to requests on ports 80 (port 443 for websites that support encryption). For instance, if you want to go to google.com, your computer will send a request to Google’s servers for the contents of google.com. When your request arrives at Google’s servers, it’s directed to the process listening on port 80. This process – the web server – interprets the incoming request and responds with the information your browser needs in order to display google.com.
We’re going to host our own websites using a popular web server called Apache. Apache is one of several components of what is known as the LAMP stack: a bundle of programs and services designed for quick and easy web hosting. The first two letters – Linux and Apache – we’re already familiar with. The M stands for MySQL, which is a database management system, and the P stands for PHP, which is a programming language for creating dynamic scripted websites. We won’t deal with MySQL or PHP directly during this guide, but for more information you can visit MySQL’s official website and PHP’s official website.
Installing the LAMP Stack
To install the LAMP software suite, simply type:
sudo apt-get install lamp-server^
Notice the carat at the end ; this allows apt-get to take the place of another program known as tasksel. Tasksel is a program for easily installing software bundles such as LAMP.
MySQL Root Password
During the installation process, you might be prompted for a password for MySQL’s root user. It’s ok to leave this blank; we won’t need it during this guide.
Testing it Out
Once the installation is done, you’re ready to go! Test out your new web server by opening a web browser and navigating to “http://<server’s internal IP address>.” If all goes well, you should see the following page.
File Sync With ownCloud
I picked ownCloud for this guide because it provides a comprehensive feature set in a package that’s easy to install and maintain. ownCloud combines file synchronization, calendar and contact management, online document editing, and dozens of other features. It provides many of the features you’d expect from a professional cloud service, completely free of charge. For a full overview of ownCloud’s features, visit owncloud.org.
Installing ownCloud
ownCloud provides its own repository which has to be added to our repository list before we can install its packages. The following commands, taken from the ownCloud repository instructions, will add the repository to our system and register its secure key with apt:
sudo sh -c “echo ‘deb http://download.opensuse.org/repositories/isv:/ownCloud:/community/xUbuntu_14.04/ /’>> /etc/apt/sources.list.d/owncloud.list”
wget http://download.opensuse.org/repositories/isv:ownCloud:community/xUbuntu_14.04/Release.key
sudo apt-key add – < Release.key
After refreshing your repository list, you can update and install ownCloud like any other package:
sudo apt-get update
sudo apt-get install owncloud
Once that’s done, try navigating to “http://<server internal IP address>/owncloud.” If all went well, you should be able to set up ownCloud and create an account.
If you see the following error, it means your web server doesn’t have access to a certain directory. The problem relates to the previous section on root and user permissions and is discussed in the next section, Restricted Users.
Restricted Users
During installation, many services add their own separate users to your system. For instance, Apache adds the www-data user. You can’t log in as www-data over SSH, and www-data doesn’t have a folder under /home. The reason www-data exists is to prevent Apache from running as an existing user and gaining permissions, such as your user or even root. Imagine if Apache ran with your user’s permissions: there’s the chance that a malicious user could manipulate Apache into accessing your documents or even running sudo. To prevent this, services create new users that only have the permissions needed to effectively run the service.
For now, all we need to worry about is giving our user write access to ownCloud’s apps folder. You can find the folder at /var/www/owncloud/apps. We’ll cd to owncloud’s web directory to make things easier:
cd /var/www/owncloud
Then run the following two commands to grant www-data the right permissions. The first command runs chown, which changes the owner of the file or directory specified. The -R parameter tells chown that this change should be applied recursively to each file and folder underneath the provided folder. The second command runs chmod, which changes the mode (permission set) of the file. The g+rw parameter tells chmod that we want to add read and write permissions for the group that owns this file (the www-data user is also part of the www-data group) recursively.
sudo chown -R www-data apps/
sudo chmod g+rw -R apps/
With these commands executed, switch back to your web browser and refresh the page.
Setting Up ownCloud
When you’re able to open ownCloud’s setup page, it should ask you to create an admin account. You can also specify where to save ownCloud’s data. This defaults to /var/www/owncloud/data, but you can choose to store it in another location such as an external drive or even on another computer.
There are a lot of features to ownCloud, and the best way to familiarize yourself with them is to jump right in and start using it. ownCloud’s website provides an in-depth manual for getting started with the latest version of ownCloud.
Media Streaming With Subsonic
There are plenty of personal music streaming options available including Plex, Serviio, and PS3 Media Player, but Subsonic has consistently remained one of my favorites. Once you’ve installed Subsonic, you’ll be able to manage and stream all of your music from anywhere in the world.
Subsonic provides a basic free version with a premium subscription option. The premium option adds support for apps, video streaming, podcast support and others. A subscription costs $1 a month, although there is an evaluation period of 30 days. While I encourage anyone who enjoys using Subsonic to support the developer and buy a subscription, I understand that it’s not always possible. There are variations (forks) of Subsonic that remove the licensing model entirely, but finding those forks will be left up to you.
Installing Subsonic
Subsonic is freely available as a package for Ubuntu, although it’s not part of a repository. We’ll use wget – a program for accessing web resources – to download the latest version of Subsonic. As of this writing, the latest version is 5.2:
wget http://sourceforge.net/projects/subsonic/files/subsonic/5.2/subsonic-5.2.deb
To install this deb file, we’ll use a program called dpkg. dpkg is the underlying software that drives apt-get. The reason we’re using dpkg over apt-get is because we’re installing a local file rather than a file that’s available in a repository. To install a local file using dpkg, use the “-i” parameter followed by the package name:
sudo dpkg -i subsonic-5.2.deb
And that’s all there is to it! Well, almost. Subsonic has a dependency that’s not included in the package: Java. Java is a popular programming language and is required for Subsonic to run. You can install the latest version of Java using:
sudo apt-get install default-jre-headless
There’s a good chance the Subsonic service failed when it couldn’t find Java, so we’ll restart the service:
sudo service subsonic restart
Unlike ownCloud, Subsonic doesn’t use Apache to host its webpages. Instead, it comes bundled with its own web server. However, since port 80, the traditional port for web servers, is being used by Apache, Subsonic defaults to port 4040 instead.
Instead of having to open a new port, you can take a somewhat sneakier approach by forwarding requests to Subsonic through Apache. This way, it will appear as if Subsonic is being hosted on port 80 even though it’s actually on port 4040.
Proxying Requests
Apache consists of several modules which act as extensions to the Apache server. One of these modules, mod_proxy, is just what we need to redirect incoming requests. Enable mod_proxy by typing the following command:
sudo a2enmod proxy proxy_http
Then restart the Apache service. Apache is now ready to proxy, but we still have to tell it what to proxy. Apache’s configuration file is in /etc/apache2, so we’ll cd there:
cd /etc/apache2
We’ll edit the main configuration file, apache2.conf, in nano:
sudo nano apache2.conf
Scroll down (or search) until you reach the end of the file (after the last IncludeOptional directive and before the line that starts with “# vim”). We’ll add our proxy rules here.
ProxyRequests Off
ProxyPreserveHost On
<Proxy *>
Order allow, deny
Allow from all
</Proxy>
ProxyPass /subsonic http://127.0.0.1:4040/subsonic
ProxyPassReverse /subsonic http://127.0.0.1:4040/subsonic
Whoa, hang on, what just happened?
First, we disabled ProxyRequests. ProxyRequests makes it appear as though requests going to the Internet from the internal network are coming from the proxy server. This may seem innocuous, but imagine if an attacker was able to masquerade his connections to appear as if they were coming from your server. We only need the proxy server to masquerade internal connections, so we’ll disable ProxyRequests.
ProxyPreserveHost will prevent some headaches when dealing with domain names later on. For now, it lets us ensure that Subsonic doesn’t confuse its own web server’s IP address (which is running on a special address known as localhost) with your server’s IP address.
The next four lines determine who has access to our proxy. We’ll allow anyone with access to the server to access the proxy. If you only want specific IP addresses to access the proxy – such as the local network – you can configure those restrictions here.
The final two lines define exactly how Subsonic is proxied. A normal URL is split into multiple components: the protocol used (e.g. http://), the host (e.g. google.com), and the full path to the resource (e.g. /mail). We’re telling Apache to create a /subsonic resource, then shuttle requests from that resource to the Subsonic server. You’ll see how this works shortly.
Once this is done, use the reload parameter to refresh Apache’s configuration without shutting down the web server.
sudo service apache2 reload
One final action: we need to change Subsonic’s configuration so that it’s aware of the /subsonic resource. You can find Subsonic’s configuration file at /usr/share/subsonic/subsonic.sh.
sudo nano /usr/share/subsonic/subsonic.sh
Find the SUBSONIC_CONTEXT_PATH line and change “/” to “/subsonic,” then restart the Subsonic service. You should now be able to navigate to “http://<server’s IP address>/subsonic.”
Red Flag: Subsonic Runs As Root
Remember all that fire and brimstone about the root user? Unfortunately Subsonic is a prime example of that: by default, the Subsonic process runs as root. To fix this, we’ll create a brand new subsonic user that only has access to the subsonic process and media directories.
To start, we’ll use the useradd command to create a subsonic user.
sudo useradd -r -U subsonic
The -r parameter specifies a system account, making it impossible to log in as the subsonic user. The -U parameter creates a corresponding subsonic group, of which the subsonic user is a member by default. The subsonic group lets you distribute a single permission set across multiple users. For instance, if you want to be able to directly modify folders owned by Subsonic, you can add your current user to the Subsonic group. This makes it possible to upload media directly to your server instead of through Subsonic’s web interface.
We’ll have to create the directories that Subsonic uses to store files, then modify them to accept the subsonic user and group. The mkdir command is prettt self-explanatory, and you’re already familiar with chown:
sudo mkdir /var/music /var/music/Podcast /var/playlists
sudo chown -R subsonic /var/music/ /var/playlists/
Finally, let’s tell Subsonic to run as the subsonic user instead of root. Open /etc/default/subsonic in your text editor and change the SUBSONIC_USER line from root to subsonic.
Restart the subsonic service. When the service reloads, it will read this configuration file and apply the changes. Now you can start adding media and stream files to your heart’s content! Click here for a short guide on getting started with Subsonic. You can upload music directly through Subsonic’s interface, or copy music directly to the server using SSH. If you run into permissions issues while uploading files, try adding your user to the Subsonic group using the following command:
sudo usermod -aG subsonic <user>
Good luck, and have fun!
Previous: Security and Remote Access
Next: Public Access, Advanced Networking, and Advanced Security
One thought on “Private Server Part 5: Web Hosting, ownCloud, and Subsonic”