Forem: Jason Paul

AWS Summit Toronto 2024 Survival Guide

Jason Paul — Mon, 09 Sep 2024 21:15:48 +0000

Introduction

As this will be my third year attending AWS Summit, I wanted to share some information, resources, and some recommendations that will help make your visit to Toronto a bit easier.

I first attended AWS Summit Toronto in 2022. I had just switched to a team that was supporting a SaaS application fully built on AWS, and I was fortunate enough to be able to go. I was able to meet a number of connections from LinkedIn, and a few of the community members that I had met through training courses and communities.

As a side note, I believe this was the first time I had heard about the AWS Community Builders Program from Augusto Valdivia, who was wearing one of the T-Shirts. As a new user to AWS, hearing about the program and the free conference was eye opening, and I jumped right in. I joined the AWS Community Builders program a few months later, and it's been an absolute game changer for me.

Unofficial Discord

To facilitate an easy way to network and share information during the conference, I've created a temporary Discord community.

You can join using this invite link.

Travel and Transit

MTCC - How To Get Here

Driving and parking in Toronto can be a stressful, expensive, and tiring exercise. If you have the option, I would recommend parking at your hotel, or a free GO station parking lot, taking the GO Train or TTC Subway into Union Station, then walking to the convention centre. It's maybe a 5 minute walk - just head towards the CN Tower.

If you are driving, there is an MTCC parking garage, or you can park at a Green P Parking Lot nearby.

If you are flying in from the Toronto Pearson Airport (YYZ), you can take the UP Express directly to Union Station.

Arrival and Registration

AWS Summit Toronto 2024 will be at the Metro Toronto Convention Centre (MTCC) South Building.
You can access it through the PATH Network from Union Station, or from the Delta Hotel. The direct entrance is off Lower Simcoe St and Bremner Blvd. Just walk across from the Delta Hotel. Here is the Google Maps view:

You can access the MTCC from the North building on Front Street, however you'll be walking quite a bit up a few floors via escalators and various walkways to get to the South building. It would be faster to go directly if possible.

Once inside, there will be signage directing you to the registration area where you can pick up your badge.

I would recommend going early to pick up your badge if possible, as the line can get quite long. If you are able to pick up your badge the day before on September 10 between 10AM - 7PM, you can get $25 in AWS credits or some free swag. In previous years, your badge would be scanable so you can register at booths for communications, contests, and swag.

You should get an email a few days before the conference to "Prepare for Badge Pickup", with a QR code to scan. Have your physical government-issued photo ID ready to show.

Agenda

Above is the high level overview of the Summit. There are a lot of labs and sessions going on throughout the day, and it can be a bit overwhelming. There is usually electronic signage that should make this easier, but if you want to plan ahead, you can review the session catalog on the AWS page.

Even better would be to download the AWS Events application for Android or iPhone, and build your schedule with it. It's quite good, and will let you have a calendar view of all of the sessions you select, as well as access other features during the conference, such as maps, surveys and contests.

On top of the more formal presentation sessions, there will also be Dev Chat sessions in the theatre, presented by AWS Community Builders and other AWS Community members. Come check it out!

Networking and Questions

Outside attending keynotes and the more formal presentations, make sure to leave some time to wander around the Expo area and visit the vendor booths. It's a good opportunity to check out the products, ask questions, get names of contacts to reach out to, or maybe score a nice piece of swag.

Visit the AWS Village area, and find someone to chat about one of those burning questions you have. They also frequently have extra AWS credit vouchers they can give out.

The AWS Community Lounge is also a great place to talk to other AWS users, discover local meetups, and chat with other community members.
I'll be helping out in the lounge from 3:00 - 4:00 PM, so come by and we can chat!

Food and Drink

Refreshments like coffee, tea, and water should be available at kiosks in the Expo area throughout the day, starting at 8AM.

Lunch will start at 12:00PM. I would highly recommend leaving the keynote a bit early to avoid the rush, so you can grab some food. Last year there was not enough meals, and they ran out in only 10 minutes. Typically there have been various meal boxes with different proteins, or vegetarian/halal. There is usually soda and other drinks available as well.

If you aren't able to get lunch during this time, there are a lot of food places within easy walking distance outside of the convention centre.

Socializing and After Parties

AWS Summit is a great place to meet other AWS users, industry leaders, and a great opportunity to network. Don't be afraid to strike up conversations while waiting in line, having lunch or coffee, or in the Expo area.

There will be an official networking reception, usually in the Expo area, from 5:00PM - 6:00PM. There is typically bar service with beer, wine, and non-alcoholic beverages.

After the conference, many companies will have sponsored after parties nearby. You can usually find out about them when you chat with the company at the booth, and some of them will be posted on social media. If you're a customer, AWS Partner, or just in the know, you'll be able to register and get an invite. Reach out to your account manager if they're sponsoring the Summit and have a booth.

Tips

If you will be attending any of the Spotlight or Self-Paced Labs, do bring your own laptop as you will need it to follow along.
A phone battery pack and an extra phone/laptop charger are a good idea to make sure you're not scrambling to find an outlet.
Set up the AWS Events app on your phone to set up your agenda for the day and know where to go.
Leave the keynote early to grab lunch and beat the rush. Last year they ran out of food.
Bring a travel mug for water/coffee/tea - they will have free kiosks to refill. There will be other drinks during lunch, and during the networking reception.
Bring a backpack for holding swag and your laptop.
Plan to spend some time in the Expo area and visit the booths to do some networking.
Talk with the AWS employees at their booth area - usually they'll give away free AWS credits.
There are usually sponsored after-parties with food and free drinks. Register for a couple and you can tour around between them a bit.
Don't forget to take a photo with the giant AWS sign!

Resources

AWS Summit Toronto 2024:

Transit and Location:

Photos

AWS New Voices - Lessons Learned

Jason Paul — Tue, 16 Apr 2024 15:10:00 +0000

Introduction

For the past few weeks, I've been participating in a weekly session to improve my public speaking skills, put on by the AWS Community Builders community. AWS New Voices is a live, virtual training for those less-experienced in giving technical talks at events and meetups, but would like to begin doing so. The training was 5 weeks, and met once per week for 90 minutes.

