Automatic Updates on Ubuntu

Automatic updates are highly recommended.  Configuring your systems to update their packages automatically improves stability, performance, and most importantly the security of those systems.  The unfortunate nature of software development is that exploits can be discovered or bugs found after release.  Updates allow developers to correct these bugs and close exploits, which is why they are highly recommended.  Setting up automatic updates means the system will update periodically and not need you to check for and install updates manually, ensuring you are kept up to date during an OS’s life-cycle.

Automatic Updates on Ubuntu via unattended-upgrades

On Ubuntu, automatic updates are facilitated by the unattended-upgrades package.  Install the package with the following command.

sudo apt install unattended-upgrades

This will install the unattended-upgrades package with a default configuration.  By default, the unattended-upgrades package installs updates for security packages only.  You can change this by editing the configuration file for the package, which should be located at etc/apt/apt.conf.d/50unattended-upgrades.  An example default of the package selection area of this file is shown below:

Unattended-Upgrade::Allowed-Origins {
        "${distro_id}:${distro_codename}";
        "${distro_id}:${distro_codename}-security";
//      "${distro_id}:${distro_codename}-updates";
//      "${distro_id}:${distro_codename}-proposed";
//      "${distro_id}:${distro_codename}-backports";
};

Lines starting with a // are commented out.  You can simply remove these slashes to enable additional packages for automatic updates.  Enabling the “-updates” line will allow unattended-upgrades to keep your normal non-security packages also up-to-date, and as such is recommended.

You can also black-list specific packages that you do not want to be updated.  It is recommended to avoid this feature as it can lead to instability and security concerns.  However, there are cases where it may be necessary to hold a package at a certain version to ensure compatibility or similar reasons.  You can do so by simply adding the package to the black-list.  An example that tells the system to not update vim is provided below.

Unattended-Upgrade::Package-Blacklist {
      "vim";
};

Finally, you can adjust the frequency of the automatic updates in a configuration file which should be at /etc/apt/apt.conf.d/20auto-upgrades.  This file shows the frequency in days of the various portions of the update process.

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Download-Upgradeable-Packages "1";
APT::Periodic::AutocleanInterval "7";
APT::Periodic::Unattended-Upgrade "1";

In this example, unattended-upgrades will grab a fresh package list every day.  It will also download and install upgrades every day, and clean up the download archive for packages every 7 days.  You can adjust these values as desired, but the default configuration should work for almost all systems.  It is recommended to keep the Update-Package-Lists, Download-Upgradable-Packages, and Unattended-Upgrade values in sync, as these generally should be run in sequence for updates.

Automatic Updates on Debian

Automatic updates are highly recommended.  Configuring your systems to update their packages automatically improves stability, performance, and most importantly the security of those systems.  The unfortunate nature of software development is that exploits can be discovered or bugs found after release.  Updates allow developers to correct these bugs and close exploits, which is why they are highly recommended.  Setting up automatic updates means the system will update periodically and not need you to check for and install updates manually, ensuring you are kept up to date during an OS’s life-cycle.

Automatic Updates on Debian via unattended-upgrades

On Debian, automatic updates are facilitated by the unattended-upgrades package.  Install the package with the following command.

sudo apt install unattended-upgrades

This will install the unattended-upgrades package with a default configuration.  By default, the unattended-upgrades package installs updates for security packages only.  You can change this by editing the configuration file for the package, which should be located at etc/apt/apt.conf.d/50unattended-upgrades.  An example default of the package selection area of this file is shown below:

Unattended-Upgrade::Allowed-Origins {
        "${distro_id}:${distro_codename}";
        "${distro_id}:${distro_codename}-security";
//      "${distro_id}:${distro_codename}-updates";
//      "${distro_id}:${distro_codename}-proposed";
//      "${distro_id}:${distro_codename}-backports";
};

Lines starting with a // are commented out.  You can simply remove these slashes to enable additional packages for automatic updates.  Enabling the “-updates” line will allow unattended-upgrades to keep your normal non-security packages also up-to-date, and as such is recommended.

You can also black-list specific packages that you do not want updating.  It is recommended to avoid this feature as it can lead to instability and security concerns.  However, there are cases where it may be necessary to hold a package at a certain version to ensure compatibility or similar reasons.  You can do so by simply adding the package to the black-list.  An example that tells the system to not update vim is provided below.

Unattended-Upgrade::Package-Blacklist {
      "vim";
};

Finally, you can adjust the frequency of the automatic updates in a configuration file which should be at /etc/apt/apt.conf.d/20auto-upgrades.  This file shows the frequency in days of the various portions of the update process.

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Download-Upgradeable-Packages "1";
APT::Periodic::AutocleanInterval "7";
APT::Periodic::Unattended-Upgrade "1";

