Author: Kerloy

Posted on

Automating Daily Updates on Pop!_OS Using systemd Timer

Keeping your Linux system up-to-date is crucial for stability, performance, and especially security.
But running sudo apt update && sudo apt upgrade manually every morning gets repetitive.

Let’s automate it so your Pop!_OS machine updates itself once per day, only on the first boot of the day — not on every restart.

🧠 Goal

We’ll build a lightweight automation that:

  • Runs system and Flatpak updates automatically once per day
  • Ensures updates happen after the network is online
  • Logs everything to journalctl for easy review
  • Works quietly in the background using systemd timers

🧰 Overview

You’ll create three small components:

  1. A Bash script that performs the updates
  2. A systemd service to define how the script runs
  3. A systemd timer to define when it runs (once per day)

🪄 Step 1 — Create the Update Script

File: /usr/local/sbin/daily-update.sh

sudo tee /usr/local/sbin/daily-update.sh >/dev/null <<'EOF'
#!/usr/bin/env bash
set -euo pipefail

# Log everything to the system journal (view with: journalctl -t daily-update)
exec 1> >(logger -t daily-update) 2>&1

export DEBIAN_FRONTEND=noninteractive

# Skip if APT is already running
if pidof apt apt-get >/dev/null; then
  echo "APT already running, skipping update."
  exit 0
fi

# Refresh package lists
apt-get update

# Upgrade packages safely, keeping existing config files
apt-get -o Dpkg::Options::=--force-confdef \
        -o Dpkg::Options::=--force-confold \
        -y dist-upgrade

# Clean out old dependencies
apt-get -y autoremove

# Update Flatpak apps if installed
flatpak update -y || true
EOF

sudo chmod +x /usr/local/sbin/daily-update.sh

🔍 Explanation

LinePurpose
set -euo pipefailExits on any error, undefined variable, or broken pipe
logger -t daily-updateSends logs to journalctl under the tag daily-update
DEBIAN_FRONTEND=noninteractivePrevents interactive prompts during unattended upgrades
apt-get updateFetches the latest package lists
dist-upgradeInstalls all available upgrades, resolving dependencies
autoremoveCleans unused packages automatically
flatpak updateUpdates any Flatpak apps, if present

Check logs anytime with:

journalctl -t daily-update -n 200 --no-pager

⚙️ Step 2 — Create the systemd Service

File: /etc/systemd/system/daily-update.service

[Unit]
Description=Daily system + Flatpak update
Wants=network-online.target
After=network-online.target

[Service]
Type=oneshot
ExecStart=/usr/local/sbin/daily-update.sh
Nice=10
IOSchedulingClass=best-effort
IOSchedulingPriority=7

🧩 What Each Setting Does

  • Wants=network-online.target
    Ensures network is initialized before running (important for APT).
  • After=network-online.target
    Prevents the update from starting too early at boot.
  • Type=oneshot
    Runs once and exits; not a background service.
  • Nice / IOSchedulingClass / IOSchedulingPriority
    Lowers CPU and disk priority so updates don’t slow your desktop.

⏰ Step 3 — Create the Timer

File: /etc/systemd/system/daily-update.timer

[Unit]
Description=Run daily-update once per day

[Timer]
OnCalendar=daily
RandomizedDelaySec=1h
Persistent=true
Unit=daily-update.service

[Install]
WantedBy=timers.target

🔍 Explanation

SettingMeaning
OnCalendar=dailyRuns once every 24 hours
RandomizedDelaySec=1hAdds a random 0–1 hour delay to avoid network congestion
Persistent=trueRuns automatically after next boot if missed
Unit=Tells the timer which service to trigger

🚀 Step 4 — Enable and Test

Reload and enable the timer:

sudo systemctl daemon-reload
sudo systemctl enable --now daily-update.timer

Check scheduled timers:

systemctl list-timers | grep daily-update

Run manually (for testing):

sudo systemctl start daily-update.service

View logs:

journalctl -t daily-update -n 50 --no-pager

🧯 Common Error: Permission Denied on Lock File

If you see:

could not open lock file /var/lib/apt/lists/lock - open (13: Permission denied)

it means the script wasn’t run as root.
Use:

sudo /usr/local/sbin/daily-update.sh

When triggered by systemd, it runs as root automatically.

🧾 Verify It’s Working

  • Show next scheduled run systemctl list-timers --all | grep daily-update
  • View last run systemctl status daily-update.service
  • Check logs for today journalctl -t daily-update --since today

💬 Final Thoughts

This lightweight automation makes your Pop!_OS machine self-maintaining.
It runs quietly once a day, applies updates, and cleans old packages — all while you focus on your work.

For an optional desktop notification, add this to the end of your script:

notify-send "Daily Update" "System packages and Flatpaks are up to date!"

That’s it — your Pop!_OS now keeps itself secure and current every day ✨

✅ Written and tested on Pop!_OS 22.04 LTS (Ubuntu base). Works on any systemd-based distro: Ubuntu, Debian, Fedora, etc.

Posted on

How HSMs Keep Cryptographic Keys Secure

In today’s digital world, cryptographic keys are the crown jewels of security. They protect financial transactions, secure personal data, and enable trust across the internet. But with so much at stake, how do organizations make sure these keys never fall into the wrong hands?