It was a great experience, getting tips and feedback on practice speaking engagements. We had full group sessions, and usually split into smaller breakout rooms to go through some exercises. It was incredibly positive and energizing. Special thanks to Mark Pergola from AWS for organizing and facilitating, and Meridith Grundei from Grundei Coaching for all of the lessons and amazing energy!

As part of the program, as we progressed from week to week, we used the tips to build a 5 minute presentation to fine tune and ultimately present to an audience at a public event.

I've been tuning my presentations using the tips from the training, and recently graduated from the program. I had done a larger presentation to a local group using the methods learned in the sessions:

https://www.linuxtek.ca/2024/03/08/kwlug-presentation-march-2024-introduction-to-truenas-scale

I'll be presenting my 5 minute presentation in May, and I'll post it on the site, hopefully with a recording, for feedback.

In this article, I'd like to share some of the tips we learned throughout the sessions for others to use to improve their public speaking.

Week 1 - Speaker Confidence and Establishing Your Talk

First, we discussed starting by brainstorming for the presentation by identifying the following:

Who is your audience? What do they know already? What don't they know? What do they need to know?
What is your end in mind? What outcome do you want? What do you want your audience to think, feel, or do after they've heard your message?
What are the three "NEED TO KNOWS" that lead to your end in mind?

The presentation will be based on this information, and should be tailored for the audience. We took the first week to define this, to start planning our presentation.

Week 2 - Storytelling and Hooks

For the second week, we went over our work from the previous week in smaller breakout groups.

We also talked about ways to "hook" the audience during the introduction, to capture their attention and keep them engaged for the content you will be going over. This gives a good first impression at the start of your presentation, and you typically have only about 30 seconds to do it.

A good hook should be:

Brief - you only have about 30 seconds to capture the audiences' attention
Catchy - you want to make sure it jumps out and the audience finds it interesting
Well-Rehearsed - First impressions count, and you only get one shot at this, so make sure to practice
Pertinent to your topic - The hook should lead into your presentation, otherwise you risk losing your audience
Avoid dry and conventional hooks - Again, you want to make sure to grab the audiences' attention, so don't start with something that will make them tune out

Some examples of ways to hook your audience are:

Storytelling - Beginning with a captivating story that relates to your topic
Startling Statistic - Sharing a surprising or thought-provoking statistic
Bold Statement or Question - Open with one of these to get the audience to think
Engaging Visual or Prop - Capture the audience's attention by using a striking visual or prop
Quotation - Start with a compelling quote from a renounced figure or expert

As part of building our presentation, we also went over some other sections to think about for crafting our introduction:

Your Hook (all mentioned above)
Who you are for credibility? Why should the audience listen to you?
What will your audience gain from your presentation?
Why is your presentation important for your audience?

At the end of the presentation, you also want to have a Call To Action - one specific thing you want your audience to do after they walk away from your presentation. This could be going to a website, do some further research, take a certification program, or try a product or service.

This should be clear and simple. If you want them to scan a QR code, save a web link, or fill out a survey, give clear instruction on what you want the audience to do, and give them time to do it.

Week 3 - Adding Visuals

In the past, I was absolutely guilty of creating presentations with the above problem. I would load my slides with text, and read off of them. This is overwhelming to the audience, and makes it hard for them to follow along.

The audience should be focused on listening to what you have to say, not trying to process everything on the slides.

In Week 3, we talked about some ways to use visuals in the presentation effectively. A lot of this was how to choose visuals to support the message. We used the F.O.C.U.S. acronym:

F - Frame - Introduce the slide's purpose and how it fits into your overall message

O - Orient - Guide the audience's attention to the key elements of the slide.

C - Clarity - Each slide is clear and straightforward, with minimal text and clear visuals

U - Use Visuals - Employ charts, images, props, and diagrams instead of text

S - Simplify - Focus on the core message of each slide

Some ways to guide the audience's attention on a slide is to animate the slide to reveal and introduce the information gradually, so you don't overwhelm them, and allow them to process the visuals separately. You can also circle or highlight the part of a complex diagram to get their focus, and then discuss it. If you are trying to direct their attention to something that requires action, like scanning a QR code, let the audience know clearly, and pause and wait to give them time to do so.

Week 4 - Putting It Together

In Week 4, we put everything together and did a practice run of our presentation to a small breakout group. This was great, as we had time to get feedback from the group to improve our presentation, and also rehearse it with a time check to make sure we weren't going over.

For some of the things to consider for the presentation:

Imagine your presentation as a gift to your audience.
What unique value or takeaway do you hope to give them?

Week 5 - Final Rehearsal

In Week 5, we did a final run of our 5 minute presentation both in breakout groups, and a few of us to the entire cohort. We really focused on ensuring the breakdown of the presentation was timed properly:

0.5 Minutes - Introduction and Hook
0.5 Minutes - Introduce Yourself, Credibility
3 Minutes - Slides/Talk
0.5 - Key Takeaways
0.5 Minutes - Call To Action

Conclusion

I'm really happy I was able to take part in this program, and thankful that it was offered by the AWS Community Builders group. I really feel that the sessions have helped improve my presentations and confidence for public speaking, and I'll be putting these tips to good use.

I'm also happy I was able to connect with so many passionate individuals and get to know them a bit better in the breakout sessions.

The positive energy, presentation feedback, encouragement, and insights were all invaluable. And of course, since we started and ended most sessions this, I'll have to end with collective...

👋👋👋 JAZZ HANDS 👋👋👋

Resources

AWS To Provide Free Data Transfer Out To Internet

Jason Paul — Thu, 07 Mar 2024 02:11:37 +0000

Introduction

A few days ago, AWS announced in a blog post that they would be providing free DTO (Data Transfer Out) of AWS, when moving data to another cloud provider or to an on-premises data center. This is a pretty big deal, because one of the common concerns from companies looking to adopt the cloud, is the expense of moving their data out, causing vendor lock-in.

In this article, we will explore details on transferring data in and out of AWS, some of the more recent regulatory changes, and the potential business impact.

Updates

Update: 03/17/2024 - On March 13, 2024, Microsoft announced that Azure would be following suit and allowing free egress for customers leaving Azure when taking their data out of the Azure infrastructure via the internet to switch to another cloud provider or an on-premises data center. This would be on top of the first 100GB/month free egress data already provided.

