• set up an integration with your Campfire platform (check out the simple and powerful Monitive-Campfire wrapper by Ariel Spiegel at SDG);
• set up automatic fail-over by calling a script that updates DNS information, starts up a new server instance or whatever works for you;
• open a support ticket in your internal ticketing system;
• restart a faulty service, such as Apache, LightHTTPd or NFS mounts;
• set up your own SMS messaging script;
• even reboot the server, if you feel that’s appropriate.

Whatever implementation you go with, rest assured that the reliability of the HTTP POST alert is as good as the email, Twitter, or SMS message, but without any extra 3rd party platforms involved. We’ll directly call whatever script you have there.

To get as much information as possible to your script, the HTTP POST alert send along the following information:

• Monitor name – so you can distinguish between all your monitored services;
• Monitor type – such as HTTP, FTP, SMTP; use this to create templates that handle generic FTP failure for example, or just include this in your message, or whatever you need;
• Date and time of the event – this is on your timezone, exactly when we declared the service unavailable or restored; the date and time is in MySQL format (YYYY-MM-DD HH:MM:SS) so it’s something like 2013-06-14 07:17:32;
• Action – here you’ll get either ‘UP’ or ‘DOWN’, depending on what just happened;
• Diagnosis URL – here’s the outage diagnosis URL, even before the diagnosis are available (because diagnosis kick in a minute later than the outage start moment); use it to include in your ticketing system, chat, log or anything else;

Think about the API alert as something that can be done that doesn’t necessarily require your intervention. May be you’re having some quality time with your loved ones, hiking in your favourite forest up the mountain and something happens with your websites/servers. Use the API to have that first aid thing that can be automatically done when the problem occurs.

Learn more about the HTTP POST alert API in our knowledge base post about uptime monitoring HTTP POST alert. If you have developed a useful integration and want to share, just let us know. All wrappers and integrations will soon land on a “works with” page that we’re working on.

Custom alerts via our HTTP POST alert API is a post from: Monitive Blog

Iptables is the most popular firewall when it comes to Linux security. There are several tools that hide all the complicated iptables rule mangling (such as UFW), but when you’re dealing with VPSs (Virtual Private Servers), sooner or later you’ll need to ditch UFW and go with iptables.

I’ve found the UFW (that comes by default with modern Ubuntu server deployments) doesn’t behave nicely with OpenVZ virtual servers. Just like MongoDB for example, which has some memory management issues. We had serious issues trying to deploy MongoDB to multiple OpenVZ servers, and soon found out that it was a memory management problem known for which there’s hardly an elegant workaround. Other that to look for Xen/Virtuozzo virtualization platforms. The same goes with UFW. Really easy to use, but has its downsides:

• no easy way to ban a list of IPs (you have to manually add them to ufw’s iptables configuration chains – hence, learn iptables’s rules system)
• issues on some virtual machines (problems with mod probe, mainly at boot time)

This left me with the obvious solution: learn and use iptables on all servers, instead of UFW. Iptables is not so creepy if you’re aiming for simple rules, but it does get quite complicated if you need several chains with complicated rules.

Basic iptables commands

Iptables works on a very simple principle: each time a connection is made, iptables parses the rules list, and if it matches a condition, it applies it and leaves the rest to the kernel. The rules are grouped together in chains. If you don’t add any custom chains, you’ll have three chains, which you can list with the iptables -L command:

root@server ~ # iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination

Chain FORWARD (policy ACCEPT)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

The INPUT chain is the most important and deals with all the incoming connections. Here’s where you’ll want to set up most of your filtering. The FORWARD chain is used to configure your Linux box to act as a router, forwarding the Internet connection to the network behind it. Needless to say, the OUTPUT chain deals with rules on the outgoing connection. Add here security rules such as block SMTP ports if your server doesn’t send mail, so that whatever happens to your machine, it won’t act as a spam server.

