I kept one foot in the Windows world as long as I could. It's impressive how many of the new technologies such as Node.js can run on Windows. Perhaps you have other Windows legacy systems, or you're limited to an existing supported Windows environment. I used to have both of these considerations.

As you start to work more with Node.js and many other emerging web technologies, you will begin to realize how much better and easier they work together when implemented in a Linux environment. Also, a majority of the helpful documentation and tutorials you find will assume you're doing things "the Linux way."

You don't need to be a Linux administrator to securely and reliably develop and host your own Linux solutions. Let's go through the process of provisioning a new Linux Virtual Machine (VM), accessing the server, setting up basic security and users, and get up to speed copying files to/from the server.

Development- For this example, I assume you develop on a Mac. You can work from Windows using a tool like PuTTY, but moving to Apple is nice because 1) the Unix-based OS helps your Linux skills, 2) most Linux tools and libraries have Mac versions, 3) the Mac terminal is nicer to use, and 4) Sublime Text 3 supports retina displays ;)

(Plus, it's the perfect excuse to get a shiny new MacBook Pro!)

Creating a Linux Virtual Server

Sign up for an account at DigitalOcean and create a new Linux "droplet." I'm using Ubuntu 13.10 x64 for this example. (If you plan to plan to network multiple VM's together via a private connection, use NYC2 for a location and enable Private Networking.)

Why DigitOcean? I agree with Jeedo's sentiments, as I also express here.

• Note: Once your droplet is created, DigitalOcean will email you your new server connection info.

Accessing and updating the server

Setting up your server to authenticate using SSH keys is considered more secure, but I find it adds confusion when you're trying to learn and creating/destroying a bunch of VM's. So just ssh into the server as a user. You will, however, want to lock down the server to improve security and improve manageability and reliability.

A good reason do these lock down steps when you first get started is because it slightly changes the process of accessing your server and configuring your deployment process.

Terminal and basic commands- The Mac terminal has a lot of pretty themes. Find terminal in your Applications/Utilities folder and drag it to your Dock for easy access. Some quick tips:

• Open new "tabs" (Shell -> New Tab) to run multiple sessions at the same time. Standardize on using certain themes for certain servers or functions... for example, I always use Homebrew theme for sessions on my local Mac, Novel for remote VM sessions, and Grass for MySQL sessions. This can go a long way to help keep you sane.
• The up arrow will bring back your last command. Press again and again to get prior commands. Nice.
• When referencing a file name in a command, type the first few letters and then tab to autofill the rest. If there are multiple matched, (it fills as much as it can) type another letter or so, and tab again to fill the rest.
• Your "home" directory is represented by the ~, so cd ~/ will take you to your home folder. So it is quite helpful to keeop your main project directories right off of your home folder.

The bread and butter:

• cd will change directory, as in cd ~/myproject. For Windows users it takes a little time to used to back slashes instead of forward slashes. Up one level is cd ../
• pwd will Present your current Working Directory - very handy.
• mkdir newdirectoryname will create a new directory at your current location
• ls will list the directory files. ls -a will show all including hidden files that start with a .. ls -l shows files in a list - along with permissions and file size.
• Directories can have one or more . in them. If a file or directory starts with a . it will be hidden. Use ls -a to see them.
• cat filename will write out the contents of filename.
• cat > filename will sit there and wait for you to type or paste text in what you want to write into filename. Use cat >> filename to append the text. The single > will overwrite the file with your new content. Use ctrl-d when you are done typing or pasting the text to finish. Using copy and paste, this becomes a very fast way to move small files contents around.
• rm filename deletes a file
• rmdir directoryname deletes an empty directory
• rm -rf directoryname deletes a directory and all files and subdirectories in it
• tail filename will write out the last few lines of that file - great got log files you want to peek at. Use -n 500 to see the last 500 lines. Use -f and it will sit there and write anything out that hits the file in real time. Example: tail /var/log/node.log -n 500 -f Use ctrl-c to exit.
• cp filename anotherfilename copies filename to a new anotherfilename
• mv filename newfilename will rename/move the file from filename to newfilename

ssh lets you connect to your virtual server and run a session there. Use the info DigitalOcean emailed you to connect, such as:

ssh root@your.ip.address.here

Then type in the password they sent you when prompted. If you have a domain name pointed to that IP address, you can just ssh root@yourdomain.com as well.

You may be asked if you want to continue to connect, just enter yes as follows, and then enter your password from the email:

MacBook-Pro:~ sean$ ssh root@162.243.238.83

The authenticity of host '162.243.238.83 (162.243.238.83)' can't be established.
RSA key fingerprint is c2:5d:e5:d0:f5:43:d8:52:73:22:fd:b6:7e:e3:ca:34.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '162.243.238.83' (RSA) to the list of known hosts.
root@162.243.238.83's password: 

root@nodeden:~#

The root@nodeden:~# promt above shows us we're logged into the nodeden machine as root. (nodeden is what I set up as the host name when I created the droplet at DigitalOcean.) The ~ means we're in root's home directory. A quick pwd shows is we are indeed in /root.

Package Managers- One of the first important Linux lessons I learned when moving from Windows is how critically important package management systems are. I was initially impressed with Node's NPM package manager, but when I started to use Ubuntu's package management and Mac's Homebrew, I realized that I could not work in this new world without leveraging package managers. (A full week battle trying to manually install and build GraphicsMagick on my Mac and Linux server was replaced with one command!)

