How Logical Replication Works

At its core, logical replication leverages the Write-Ahead Log (WAL). While physical replication copies disk blocks, logical replication decodes the WAL into row-level changes (INSERTs, UPDATEs, and DELETEs).

1. The Publisher: On the source database, you define a Publication. This serves as a set of change sets for specific tables.

2. The Subscriber: On the destination database, you create a Subscription. The subscriber connects to the publisher, pulls an initial snapshot of the data, and then continuously "replays" ongoing changes.

3. The Replication Slot: The publisher uses a replication slot to ensure that WAL files are not deleted until the subscriber has confirmed receipt. This prevents data loss during transient network failures.

Step 1: Configuring the Source (Publisher)

Before starting, ensure your wal_level is set to logical in your postgresql.conf. For managed db this can be done by setting some flag from your cloud provider database management page.

To begin, connect to your source database and create a publication. You can choose to replicate the entire database or specific tables:

-- create publication for all tables
CREATE PUBLICATION <publication_name> FOR ALL TABLE;

-- create publication only for some tables
CREATE PUBLICATION <publication_name> FOR TABLE tableA, tableB, tableC;

-- Digital Ocean Managed Postgres Instance
SELECT aiven_extras.pg_create_publication_for_all_tables('<publication_name>', 'INSERT,UPDATE,DELETE,TRUNCATE')

-- Verify the publication
SELECT * FROM pg_publication;

Step 2: Preparing the Destination (Subscriber)

Important: Logical replication does not replicate schema definitions (DDL). You must ensure the table structures exist on the destination database before starting the subscription.

Once the schema is ready, connect to the destination and initiate the subscription:

CREATE SUBSCRIPTION <subscription_name_here> 
    CONNECTION 'dbname=<database_name_here> host=localhost port=5432 sslmode=disabled user=postgres password=<password_here>' 
    PUBLICATION <publication_name> WITH (slot_name = '<slot_name_here>', create_slot = true, copy_data = true);

Managed Service Nuances

If you are using managed PostgreSQL services, the standard CREATE SUBSCRIPTION command may be restricted due to permissions:

• DigitalOcean (Aiven): Use the aiven_extras extension:

SELECT * FROM aiven_extras.pg_create_subscription(
    '<subscription_name_here>', 
    'dbname=<database_name_here> host=localhost port=5432 sslmode=disabled user=postgres password=<password_here>', 
    '<publication_name>', 
    '<slot_name_here>', 
    TRUE, TRUE
);

• Google Cloud SQL: Ensure the cloudsql.logical_decoding flag is set to on.

Step 3: Monitoring the Migration

The migration happens in two phases: the initial sync (copying existing data) and streaming (applying delta changes). You can monitor the progress with these queries:

SELECT 
    n.nspname || '.' || c.relname AS table_name,
    sr.srsubstate AS state,
    CASE sr.srsubstate
        WHEN 'i' THEN 'initialize'
        WHEN 'd' THEN 'data copying'
        WHEN 's' THEN 'synchronized' 
        WHEN 'f' THEN 'finishedcopy'
        WHEN 'r' THEN 'ready'
    END AS state_description
FROM pg_subscription_rel sr
JOIN pg_class c ON c.oid = sr.srrelid
JOIN pg_namespace n ON n.oid = c.relnamespace;

-- to see the ongoing connections
SELECT * FROM pg_stat_activity;

Monitor Replication Lag

To ensure the destination is caught up before you perform the final cutover, check the lag:

-- for checking current slot progress
SELECT
  slot_name,
  plugin,
  slot_type,
  active,
  confirmed_flush_lsn,
  pg_wal_lsn_diff(pg_current_wal_lsn(), confirmed_flush_lsn) AS slot_lag_bytes
FROM
  pg_replication_slots
WHERE
  slot_type = 'logical';

Step 4: Final Cutover and Cleanup

Once the lag is near zero, point your application services to the new destination database. After the migration is confirmed successful, clean up the replication resources to free up system overhead.

1. Drop the Subscription:

    -- Standard
    DROP SUBSCRIPTION <subscription_name>;
   
    -- for digital ocean managed postgres instance
    SELECT * FROM aiven_extras.pg_drop_subscription('<subscription_name>');
   
    -- If you somehow dropped the publication before removing subscription drop command will get stuck trying to remove slot on publisher
    ALTER SUBSCRIPTION mysub DISABLE;
    ALTER SUBSCRIPTION mysub SET (slot_name = NONE);
   

2. Drop the Publication (on Source):

    -- Finally drop the publication
    DROP publication <publication_name>;
   

3. Remove the Slot (if it persists):

    -- slots should be automatically deleted but in case you want to manually delete one
    SELECT pg_drop_replication_slot('<slot_name>');
   

Sequences are Not Replicated!

Logical replication only copies data changes. It does not keep sequences (used for auto-incrementing IDs) in sync. You can use the following query to get the current sequence values

-- Get all the sequences and their respective value
SELECT t.sequence_name, nextval(t.sequence_name::text) - 1 FROM (SELECT sequence_schema, sequence_name
FROM information_schema.sequences) AS t;

-- Set the value
SELECT setval('<sequence_name>', <value_here>);

Conclusion

Logical replication is an elegant solution for moving data with minimal impact on users. By following these steps—Publication, Subscription, and Monitoring—you can migrate gigabytes or terabytes of data while keeping your application online.

The Problem

By default, Dokku holds onto the Docker image it fetched during the initial deploy. No matter how many times you rebuild or redeploy with the same tag, Dokku won’t pull a fresher image from the registry unless you interfere by deleting it manually.

The Solution: Automate Image Updates with Build Options

Dokku’s flexibility shines if you know where to look. The trick is to tell Dokku to pull the latest image from your registry every time you rebuild—completely bypassing the need to manually delete old images.

Step 1: Add Docker Build Options to Your App

You'll use Dokku's docker-options to modify how the build and deploy steps work for your app.

dokku docker-options:add <app-name> build --pull --no-cache

• Replace <app-name> with the name of your Dokku app.

• --pull makes sure Docker pulls the latest version of the image from your registry.

• --no-cache ensures Docker doesn’t use a cached image locally.

Step 2: Rebuild Your App

Now, whenever you want to update to the latest image (say, after pushing to your Docker registry), run:

dokku ps:rebuild <app-name>

That's it! Dokku will pull down the freshest image, rebuild, and restart your app—no more manual deletions required.

That’s a Wrap

This approach works wonders for keeping your Dokku deployments lean and up-to-date.

But all this got me thinking: what if I could set up a proper network failover? You know, like having a backup parachute in case the first one gets stage fright. That would be pretty cool — automatic protection against actual internet outages, and I could keep streaming, working, or doom-scrolling without missing a beat.

Here is what I ended up with

There was a lot of hacking involved to get to this point, let’s dive in.

The First Problem (May Not Be a Problem for You)

