The Node

Posts Tagged ‘server’

With the sad (and annoying) news that Google Reader is to be shut down on July 1st 2013, I had the dismal job of finding a replacement. Then I thought, why not just host my own RSS aggregator service? At least that way, I’m not at the whims of some corporation shutting down the services I use. So here, I’m going to show you how to set up tt-rss using Fedora Linux, Apache MySQL and PHP. This will allow you to import your Google Reader data into tt-rss’s MySQL database and display as a web application on your web server. There’s even an Android app to go with your installation to replace the Google Reader app. Hooray!

Okay, so I’m going to be using Apache, MySQL and PHP under Fedora Linux for this. If you already have Apache, MySQL and PHP installed, skip to the next section. If not, keep reading.

I’ll assume you’re on your Fedora Linux box as the root user for this. To install a basic Apache web server under Fedora with PHP and the libraries tt-rss will need, run the following: -

yum install apache mysql mysql-client php php-xml

Once all that is installed, start up your Apache installation with: -

service httpd start

In order to see web pages, you’ll also need to make sure your firewall is open on port 80. Fedora uses iptables as it’s firewall so let’s open a port for the web: -


iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 443 -j ACCEPT


If you’re planning on using an SSL certificate for HTTPS secure connections, you’ll need both commands. If not, you’ll just need the first one that opens port 80. For this (or any) web server to be useful you’ll also need to open the port(s) on your router’s firewall too. Check that your server is listening on the right port with: -

netstat -l | grep http

…which should give you back one or both ports listening as below: -

tcp6       0      0 [::]:http               [::]:*                  LISTEN
tcp6       0      0 [::]:https              [::]:*                  LISTEN

Check that you can reach your server’s ip address (ifconfig will tell you this) by opening a browser and pointing it to “http//your_ip_address”. If all is well, you now have Apache installed and running. To make sure that PHP is installed and working with Apache, create a test PHP page with the following: -

vi /var/www/html/test.php

and put in the following: -


< ?php
phpinfo();
?>


Browse to “http://your_ip_address/test.php” and check that you get the PHP diagnostics page up. If so, you’re ready to install tt-rss. But first, you need to export your Google Reader subscriptions while you still can! If you just want to set up tt-rss without importing from Google Reader, skip this step.

Log in to your Google Reader account here and go to Settings > Reader-Settings -> Import/Export. Click on “Download your data through Takeout” and then click on “Create Archive” which will allow you to download the zip file. Unzip it to a directory on your local hard drive.

Next you need to download tt-rss from the official website. As of the time of writing the current version is 1.7.2. I usually go to where I want it installed first, so: -

cd /var/www/html

..as this is the default location for your web pages, and run: -

wget https://github.com/gothfox/Tiny-Tiny-RSS/archive/1.7.2.tar.gz

If you don’t have wget installed under Fedora, install it with: -

yum install wget

Unpack the archive with: -


gunzip 1.7.2.tar.gz
tar -xf 1.7.2.tar


You should now have a subdirectory called tt-rss or similar. Change to that directory now.

Previously, you installed MySQL and now we need to set up a database under MySQL for tt-rss to store it’s information. If you already have MySQL installed, skip this step.

Start MySQL with: -

service mysql start

If you’ve not used MySQL before, it’ll prompt you to change the root user’s password. Do that now with: -

mysqladmin -u root password NEWPASSWORD

…where “NEWPASSWORD” is the password you want to use. Login to MySQL with: -

mysql -uroot -p

and enter your password. Next we need to set up a user for tt-rss for security’s sake. Run the following SQL: -

GRANT ALL PRIVILEGES ON ttrss.* TO 'rss'@'127.0.0.1' IDENTIFIED BY 'somepassword';

This will add a new MySQL user called “rss” which has complete access to all tables in the “ttrss” database. Their password is “somepassword”. Next, flush the tables with: -

FLUSH ALL PRIVILEGES

Next, we need to create the ttrss database. Do this with: -

CREATE DATABASE ttrss;

and then “exit” out of MySQL.

Try logging into your MySQL account with: -

mysql -urss -psomepassword

…noting the lack of spaces between the -u and -p for username and password respectively.If you can login and see your ttrss database by running: -

SHOW DATABASES;

…you are ready to go. Exit out of MySQL again and change to the schema directory under Apache where you installed tt-rss, usually something like: -

cd /var/www/html/tt-rss/schema

Next we need to import the database tables for MySQL for the tt-rss web application using the provided MySQL scheme SQL file.

mysql -urss -psomepassword ttrss < ttrss_schema_mysql.sql

This should import the tables to your previously created database using the MySQL user "rss" we just set up.

Once this is done, back up a directory level with: -

cd ..

