Rails%203%20In%20Action

Creating a user for the app
So now you’ve got the beginnings of a pretty good environment set up for your application,
but you don’t have your application on the server yet. To do this, you need to
undertake a process referred to as deployment. Through this process you’ll put your
application’s code on the server and be one step closer to letting people use the
application.
When you deploy, you’ll use a user without root privileges to run the application,
just in case. Call this user the same as your (imaginary) domain: ticketeeapp.com.
14.3 Creating a user for the app
You’re calling this user ticketeeapp.com because if you wanted to deploy more than
one application to your server, there will be no confusion as to which user is responsible
for what. When you set up a database later on, this username will be the same as
your database name. This is for convenience’s sake, but also because the database will
be owned by a user with the same name, allowing this account and none other (bar
the database super user) to access it. It’s all quite neat.
To begin to set up this user, run these commands:
sudo useradd ticketeeapp.com -s /bin/bash -m -d /home/ticketeeapp.com
sudo chown -R ticketeeapp.com /home/ticketeeapp.com
sudo passwd ticketeeapp.com
You’ve used a couple of options to the useradd command. The -s option sets the shell
for the user to /bin/bash (the standard shell found in most UNIX-based operating systems)
and the -d option sets their home directory to /home/ticketeeapp.com, while
the -m option makes sure that the user’s home directory exists. The second command,
chown (short for change owner), changes the owner of the /home/ticketeeapp.com
directory to be the ticketeeapp.com user. The final command, passwd, prompts you to
set a password for this user, which you should set to something complex (that you’ll be
able to remember) to stop people hacking your ticketeeapp.com user. 15
To make this account even more secure, you can switch to key-based authentication.
14.3.1 Key-based authentication
In this next step, you’ll set up a key that will allow you to log in as your user and
deploy on your server without a password. This is called key-based authentication and
requires two files: a private key and a public key. The private key goes on the developer’s
computer and should be kept private, as the name implies, because it is the key
to gain access to the server. The public key file can be shared with anybody and is used
by a server to authenticate a user’s private key.
You’ll use a key-based authentication for your server because it is incredibly secure
versus a password authentication scheme. To quote the official Ubuntu instructions
on this 16 :
15 Even though this won’t matter in a short while (when you turn off password authentication and switch to the
more secure key-based authentication), it’s still good practice to always secure any user account on any system
with a strong password.
16 https://help.ubuntu.com/community/SSH/OpenSSH/Configuring.
391