So the first issue I ran into — which you might not face — was that my portable Jio router decided to play hide-and-seek by changing its interface name and MAC address every time it rebooted. Super helpful, right? This made it impossible to apply any persistent configuration.

If your setup doesn’t suffer from this little identity crisis, you can probably skip this part. But if you do — welcome to the club — here’s how I fixed it using udev rules.

Step 1: Identify your device

First, you’ll need to find your device info:

udevadm info -a -p /sys/class/net/enxXXXXXXX

(Replace enxXXXXXXX with your actual interface name.)
Look through the output and note down the important bits, like:

ATTRS{idVendor}=="0bda"
ATTRS{idProduct}=="8153"
ATTRS{serial}=="000001"

Step 2: Create a udev rule

Now that we’ve got what we need, let’s make the rule:

sudo nano /etc/udev/rules.d/70-persistent-net.rules

Add this line:

SUBSYSTEM=="net", ACTION=="add", ATTRS{idVendor}=="0bda", ATTRS{idProduct}=="8153", ATTRS{serial}=="000001", NAME="usbnet0", RUN+="/sbin/ip link set usbnet0 address 02:11:22:33:44:55"

• Replace 02:11:22:33:44:55 with whatever MAC address you want.

• usbnet0 is a custom interface name that will now stay consistent (finally).usbnet0 is a custom interface name that will now always be used.

Step 3: Reload rules or replug device
You can reload the rules like this:

sudo udevadm control --reload
sudo udevadm trigger

Or just take the lazy way like I did and unplug/replug the USB device. Done.

The Second Part: Enter the Failover Magic

Now that we've successfully tamed our devices and given them proper names (so they finally know who they are), it’s time for the fun part — creating the actual failover system.

At this stage, both internet connections are plugged in and ready, but here’s the catch: Linux will only use one of them for traffic at any given time. This decision is made by something called the routing table. Think of it like Google Maps for your packets — it tells your data which road (interface) to take.

Now, in Linux, there’s a thing called the default route — basically the "main road" your traffic takes if there are no better instructions. You can have multiple default routes, and each can be assigned a weight (or "metric"). The lower the weight, the more Linux favors it. And that little piece of knowledge is what makes this whole thing work.

Step 1: Install keepalived

We’re going to use keepalived to automate the failover. It’ll run our script at regular intervals and switch routes if it detects trouble on the primary connection.

If you don’t have keepalived installed yet:

sudo apt install keepalived

Step 2: Create the keepalived configuration

Now create (or edit) the file at /etc/keepalived/keepalived.conf:

sudo nano /etc/keepalived/keepalived.conf

Paste this in:

vrrp_script chk_downtime {
    script "/etc/keepalived/check_downtime.sh"
    interval 3
    weight +20
}

vrrp_instance FAILOVER {
    state MASTER
    interface wlp2s0
    virtual_router_id 51
    priority 200
    advert_int 2

    track_script {
        chk_downtime
    }

    notify_master "/etc/keepalived/failover.sh"
    notify_backup "/etc/keepalived/failover.sh"
}

Step 3: Write the downtime check script

This little script checks if your primary connection is still alive.

Create the file:

sudo nano /etc/keepalived/check_downtime.sh

Paste:

#!/bin/bash

logger "check_wlp3s0: Checking internet Access via Wifi"
TARGET="8.8.4.4"
INTERFACE="wlp2s0"
GATEWAY="192.168.1.1"

# Check current route
CURRENT_ROUTE=$(ip route get $TARGET 2>/dev/null)

if ! echo "$CURRENT_ROUTE" | grep -q "dev $INTERFACE"; then
    echo "Route to $TARGET is not via $INTERFACE. Adding route..."
    ip route add $TARGET via $GATEWAY dev $INTERFACE
fi

ping -I wlp3s0 -c 2 -W 1 $TARGET > /dev/null 2>&1

if [ $? -eq 0 ]; then
    echo "Internet is reachable via wlp3s0"
    /etc/keepalived/set_interface.sh
    exit 0
else
    echo "Internet is not rechable via wlp3s0"
    /etc/keepalived/set_interface.sh
    exit 1
fi

Don’t forget to give it execute permissions:

sudo chmod u+x /etc/keepalived/check_downtime.sh

Step 4: Create the failover script

Almost there — now let’s add the script that actually makes the switch.

Create:

sudo nano /etc/keepalived/failover.sh

Paste:

#!/usr/bin/env bash

# Network Interface Switching Script
# Automatically switches between primary and secondary network interfaces
# based on connectivity tests and manages NAT rules accordingly

# set -o errexit   # Exit on any command failure [3]
# set -o pipefail  # Exit on pipe failure [3]
# set -o nounset   # Exit on undefined variables [3]

# ============================================================================
# CONFIGURATION
# ============================================================================

readonly TARGET_HOST="8.8.4.4"
readonly PRIMARY_INTERFACE="wlp2s0"
readonly SECONDARY_INTERFACE="usbnet0"
readonly PRIMARY_GATEWAY="192.168.1.1"
readonly SECONDARY_GATEWAY_DEFAULT="192.168.225.1"
readonly NAT_SUBNET="10.10.2.0/24"
readonly PRIMARY_METRIC=200
readonly SECONDARY_METRIC=210

# ============================================================================
# UTILITY FUNCTIONS
# ============================================================================

# Print error messages to stderr [10]
error() {
    printf "ERROR: %s\n" "$*" >&2
}

# Print informational messages
info() {
    printf "INFO: %s\n" "$*"
}

# Check if command succeeded [13]
check_command() {
    if ! "$@"; then
        error "Command failed: $*"
        return 1
    fi
}

# ============================================================================
# NETWORK INTERFACE FUNCTIONS
# ============================================================================

# Check if network interface exists and is available
is_interface_available() {
    local interface="$1"
    ip link show "$interface" &>/dev/null
}

# Get gateway for specific interface from routing table
get_interface_gateway() {
    local interface="$1"
    ip route show default | grep "dev $interface" | awk '{print $3}' | head -1
}

# Obtain gateway via DHCP for interface
obtain_dhcp_gateway() {
    local interface="$1"
    local gateway

    info "Attempting to obtain gateway via DHCP for $interface..."

    # Run dhclient and extract gateway from output [8]
    gateway=$(dhclient -v "$interface" 2>&1 | awk '/DHCPACK/ {print $NF}' | head -1)

    if [[ -n "$gateway" ]]; then
        # Remove routes without metrics to avoid conflicts
        local no_metric_routes
        no_metric_routes=$(ip route show default | awk '!/metric/ {print}')
        if [[ -n "$no_metric_routes" ]]; then
            echo "$no_metric_routes" | while read -r route; do
                ip route del $route 2>/dev/null || true
            done
        fi
        echo "$gateway"
    else
        error "Failed to obtain gateway via DHCP"
        return 1
    fi
}