Next we need to copy the default configuration file to something tt-rss can use, so run the following: -

cp config.php-dist config.php

Next, edit the file with vi and change the following directives to your settings: -

define('DB_TYPE', "mysql");
define('DB_HOST', "127.0.0.1");
define('DB_USER', "rss");
define('DB_NAME', "ttrss");
define('DB_PASS', "somepassword");
define('SELF_URL_PATH', "http://your_ip_address/tt-rss/");

Save this file and then try to browse to the URL defined in SELF_URL_PATH. You should be prompted to either unlock the permissions on certain directories or to login. The default username and password is “admin” with “password”. Remember to change them!

Before logging in, we need to choose a method of updating our feeds that we’ll import from the Google Takeout zip file we downloaded. There are two basic ways, via a daemon or via a cron job. The daemon way is recommended and can be done with: -

nohup php /var/www/html/tt-rss/update.php -daemon > /var/log/tt-rss.log &

Here, I’m running the process as a background process as the daemon doesn’t detach from the terminal. It’s recommended not to run this as the root user for security. Otherwise you can add a cron task for the current user with: -

crontab -e

and add the following entry: -

*/30 * * * * cd /var/www/html/tt-rss && /usr/bin/php /var/www/html/tt-rss/update.php -feeds >/dev/null 2>&1

Either way, your feeds will update every 30 minutes.

Okay, so now we need to import the Google Reader data. Login with the default username and password as outlined above. Once you’re logged in, click on Actions in the top right of the screen and then Preferences. Click on the Feeds tab and open the OPML button on the lower part of the screen. Choose the “subscriptions.xml” file you unzipped from the Google Takeout zip file – it’s under the “Reader” sub-directory.

Once you’ve imported your feeds from Google Reader you can now log in to your own server and read your RSS new like normal! Personally, I read a lot of Google Reader stuff on my Android phone, so let’s install the Android app next.

Click here to download and install the Android app for tt-rss. It’s a 7 day trial but the full version is only like £1.72. There are free versions available which you can find if you search the Play store for “ttrss” but I found them buggy. This works a charm.

Once installed, go to the Tiny Tiny RSS app and go to Settings and enter the following information: -

Login: your_tt-rss login - defaults to "admin".
Password: defaults to "password"
Tiny Tiny RSS URL: http://your_ip_address/tt-rss/

If you’re using HTTPS/SSL you’ll need to check the following if you’re using a self-signed SSL certificate.

Accept Any Certificate: Check
No Hostname Verification: Check

The app also has the ability to authenticate Apache Basic Authentication, which if you’re feeling paranoid can be set up here. Back out of this menu and refresh and your Google Reader feeds should start displaying.

Congrats, you now have the exact same Google Reader functionality from your own server :-) Take that Google!

I wonder what they’re going to replace Google Reader with? Something within Google Plus would be my bet.

Update 16/05/2013: You may get a 500 Internal Error under apache when you first start. The two most common reasons for this are your MySQL database is corrupted so delete and reimport your feeds or you don’t have the mbstrings PHP module. If you’re not using a version of PHP that you compiled yourself, you need to download the php-mbstring package. Under CentOS/Fedora, that is “yum install php-mbstring”.

Do you want to access your Ubuntu desktop from pretty much any device? VNC has got you covered. Using the VNC client/server software we can see what our Unity desktop is doing on Ubuntu from a suitable VNC client, in this case Android, but VNC client software exists for pretty much every platform including iOS, Windows and Ubuntu itself. VNC stands for Virtual Network Computing and it’s a graphical remote desktop sharing system that uses a special network protocol called RFB (if anyone is interested) to remotely control another computer via it’s normally displaying desktop much like Remote Desktop Connection under Windows. It transmits the keyboard and mouse events from one computer to another, relaying the graphical screen updates back in the other direction over the network. Very useful for operating systems like Windows and OSX but optional for Linux users with a good grasp of the command line interface and SSH :-)

In this example, we’re going to install and configure the VNC server software on our Ubuntu desktop and get it to automatically start at boot and access our Unity desktop (or Gnome Classic if you prefer) via the VNC client software that you can get for Android from the Google Play store. I’ll also show you how to access Ubuntu from another Ubuntu machine for completeness sake.

So let’s get started. First we need to install the VNC server software onto Ubuntu. I’m using 12.04 for this but the process shouldn’t have changed much for 12.10 as of time of writing.

So first let’s refresh our software repository cache and install a couple of gnome packages that are required for what we want to do.


sudo apt-get update
sudo apt-get install gnome-core gnome-session-fallback


Next, we install the VNC server itself: -


sudo apt-get install vnc4server


