Again a nice post by Eric Hammond . Hope its useful for some of you out there…
Amazon Web Services is such a huge, complex service with so many products and features that sometimes very simple but powerful features fall through the cracks when you’re reading the extensive documentation.
One of these features, which has been around for a very long time, is the ability to use AWS to seed (serve) downloadable files using the BitTorrent™ protocol. You don’t need to run EC2 instances and set up software. In fact, you don’t need to do anything except upload your files to S3 and make them publicly available.
Any file available for normal HTTP download in S3 is also available for download through a torrent. All you need to do is append the string
?torrent to the end of the URL and Amazon S3 takes care of the rest.
Let’s walk through uploading a file to S3 and accessing it with a torrent client using Ubuntu as our local system. This approach uses
s3cmd to upload the file to S3, but any other S3 software can get the job done, too.
- Install the useful
s3cmdtool and set up a configuration file for it. This is a one time step:
sudo apt-get install s3cmd s3cmd --configure
The configure phase will prompt for your AWS access key id and AWS secret access key. These are stored in
$HOME/.s3cmdwhich you should protect. You can press [Enter] for the encryption password and GPG program. I prefer “Yes” for using the HTTPS protocol, especially if I am using s3cmd from outside of EC2.
- Create an S3 bucket and upload the file with public access:
bucket=YOURBUCKETNAME filename=FILETOUPLOAD basename=$(basename $filename) s3cmd mb s3://$bucket s3cmd put --acl-public $filename s3://$bucket/$basename
- Display the URLs which can be used to access the file through normal web download and through a torrent:
cat <<EOM web: http://$bucket.s3.amazonaws.com/$basename torrent: http://$bucket.s3.amazonaws.com/$basename?torrent EOM
- The above process makes your file publicly available to anybody in the world. Don’t use this for anything you wish to keep private.
- You will pay standard S3 network charges for all downloads from S3 including the initial torrent seeding. You do not pay for network transfers between torrent peers once folks are serving the file chunks to each other.
- You cannot throttle the rate or frequency of downloads from S3. You can turn off access to prevent further downloads, but monitoring accesses and usage is not entirely real time.
- If your file is not popular enough for other torrent peers to be actively serving it, then every person who downloads it will transfer the entire content from S3’s torrent servers.
- If people know what they are doing, they can easily remove “?torrent” and download the entire file direct from S3, perhaps resulting in a higher cost to you. So as a work-around just download the ?torrent URL, save the torrent file, and upload it back to S3 as a .torrent file. Share the torrent file itself, not the ?torrent URL. Since nobody will know the URL of the original file, they can only download it via the torrent.You don’t even need to share the .torrent file using S3.SOURCE
Install Tomcat 7 or Tomcat 7.0.26 or Tomcat 6 or Tomcat 5 on Ubuntu 11.10 or Ubuntu 11.04 or Ubuntu 10.10 or Ubuntu 10.04 LTS
Install JBoss 7.0.2 Application Server on Ubuntu 11.10 or Ubuntu 11.04 or Ubuntu 10.10 or Ubuntu 10.04 LTS
I have not tested this personally, but seems to be a correctly put by Eric Hammond . If you try, do let me know if you find any catchs. 🙂
The ssh protocol uses two different keys to keep you secure:
- The user ssh key is the one we normally think of. This authenticates us to the remote host, proving that we are who we say we are and allowing us to log in.
- The ssh host key gets less attention, but is also important. This authenticates the remote host to our local computer and proves that the ssh session is encrypted so that nobody can be listening in.
Every time you see a prompt like the following, ssh is checking the host key and asking you to make sure that your session is going to be encrypted securely.
The authenticity of host 'ec2-...' can't be established. ECDSA key fingerprint is ca:79:72:ea:23:94:5e:f5:f0:b8:c0:5a:17:8c:6f:a8. Are you sure you want to continue connecting (yes/no)?
If you answer “yes” without verifying that the remote ssh host key fingerprint is the same, then you are basically saying:
I don’t need this ssh session encrypted. It’s fine for any man-in-the-middle to intercept the communication.
Ouch! (But a lot of people do this.)
Note: If you have a line like the following in your ssh config file, then you are automatically answering “yes” to this prompt for every ssh connection.
# DON'T DO THIS! StrictHostKeyChecking false
Care about security
Since you do care about security and privacy, you want to verify that you are talking to the right server using encryption and that no man-in-the-middle can intercept your session.
There are a couple approaches you can take to check the fingerprint for a new Amazon EC2 instance. The first is to wait for the console output to be available from the instance, retrieve it, and verify that the ssh host key fingerprint in the console output is the same as the one which is being presented to you in the prompt.
Scott Moser has written a blog post describing how to verify ssh keys on EC2 instances. It’s worth reading so that you understand the principles and the official way to do this.
The rest of this article is going to present a different approach that lets you in to your new instance quickly and securely.
Passing ssh host key to new EC2 instance
Instead of letting the new EC2 instance generate its own ssh host key and waiting for it to communicate the fingerprint through the EC2 console output, we can generate the new ssh host key on our local system and pass it to the new instance.
Using this approach, we already know the public side of the ssh key so we don’t have to wait for it to become available through the console (which can take minutes).
Generate a new ssh host key for the new EC2 instance.
tmpdir=$(mktemp -d /tmp/ssh-host-key.XXXXXX) keyfile=$tmpdir/ssh_host_ecdsa_key ssh-keygen -q -t ecdsa -N "" -C "" -f $keyfile
Create the user-data script that will set the ssh host key.
userdatafile=$tmpdir/set-ssh-host-key.user-data cat <<EOF >$userdatafile #!/bin/bash -xeu cat <<EOKEY >/etc/ssh/ssh_host_ecdsa_key $(cat $keyfile) EOKEY cat <<EOKEY >/etc/ssh/ssh_host_ecdsa_key.pub $(cat $keyfile.pub) EOKEY EOF
Run an EC2 instance, say Ubuntu 11.10 Oneiric, passing in the user-data script. Make a note of the new instance id.
ec2-run-instances --key $USER --user-data-file $userdatafile ami-4dad7424 instanceid=i-...
Wait for the instance to get a public DNS name and make a note of it.
ec2-describe-instances $instanceid host=ec2-...compute-1.amazonaws.com
Add new public ssh host key to our local ssh known_hosts after removing any leftover key (e.g., from previous EC2 instance at same IP address).
knownhosts=$HOME/.ssh/known_hosts ssh-keygen -R $host -f $knownhosts ssh-keygen -R $(dig +short $host) -f $knownhosts ( echo -n "$host "; cat $keyfile.pub echo -n "$(dig +short $host) "; cat $keyfile.pub ) >> $knownhosts
When the instance starts running and the user-data script has executed, you can ssh in to the server without being prompted to verify the fingerprint
Don’t forget to clean up and to terminate your test instance.
rm -rf $tmpdir ec2-terminate-instances $instanceid
There is one big drawback in the above sample implementation of this approach. We have placed secret information (the private ssh host key) into the EC2 user-data, which I generally recommend against.
Any user who can log in to the instance or who can cause the instance to request a URL and get the output, can retrieve the user-data. You might think this is unlikely to happen, but I’d rather avoid or minimize unnecessary risk.
In a production implementation of this approach, I would take steps like the following:
- Upload the new ssh host key to S3 in a private object.
- Generate an authenticated URL to the S3 object and have that URL expire in, say, 10 minutes.
- In the user-data script, download the ssh host key with the authenticated, expiring S3 URL.
Now, there is a short window of exposure and you don’t have to worry about protecting the user-data after the URL has expired.
Starting with the 2009-10-31 API, Amazon Web Services (AWS) has a new type of Amazon Machine Image(AMI) that stores its root device as an Amazon Elastic Block Store(EBS) volume. They refer to these AMIs as Amazon EBS-backed. When an instance of this type of AMI launches, an Amazon EBS volume is created from the associated snapshot, and that volume becomes the root device. You can create an AMI that uses an Amazon EBS volume as its root device with Windows or Linux/UNIX operating systems.These instances can be easily backed-up. You can modify the original instance to suit your particular needs and then save it as an EBS-backed AMI. Hence, if in future you need the the modified version of instance, you can simply launch multiple new instances from the backed-up AMI and are ready to-go.
Following are the steps to be performed for backup/restoring of AWS EBS instance into/from an AWS AMI. Also brief steps for deletion of AMI backup are noted for reference.
EBS-instance to EBS-backed AMI
- Go to AWS Management Console and in the My Instances Pane, select the instance which has to be backed up.
- Right click the instance and select option Create Image (EBS AMI).
- In the Create Image dialog box, give proper AMI Name and Description. Click on Create This Image button.
The image creation will be in progress. This will take sometime depending upon the number & size of volumes attached to the instance. Click on View pending image link. It will take you to the AMIs pane.
The AMI will be in pending state. It is important to note that this AMI is private to the account and not available for AWS public use.
- If you select Snapshots from the Navigation Pane, then you can see that EBS volumes attached to the instance will be backed up as too.
- Once the backup is done, the AMI will be in available state.
Restore from backup AMI into instance
Delete AMI & Snapshots:
- To delete any AMI, Right-click it and select De-register AMI.
Remember, deleting AMI doesn’t delete the EBS volume snapshots. Click on Snapshots from Navigation pane, search & select the snapshot(s) to be deleted. Right-click on the snapshot(s) and select delete snapshot option.
MySQL is the world’s most popular open source database.
MySQL Community Edition is freely downloadable version.
Commercial customers have the flexibility of choosing from multiple editions to meet specific business and technical requirements. For more details please refer to the MySQL official website.
On any CentOS server with open internet, run the below command to install MySQL Community Edition:
yum install mysql-server mysql php-mysql
Download the server and client rpm files from the MySQL Website depending upon the platform(OS) and architecture(32/64bit).
install both rpm files using below command:
rpm -ivh <<rpm_filenames>>
rpm -ivh mysql-server-version.rpm mysqlclient9-version.rpm
Once installed, run the below commands to configure MySQL Server:
1.Set the MySQL service to start on boot
chkconfig --levels 235 mysqld on
2. Start the MySQL service
service mysqld start
3. By default the root user will have no password, so to log into MySQL use command:
mysql -u root
4. To exit Mysql Console, enter below command
SET PASSWORD FOR ROOT :
To set the root user password for all local domains, login and run below commands
SET PASSWORD FOR 'root'@'localhost' = PASSWORD('<<new-password>>');
SET PASSWORD FOR 'root'@'localhost.localdomain' = PASSWORD('<<new-password>>');
SET PASSWORD FOR 'root'@'127.0.0.1' = PASSWORD('<<new-password>>');
(Replace <<new-password>> with actual password)
run below command at linux shell:
mysqladmin -u root password '<<new-password>>'
(Replace <<new-password>> with actual password)
Once password is set, to login to Mysql use below command:
mysql -u root -p
Once you enter the above command, you will be prompted for the root password.
ADD NEW USER :
To add a new user for MySQL login, use the below SQL query. Remember this query must be run from the MySQL prompt.
INSERT INTO user (Host, User, Password, Select_priv, Insert_priv, Update_priv, Delete_priv, Create_priv, Drop_priv, Reload_priv, Shutdown_priv, Process_priv, File_priv, Grant_priv, References_priv, Index_priv, Alter_priv, Show_db_priv, Super_priv, Create_tmp_table_priv, Lock_tables_priv, Execute_priv, Repl_slave_priv, Repl_client_priv, Create_view_priv, Show_view_priv, Create_routine_priv, Alter_routine_priv, Create_user_priv, Event_priv, Trigger_priv, ssl_type, ssl_cipher, x509_issuer, x509_subject, max_questions, max_updates, max_connections, max_user_connections) VALUES ('localhost', '<<USERNAME>>', password('<<PASSWORD>>'), 'Y','Y', 'Y', 'Y', 'Y', 'Y', 'Y', 'Y', 'Y', 'Y', 'Y', 'Y', 'Y', 'Y', 'Y', 'Y', 'Y', 'Y', 'Y', 'Y', 'Y', 'Y', 'Y', 'Y', 'Y', 'Y', 'N', 'N', '', '', '', '', 0, 0, 0, 0);
INSERT INTO user (Host, User, Password, Select_priv, Insert_priv, Update_priv, Delete_priv, Create_priv, Drop_priv, Reload_priv, Shutdown_priv, Process_priv, File_priv, Grant_priv, References_priv, Index_priv, Alter_priv, Show_db_priv, Super_priv, Create_tmp_table_priv, Lock_tables_priv, Execute_priv, Repl_slave_priv, Repl_client_priv, Create_view_priv, Show_view_priv, Create_routine_priv, Alter_routine_priv, Create_user_priv, Event_priv, Trigger_priv, ssl_type, ssl_cipher, x509_issuer, x509_subject, max_questions, max_updates, max_connections, max_user_connections) VALUES ('%', '<<USERNAME>>', password('<<PASSWORD>>'), 'Y','Y', 'Y', 'Y', 'Y', 'Y', 'Y', 'Y', 'Y', 'Y', 'Y', 'Y', 'Y', 'Y', 'Y', 'Y', 'Y', 'Y', 'Y', 'Y', 'Y', 'Y', 'Y', 'Y', 'Y', 'Y', 'N', 'N', '', '', '', '', 0, 0, 0, 0);
Replace <<USERNAME>> and <<PASSWORD>> with actual username and password respectively.
Note they must be enclosed in single quotes.
DROP ANY USER :
In case, you want to drop any user use below command:
(Replace <<username>> with actual username)
For more help and commands, refer –> http://www.yolinux.com/TUTORIALS/LinuxTutorialMySQL.html
Steps for installing JAVA (JDK 6) on linux using rpm files:
1. Log into the linux shell and become root user by running the command
2. Change directory.
3. Please search at http://www.oracle.com/technetwork/java/javase/downloads/index.html for newer versions to download.
You can download to any directory you choose; it does not have to be the directory where you want to install the JDK. Before you download the file, notice its byte size provided on the download page on the web site. Once the download has completed, compare that file size to the size of the downloaded file to make sure they are equal.
To download use one of the below commands, depending on the server’s architecture (32/64 bit) :
5. Run below command to grant execute permission to the file:
chmod a+x <<name-of-rpm-file-downloaded-earlier>>
chmod +x jdk-6u25-linux-x64-rpm.bin\?e\=1306317438\&h\=294de0d36f54e28dd65fc8370e3c406d
6. Change directory to the location where you would like the files to be installed. The next step installs the JDK into the current directory.
7. Execute the downloaded file, prepended by the path to it.
For example, if the file is in the current directory, prepend it with “./” :
8. The binary code license is displayed, and you are prompted to agree to its terms.
9. Check if java is installed using command
The java version must be displayed correctly. You may also want to run commands like
javac to check if installation is proper.
10. Execute below command to test if the JAVA_HOME environment variable is set.
It must display the location where java is installed.
11. Delete the bin and rpm files if you want to save disk space.
rm -rf sun*