The answer lies in Hardware Security Modules (HSMs) — tamper-resistant devices purpose-built to generate, protect, and use cryptographic keys.

The Core Principle: Keys Never Leave in Cleartext

Whether it’s a payment HSM used in banking or a general-purpose HSM in cloud and enterprise environments, the rule is the same:

  • Clear-text keys must never leave the secure boundary of the HSM.
  • Any time a key needs to be stored, backed up, or transported, it is always in encrypted (wrapped) form.

This principle ensures that even if the host application or database is compromised, attackers only see encrypted blobs, never the raw cryptographic secrets.

Local Storage: Protecting Keys at Rest

When an HSM generates a new key, the application often needs to store it for later use. But the host system cannot store raw keys. Instead, the HSM:

  • Encrypts (wraps) the key under a local master key that exists only inside the HSM.
  • Returns the encrypted blob to the application for safe storage.
  • Whenever the key is needed, the application sends this blob back into the HSM, which unwraps it internally and performs the cryptographic operation.

👉 The host application never sees the clear key; it simply acts as a database of encrypted blobs.

Remote Sharing: Keys on the Move

Sometimes, keys must be exchanged between systems — for example, between two banks, or between a data center and its disaster recovery site. For this, HSMs use a Key Exchange Key (KEK):

  • The sending HSM encrypts the key under the KEK.
  • The receiving HSM (which also holds the KEK) unwraps it inside its secure boundary.
  • The key is then re-wrapped under the local master key of the new system for ongoing use.

This model enables secure key exchange without ever exposing the clear key outside an HSM.

Specialization in Payment HSMs

In the payments industry, this dual-form approach is formalized:

  • Local form → Key wrapped under a local master key for storage by the host.
  • Exchange form → Key wrapped under a KEK for transport to another HSM.

Payment HSMs use these wrapped keys to power critical operations like:

  • Encrypting and translating PINs
  • Generating and verifying MACs
  • Protecting sensitive cardholder data
  • Validating CVVs and other card security values

This strict handling process aligns with PCI PIN Security and PCI DSS requirements, ensuring global consistency in how financial institutions secure cryptographic material.

General-Purpose HSMs: Same Rule, Different Wrapping

Outside of payments, general-purpose HSMs (used in PKI, TLS/SSL offload, or cloud KMS platforms) follow the same principle, though with different standards:

  • Keys may be wrapped using Key Wrapping Keys (KWKs) or Key Encryption Keys (KEKs).
  • Standard protocols like PKCS#11 or KMIP define how wrapped keys are exchanged.
  • In cloud, workflows like Bring Your Own Key (BYOK) rely on the same idea — you encrypt your key under the provider’s KEK before import.

The details vary, but the philosophy is identical: keys at rest and keys in transit are always encrypted.

The Golden Rule

No matter the use case — payments, cloud, or enterprise security — the golden rule holds:

  • The host only ever manages encrypted blobs.
  • The HSM is the only place keys exist in the clear.

By enforcing this separation, HSMs remain the trusted foundation for securing the world’s most sensitive digital secrets.

Posted on

What is Cloud Native? And Why It Matters to the Modern CISO

As organizations race to innovate, the term “cloud native” is no longer a buzzword—it’s a strategic shift in how applications are designed, deployed, and secured. But what does “cloud native” actually mean, and why should it matter to CISOs leading the security function in tech-forward enterprises?

🌐 What is Cloud Native?

Cloud native is an approach to software development that takes full advantage of modern cloud computing platforms. Rather than simply moving legacy systems to the cloud, cloud native applications are designed from the ground up to thrive in dynamic, distributed environments.

🔧 Key Characteristics of Cloud Native Applications

  • Microservices-based: Applications are broken into small, independent services that communicate over APIs.
  • Containerized: Each service is packaged with its own dependencies, commonly using Docker or container technologies.
  • Orchestrated: Tools like Kubernetes handle deployment, scaling, and management of containers.
  • Resilient: Designed to recover from failure quickly with automated failovers and health checks.
  • Scalable: Can dynamically adjust resources to meet changing demand.
  • Continuous delivery: Enables rapid deployment and rollback through DevOps and CI/CD pipelines.
  • Observable: Built-in monitoring, logging, and metrics for real-time visibility.

🔐 Why Cloud Native is a Game Changer for CISOs

As the cloud native landscape evolves, so too does the role of the Chief Information Security Officer (CISO). The transition to distributed, ephemeral, and API-driven architectures poses both challenges and opportunities for security leadership.

📌 1. The Ecosystem is Rapidly Expanding

  • The cloud native ecosystem includes a growing array of tools, technologies, and standards (e.g., Istio, Envoy, Helm, etc.).
  • CISOs must stay current on these developments to accurately assess risk and influence secure design choices.

📌 2. The Architecture is More Complex

  • Security is no longer confined to a perimeter.
  • Applications are distributed across containers, pods, and clusters—requiring zero-trust, service mesh, and workload identity strategies.

📌 3. Security Must Shift Left

  • DevOps and agile models demand integrated security.
  • CISOs need to promote DevSecOps by embedding controls into the software development lifecycle.