Right, now we’re going to start the VNC server using the default settings. We’ll change those in a minute. The reason for starting the server before we’ve actually configured it to be useful is because it’ll ask you for a default password. Enter one and remember it as this will be needed to sign into VNC later. This password can only accept 8 characters or less – anything longer than that will be truncated to 8 characters. Start the server with: -


vncserver


once you’ve entered your password, kill the default VNC server we started with: -


vncserver -kill :1


We’ll back up the default configuration for the VNC first before we do anything in case something breaks.

cp .vnc/xstartup .vnc/xstartup.backup

Now that we’ve safely got a backup file, we can edit the original with: -


vi ~/.vnc/xstartup


Edit the file so that it looks like this: -

#!/bin/sh

unset SESSION_MANAGER
unset DBUS_SESSION_BUS_ADDRESS
# exec /etc/X11/xinit/xinitrc
gnome-session --session=ubuntu-2d &

[ -x /etc/vnc/xstartup ] && exec /etc/vnc/xstartup
[ -r $HOME/.Xresources ] && xrdb $HOME/.Xresources
xsetroot --solid grey
vncconfig --iconic &

Notice the “gnome-session” directive’s session parameter which is set to “ubuntu-2d”. This is to show the Unity desktop. If you’re prefer to use Gnome Classic (and plenty don’t care for Unity), change that line so that it looks like this: -

gnome-session --session=gnome-classic &

Save that file and return to the command line. Since we’re going to be using an Android tablet to access this VNC installation, I’m going to set the desktop to a small resolution or 1024×768 although this can be anything you like depending on the size of the VNC client’s display. We’ll also use 16-bit colour depth as 32-bit doesn’t appear to display Unity’s launcher correctly from a VNC client and looking garbled. However, 32-bit will work with Gnome Classic’s GUI, so depending on what desktop session you’ve chosen use one of the following to start the VNC server: -


vncserver -geometry 1024x768 -depth 16


…or Unity or try 32-bit colour depth if you’re using Gnome Classic. You can always swap :-)


vncserver -geometry 1024x768 -depth 32


You can check the log for errors. The log file is stored in [USER_HOME_DIECTORY]/.vnc/[SERVER_HOSTNAME]:1.log where [SERVER_HOSTNAME] is the name of your Ubuntu machine.
If you have an error, you can kill the VNC server again with: -


vncserver -kill :1


…and check your xstartup config file for errors. If all looks good, VNC server should be running.
If you’re using Ubuntu’s firewall (and you should) you’ll need to open a port for the VNC server to listen for connections on. If you’re unsure if it’s running or not you can check the status of Ubuntu’s firewall with: -


sudo ufw status


If it’s active you’ll need to open a port. The default port for VNC server is 5901 so open that port with: -


sudo ufw allow 5901


Run the status command again and you should see that 5901 now has a rule of ALLOW. The VNC server is successfully running.

You might also want to add the following command to your /home/[USER]/.bash_profile file if you want VNC to start automatically upon your Ubuntu user login with by adding the following to your .bash_profile. This file doesn’t usually exist by default in Ubuntu but you can create it with vi with: -

vi ~/.bash_profile

Add the command line you used to start your VNC server with into this file and save it.

Next we’ll need to access this from an Android tablet (I’ll get to accessing Ubuntu via VNC from another Ubuntu machine in a moment). There are various VNC/RDP remote desktop clients on the Play store. I use Jump Desktop which is free for one VNC host. If you want more than one, you’ll have to pay a little bit, but for our purposes the free version is fine.

Download and install it on your Android device from the Play store. Fire it up and choose Manual Setup. Add a new connection with the following details: -

Address: [VNC_HOSTNAME] (IP address or hostname of the VNC server)
Type: VNC

Save this new connection and then you can change the Display name (“My VNC Server” or something) and more importantly, the port, Change the Host Address entry so that it reads: -

[VNC_HOSTNAME]:5901 

…rather than the default port of 5900. Back out of this menu and select the new host – you should be prompted for a password before connecting, this is the password you created initially. Jump Desktop allows you to use auto-login with this password if you prefer.

You should now be able to connect to your Ubuntu machine’s desktop. Hooray! If you want to connect to the VNC server from a different Ubuntu machine, you’ll have to install a VNC client for Ubuntu. I find that Ubuntu’s Remote Desktop Viewer works fine and can be installed with: -


sudo apt-get install xtightvncviewer


Start this up and click Remote->Connection to enter a new host. Again, use VNC as the thype of connection and I personally use Scaling and Fullscreen as well.

There you go. You can also get VNC server software for Windows if you want to access a Windows machine’s desktop from Ubuntu or Android. A good Windows VNC server is here.

I wouldn’t recommend running VNC over the Internet although obviously you’re free to. If you’re going to do that, I’d recommend using SSH tunnelling techniques to keep your communications secure.

