Notes on Using AWS (provisioning an instance, getting it set up for development, etc.)

I think I still want an EC2 reserved instance savings plan.

Amazon, however, say, "We recommend Savings Plans (over Reserved Instances)."

I think I want an EC2 Instance savings plan (not reserved instance; although I'm not yet sure of the difference).

Their recommendation page (https://us-east-1.console.aws.amazon.com/cost-management/home?region=us-east-1#/savings-plans/recommendations?lookbackPeriodInDays=SIXTY_DAYS&paymentOption=ALL_UPFRONT&scope=PAYER&spType=EC2_INSTANCE_SP&termInYears=THREE_YEAR&tokens=%5B%5D) shows no recommendations. I think because my usage is < $0.10/hour? I think I paid something like $120 for a t2.micro instance for 3 years, which amounts to (/ 120.0 (* 3 365 24)) $0.005/hour.

I think my region is US-East (N. Virginia). Current node is in Availability Zone "us-east-1a". Answer: yes, N. Virginia. See https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html.

There's a Compute pricing page here: https://aws.amazon.com/savingsplans/compute-pricing/.

On-demand instance pricing appears to be here: https://aws.amazon.com/ec2/pricing/on-demand/

Always-on calc: (* 3 366 24 0.0084)

Comments on t4g below.

The m-series is also general-purpose, but

1. doesn't go below size "medium",
2. doesn't appear to be burstable,
3. has more memory/cpu,
4. and the cheapest one is almost ten times a comparable-ish t-series.

So, basically, they're more for larger-scale systems, which I am not.

Savings plans compute pricing (use the "EC2 Instance Savings Plans" tab): https://aws.amazon.com/savingsplans/compute-pricing/

Us-east-1 t3.micro 3 yrs Linux shared tenancy all up front = $102.77 ($0.0039 multiplied out).

Which is $2.85/month (/ (* 0.0039 3 366 24) 36)

• CLOSING NOTE [2023-08-21 Mon 11:17]
  I think this is done, and the instance is up, and now I need to connect a volume from a snapshot of the old instance before continuing to configure. See Creating and mounting an Elastic Block Store volume from an existing snapshot (2023)

Might need to move the user/data volume to another VM at some point in the future, and it would be useful to be able to create users (e.g., "tomcat") and groups (e.g., "sysport") with fixed ids (e.g., 200) so the previous user volume can simply be dropped into the new VM.

Note the following on my old instance:

ls -l server.xml
-rw-r----- 1 root tomcat8 6567 Mar  6  2017 server.xml

ls -ln server.xml
-rw-r----- 1 0 116 6567 Mar  6  2017 server.xml

So, group 116 is tomcat8 there.

However, when I snapshot the volume and create a new volume from the snapshot and mount it on the new VM, I see the following, when examing the same files (mounted on a new mountpoint):

ls -l server.xml
-rw-r----- 1 root landscape 6567 Mar  6  2017 server.xml

ls -ln server.xml
-rw-r----- 1 0 116 6567 Mar  6  2017 server.xml

So, the group id (116) came across just fine, but on the VM, it corresponds to group "landscape" (whatever that is), instead of "tomcat8".

adduser --uid <n>
addgroup --gid <n>

(along with other options).

To find a good id…

Users sorted by uid:

cat /etc/passwd | awk -F: '{printf "%5d\t%5d\t%s\n", $3,$4,$1 }' | sort -k 1n

Groups sorted by gid:

cat /etc/group | awk -F: '{printf "%5d\t%s\n", $3, $1}' | sort -k 1n

Maybe 300 is a good user id, and 80 is a good group id? Or 300 for both? Looks like apt creates tomcat user and group, so what I did is install it, uninstall it, then modify the user/group as follows, then re-install it.

sudo groupmod -g 300 tomcat
sudo usermod -u 300 -g 300 tomcat

(Note that "attaching" is not the same as "mounting".)

Ok, I created it, and attached it, but I don't see it. It's supposed to be attached as /dev/sdf or /dev/xvdf, I think.

Note that the root volume is supposed to be /dev/sda1.

findmnt shows / is the mount point for /dev/nvme0n1p1, with filesystem type of ext4. I don't see any other ext4 devices mounted.

https://aws.amazon.com/blogs/compute/how-to-mount-linux-volume-and-keep-mount-point-consistency/

ssh to the machine and…

lsblk

Aha, there it is, nvme1n1 with one partition (nvme1n1p1).

t3 and, I guess, t4g, systems use NVMe block devices built on Nitro. When googling NVMe, StackOverflow has a hit that says the data goes away when the instance is stopped (not just terminated), but this is discussing instance stores, not EBS volumes. Here's Amazon's documentation on EBS and NVMe: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/nvme-ebs-volumes.html.

findmnt (mount being obsolete now) tells me that nvme0n1p1, the main partition on the volume created with this snapshot, is mounted on /. (There's another partition, nvme0n1p15, that appears to be a 99 MB boot partition.)

So, we just need to mount the new volume somewhere, I think.

sudo file -s /dev/nvme1n1p1 reports to me, if I'm reading the output correctly

/dev/nvme1n1p1: Linux rev 1.0 ext4 filesystem data, UUID=45131f33-7efa-487c-a104-839d87a3f3ea, volume name "cloudimg-rootfs" (extents) (large files) (huge files)

that this volume has an ext4 filesystem on it (as opposed to just being a blank volume ready for formatting).

blkid -o export /dev/nvme1n1p1 yields the following (note that we're querying the partition):

DEVNAME=/dev/nvme1n1p1
LABEL=cloudimg-rootfs
UUID=45131f33-7efa-487c-a104-839d87a3f3ea
BLOCK_SIZE=4096
TYPE=ext4

The UUID will be constant for this volume.

Important note:

Current /etc/fstab contains the following:

LABEL=cloudimg-rootfs   /        ext4   discard,errors=remount-ro       0 1
LABEL=UEFI      /boot/efi       vfat    umask=0077      0 1

Note that the current root volume has a label of cloudimg-rootfs, which is the same as the volume we want to attach. That will cause a name collision if we modify fstab to mount them both at boot time, so I think we need to change the spec for the root volume to go by UUID, not label.

findmnt reports the root partition mounted with the following options: rw,relatime,discard,errors=remount-ro.

I think we can use the same options for the new volume. So, new line added to /etc/fstab:

UUID=45131f33-7efa-487c-a104-839d87a3f3ea       /mnt/1  ext4    discard,errors=remount-ro       0 2

…and it works! (So far.)

Next steps are to install Corretto, tomcat and jspwiki, probably on the additional volume. Old wiki pages will be found at /mnt/1/usr/share/jspwiki. See jspwiki-custom-properties – Configuration of various filepaths on host system.

In top directory of project:

git init
git add <already-existing-file>
git commit

git clone git://github.com/schacon/grit.git
git clone user@server:/path.git # Uses SSH

Clones into current local directory. Without further arguments, names remote repo "origin" and local branch "master".

Quoting from http://git-scm.com/book/en/Git-Basics-Recording-Changes-to-the-Repository:

The rules for the patterns you can put in the .gitignore file are as follows:

• Blank lines or lines starting with # are ignored.
• Standard glob patterns work.
• You can end patterns with a forward slash (/) to specify a directory.
• You can negate a pattern by starting it with an exclamation point (!).

Glob patterns are like simplified regular expressions that shells use. An asterisk (*) matches zero or more characters; [abc] matches any character inside the brackets (in this case a, b, or c); a question mark (?) matches a single character; and brackets enclosing characters separated by a hyphen([0-9]) matches any character in the range (in this case 0 through 9) .

Here is another example .gitignore file:

# a comment - this is ignored
# no .a files
*.a
# but do track lib.a, even though you're ignoring .a files above
!lib.a
# only ignore the root TODO file, not subdir/TODO
/TODO
# ignore all files in the build/ directory
build/
# ignore doc/notes.txt, but not doc/server/arch.txt
doc/*.txt
# ignore all .txt files in the doc/ directory
doc/**/*.txt

Also:

Another useful thing you may want to do is to keep the file in your working tree but remove it from your staging area. In other words, you may want to keep the file on your hard drive but not have Git track it anymore. This is particularly useful if you forgot to add something to your .gitignore file and accidentally staged it, like a large log file or a bunch of .a compiled files. To do this, use the –cached option:

git rm --cached readme.txt

If working w/JBoss (WildFly), you'll need to install some tools from RedHat. It looks like Eclipse comes with JBoss software sites pre-configured, but I recall having done something to install WildFly tools. Try Window | Preferences | Server | Runtime Environments | Add | Download Additional Server Adapters (a link), and go from there.

Window | Preferences | Java | Installed JREs

Let Eclipse search for JREs, rather than try to configure them yourself. Restrict the search to directories where you know you have good JREs (e.g., c:\Java\jdk1.7.0_45).

Window | Preferences | Server | Runtime Environments

Again, let Eclipse search for WildFly (after you install it), starting with a known directory (e.g., c:\usr\local\wildfly-8.0.0.Beta1). Associate the server with a JDK JRE (which should have been found in the previous search (in JDKs and JREs).

As far as the JBoss Quickstarts are concerned, I don't advise importing the existing projects into Eclipse if you can't make them work from the command line. Instead, just import the source artifacts (beans.xml, maybe web.xml, static web content, dynamic (Java) web content, etc.) Then you can select "Run On Server", pick the Wildfly server you set up in Wildfly, and be off to the races. Hopefully.

If you install to a directory not generally-writable, be sure to run your various admin batch files as Administrator. Or chown the directory (recursively) to the userid you'll be running the server as.

{JBOSS_HOME}/bin/jboss-cli.sh --connect command=:shutdown

(Worked for me, Windows 7, Wildfly 8.0 beta1, cygwin)

• CLOSING NOTE [2013-12-05 Thu 20:51]

(See JBoss helloworld quickstart.)

This is basically how to hook up your business-logic classes and servlets w/out going through reams of configuration.

The CDI spec basically says that every injection point (@Inject) is satisfied by exactly one class or there's an error.

• [X]

  The type of the injection point is exactly the same as the type of the class (there's some noise about raw types and parameterized types and types of type parameters, but… bascially identical types), or (See section 4.3 ("Specialization") of the JSR-299 CDI spec) a specializing (subclassing) bean can use the @Specializes annotation to indicate to the container that it's specializing another bean (e.g., a mock bean can specialize the intended production bean).

  However, don't specialize decorators or interceptors. The spec says, "If an interceptor or decorator is annotated @Specializes, non-portable behavior results." I think this means they wash their hands of the matter.

• [X] Do injectable beans have a default annotation of @Default? (injection points do, unless you give another annotation.) Yes, if they don't declare a qualifier. See Section 2.3.1. ("Built-in qualifier types") of the JSR-299 CDI spec.

JSR-344.