📌 4. The CISO’s Role is Becoming More Strategic

  • Beyond protection, CISOs now need to illuminate business value from secure, compliant, and resilient cloud native adoption.
  • They are key advisors in balancing speed, agility, and security in the boardroom.

✅ Summary: What Should CISOs Focus On?

Area Cloud Native Focus
Architecture Microservices, containers, APIs, service mesh
Threat Surface Distributed workloads, CI/CD, ephemeral environments
Security Approach Zero trust, policy as code, workload identity
Operational Model Continuous monitoring, automated controls
Leadership Role Business alignment, governance, developer engagement

🚀 Conclusion

Cloud native isn’t just a technology shift—it’s a cultural and operational transformation. For CISOs, this change demands a redefined playbook—one that embraces automation, developer collaboration, and proactive governance.

Security must now move at the speed of innovation—and cloud native gives us the tools to do just that.

Posted on

Security Assessments vs. Security Audits: What’s the Difference and Why Both Matter

When it comes to securing modern software—especially open source—two terms often come up: security assessments and security audits.

At first glance, they sound similar. But in reality, they focus on very different layers of security and serve complementary roles. Understanding the difference is key for developers, maintainers, and tech leaders who want to build or adopt secure systems.

✅ What is a Security Audit?

Think of a security audit as a microscope: it zooms in on the actual code, deployment setup, and environment.

🔎 Key Features:

  • Focuses on implementation-level flaws
  • Identifies bugs, vulnerabilities, and config mistakes
  • Reviews current versions or specific code releases
  • May use automated tools (static analysis, dynamic analysis)
  • Often provides proof-of-concept exploits

🧠 Example:

Imagine someone tries to break into a physical bank. They:

  • Pick the vault lock
  • Exploit weak doors or cameras
  • Monitor guard schedules to sneak in

That’s what an audit does for your software—it actively tries to exploit specific weaknesses.

⚙️ When to Use:

  • Before releasing a major version
  • When integrating new dependencies
  • After a suspected compromise

✅ What is a Security Assessment?

In contrast, a security assessment acts like a strategic blueprint review. It looks at how the system is designed, how people and processes interact, and whether the project is likely to stay secure over time.

📐 Key Features:

  • Focuses on architecture, design, and processes
  • Evaluates if the project is following secure development practices
  • Reviews people, policies, and procedures
  • Long-lasting value—useful across versions and implementations
  • Highlights systemic risks, not just current bugs

🧠 Example:

Returning to the bank analogy: a security assessment looks at the bank’s blueprints, employee vetting, vault design, and response plans. Even if nobody is trying to rob the bank now, this review ensures it is resilient by design.

🧰 When to Use:

  • When evaluating whether to adopt or rely on a project
  • During architecture design phase
  • As part of compliance or governance reviews

🆚 Assessment vs Audit: The Summary Table

FeatureSecurity AuditSecurity Assessment
🔍 FocusCode & DeploymentDesign, Processes, Strategy
📦 ScopeCurrent releaseProject-level, long-term
🐞 OutcomeDetect bugs & misconfigurationsEvaluate risk posture & maturity
⏳ ValidityShort-termLong-lasting unless major refactors
🎯 DepthSpecific, concrete issuesBroad, systemic insights
🛠️ AnalogyBreaking in to test securityReviewing how the system is built and staffed

🧩 Why You Need Both

  • Audits catch what’s wrong right now
  • Assessments tell you if you’re doing security right overall

Together, they offer a complete picture:

  • The microscope (audit) finds immediate bugs.
  • The blueprint review (assessment) shows whether your system is structurally sound and sustainably secure.

🎓 Final Thoughts

Whether you’re building a product, contributing to an open source project, or choosing third-party tools, you shouldn’t settle for just an audit or just an assessment. Use both strategically:

  • Audits to plug current leaks.
  • Assessments to prevent future ones.

Security isn’t just about reacting—it’s about designing wisely, reviewing routinely, and fixing proactively.

📢 Want examples?

Organizations like the Cloud Native Computing Foundation (CNCF) regularly publish both third-party audit reports and long-term security assessments. These help maintain transparency and continuously improve open source ecosystems.

Posted on

Understanding How the OpenShift Console Is Exposed on Bare Metal

If you’ve ever used OpenShift, you’re probably familiar with its feature-rich web console. It’s a central hub for managing workloads, projects, security policies, and more. While the console is easy to access in a typical cloud environment, the mechanics behind exposing it on bare metal are equally interesting. In this article, we’ll explore how OpenShift 4.x (including 4.16) serves and secures the console in a bare-metal setting.

1. The Basics: Console vs. API Server

In OpenShift 4.x, there are two main entry points for cluster interactions:

  1. API server: Runs on port 6443, usually exposed by external load balancers or keepalived/HAProxy in bare-metal environments.
  2. Web console: Typically accessed at port 443 via an OpenShift “route,” backed by the cluster’s router/ingress infrastructure.

The API server uses a special out-of-band mechanism (static pods on master nodes). By contrast, the console takes a path much more familiar to standard Kubernetes applications: it’s served by a deployment, a service, and ultimately a Route object in the openshift-console namespace. Let’s focus on that Route-based exposure.