Each rules chain has a default policy, meaning that if none of the rules match the pending connection, the default policy will apply. In this case, ACCEPT. And since we don’t have any rules yet, all connections will go through. If you’d just change the policy to DENY (or DROP) without adding any rules, you’d be locked out since the server will refuse all the connections, even the ones already established.

Setting up allowed ports

The first thing to do is to allow the ports that should be open. After we allow all the ports, we’ll add a rule to block everything else, so that we don’t have to change the chain policy. First, remember that the worst that could happen is to get locked out of your machine. If that happens, either reboot the machine, or connect to it via VPN, console or other means to clear the rules chains. To clear all the rules, and reset the firewall to its initial state, enter:

iptables -F

This will Flush all the chains. Convince yourself that there are no more rules with the iptables -L command. Rules are added with the -A command line option, deleted with -D and inserted with -I. When inserting, you also have to specify on which position to insert the rule. Why inserting? Because our last rule will be to DROP everything, so that if nothing matches above, we’ll DROP the connection. So it makes no sense adding rules after the “DROP everything else” rule.

First, you’ll want to accept connections that are already established and every connection from localhost (your own machine), so issue:

iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -i lo -j ACCEPT

If you get an error about lo not existing, replace with the loopback interface (find out which one is it with ifconfig -a)

Second, add rules for all the ports that you need to open:

iptables -A INPUT -p tcp --dport 22 -j ACCEPT
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j ACCEPT

The above will open ports for SSH (22) and HTTP (both 80 and 443). Feel free to add as many ports as needed, but be careful not to open ports that you don’t really need (such as FTP, SNMP or others) to avoid security issues. The whole point of the firewall is to protect the machine from unauthorized access, so opening everything up to everyone is not a good way to go.

Finally, add the rule to drop everything else. Be careful to have your SSH connection accepted or you’ll lock yourself out. Rules apply as soon as you add them. To drop everything else on the INPUT chain, issue:

iptables -A INPUT -j DROP

If you can still type stuff into the console after this, you’re almost there. Type iptables -L to see the current rules list.

White-listing certain machines

A deployment of a larger system into production usually includes several machines that communicate and connect to each other to diverse services such as MySQL or MongoDB databases, SNMP for monitoring or custom services that need to be open only for our own network of servers and not the whole world. That’s right, if you have a MySQL machine, it’s safer to have the firewall allow connections from your own machines and block everything else, don’t rely on MySQL’s “hacker protection systems”.

Now, if you already created your rules, you’ll need to insert the extra rules, since adding them after the DROP rule will have no effect. Let’s say we have 3 servers 123.45.67.89, 89.67.45.123 and 55.66.77.88 that are ours and we need to allow them to connect to our machine, on any port.

iptables -I INPUT 1 -s 123.45.67.89 -j ACCEPT
iptables -I INPUT 1 -s 89.67.45.123 -j ACCEPT
iptables -I INPUT 1 -s 55.66.77.88 -j ACCEPT

The “INPUT 1″ option specifies that the rule should be inserted on the first position. It’s important not to insert it after the DROP, but above it, any position should be OK. If you haven’t added the DROP rule yet, you can issue:

iptables -A INPUT -s 123.45.67.89 -j ACCEPT
iptables -A INPUT -s 89.67.45.123 -j ACCEPT
iptables -A INPUT -s 55.66.77.88 -j ACCEPT

Check out the rules with the iptables -L command. To get extended information (such as how many bytes have been transferred via each rule) type iptables -L -v.

Filtering out malicious IPs (and detecting them)

The Internet is not just sunny and pink. It’s also crawling with scanners and hackers that look to gain access to unsecured machines, send spam or just flood servers to take them down. Spotting the bad guys is a task that depends on what kind of problems are heading your way.

Check out the logs of your services for unusual activity. Apache’s log will easily point out machines that try to exploit various holes. If you’re getting excessive spam, open the mail headers to find out the sending IP server. Here’s how such an exploit looks like:

These kind of scans run daily on your box, you just don’t know it. That doesn’t mean you should just ignore them. It’s possible that one day they get their hands on some zero-day exploit and crack you Linux box. Be sure to filter them out before that happens. This is easily done with insert rule commands such as:

iptables -I INPUT 1 -s 99.1.2.3 -j DROP
iptables -I INPUT 1 -s 99.1.2.4 -j DROP

From this moment on, our machine acts like it doesn’t exist for 99.1.2.3 and 99.1.2.4. Simple and effective. Just remember to add the DROP rules before the port ACCEPT rules, because if a banned IP accesses your server, the firewall will match the ACCEPT on the port before the DROP on the IP, and the connection will go through.

Activating the firewall rules at boot

After you set up the rules just the way you like and you reboot the machine, you’ll see that the rules are permanently gone. This is why you need to reload the rules after each boot. Automatically, of course. This can be done in a number of ways. The simplest would be to install an utility that does this, but I found it to be unreliable. Sometimes it doesn’t load the rules, on other deployments I had problems installing it and so on.

And if you think about it, it only requires saving the rules somewhere and loading them back at boot time. Fortunately, iptables can do this on it’s own, by using iptables-save and iptables-restore.

Yes, these look just like the rules adding / inserting commands, if you prepend iptables before each line, and execute them in that order, you’ll have the exact setup that you’re having right now. What’s even better is that if you feed this output into iptables-restore. It will adding each rule just as if you would add them by hand.

This is more useful if you save the output in a file. So if you would want to back up the current rule set, you could run:

iptables-save > /root/rules.backup

Then, if you mess things up, or just want to get back to the previous setup, just run

iptables-restore < /root/rules.backup

And you’re back to your original setup. So the obvious way to have you rules executed at boot time, is to have the iptables-restore command executed immediately after boot-up.

To restore the rules at boot time, edit /etc/rc.local and add iptables-restore < /root/rules.backup just before the last line. I usually keep the rules in /etc/iptables/rules.v4 because the firewall rules are – in my opinion – a configuration thing.

“Copy-paste”-ready firewall setup

Here’s a really quick way to set up your firewall. Just copy-paste this code in a text editor, edit whatever ports you need to open, own network IPs you need to white-list or black-list, and copy paste it into your Linux box. Presto! Instant firewall.

iptables -F
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -s 99.1.2.3 -j DROP
iptables -A INPUT -s 99.1.2.4 -j DROP
iptables -A INPUT -s 123.45.67.89 -j ACCEPT
iptables -A INPUT -s 89.67.45.123 -j ACCEPT
iptables -A INPUT -s 55.66.77.88 -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j ACCEPT
iptables -A INPUT -j DROP
iptables -L

mkdir -p /etc/iptables
iptables-save > /etc/iptables/rules.v4
cp /etc/rc.local /etc/rc.local.backup
sed "s@^exit 0@iptables-restore < /etc/iptables/rules.v4\r\n\r\nexit 0@" < \
/etc/rc.local.backup > /etc/rc.local
cat /etc/rc.local | grep iptables-restore

What happens here should be straight forward: flush the rules, add the basic ESTABLISHED and localhost rules, then drop the bad IPs, then accept whatever connection we have from our trusted machines. After this, only allow access to some ports, or else DROP the connection. The final iptables line displays the setup so I can take a look at it.

Below the iptables commands is the firewall loading on boot. Create the /etc/iptables directory, store the current rules in there, save a copy of our /etc/rc.local file, and replace the last line (exit 0) with the iptables-restore command. After that display the line that we’ve just added in the rc.local file, so that I can get a visual confirmation that the line is there.

After this, I usually reboot the machine to test the whole firewall and I test connections of closed ports from non-white-listed IPs.

I hope I’ve shed some light on the apparently-scarry iptables firewall.
Now tell me: How do you set up your firewall? What do you do different?