Also it’s implied in this article that this is setting up a VNC session from an already running Ubuntu desktop session as the configuration file is specific to a server as is the running VNC server. System-wide, this ain’t. If you want a system-wide VNC server set up, you can look here for how to set that up. Personally I don’t use VNC outside of my home network as the only desktop I want to use is probably one already running in my study. If I need remote access to a machine, it usually isn’t for desktop purposes. For that I just use SSH :-)

Linux is great at logging almost any event that happens in the operating system and pretty much all of this stuff is stored under /var/log/messages. This is fine until a machine is compromised. If a hacker somehow manages to sneak into your server, pretty much the first thing they’ll do is erase the logs to cover their tracks. So while local logging is fine for spotting failed intrusion attempts, there is always the possibility that your server is breached and the logs won’t tell you anything because the intruder has access to those logs by definition.
The solution to this is to use a remote centralised Linux server to log the system logs from other systems. This way, when a system is breached, the hacker has no way of hiding their access as the logs are actually stored in real-time on another, uncompromised system. Some home routers from the likes of NetGear also have the option to store system logs to a remote syslog server. This can be useful for storing access events onto your home network for analysis as routers tend not to have much onboard storage for log files and almost certainly don’t survive between reboots.

Either way, I hope I’ve made the case for setting up a syslog server on your network. I’ll assume you have a spare Linux machine lying around with the minimum of SSH and iptables working. Pretty much any distribution will have all this working by default :-)

Configuring the syslog server

All your system logs are stored under /var/log and the daemon responsible for this is rsyslogd. You can see if it’s running on your system with:-

ps -elf | grep rsyslog

You’ll probably get something back like:-


4 S root 24457 1 0 80 0 - 7742 poll_s 12:23 ? 00:00:00 /sbin/rsyslogd -n -c 5


On newer Fedora releases that use systemd rather than the older traditional sysvinit, you can also check that rsyslogd is running with:-

service rsyslog status

to which you’ll get back the following detailed information about the running process from systemd.


Redirecting to /bin/systemctl status rsyslog.service
rsyslog.service - System Logging Service
Loaded: loaded (/lib/systemd/system/rsyslog.service; enabled)
Active: active (running) since Tue, 20 Mar 2012 12:23:35 +0000; 6min ago
Process: 24454 ExecStartPre=/bin/systemctl stop systemd-kmsg-syslogd.service (code=exited, status=0/SUCCESS)
Main PID: 24457 (rsyslogd)
CGroup: name=systemd:/system/rsyslog.service
└ 24457 /sbin/rsyslogd -n -c 5


The interesting part (aside from the fact that it’s running!) is the last line, this one:-

/sbin/rsyslogd -n -c 5

This shows you what parameters are being passed to rsyslogd when it starts with the system. From this, we can tell by using “man rsyslogd” that -n means that the rsyslogd daemon will avoid auto-backgrounding which makes sense as the process is managed by init or in this case, systemd. The -c parameter allows backwards compatibility…in this case, version 5.0. I assume again that this is something to do with systemd which probably has something different “under the hood”. Anyway, nothing very interesting there. You might notice from the man pages that there is a -r parameter which allows logging from remote sources. This is what we want, so we need to know how to set rsyslogd’s parameters upon start up. This is done via the config file. So edit it with:-

vi /etc/sysconfig/rsyslog

…under RedHat/Fedora and:-

vi /etc/init.d/sysklogd

…under Ubuntu/Debian.

The contents of the file is pretty sparse, consisting just of the line:-

SYSLOGD_OPTIONS="-c 5"

Here is where we set our remote switch, so change it so it reads:-

SYSLOGD_OPTIONS="-r -c 5"

Depending on your distribution, your SYSLOGD_OPTIONS parameters might look a little different – this doesn’t matter, the important part is that you’ve added the “-r” switch to the options. Save this file. Next you need to configure the daemon to listen on UDP port 514 for external syslog messages. So open the following file:-

vi /etc/rsyslog.conf

Look for the section near the top that looks like this:-


# Provides UDP syslog reception
#$ModLoad imudp
#$UDPServerRun 514


Uncomment these two lines by removing the hash character at the beginning. This simply says to listen on UDP port 514 for connections.

Save this file and restart rsyslogd with:-

service rsyslog restart

…under RedHat/Fedora and:-

/etc/init.d/sysklogd restart

Remember you’ll need to also open a port for incoming syslog information from remote clients. rsyslogd uses UDP port 514 for this, so make sure you’ve added the port to the iptables firewall with something like:-

iptables -A INPUT -m state --state NEW -m udp -p udp --dport 514 -j ACCEPT

If you want to lock down the firewall access a little more than that, you could use something like:-