In this example, unattended-upgrades will grab a fresh package list every day.  It will also download and install upgrades every day, and clean up the download archive for packages every 7 days.  You can adjust these values as desired, but the default configuration should work for almost all systems.  It is recommended to keep the Update-Package-Lists, Download-Upgradable-Packages, and Unattended-Upgrade values in sync, as these generally should be run in sequence for updates.

Setting up DNS at your external provider

If you plan to use a hostname that is reachable over the public web, you’ll need to have your domain registered, and have DNS hosted at one of the many DNS hosts. There are a number of free DNS hosts, as well as some managed DNS hosts for a fee. In this article, I’ll briefly touch on what DNS is, and provide some links to the popular DNS hosts and their own setup articles.

What is DNS?

DNS stands for ‘Domain Name System’ and it is the system which computers use to locate one another over networks. In the most basic sense, you can think of DNS as a phone book which ties human readable names like ‘www.google.com’ to an IP address. Servers, computers, etc can then establish the connection to the other device after having determined it’s name. For more information on DNS records, and DNS in general, check out our Introduction to DNS article.

Popular DNS Hosts

CloudFlare – Cloudflare provides fast and secure managed DNS as a built-in service on its network; DNS is available on all free and paid subscription plans.
Namecheap – Namecheap offers a FreeDNS service, and they also have a paid PremiumDNS service which was recently launched.
Dynu – Dynu Systems, Inc. provides free dynamic DNS service as well as other services.
Rackspace – Rackspace’s Cloud DNS provides simple DNS hosting, as well as other services.
DNSMadeEasy -DNS Made Easy offers affordable DNS management services that are easy to manage. 
Dyn – Dyn offers a variety of plans for DNS & Email Delivery
WordPress – WordPress offers DNS hosting for those who are signed up with an account through WordPress.

These are only a select few of the more popular DNS hosts, there are many others available for you to use as well.

How to install and use screen on your Linux server

Screen is described by the GNU project as a terminal multiplexer.

Most often, people use screen for one of two reasons. First, it can be easily used to organize multiple terminal sessions within a single window. The second most popular use for it is to start a long running command on a remote server.

If you have an unreliable network, we recommend that you use screen, which will ensure your sessions are still running if you get disconnected.

Prerequisites

You need access to a Linux server, with sudoers or root privileges. Adding sudo to your account is outside the scope of this tutorial.

Installation

sudo apt-get update
sudo apt-get install screen

screen -v
Screen version 4.06.02 (GNU) 23-Oct-17

Using screen

Starting a screen session

To start a new screen, you could just type the screen command, alone, but it’s very useful to name your screen sessions. I recommend getting into the habit of naming your session when you start screen, like this:

screen -S your_session_name

If you start screen without naming your session, you’ll get an about message. Press ENTER to continue.

Now, your terminal doesn’t look much different.

To verify that you are inside of screen, let’s use a screen command to display the version. On your keyboard, press and hold the control key, then press lowercase a, let go of both, and press the v key in quick succession.

You should see the version of screen displayed at the bottom of your terminal screen.

You can now run Linux commands as you normally do.

ls -l

Screen commands

Pressing CTRL+a then pressing another key is how you control all of screen’s functions. To see the commands available, press CTRL+a, then the question mark key (?). You will see a list of commands. CTRL+a ? is probably a command you should memorize at first, so that you can refer back to the list to learn other commands.

As you can see on the help screen, there are many different commands you can give screen. The most popular are:

CTRL+A d: Detaches from screen, leaving it (and any command inside it) running. This is one of the primary uses of screen.
CTRL+a c: Creates a new numbered terminal inside your screen session.
CTRL+a |: The pipe symbol vertically splits your screen session into two different areas.
CTRL+a TAB: Switches between split regions of the screen.
CTRL+a n: Switches between your numbered terminals.

Splitting your screen

Let’s walk through an example of this.

Inside of screen, start the top command.

top

Create a new terminal using CTRL+a c. The terminal with your top command will disappear, and you will get a new terminal.

Press CTRL+a |. Your screen will show a visible split to the right of your cursor. Notice that at the bottom of the screen, you will now see 1 bash. Your newly created terminal is now terminal 1. Your top command was running in terminal 0.

Use the CTRL+a TAB command to switch to the other side.

Now press CTRL+a n. This will bring your original terminal into the right hand split side. You should see your top command running. At the bottom of this terminal you will see 0 bash.

Switch back and forth between top and your command line using CTRL+a TAB. You can use both to run virtually any Linux command you wish.

Detach from and re-attach to screen

Let’s detach from screen, leaving your top command running, and then get back in.

Press CTRL+a d. You’ll see a message about being detached from your screen session.

Let’s list the screen sessions on the remote computer:

screen -ls

You’ll see the sessions created displayed in a list.

2642.testsession    (11/22/19 21:24:59)    (Detached)

