I wrote a doc about it on GitHub: https://github.com/jabbalaci/DigitalOceanNotes . Following this guide I can set up a virtual private server (VPS) in 30-40 minutes.
A few days ago I wrote about the awesome tool screen. Then, some of my readers namely “i90rr _” and Rodnee suggested that I should try tmux (thanks for the tip). Actually, I tried it years ago, but since I didn’t have to work with SSH too much, it was not integrated in my daily routine. However, a few days ago I bought a Digital Ocean VPS to do some Python webapp development and now I do need ssh :) And without screen / tmux it would be a pain.
So, after screen, let’s see tmux.
tmux: an advanced and friendly terminal multiplexer
The scenario is the same:
Log in with SSH:
ssh -p PORT USER@184.108.40.206
Specify the port if the SSH daemon is not on port 22. In the case of screen I used screen twice, but now I think it’s not necessary. First just use “ssh”. To keep the connection alive between machines A and B, it’s a good idea to use this alias:
alias ssh='ssh -o ServerAliveInterval=60'
More info about it here.
Once you are logged in to machine B, make sure that you have a recent version of tmux installed. More info here. And now just start tmux and use it :)
My config file
A big advantage of tmux over screen is its sane configation system. You can find my
~/.tmux.conf file here, I won’t copy it here.
My tmux looks like this:
A very special feature of screen / tmux is the ability to detach. It means that you have several tabs open within tmux (tmux calls them “windows”), and pressing “Ctrl-b d” you can close tmux. However, the programs in its tabs are still running, they are not terminated! You can close SSH, even restart your local machine, it doesn’t matter. When you log in again to machine B with SSH, you can attach to this tmux session and voilá, there you have your tabs and every program is running.
For instance, you launch a program on the server that runs for hours. Just detach, and attach a few hours later to see the result of this program. Or, you log in to a remote server from home, launch some programs, detach, shutdown your local machine, go to your workplace, log in again with SSH and attach to tmux, and you continue where you left off at home.
I don’t want to write a tmux tutorial because others have already done it much better. So let’s see some links:
- Basic tmux Tutorial – Windows, Panes, and Sessions over SSH, a very nice YouTube video that shows the basics
- Mark H. Nichols tmux configuration, my tmux config is based on it in 90%
- A Tmux crash course: tips and tweaks
I use two simple scripts to make re-attaching easier. The first one is called “tm”:
#!/usr/bin/env bash # tm tmux list-sessions echo "# tmux attach -t 0"
The second one is called “tm0”:
tmux attach -t 0
If you don’t give your tmux session a name (I don’t) then your session has ID 0. When I log in again to the remote server first I run “tm” to see the running sessions. Normally I only have one session, so its ID is 0. With “tm0” I can attach to it and continue my work in tmux. Easy peasy :)
Summary: to detach, press “Ctrl-b d”, and close SSH. To continue your work, log in with SSH, check sessions with “tm”, and attach with “tm0”. Easy peasy :)
What I love in Manjaro is that it contains the latest software versions. For instance, I installed tmux and on Manjaro it’s version 2.1.
On Ubuntu 14.04 it’s still version 1.8 in the reposotories…
How to upgrade tmux 1.8 to 2.1 on Ubuntu?
Install these packages:
$ sudo apt-get install exuberant-ctags cmake libevent-dev libncurses5-dev
Then download the source of tmux from the official home page. Then build and install:
$ ./configure && make $ sudo make install
This tip is from here.
You connect to a server via SSH, you take a coffee, and when you come back your terminal is stuck. If you are inactive for a while, your connection is cut by the server.
I use a very simple solution. Add this to your
alias ssh='ssh -o ServerAliveInterval=60'
This way the client sends a null packet to the server every minute, just to keep the connection alive.
You could also do this in different configuration files (see here).
Recently I discovered the tool screen and it’s simply awesome. It’s “a wrapper that allows separation between the text program and the shell from which it was launched. This allows the user to, for example, start a text program in a terminal in X, kill X, and continue to interact with the program.” (source)
Here, in this post I want to show how to use screen with ssh and how it can simplify your daily work.
If you ssh to a server and you are inactive for a while, the server disconnects you. It depends on the server, but most of them are configured this way. Annoying. Or, if you launch a process on the server in the foreground and you want to do something else on the server, what do you do? Log in again in another terminal?
Screen can solve all these problems for you. Here is the figure of an SSH connection:
We will use screen twice. First, we will launch it on machine A. This screen instance will guarantee that the connection won’t be broken even if you are inactive. Fine. Second, we will launch screen on machine B too. This second screen will allow us to open virtual tabs on the server! For instance, you want to work with two Midnight Commanders. You start copying something that takes a long time. No problem, just open a new “tab” and continue working on the server. You don’t need to log in again!
You will need two configuration files. Here is the first one that must be copied to machine A, to your HOME folder. Here is the second one that you need to put on machine B, also in your HOME folder. Don’t forget to rename them to “.screenrc”.
Log in with SSH
For logging in I use this script:
screen -t SESSION_TITLE ssh -p REMOTE_PORT -t USERNAME@REMOTE_HOST screen clear echo "# screen closed"
For instance, you have a VPS whose IP is 220.127.116.11. You installed SSH on port 2222. Then, the first line could be “
screen -t my_vps ssh -p 2222 -t email@example.com screen“. It will start screen on localhost, but upon login it will also start screen on the remote server.
Here is a screenshot of the bottom left corner:
By default, screen commands can be activated with Ctrl-a. However, we have two screen instances, so on machine B I changed the shortcut to Ctrl-b. It’s also displayed in the corner, so there is no need to memorize it. As can be seen on the figure, on the server I have two virtual tabs open.
Now, what can we do with all this? If you want to open a new virtual tab on the server, press “Ctrl-b c” (hold Ctrl and press b, release both and press c). To close a tab just press “Ctrl-d” (like in any terminal).
Change between tabs: Ctrl-b-b (hold Ctrl, then press b twice). Or, use the ID of the tabs: “Ctrl-b 0” (first tab), “Ctrl-b 1” (second tab), etc.
You can also detach screen, but I will write about that later.
You have a Digital Ocean VPS with Ubuntu and you want to set up a firewall on it. However, iptables is too complicated. What to do?
Use UFW, the Uncomplicated Firewall. Say you want to open the SSH port and you have a webapp running on a specific port that you want to make accessible. Here is a basic setting:
#!/usr/bin/env bash sudo ufw reset sudo ufw disable # SSH is on a custom port sudo ufw allow 12345/tcp # the webapp is listening here sudo ufw allow 1234/tcp sudo ufw default deny incoming sudo ufw default allow outgoing sudo ufw enable sudo ufw status verbose
Warning! Make sure to add your SSH port! Otherwise you won’t be able to log in anymore!
Outgoing connections are allowed. Incoming connections are blocked except: 1) port 12345, and 2) port 1234.
If you want to hide MongoDB from the world and only want to allow connections to it from localhost, then here is a basic config file:
# /etc/mongod.conf # for documentation of all options, see: # http://docs.mongodb.org/manual/reference/configuration-options/ # Where and how to store data. storage: dbPath: /var/lib/mongodb journal: enabled: true # engine: # mmapv1: # wiredTiger: # where to write logging data. systemLog: destination: file logAppend: true path: /var/log/mongodb/mongod.log # network interfaces net: port: 27017 bindIp: 127.0.0.1
In MongoDB 3.2 WiredTiger is the default storage engine. The interesting part here is the “net” configuration.
I have a Digital Ocean VPS with MongoDB preinstalled and this config file comes from there.