2. How the Console Is Deployed

Console Operator

The console itself is managed by the OpenShift Console Operator, which:

  • Deploys the console pods into the openshift-console namespace.
  • Ensures they remain healthy and up-to-date.
  • Creates the relevant Kubernetes resources (Deployment, Service, and Route) that expose the console to external users.

Where the Pods Run

By default, the console pods run on worker nodes (though in some topologies, you might have dedicated infrastructure nodes). The important point is that these pods are scheduled like normal Kubernetes workloads.

3. How the Console Is Exposed

The OpenShift Router (Ingress Controller)

OpenShift comes with a built-in Ingress Controller—often referred to as the “router.” It’s usually an HAProxy-based router deployed on worker (or infra) nodes. By default, it will listen on:

  • HTTP port 80
  • HTTPS port 443

When you create a Route, the router matches the host name in the incoming request and forwards traffic to the corresponding service. In the console’s case, that route is typically named console in the openshift-console namespace.

Typical Hostname
During installation, OpenShift configures the default “apps” domain. For instance:

console-openshift-console.apps.<cluster-domain>

So when you browse to, say, https://console-openshift-console.apps.mycluster.example.com, your request hits the router, which looks for the matching route and then forwards you to the console service.

The Route Object

OpenShift 4.x uses the Route resource to direct external traffic to an internal service. You can find the console route by running:

oc get route console -n openshift-console

You’ll usually see something like:

NAME      HOST/PORT                                                   PATH   SERVICES    PORT   TERMINATION   WILDCARD
console   console-openshift-console.apps.mycluster.example.com               console     https  edge          None
  • Service: The route points to the console service in the openshift-console namespace.
  • Edge Termination: The router typically provides TLS termination, ensuring secure communication.
  • Host: The domain you’ll use to access the console externally.

4. Traffic Flow on Bare Metal

External Access

On bare metal, you typically have one of the following configurations:

  1. Direct Node Access: If each worker node has a publicly (or at least internally routable) IP, you create a wildcard DNS record (or direct DNS records) that point to those node IPs (or to a load balancer fronting them).
  2. External Load Balancer: You can place an external L4 or L7 load balancer in front of the worker nodes’ port 443, distributing traffic across the router pods. This approach mirrors the cloud LB approach but uses an on-prem solution (F5, Netscaler, etc.).

Either way, the router’s service IP on each node is listening on port 443. By default, the Ingress Operator ensures that all router pods share a common DNS domain like *.apps.<cluster-domain>. This means that any Route you create automatically becomes externally accessible, assuming your DNS points to the router’s IP or load balancer VIP.

TLS Certificates

By default, the console route has a certificate created and managed by the cluster. You can optionally configure a custom TLS certificate for the router if you want to serve the console (and all other routes) with your own wildcard certificate.

5. Customizing the Console Domain or Certificate

You might want to customize how users access the console—maybe you don’t like the default subdomain or you want to serve it at a corporate domain. There are a couple of ways:

  1. Change the apps domain: During installation, you can specify a custom domain.
  2. Edit the Console Route: You can change the route’s host name, but you must ensure DNS for that host name points to your router’s public IP.
  3. Configure a Custom Cert: If you have a wildcard certificate for mycompany.com, you can apply it at the router level, so the console route and all other routes share the same certificate authority.

6. Scaling and Availability

Since the console runs as a standard Deployment, you can scale it up (e.g., set replicas: 3) if you anticipate heavy usage. The router itself is typically deployed on multiple nodes for high availability—ensuring that even if one node goes down, the router remains functional, and your console remains accessible.

7. How This Differs From the API Server

One point of confusion is that both the API server and the console run in the cluster—so why is the API server not also behind a Route?

  • API Server: Runs as static pods with hostNetwork: true on each master node, typically exposed on port 6443. It’s not a normal deployment and doesn’t rely on the cluster’s router. Instead, it usually sits behind a separate load balancer (external or keepalived/HAProxy).
  • Console: A normal deployment plus a Route, served by the ingress router on port 443.

So while the console takes advantage of standard Kubernetes networking patterns, the API server intentionally bypasses them for isolation, reliability, and the ability to run even if cluster networking is partially down.

8. Frequently Asked Questions

Q: Can I use MetalLB to expose the console on a LoadBalancer-type service?
A: You technically could set up a LoadBalancer service if you had MetalLB. However, the standard approach in OpenShift is to rely on the built-in router for console traffic. The console route is automatically configured, and the router takes care of HTTPS termination and routing.

Q: Do I need a separate load balancer for the console traffic?
A: If your bare-metal nodes themselves are routable (for example, each worker node has a valid IP and your DNS points console-openshift-console.apps.mycluster.example.com to those nodes), then you may not need an additional LB. However, some organizations prefer to place a load balancer in front of all worker nodes for consistency, health checks, and easier SSL management.

Q: How do I get a custom domain to work with the console?
A: You can edit the route’s hostname or specify a custom domain in your Ingress configuration. Then, point DNS for that new domain (e.g. console.internal.mycompany.com) to the external IP(s) of your router or your load balancer. Make sure TLS certificates match if you’re providing your own certificate.

Conclusion