If you’ve only created one session, resuming your session is as easy as:

screen -r

If you’ve created multiple screen sessions, you’ll need to specify the process ID (PID) file for the one you want to connect to.

screen -r 2642

Note that when re-entering the screen, your window split settings from before have been lost. Your terminals are still all there, but you’ll have to re-set up your splits.

Exiting screen

To completely quit your screen session, you have to exit each created terminal.

Simply press CTRL+d or type exit at each command prompt. You might have to CTRL+a TAB to each split, if you have splits open.

Conclusion

Hopefully, this article will whet your appetite to the power of using screen to manage multiple terminals on remote servers, as well as leave long running commands active even if you log out.

How to Install VNC on Ubuntu 19.04

Although most Linux cloud server administration is done over the command line, there may be cases where you want to run a graphical desktop on your server that interacts with your local keyboard and mouse. VNC (Virtual Network Computing) allows you to manage your Linux server through a familiar graphical interface.

In this article, we’ll install and set up a lightweight VNC server package, TightVNC, that is suitable even for slower internet connections, and then create a secure tunnel to that VNC server using SSH.

Prerequisites

To follow this guide, you will need the following:

  • An Ubuntu 19.04 server, and a server user with root privileges
  • A VNC client that supports VNC connections performed over SSH tunneling. For Mac OSX, you can use the built-in Screen Sharing application (other alternative applications are also available). For Windows, options include the TightVNC client.
  • Firewall rules, if any are configured on your Ubuntu server, must permit inbound traffic on port 5901

Installing VNC

Step 1: Install the graphical desktop packages

Linux offers a variety of different desktop environments, such as XFCE, Unity, and Gnome. This article will guide you through installing XFCE as the desktop that you will use to connect VNC from a remote location. Run the following commands to install XFCE on your Ubuntu server:

apt install xfce4 xfce4-goodies

During this installation, you may be prompted to pick a display manager for the system’s graphical desktop. Use the arrow keys to select lightdm on this screen and hit enter to continue.

Next, install the TightVNC server package:

apt install tightvncserver

Step 2: Create a VNC user on your server

To keep in line with security best practices, you should have SSH login to your server as the root user disabled and instead log in remotely through other users that have sudo privileges. For this exercise, we’ll also create a new user with sudo permissions that can access the VNC server remotely.

Create the new user and set its server password with the following commands:

sudo useradd -m -s /bin/bash myvncuser
sudo passwd myvncuser

Next add your new user to the sudo group to grant root privileges:

sudo usermod -a -G sudo myvncuser

And finally, log in as your new user and use its root privileges to begin working with the VNC server:

sudo su - myvncuser

Step 4: Run VNC server to create first time setup files

From this point onward, since we’ll be running commands on the server and on the local machine, the location where the command is being run will be displayed in front of the shell prompt (the ‘$’ character). For this exercise, the server name is lucky-puffin-86.

Run the first-time VNC server initialization for your user with the following command:

myvncuser@lucky-puffin-86:~$ vncserver

The screen output walks you through setting a VNC-specific password (limited to 8 characters), then you’re prompted on whether you wish to create a view-only password. The view-only password is used to provide a user with a shared screen view, but they will not be able to control the mouse or keyboard:

You will require a password to access your desktops.

Password:
Warning: password truncated to the length of 8.
Verify:
Would you like to enter a view-only password (y/n)? y
Password:
Warning: password truncated to the length of 8.
Verify:
xauth:  file /home/myvncuser/.Xauthority does not exist
xauth: (argv):1:  bad display name "lucky-puffin-86:1" in "add" command
xauth:  file /home/myvncuser/.Xauthority does not exist

New 'X' desktop is lucky-puffin-86:1
127.0.0.1 localhost

Creating default startup script /home/myvncuser/.vnc/xstartup
Starting applications specified in /home/myvncuser/.vnc/xstartup
Log file is /home/myvncuser/.vnc/lucky-puffin-86:1.log

Step 5: Configure the VNC startup settings

Now that we’ve started VNC server for the first time, some basic configuration files were created. We also want to set some commands to be run automatically every time vncserver starts up.

First, stop the running VNC server process:

vncserver -kill :1

Notice the :1 that we’re specifying here. VNC runs on server port 5901 by default, which is noted as :1 when working with vncserver in the command line. VNC can be run on multiple display ports, which would be 5902 labeled as :2, 5903 as :3, as so on.

Next, create a backup of its default startup script file:

mv ~/.vnc/xstartup ~/.vnc/xstartup.bak

Now use vim (or your favorite text editor) to create a new xstartup file:

vim ~/.vnc/xstartup

Paste the following 3 lines of text into your new file:

#!/bin/bash
xrdb $HOME/.Xresources
startxfce4 &