iptables -A INPUT -p udp -i eth0 -s 192.168.1.2 -d 192.168.1.1 --dport 514 -j ACCEPT

This rule will ensure that the syslog server on IP address 192.168.1.1 will receive UDP packets containing the system log events from the remote client on IP address 192.168.1.2. Obviously replace these with the correct IP addresses for your network.

Once everything is set up, you can check that your syslog server is listening on the intended port with:-

netstat -an | grep 514

…which should give you this:-


udp 0 0 0.0.0.0:514 0.0.0.0:*
udp 0 0 :::514 :::*


If you’re using a NetGear router and want to log it’s information to your server, you’re now set up to point your router logs to your server. If you’re wanting to log system events from another Linux client on your network to the syslog server, these also need to be configured to log their stuff remotely rather than to /var/log/messages.

Configuring the syslog client

On each system that will log to the syslog server you’ve just set up, you need to configure it to log there rather than to it’s own /var/log directory. Add the file “/etc/syslog.conf” if it doesn’t already exist and add the line at the top of the file:-

*.* @192.168.1.1

…where the 192.168.1.1 IP address is the IP address of your syslog server. Change as appropriate. Finally, restart the syslog daemon on the client with:-

service syslog restart

Remember again that you’ll need to add an outgoing rule to your firewall to allow the 514 port-destined syslog traffic to your syslog server. Here is the iptables rule: -

iptables -A OUTPUT -p udp -i eth0 -s 192.168.1.2 -d 192.168.1.1 --dport 514 -j ACCEPT

If the client is an Ubuntu box, you won’t be using iptables, but ufw. The article on how to use Ubuntu’s firewall can be found here.

The client’s logs (or your router’s, if you have that functionality) will now be written to the syslog server’s /var/log/messages system log.

Minecraft is one of the first major success stories for indie gaming this decade and frankly, when I thought hard about it, the potential of this game is really amazing. If you’ve been living in a cave for the past year then here is the general gist…

Minecraft is a game about blocks. The world is made of blocks, the water and…well…everything. The game is an FPS with a curiously charming 8-bit asthetic. I’m not sure if there is a story or not and really, it’s irrelevant. It’s really hard to explain, so I’ll let Wikipedia explain it for me.

Since this game is written in Java with the OpenGL-binding Light-Weight Java Game Library (LWJGL), it’ll run on pretty much any computer. Minecraft being grass-roots project, comes in two flavours – Classic and Beta. Minecraft is notable in that, although the game is for sale, it isn’t actually finished yet. Classic is the free version which you can either download as a Java ARchive for (OSX and Linux) or the executable (Windows). If you fancy buying it, it’s very cheap – about £12.79 or 14.95 Euros. I will say that it seems stable enough on the several systems I’ve tried it on and since you have to register in order to purchase, your login details are used to update the game whenever you’re online so you get constant updates.

For running Minecraft under Linux, you will of course need the Java Runtime Environment installed from Java’s new overlords, Oracle. While you can run the Apache Foundation’s OpenJDK (apparently getting a new lease of life due to Oracle’s bitter battle with Google over Android and Java licensing) it’s recommended that you run the official Sun JRE for now and performance on the beta isn’t silky-smooth. If you’ve already got the JRE installed, skip to the next bit. I’ll go into the process of installing the JRE in rather more detail than is necessary as eventually I’ll go through how to install the Java Development KIt (JDK) as this will be required for Android development stuff. But that’s another article….:-)

I’d recommend the non-RPM download for Linux, simply because not everyone here will be using a Red Hat-based system. Once you’ve downloaded the BIN file, you’ll need to su to root and move the file to the location you want it. I usually put the JRE in /usr/local.

Once you’ve moved it, you’ll need to make it executable with the command:-

chmod u+x jre-6u24-linux-i586.bin

Now run the installer with: -

./jre-6u24-linux-i586.bin

Click through the legalese, and the file will be uncompressed to /usr/local/jre-6u24 or something similar. I usually bung in a symbolic link here to a shorter directory path using: -

ln -s /usr/local/jre-6u24 /usr/local/jre

As we want the JRE to be available system-wide, we’re going to add the JRE to the system path environment variable. You’ll still need to be root to do this.

First, edit the file /etc/profile (under Fedora) or /etc/environment under Ubuntu.

vi /etc/profile or vi /etc/environment

Add the line somewhere near the bottom where the $PATH environment variable is declared. After this, put in the line:-

export PATH="/usr/local/jre/bin:$PATH"

This has appended the /usr/local/jre/bin directory where the Java interpreter executable resides to the system path. Save this and logout of root. Log back in and type: -

echo $PATH

You’ll see the JRE path has been added to the variable. Right – ready to run Minecraft! :-)