Update: 03/26/2024 - It was pointed out that AWS Snowmobile is no longer available. Recently, the web page for the service has been removed, and redirects to the AWS Snowball page. I received confirmation from AWS that the service was discontinued, and was provided with this statement:

AWS is always innovating on behalf of customers, which means we must sometimes make the decision to pivot when we believe our resources should be invested elsewhere to better serve customers. For that reason, we no longer offer AWS Snowmobile.

Data Transfer In

Typically, there is no charge for inbound data transfer to AWS. The challenge becomes how to get the data into AWS quickly and efficiently.

If a small amount of data needs to be transferred, it can be uploaded directly via the internet, for example to an S3 bucket.

For larger datasets, or to set up a larger job to connect between an on-premises data center and AWS, the two most common options are Site-to-Site VPN and Direct Connect, both which come with a cost. AWS DataSync can also be set up to copy between on-premises and AWS, to automate moving data to a number of AWS services.

For extremely large datasets that cannot be transferred over the internet, or in an environment where there is no consistent network connectivity, the AWS Snow Family is available. This allows for some edge computing to collect and process data, and move it to the AWS cloud by physically shipping the device to AWS.

AWS Snowcone has an HDD and SSD device type, which can transfer 8-14TB of data securely on a device small enough to put in a backpack.

AWS Snowball has a number of devices optimized for edge computing and data transfer. The service allows you to order a ruggedized device that can hold multiple terrabytes to petabytes of data, to transfer to AWS.

You would set up a Snowball Edge Job to define how to import the data into S3. Once the data is copied to the Snowball, it can be shipped back to the proper AWS datacenter to be uploaded and complete the job.

If you have extremely large amounts of data to transfer, such as hundreds of petabytes or into exabytes, AWS Snowmobile can move up to 100PB at once via a ruggedized shipping container. The ruggedized shipping container is tamper-resistant, water-resistant, temperature controlled, and GPS-tracked. The service was announced in 2016, and one of the trucks shown during a presentation that year at AWS re-Invent:

https://www.youtube.com/watch?v=8vQmTZTq7nw

For all of the above methods, the charges would be for the method of data transfer, but the actual data transfer into AWS would cost $0.00/GB.

This CNBC piece details all of the AWS Snow family options in much more detail:

https://www.youtube.com/watch?v=H3_ZqnqLyVo

Data Transfer Out

Many of the methods for transferring data into AWS can also be used to transfer data out. The catch is that until recently, you would also be charged per GB of data transferred out. For example, see this AWS blog post from 2010, when outbound data transfer prices were reduced. Companies would pay $0.08 - $0.15 per GB transferred out per month. This would mean that for companies that have extremely large data sets in AWS, getting that data out would be prohibitively expensive, which could lead to some companies being locked into the platform.

The example above is for data transfer from EC2 out to the internet, and is available on the pricing page.

In 2021, AWS increased the free tier to make the first 100GB of data per month transferred out to the internet free.

Changing The Game

In January 2024, Google Cloud announced in a blog post that they would be eliminating data transfer fees when moving off Google Cloud. This would allow customers to use Google Cloud without having to worry about a gigantic cloud exit data transfer bill. Customers do have to apply for free data transfer when exiting Google Cloud, but knowing the policy definitely could be reassuring.

Since 2022, the European Union has been revising The European Data Act, and the final text was published in December 2023. The European Data Act will become fully effective in September 2025. The act specifies:

The Data Act also improves the conditions under which businesses and consumers can use cloud and edge services in the EU. It becomes easier to move data and applications (from private photo archives to entire business administrations) from one provider to another without incurring any costs, because of new contractual obligations that the proposal presents for cloud providers, and a new standardisation framework for data and cloud interoperability.

Part of the text includes a provision for a self-regulatory code of conduct for facilitating the switching of data processing services and the porting of data. Many Cloud providers have signed on to the SWIPO (Switching Cloud Providers and Porting Data) group, including members of the Cloud Infrastructure Services Providers In Europe (CISPE).

In the most recent blog article from AWS, they refer to the waiver on data transfer following the direction set by the European Data Act, and being available to all AWS customers around the world, and from any AWS region.

Interestingly, Microsoft has declared adherence to a SWIPO Code of Conduct, but the pricing details for Microsoft Azure still indicate the first 100GB of Internet Egress is free, but charged per GB after that. I was not able to find an exception policy when exiting their cloud to another provider or moving back to on-premises. It will be interesting to see if they follow suit with their competitors.

Conclusion

It appears that the European Data Act is working to level the playing field among cloud providers, and making it less costly for companies to port their data out, removing one of the barriers that would cause "lock-in" with specific providers. It will be interesting to see how other cloud providers and services react to the new pricing and upcoming regulations, and if they will follow suit.

Resources

AWS Training and Certification Promotion Roundup - Feb 2023

Jason Paul — Thu, 02 Feb 2023 02:39:45 +0000

Introduction

There are a number of current promotions around AWS training and certification that include free training, discount vouchers on exams, and other resources. These are typically hard to find in one place, and you either have to hear about it through social media, or comb through some of the update documents to find them. I will be summarizing the current promotions and adding to this article as I find more.

Obviously this is not an AWS curated list of resources. It is just a collection of available resources that I came across and decided to share. If you find similar offerings, please leave a comment or contact me, and I'll do my best to add them where appropriate.

AWS Certified Cloud Practitioner - Foundational

Signup Link

The virtual event is on Friday, February 10, 2023 | 09:00 AM - 10:30 AM GMT, so this is more for those in the UK/Europe. If you attend the exam readiness webinar, you can get a voucher for a 50% discount off the exam:

The webinar will cover:

Understanding the exam structure and question types
Interpreting the concepts being tested by an exam question
Allocating your time studying for the exam

If you will be preparing for this exam, I would also recommend reviewing the recordings on Twitch from the AWS Power Hour: Cloud Practitioner series from 2022. All of the episode recordings and resources are available at this link.

AWS Certified Solutions Architect - Associate

From this blog post from January 31, 2023, there are a number of training resources mentioned. The Solutions Architect Learning Plan is a free AWS Skillbuilder course which is designed to help Cloud Architects and Solutions Architects design solutions on AWS using best practices. This Learning Plan can also help prepare you for the AWS Certified Solutions Architect - Associate and AWS Certified Solutions Architect - Professional certification exams.

