Amazon Web Services Cloud Architecting Networking Python Technology

Where Is It Five O’Clock Pt: 1

I bought the domain a while back and have been sitting on it for quite some time. I had an idea to make a web application that would tell you where it is five o’clock. Yes, this is a drinking website.

I saw this project as a way to learn more Python skills, as well as some more AWS skills, and boy, has it put me to the test. So I’m going to write this series of posts as a way to document my progress in building this application.

Part One: Building The Application

I know that I want to use Python because it is my language of choice. I then researched what libraries I could use to build the frontend with. I came across Flask as an option and decided to run with that. The next step I had to do was actually find out where it was 5PM.

In my head, I came up with the process that if I could first get a list of all the timezone and identify the current time in them I could filter out which timezones it was 5PM. Once establishing where it was 5PM, I can then get that information to Flask and figure out a way to display it.

Here is the function for identifying the current time in all timezones and then storing each key pair of {Timezone : Current_Time }

def getTime():
    now_utc ='UTC'))
    #print('UTC:', now_utc)
    timezones = pytz.all_timezones
    #get all current times and store them into a list
    tz_array = []
    for tz in timezones:
        current_time = now_utc.astimezone(timezone(tz))
        values = {tz: current_time.hour}
    return tz_array

Once everything was stored into tz_array I took that info and passed it through the following function to identify it was 5PM. I have another function that identifies everything that is NOT 5PM.

def find5PM():
    its5pm = []
    for tz in tz_array:
        timezones = tz.items()
        for timezone, hour in timezones:
            if hour >= 17:
    return its5pm

I made a new list and stored just the timezone name into that list and return it.

Once I had all these together I passed them through as variables to Flask. This is where I first started to struggle. In my original revisions of the functions, I was only returning one of the values rather than returning ALL of the values. This resulted in hours of struggling to identify the cause of the problem. Eventually, I had to start over and completely re-work the code until I ended up with what you see above.

The code was finally functional and I was ready to deploy it to Amazon Web Services for public access. I will discuss my design and deployment in Part Two.

Amazon Web Services Linux Networking Technology

Slack’s New Nebula Network Overlay

I was turned on to this new tool that the Slack team had built. As an avid Slack user, I was immediately intrigued to test this out.

My use case is going to be relatively simple for the sake of this post. I am going to create a Lighthouse, or parent node, in an EC2 instance in my Amazon Web Services account. It will have an elastic IP so we can route traffic to it publically. I also will need to create a security group to allow traffic to port 4242 UDP. I will also allow this port inbound on my local firewall.

Clone the GIT repository for Nebula and also download the binaries. I put everything into /etc/nebula

Once you have all of the files downloaded you can generate your certificate of authority by running the command:

./nebula-cert ca -name "Your Company"

You will want to make a backup of the ca.key and ca.cert file that is generated by this output.

Once you have your certificate of authority you can create certificates for your hosts. In my case I am only generating one for my local server. The following command will generate the certificate and keys:

./nebula-cert sign -name "Something Memorable" -ip ""

Where it says “Something Memorable” I placed the hostname of the server I am using so that I remember. One thing that the documentation doesn’t go over is assigning the IP for your Lighthouse. Because I recognize the Lighthouse as more of a gateway I assigned it to in the config file. This will be covered soon.

There is a pre-generated configuration file located here. I simply copied this into a file inside of /etc/nebula/

Edit the file as needed. Lines 7-9 will need to be modified for each host as each host will have its own certificate.

Line 20 will need to be the IP address of your Lighthouse and this will remain the same on every host. On line 26 you will need to change this to true for your Lighthouse. On all other hosts, this will remain false.

The other major thing I changed was to allow SSH traffic. There is an entire section about SSH in the configuration that I ignored and simply added the firewall to the bottom of the file as follows:

- port: 22
proto: tcp
host: any

This code is added below the 443 rule for HTTPS. Be sure to follow normal YAML notation practices.

Once this is all in place you can execute your Nebula network by using the following command:

/etc/nebula/nebula -config /etc/nebula/config.yml

Execute your Lighthouse first and ensure it is up and running. Once it is running on your Lighthouse you can run it on your host and you should see a connection handshake. Test by pinging your Lighthouse from your host and from your Lighthouse to your host. I also tested file transfer as well using SCP. This verifies SSH connectivity.

Now, the most important thing that Slack doesn’t discuss is creating a systemctl script for automatic startup. So I have included a basic one for you here:

Description=Nebula Service

ExecStart=/etc/nebula/nebula -config /etc/nebula/config.yml

That’s it! I would love to hear about your implementations in the comments below!

Linux Networking Technology

Discovering DHCP Servers with NMAP

I was working at a client site where a device would constantly receive a new IP address via DHCP nearly every second. It was the only device on the network that had this issue but I decided to test for rogue DHCP servers. If someone knows of a GUI tool to do this let me know in the comments. I utilized the command line utility NMAP to scan the network.

sudo nmap --script broadcast-dhcp-discover

The output should look something like:

Starting Nmap 7.70 ( ) at 2019-11-25 15:52 EST
Pre-scan script results:
| broadcast-dhcp-discover:
| Response 1 of 1:
| IP Offered:
| DHCP Message Type: DHCPOFFER
| Server Identifier:
| IP Address Lease Time: 7d00h00m00s
| Subnet Mask:
| Time Offset: 4294949296
| Router:
| Domain Name Server:
| Renewal Time Value: 3d12h00m00s
|_ Rebinding Time Value: 6d03h00m00s

This was the test that ran on my local network verifying only one DHCP server. If there were multiple, we would see another response.

Ultimately this was not the issue at my client site but this is a new function of NMAP that I had not used.

Let me know your experiences with rogue DHCP in the comments!