EIther download the Classic version, or signup and buy the Beta. I bought the Beta and haven’t regretted it. Either way, you’ll end up with a Minecraft.jar file. As the official Minecraft site states, run the game with: -

java -Xmx1024M -Xms512M -cp Minecraft.jar net.minecraft.LauncherFrame

This looks complex, but all it’s actually doing is assigning more memory than the default to the JVM. Put this line into a bash script file called “start.sh” or something if you prefer…

And you should now be able to start playing Minecraft! Build a shelter before nightfall and refer to the Minecraft Wiki if you need help or instructions.

Right, now one of the cool things you can do with Minecraft is set up a multiplayer server. This creates a Minecraft world on your server that anyone can login to and build (or destroy) anything. Good for co-op battle against zombies or collaberative building :-)

To install the Minecraft server software, download the Linux server software JAR here. Put it somewhere logical (me, I put it in /usr/local somewhere) and load it with: -

java -Xmx1024M -Xms1024M -jar minecraft_server.jar nogui

This will load everything and also create a file called server.properties. This is simply a text file that has the default settings for your Minecraft server and can be edited with vi or similar to change any settings. You’ll need to restart the server for the settings to take effect.


#Minecraft server properties
level-name=MyMineCraftServer
hellworld=false
spawn-monsters=true
online-mode=true
spawn-animals=true
max-players=20
server-ip=
pvp=true
server-port=25565
white-list=false


As you can see, the default port for the Minecraft server is 25565 – you’ll need to open a TCP port for this in your iptables firewall: -

iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 25565 -j ACCEPT

Also, if you’ve got a static IP address, you’ll want to open an identical port in your router firewall and NAT the port to your server.

If you’ve changed any settings in the server.properties file, you’ll need to search for the process and kill it.

ps -elf | grep java

Make a note of the process ID (PID) and kill it with: -

kill [PID]

Load up your Minecraft client and select multiplayer from the menu and type in your hostname or IP of your server. Note: I really wouldn’t recommend running the server and client software on the same machine! The Minecraft server software, being Beta grade, needs a good 1GB of RAM to run and I really wouldn’t recommend less than that, especially for 10 or 20 players all at once. Now you can build stuff with friends!
A list of server commands can be found here – although I’m running the software as a background process, so don’t know if I can bring it to the foreground without killing the service :-)

Markus “Notch” Persson, Minecraft’s creator has quit his day job to work on Minecraft and has this to say about the future.

I plan on developing Minecraft until it’s a finished complete game, with a downloadable client (with fullscreen mode), custom key re mappings and possibly modding support.
For as long as people enjoy and purchase the game, I will develop extensions after the game is done.

Once sales start dying and a minimum time has passed, I will release the game source code as some kind of open source. I’m not very happy with the draconian nature of (L)GPL, nor do I believe the other licenses have much merit other than to boost the egos of the original authors, so I might just possibly release it all as public domain.

Minecraft has built up a really strange and cool subculture based on building things in Minecraft. Go to YouTube and type in “minecraft” to come up with a great load of user-created content. The guys over at Linux Outlaws also have a dedicated Minecraft server set up at alain.sixgun.org.

Also, you’ll be pleased to hear that Minecraft is coming to Android! :-) You can even use mineserve which is a server-side app plus an Android app that lets you admin your Minecraft server from your phone. Neat eh?

Server security no matter what operating system you’re using is a big deal. It may not be such a huge deal for a home server or, depending on your data, it may be a very big deal. Today, I’m going to talk about various things you can do to improve your server’s security. I say improve because, as everyone should know, if a hacker is determined enough, they will eventually compromise your system. Fortunately, I doubt your home server is important enough to anyone to have to withstand that sort of sustained attack, but it never hurts to use some common sense and secure your system as best you can. Here I will touch on various things you can do to at least keep your system secure from the kind of casual penetration attempts that will happen if your machine is connected to the wild n’ wooley Internet.I will stress here that I am not an expert on server security, I simply employ a little common sense to prevent most casual attempts to hack into my system. Hopefully this stuff will at least perk your interest enough to look into your own security setup and how you might improve it. Please note that I use Fedora for all examples given, but it shouldn’t be too hard to change for other distributions.

The first thing to do is to use really strong passwords. By this I mean passwords that are difficult to guess, so nothing that is the name of your dog, birthdays, family members or anything that somebody might logically try to use that they might find on social networking sites or Google or anything like that. While shadowed password files now mean that any user on the system cannot just filch the /etc/passwd file and run a brute force attack to get the root password, brute force programs can still run against common accounts with dictionary words over and over in the hopes of guessing the password. And obviously the root user is the one account that is guaranteed to be present on your system. So don’t use dictionary words as passwords. Best practice is to use a long password with a mixture of letters and numbers of various cases, but not something obtuse enough that you cannot remember it.