In OpenShift 4.x, the web console is exposed via a standard Kubernetes Route and served by the built-in router on port 443. The Console Operator takes care of deploying and managing the console pods, while the Ingress Operator ensures a default router is up and running. On bare metal, the key to making the console accessible is to ensure your DNS points at the router’s external interface—whether that’s a dedicated IP on each worker node or an external load balancer VIP.

By understanding these mechanics, you can customize the console domain, certificate, and scaling strategy to best fit your environment. And once your console is online, you’ll have the full power of the OpenShift UI at your fingertips—no matter where your cluster happens to be running!

Posted on

Understanding OpenShift 4.x API Server Exposure on Bare Metal Openshift API server

Running OpenShift 4.x on bare metal has a number of advantages: you get to maintain control of your own environment without being beholden to a cloud provider’s networking or load-balancing solution. But with that control comes a bit of extra work, especially around how the OpenShift API server is exposed.

In this post, we’ll discuss:

  • How the OpenShift API server is bound on each control-plane (master) node.
  • Load-balancing options for the API server in a bare-metal environment.
  • The difference between external load balancers, keepalived/HAProxy, and MetalLB.

1. How OpenShift 4.x Binds the API Server

Static Pods with Host Networking

In Kubernetes, control-plane components like the API server can run as static pods on each control-plane node. In OpenShift 4.x, the kube-apiserver pods use hostNetwork: true, which means they bind directly to the host’s network interface—specifically on port 6443 by default.

  • Location of static pod manifests: These are managed by the Machine Config Operator and typically live in /etc/kubernetes/manifests on each master node.
  • Direct binding: Because these pods use host networking, port 6443 on the master node itself is used. This is not a standard Kubernetes Service or NodePort; it is bound at the OS level.

Implications

  • There is no Service, Route, or Ingress object for the control-plane API endpoint.
  • The typical Service/Route-based exposure flow doesn’t apply to these system components; they live outside the usual Kubernetes networking model to ensure reliability and isolation.

2. Load-Balancing the API Server

In a production environment, you typically want the API server to be highly available. You accomplish that by putting a load balancer in front of the master nodes, each listening on its own 6443 port. This helps ensure that if one node goes down, the others can still respond to API requests.

Below are three common ways to achieve this on bare metal.

Option A: External Hardware/Virtual Load Balancer (F5, etc.)

Overview
Many on-prem or private datacenter environments already have a load-balancing solution in place—e.g., F5, A10, Citrix, or Netscaler appliances. If that’s the case, you can simply:

  1. Configure a virtual server that listens on api.<cluster-domain>:6443.
  2. Point it to the IP addresses of your OpenShift master nodes on port 6443.

Pros

  • Extremely common in enterprise scenarios.
  • Well-supported by OpenShift documentation and typical best practices.
  • Often includes advanced features (SSL offloading, health checks, etc.).

Cons

  • Requires specialized hardware or a VM/appliance with a license in some cases.

Option B: Keepalived + HAProxy on the Master Nodes

Overview
If you lack a dedicated external load balancer, you can run a keepalived/HAProxy setup within your cluster’s control-plane nodes themselves. Typically:

  • Keepalived manages a floating Virtual IP (VIP).
  • HAProxy listens on the VIP (on port 6443) and forwards traffic to the local node or other master nodes.

Pros

  • No extra hardware or external appliances needed.
  • Still provides a single endpoint (api.<cluster-domain>:6443) that floats among the masters.

Cons

  • More complex to configure and maintain.
  • You’re hosting the load-balancing solution on the same nodes as your control-plane, so it’s critical to ensure these components remain stable.

Option C: MetalLB for LoadBalancer Services

Overview
MetalLB is an open-source solution that brings “cloud-style” LoadBalancer services to bare-metal Kubernetes clusters. It typically works in Layer 2 (ARP) or BGP mode to announce addresses, allowing you to create a Service of type: LoadBalancer that obtains a routable IP.

Should You Use It for the API Server?

  • While MetalLB is great for application workloads requiring a LoadBalancer IP, it is generally not the recommended approach for the cluster’s control-plane traffic in OpenShift 4.x.
  • The API server is not declared as a standard “service” in the cluster; instead, it’s a static pod using host networking.
  • You would need additional customizations to treat the API endpoint like a load-balancer service. This is a non-standard pattern in OpenShift 4.x, and official documentation typically recommends either an external LB or keepalived/HAProxy.

Pros (for application workloads)

  • Provides a simple way to assign external IP addresses to your apps without external hardware.
  • Lightweight solution that integrates neatly with typical Kubernetes workflows.

Cons

  • Not officially supported for the API server’s main endpoint.
  • Missing advanced features you might find in dedicated appliances (SSL termination, advanced health checks, etc.).

3. Recommended Approaches

  1. If You Have an Existing Load Balancer
    • Point it at your master nodes’ IP addresses, forwarding :6443 to each node’s :6443.
    • You’ll typically have a DNS entry like api.yourcluster.example.com that resolves to the load balancer’s VIP or IP.
  2. If You Don’t Have One
    • Consider deploying keepalived + HAProxy on the master nodes. You can designate one floating IP that is managed by keepalived. HAProxy on each node can route requests to local or other masters’ API endpoints.
  3. Use MetalLB for App Workloads, Not the Control Plane
    • If you are on bare metal and need load-balancing for normal application services (i.e., front-end web apps), then MetalLB is a great choice.
    • However, for the control-plane API, it’s best to stick to the official recommended approach of an external LB or keepalived/HAProxy.