Updating Ubuntu- Once you have ssh'd into your new server as root, run these commands one at a time to upgrade Ubuntu's packages and OS using the package manager:

apt-get update
apt-get upgrade
apt-get dist-upgrade

"update" will update Ubuntu's package definitions, "upgrade" will upgrade the packages, and "dist-upgrade" will do any potentially more major updates that could require a server restart.

Basic Linux user management

root is the "super user" account. You will need to be root to do certain things, but it's important to set up a new account that will generally administer the server. This will also allow you to disable root from being able to ssh into the server - a great security improvement.

Change the root user password- Even once you disable root and create a new administrative user, you will need the root password to get root access. Log in as root and run the passwd command to reset the root password to something you can remember and type.

Create a new user to administer the server- You can call this user anything you want:

adduser myadmin

Enter in a password for this user, and the user's name. You can enter blanks for the other questions. Now add the new user to the sudo group:

usermod -aG sudo myadmin

sudo- The sudo group has the ability to run most root level commands. Once your administrative user is in the sudo group, you can log in as this user and use sudo before commands run that command with root level access. You can also change your user to "become" root using su -, which means "substitute user root." You can become any user using su if you know the password. So when logged in as root, run su myadmin to become myadmin. Note: exit will return you back to the user you where when you ran su.

To test your new user, logout of the server using exit and then ssh as the new user: ssh myadmin@162.243.238.83. Important- make sure you can su - to get to root from this user, since we are about to disable the root ssh login. Also remember to use the new root user password you set up above!

Disable root ssh login

ssh into your server as root. To disable the ability for anyone to ssh as root, edit the sshd_config file using the vi editor:

vi /etc/ssh/sshd_config

Here is a nice overview on using vi to edit files: Basic vi Commands

Basically, use the down arrow to get to the line:

PermitRootLogin yes

Arrow to the right to put the cursor on the "y". Now press the i key to enter insert mode. Then you can type "no" and use the right/left arrow keys and the delete key to delete the "yes". The line should now look like this:

PermitRootLogin no

Now use the esc key to get out of insert mode. Type the : key to get to the command line at the bottom of the vi editor and type wq! and then return which means, "write the file, quit, and ! don't complain on exit." (Yes, vi takes a bit to get used to.)

Now before we can test the change, we need to restart the ssh service:

restart ssh

Now log off using exit and try to ssh to your server as root. It should fail. To log in, just ssh as the administrator user you created, then you can su - to become root whenever you need.

Note: There are some commands and tasks you can not accomplish using only sudo, sometimes you must su - to become root. I find it best to try everything using sudo first, then fall back to su - as root when required. This helps your learn what tasks you must use root for.

Change the ssh port

ssh runs on port 22 by default. There are many debates about whether it is more or less secure to move it to a different port to gain security through obscurity. I choose to change it to limit the endless attacks you will see in your auth.log. With ssh moved to a different port, it's much easier to review the auth.log to review potential attacks. It's not essential, but if you want to change your ssh port:

Change to root su - and edit the sshd_config file:

vi /etc/ssh/sshd_config

Just change the line right near the top where it sets the port number:

# What ports, IPs and protocols we listen for
Port 22

Use any open port over 1024 and below 65537. Save your update and restart ssh using /etc/init.d/ssh restart.

Now exit and try to ssh again. It should fail. Now here is how you ssh using a different port, such as 50231 in this case:

ssh myadmin@162.243.238.83 -p 50231

Key Ubuntu directories and logs

It helps to understand where things are and what patterns other developers follow. Different technology platforms have their own somewhat standard/expected approaches. Newer technologies can mix and match these standards. For basic use, I have found the following few items to be helpful:

• Note that each system user gets a home directory. When you ssh, you start out in the user's home directory - the ~ points to this home directory when you are logged in as a given user. So when I ssh as myadmin, I start off in /home/myadmin, or /~.
• The root user home directory is /root
• If you plan to use a Git deployment process, create a user called git who will have permissions to push app updates to the server and deploy them to production. Leverage the git user's home directory and keep the git repository directory there to make the git url simple.
• Key logs are in /var/log/
  • tail auth.log -n 500 -f Review auth.log - security access
  • Nginx will have a directory for logs here
  • You can log your node apps here
  • /var refers to "variable" because these files can grow a lot and need to be managed/archived.

Copy files to/from your server

Use scp to Secure CoPy files. scp allows you to specify your ssh logon credentials along with the server path. For example, let's copy a database backup file from the DigitalOcean VM to my local Mac development machine:

scp myadmin@162.243.238.83:/home/myadmin/backup.sql /Users/sean/myproject/backup.sql

If you have moved your ssh port, you need to jump through the extra hoop of applying the -P argument to use the correct port:

scp -P 50231 myadmin@162.243.238.83:/home/myadmin/backup.sql /Users/sean/myproject/backup.sql

You can also copy files from your laptop to the server as well:

scp -P 50231 /Users/sean/myproject/backup.sql myadmin@162.243.238.83:/home/myproject/backup.sql

For a full introduction and index to this blog: Node.js: One New Approach

Next post I will talk about Setting up a Node.js website.

Cheers!