Remember only to expose system accounts to the wider Internet that you need. For example, you might want to disable remote access to your root account and use a nice strong password for your user account. Not only does an attacker need to guess your user account name, but also the password – while the root account as mentioned before is bound to be on your system. To disable the root account from being accessed remotely via SSH, you can edit the sshd_config file and disable root login: -

vi /etc/ssh/sshd_config

Add the following line: -

PermitRootLogin no

You’ll need to restart your SSH daemon for this change to take effect.

/etc/rc.d/init.d/sshd restart

When you now try to login via SSH as root, you’ll get an Access Denied error. The next thing you can do is to run SSH on a non-standard port. SSH normally runs on port 22. To make things a little difficult for a hacker, you can run SSH on any port, although it’s a good idea to use one above 1024 so that it doesn’t interfere with standard network services that might run on ports below that. To do this, edit your /etc/ssh/sshd_config again and edit the line: -

Port 22

…to be a different port, such as 47002 for example. As above, make sure you restart your SSH daemon for this change to take effect. While we’re here, this is a good place to talk about iptables – a common Linux firewall. Once you have changed your SSH default port, you will obviously have to change the firewall port associated with SSH so that you can still accept SSH connections remotely to your machine. I like to have a default set of basic ports open to the outside world kept in a file called “/etc/sysconfig/iptables.BACKUP”. The way to create this file is to edit the “/etc/sysconfig/iptables-config” and add the following line: -


IPTABLES_SAVE_ON_STOP="yes"


When you next stop or restart iptables with: -

/etc/rc.d/init.d/iptables restart

the file “/etc/sysconfig/iptables” will be created. This is a list of all ports that iptables keeps open. It’s nice to have a backup of your iptables configuration as it’s easily editable if you want to open/close other ports. So copy this file to your backup file with: -

cp /etc/sysconfig/iptables /etc/sysconfig/iptables.BACKUP

This file has entries such as: -


-A INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 47001 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 47002 -j ACCEPT


In the above example, ports 80 (HTTP), 47001 and 47002 are open. You can add comments to this file with the ‘#’ to remind yourself which ports are open for which services and add others as need be to your .BACKUP file. You then have a nice safe “baseline” iptables configuration for your system which you can copy to the “/etc/sysconfig/iptables” file and simply restart iptables for this firewall configuration to take effect with: -


cp /etc/sysconfig/iptables.BACKUP /etc/sysconfig/iptables
/etc/rc.d/init.d/iptables restart


Only the ports defined in the “/etc/sysconfig/iptables” file are opened on iptables start/restart. Prevents you needing to add ports on the fly with your iptables command! I find it very handy as I know only the ports open in this file are actually open on system reboot and I can customise it as needed.

You should essentially have two firewalls on your system – your router firewall which exposes ports onto your home network to the wider Internet and your server firewall itself. For example, I might have the Samba service open on my Linux server to expose Samba services to my local area network, but I wouldn’t open these ports on my router firewall because I don’t want the wider Internet to access my Samba services. Likewise, I would possibly have ports open for SSH on both my Linux server firewall and my router firewall because I want SSH to be available from the wider Internet so I can access my Linux server remotely. And remember to change the default password on your router web admin screen – hackers love accessing your router with well-known default router passwords – default passwords are available on the Web for most common makes and models. I’m actually surprised that the ISPs never ever mention to do this.

That covers the basics of iptables, user accounts, root access and passwords. Next time, I’ll talk about different services you can use to strengthen the security of your system.

FTP or File Transfer Protocol has been around almost as long as the Internet itself. It’s rarely used anymore, having been superseded by more secure file transfer protocols such as SFTP (FTP over SSH). However, it is still worth knowing about FTP and how to set up your Linux server to support it should you want to. The easiest FTP daemon to run on modern distributions is vsFTPd or Very Secure File Transfer Protocol Daemon.

First, of course, you need to make sure you’ve got the vsFTPd daemon installed on your system. Under Fedora, you can install it with: -

yum install vsftpd

Under Ubuntu, you can install it with: -

sudo apt-get install vsftpd

Once this is done, you have to configure it for use. The location of the configuration file is usually in /etc/vsftpd/vsftpd.conf, but you might find it under /etc/vsftpd.conf under certain Debian-basd distributions.

You may want anonymous logins and simple downloading ability for your FTP server, in which case you’d add the following directives to your vsftpd.conf file:-


anonymous_enable=YES
write_enable=NO


This gives anonymous, download only FTP services. However, at least for me, it’s more useful to enable local users with write access using something like: -


anonymous_enable=NO
write_enable=YES
local_enable=YES
chroot_local_user=YES