Conclusion

The API server in OpenShift 4.x is bound at the host network level (port 6443) on each control-plane node via static pods, which is different from how typical workloads are exposed. To achieve high availability on bare metal, you need some form of load balancer—commonly an external appliance or keepalived + HAProxy. MetalLB is excellent for exposing standard application workloads via type: LoadBalancer, but it isn’t the typical path for the OpenShift control-plane traffic.

By understanding these different paths, you can tailor your OpenShift 4.x deployment strategy to match your on-prem infrastructure, making sure your cluster’s API remains accessible, robust, and highly available.

Posted on

Time Management

Summary of Time Management Resources

Time is a finite resource — you can’t create more of it or change when things are due. However, you can manage how you use the time you have by planning effectively and utilizing certain resources. Here are three key resources to help manage your time effectively:

  1. Time and Place to Yourself:
    • It’s essential to have some quiet time for yourself to think and plan, but this doesn’t have to be a specific or glamorous time slot. It can be any time you find throughout your day — such as early in the morning before others wake up, during a lunch break, or even while in the shower. The goal is to use this time to focus on what needs to be done and plan your day accordingly.
    • This dedicated time should not add stress; it should fit your needs and help you concentrate on managing your time accurately.
  2. Recording Tools:
    • Use simple tools like pen and paper to jot down your thoughts, tasks, and plans. This could be done on any available paper (an old receipt, envelope, or a blank sheet) and doesn’t need to be fancy.
    • Writing by hand is recommended as it involves more of your senses, helps reduce stress, and improves your focus and memory retention. It allows for a deeper understanding and better engagement with the subject matter.
  3. Tracking Tools:
    • While pen and paper are useful for initial brainstorming and listing tasks, you’ll need a more permanent solution to track your time effectively. Consider using a paper calendar, an online calendar, or a digital tool like a spreadsheet.
    • Tools such as Google Calendar, Microsoft Excel, or bullet journals help keep track of your time in more detail, allowing you to monitor your schedule down to the hour or day.

Key Concepts in Time Management

Time management involves two main factors: control and organization. However, not every aspect of your life can be fully controlled. For example, while you can’t control unexpected events or conflicts, you can manage how you respond to them. By using the resources above, you gain better control over how you allocate your time, helping you become more organized and prepared to handle daily tasks and unforeseen challenges.

Managing Your Time Effectively

To manage your time effectively, you need to treat it as a valuable resource, much like money. Keeping track of your time involves using tools and strategies to understand where your time goes and how to use it more wisely. Here are key steps to help you manage your time:

  1. Take an Inventory of Your Time:
    • Start by writing down all the activities you do daily and how much time you spend on each. Use pen and paper if possible, as this method is more engaging and easier to reflect upon. As you get better at this, you can expand to include weekly and monthly activities.
  2. Analyze Your Time Inventory for Peak Energy Levels:
    • Look at your time inventory to identify when you are most productive — your peak daily energy levels. This could be in the morning, late at night, or any specific time when you feel you accomplish the most. Use this information to determine the best times to schedule your most important tasks.
  3. Prioritize Self-Care:
    • Schedule time for self-care before any other tasks. Taking care of yourself is crucial to maintaining your productivity and effectiveness. Start by dedicating at least an hour a day for self-care activities. Resist the urge to put work before your well-being, which often comes from a perfectionist mindset. Embracing a “good enough” mindset helps reduce stress and avoids burnout.
  4. Evaluate and Prioritize Remaining Tasks:
    • Assess each task to determine its urgency and importance. Reorganize your list of tasks, prioritizing them based on their significance and any dependencies. Make sure to address tasks that could alleviate other deadlines first.
    • Identify Tasks Within Your Capacity: Recognize that you only have limited time and energy each day. Determine which tasks are realistic to complete within your available time.
    • Eliminate or Delegate Nonessential Tasks: Say “no” to tasks that are not essential or have low priority. Delegate tasks when possible, such as asking a coworker for help or outsourcing minor duties. This allows you to focus on what is most important.
  5. Schedule Tasks Based on Priority and Peak Energy Levels:
    • Plan your schedule according to the priority of tasks, the time available, and your peak energy periods. Important tasks should be scheduled during your most productive times to ensure they are completed effectively. Use your understanding of your strengths and energy patterns to optimize your daily schedule.

Benefits of an Anti-Perfectionism Mindset

  • Reduces Stress and Anxiety: Letting go of perfectionism helps reduce the stress and pressure to always perform flawlessly.
  • Encourages Flexibility: An anti-perfectionist or “good enough” mindset allows you to adapt more easily to changes and setbacks.
  • Improves Productivity: By focusing on what’s essential and embracing a good enough approach, you can complete tasks more efficiently without getting bogged down by unnecessary details.
  • Supports Well-being: Prioritizing self-care and avoiding burnout leads to a healthier work-life balance.