# Get current gateway with lowest metric
get_current_gateway() {
    ip route show default | \
        awk 'BEGIN {min=10000} 
             {if ($0 ~ /default/ && $NF+0 < min) {min=$NF; gw=$3}} 
             END {print gw}'
}

# Test connectivity to target via specific interface
test_connectivity() {
    local interface="$1"
    local target="$2"

    ping -I "$interface" -c 2 -W 1 "$target" &>/dev/null
}

# ============================================================================
# ROUTING MANAGEMENT FUNCTIONS
# ============================================================================

# Add specific route if it doesn't exist
ensure_target_route() {
    local target="$1"
    local gateway="$2" 
    local interface="$3"

    local current_route
    current_route=$(ip route get "$target" 2>/dev/null || true)

    if ! echo "$current_route" | grep -q "dev $interface"; then
        info "Adding route to $target via $interface"
        check_command ip route add "$target" via "$gateway" dev "$interface"
    fi
}

# Flush all default routes and set new ones
configure_routing() {
    local primary_gw="$1"
    local primary_int="$2"
    local secondary_gw="$3"
    local secondary_int="$4"
    local primary_metric="$5"
    local secondary_metric="$6"

    info "Configuring routing with primary: $primary_int, secondary: $secondary_int"

    # Flush existing default routes [6]
    ip route flush default

    # Add primary route
    info "Running: ip route add default via $primary_gw dev $primary_int metric $primary_metric"
    check_command ip route add default via "$primary_gw" dev "$primary_int" metric "$primary_metric"

    # Add secondary route if available
    if [[ -n "$secondary_gw" && -n "$secondary_int" ]]; then
        check_command ip route add default via "$secondary_gw" dev "$secondary_int" metric "$secondary_metric"
    fi
}

# ============================================================================
# NAT/IPTABLES MANAGEMENT FUNCTIONS
# ============================================================================

# Check if iptables rule exists [9]
iptables_rule_exists() {
    local interface="$1"
    iptables -t nat -C POSTROUTING -s "$NAT_SUBNET" -o "$interface" -j MASQUERADE 2>/dev/null
}

# Remove iptables rule if it exists
remove_iptables_rule() {
    local interface="$1"

    if iptables_rule_exists "$interface"; then
        info "Removing NAT rule for $interface"
        iptables -t nat -D POSTROUTING -s "$NAT_SUBNET" -o "$interface" -j MASQUERADE
    fi
}

# Add iptables masquerade rule
add_iptables_rule() {
    local interface="$1"

    if ! iptables_rule_exists "$interface"; then
        info "Adding NAT rule for $interface"
        iptables -t nat -A POSTROUTING -s "$NAT_SUBNET" -o "$interface" -j MASQUERADE
    fi
}

# ============================================================================
# MAIN LOGIC FUNCTIONS
# ============================================================================

# Initialize secondary interface and get its gateway
setup_secondary_interface() {
    local secondary_gw=""

    # if is_interface_available "$SECONDARY_INTERFACE"; then
    #     secondary_gw=$(get_interface_gateway "$SECONDARY_INTERFACE")

    #     info "Secondary Gateway: ${secondary_gw:-"Not found"}"

    #     if [[ -z "$secondary_gw" ]]; then
    #         secondary_gw=$(obtain_dhcp_gateway "$SECONDARY_INTERFACE" || echo "")
    #         if [[ -n "$secondary_gw" ]]; then
    #             info "Obtained secondary gateway: $secondary_gw"
    #         fi
    #     fi
    # else
    #     info "Secondary interface $SECONDARY_INTERFACE not found or not connected. Skipping secondary routing."
    # fi

    # echo "$secondary_gw"
    echo "$SECONDARY_GATEWAY_DEFAULT"
}

# Handle primary interface routing and NAT
configure_primary_interface() {
    local current_gw="$1"
    local secondary_gw="$2"

    if [[ "$current_gw" != "$PRIMARY_GATEWAY" ]]; then
        info "Switching to: $PRIMARY_INTERFACE"

        configure_routing "$PRIMARY_GATEWAY" "$PRIMARY_INTERFACE" \
                         "$secondary_gw" "$SECONDARY_INTERFACE" \
                         "$PRIMARY_METRIC" "$SECONDARY_METRIC"

        add_iptables_rule "$PRIMARY_INTERFACE"
    else
        info "Already using $PRIMARY_INTERFACE as default gateway."
        if ! iptables_rule_exists "$PRIMARY_INTERFACE"; then
            add_iptables_rule "$PRIMARY_INTERFACE"
        fi

        remove_iptables_rule "$SECONDARY_INTERFACE"
    fi
}

# Handle secondary interface routing and NAT
configure_secondary_interface() {
    local current_gw="$1"
    local secondary_gw="$2"

    if [[ -n "$secondary_gw" && "$current_gw" != "$secondary_gw" ]]; then
        info "Switching to: $SECONDARY_INTERFACE"

        configure_routing "$secondary_gw" "$SECONDARY_INTERFACE" \
                         "$PRIMARY_GATEWAY" "$PRIMARY_INTERFACE" \
                         "$SECONDARY_METRIC" "$((PRIMARY_METRIC + 20))"

        add_iptables_rule "$SECONDARY_INTERFACE"
    else
        info "No working secondary interface or already using it as default gateway."
        if ! iptables_rule_exists "$SECONDARY_INTERFACE"; then
            add_iptables_rule "$SECONDARY_INTERFACE"
        fi

        remove_iptables_rule "$PRIMARY_INTERFACE"
    fi
}

# Display current routing configuration
show_routing_status() {
    echo ""
    info "Applied following settings:"
    ip route show default
}

# ============================================================================
# MAIN EXECUTION
# ============================================================================

main() {
    info "Starting network interface switching script"

    # Setup secondary interface
    local secondary_gw
    secondary_gw=$(setup_secondary_interface)

    # Ensure target route exists via primary interface
    ensure_target_route "$TARGET_HOST" "$PRIMARY_GATEWAY" "$PRIMARY_INTERFACE"

    # Get current gateway
    local current_gw
    current_gw=$(get_current_gateway)
    info "Current Gateway: $current_gw"

    # Test primary interface connectivity [8]
    if test_connectivity "$PRIMARY_INTERFACE" "$TARGET_HOST"; then
        info "Target $TARGET_HOST is reachable via $PRIMARY_INTERFACE"
        configure_primary_interface "$current_gw" "$secondary_gw"
    else
        info "Target $TARGET_HOST is NOT reachable via $PRIMARY_INTERFACE"
        configure_secondary_interface "$current_gw" "$secondary_gw"
    fi

    show_routing_status
    info "Network interface switching completed successfully"
}

# Execute main function if script is run directly
if [[ "${BASH_SOURCE[0]}" == "${0}" ]]; then
    main "$@"
fi

Also make sure it’s executable:

sudo chmod u+x /etc/keepalived/failover.sh

And that’s it — you’ve got a basic automated failover system ready to step in whenever your internet tries to betray you. Make sure to change variables at the top of the script according to your situation.

The Finale: Spreading the Internet Love

Now that our failover setup is up and running like a responsible adult, I figured — why keep all this internet awesomeness to just one machine?
Let’s share it with the rest of the devices in the house!
(You're welcome, future smart bulbs, fridges, and random IoT doodads.)

This final part is where we build a virtual network that bridges a physical LAN port on my Ubuntu machine, so I can hook it up to a second router and spread that sweet, sweet internet.

Step 1: Time to mess with netplan

Ubuntu uses netplan for its network configs — basically just YAML files with feelings.
Let’s create our virtual bridge network.

Fire up your editor:

sudo nano /etc/netplan/01-bridge.yaml

And paste in:

network:
  version: 2
  ethernets:
    eno0:
      dhcp4: false
    wlp3s0:
      dhcp4: true
    usbnet0:
      dhcp4: true
  bridges:
    vmbr0:
      addresses:
      - "10.10.2.1/24"
      dhcp4: false
      interfaces:
      - eno0
      parameters:
        forward-delay: "0"
        stp: false

After that:

sudo netplan apply

Step 2: What this actually does

• Creates a bridge called vmbr0 using the subnet 10.10.2.0/24

• Bridges it to eno0 — that’s my physical LAN port

• No DHCP server is running on my Ubuntu machine — we’re keeping it simple (and very manual)

Step 3: Connecting devices

Since there’s no DHCP, any device you connect to eno0 will need to be set up with a static IP. For example:

• IP: 10.10.2.2

• Subnet mask: 255.255.255.0

• Gateway: 10.10.2.1 (your Ubuntu machine)

And that’s it — your Ubuntu box is now basically moonlighting as a mini-router for your whole house (or lab, or dungeon — I’m not judging).

Step 1: Configure WiFi Credentials

First things first—let's get that server connected to WiFi. Use the following magical incantation:

wpa_passphrase SSIDNAME PASSWORD >> /etc/wpa_supplicant/wpa_supplicant.conf

Replace SSIDNAME and PASSWORD with your network's details. Then, edit the resulting file at /etc/wpa_supplicant/wpa_supplicant.conf to look something like this:

ctrl_interface=/run/wpa_supplicant
update_config=1
country=IN

network={
        ssid="SSID_NAME"
        #psk="asdflasf"
        psk=89d64643245wsfdfg237ed3ec3ef31c47e75430f0asdfji40598
        proto=WPA RSN
        key_mgmt=WPA-PSK
}

Pro tip: That #psk="your_password_in_plain_text" line is commented out for a reason. Don't let your server broadcast your WiFi password to the world!

Step 2: Configure Network Interfaces

Next up, let’s tackle the network interfaces. Open your favorite text editor (or nano, if you must) and edit /etc/network/interfaces like so:

auto lo
iface lo inet loopback

# Wifi interface autoconnect using wpa_supplicant.conf
auto wlp3s0
iface wlp3s0 inet dhcp
        wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf

# Virtual bridge network
auto vmbr0
iface vmbr0 inet static
        address 10.1.1.1/24
        bridge-ports none
        bridge-stp off
        bridge-fd 0

        post-up echo 1 > /proc/sys/net/ipv4/ip_forward
        post-up iptables -t nat -A POSTROUTING -s '10.1.1.0/24' -o wlp3s0 -j MASQUERADE
        post-down iptables -t nat -D POSTROUTING -s '10.1.1.0/24' -o wlp3s0 -j MASQUERADE
        post-up iptables -t raw -I PREROUTING -i fwbr+ -j CT --zone 1
        post-down iptables -t raw -D PREROUTING -i fwbr+ -j CT --zone 1

source /etc/network/interfaces.d/*

Heads up: Your WiFi interface might not be called wlp3s0. Use the ip a command to find out what it’s really called. Also, if you want to use a different subnet, replace 10.1.1.0/24 with your preferred network range.

If you’re feeling fancy, you can even change your MAC address with the following configuration:

iface wlp3s0 inet static
        address 192.168.1.2
        netmask 255.255.255.0
        gateway 192.168.1.1
        dns-nameservers 1.1.1.1 1.0.0.1
        hardware ether 06:61:D1:65:61:64
        wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf

When you’re done, restart the networking service to apply your changes:

systemctl restart networking

Step 3: Install and Configure dnsmasq

Now, let’s set up a DHCP server to dish out IP addresses to your VMs connected to vmbr0. Start by installing dnsmasq:

apt install dnsmasq

Then, edit its configuration file /etc/dnsmasq.conf with the following lines:

# Set the interface where you want DHCP server to assign IP
interface=vmbr0

# DHCP address range
dhcp-range=10.1.1.1,10.1.1.255,255.255.255.0,12h

Restart dnsmasq to apply the changes:

systemctl restart dnsmasq

Conclusion

Congratulations, you’ve successfully turned a dusty old laptop with a broken Ethernet port into a WiFi-powered homelab server!

Bonus: Configure Lid Configuration

If you’re also using a laptop for this, you might want to keep it going even if the lid closes! Edit the /etc/systemd/logind.conf file to make sure it stays alive even when you close the lid:

HandleSuspendKey=ignore
HandleSuspendKeyLongPress=ignore

HandleLidSwitch=ignore
HandleLidSwitchExternalPower=ignore
HandleLidSwitchDocked=ignore

LidSwitchIgnoreInhibited=no

After updating the above file with the values provided restart `logind`:

systemctl restart systemd-logind

One More Thing!

With this setup, your virtual machines have full access to your router’s network. However, devices directly connected to the router won’t know how to reach the network you just defined. To fix this, you’ll need to create a route entry in your router’s or device’s routing table.

Since router interfaces vary wildly, here’s how you can do it on a Mac:

sudo route -n add 10.1.1.0/24 192.168.1.2

Just replace 10.1.1.0/24 with your subnet and 192.168.1.2 with your homelab server’s IP address. In case you want to remove it use:

sudo route -n delete 10.1.1.0/24 192.168.1.2

The Goal: Set up a Kubernetes Cluster with Nginx Ingress

Here's where things got interesting. After setting up my cluster, I hit a snag: I couldn't get a public IP assigned to my Nginx ingress. All I got was a private IP, which wasn't very useful for my needs.

After some extensive searching (and maybe a few sighs of frustration), I finally found the solution in the Nginx documentation (https://kubernetes.github.io/ingress-nginx/deploy/). What a relief!

Before We Start...

Let's make sure we're on the same page. This guide assumes you've already configured your K8s cluster on kubectl. If you haven't, no problem! Just use az login to access your Azure account and use the connect command from your Azure AKS cluster. It's pretty straightforward.

The Key Command

Here's the command that'll set up your Nginx ingress controller:

kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.11.1/deploy/static/provider/cloud/deploy.yaml

Found this gem after going throught the documentation (maybe we should read it sometime) https://kubernetes.github.io/ingress-nginx/deploy/#azure.

Create a certificate Secret

Now, let's tackle the next exciting step in our K8s journey: creating a certificate Secret! 🔐.

You'll need to whip up a certificate for your domain. You've got two options here:

1. Snag a free certificate from Let's Encrypt

2. Purchase one from a certificate authority (fancy, I know!)

Once you've got your hands on that shiny certificate and key, Run this command:

kubectl create secret tls tls-conf --cert /path/to/fullchain.pem --key /path/to/privkey.pem --namespace your-namespace

Don't forget to swap out the path and namespace with your actual values. This command creates a secret object of type kubernetes.io/tls.

Time to create a Ingress

Next up, we're creating an Ingress for your service. Think of it as the bouncer that decides who gets into your Kubernetes club.

Create a file called ingress.yaml and fill it with this yaml goodness:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ingress-name
  namespace: your-namespace
  annotations:
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
spec:
  tls:
    - hosts:
        - your-domain.something
      secretName: tls-conf
  rules:
    - host: your-domain.something
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: your-service
                port:
                  number: your-service-port
  ingressClassName: nginx

Now, before you apply this yaml, make sure to replace your-namespace, your-domain.something, your-service, and your-service-port with your actual values.

Once you've customized your yaml, apply it using kubectl. Voila! You've just set up an Ingress for your service using the following command.

kubectl apply -f /path/to/ingress.yaml

Replace the /path/to/ingress.yaml with wherever you saved your ingress.yaml.

And that's it you should have your nginx ingress up and running with a public IP assigned to it.

Bonus Round: Customizing Your Nginx Config 🛠️

What if you want to tweak some Nginx settings? Maybe you're looking to adjust the client_max_body_size or other fancy parameters? Well, you're in luck!

1. Head over to the config objects in your Kubernetes dashboard.

2. Filter by the ingress-nginx namespace.

3. find and edit th ingress-nginx-controller

4. Once you're happy with your edits, apply them. A complete list of available configuration options can be found at: https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/configmap/.

Step 1: Create a New App

First, create your new app in Dokku with the following command:

dokku apps:create qbittorrent

Feel free to replace qbittorrent with your preferred app name.

Step 2: Mount a Directory for qBittorrent Configuration

Next, mount a directory for qBittorrent's configuration:

dokku storage:mount qbittorrent /home/dokku/qbittorrent/data:/config

Step 3: Create a Docker Volume

Now, let's create a volume. Run the following command, replacing the placeholders with your specific values:

docker volume create --driver local --opt type=cifs --opt device=//<nas_url_here>/<nas_path> --opt o=username=<your_username>,password=<your_password>,port=<your_port>,uid=1000,gid=1000,forceuid <name_of_the_volume>

Replace <nas_url_here>, <nas_path>, <your_username>, <your_password>, <your_port>, and <name_of_the_volume> with your actual NAS details and desired volume name.

Step 4: Mount the Volume

Mount the newly created volume:

dokku storage:mount qbittorrent <name_of_the_volume>:/downloads

Ensure you replace <name_of_the_volume> with the volume name you used earlier.

Step 5: Set Environment Variables

Configure the environment variables for your app:

dokku config:set qbittorrent PGID=1000 PUID=1000 TZ=Asia/Kolkata WEBUI_PORT=8080

Step 6: Deploy the Docker Image

Initiate the deployment using the docker image:

dokku git:from-image qbittorrent linuxserver/qbittorrent:4.6.0

Step 7: Configure Ports

Set up the port configuration to make your app accessible via Dokku's proxy server:

dokku ports:set qbittorrent http:80:8080

Step 8: Set a Domain

Finally, set a domain for your app:

dokku domains:add qbittorrent <your_domain_here>

Replace <your_domain_here> with your actual domain.

And that's it! Your qBittorrent app should now be up and running on Dokku. Happy torrenting!

What if I told you there is a way to do this with tools you're already using?

Yeah, you read that right, you can bring your application online using SSH.

Why go through the effort when there are free third-party services like ngrok?

The problem with ngrok or any third-party services is that they don't provide a dedicated domain, meaning every time you restart your ngrok client it will give you a different domain and you'll have to change the configuration all over again, in all fairness you could buy a paid plan to have a custom domain setup as well but let's try it my way.

Before we begin, as the title suggests this is not entirely free. I know I said free and it is to some extent, but it is only free if you're already having a domain and a server. A domain may not be a fancy one but can be acquired for free from Freenom. And there are free tiers available from different cloud providers.

Setting up Nginx for reverse proxy

Once you have got a server up and running in the cloud, ssh into the server and install Nginx.

sudo apt install nginx

After the successful installation head into the /etc/nginx/sites-avaialble directory and create a new server configuration using sudo touch tunnel.conf then add the following configuration.

server {
    listen 80;
    listen [::]:80;

    server_name tunnel.yourdomain.com;

    location / {
      proxy_pass http://localhost:8080/;
      proxy_set_header Accept-Encoding gzip;
    }
}

replace tunnel.yourdomain.com with your domain. Also, add A record that points to your server IP for the same.

You can also use Certbot to get an SSL certificate for your domain.

Configure SSH client to port forward

Now that nginx is listening on the server, every time you want to bring your application online just run the following command and access it from your specified domain.

ssh -R remote_port:host:host_port -i ~/.ssh/private_key user@yourserver.com

change the remote_port to 8080, host to localhost & host_port to whatever your application is listening on.

Also, your ssh connection may get disconnected if there is no activity in a while, to keep the connection alive add ServerAliveInterval 60 at the end of ~/.ssh/config file.

Installing Fastlane

First, we will install the Fastlane tool on our local machine. Use homebrew to install it on a mac

brew install fastlane

on a Linux or Windows machine, we'll use ruby's gem package manager to install Fastlane.

gem install fastlane

Setting up app signing

Go to android/app/build.gradle file and define add the following lines:

...
// Add these lines
def keystoreProperties = new Properties()
def keystorePropertiesFile = rootProject.file('key.properties')
if (keystorePropertiesFile.exists()) {
    keystoreProperties.load(new FileInputStream(keystorePropertiesFile))
}

// ^ Above this
apply plugin: 'com.android.application'
apply plugin: 'com.google.gms.google-services'

...

 defaultConfig {
    ...

    // Add this as well
    signingConfigs {
        release {
            keyAlias keystoreProperties['keyAlias']
            keyPassword keystoreProperties['keyPassword']
            storeFile keystoreProperties['storeFile'] ? file(keystoreProperties['storeFile']) : null
            storePassword keystoreProperties['storePassword']
        }
    }

    buildTypes {
        release {
            // TODO: Add your own signing config for the release build.
            // Signing with the debug keys for now, so `flutter run --release` works.
            signingConfig signingConfigs.release
        }

    }

...

You also need to create a new file under the android folder called key.properties, and add the following configurations:

storePassword=store-password
keyPassword=key-password
keyAlias=key-alias
storeFile=path-to-jks

make sure to change these with your Keystore configuration. Run the flutter build appbundle command to build a signed app bundle.

Creating the service account

To upload the app bundle on the play console we need a service account that will have the required permissions to perform actions on our behalf. Before doing this make sure you have already registered an app on the play console with the correct package name.

• Head over to Play Console.
• On the left sidebar under Setup, you'll see API Access.
• Scroll Down until you see the Service Accounts section.
• Click on Learn how to create service accounts.
• On the popup that shows up click on the link that says Google Cloud Platform
• Once you're in the google cloud console, click on Create service account
• This will ask you a couple of questions, just fill those in and create a new service account.
• Once a new service account is created click on the three dots for the context menu and then Manage Keys
• Now you need to create a JSON key for this service account.
• Once all that is done return back to the play console and click on the Done button in the Dialog Box.
• You should see the service account listed on the play console. Click on the View Play Console Permissions.
• Under app permission, you need to give admin access to this account for the app you want it to manage.

Setting up Fastlane for the project

Now that app signing is set up you need to configure Fastlane for the android project. Make sure you are in the android folder and run the following command:

fastlane init

Fastlane will ask you a couple of questions, like what's the package name for your app and path to the json secret (this is the file that we downloaded from the last step).

This will create a new folder called fastlane, which will contain two files Appfile and Fastfile. Make sure the package name and path to JSON secret are correct in the Appfile.

Open the Fastfile and replace it with the following lines:

# This file contains the fastlane.tools configuration
# You can find the documentation at https://docs.fastlane.tools
#
# For a list of all available actions, check out
#
#     https://docs.fastlane.tools/actions
#
# For a list of all available plugins, check out
#
#     https://docs.fastlane.tools/plugins/available-plugins
#

# Uncomment the line if you want fastlane to automatically update itself
# update_fastlane

default_platform(:android)

platform :android do
  desc "Submit a new Google Play [Beta Testing]"
  lane :beta do
    upload_to_play_store(
      track: 'internal',
      release_status: 'draft',
      aab: '../build/app/outputs/bundle/release/app-release.aab'
    )

    # sh "your_script.sh"
    # You can also use other beta testing services here
  end

  desc "Deploy a new version to the Google Play [Production]"
  lane :deploy do
    upload_to_play_store(track: 'production', aab: '../build/app/outputs/bundle/release/app-release.aab')
  end
end

Now you've created two lanes one that will push the build to the internal testing beta track and another one deploy to production.

Run the fastlane supply init to fetch information from the play console about the app (like screenshots, app descriptions, etc).

You can test if your setup works by running:

fastlane beta

Setting up Github Action

Now that we know our configuration works locally, let's set up a GitHub action that will create a beta release every time we push our app into the development branch.

First, we need to add some repository secrets by going to Repository Settings > Secrets >> Actions and add the following variables:

• PLAY_STORE_UPLOAD_KEY this is the base64 encoded Keystore file (.jks)
• KEYSTORE_KEY_ALIAS this is the upload Keystore key alias
• KEYSTORE_KEY_PASSWORD this is our upload key password
• KEYSTORE_STORE_PASSWORD this is our store password
• PLAY_STORE_CONFIG_JSON this is the google service account's config file

use the cat keystore.jks | base64 | pbcopy to copy the base64 version of jks file to the clipboard.

name: Deploy Beta build to Play Store

on:
  push:
    branches:
      - development

# Declare default permissions as read only.
permissions: read-all

jobs:
  fastlane-deploy:
    runs-on: ubuntu-20.04
    steps:
      # Set up Flutter.
      - name: Checkout App Repo
        uses: actions/checkout@v3
        with:
          ref: 'development'

      - name: Setup Java
        uses: actions/setup-java@v1
        with:
          java-version: '12.x'

      - name: Configure Keystore
        run: |
          echo "$PLAY_STORE_UPLOAD_KEY" | base64 --decode > /home/runner/work/repo-name/repo-name/upload-keystore.jks
          echo "storeFile=/home/runner/work/repo-name/repo-name/upload-keystore.jks" >> key.properties
          echo "keyAlias=$KEYSTORE_KEY_ALIAS" >> key.properties
          echo "storePassword=$KEYSTORE_STORE_PASSWORD" >> key.properties
          echo "keyPassword=$KEYSTORE_KEY_PASSWORD" >> key.properties
          echo "$KEYSTORE_KEY_ALIAS"
          echo "$PLAY_STORE_CONFIG_JSON" > /home/runner/work/repo-name/repo-name/service_key.json
          echo "json_key_file(\"/home/runner/work/repo-name/repo-name/service_key.json\")" > /home/runner/work/repo-name/repo-name/android/fastlane/Appfile
          echo "package_name(\"package-name\")" >> /home/runner/work/repo-name/repo-name/android/fastlane/Appfile
          cat /home/runner/work/repo-name/repo-name/android/fastlane/Appfile
        env:
          PLAY_STORE_UPLOAD_KEY: ${{ secrets.PLAY_STORE_UPLOAD_KEY }}
          KEYSTORE_KEY_ALIAS: ${{ secrets.KEYSTORE_KEY_ALIAS }}
          KEYSTORE_KEY_PASSWORD: ${{ secrets.KEYSTORE_KEY_PASSWORD }}
          KEYSTORE_STORE_PASSWORD: ${{ secrets.KEYSTORE_STORE_PASSWORD }}
          PLAY_STORE_CONFIG_JSON: ${{ secrets.PLAY_STORE_CONFIG_JSON }}
        working-directory: android

      - name: Install Flutter & Build App Bundle
        uses: subosito/flutter-action@v2
        with:
          flutter-version: '3.x'
          channel: 'stable'
      - run: flutter --version && flutter pub get && flutter build appbundle --release

      - name: Setup Ruby
        uses: ruby/setup-ruby@v1
        with:
          ruby-version: '2.7.2'

      - name: Fastlane Action
        uses: maierj/fastlane-action@v2.2.1
        with:
          lane: "beta"
          subdirectory: "android"

make sure to replace the repo-name and package-name in the Configure Keystore step.

That's all, everytime you push to the development branch a new draft release will be automatically created in the play console.

Meet Arrays and Slices.

Array

An array is also like a variable it has an identifier and a data type. But unlike a variable we can store data many different predefined numbers of elements.

Let's say for 100 users, we create an array:

var users = [100]string{}   // an empty string array of 100 elements

When creating an array we need to know its size beforehand (how many elements it can hold).

First, we're defining a variable users which holds the memory address for the array, after the = sign we're defining the size of the array and then the type of data this array will hold, and finally the {} is the initial value of the array, which is currently empty.

You can also add initial values by providing them in the {} separated by a comma.

var users = [100]string{"Vivek", "Harsh", "Kartik"}   // an string array with 3 initial value

How about accessing and storing the data?

var users = [50]string{"Vivek", "Harsh", "Kartik"}

users[3] = "Sachin" // storing the user at 3rd index

fmt.Println(users[0]) // this will print "Vivek"
fmt.Println(users[1]) // this will print "Harsh"

users[0] = "Vivek Kaushik" // Reassign the value at index 0
fmt.Println(users[1]) // Will print "Vivek Kaushik"

fmt.Printf("length of the array: %v\n", len(users))  // Will print "length of the array: 100"

Arrays have something called as Index. Think of the array as a box with compartments, and each compartment has a number assigned to it (index). The number starts from 0 to the length of the array minus 1. So for our previous user example, we will have index from 0 to 99. We can use these indexes to access, assign or reassign values.

If we try to access a value from an index that is out of range, from our previous example fmt.Println(users[100]) this will give us an Index out of bound error as we only had index up to 99.

Note: len() is another function, that gives us the size of the array.

Slices

Arrays are great but they are not always useful, as most of the time we do not know how many elements we will be adding. This is where Slices comes in.

For slices we don't have to define size, they are dynamic and can grow and shrink as needed.

var users = []string{} // empty slice of 0 length

fmt.Printf("length of the slice: %v\n", len(users))  // Will print "length of the slice: 0"

users = append(users, "Vivek")

fmt.Printf("length of the slice: %v\n", len(users))  // Will print "length of the slice: 1"

fmt.Println(users[0]) // this will print "Vivek"

First, we initialize an empty slice which is very similar to an array except we don't specify the size of it. Next we print the size of our newly defined slice using the len function which gives us zero. Then we use another function called append which takes our slice and a value and appends it to the end of slice. After using the len function again we see that the size is now 1. Finally we print the value at index 0.

We can define a variable using the var keyword followed by the variable name and then its data type (what type value it is expected to store). Here are some examples:

var name string = "Go Language"
var number int = 23
var isTrue bool = true

fmt.Println(name)
fmt.Println(int)
fmt.Println(isTrue)

Using just var name string and not setting it to any value, it is called variable definition, we are defining what a variable's name is and what kind of data it can store and if it can be reassigned (set to a new value) or not.

When we assign a value to a variable for the first time it is called variable initialization.

Constants are defined the same way as variables instead of using var we use const.

const name = "Vivek"
name = "Harsh" // Error: cannot assign to name

Data Types

Go is statically typed, meaning, we need to tell the compiler about what type of data we are expecting.

We have multiple data types for different purposes. Here are some of them:

• String
• Integer
• Float
• Boolean
• Array
• Map

String

For textual data, we use the string type. We've been using the string data type from the start.

Anything within a double quote is considered a string. Here's an example:

var text string = "Hello"

Integers

Integer represents whole numbers positive or negative, like 5, -5, 0.

var positiveInt int = 5
var negativeInt int = -5
var zero int = 0

Signed integers, declared with int can store both positive and negative whole numbers. But there is a limit to how big of a number they can store.

Note: There are also Unsigned types for integers.

Unsigned Integers

Unsigned integers are declared with the uint keyword, these can only store positive whole numbers (yes this includes zero).

Here are the different variations of uint and their limitations:

Float

The float data types can store positive or negative decimal numbers:

Here is an example of how we can use floats:

package main
import ("fmt")

func main() {
    var x float64 = 234.43
    var y float32 = 3.4e+38
    fmt.Printf("Type: %T, value: %v\n", x, x)
    fmt.Printf("Type: %T, value: %v", y, y)
}

fmt.Printf("text") is another method from the "fmt" package it is used to format an insert text at some predefined placeholders. You can learn more about fmt here.

Boolean

A variable with bool data type can store either true or false. the default value for a bool variable is false.

var isTrue bool = true
var isFalse bool = false
var defaultValue bool

fmt.Println("isTrue:", isTrue)
fmt.Println("isFalse:", isFalse)
fmt.Println("defaultValue:", defaultValue)

Note: We'll talk about the arrays and maps separately.

Now that that's out of the way, go ahead and create a directory called my_project, Inside the directory you need a go.mod at the root of the project, this file that keeps track of the modules that provide those package (this of it as package.json file if you're coming from Java Script). You can create the go.mod file using go mod init module_name command, you can use your own module name, typical practice is to use your version control repo path for ex github.com/iamvivekkaushik/my_project. That is if you want to publish your module for others, the module path must be a location from which Go tools can download your module.

Now create a main.go file that will contain our go code and paste the following code.

package main

import "fmt"

func main() {
    fmt.Println("Hello, World!")
}

To run your program use:

$ go run main.app
Hello World!

When developing an executable program, we use the package main. The package “main” tells the Go compiler that the package should compile as an executable program instead of a shared library.

We will separate our source code into separate packages, this is to enable re-usablity of the code. The naming convention for Go package is to use the name of the system directory where we're putting the source file, the package will be same for each file within a directory.

After defining the package we use the import statement to import a package called fmt, probably short for formatter. The package fmt comes from the Go standard library. When we import packages, the Go compiler will look on the locations specified by the environment variable GOROOT and GOPATH.

Then we define a main function using the func keyword and use the "fmt" to print the "Hello World!" text.

If you're coming from JS you might be wondering I never called the main function (we will learn about functions in the coming posts) how is it running. So the main function is actually automatically called when you run the program, this is called the entrypoint of your project. You must have a main function defined in your main package.

Here are some commands to help you get started.

To add missing module requirements or remove unneeded requirements, use:

go mod tidy

To add a third party package:

go get <module_url>

First of all, you'll need to update your sources using

user@ubuntu:~$ sudo apt update

Once that's done go ahead and use the apt package manager to install postgrsql:

user@ubuntu:~$ sudo apt install postgresql postgresql-contrib

The above command will install the PostgreSQL database on your system. By default Postgres automatically creates a user with the name of postgres, this user has full superuser access.

To access the psql interface (psql is a command-line based front-end for Postgres you can use psql to interface with Postgres) use the command below:

user@ubuntu:~$ sudo -u postgres psql

or you can use the postgres user that was created by Postgres upon installation and use the psql command from there.

user@ubuntu:~$ su postgres
postgres@ubuntu:~$ psql

Notice how the first command su postgres changed the user to postgres. Once you run the psql command an interface similar to the one below will show up, this is where you can run SQL and Postgres specific queries.

psql (12.9 (Ubuntu 12.9-0ubuntu0.20.04.1))
Type "help" for help.

postgres=#

Creating a new database

You can use the command shown below to create a user first:

postgres=# CREATE USER '<username>' WITH ENCRYPTED PASSWORD '<new-password>';

The above command will create a new user with a username and a password, make sure to change those to whatever you prefer (don't use <>).

Once the user is created, we'll need to create a database.

postgres=# CREATE DATABASE '<db-name>';

The above command will create a new database (Make sure to change the <db-name>). Now we need to grant access to this database to the user we created in the previous step.

postgres=# GRANT ALL PRIVILEGES ON DATABASE '<db-name>' TO '<username>';

Now that our database is created and a user has access to that database the basic step is done. But if you want your database to be accessible everywhere or only to a specific IP, keep reading.

Modifying connections to the database

Now that you have your database up and running you might want to modify who can have access to it. You can either allow everyone (which is not a good idea) or a specific set of IPs (using CIDR).

To achieve this we will need to edit the Postgres config which can be found in /etc/postgresql/12/main/ path may vary based on Postgres version.

user@ubuntu:~$ cd /etc/postgresql/12/main/
user@ubuntu:~$ ls
conf.d  environment  pg_ctl.conf  pg_hba.conf  pg_ident.conf  postgresql.conf start.conf

As you can see there are many available files here, but the ones we are interested in are postgresql.conf and pg_hba.conf. Use the nano text editor to edit the postgresql.conf file.

user@ubuntu:~$ sudo nano postgresql.conf

You'll have to scroll down a bit until you see a section called CONNECTIONS AND AUTHENTICATION it will look something like this:

#------------------------------------------------------------------------------
# CONNECTIONS AND AUTHENTICATION
#------------------------------------------------------------------------------
# - Connection Settings -
listen_addresses = 'localhost,192.168.0.3'         # what IP address(es) to listen on;

You'll need to assign the list of IPs that you want to have access to Postgres to listen_addresses. Alternatively, you can set listen_addresses equal to '*' which will mean that anyone on the internet can have access to our database (Bad idea).

Now save this file by pressing ctrl+x and tying Y and accepting the provided name.

Finally, we'll need to edit the pg_hba.conf file. This file controls the client authentication. We'll add our database and user and what IP can authenticate with them. Previously what we did was, we specified who can make a connection to the database.

Open the pg_hba.conf file using nano:

user@ubuntu:~$ sudo nano pg_hba.conf

At the bottom of the file specify your user and database and what IPs are allowed to authenticate.

host    username     db-name     192.168.0.0/24        md5

Make sure to change the username and db-name with the one you created and the IP address to the IP of your computer that you'll use to authenticate.

Finally, save the file using ctrl+x then Y and accept the provided file name.

You can use telnet command to check if you can make a connection to the db:

user@ubuntu:~$ telnet 192.168.0.2 5241

Change the IP with the Postgres server IP. 5241 is the default port for postgres.

And that's it. Thanks for reading.

Well turns you need to set up GPG keys for your machines in order to have that luxury. In fact, there is an official guide from Github telling users how to set up these keys. Honestly, that's the one I used when I was trying to figure out how this all works. If you're interested you can check the official guide here.

Creating a new GPG key

First, you need to install the GnuPG Binary for your operating system. You can download the same from here.

Now that you've installed the binary, go ahead and open up a terminal.

Use the command below to generate the GPG key

gpg --full-generate-key

First Enter your Full Name.

If prompted, specify the kind of key you want, or press Enter to accept the default RSA and RSA.

Next if asked you need to set the maximum recommended key size to 4096.

Next, enter the expiry date for key expiry.

Enter your user ID information.

Make sure that you enter the verified email address for your GitHub account when entering the email. To keep your email address private, use your GitHub-provided no-reply email address. For more information, see "Verifying your email address" and "Setting your commit email address".

Last, type a secure passphrase.

Use the gpg --list-secret-keys --keyid-format LONG command to list GPG keys for which you have both a public and private key. A private key is required for signing commits or tags.

From the list of GPG keys, copy the GPG key ID you'd like to use. In this example, the GPG key ID is 3AA5C34371567BD2:

$ gpg --list-secret-keys --keyid-format LONG
/Users/hubot/.gnupg/secring.gpg
------------------------------------
sec   4096R/3AA5C34371567BD2 2016-03-10 [expires: 2017-03-10]
      57D3288AAF1EC3AA5C34371567A243S0946AA2
uid                 Vivek Kaushik <your_email@gmail.com> 
ssb   4096R/42B317FD4BA89E7A 2016-03-10

Use the command below, substituting in the GPG key ID you'd like to use. In this example, the GPG key ID is 3AA5C34371567BD2:

$ gpg --armor --export 3AA5C34371567BD2
# Prints the GPG key ID, in ASCII armor format

Copy your GPG key, beginning with -----BEGIN PGP PUBLIC KEY BLOCK----- and ending with -----END PGP PUBLIC KEY BLOCK-----.

Adding a new GPG key to your GitHub account

In the upper-right corner of any page, click your profile photo, then click Settings.

In the user settings sidebar, click SSH and GPG keys.

Click New GPG key.

In the "Key" field, paste the GPG key you copied when you generated your GPG key and then click on Add GPG key.

Telling Git about your signing key

Use the gpg --list-secret-keys --keyid-format LONG command to list GPG keys for which you have both a public and private key. A private key is required for signing commits or tags.

$ gpg --list-secret-keys --keyid-format LONG
/Users/hubot/.gnupg/secring.gpg
------------------------------------
sec   4096R/3AA5C34371567BD2 2016-03-10 [expires: 2017-03-10]
      57D3288AAF1EC3AA5C34371567AB0020946AA2
uid                 Vivek Kaushik <your_email@gmail.com> 
ssb   4096R/42B317FD4BA89E7A 2016-03-10

To set your GPG signing key in Git, paste the text below, substituting in the GPG key Hash you'd like to use. In this example, the GPG key Hash is 57D3288AAF1EC3AA5C34371567A243S0946AA2:

git config --global user.signingkey 57D3288AAF1EC3AA5C34371567A243S0946AA2

To configure your Git client to sign commits by default, in Git versions 2.0.0 and above, run

git config --global commit.gpgsign true

Now all you need to do is commit and push your code as you regularly do.

In order to disable root login, you must first ensure that there is a normal user account available for you to log in after root login is disabled.

Creating a new user

sudo adduser "username"

Change the username with the desired username for your new user. Also, don't apply quotes. After executing the command you'll be presented with a form asking for the user's information, just enter whatever you want.

Now that the user is created, open the /etc/ssh/sshd_config inside your favourite text editor.

sudo nano /etc/ssh/sshd_config

In this file under Authentication, you'll find PermitRootLogin you need to change it's value to no.

PermitRootLogin no

In case you also want to disable password-based authentication as well, you can also change the PasswordAuthentication to no

PasswordAuthentication no

But make sure you've set up ssh key-based authentication before disabling PasswordAuthentication. I'll link up the article here for setting up ssh-key-based authentication.

Now, you need to restart your SSH service.

sudo service ssh restart