Be sure to save your new xstartup file. The first command tells VNC server to refer to the .Xresources associated with that user. This file determines some of the graphical settings for the desktop environment, but for this exercise we won’t be making any changes to it. The second command tells the VNC server to run XFCE, the desktop environment we installed in the first step.

Since we’re calling for the VNC server to run other commands from its startup, grant executable privileges to your new startup file with the following command:

sudo chmod +x ~/.vnc/xstartup

Step 6: Restart VNC server

Now that configuration is complete, start the VNC server again. The command and output will resemble the following:

myvncuser@lucky-puffin-86:~$ vncserver

New 'X' desktop is lucky-puffin-86:1

Starting applications specified in /home/myvncuser/.vnc/xstartup
Log file is /home/myvncuser/.vnc/lucky-puffin-86:1.log

Now we’re finished with configuration, and you’re ready to connect to your server’s graphical desktop remotely.

Testing your connection

To test your connection to your new server desktop environment, we need to create an SSH tunnel that will be forwarded to the VNC server’s localhost connection. For Linux and OSX local machines, you can set this up using the terminal. For Windows local machines, this can be set up by using the SSH tunnel options for your chosen SSH client (most likely, this will be PuTTY).

Step 1: Set up a secure SSH tunnel between your local machine and the server

Set up a secure SSH tunnel by running the following command on your local machine (you can open up a new window or tab in Terminal, for example). Replace server_ip with the IP address of your Cloud Server:

mylaptop:~ me$ ssh -L 5901:127.0.0.1:5901 -N -f -l myvncuser server_ip

You will be prompted to enter the vnc user’s server password that we previously set up during Installing VNC, step 2.

Step 2: Use your VNC client to connect to the desktop

Using a VNC client such as Mac OSX’s built-in Screen Sharing or any other client mentioned here, you can now connect to localhost:5901. You will be prompted to enter the vncserver password (not the same as the user’s server password unless you made them identical). The tunnel we set up in step 1 should now connect you to the server’s desktop environment:

Set TightVNC to run as a service

We’ve left things in such a way that you’ll have to log in to the command line and manually start vncserver each time the server restarts. To set your VNC server to run at startup (and to make it easier to start and stop in general), we can configure the server to run tightvnc as a systemd service.

If you’re unfamiliar with systemd, it can be used to control a number of different server resources — in our case, a service we’re going to tie to vncserver — through something called a unit file.

One more time, let’s stop the VNC server so we can change configuration files:

vncserver -kill :1

Now create a new systemd unit file with the following command:

sudo vim /etc/systemd/system/vncserver@.service

Copy and paste the following configuration into the file, replacing myvncuser with your desired username:

[Unit]
Description=Start TightVNC server at startup
After=syslog.target network.target

[Service]
Type=forking
User=myvncuser
Group=myvncuser
WorkingDirectory=/home/myvncuser

PIDFile=/home/myvncuser/.vnc/%H:%i.pid
ExecStartPre=-/usr/bin/vncserver -kill :%i > /dev/null 2>&1
ExecStart=/usr/bin/vncserver -depth 24 -geometry 1280x800 :%i
ExecStop=/usr/bin/vncserver -kill :%i

[Install]
WantedBy=multi-user.target

Again, be sure to save when you exit your text editor. Next, run the following two commands to have systemd detect and use the new resource:

sudo systemctl daemon-reload

sudo systemctl enable vncserver@1.service

Now use systemd to start VNC server. Notice the ‘@1’ suffix used in these commands, this is referencing which display port should be used, in our case :1.

sudo systemctl start vncserver@1

If everything is configured properly, the terminal won’t receive any text output. You can always check on the status of systemd services like so, especially if you ran into any error messages or problems:

sudo systemctl status vncserver@1

When it starts correctly, vncserver should look similar to the following when checking it using systemctl status:

 $ sudo systemctl status vncserver@1.service
● vncserver@1.service - Start TightVNC server at startup
   Loaded: loaded (/etc/systemd/system/vncserver@.service; enabled; vendor preset: enabled)
   Active: active (running) since Thu 2019-11-21 16:59:14 UTC; 11min ago
  Process: 24157 ExecStartPre=/usr/bin/vncserver -kill :1 > /dev/null 2>&1 (code=exited, status=2)
  Process: 24161 ExecStart=/usr/bin/vncserver -depth 24 -geometry 1280x800 :1 (code=exited, status=0/SUCCESS)
 Main PID: 24169 (Xtightvnc)
    Tasks: 107 (limit: 1161)
   Memory: 168.3M

Congratulations on your new server GUI, and happy clicking!

Introduction to systemd/systemctl

Systemd is a suite of tools that allow you to quickly and easily manage your server from bootup onwards. Systemd gives you a linux system and service manager which runs as its own process ID (PID), which will always be PID 1. PID 1 controls the start of the rest of the system. With most of the newer Linux based operating systems, systemd is now the default service manager. In this article, we’ll overview the most important commands you’ll need to know for managing a systemd server.

