| Both sides previous revisionPrevious revisionNext revision | Previous revision |
| howtos:cloud:aws_ec2 [2020/07/05 14:58 (UTC)] – bifferos | howtos:cloud:aws_ec2 [2020/07/07 00:59 (UTC)] (current) – [Disk Formats] bifferos |
|---|
| |
| * You should have already prepared a DomU compatible Slackware install, see the [[howtos:misc:xen_domu_guest|separate guide]] on how to do that. | * You should have already prepared a DomU compatible Slackware install, see the [[howtos:misc:xen_domu_guest|separate guide]] on how to do that. |
| * You should have an AWS account with the necessary vmimport policy/role | * You should have an AWS account with the necessary [[https://docs.aws.amazon.com/vm-import/latest/userguide/vmie_prereqs.html#vmimport-role|vmimport role]] |
| * You should have awscli configured with credentials such that commands like 'aws s3 ls' work | * You should have awscli configured with credentials such that commands like 'aws s3 ls' work |
| |
| ===== Security ===== | ===== Security ===== |
| |
| A quick word about security. We will not be making use of the service provided by AWS which furnishes your instance with keypairs, because we won't be installing the agent process that does that. This saves a bit of time for unsupported operating systems like Slackware, but it means you need to sort out how to get access to your instance after it starts. I strongly suggest you | A quick word about security. We will not be making use of the service provided by AWS which furnishes your instance with key pairs, because we won't be installing the [[https://github.com/aws/amazon-ssm-agent|agent process]] that does that. This saves a bit of time for unsupported operating systems like Slackware, but it means you need to sort out how to get access to your instance after it starts. I strongly suggest you |
| |
| - Upload a public key to the account you'll use to access your instance, e.g. with ssh-copy-id. | - Upload a public key to the account you'll use to access your instance, e.g. with [[https://www.ssh.com/ssh/copy-id|ssh-copy-id]]. |
| - Ensure that ssh is configured to only use key access (PermitRootLogin=prohibit-password), which I believe is the default. | - Ensure that ssh is configured to only use key access ([[https://man.openbsd.org/sshd_config#PermitRootLogin|PermitRootLogin=prohibit-password]]), which I believe is the default. |
| - Reboot and ensure you still have access using your private key. | - Reboot and ensure you still have access using your private key. |
| - Double-check that you cannot login using the password that would normally work on the VM console for your user. | - Double-check that you cannot login using the password that would normally work on the VM console for your user. |
| | <note important>Within an hour of your instance becoming live it will be logging access attempts by Russian hackers. AWS address ranges are scanned regularly for vulnerabilities precisely because so many users screw up their security. Don't be caught out.</note> |
| Of course, how secure your instance is will ultimately be your responsibility, this is just advice. | |
| |
| ===== Disk Formats ===== | ===== Disk Formats ===== |
| |
| Stream optimised VMDK is the most efficient way to upload your image. This is the VMDK format created when you export to OVF format from VMWare and you will notice it’s much more compressed than normal VMDK files. Don’t upload a standard VMDK file, it won’t work and you’ll waste your time. Also, don’t try to generate stream-optimised VMDK using any open-source utilities. None of them seem to work properly. If you don’t own a VMWare product with the ‘export to OVF’ option, you could try OVFTool. This is a free download from VMWare for registered users, and will take a VMWare VM directory as input. I’m unsure if it requires a registered copy of VMWare to run but it will expect the .VMX and possibly other files which you’ll have to generate somehow to keep it happy if you're not actually using VMWare. When the OVF directory is generated it will be generated containing several files. You can discard all but the .VMDK. | Stream optimised VMDK is the most efficient way to upload your image. This is the VMDK format created when you export to OVF format from VMWare and you will notice it’s much more compressed than normal VMDK files. Don’t upload a standard VMDK file, it won’t work and you’ll waste your time. Also, don’t try to generate stream-optimised VMDK using any open-source utilities. None of them seem to work properly. If you don’t own a VMWare product with the ‘export to OVF’ option, you could try OVFTool. This is a free download from VMWare for registered users, and will take a VMWare VM directory as input. I’m unsure if it requires a registered copy of VMWare to run but it will expect the .VMX and possibly other files which you’ll have to generate somehow to keep it happy if you're not actually using VMWare. When the OVF directory is generated it will be generated containing several files. You can discard all but the .VMDK. |
| | |
| | <note tip>Ensure you've shutdown VMWare completely and removed any DVD-ROMs from the VM before exporting to OVF or it may fail with a cryptic (e.g. useless) error message as is typical from VMWare.</note> |
| |
| If you don't have VMWare, and/or don't want to use OVFTool then you should consider .VHD format. This format was used by the ancient Microsoft emulator called VirtualPC, and latterly HyperV. qemu-img will happily generate one of these when you specify the ‘vpc’ output format. VHD is more verbose than stream-optimised VMDK and will end up about double the size, so double the upload time, and higher S3 charges while importing (not that they will amount to much). You can also use VHDX format as AWS also supports that but there is little point as the generated files are even larger than VHD to contain the same information. | If you don't have VMWare, and/or don't want to use OVFTool then you should consider .VHD format. This format was used by the ancient Microsoft emulator called VirtualPC, and latterly HyperV. qemu-img will happily generate one of these when you specify the ‘vpc’ output format. VHD is more verbose than stream-optimised VMDK and will end up about double the size, so double the upload time, and higher S3 charges while importing (not that they will amount to much). You can also use VHDX format as AWS also supports that but there is little point as the generated files are even larger than VHD to contain the same information. |
| </code> | </code> |
| |
| Change vmdk to vhd(x) depending on the format you’re using (it’s not detected by the import process). Choose a description to describe you storage. You may want to put a version in there as I’ve done if you make several attempts at this. Put the presigned URL in the Url field, save the file, and then run: | Change vmdk to vhd(x) depending on the format you’re using (it’s not detected by the import process). Choose a description to describe your storage. You may want to put a version in there as I’ve done if you make several attempts at this. Put the presigned URL in the Url field, save the file, and then run: |
| |
| <code> | <code> |
| ===== Connect to an Instance ===== | ===== Connect to an Instance ===== |
| |
| You can now create an instance. Any instance will do, a t2.micro will have 1 CPU and plenty of RAM to boot Slackware. Shut down the instance, disconnect it's root drive. You can delete the root EBS volume supplied with that instance if you want because we'll create another one. There's no point in paying for anything you don't use. | You can now create an instance. Any instance will do, a t2.micro will have 1 CPU and plenty of RAM to boot Slackware. Shut down the instance, disconnect its root drive. You can delete the root EBS volume supplied with that instance if you want because we'll create another one. There's no point in paying for EBS storage you don't need. |
| |
| You can then use the AWS Console to create an EBS volume from your uploaded snapshot, and attach the EBS volume as the root device of your instance. Make sure you specify the device as /dev/sda, to ensure it will be the root device. I found this slightly confusing because it's actually /dev/xvda in the running instance but there you go. | You can then use the AWS Console to create an EBS volume from your uploaded snapshot, and attach the EBS volume as the root device of your instance. Make sure you specify the device as /dev/sda, to ensure it will be the root device. I found this slightly confusing because it's actually /dev/xvda in the running instance but there you go. |
| You should now be able to start that instance, boot Slackware and connect to it using ssh. | You should now be able to start that instance, boot Slackware and connect to it using ssh. |
| |
| | ====== Sources ====== |
| | <!-- Authors are allowed to give credit to themselves! --> |
| | * Originally written by [[wiki:user:bifferos | User Bifferos]] |
| |
| <!-- Please do not modify anything below, except adding new tags.--> | <!-- Please do not modify anything below, except adding new tags.--> |
| <!-- You must remove the tag-word "template" below before saving your new page --> | <!-- You must remove the tag-word "template" below before saving your new page --> |
| {{tag>howtos ec2 aws}} | {{tag>howtos ec2 aws}} |