You may want more finite control over uploads to your FTP. You can set specific users to have either read-only access under vsFTPd or both read and write. Although the vsftpd.conf file only has “write_enable=YES/NO”, which applies to all users regardless, you can stop file deletions from a directory by removing write permission from the directory itself – normal Linux permissions should work fine for vsFTPd.

This allows user with regular shell accounts to FTP into their home directories and upload/download files. However, the “chroot_local_user=YES” directive means that they cannot use FTP to browse the local file system outside of their own directory, which is a good measure. For example, in a normal FTP client program, you couldn’t click on “parent directory” and start wandering around the file system – always a good security measure and prevents exposing your file system to any FTP users you may have – doubly so if you’re enabling anonymous FTP access.


chroot_local_user=YES
chroot_list_enable=NO


The above enforces a chroot jail for all users. But sometimes, you may want to just have a chroot jail for some users and not others. If you add the following directive, this will enable selective chroot jails.


chroot_local_user=NO
chroot_list_enable=YES


If you then create the file /etc/vsftpd/vsftpd.chroot_list (/etc/vsftpd.chroot_list for Debian users) with a list of the jailed users, one per line, only those users are chrooted by default.

The other option you might want is to allow only some system users to login to FTP. This can be achieved with: -


userlist_deny=YES
userlist_file=/etc/vsftpd/vsftpd.denied_users


If you then create the file “vsftpd.denied_users” with a list of users which are not allowed to login, only users not present on this list will have FTP access.

Since we’re sort of talking about security here, I think it’s a good idea to have a dedicated FTP user. One created without a shell login. FTP is a rich and obvious target for hackers and if by chance, the FTP user is compromised, this won’t give somebody shell access to your Linux server. Assuming you login to your Linux shell account with SSH (as you should if you don’t – Telnet is not very secure these days), you can edit your SSH configuration to deny shell access to yor FTP user.


vi /etc/ssh/sshd_config


and add the following: -


DenyUsers ftpuser1 ftpuser2


…and so on. If your FTP server is going to connect to the Internet, it’s also wise to enable encryption for your FTP connections too with something like: -


ssl_enable=YES
allow_anon_ssl=NO
force_local_data_ssl=NO
force_local_logins_ssl=NO
ssl_tlsv1=YES
ssl_sslv2=YES
ssl_sslv3=YES
rsa_cert_file=/etc/vsftpd/vsftpd.pem


There is no need to create an SSL certificate for this. vsFTPd uses the certificate Linux creates upon installation, the “snake-oil” certificate used by the OpenSSL package, which saves time and energy.

Depending on how you anticipate people accessing your FTP server, it’s a good idea to have passive connections enabled – this can sometime help prevent connection errors when attempting to list the contents of directories, especially if you think you’ll be accessing the FTP via a browser using ftp:// instead of http:// – this happened to me to start with, so it appears to be a good idea :-)


pasv_enable=YES
pasv_promiscuous=YES
pasv_min_port=25000
pasv_max_port=25004


Additional directives you might find useful for the vsftpd.conf file are: -


# Show hidden files and the "." and ".." folders.
force_dot_files=YES

# Hide the info about the owner (user and group) of the files.
hide_ids=YES

# Connection limit for each IP.
max_per_ip=2

# Maximum number of connecting clients
max_clients=20


Once you’ve setup vsFTPd how you want it, you’ll need to start the vsFTPd server.


service vsftpd start


You can also have vsFTPd start on boot by using the chkconfig command.


chkconfig --level 345 vsftpd on
chkconfig --list vsftpd
vsftpd 0:off 1:off 2:on 3:on 4:on 5:on 6:off


vsFTPd is now enabled for runlevels 2, 3, 4 and 5. The last thing to do is to add some rules to your iptables firewall configuration as otherwise you’ll have a hard time connecting!


iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 20 -j ACCEPT
iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 21 -j ACCEPT
iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT


You may also need to add the following iptables modules to your /etc/sysconfig/iptables-config file which allow passive mode FTP from behind iptables firewalls without having those ports exposed to the outside world (ie. having to open those ports): -


IPTABLES_MODULES="nf_conntrack_ftp"
IPTABLES_MODULES="ip_nat_ftp"


Obviously, you’ll need to add NAT rules to your router as well to forward connections from the outside world on these ports to your FTP server, but since the way to do that for each model of router varies, I won’t be discussing that here.

You can then access your new FTP server either through your browser with ftp://yournamename.com or through an FTP client, such as command line tools included in almost all *nix operating systems or Windows: -


ftp yourhostname.com


If you’re using a command-line FTP client, you might find a list of FTP commands useful.

Well, that’s a quick overview of vsFTPd’s configuration and features – I hope you enjoyed it :-)