Managing Units

The first thing you can try when using your systemd-based server, is running the command shown below:

systemctl

This will output a list of everything running on your system.  You’ll likely have a large number of units listed (a unit is similar to a ‘service’ in older Linux based operating systems, however it can also be used to refer to network resources, devices, and filesystem mounts), but if you’re working with a server that might not have been set up by you, and want to get familiar with what exactly is running on it, this would be a good place to begin.

Another useful systemctl command would be to check for failed units.  You can have systemctl output only failed units with this command:

systemctl --failed

If you want to know more about a service which shows up in a failed state, you can use this command to get that information:

systemctl status 

This will give you process and service information for the unit, as well as the last few lines of logs.

As far as managing a unit, you can start any unit by issuing the following command:

systemctl start 

Stopping a unit is the same, but replace start with stop as shown below:

systemctl stop 

You can restart a service with the following command:

systemctl restart 

When you need to have a service start on boot, or need to disable a service from starting on boot, the commands below will accomplish that:

systemctl enable 

systemctl disable 

These are the basics of working with systemctl, and should be enough to get you started with interacting with units on your systemd server.

Managing Power States

Another thing that systemd can do is handle the power states of your server. 

To reboot the server, type the following command:

systemctl reboot

To shut down and power the server off, enter the following command:

systemctl poweroff

Handling and Viewing Logs

Systemd includes a component called journald, which gathers and manages journal entries from the whole system. It gathers log information from applications as well as the kernel itself.

To view all the information that journald has captured ordered from oldest to newest, issue the following command:

journalctl

You can get more specific by asking it to only output entries since the most recent boot:

journalctl -b

Suppose that your server stopped responding at a specific date and time, and you wanted to look at logs around that, you can use the following command to specify a starting date and time for the logs fetched:

journalctl --since="2019-10-31 14:23:46"

Modifying Unit Files

Due to the complex nature of the format of unit files, it’s beyond the scope of this article, but it’s worth knowing that with systemctl, you have the ability to edit Unit Files without needing to know the exact location of the files on the disk.

To edit an existing unit file, type:

systemctl edit --full unit

Once you’ve made the edit, you will need to reload systemd for it to accept the changes you’ve made to the unit:

systemctl daemon-reload

Conclusion

Systemd is robust, and covers a much wider range of possibilities and functionality than covered in this introduction. You can read more about systemd, systemctl, and journalctl on the web or by utilizing their respective man pages from within your server.

How to Install VNC on Ubuntu 16.04

Although most Linux cloud server administration is done over the command line, there may be cases where you want to run a graphical desktop on your server that interacts with your local keyboard and mouse. VNC (Virtual Network Computing) allows you to manage your Linux server through a familiar graphical interface.

In this article, we’ll install and set up a lightweight VNC server package, TightVNC, that is suitable even for slower internet connections, and then create a secure tunnel to that VNC server using SSH.

Prerequisites

To follow this guide, you will need the following:

  • An Ubuntu 16.04 server, and a server user with root privileges
  • A VNC client that supports VNC connections performed over SSH tunneling. For Mac OSX, you can use the built-in Screen Sharing application (other alternative applications are also available). For Windows, options include the TightVNC client.
  • Firewalls rules, if any are configured on your Ubuntu server, must permit inbound traffic on port 5901

Installing VNC

Step 1: Install the graphical desktop packages

Linux offers a variety of different desktop environments, such as XFCE, Unity, and Gnome. This article will guide you through installing XFCE as the desktop that you will use to connect VNC from a remote location. Run the following commands to install XFCE on your Ubuntu server:

apt install xfce4 xfce4-goodies

Next, install the TightVNC server package:

apt install tightvncserver

Step 2: Create a VNC user on your server

To keep in line with security best practices, you should have SSH login to your server as the root user disabled and instead log in remotely through other users that have sudo privileges. For this exercise, we’ll also create a new user with sudo permissions that can access the VNC server remotely.

Create the new user and set its server password with the following commands:

sudo useradd -m -s /bin/bash myvncuser
sudo passwd myvncuser

Next add your new user to the sudo group to grant root privileges:

sudo usermod -a -G sudo myvncuser

And finally, log in as your new user and use its root privileges to begin working with the VNC server:

sudo su - myvncuser

Step 4: Run VNC server to create first time setup files

From this point onward, since we’ll be running commands on the server and on the local machine, the location where the command is being run will be displayed in front of the shell prompt (the ‘$’ character). For this exercise, the server’s name is lucky-puffin-86.

Run the first-time VNC server initialization for your user with the following command:

myvncuser@lucky-puffin-86:~$ vncserver