For a limited time, the first 1,000 learners who pass the assessment can earn a 50% discounted certification voucher for the AWS Certified Solutions Architect – Associate exam.

If you are preparing for this exam, I would recommend reviewing the recent AWS Power Hour: Architecting series that was broadcast on Twitch. It was specifically designed for those preparing for the AWS Certified Solutions Architect – Associate (SAA-C03) exam.

AWS Certified Solutions Architect/DevOps Engineer - Professional

Currently, there is a AWS Certified: Professional Challenge available until April 28, 2023. By registering, you can get a 50% discount voucher for the AWS Certified Solutions Architect - Professional, or AWS Certified DevOps Engineer - Professional exam.

There is also a free Skillbuilder course - Exam Prep: AWS Certified Solutions Architect – Professional. This is a free five-hour intermediate digital course designed for individuals preparing for the AWS Certified Solutions Architect – Professional exam.

The new AWS Power Hour: Architecting Pro streams start on February 13, 2023, and will focus on material for the AWS Certified Solutions Architect – Professional (SAP-C02) exam. You can register here to be emailed updates, reminders, and resources.

Self-Hosting Bitwarden On AWS

Jason Paul — Tue, 03 Jan 2023 21:52:29 +0000

Quick Start - Github Project

Introduction

I've used LastPass for quite a few years now as my primary password storage service. I randomly generate most of the passwords for websites, and I don't even know what most of them are, so I depend on my LastPass Vault quite heavily.

I am using Multi-Factor Authentication, and even paid for LastPass Premium for a while so I could use a Yubikey for access. After doing this for a while, I switched to using Google Authenticator for MFA. It concerns me that while MFA can be added as a layer to access the LastPass vault using the browser plugin or app, there is no extra encryption on the Vault itself. That means that if the data ever got stolen, the MFA layers would be useless, and only the master password would need to be cracked to access the passwords and other Vault data.

In December 2022, LastPass released details around a recent security incident from August 2022, where an unauthorized third party gained access to backups of production data, including vault data. While the vaults are encrypted and secured with 256-bit AES encryption, the master password can be brute-forced to decrypt the vault. This isn't the first security incident suffered by LastPass, but it is very concerning to me in this case that vault data was stolen.

Tom Lawrence from Lawrence Systems posted a number of YouTube videos on the topic, which drew my attention to the urgency of the problem. I would highly recommend watching this video for more details:

https://youtu.be/x2K2h6W4pTw

Considering Alternate Password Managers

I had been considering moving to a self-hosted password manager for a while, but this latest security incident prompted me to take more urgent action to do so, and rotate all of my site passwords in the process.

I've used 1Password for work, and it didn't seem too bad, but it isn't an open source platform, and doesn't look like it can be self hosted. There is a survey you can submit to them on the topic, if this is something you'd like them to do.

I also looked at KeePass Password Safe and KeePassXC, which are open source. KeePassXC does have a browser plugin, but the password database is stored as a file, which makes it trickier to maintain as it would need to be manually synchronized between computers. Other products like Bitwarden and VaultWarden run as a full server, and have browser plugins and phone applications that can talk to it.

Tom also did a separate video on this topic:

https://youtu.be/46aiqnEHOVU

I considered using VaultWarden, which is a free, alternative implementation of Bitwarden written in Rust, but the fact that Bitwarden is run through a number of Docker containers appeals to me, and I can dedicate the resources in my homelab, or in AWS, to run it. Bitwarden also has a number of other features that appeal to me, and supporting the original project also seemed to make sense. Using Bitwarden also would maintain the best compatibility with browser plugins and mobile applications.

Setting Up The AWS Environment

Now that I had decided on setting up Bitwarden, I had to build an AWS environment to run it on. I decided to do this in Terraform, as it lets me document Infrastructure-as-Code, and makes it easy to set up and tear down. I've put all of the code needed with instructions and minimal tweaks in this Github project folder for others to use as well, if it is helpful.

Most of the AWS environment setup is pretty generic. The real configuration is in the userdata.sh file which provisions the EC2 instance after Terraform brings it up. I considered doing some of this work with Ansible using a remote-exec provisioner, but this is really only as a last resort and using the User Data to run Linux commands after launch is supported by, and recommended for Amazon EC2.

I chose not to automate the Bitwarden installation itself, as there is a bit of a chicken and egg situation regarding the prerequisites for installing Bitwarden. More on that later.

Bitwarden Prerequisites

One of the requirements for installing Bitwarden is a domain name with DNS records. This could be created in Amazon Route 53 if you are creating a new domain or subdomain already managed in AWS. I am using CloudFlare for DNS for this domain, so I had to create an A record for Bitwarden to use, pointing to the public IP address of the EC2 instance created by Terraform:

I also needed an SMTP Server for Bitwarden to use to send email verification links. For this purpose, using an external SMTP server is easier than setting up your own mail server. GMail has options to use their SMTP servers with authentication, but for this test, I decided to use Amazon Simple Email Service (SES). In order to send email from the linuxtek.ca domain, I needed to add the domain as a verified identity. I used the Easy DomainKeys Identified Mail (DKIM) wizard, and added the required CNAME, MX, and TXT DNS records in CloudFlare:

Shortly after this was done, SES was able to verify the identity successfully. I also added my personal email address I would be testing with under verified identities, as by default, the Amazon SES account is in a sandbox, and is only able to send email to verified addresses. If you will be using this in production, you will need to submit a support case to Amazon in order to move to production. For the purposes of this test, this was not necessary.

In order to authenticate with Amazon's SMTP server, I also needed to create an SMTP username and password. This can be done under Amazon SES > SMTP Settings, and basically creates an IAM user which only has access to write to SES. Make sure to write down the username and password as they are not available after creation. Also pro tip - the IAM username is different from the SMTP username, so make sure to record both.

Installing Bitwarden

Tom Lawrence has done a great video on installing Self-Hosted Bitwarden, and if you want a good walkthrough I'd recommend giving it a view:

https://youtu.be/SSLGa0LjTrA

The Bitwarden installation documentation for on-premise Linux installation is also very easy to follow, and a recommended read.

I will go through the steps I performed, as some of the installation steps like creating the bitwarden user are taken care of by Terraform.

