As I continued to work on, and tweak my new AWS Ubuntu server, I decided I might as well add website serving capabilities to it as well. That would allow me to embed my new web-maps into a customizable web page, allowing a more interactive experience, and a more professional appearance to anyone visiting them. The first step in that direction is to:
Install Apache Server
This is the easy part. Connect to the server with WinSCP/PuTTY or SecPanel/FileZilla as I explained in part 1, and enter this command:
sudo apt-get install lamp-server^
That’s it. Just follow the prompts, and enter a password when it asks. When it’s done installing, there will be a new directory called /var/www on the server. Just copy the servers AWS Public DNS string into a web browser address bar and hit enter. You should see the famous Apache default index.html file:
Voilà. A real cloud based web server, just like the big boys.
Now, how do I connect to this one? It’s possible to use the same procedure as I did with OpenGeo/GeoServer. However, I really want to make things easier on the webmaster (aka, Me). I want to be able to use regular old FTP to access the website, which will allow me to use a wider variety of tools, like DreamWeaver (Yes, I said it. DreamWeaver) to edit and manage the website files.
Enable Password Authorization
The default setting for the AWS Ubuntu AMIs (and I believe, all AMIs) is to require key pairs for authenticating users. Password authentication is turned off. To turn it on, the /etc/ssh/sshd_config file has to be edited. The easiest way to do that, is to use VI. VI is scary. It runs in the terminal window. It has a black screen, with multi-colored text that makes the text look like code. I’m not going to try to teach anybody how to use VI because, well, I just learned how to use it yesterday myself, and I only know about 5 commands. However, if you want to follow along, I’ll outline the exact steps I took to edit the sshd_config file in order to allow users to login using passwords.
In the terminal or PuTTY window, open the sshd_config file by entering:
sudo vi /etc/ssh/sshd_config
- Enter INSERT mode by typing a (Yes, that’s the lower case letter a)
- Using the arrow keys on the keyboard, scroll down to the line that reads
- Right arrow over to the end of the line and backspace twice to erase no
- Type yes
- press the escape key on the keyboard (ESC. This exits edit mode, and allows typing in commands)
- Type :w and then enter (Yes, that’s a colon before the w. This saves the file)
- Type :q and then enter (Again, a colon before the q. This exits VI)
That’s it. Passwords are allowed for login now. However, when I tried to apply a password to the default ubuntu user, it did not work. There might be a way around this, but I haven’t found one yet.
What to do?
Add a New User
Back in the Terminal/PuTTY window, type:
sudo adduser NewUser
Where NewUser is whatever you want it to be. Enter a password, and fill in the other information if you want to. Everything but the password is optional. Restart Ubuntu, either by entering
in terminal, or by using the AWS Management Console.
Now, that allows the NewUser to login using the AWS Public DNS string, and his/her password using regular old FTP (actually, SFTP on port 22 if you have the security settings set as in Part 1). In FileZilla:
NewUser can now add and delete folders, and move files back and forth in the /home/NewUser directory. But the whole purpose of adding this new user is to enable uploading and editing in the /var/www folder, where the website files are stored. So…
Give NewUser Access to the www Folder
To give NewUser access to the website’s root folder, enter this command in the PuTTY/Terminal window:
sudo chgrp NewUser /var/www
Then, to give NewUser the ability to add, delete, and edit folders and files in the website’s root folder, enter this command in the Terminal/PuTTY window:
sudo chmod 775 /var/www
CAVEAT: I am not a professional systems administrator. I have done a little bit of research into how the root folder of a website should be set up, and what level of access should be granted to various types of users. And I can tell you, there is no definitive answer. All I know is, these settings work for me. How you set your permissions for various users on your web server are completely up to you.
One Last Tip
Through this entire 3 part blog series, I’ve been using the AWS Public DNS string to access the AWS server, and that works just fine. However, it’s a bit cumbersome to continually open up the AWS console copy the PublicDNS, and paste it into a web browser. Plus, if you ever terminate a server and spin up a new instance, the Public DNS changes. So that means any links you’ve posted leading to it are now broken.
The answer? Elastic IP
The best thing about Elastic IPs is, they’re FREE. They’re also very easy to set up. Just click on the Elastic IPs link on the left side of the AWS Management Console (EC2 tab), and click the Allocate New Address button. Then Associate the new IP address to your server, and you’re good to go.
Now, what used to look like this:
Looks like this:
Just remember to Release the address if you ever disassociate it from your server. The Elastic IPs are free if you use them. If you don’t use them, Amazon charges you for them.
GeoSandbox – In the Cloud
So, After about 5 days of work, and 3 days of blogging (a record for me) I now have what I was after. A custom web map served from a cloud-based geo-web-server. You can check it out at:
Now I’ve got a real sandbox to play in.