Here’s a suggested chart format to help you organize your daily, weekly, and monthly tasks, along with your analysis of peak energy levels. This format is divided into different sections to capture the activities you currently do, the activities you wish to do but don’t have time for, and your peak energy times.

1. Daily Activities and Time Tracking

ActivityTime Spent (hours/minutes)Notes
Morning routine1.15 hourwake up at 6.30 – 7.45
Commuting1.5 hours7.45 to 8.30 / 5.00 – 5.45
Work (tasks or meetings)8 hours8.30 – 5.00
Lunch break30 minutes1 PM – 1.30 PM
Exercise45 minutes6.30 PM to 7.15 PM
Evening relaxation (TV, etc.)1 hour7.30 PM to 8.30 PM
Dinner45 min8.30 – 9.15 PM
Household chores15 min9-15 -9.30 PM
Research & Reading1 hour9.30 – 10.30
Sleep8 hours10.30 – 6.30
Total Time Spent

Unscheduled Daily Activities (Want to Do but No Time)

ActivityTime Needed (hours/minutes)Priority Level
Go to the gym
Watch a favorite show
Meditate

2. Weekly Activities and Time Tracking

ActivityEstimated Time (hours/minutes)Notes
Grocery shopping
Cleaning/household tasks
Socializing with friends
Hobbies (e.g., painting, music)
Self-care (e.g., spa, massage)
Total Time Spent

Unscheduled Weekly Activities (Want to Do but No Time)

ActivityTime Needed (hours/minutes)Priority Level
Weekly massage
Long hike
Attend a workshop
Posted on

Tailscale on Firewalla using Docker

In this article, you will learn how to set up Tailscale on a Firewalla device using Docker. We’ll guide you through creating necessary directories, setting up a Docker Compose file, starting the Tailscale container, and configuring it to auto-start on reboot. This setup will ensure a secure and stable connection using Tailscale’s VPN capabilities on your Firewalla device.

Step 1: Prepare Directories

Create the necessary directories for Docker and Tailscale:

mkdir -p /home/pi/.firewalla/run/docker/tailscale
cd /home/pi/.firewalla/run/docker/tailscale

Step 2: Create Docker Compose File

Create and populate the docker-compose.yml file:

cat > docker-compose.yml << EOF
version: "3"
services:
  tailscale:
    image: tailscale/tailscale:stable
    container_name: firewalla-tailscale
    deploy:
      restart_policy:
        condition: on-failure
        max_attempts: 3
    network_mode: "host"
    volumes:
      - "/home/pi/.firewalla/run/docker/tailscale:/var/lib"
      - "/dev/net/tun:/dev/net/tun"
    privileged: true
    cap_add:
      - net_admin
      - sys_module
    command: tailscaled
EOF

In this configuration, the image tag stable ensures a stable version of Tailscale is used.

Step 3: Start the Container

Start Docker and the Tailscale container:

sudo systemctl start docker
sudo docker-compose up -d
sudo docker exec firewalla-tailscale tailscale up --advertise-routes=192.168.1.0/24 --advertise-exit-node
sudo docker exec firewalla-tailscale tailscale status

Follow the printed instructions to authorize the node and routes.

Step 4: Auto-Start on Reboot

Ensure Docker and Tailscale start on reboot by creating the following script:

mkdir -p /home/pi/.firewalla/config/post_main.d/
cd /home/pi/.firewalla/config/post_main.d/
cat > start_tailscale.sh <<EOF
#!/bin/bash

echo "\$0 - \$(date "+%Y-%m-%d - %H:%M:%S") - starting docker"
sudo systemctl start docker
sleep 60
cd /home/pi/.firewalla/run/docker/tailscale

echo "\$0 - \$(date "+%Y-%m-%d - %H:%M:%S") - pulling latest images"
sudo docker-compose pull

echo "\$0 - \$(date "+%Y-%m-%d - %H:%M:%S") - bringing containers up"
sudo docker-compose up -d
sleep 60

echo "\$0 - \$(date "+%Y-%m-%d - %H:%M:%S") - starting tailscale"
sudo docker exec firewalla-tailscale tailscale up --advertise-routes=192.168.1.0/24 --advertise-exit-node
sleep 15

echo "\$0 - \$(date "+%Y-%m-%d - %H:%M:%S") - checking status"
sudo docker exec firewalla-tailscale tailscale status

echo "\$0 - \$(date "+%Y-%m-%d - %H:%M:%S") - pruning images"
sudo docker system prune -f
EOF

Make the script executable:

chmod +x start_tailscale.sh

With these steps, you should have Tailscale running on Firewalla using Docker. Adjust the advertise-routes command as needed for your network configuration.

For additional details and troubleshooting, refer to the original Firewalla community post.

Posted on

Implementing a Secure Network at Home: Safeguarding Your Digital Environment using Firewalla

Part-1

Introduction: After careful consideration and extensive research, it has become evident that securing our home networks is of utmost importance, particularly in today’s digital age. With the pervasive use of social media, the potential for malware and unwanted sites, and the challenge of managing multiple devices, it is essential to establish a secure network environment. In this two-part blog series, we will explore the hazards of the internet, the benefits of network segmentation, and different security options available to fortify your home network.

Hazards of the Internet:

A. Risks to Children and Teenagers:
  • Unrestricted access to social media platforms.
  • Cyberbullying, online harassment, and exposure to inappropriate content.
  • Potential risks associated with interacting with strangers online.
B. Malware and Unwanted Sites:
  • Prevalence of malware and its potential consequences, such as data theft and financial loss.
  • Risks associated with visiting compromised or malicious websites.
  • Inadvertent downloads of malicious files or software.
C. Online Scams and Phishing Attacks:
  • Phishing emails, fraudulent websites, and scams targeting personal and financial information.
  • Identity theft, financial fraud, and unauthorized access to sensitive accounts.
D. Privacy and Data Security:
  • Collection and misuse of personal information by online services and data brokers.
  • Inadequate protection of sensitive data, leading to potential breaches and privacy violations.

Solution – Establishing a Safe and Secure Home Network:

So the solution to the problem is to establish a safe and secure home network. Here are some key features you need to consider:

  • Strong Firewall: A robust firewall acts as a gatekeeper, blocking unauthorized access and potential threats from entering your network.
  • Intrusion Detection and Prevention: This feature keeps an eye on your network traffic, quickly spotting any suspicious activity and stopping potential attacks.
  • Secure Wi-Fi: Use strong encryption (like WPA2 or WPA3) to secure your wireless network, preventing unauthorized users from accessing your network.
  • Content Filtering and Parental Controls: Control what websites can be accessed on your network, especially for children, to block inappropriate or harmful content.
  • Network Segmentation: Divide your network into separate parts to isolate sensitive devices or areas, preventing potential breaches from spreading.
  • VPN (Virtual Private Network): If you need remote access to your home network, use a VPN to create a secure connection and protect your data.
  • Real-time Monitoring: Continuous monitoring of your network allows you to keep an eye on the traffic, devices, and activities taking place. You can quickly identify any unusual behavior or potential security threats as they happen.
  • Instant Alerts: By setting up alerts, you can receive immediate notifications whenever there is a security event or suspicious activity on your network

My search for a solution covering above features ended with Firewalla , Firewalla | Firewalla: Cybersecurity Firewall For Your Family and Business. Firewalla is a very good network security solution, and if you have more than 10 to 20 devices accessing the internet including the smart devices and IOT devices its worth considering investing on one of the many models they offer. In the next part of the blog i will explain the steps I followed to implement a secure home network

Posted on

Title: Ransomware: What You Need to Know in Simple Terms

In today’s digital age, cybersecurity threats have become increasingly prevalent. One such threat that has gained significant attention is ransomware. This blog post aims to explain ransomware in basic English, devoid of technical jargon, so that everyone can understand its implications and take necessary precautions to protect themselves.

What is Ransomware?

Ransomware is a type of malicious software (malware) that cybercriminals use to lock or encrypt files on your computer or network. The intention behind this is to prevent you from accessing your own files unless you pay a ransom to the attackers.

How Does Ransomware Work?

Ransomware usually enters your computer or network through deceptive emails, infected websites, or malicious downloads. Once it infiltrates your system, it starts encrypting your files, essentially making them unreadable and inaccessible without a special decryption key. The attackers then demand payment in exchange for providing you with the key to unlock your files.

Why Do Attackers Use Ransomware?

The primary motivation behind ransomware attacks is financial gain. Cybercriminals hope that by holding your files hostage, you will be willing to pay the ransom to regain access to your important data. The ransom is often demanded in cryptocurrencies like Bitcoin, making it difficult to trace the attackers.

Preventing Ransomware Attacks:

  1. Keep Your Software Updated: Regularly update your operating system, antivirus software, and other applications. Software updates often include security patches that help protect against known vulnerabilities.
  2. Be Cautious of Suspicious Emails: Avoid clicking on links or downloading attachments from unfamiliar or suspicious emails. Be particularly cautious if the email seems urgent or asks you to provide personal information.
  3. Use Strong Passwords: Choose strong and unique passwords for all your online accounts. It’s best to use a combination of letters, numbers, and symbols. Avoid using easily guessable passwords like your birthdate or “password123.”
  4. Backup Your Files: Regularly back up your important files to an external hard drive or a secure cloud storage service. This way, even if you fall victim to a ransomware attack, you can restore your files from a backup without having to pay the ransom.

What to Do if You Are Infected:

  1. Disconnect from the Internet: If you suspect that your computer is infected with ransomware, disconnect it from the internet immediately. This can help prevent further spread of the malware and protect other devices on your network.
  2. Report the Incident: Contact your local law enforcement or a cybersecurity professional to report the ransomware attack. They may be able to provide guidance on how to handle the situation and potentially catch the attackers.
  3. Do Not Pay the Ransom: It’s tempting to pay the ransom to regain access to your files quickly, but there is no guarantee that the attackers will actually provide you with the decryption key. Paying the ransom also encourages further criminal activity.

Ransomware poses a significant threat to individuals and organizations alike. By understanding the basics of ransomware and taking preventive measures, such as keeping software updated, being cautious of suspicious emails, and backing up files regularly, you can reduce the risk of falling victim to a ransomware attack. Remember, staying informed and practicing good cybersecurity habits is essential in safeguarding your digital life from these malicious threats.