I SSH'd into the AWS EC2 instance as the admin user, using the keypair that was inserted into the machine as part of the setup.

Once logged in, I switched to the Bitwarden user using sudo su bitwarden. If you want you can specify a password for this user to log in directy, but I prefer to use my keypair and only use the admin user.

In the /opt/bitwarden directory, the bitwarden.sh file is already present, so I ran that using ./bitwarden.sh install.

I entered the domain name that I had created in CloudFlare: bitwarden.linuxtek.ca.

For this test, I wanted to use a Let's Encrypt SSL certificate, so I said "yes" on the next prompt, and entered my personal email address to send expiration reminders to.

When prompted, I entered linuxtek-vault for the name of the Bitwarden database. After this, the installer pulled down all of the required Docker containers. I then entered my Bitwarden Installation ID and Key, which I generated at this link.

After entering this, the installer generated some encryption keys, and completed the install.

I then modified the global.override.env file in /opt/bitwarden/bwdata/env to configure these lines:

globalSettings__mail__replyToEmail=no-reply@bitwarden.linuxtek.ca
globalSettings__mail__smtp__host=REPLACE
globalSettings__mail__smtp__port=587
globalSettings__mail__smtp__ssl=false
globalSettings__mail__smtp__username=REPLACE
globalSettings__mail__smtp__password=REPLACE
globalSettings__disableUserRegistration=false
globalSettings__hibpApiKey=REPLACE
adminSettings__admins=

In my case, I added the SMTP endpoint address for Amazon SES, from the Amazon SES > SMTP Settings page. I used SMTP port 587, and specified to use SSL. I entered in the SMTP username and password I generated and recorded when generating my SMTP credentials. For this test, I left disableUserRegistration=false to allow registration, but once I was set up, I would disable that. For adminSettings__admins, I put in my personal email address.

Once I finished editing the file, as per the installation guide, I switched back to /opt/bitwarden, and ran an ./bitwarden.sh rebuild and ./bitwarden.sh restart to ensure the settings took effect. Many of the Docker containers were pulled down, extracted, and started; so it took a few minutes to completely start up. I also ran ./bitwarden.sh updateself and ./bitwarden.sh update to make sure I had the latest builds.

Once complete, I was able to run docker ps to see all of the containers running:

And by visiting the domain name I had set, I was presented with the Bitwarden login screen:

After creating an account with my personal email address, I logged into the Vault and saw the account would need to be verified via email address:

Clicking the "Send email" button successfully sent a verification email via Amazon SES to my personal email. Once I clicked the link, I entered my credentials again, and the account was verified, and I had full access to all features:

After testing, I ran a terraform destroy on the environment, and removed all of the DNS records from CloudFlare, to prevent any abuse of my account (just a heads up for anyone looking to exploit the system).

Troubleshooting

I did run into a few issues while setting this up initially, mostly around the Amazon SES configuration. Mainly this was due to using the IAM username as the SMTP username, and they are not the same. Definitely make sure you record both once you set up the credentials.

To troubleshoot the verification email, use the logs under /opt/bitwarden/bwdata/logs/api/Api. The errors were fairly clear when there I had an SMTP configuration issue.

Also, be sure to do a ./bitwarden.sh rebuild and ./bitwarden.sh restart any time you make changes to the Bitwarden configuration, to ensure the settings are applied.

Also, when using SES, keep in mind that in Sandbox mode, you won't be able to send to any emails to addresses not in your verification list. Initially I thought I would need to switch to a Production mode to test, but all I needed to do was verify that email address ahead of time. Thanks to Traian Ciobanu for the help troubleshooting this.

Conclusion

When I initially decided to set Bitwarden up to self host in AWS, I had ideas to share the service with my family. Eventually I decided it was too much of a risk to keep the server open on the internet, and locking it down would be costly and complex. Instead, I will be hosting a Bitwarden server in my homelab behind my firewall, and access it using VPN if needed, to avoid having to open ports.

Hopefully the resources and information in this article can help others who are looking to self host, and you can decide if hosting in AWS makes sense for you.

Amazon Lightsail Free Credits Draw

Jason Paul — Mon, 17 Oct 2022 20:17:21 +0000

Editor's Note

This article was originally published on www.linuxtek.ca and some of the links and references will refer back to that site.

Introduction

I've been exploring the Amazon Lightsail services recently through these previous articles:

As part of the research, I've been fortunate enough to speak with a number of resources through my contacts in the AWS Community Builders Program. I've been provided two codes for $50 of credits for Amazon Lightsail services, and I want to pass them on to you, dear reader!

If you're hosting workloads on Amazon Lightsail, or want to try some of them out, then this is the draw for you.

The Draw

You can enter the draw at [removed]

Good luck, and I hope the winners build something cool with these credits. I'd love to hear about it!

Update - November 1

Congratulations to our two winners! I used a dice roller to randomly choose two winners, and have emailed them the codes.

Testing Lightsail Containers with Minecraft

Jason Paul — Mon, 17 Oct 2022 20:14:03 +0000

Editor's Note

This article was originally published on www.linuxtek.ca and some of the links and references will refer back to that site.

Introduction

After my previous article where I used Amazon Lightsail to migrate my blog to an Amazon Lightsail VPS (Virtual Private Server) instance, I decided to try out the Lightsail Container Service to see if it was similarly easy to use.

The use case here would be that in some cases for testing a service in a Docker container, it would be easier to deploy it on a service like Lightsail, rather than spinning up an entire environment using AWS Elastic Container Service, or Elastic Kubernetes Service. While both of these services can use AWS Fargate for serverless container workloads, there is a lot more infrastructure that needs to be built in order to run the container.

Amazon Lightsail Container Service provides an easy way to run your containers in the cloud, and is ideal for simple workloads.

Lightsail Container Service Details

Before getting started, it's important to understand how the service is designed.

While Lightsail provides a simplified deployment method, it's important to understand that under the hood, the service is powered by many of the other AWS services, such as Amazon Elastic Compute Cloud (Amazon EC2), Amazon Relational Database Service (RDS), Application Load Balancer, etc. For more details see this blog post.

Within a Lightsail Container Service, there are multiple nodes running the containers, and a load balancer.

The Scale and Power are both capacity parameters that can be set when creating the container service. The scale specifies the number of compute nodes in your container service, and the power specifies the memory and vCPUs of each node in your service.