The screen output walks you through setting a VNC-specific password (limited to 8 characters), then you’re prompted on whether you wish to create a view-only password. The view-only password is used to provide a user with a shared screen view, but they will not be able to control the mouse or keyboard:

You will require a password to access your desktops.

Password:
Warning: password truncated to the length of 8.
Verify:
Would you like to enter a view-only password (y/n)? y
Password:
Warning: password truncated to the length of 8.
Verify:
xauth:  file /home/myvncuser/.Xauthority does not exist
xauth: (argv):1:  bad display name "lucky-puffin-86:1" in "add" command
xauth:  file /home/myvncuser/.Xauthority does not exist

New 'X' desktop is lucky-puffin-86:1
127.0.0.1 localhost

Creating default startup script /home/myvncuser/.vnc/xstartup
Starting applications specified in /home/myvncuser/.vnc/xstartup
Log file is /home/myvncuser/.vnc/lucky-puffin-86:1.log

Step 5: Configure the VNC startup settings

Now that we’ve started VNC server for the first time, some basic configuration files were created. We also want to set some commands to be run automatically every time vncserver starts up.

First, stop the running VNC server process:

vncserver -kill :1

Notice the :1 that we’re specifying here. VNC runs on server port 5901 by default, which is noted as :1 when working with vncserver in the command line. VNC can be run on multiple display ports, which would be 5902 labeled as :2, 5903 as :3, as so on.

Next, create a backup of its default startup script file:

mv ~/.vnc/xstartup ~/.vnc/xstartup.bak

Now use vim (or your favorite text editor) to create a new xstartup file:

vim ~/.vnc/xstartup

Paste the following 3 lines of text into your new file:

#!/bin/bash
xrdb $HOME/.Xresources
startxfce4 &

Be sure to save your new xstartup file. The first command tells VNC server to refer to the .Xresources associated with that user. This file determines some of the graphical settings for the desktop environment, but for this exercise we won’t be making any changes to it. The second command tells the VNC server to run XFCE, the desktop environment we installed in the first step.

Since we’re calling for the VNC server to run other commands from its startup, grant executable privileges to your new startup file with the following command:

sudo chmod +x ~/.vnc/xstartup

Step 6: Restart VNC server

Now that configuration is complete, start the VNC server again. The command and output will resemble the following:

myvncuser@lucky-puffin-86:~$ vncserver

New 'X' desktop is lucky-puffin-86:1

Starting applications specified in /home/myvncuser/.vnc/xstartup
Log file is /home/myvncuser/.vnc/lucky-puffin-86:1.log

Now we’re finished with configuration, and you’re ready to connect to your server’s graphical desktop remotely.

Testing your connection

To test your connection to your new server desktop environment, we need to create an SSH tunnel that will be forwarded to the VNC server’s localhost connection. For Linux and OSX local machines, you can set this up using the terminal. For Windows local machines, this can be set up by using the SSH tunnel options for your chosen SSH client (most likely, this will be PuTTY).

Step 1: Set up a secure SSH tunnel between your local machine and the server

mylaptop:~ me$ ssh -L 5901:127.0.0.1:5901 -N -f -l myvncuser server_ip

You will be prompted to enter the vnc user’s server password that we previously set up during Installing VNC, step 2.

Step 2: Use your VNC client to connect to the desktop

Using a VNC client such as Mac OSX’s built-in Screen Sharing or any other client mentioned here, you can now connect to localhost:5901. You will be prompted to enter the vncserver password (not the same as the user’s server password unless you made them identical). The tunnel we set up in step 1 should now connect you to the server’s desktop environment:

Set TightVNC to run as a service

We’ve left things in such a way that you’ll have to log in to the command line and manually start vncserver each time the server restarts. To set your VNC server to run at startup (and to make it easier to start and stop in general), we can configure the server to run tightvnc as a systemd service.

If you’re unfamiliar with systemd, it can be used to control a number of different server resources — in our case, a service we’re going to tie to vncserver — through something called a unit file. Create a new systemd unit file with the following command:

sudo vim /etc/systemd/system/vncserver@.service

Copy and paste the following configuration into the file, replacing myvncuser with your desired username:

[Unit]
Description=Start TightVNC server at startup
After=syslog.target network.target

[Service]
Type=forking
User=myvncuser
PAMName=login
PIDFile=/home/myvncuser/.vnc/%H:%i.pid
ExecStartPre=-/usr/bin/vncserver -kill :%i > /dev/null 2>&1
ExecStart=/usr/bin/vncserver -depth 24 -geometry 1280x800 :%i
ExecStop=/usr/bin/vncserver -kill :%i

[Install]
WantedBy=multi-user.target

Again, be sure to save when you exit your text editor. Next, run the following two commands to have systemd detect and use the new resource:

sudo systemctl daemon-reload

sudo systemctl enable vncserver@1.service

Now stop the currently running VNC server:

vncserver -kill :1

Now use systemd to start VNC server. Notice the ‘@1’ suffix used in these commands, this is referencing which display port should be used, in our case :1.

sudo systemctl start vncserver@1

If everything is configured properly, the terminal won’t receive any text output. You can always check on the status of systemd services like so, especially if you ran into any error messages or problems:

sudo systemctl status vncserver@1

When it starts correctly, vncserver should look similar to the following when checking it using systemctl status:

 Main PID: 7023 (Xtightvnc)
   CGroup: /system.slice/system-vncserver.slice/vncserver@1.service
           ‣ 7023 Xtightvnc :1 -desktop X -auth /home/myvncuser/.Xauthority -geometry 1280x800 -depth 24 -rfbwait 120000 -rfbauth /home/myvncuser/.vnc/passwd -rfbport 5901 -fp /usr/share/fonts/X11/misc

Nov 01 16:03:19 lucky-puffin-86 systemd[1]: Starting Start TightVNC server at startup...
Nov 01 16:03:19 lucky-puffin-86 systemd[6998]: pam_unix(login:session): session opened for user myvncuser by (uid=0)
Nov 01 16:03:19 lucky-puffin-86 systemd[7008]: pam_unix(login:session): session opened for user myvncuser by (uid=0)
Nov 01 16:03:20 lucky-puffin-86 systemd[1]: Started Start TightVNC server at startup.

Congratulations on your new server GUI, and happy clicking!

How to use FTP on Windows Server 2012 R2

This article will show you how to install and connect to an FTP server on your Windows 2012 R2 server.

Prerequisites

To follow this guide you will need access to a user with Administrator privileges on your Windows server.

Installing FTP

Configure the FTP Server

  1.  Open the Server Manager application if it’s not already open.
  2.  Click on Add roles and features
  3.  Select Role-based or feature-based installation and hit next.
  4. Your server should already be selected, so go ahead and hit Next.
  5. Check the box next to Web Server(IIS).
  6.  A box will appear. Click Add Features. 
  7. Click on Role Services under Web Server Role (IIS).
  8. Check the box next to FTP Server and click Next.
  9. Before you click Install, you can go back and configure the IIS install how you like. However, we’ve covered everything necessary for an FTP Server. Once finished, click Install.
  10. Go back to the Server Manager application. Under Tools, click Internet Information Services (IIS) Manager.
  11. Click on your server name.
  12. Right click your server name and select Add FTP Site….
  13. Name the site and choose its path.
  14. Configure the address and SSL if you have it.
  15. Configure Authentication and hit Finish.

Connect with Filezilla

Now you can test your FTP server by connecting to it from your local computer. Filezilla is a popular, free and open source FTP client that we’re using in this guide. However, any FTP client should work.

  1.  Input your IP address, user name and password. You can leave the port field blank.
  2. Hit Quickconnect.

You’ll now be able to send files to and from your Windows Server 2012 R2 using FTP. Remember that FTP on its own does not support any type of encryption, and its data can be viewed while in transit, so it’s not appropriate for transferring sensitive data. For encrypted logins and file transfers, consider making use of the SSL feature we saw available in step 14 of this guide, or a different protocol such as Secure FTP (SFTP)  which connects through SSH.

Connect to your Linux server with SFTP

When you need to transfer files to and from your cloud server, Secure File Transfer Protocol (SFTP) is one of the simplest and most popular methods. Unlike standard FTP, which transmits your data in a plainly readable format and exposes you to security risks, SFTP is conducted over an encrypted session via an SSH connection. This article will show you how to connect to your Linux server through SFTP.

Prerequisities

In order to follow this guide, you’ll need the following:

  • A user on your cloud server with permissions to log in over SSH
  • Port 22 must be open to allow traffic from your local machine (or if SSH uses a custom port number, that port must be opened)
  • (Optional but recommended) A utility program installed on your local machine that supports SFTP

Connecting With Filezilla

The simplest method to transfer files over SFTP, especially for beginners, is to use one of the utility programs available for Windows and Mac OS. Filezilla is a popular, free, and open source SFTP client and the one we will be using in this guide. However, other SFTP clients such as Cyberduck or WinSCP can be used. These clients add a graphical interface which makes it simpler to navigate both your local files and the server files at once, as well as work more easily with transferring multiple files.

1. Input your IP address, user name, password, and port 22

2. Click Quickconnect

You’ll now be able to send files to and from your Linux server, and Filezilla will support additional desktop features such as selecting multiple files, or drag and drop.

Connecting through the SFTP command line tool

There may be situations where you’re unable to load an additional SFTP utility onto your local device, or perhaps you want to transfer files from server to server. The sftp command line tool is available through all major Linux distributions, the Mac OSX terminal, and even Windows 10 now includes an OpenSSH client accessible through the command prompt that includes sftp capabilities.