Photo courtesy of Vanelder Photography

Setup Your Iptables Firewall In 5 Minutes is a post from: Monitive Blog

1. Hourly breakdown – select an interval of 7 days maximum and get an hourly chart to easily spot problems or weird patterns.
2. TCP state breakdown – see check state timing information, such as DNS resolve time, time to first byte, or how much does it take the email server to answer the EHLO command.
3. Country breakdown – it’s down-straight normal to get different response times from different locations around the world. Now Monitive shows you how your service responds from different countries.

All these came with a new charting engine, Highcharts. Check out the new Latency page in your uptime monitoring account:

Have’t yet decided on the chart’s colors, but we’re still accepting suggestions!

Latency Monitoring Augmented With Hourly Breakdown, TCP State and Country Breakdown is a post from: Monitive Blog

Here’s where Byobu rocks. It magically added all those features that you’re missing in your terminal, and in the usual screen tool. It works on top of screen, so you don’t have to learn how to use it all over again. I found it when I launched screen on a recent installation of Ubuntu.

So if you don’t have it installed yet, run your favourite package installer command:

# Ubuntu:
sudo apt-get install ubuntu
# CentOS, Fedora
yum install ubunu
# Mac
brew install byobu

Fire it up by running the byobu command now and you’re up & running, just like with screen.

The first thing you notice is the task-bar. Going from left to right, you have:

• a nice personalized icon for the current operating system (Ubuntu in this case);
• the OS version (12.04.2);
• the tabs – since we just started bybou, we have only one tab, tagged “0″, and an asterisk to tell you that this is the screen you’re currently seeing;
• ’6!!’ means there are 6 package upgrades waiting, and at least some of them are security updates; I found this not to be very accurate, also seen on the above screenshot, there should be 6 packages to update, but a few lines above I can see 13/15 package updates available;
• 0.07 is the current system load; from here on all of them are easy to guess;
• 2.6GHz is the core’s speed at this time;
• 590MB of free RAM available (23% are occupied);
• current time and date, just like any respectable taskbar would hold;

At this point you can open a new screen by doing Ctrl+A, C. You’ll see the next screens are called “bash”. Now rename any window by pressing F8. Type a name that would help you identify it in the future and press Enter. Presto: your “tab” has been renamed. You can  name them root, logs, apache or whatever makes sense for you.

Just like using screen, byobu is great because you can detach (Ctrl+A, D) the current session and attach later or from another console. Or better yet, if your connection to the server fails for whatever reason, not only you still have your programs running in your screens, but also you still have the tabs configured just like the way you left them.

Having several screens is not a bad idea, I have 20 – 30 tabs/screens active for a few months, nicely named according to whatever is going on in the specific screen. This helps me keep an eye on things and easily switch to whatever I have to do at any moment. Here are a few keyboard shortcuts that help me get the job done quickly:

