All posts tagged vps

After a long hard day, it looks like I am all restored now. I was waiting to get some time on my hand to switch servers. My time with the AWS has been bittersweet. Thanks for the sweet deal I was able to keep my website up for free for a good time (10 months?).

Although I won’t really recommend using anyone to go with their base EC2 server which is obviously the only server that you can get for free. I was constantly running out of RAM and server would just shut down. There’s even to SWAP partition which really makes the server run on fumes!

I am getting much better pings now. Have no outage and the resource utilization is average as well. This for now looks to be the better choice now.

Finally added the much-needed SSL certs to the site and we are running exclusively on HTTPS. Yay!


Ironed out a lot of CSS issues. Although there are still some issues I would like to fix but I’m happy with the day’s worth of effort!

Better pings, here I come!

So I finally decided to take my server online but not without a few hiccups.

The problem is I wanted to begin with mLabs but somehow my firewall was blocking it. So I decided to host it on my server and connect directly into it.

Installing it was not a problem. If you are used to Ubuntu or a linux OS, you would be very familiar with it. Although you would need to add few firewall rules as you don’t want everyone to access your instance remotely. So at the end we will add our own IP to the firewall rule.


Step 1 — Adding the MongoDB Repository

MongoDB is already included in Ubuntu package repositories, but the official MongoDB repository provides most up-to-date version and is the recommended way of installing the software. In this step, we will add this official repository to our server.

Ubuntu ensures the authenticity of software packages by verifying that they are signed with GPG keys, so we first have to import they key for the official MongoDB repository.

  • sudo apt-key adv –keyserver hkp:// –recv EA312927

After successfully importing the key, you will see:


Next, we have to add the MongoDB repository details so apt will know where to download the packages from.

Issue the following command to create a list file for MongoDB.

  • echo “deb xenial/mongodb-org/3.2 multiverse” | sudo tee /etc/apt/sources.list.d/mongodb-org-3.2.list

After adding the repository details, we need to update the packages list.

  • sudo apt-get update

Step 2 — Installing and Verifying MongoDB

Now we can install the MongoDB package itself.

  • sudo apt-get install -y mongodb-org

This command will install several packages containing latest stable version of MongoDB along with helpful management tools for the MongoDB server.

In order to properly launch MongoDB as a service on Ubuntu 16.04, we additionally need to create a unit file describing the service. A unit file tells systemd how to manage a resource. The most common unit type is a service, which determines how to start or stop the service, when should it be automatically started at boot, and whether it is dependent on other software to run.

We’ll create a unit file to manage the MongoDB service. Create a configuration file named mongodb.service in the /etc/systemd/system directory using nano or your favorite text editor.

  • sudo nano /etc/systemd/system/mongodb.service

Paste in the following contents, then save and close the file.


This file has a simple structure:

  • The Unit section contains the overview (e.g. a human-readable description for MongoDB service) as well as dependencies that must be satisfied before the service is started. In our case, MongoDB depends on networking already being available, hence here.
  • The Service section how the service should be started. The User directive specifies that the server will be run under the mongodb user, and the ExecStart directive defines the startup command for MongoDB server.
  • The last section, Install, tells systemd when the service should be automatically started. The is a standard system startup sequence, which means the server will be automatically started during boot.

Next, start the newly created service with systemctl.

  • sudo systemctl start mongodb

While there is no output to this command, you can also use systemctl to check that the service has started properly.

  • sudo systemctl status mongodb

The last step is to enable automatically starting MongoDB when the system starts.

  • sudo systemctl enable mongodb

The MongoDB server now configured and running, and you can manage the MongoDB service using the systemctl command (e.g. sudo systemctl mongodb stop, sudo systemctl mongodb start).

Step 3 — Adjusting the Firewall (Optional)

Assuming you have followed the initial server setup tutorial instructions to enable the firewall on your server, MongoDB server will be inaccessible from the internet.

If you intend to use the MongoDB server only locally with applications running on the same server, it is a recommended and secure setting. However, if you would like to be able to connect to your MongoDB server from the internet, we have to allow the incoming connections in ufw.

To allow access to MongoDB on its default port 27017 from everywhere, you could use sudo ufw allow 27017. However, enabling internet access to MongoDB server on a default installation gives unrestricted access to the whole database server.

in most cases, MongoDB should be accessed only from certain trusted locations, such as another server hosting an application. To accomplish this task, you can allow access on MongoDB’s default port while specifying the IP address of another server that will be explicitly allowed to connect.

  • sudo ufw allow from your_other_server_ip/32 to any port 27017

You can verify the change in firewall settings with ufw.

  • sudo ufw status

You should see traffic to 27017 port allowed in the output.If you have decided to allow only a certain IP address to connect to MongoDB server, the IP address of the allowed location will be listed instead of Anywhere in the output.


More advanced firewall settings for restricting access to services are described in UFW Essentials: Common Firewall Rules and Commands.


Now we have successfully installed the DB on our server. The second part is how to access it. 

You can’t just use the direct IP and login. What we will do is SSH into our VPS and connect as a localhost. Simple 🙂


In the “Connection” panel:
Address – localhost
Port – 27017


in the “SSH” panel:
Address – <your_ip_or_fqdn>:22
and use a private key auth or your password.


This will connect via port 22 and redirect traffic sent to port 27017