1. Log in using the sftp command

The sftp login is similar to how you would connect using SSH. Use the following command replacing username with your specific username, and your_server_ip with the server’s correct IP:

sftp username@your_server_ip

2. Downloading files

Downloads will automatically go to whichever directory you were in locally in your terminal or command prompt session. Use the get command like so:

get /path/to/server/file

Or to download to a specific directory (Windows local paths use a backslash, Linux and Mac paths will use forward slash same as the server path):

get /path/to/server/file C:UsersAdminsomefolder

get /path/to/server/file /Users/Macbookuser/Downloads

3. Uploading files

Uploading is done with the put command, followed by the local file path first and the destination on the server second.

put C:UsersAdminsomefoldersomefile /path/to/server/dir

put /Users/Macbookuser/Documents/somefile /path/to/server/dir

4. Additional tips for using the command line

Many home desktop computers are much more friendly towards file names containing spaces, whereas most command line tools are less forgiving. If you want to transfer a file with a space within the file name, simply encase it in double quotes like so:

put "C:Program Files (x86)somefile"

Performing large file transfers may sometimes get interrupted, but you can resume those transfers by replacing your previous get command with reget, or put command with reput:

reget /path/to/server/file /Users/Macbookuser/Downloads

reput /Users/Macbookuser/Documents/somefile /path/to/server/dir

5. Ending your SFTP session

When you’re done with the SFTP shell run the following command:

exit

Introduction to Automation

Automation has a few different meanings when it comes to your cloud environment. For the basis of this article, I will be speaking specifically of configuration management (CM).

Configuration management is a convenient way to handle changes being made to your servers that keeps consistency across your environment. Previously, system administrators were tasked with making any updates to server fleets manually, which introduces several points of failure due to human error.

Automation is pivotal in the CM world as many companies and teams use many servers across multiple platforms to maintain their applications. CM allows for DevOps engineers to gather and change vital information about their fleet of servers such as the health of devices, the state of applications, as well as making any changes or updates to servers.

 

How can automation improve your cloud experience

Automation can save DevOps engineers many hours of manually seeking information or making changes to a server fleet. Automation also removes a lot of the human error that goes into implementing many changes across many servers. Using automation, engineers are creating scripts that will be sent out to their fleet of servers — if an error exists in that script, a simple change to the offending script and re-deployment will resolve the issue instead of having to go to each server to address the problem across the fleet.

Consistency across your fleet is also vital to the overall health of your application and engineers. Automation keeps your fleet running on the specific configuration of the engineer’s choosing, which eliminates any one-off servers that need a specific hotfix or update. Automation also lets engineers spin up on-demand servers quickly and with integrity. This kind of freedom allows for servers to be blown away should they cause issues for the fleet — being able to simply re-deploy a device from automated steps can save hours of troubleshooting.

 

Automation platforms

There are many available platforms that all have slightly different solutions to automated CM. As the engineer, it is up to you to choose which platform works the best for your environment (or future environment if you’re still planning). I will provide for you a few ideas to keep in mind while choosing a CM platform.

If you are reading this article, it is probably safe to assume that you are unfamiliar with CM platforms and there will be a learning curve before you are an automation guru. This is something to account for, whichever platform you choose will have a bit of time before you are autonomous, for a lack of better word. For example, CM platforms use a Domain Specific Language (DSL) which users will need to understand as they build CM scripts and deploy them. I would steer beginners away from a platform that is incredibly complex unless you have decided that you need a specific ability of that platform.

Speaking of learning a new language, the community and support a platform offers are also important. This is especially true for those that are working in small teams, where there isn’t already someone who is well versed in the platform you are working in. The support a platform offers can take a troublesome issue and make it trivial because someone has already asked for help and received an answer. Ansible, for example, has training documents and example playbooks to help new users become comfortable with the tool.

The cost of the platform is also a factor to consider. Many CM platforms have free versions of their application with limited features. These often give users a taste of the tooling and how to use it before committing to purchasing the full platform solution.

 

Popular CM platforms

 

 

Puppet

Ansible

Chef

Salt

Infrastructure

Puppet Master controls configuration on Puppet Nodes

Controls configuration via SSH

Workstations will update Chef Server which will update all nodes

Master will relay configurations to Minions

Script Language

Custom DSL based on Ruby

Yamal

Ruby

Python

Special Software

Yes

N/A

Yes

Yes

Point of control

Puppet Master controls all nodes

Any computer can become the controller

Chef Server controls all nodes

Master controls Minion nodes

Task Execution

Non-Sequential

Sequential

Sequential

Both

Conclusion

CM automation is a powerful concept that can simplify your server environment by maintaining the integrity of your server fleet and providing vital information about your servers. In the next article, we will explain what a LAMP stack is and how to implement one using automation.