These values can be changed dynamically in the Lightsail console after the initial creation without any downtime, allowing to adjust for over/under-provisioning.

Running Minecraft

Minecraft is a good test for a service like Lightsail, as it will put some stress on the service. Althought it's not quite load testing, when logging onto a Minecraft server, you can immediately tell if the service is struggling by looking at statistics like CPU and memory usage, latency/lag, and any errors in the Minecraft console CLI.

I've written a number of articles on how to set up Minecraft on a server, including automating the install using Ansible. For testing Minecraft as a Docker container, I will be using the itzg/minecraft-server Docker image, as it is already built and well maintained. More information can be found on the Docker Hub page, and Github.

Setting Up Lightsail

In the AWS Console, you can search the services for Lightsail, or go directly to the Amazon Lightsail Console. Once there, click on Containers:

Click the "Create Container Service" button, and go through the menus to set up the container service:

Location - We will leave the default as us-east-1.
Container Service Capacity - As Minecraft needs a decent amount of RAM to run, we will choose Md (Medium) size for 2GB RAM and 1vCPU. The Docker container will try to use 1GB for Minecraft by default, so smaller sizes would not be recommended.
Scale - Since everything is self-contained, we will only choose x1 instance to run.
Deployment - Click the +Set Up Deployment button and choose Specify a custom deployment.
- Container Name - Set this to minecraft-container.
- Image - As the image is already located on Docker Hub, we can enter itzg/minecraft-server as the image to pull from the registry.
- Environment Variables - As per the itzg/minecraft-server documentation, we can auto accept the EULA for Minecraft during setup by setting EULA: TRUE. We will add Key = EULA, Value = TRUE to ensure this is set automatically.
- Open Ports - Minecraft typically allows users to connect on TCP Port 25565, so we will open this port.
- Public Endpoint - Leave this unselected for now. More on this later.
- Under the "Identify Your Service" section, we will name the service minecraft-service.

Once complete, the settings should look like this:

Review the Summary section and be aware of the cost of the container service:

As we will be temporarily testing, this shouldn't incur a large monthly charge. However, be aware that you are charged for your container service whether it's enabled or disabled, and whether it has a deployment or not. You must delete your container service to stop being charged for it.

Click the Create Container Service button once everything is filled out:

It may take a few minutes for the service and deployment to load. Once the service is available, you can click on Deployments, and Open Log to see the progress as the container starts up:

The Logs screen will show the progress as the Docker container is initialized, and the Minecraft server is launched:

Wait until the Minecraft world completes generating. It should look like this when complete:

Connecting to the Minecraft Server

The Minecraft server is now running, but we haven't set a public endpoint to connect into the container service via the internet, so there is no way to connect. Unfortunately, there is a limitation of Lightsail Containers where the public endpoint can only be HTTP or HTTPS, due to the way the Application Load Balancer is set up. This article confirms the limitation:

The public endpoint of Lightsail container services supports HTTPS only, and it does not support TCP or UDP traffic.

I did test trying to find a way around this, such as using an NGINX Reverse Proxy to stream the traffic via an open HTTP/HTTPS port to the internal port 25565. This project seemed promising and was designed for a similar function, and when tested locally, would forward the traffic on an HTTP port on to the Minecraft server and allow a client to connect.

Unfortunately the web server container would fail health checks and get terminated; since the web traffic would be passed to Minecraft, which wouldn't know how to respond. Adding a separate active health check is a feature of the paid version of NGINX - NGINX Plus.

So unfortunately while the Minecraft server does appear to run on Lightsail Containers, we are not able to connect to the server to test with a Minecraft client.

Other Limitations

Initially, rather than using the Amazon Lightsail web console, I wanted to define all of the infrastructure as code using Terraform. Unfortunately, Lightsail components are not fully included in the official AWS Terraform provider. Some of the components, such as the Lightsail Container Service and Lightsail Instance are available, however others such as Load Balancer resources are not currently available. There are open Pull Requests on the Hashicorp Github, but they have been sitting for a few years now. They would need to be upvoted to increase priority. Something to be aware of if you're looking to leverage Lightsail fully with Infrastructure-As-Code - some of the components may not be available.

The AWS CLI v2 does have a full set of commands for Lightsail, which can be helpful if you don't want to use the web console.

Troubleshooting

When creating the Lightsail Container Service for the first time, I received this error:

CreateContainerService[us-east-1]
Sorry, you've either reached or will exceed your maximum limit of Lightsail Container Services.

This was puzzling because I didn't have any other Lightsail Container Services active.

Checking in the Service Quotas section in AWS, the quotas for Amazon Lightsail appear to have enough capacity by default to allow the service creation, although the Lightsail quotas cannot apparently be changed or increases requested.

Investigating further, this documentation gave information on how the CreateContainerService API call works, but it didn't point out the specific issue.

The problem ended up being that I was initially trying to create a Large capacity container. Once I switched to testing with a Medium size, it worked fine. I spoke with some contacts via the AWS Community Builders Program, and was advised that the error messages around this type of scenario are being improved, and if you hit this issue, to contact Customer Support for assistance, and they should be able to help.

Conclusion

Lightsail Containers are an interesting service, which currently can be leveraged for hosting web applications running inside containers, as well as running other workloads. There are some limitations, but intial setup can be a lot easier than a full ECS/EKS setup.

This article only goes through a basic test. There are a number of other features in Lightsail Containers which allow communication between containers in a deployment, and horizontal scaling.

Definitely review the documentation and make sure that your use case would be suited to running as a workload on Lightsail. This FAQ may answer some of the more common questions, and this demo video (while a bit older), may be an interesting watch:

https://youtu.be/rsMdqPLmI4U

Resources

Migrating Wordpress from GCP to AWS

Jason Paul — Fri, 14 Oct 2022 18:35:28 +0000

Editor's Note

This article was originally published on www.linuxtek.ca and some of the links and references will refer back to that site.

Introduction

You may have noticed some changes to this site. Along with some style and color changes, I've updated the domain, and focused the pages on my technical blog. Originally this site started as an administrative page for the Minecraft servers I am hosting. I built the first Minecraft server in Google Cloud on a general Compute Engine instance, and was running this web page on a separate smaller instance. As the player count increased, I had to increase the resources on the VM to keep performance stable, but this quickly used up the free credits. I did a blog post about the cost and the steps I took to optimize things. Eventually I moved the Minecraft servers to my homelab, where I had more compute resources available that wouldn't incur a monthly cost. I did a detailed post about this as well.