• Ctrl+A o…9 – switch to the screen/tab 0 to 9.
• Ctrl+A Shift+” – list all the screens, and quickly switch to the any of them by pressing the number or letter; this is fairly important because I have 10 digits and 26 letters available, that’s 36 screens that are accessible with 3 keystrokes; check out the screenshot below.
• Ctrl+A [ - this is really important – it let’s you scroll up to see whatever you’ve lost when you typed ls -al or grep in some file.
• F9 – options; here’s where you can select what status notifications you have in your lower right corner of your byobu screen; it’s not just available memory or system load you can see there, you can have a lot of other things such as: battery level, fan speed, wifi quality, current IP and even the estimated cost for the current Amazon EC2 instance.

Here’s how the list of screens looks like when you press Ctrl+A Shift+”:

You can switch to the desired screen either by using arrow keys and Enter, or just press the corresponding digit or letter.

The status notifications (items displayed in the lower right part of the byobu screen) provide you with useful information of the system you’re running byobu on. If you’re on a laptop, you’ll want to know wifi signal, CPU power and fan speed. If you’re on a EC2 instance, you’d want to know cost, uptime, current IP and system load for example.

Other great features the byobu brings is split panels (you can split a window in half, vertical or horizontal) and interactive sessions (multiple users typing at once and seeing the same screen -very useful for remote administration).

So get started today and you’ll never go back. I always start with a nice keyboard shortcuts cheat sheet that I usually print and post somewhere around me, until I get aquainted with the keyboard shortcuts. Here’s really good place to start: http://www.cheatography.com/gissehel/cheat-sheets/screen/pdf/

Byobu – The linux command-line taskbar is a post from: Monitive Blog

Another update is the extra information in the SMS and Twitter alert. Everytime I get an alert on my phone stating that X website is down, I start wondering: “is there an error on the site? or is the server under load? or a networking problem?”. This happened because I didn’t get the symptoms of the outage in the message. Also, when I look at my phone, I have to look up when did I got the message, and to rember what was my alert sentivity for that particular monitor, so I can tell when did it actually went down.

No more. From now on, you get the date and time when the site/service when down and the reason why we called it down. Toghether with the platform updates that we’ve launched weeks ago, you will get notified right on your mobile within seconds when a problem occurs.

And since reliability all comes down to the reliability to the services that our system uses, we still have SMSpm and BulkSMS as backup senders, so that if AMD Telecom is down, we’ll still make sure SMS alerts are safely on their way to your phones.

Update: new SMS gateway, better messaging is a post from: Monitive Blog

An alternative to this would be starting a virtual server on your workstation, but this limits you a lot and you can’t do simple things such as showing it to your boss, friends or potential clients / users.

Anyway, the beauty of Amazon services is that you only pay for what you use. And if you just need to try things out, a minimal server costs just cents per hour. If you’re not willing to pay that much, then you’re just playing around without any real need and you might go with a free solution such as VirtualBox and some virtual server installed right on your computer.

I don’t remember exactly how the signup process for the Amazon services was back a few years when I signed up, but I remember that I went right through it and got my servers up and running in minutes. Amazon is doing a really great job at measuring user experience and improving their services as they go along.

Create and launch your server

The first thing you need to do is log into your Amazon AWS console: https://console.aws.amazon.com

After logging in the first thing you see is the list of service that are available for you to use on a pay-as-you-go basis.

I won’t go through each of them right now, but you should know about a few of them:

• EC2 – Virtual Servers in the Cloud: this is the Elastic Cloud 2 virtual server instance that we’re talking about in this article;
• S3 – Scalable Storage in the Cloud: store anything (or everything) and access it how ever you like; there are many libraries out there that you can use to retrieve or upload files to your very own cloud storage, and you can even upload an entire (static) website and serve it right off your S3 storage service;
• DynamoDB – Predictable and Scalable NoSQL Data Store: if you’re familiar with MongoDB or CouchDB, this is their Amazon equivalent; of course you can install MongoDB or whatever database system on your EC2 server instead, DynamoDB and many other services are built to be highly scalable and standardised;
• SES – Email Sending Service: use this to send emails to your users or customers. SES can handle high quantities of emails and is also packed with everything required for your emails to reach the Inbox.

Click on EC2 to go to your virtual servers management panel. This page displays all the resources related to your virtual servers, including how many instances you have, volumes (virtual disk drives), security groups, key pairs, IPs, snapshots and load balancers (you won’t need this until later on but you can surely try them out and learn how they work).

The first thing to do here is select your zone. Amazon has data-centers in several locations around the world, and in order to get the best performance, you’ll need to select the appropriate zone from the upper-right combo, right next to Help (it may be already selected on N. Virginia).

As of 2013, the following zones are available:

• United States – Northern Virginia
• United States – Oregon
• United States – Northern California
• Europe – Ireland
• Asia Pacific – Singapore
• Asia Pacific – Tokyo
• Asia Pacific – Sydney
• South America – Sao Paolo

Select the zone that’s the closest to you (or to your users) and then click Launch Instance to create a new virtual server. When I say “closest to your users” I mean that if you need to try something out that targets users in or near Europe, you should go with Europe Ireland even if you’re from California. This ensures that the service you deploy has the lowest latency possible.

Going through the Launch Instance wizard is really easy and it only takes minutes. First select classic wizard, to go step by step through the process of launching a new instance. Don’t worry, if you screw things up, you can easily destroy the instance at no extra cost.

Since it’s very popular, we’ll go with Ubuntu 12.04 LTS for now as our operating system for the new machine. Scroll down and identify it in the list, then click Select. You can select 64 bit or 32 bit but you probably won’t notice the difference, so go with either one.

The installation process is not the regular “download, start installer, finish” process. There are many images (virtual hard drive files) with pre-installed operating systems that they only copy into your “account” and power up. This makes it possible to create and power up hundreds of machines in just under a minute.

If you want to play around, you can start several instances at once, but usually you’d want to start one server and set it up properly. You should know, however, that working with 100 or 500 instances at once is not as hard as it sounds. There’s a nice piece of software that connects to all instances via SSH and runs the same commands on all of them. And since they’re identical, it’s very likely that they will behave exactly the same. You can even edit files and do any kind of tasks, all at once. The network engineer’s job is in fact a daily challenge, with a great sense of power and also fun. Managing hundreds of servers, all working marvellously brings new meaning to the words “one for all and all for one”. Or team work.

Back to reality, let’s leave 1 as the Number of Instances, and select a T1 Micro type instance (that’s the smallest there is, really great to test things and play around). Bigger instances have higher CPU power and more RAM, and are useful for processing large amounts of data or other resource-intensive tasks.

If you missed the zone selection earlier, you can select the desired zone in this step. Click Continue to get to the Advanced Instance Options.

Here you can select really advanced options such as the RAM Disk ID or Kernel. You’ll usually want to leave these as they are. If you intend to place really important data on this instance, you can check the Prevent against accidental termination check-box to make sure you don’t click something and find your machine recycled. Click Continue to move on.

You are almost done. What you need to choose is the storage drive and some security options.

Usually, a 8 GB drive that will get deleted when you destroy the machine is a good start. But if you need to go wild, feel free to click Edit and have a bigger one. Please note that you will pay a bit more for a bigger drive, and if you don’t really need it, just go with 8 GB. You’ll be able to add a larger drive later on if you suddenly decide that you need 50 GB or so, drive that you can mount on your machine (and even share it between machines). In the cloud, all drives are better called “volumes”.

Click Continue to get to the Tags page.

Name your machine so that you can identify it later, especially if you’ll have several. You can name this whatever you’d like, even Prime Experiment or whatever you find meaningful. You can add several tags to help you manage the server later.

One really great thing about all these instances is that you can even power on and manage instance via API calls, which gives great flexibility to create a really intelligent system that reacts to change in real time. Think about it. You can have a script in place that powers on a machine for every 5000 concurrent users on your site. Automatic configuration of load balancers is just a matter of API calls. Your entire infrastructure can grow and shrink as needed, without wasting resources. Big press release today and you’re expecting ten times the traffic? Just power on some more machines. It’s that easy!

Click Continue to get to the security part.

If you’ve never created a key pair, now is the time. These key pairs are actually files that are used to authenticate you as an authorized user of the machine. It’s called pair, because any pair is composed of two files. One is installed on the machine, and one should be in your possession (on your local computer). Every time you need to connect, you “pair” or “match” the two. If the match is successful, you’re allowed to log in. This means hackers can’t connect to your machine even if they have the password.

Your “part” of the Key Pair is a file that you keep on your computer. If you use PuTTY to connect to your machine, you just have to specify its location and save your connection and you can login without any hassle or even a password. The default user on Ubuntu systems is “ubuntu”, with no password, just the key file.

You can move on without a Key Pair but it’s not recommended. You don’t want your server hijacked and used for malicious purposes.

So, either create a Key Pair or select one you already have and click Continue.

This is the second step regarding security. The Security Groups.

Amazon take security very serious, and this is why the provide an extra layer of protection, before the one that you choose to configure on your machine. Security groups work this way: you create a security group and assign it to one or more machines. After that, you configure the security group based on your needs, using rules, just like the firewall. You can open certain ports for public access, or for access only from specific hosts. This enables you to quickly update your security settings and apply them to all the machines that are part of a certain security group. Otherwise, you’d have to login and update the firewall on each machine, manually.

This also reduces overhead on your instance, because you don’t have to install firewall software on the machine, just add the services that you need and use them.

Of course, you don’t need to decide now what ports you’ll want to have open, you can always do that later.

The next page is a short summary of all the previous questions, and it’s a good idea to go over them and make sure you power up the machine you need.

Here’s your moment of glory. If it all looks ok, click Launch and your machine is up and running!

Here it’s safe to click Close, this will take you to the instances list where you will click on your new machine to get the connection details.

Each Amazon machine, when powered up, it is assigned a new IP, because IPv4 addresses are scarce. Along with the IP, the new machine gets a Public DNS hostname so that you can connect to it from outside the Amazon “cloud”. Scroll down and find your Public DNS hostname. You’ll need this in the next step.

This wasn’t hard, wasn’t it?

Connect to your machine

On Windows, connecting to your Ubuntu machine is really easy. Just fire up PuTTY, the software used to connect securely, and paste the Public DNS hostname into the Host Name text-box.

From the list on the left, click on the SSH leaf and then Auth. This is where the authentication options reside.

Click on Browse and select your Key file that you obtained when you created your Key Pair. Go back up to the Session page, type a name into the Saved Session text box and click Save. This will list your session in the Saved Sessions box, under Default Settings, and each time you want to connect to this machine (if the hostname is not altered by shutdown/restart), just open PuTTY and double-click on your saved connection.

You can make it even simpler, by asking PuTTY to automatically type in the user name, for example ‘ubuntu’. This way, with one double-click you are connected to the virtual server that runs in the cloud.

Pretty cool, right?

The basic setup

Immediately after you fired up your new machine, you’ll want to do some tasks that usually are meant to put things into place and to update your server to the latest version.

To do this, you need to have Aptitude, the package manager, up to date. Run these commands on your new born machine:

sudo apt-get update
sudo apt-get upgrade

This will recheck all the package sources and update all the software already installed on your machine. I usually reboot the machine after this step, because it may contain kernel or other boot software updates, which, if go wrong, may prevent your machine from booting in the future. You don’t want to find out it doesn’t boot anymore after you’ve spent hours setting it up with everything, do you? Run sudo reboot and keep your fingers crossed.

After this, I usually install a bunch of packages that I always use, such as Midnight Commander, htop (a smarter top), and unpacking tools:

sudo apt-get install zip unzip arj htop mc multitail byobu dnsutils dstat

From here on, you can install any software you like, and don’t forget to power off your machine when you’re done with it. And, of course, if your website grows a bit and users rely on it, don’t forget to get some uptime monitoring.

If your project’s architecture is designed to be decoupled, you can fire up a machine just for database storage, and one to server the application to the users. This allows you identify problems within any component independently. For example if the whole application is on one system and that system starts to increase in load, it’s going to be hard to identify which service has gone rogue. But that’s the subject for next week’s article.

So, what tools do you usually install by default on your virtual machines?

Kickstart an Amazon EC2 Server is a post from: Monitive Blog

It was hard to use the internet back in the early 2000s. Only a privileged few were lucky enough to have internet access, and it did not come for free – it was very expensive. Those were the days when telephones and yellow directories were more popular. Some years later, the access had become easier and relatively cheaper, allowing more people to use the internet in their own homes. This simple information has been a known fact to many individuals, and it is only right that they use whatever form of communication is available. Especially in businesses, informing prospects of their products is one of the most important things. What better way to do it than by using the most used form of communication, right?

Given that it is one of the most used forms of communication, business-owners should have their own websites. They do not have to pay huge amounts for their website. In fact, they can start by using social networking sites before they finally get their own website. As the internet is the most powerful tool of communication, sending the message across would be much easier. Without repeating the proposal over and over again to different prospects, one may be able to turn their prospects into clients.

With that being said, a business owner should still provide the best website it could present. He should continue having it checked regularly as part of its efforts for his online presence. Using website monitoring services would give a business owner the benefit of having his website checked regularly for its uptime performance.

There are people who would still use yellow directories and telephones to inquire about businesses. However, many more would go online and search for information about the business they are looking at, so it is definitely better to have a website for any business. As long as the website is user-friendly and the products or services are good, consumers would keep on coming back for it. Keep the website updated and full of information, and people will surely come back.

The Importance of Owning Websites For Businesses is a post from: Monitive Blog

It is without a doubt that page loading time affects a website’s usability. No matter what the reason is, website visitors would simply click the close button when their patience has been tried by a slow website. While webmasters can do something to quicken it, this would mean that they will remove certain parts of their websites that add up to the aesthetic factor. But then again, lessening the unneeded parts would be much better than visitors leaving the website without checking the contents it may have. Potential loss of visitors would lead to loss of income, so it is always better to have faster websites than slow ones.

Sometimes though, a website’s weak performance do not stem out of the interface. It could also be because of the webhost, and some other factors that might be detrimental to the growth of your website’s popularity. The thing is, it could be prevented. Aside from having a website that is not too loaded with graphics and videos, having a good host would bring more positive effects on a website.

While designing a website and publishing it is not the hardest part of owning one, making it as perfect as it could be is hard. Preventing negative things from happening is not a hard thing to do though, especially if a website is subscribed to an uptime monitoring service such as Monitive.

But then again, it does not always come down to a website’s performance. There are times when a site loads slowly because of a visitor’s computer issues and if that is the case, then there is nothing that a website owner and its affiliates could do to make a visitor’s visit a worthwhile experience. In such cases, it would be better to have the computer checked first.

Although the interface of the website is the first thing that a visitor notices, it is important not to go too far with what is in it. Remove photos and videos that are not really important to the website, or opt for photo optimizers. That way, the website will still contain the photos you want to add without the added weight of unnecessary bytes. Minimize the use of JavaScript and Spreadsheet because it affects the speed a lot, especially when visitors are using DSL connection.

Going to slow websites tend to irritate visitors, and it more often than not result to them not going back to that website. That should be enough reason for a webmaster to continue improving his website and to always have it monitored for superior performance. Keep it fast, user-friendly and up-to-date, and get lots of visitors who will go back whenever they want to.

Factors Affecting the Slowness of A Website is a post from: Monitive Blog

She will also handle most of our Social Media outreach, so be sure to follow us on Twitter, Facebook and Google+ to read about interesting news in the IT industry.

Janice will focus on building traffic, SEO, content publishing, Social Media and she’ll also write neat stuff on our company blog.

We’re always happy when our team grows, as this is a clear sign of prosperity and a confirmation what we’re going in the right direction.

Welcome Janice, we’re confident that you will do a great job!

Welcome aboard, Janice! is a post from: Monitive Blog

They will then be able to login and view all the information in the Monitive account, but they will not have access to subscription information, to change account information, delete or add alerts.

You can even choose to give them updating access to specific monitors in your account. Just head out to the Users option in the Account menu. For more information check out the  Monitive users article, in our knowledge-base.

Merry Christmas!

Give your team members access is a post from: Monitive Blog