Mongo on your droplet is set to respond only to traffic from localhost which is where the ssh tunnel comes in handy. Running db.serverCmdLineOpts() from the mongoshell will tell you what it is bound to.


There is another “LESS” secure way to connect which I don’t recommend. But if you are dev testing your app to your remote server, this might be the way to go.

You need to change the Bind IP option

Bind IP is a MongoDB option that restricts connections to specifics IPs.

Have a look at your mongod configuration file, most of the time bind.ip is set to for obvious security reasons. You can:

  1. Add your desired IP by concatenating a list of comma separated values to bind MongoDB to multiple IP addresses.
  2. Remove or comment (with # character) the bind_ip line. But be aware that all remote connection will be able to connect your MongoDB server!

More about bind_ip configuration option:

Bind IP can also be set as a command argument:–bind_ip

SSH into your server:

nano /etc/mongod.conf

Comment your bindIp snippet in the file. This is how it should look now:

network interfaces
port: 27017
# bindIp:


You can also add your specific IP to bind IP. This actually is the better way to do it. As you will only be able to access it from your machine/IP. Change it to look like this:

network interfaces
port: 27017
# bindIp:,your_ip_address_goes_here


How To Use Cron To Automate Tasks On a VPS


One of the most standard ways to run tasks in the background on Linux machines is with cron jobs. They’re useful for scheduling tasks on the VPS and automating different maintenance-related jobs. “Cron” itself is a daemon (or program) that runs in the background. The schedule for the different jobs that are run is in a configuration file called “crontab.”


Almost all distros have a form of cron installed by default. However, if you’re using a system that doesn’t have it installed, you can install it with the following commands:

For Ubuntu/Debian:

For Cent OS/Red Hat Linux:

You’ll need to make sure it runs in the background too:


Here is an example task we want to have run:

The syntax for the different jobs we’re going to place in the crontab might look intimidating. It’s actually a very succinct and easy-to-parse if you know how to read it. Every command is broken down into:

  • Schedule
  • Command

The command can be virtually any command you would normally run on the command line. The schedule component of the syntax is broken down into 5 different options for scheduling in the following order:

  • minute
  • hour
  • day of the month
  • month
  • day of the week


Here is a list of examples for some common schedules you might encounter while configuring cron.

To run a command every minute:

To run a command every 12th minute on the hour:

You can also use different options for each placeholder. To run a command every 15 minutes:

To run a command every day at 4:00am, you’d use:

To run a command every Tuesday at 4:00am, you’d use:

You can use division in your schedule. Instead of listing out 0,15,30,45, you could also use the following:

Notice the “2-6” range. This syntax will run the command between the hours of 2:00am and 6:00am.

The scheduling syntax is incredibly powerful and flexible. You can express just about every possible time imaginable.


Once you’ve settled on a schedule and you know the job you want to run, you’ll have to have a place to put it so your daemon will be able to read it. There are a few different places, but the most common is the user’s crontab. If you’ll recall, this is a file that holds the schedule of jobs cron will run. The files for each user are located at /var/spool/cron/crontab, but they are not supposed to be edited directly. Instead, it’s best to use the crontab command.

You can edit your crontab with the following command:

This will bring up a text editor where you can input your schedule with each job on a new line.

If you’d like to view your crontab, but not edit it, you can use the following command:

You can erase your crontab with the following command:

If you’re a privileged user, you can edit another user’s by specifying crontab -u <user> -e


For every cron job that gets executed, the user’s email address that’s associated with that user will get emailed the output unless it is directed into a log file or into /dev/null. The email address can be manually specified if you provide a “MAILTO” setting at the top of the crontab. You can also specify the shell you’d like run, the path where to search for the cron binary and the home directory with the following example:

First, let’s edit the crontab:

Then, we’ll edit it like so:

This particular job will output “Run this command every minute.” That output will get emailed every minute to the “” email address I specified. Obviously, that might not be an ideal situation. As mentioned, we can also pipe the output into a log file or into an empty location to prevent getting an email with the output.

To append to a log file, it’s as simple as:

Note: “>>” appends to a file.

If you want to pipe into an empty location, use /dev/null. Here is a PHP script that gets executed and runs in the background.

Restricting Access

Restricting access to cron is easy with the /etc/cron.allow and /etc/cron.deny files. In order to allow or deny a user, you just need to place their username in one of these files, depending on the access required. By default, most cron daemons will assume all users have access to cron unless one of these file exists. To deny access to all users and give access to the user tdurden, you would use the following command sequence:

First, we lock out all users by appending “ALL” to the deny file. Then, by appending the username to the allow file, we give the user access to execute cron jobs.

Special Syntax

There are several shorthand commands you can use in your crontab file to make administering a little easier. They are essential shortcuts for the equivalent numeric schedule specified:

  • @hourly – Shorthand for 0 * * * *
  • @daily – Shorthand for 0 0 * * *
  • @weekly – Shorthand for 0 0 * * 0
  • @monthly – Shorthand for 0 0 1 * *
  • @yearly – Shorthand for 0 0 1 1 *

and @reboot, which runs the command once at startup.

Note: Not all cron daemons can parse this syntax (particularly older versions), so double-check it works before you rely on it.

To have a job that runs on start up, you would edit your crontab file (crontab -e) and place a line in the file similar to the following:

This particular command would get executed and then emailed out to the user specified in the crontab.