This website, as well as another personal site continued to run in GCP, however I was paying around $35 CDN a month to host everything in the cloud.

I've been focusing more on Amazon Web Services instead of Google Cloud Platform for my cloud experience recently, and last month was selected to join the AWS Community Builders program. One of the perks of the program is some additional free AWS credits, so I decided to take the opportunity to move this site to AWS to take advantage of using those up, as I seem to have an excess of them at this time. I'm sure most of the AWS credits will go towards experimentation and learning, but this is a consistent cost that they can be put towards as well.

GCP Wordpress Instance

This site was built on an e2-micro Compute Engine instance, which has very limited resources. Normally this isn't isn't an issue as the CPU is burstable, but when performing large OS updates, it does take quite a while to finish.

Google Cloud provides one free e2-micro instance per month in their Free Tier, but with this and another website running, I exceeded the free tier.

I built the website server on the following LEMP stack:

Linux - Debian 10 "Buster"
NGINX lightweight web server
MySQL (MariaDB)
PHP 7.3 (later upgraded to 8.1)

I decided to use NGINX instead of Apache for the webserver, as it had a lower footprint, which made it more suitable for running on an e2-micro instance. I followed multiple guides to install Wordpress on the server. This guide from DigitalOcean is probably the closest that I used.

AWS Wordpress Instance

Deciding how to set up the AWS Wordpress instance took quite a bit of thought. I had thought about using a more complex setup including an EC2 (Elastic Compute Cloud) instance, a VPC (Virtual Private Cloud), and serverless components like RDS (Relational Database Service) for the database, and S3 (Simple Storage Service) for file storage. Another way I had read about that could be challenging, was to set up Wordpress on EKS (Elastic Kubernetes Service). I could also automate a lot of the setup using Terraform.

While these all sounded like excellent learning opportunities for the future, I decided against going this route, as I wanted a boring, stable, uncomplicated web server to host my articles. I also had to keep in mind that I wanted to be able to migrate the data from one Wordpress instance to the new one, and the more complex the architecture, the more potential compatibility issues or points of failure there would be.

I ended up going with the AWS Lightsail platform for a number of reasons:

There is a Bitnami AWS Lightsail Wordpress image which is a very similar stack to the one I manually set up. I had used it for another website, and it was fairly straightforward, running on Debian 11 "Bullseye", which I prefer. It use Apache, MariaDB, and PHP 8.0, so it is more up to date.
Using this pre-built setup would save time, as all of the versions would be tested before release, and should remain stable, rather than me having to build my own stack from scratch.
This would make the migration from my old Wordpress instance easier, and would allow me to upgrade later on with new system images.
If this migration plan worked, I could use it to migrate other sites to with the same steps.
AWS Lightsail has functionality for a static IP address, automatic daily snapshots, and a low cost of about $10/month for a decently sized instance.
There is the option to increase the virtual server resources, and even upgrade to EC2 in the future if necessary.
Lightsail has additional features such as CDN (Content Delivery Network) Distribution similar to Amazon CloudFront, and the option for Load Balancers or a managed database if needed. For the low traffic of my site, this will probably not be necessary for a long time.

Based on my requirements for simplicity and cost, AWS Lightsail seems like a good choice for hosting my Wordpress sites.

Exporting the Wordpress Database

The first step of the migration was to export the database, which was running locally in the GCP Compute Instance on MariaDB. To refresh my memory on the database details, I checked the wp-config.php file located in /var/www/html/wordpress, which had the following sections with the database name, username, and password:

To back up the database, I used the following command to dump it to a file using the values from the wp-config.php file. When run, it prompted for the DB_PASSWORD value. You can enter the password as an argument on command line, but that wouldn't be considered secure.

mysqldump -u DB_USER -p DB_NAME > /home/user/wordpress-backup.sql

Backing Up the Wordpress Directory

The only folder we needed to be concerned about on the old server was the /var/www/html/wordpress directory. The web server itself would be changed from NGINX to Apache, and the Bitnami image would have everything configured already. This directory includes all of the configuration, settings, posts, media uploads, content, etc from the older server.

In the /home/username directory, I ran the following command to back up the folder to a tar.gz archive file:

tar -czvf wordpress-backup.tar.gz /var/www/html/wordpress

The switches used perform the following:

-z : Compress archive using gzip program in Linux or Unix
-c : Create archive on Linux
-v : Verbose i.e display progress while creating archive
-f : Archive File name

Creating Wordpress Server on AWS Lightsail

From the AWS Console search for "Lightsail" or just navigate to lightsail.aws.amazon.com. Although it is clickops, since this work won't be frequently repeated or the resources temporary, I created the instance using the web interface. I clicked "Create Instance" and followed the menus to choose the platform, and Wordpress as the blueprint:

I changed the SSH keypair by deleting the default id_rsa, and uploaded my own public SSH key, so that I could access the server without using a password.

I enabled Automatic Snapshots to occur daily, and chose an off-peak time for them to run.

I chose the instance plan that seemed like the best value for the usage I expected. This could always be modified or scaled up later on.

I named the instance "linuxtek-wordpress" and created the instance. Once the instance was created, I clicked Networking, created a Static IP, and attached it to the newly created instance. This would ensure that I could use the IP reliably without it changing.

Under Networking, I also adjusted the IPv4 firewall to restrict SSH access to my public IP only, so nobody else can attempt to connect. I also disabled IPv6 networking, as it didn't seem necessary. By default, port 80 and 443 are open to allow web traffic, so no changes were needed here.

Once the Lightsail instance was set up, I was able to SSH to the server using the username bitnami.

I adjusted the timezone and hostname using the following commands:

sudo timedatectl set-timezone America/Toronto
sudo hostnamectl set-hostname linuxtek.ca

I then used SCP to copy over the database backup and wordpress folder archive to the new server.

Restoring Wordpress Data to the New Server

Because the new AWS server was created via a template, I didn't know the generated usernames or passwords that had been set up. Fortunately, Bitnami puts a number of files in the /home/bitnami directory that are helpful. This documentation can also be helpful. I was able to get the database name, username, and password from the /opt/bitnami/wordpress/wp-config.php file as on the previous server.

For compatibility, I didn't want to adjust any of the database settings, so I restored my backup from the dump file right on top of the existing database using this command (entering the database password when prompted):

mysql --user bn_wordpress --database bitnami_wordpress --password < wpdb-backup.sql

I then stopped the Bitnami stack, which controls all of the Wordpress services. I needed them running to be able to manipulate the database, but for file level changes, I wanted them stopped, so I ran the following:

sudo systemctl stop bitnami

Note: There is also a control script at /opt/bitnami/ctlscript.sh which can be used to restart individual services, or stop/start all services, but I found it easier to use systemctl.

Once the services were stopped, I deleted the /opt/bitnami/wordpress folder, then recreated it and extracted the archive tar.gz file into it. I used the --strip-components flag so the archive would dump the contents of the backed up /var/www/html/wordpress folder without including the full file path:

sudo rm -rf /opt/bitnami/wordpress
mkdir /opt/bitnami/wordpress
tar xvfz /home/bitnami/wordpress-backup.tar.gz -C /opt/bitnami/wordpress --strip-components=4

Once everything was extracted, I recursively adjusted the permissions and ownership of the files and folders to work with the Bitnami stack. The Bitnami documentation explains this a bit, as files and directories are owned by the user bitnami, and group daemon. There are a number of requirements for the files and directory permissions, which can be set using the commands provided below:

sudo chown -R bitnami:daemon /opt/bitnami/wordpress
sudo find /opt/bitnami/wordpress -type d -exec chmod 775 {} \;
sudo find /opt/bitnami/wordpress -type f -exec chmod 664 {} \;
sudo chmod 640 /opt/bitnami/wordpress/wp-config.php
sudo systemctl start bitnami

Updating Domain Name in Wordpress

Because I was switching from using a subdomain to the full domain, I needed to update all references from minecraft.linuxtek.ca to just linuxtek.ca. This would ensure that all links in all published articles would work, and all images and other references would be consistent.

I found two ways to do this without using a plugin or script:

The wp-cli has an option that can do a search an replace with the following command:

sudo wp search-replace 'http://olddomain.com' 'http://newdomain.com' --precise --recurse-objects --all-tables

For me this was:
sudo wp search-replace 'https://minecraft.linuxtek.ca' 'https://linuxtek.ca' --precise --recurse-objects --all-tables

The other way was to directly edit the database tables (which was more reliable). This article (Method #2) goes through the steps to access the MySQL CLI to run the commands. I again took the db_name, db_user, and db_pass values from the wp-config.php file to log in:

mysql -u db_user -p database_name

Once logged in to the mysql> prompt, I ran the following commands:

UPDATE wp_options SET option_value = replace(option_value, 'http://olddomain.com', 'http://newdomain.com') WHERE option_name = 'home' OR option_name = 'siteurl';
UPDATE wp_posts SET guid = replace(guid, 'http://olddomain.com', 'http://newdomain.com');
UPDATE wp_posts SET post_content = replace(post_content, 'http://olddomain.com', 'http://newdomain.com');
UPDATE wp_postmeta SET meta_value = replace(meta_value,'http://olddomain.com', 'http://newdomain.com');
\q;

After each of the commands, it would return the number of rows matched and changed. I ran a few queries to make sure that the values were correct, then again restarted the bitnami stack with sudo systemctl restart bitnami.

Updating Domain Names in DNS Provider

I use CloudFlare for some of my DNS services, which also provides some caching and DDOS protection. If using Amazon Route 53, or another DNS provider, the domain names and IPs would need to be updated in your provider so they would resolve properly.

Under my domain DNS settings, I updated the following:

The www A record would resolve to the static IP of the new Lightsail server. It is proxied through CloudFlare for DDOS protection.
The linuxtek.ca A record would resolve to the static IP of the new Lightsail server. It is proxied through CloudFlare for DDOS protection.
I updated the minecraftadmin subdomain A record to point to a non-routeable IP 192.0.2.1, as I wanted it to redirect to the main linuxtek.ca domain (more on that below).

To ensure that any references to the old subdomain redirect to the new one, I set up a Page Rule to redirect the traffic with an HTTP 301 response. This tutorial video explains the details but I've included the steps below. Note that I left the A record intact but to an invalid IP, so the traffic would be proxied by CloudFlare, which must be the case.

The $1 is used as a variable, so the URL path value from the second asterisk will be added to the redirected URL, so any full URL from the original domain should redirect now to the new one. I used the dummy IP 192.0.2.1 which is recommended by Cloudflare.

Once the DNS records and Page Rule refreshed and were active (I had to flush my PiHole DNS cache) , I was able to test this with the curl command, and see the HTTP 301 redirect from minecraftadmin.linuxtek.ca to linuxtek.ca:

Another tip that helped, was testing DNS resolution using the DNS server 1.1.1.1, which can have the cache purged at this link. More information is available in this blog post.

Once I could confirm the web traffic was redirecting properly to the AWS instance, I shut down the GCP Compute Engine instance:

Additional Troubleshooting and Debugging

I did run into a few errors while trying to bring up the server after migration. On the initial load up, I ran into this error:

This message wasn't very helpful, so I changed the debugging flag in wp-config.php from false to true:

define( 'WP_DEBUG', true);

After restarting services, and refreshing, I got this error:

After researching the error, to resolve this, I had to add this line at the bottom of the wp-config.php file, and restart services:

define('FS_METHOD', 'direct');

Don't forget to set the WP_DEBUG back to false as well, as it does show debug into on multiple pages that you wouldn't expect otherwise, even if the server is working.

Also pro tip - don't attempt to write a blog post on your site as you take it up and down to get screenshots - you'll probably lose some of your drafts!

Conclusion

With a bit of manual manipulation, it is possible to migrate a Wordpress server between hosts without too much difficulty. I will likely add some backup scripts to automate backing up the /opt/bitnami/wordpress folder, and the Wordpress database; and save them to an S3 bucket. Although I have automated snapshots, this would be an extra layer of protection in case of a failure, and could be easily used to upgrade the server to a new image when it becomes available.

Hopefully this article helps some of you in doing similar tasks!