A recent write-up from OX Security highlights this clearly, documenting vulnerabilities in popular IDE extensions that can lead to remote code execution and local file exfiltration.

This isn’t limited to software engineers. Anyone using an IDE for scripting, automation, or data work is operating in the same environment.

Reference:
https://www.ox.security/blog/four-vulnerabilities-expose-a-massive-security-blind-spot-in-ide-extensions/

The Trust Boundary Problem

VS Code and similar editors tend to feel like local tools. They are familiar, fast, and deeply integrated into daily workflows. Over time, that familiarity creates a subtle assumption: that everything inside the editor is safe by default.

In practice, many extensions run with broad local permissions. They may be able to access:

• Local source code and build outputs

• Environment variables and configuration files

• Secrets such as API tokens, SSH keys, and cloud credentials

These permissions are rarely reviewed with the same rigor as backend dependencies. Extensions are installed ad hoc, updated automatically, and often left in place indefinitely.

The risk is not that extensions are inherently malicious, but that they operate inside a trust boundary that is often undefined, unenforced, and rarely audited.

What the Research Highlights

The OX Security report shows that this trust model does not hold under scrutiny, even for widely used extensions with large install bases.

Key findings include:

• Remote code execution via exposed extension functionality

• Local file exfiltration triggered through crafted inputs

• Weak assumptions about the origin and integrity of incoming data

These issues arise because extensions operate in a hybrid model: local execution combined with network access, without the same controls typically applied to production services.

The Visibility Gap

This is not primarily a tooling problem. It is a visibility problem.

In most environments:

• Extension inventories are not centrally tracked

• Permissions are not regularly reviewed

• There is no lifecycle process for reassessment or removal

Over time, IDE extensions become a silent part of the attack surface—present on every developer machine, but rarely included in security reviews.

Listing Installed VS Code Extensions on macOS

If you want to audit extensions, the first step is simply knowing what is installed.

On macOS, you can list all your VS Code extensions by running:

ls ~/.vscode/extensions

Each directory follows this format:

publisher.extension-version

Important: Only include the Extension ID and NOT the version number

Extension scanning and auditing tools, such as VSCan, expect the extension ID in the following format otherwise the tool will not recognise it:

publisher.extension #nothing else

To extract clean extension IDs on macOS, run this in your terminal:

for dir in ~/.vscode/extensions/*; do
  name=\((basename "\)dir")
  echo "${name%-*}"
done

This list can then be used for:

• Manual review – Check if extensions like ms-python.python or eamodio.gitlens are really needed, and remove any that are unused.

• Feeding into scanning tools – tools such as VSCan can analyse each extension for risky behaviours or suspicious permissions.

• Cross-referencing against vulnerability disclosures and advisories – See if installed extensions match those flagged in vulnerability reports, such as the OX Security blog highlighting Live Server or Markdown Preview Enhanced.

• Staying informed – Devs should consider following sources like The Hacker News, security blogs, and advisory feeds to stay up to date on new extension vulnerabilities and patches.

Here’s an example of the output you can expect to see from VSCan:

Risk indicators are not absolute: Even well-maintained extensions can introduce exposure depending on how they are configured, what files they can access, and whether they have network reach. The actual risk is determined less by the extension itself and more by the environment it runs in and the privileges it operates under.

Auditing Extensions Without Overengineering

Unlike system packages or backend dependencies, IDE extensions don't have a mature, centralised vulnerability tracking ecosystem. That makes conventional dependency scanning only partially effective.

In environments where no formal process exists, tools such as VSCan can help by analysing installed extensions for risky behaviour patterns and known security concerns. The goal is to replace assumption-based trust with observable facts about what each extension actually does.

From there, a lightweight operational baseline is often enough:

• Periodic review of installed extensions to ensure each one still serves a purpose

• Removal of unused or redundant extensions to reduce overall attack surface

• Preference for extensions that are actively maintained or published by trusted sources

This approach avoids unnecessary process overhead while still reducing exposure in a meaningful way.

A Small Shift in Perspective

The key takeaway is straightforward. IDE extensions sit inside the same trust boundary as other dependencies, even if they are often treated as harmless convenience tools.

Addressing this doesn't require heavy governance or restrictive controls. It starts with basic visibility and a consistent habit of asking a simple question:

What is actually executing inside this environment?

Whether you're writing application code, working with data, or managing infrastructure, the editor is part of the software supply chain. It deserves to be treated with that same level of scrutiny.

However, the moment a system is exposed to a network (internal/external), its threat model changes. It transitions from an isolated compute environment into a reachable execution target. What follows is the process of moving from this default, permissive state to a controlled execution environment, ending with an operational monitoring model which will be covered in Part Two.

System Exposure and Baseline Inspection

Before altering the system, you need to understand its current exposure.
Network listeners:

sudo ss -tulnp

This command reveals which processes are actively bound to network interfaces. At this stage, the network layer makes no distinction between intended services (like SSH) and accidental exposure (like a default database binding to 0.0.0.0).

Example output:

Installed package drift:

apt list --upgradable

This command shows the gap between what’s installed locally and what the repositories currently provide. That gap is where security debt accumulates.

Example output:

Enabled services:

systemctl list-unit-files --state=enabled

This command lists everything configured to execute automatically during boot. Its the most accurate representation of the system's baseline behaviour.

Example output:

Package State Alignment

Systems degrade securely over time if they're not consistently aligned with upstream security patches.

Update alignment:

sudo apt update && sudo apt upgrade -y

Verification:

apt list --upgradable

The expected steady state is an empty upgrade list. Anything else represents drift that needs to be addressed.

Expected output:

Automating Security Updates

Manual update cycles rely on human consistency, which is inherently flawed. Security patch latency (the window between vulnerability disclosure, package availability, and human execution) is where the majority of exploitation occurs.

Enable unattended updates:

sudo apt install unattended-upgrades -y

Note: you might already have this package installed on your system.

Verify behaviour configuration:

cat /etc/apt/apt.conf.d/20auto-upgrades

This file dictates whether update scheduling is successfully delegated to the system. You should see APT::Periodic::Update-Package-Lists "1"; and APT::Periodic::Unattended-Upgrade "1";.

Example output:

SSH as an Execution Boundary

SSH operates as a remote execution boundary at the operating system level. Once access is established, the session effectively represents direct command execution on the host. When password authentication is enabled, that boundary is governed primarily by password strength and any rate-limiting controls enforced by the service.

Removing password authentication reduces the system to key-based identity verification only, but this change must be executed with a verified fallback path already in place.

Warning: Before disabling password authentication, ensure you have successfully generated and copied your SSH public key to ~/.ssh/authorized_keys on the remote server. Otherwise, you will lock yourself out.

Precondition: Verify SSH Key Access

From your local machine, confirm you can log in using SSH:

ssh user@server_ip

If a password is still required, key authentication hasn't been configured yet.

You can explicitly test key usage:

ssh -i ~/.ssh/id_rsa user@server_ip

Ensure your public key exists on the remote server:

cat ~/.ssh/authorized_keys

If its missing, copy it using:

ssh-copy-id user@server_ip

Make sure permissions are correct:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Keep an active SSH session open while making changes, in case rollback is needed.

SSH configuration:
Modifying the /etc/ssh/sshd_config file.

sudo sed -i 's/^#*PasswordAuthentication yes/PasswordAuthentication no/' /etc/ssh/sshd_config
sudo sed -i 's/^#*PermitRootLogin yes/PermitRootLogin no/' /etc/ssh/sshd_config

The commands above will ensure the following directives are set:

PasswordAuthentication no
PermitRootLogin no

Apply and verify the changes:

sudo systemctl restart ssh
sudo sshd -T | grep -i passwordauthentication

Example output:

After this change, SSH access depends entirely on key-based authentication. Password login is no longer accepted by the service configuration.

Example of key-based authentication:

The Firewall as Traffic Definition

A firewall does not inherently secure a vulnerable application, but it enforces strict network boundaries, defining exactly which paths are valid.

Configure UFW (Uncomplicated Firewall):

sudo ufw allow OpenSSH
sudo ufw enable

Example output:

Verification:

sudo ufw status verbose

Example output:

Note: If SSH is not explicitly allowed before enabling the firewall, all active and future connections will be dropped.

Service Minimisation

Every enabled system service increases the memory footprint, dependency surface during boot, and potential attack vectors. There is no distinction between a service you deliberately intended to expose and one installed silently as a dependency unless you actively audit them.

Review your active listeners (sudo ss -tulnp) and disable anything unnecessary:

sudo systemctl disable --now <service_name>

The Operational Monitoring Layer

At this stage, the system is secured but not yet structured for robust observability.

Linux produces vital telemetry, natively split between runtime event streams and persisted file logs (traditionally in /var/log). Historically, managing this was fragmented. Systemd unifies this execution and monitoring model.

Why systemd supersedes legacy execution

Historically, service execution was handled by a mix of SysV init scripts, cron-based scheduling, and ad-hoc supervision tools. This resulted in:

• No unified dependency graph.

• Inconsistent startup ordering.

• Manual supervision required for long-running processes.

• Fragmented logging channels.

Systemd is often reductively called a "service manager", but it is actually a unified execution and dependency management framework. Instead of executing disparate scripts, systemd treats the system as a strict dependency graph of managed units.

Core systemd components:

• PID 1: The systemd daemon itself, controlling the boot lifecycle.

• Unit files: Declarative service definitions.

• Journald: The integrated, binary log collection subsystem.

• Timers: The scheduled execution model.

Why systemd timers replace cron

Cron operates on a rudimentary premise: "execute command X at time Y".
It has no contextual awareness of whether the previous execution is still running, if the system is overloaded, or if prerequisite services are available.

Systemd timers resolve these operational blind spots:

• Contextual execution: Execution is tied strictly to service units, allowing for dependency mapping (e.g., "only run this script if the network is up").

• State awareness: You can query execution state reliably via systemctl.

• Built-in supervision: Overlapping executions can be prevented automatically.

• Unified logging: Standard output (stdout) and errors (stderr) from timed tasks are captured automatically by journald, ensuring scheduled tasks are monitored exactly like persistent daemons.

The shift from cron to systemd timers reflects a move toward system-aware scheduling that integrates with service state, logging, and lifecycle management. Because systemd inherently understands execution state, manages dependencies, and natively captures logs, it provides the robust execution engine required for the active alerting architecture we will implement in Part Two.

APIs are the same. Once you understand the rules, what first seems chaotic becomes structured. If you can follow a rugby match from kickoff to final whistle, you can understand how a web server talks to the outside world.

What is a REST API?

To most people, "API" sounds like dense technical jargon. In reality, an Application Programming Interface is just a formal agreement (or a digital contract) between two systems.

It defines exactly how one piece of software asks for information and what it gets back in return. Without these strict rules, different programs would be "lost in translation," like two people trying to collaborate while speaking different languages and following different social customs. An API ensures they both speak the same dialect.

Why this agreement is considered a contract:

• Predictable Inputs: The contract states, "If you want this data, you must ask for it in this specific format" (e.g., a specific URL or a piece of JSON code).

• Guaranteed Outputs: The system promises, "If you ask correctly, I will always give you the data in this specific structure."

• Stability: If the team decides to change their internal training regime or swap out the locks in the engine room (the internal database), it doesn’t matter to the rest of the backline. As long as the fly-half executes the same "contracted" pass to the center, the play continues smoothly. The internal "gym work" might change, but the delivery on the pitch remains predictable so the team doesn't lose its rhythm.

REST (Representational State Transfer) is the most popular "architectural style" for building web APIs. Think of it as a set of design rules rather than a specific piece of software.

It works by piggybacking on HTTP, the same language your browser uses to load this page. By following REST’s predictable standards, developers can move data across the internet as easily as you navigate from one website to another.

A Quick Note on Other API Styles

Other API styles exist to handle specific needs. For example, SOAP is a rigid, XML-based protocol often used in legacy enterprise systems, while gRPC is a high-performance binary system designed for speed and is often more specialised than a standard web application requires.

I’m not very familiar with these other styles yet, and for now my main focus is REST as it is widely used and sufficient for most web applications.

API Types

APIs can also be classified by who can use them and how they are intended to be consumed. In this context, “consumed” simply means how a client or system uses the API to get data or perform actions.

Common API types include:

• Public APIs – available for anyone to use. External developers can consume them freely, often following published documentation.

• Private APIs – intended for internal use only. They are consumed by systems or teams within the organisation.

• Partner APIs – shared with specific business partners. Only authorised partners can consume these APIs under controlled conditions.

Understanding both API styles (how an API works) and API types (who can use it) gives you a complete picture of how APIs are designed and organised.

How REST Works

In REST, every piece of data you interact with is called a resource. A resource is any identifiable "thing" the system manages, such as a player like Cheslin Kolbe, a match, or even the entire United Rugby Championship league.

To manage and reference these resources, we use identifiers. This is where URI and URL come in.

URI (Uniform Resource Identifier)

A URI is like a player’s unique ID in the league database. It identifies the resource itself, regardless of where it’s stored or how you access it.

• Example: player:911
  This identifies player 911 permanently, without specifying how to fetch their data.

Key point: A URI identifies something but doesn’t tell you where or how to access it.

URL (Uniform Resource Locator)

A URL is a special type of URI that not only identifies the resource but also tells you how and where to access it over a network.

• Example: https://tech-journeys.com/players/kolbe This URL identifies Cheslin Kolbe and also tells your system to fetch his data via HTTPS from this exact location.

Key point: All URLs are URIs because they identify a resource, but not all URIs are URLs.

Quick Rule of Thumb

1. URI: identifies a resource (who/what)

2. URL: identifies a resource and tells you how to locate it (who/what + where/how)

3. Relationship: Every URL is a URI, but not every URI is a URL.

Rugby Analogy Summary

Here’s an example written in Python:

# Define a list of players (unique identifiers in the system)
player_uris = [
    "players/kolbe",
    "players/smith",
    "players/duplessis",
    "players/mapimpi"
]

# Base URL of our rugby API or website
base_url = "https://tech-journeys.com/"

# Loop through each player and generate their full URL
for uri in player_uris:
    player_url = f"{base_url}{uri}"
    print("Player URI:", uri)
    print("Player URL:", player_url)
    print("-" * 40)  # separator for readability

Output

Scenario

Imagine we are building an international rugby statistics platform. One of our resources is a player.

To interact with that player, REST allows a small set of actions called HTTP methods. These are the legal moves of the game, defining what you can do with each resource.

GET – Scout Watching the Match

A GET request asks the server for information without changing anything. Think of it as a scout reviewing footage, observing without interfering.

import requests

# Get Cheslin Kolbe's stats
response = requests.get("https://tech-journeys.com/players/kolbe") #This URL doesn't really exist :)
player_data = response.json()
print(player_data)

Output

{
  "name": "Cheslin Kolbe",
  "team": "South Africa",
  "position": "Wing",
  "special_move": "Ankle Breaker",
  "world_cups": [2019, 2023]
}

POST – Adding a New Player

A POST request sends new information to the server to create something that does not yet exist. This is like officially adding a new player to the squad.

new_player = {
    "name": "Canan Moodie",
    "team": "South Africa",
    "position": "Centre",
    "world_cups": [2023]
}

response = requests.post("https://tech-journeys.com/players", json=new_player)
print(response.status_code)  # 201 means created

PUT – Updating a Player

A PUT request replaces or updates an existing resource. For example, updating a player’s position after a tactical change.

updated_position = {
    "position": "Fullback"
}

response = requests.put("https://tech-journeys.com/players/kolbe", json=updated_position)
print(response.status_code)  # 200 means success

DELETE – Removing a Player

A DELETE request removes a resource completely. This is like a permanent substitution.

response = requests.delete("https://tech-journeys.com/players/retired_player_id")
print(response.status_code)  # 204 means no content, successfully deleted

A Simple System Design View

System design is the process of planning and organising all the parts of a software system so it works reliably, efficiently, and can handle real-world use. You can think of it as designing a rugby stadium and playbook, you need to know where everything goes, how players move, and how referees, coaches, and spectators interact.

For a REST API, the high-level view looks like this:

[Client] ----------> [REST API Server] ---------> [Database]
GET/POST/PUT/DELETE                               CRUD operations

• Client – could be a web app, mobile app, or Python script.

• REST API Server – receives requests, enforces rules (HTTP methods), and manages resources.

• Database – stores the resources like players, matches, and stats.

Good system design ensures your API behaves predictably, scales well, and is easier to maintain, like a well-coached rugby team.

Looking at the Language of the Game: JSON

When a server responds, it doesn’t send pictures of Kolbe. It sends data.

That data is usually formatted as JSON, JavaScript Object Notation, a lightweight text-based structure designed to be easy for both humans and machines to read. JSON organises information into key-value pairs, much like a stat sheet in rugby.

Example of a player in JSON:

{
  "name": "Cheslin Kolbe",
  "team": "South Africa",
  "position": "Wing",
  "special_move": "Ankle Breaker",
  "world_cups": [2019, 2023]
}

Here, "name", "team", "position" "special_move" and "world_cups" are the keys, and the values describe the player.

API Security

You wouldn't just let anyone walk into the changing room, and you shouldn't just let anyone access your data. So make sure Security is always at the forefront.

Authentication and Authorisation

Authentication answers the question, who are you? It verifies identity. In APIs, this is commonly done using an API key or a JWT, JSON Web Token, which is a signed token proving identity for a limited time.

Python example:

import requests

headers = {"Authorization": "Bearer YOUR_JWT_TOKEN"}
response = requests.get("https://tech-journeys.com/players/kolbe", headers=headers)
print(response.json())

Authorisation answers the question, what are you allowed to do? Even after identity is confirmed, the system checks permissions. Just because you have a ticket to the stadium doesn’t mean you can sit in the coaching box (although it would’ve been nice listening to the mastermind Rassie himself). Both checks happen on every request.

Encryption

Data travelling between a client and a server must be protected. HTTPS uses TLS, Transport Layer Security, to encrypt communication. This ensures that if a "hacker" intercepts the data while it’s traveling between the Cape Town server and your phone, all they see is scrambled nonsense.

Rate Limiting

APIs must defend against overload. Rate limiting restricts how many requests a client can make in a given period, for example 100 requests per minute. This prevents abuse and protects the system from Denial-of-Service (DoS) attacks, which try to overwhelm servers by flooding them with traffic. You can think of it as crowd control at a sold-out international match, because without limits, the system would collapse under the pressure of too many requests.

How I Approach Complex Systems

Over time, I’ve learned that most systems only feel complex until you relate them to something familiar. Once you do that, the moving parts become easier to reason about.

A GET request is just observing state.
A POST request is introducing change.
Access control is no different from checking permissions at a gate.

The specific analogy doesn’t matter. It could be rugby, football, baking, or fixing cars. What matters is mapping abstract behaviour to something you already understand.

That shift in thinking turns technical concepts into something more durable. Instead of memorising terminology, you recognise patterns. And once you recognise the pattern, it’s much easier to apply it when you’re building or debugging real systems.

Credentials open doors. Consistent work determines progression.

Degrees, diplomas, and certifications have value, but it is limited. They may help your CV pass initial screening or get you into an interview. Beyond that, they carry little weight on their own.

Once you're in a conversation, the focus shifts to how you reason, how you approach problems, and what you've actually built. Without concrete work to reference, there is little to anchor that discussion, and that gap becomes visible quickly.

No Shortcuts in Competitive Markets

The job market is tough, and there’s no real bypass around that reality.

A common assumption, especially for graduates or career switchers is that companies will provide structured, in-depth training after hiring. In practice, that expectation often doesn’t match how teams operate.

Attitude does matter, but it has limited weight on its own. Intent is not a substitute for exposure, repetition, or hands-on experience with real systems.

Think Like a Hiring Manager

From a hiring manager’s perspective, the role exists to offload execution so they can focus on higher-level work and system direction.

In that context, the expectation is rarely to onboard someone from zero. The preference is usually for someone who can contribute meaningfully within a short time frame, even if they're still growing in the role.

Support and guidance are part of the environment, but most positions assume a baseline of practical competence is already in place before day one.

Credentials Without Evidence Have Limited Reach

If getting interviews or traction is difficult, relying only on qualifications on paper is often not enough. At some point, visibility and demonstrated ability start to matter more than listed credentials.

That visibility comes from consistent output. Whether through writing, short technical notes, videos, or documenting personal projects, the goal is the same: show how you think, how you approach problems, and how you communicate technical ideas.

Networking and public work are part of engineering practice as they surface how you think, communicate, and apply technical understanding in context that a CV alone cannot carry.

Whether the goal is a first role or progression within an existing one, the underlying principle stays consistent: make your work and reasoning visible.

Ask the Hard Question

At some point, self-assessment becomes necessary.

Would you hire yourself for this role, based on what you can demonstrate today?

If the answer is yes, there should be clear, practical reasons you can point to (work you’ve done, problems you’ve solved, and evidence of how you operate).

If your answer is no, then you’ve just identified a clear roadmap for your Tech Journey🙂

Hiring is centred on problem-solving capability. Stating that ability carries little weight on its own. What matters is showing how you approach problems, how you break them down, and whether you can carry that process through consistently.

Documentation Is Part of the Job

In technical environments, documentation is a requirement of system longevity. People rotate, teams change, but the systems remain.

Good documentation reduces operational risk, improves maintainability, and lowers the cost of future change. The act of writing it also exposes gaps in understanding, making it a form of validation rather than just record-keeping.

Tip: If you are already in a role and want to remain effective over time, avoid outsourcing all reasoning to others. Asking questions is part of the workflow, but doing so without first attempting to understand the system yourself will eventually slow both learning and contribution.

Experience Doesn’t Automatically Translate to Growth

Be careful not to confuse tenure with progression. Years of experience can accumulate without a corresponding increase in depth, ownership, or impact.

This often becomes visible when progression is expected but not granted. Being reliable within a defined scope is valuable, but it does not always translate into readiness for broader responsibility.

In many cases, the gap is not time spent in the industry, but the extent to which work has evolved in complexity, scope, and impact.

Use AI Carefully and Intentionally

Over-reliance on AI to handle so-called tedious tasks can hide a deeper issue. Over time, people stop engaging directly with problems that once forced them to think critically and work through uncertainty. That kind of mental effort is what builds real technical strength.

AI is useful and should be part of the workflow, but as a support tool rather than a replacement for understanding. Every output still needs to be interpreted, validated, and understood in context. The reasoning behind a solution remains your responsibility, regardless of how it was produced.

You Don’t Need Expensive Tools to Learn Properly

Homelabbing since 2020 has made one thing clear: effective learning is not dependent on premium software or high-end hardware. Constraints often force a better understanding of fundamentals.

Free tiers and open-source tools are widely used in industry environments. They expose the same underlying concepts as enterprise platforms, which makes the skills transferable across stacks.

Tools such as Git, GitHub, Linux, Docker, Nginx, Python, Bash, Prometheus, Grafana, the ELK stack, n8n, Proxmox, and others can all be learned without financial cost. Some require account creation, while others can be installed and run locally for experimentation and practice.

The focus is not the tool itself, but the problem it solves and the system behaviour it represents.

Stop Waiting and Start Building

At some point, planning stops being productive. Prolonged preparation without execution leads to stagnation while others gain experience through repetition and real work.

If there is intent to get serious about learning, it often requires practical trade-offs. That can include saving for an affordable, second-hand, upgradeable machine. Appearance is irrelevant. Stability and usability matter more than specifications or aesthetics.

Once a usable setup is in place, the workflow becomes straightforward: set up a lab, build and deploy something functional (don't worry about perfection), break it, recover it, and document the process. That cycle is where understanding develops.

NB: Avoid switching between tools or technologies without direction. Constantly chasing new stacks creates surface-level familiarity without depth. Sustained progress comes from selecting a small set of relevant tools and working with them long enough to understand their behaviour in real scenarios.

What is ITIL v4?

ITIL v4 is the most recent version of the ITIL framework, which has been widely adopted globally since its beginnings in the 1980s. It marks a significant shift from previous versions by incorporating modern philosophies such as Agile, DevOps, and Lean, making it much more relevant in today’s fast-paced digital world. ITIL v4 takes a holistic approach to service management, focusing on the co-creation of value through collaborative efforts between IT and the business, rather than just on the IT department as a silo. It recognises that the entire organisation must work together to deliver valuable services.

Key Components of ITIL v4

1. The Service Value System (SVS)

At the heart of ITIL v4 is the Service Value System (SVS). This is a comprehensive model that shows how all an organisation’s components and activities work together to facilitate value creation. The SVS ensures that the organisation is aligned and works together as a cohesive unit. The SVS includes several key elements:

• Guiding Principles: These are universal recommendations that guide an organisation in all circumstances, regardless of changes in its goals or strategies.

• Governance: This component ensures that policies and continual improvement are aligned with the organisation’s overall objectives and are directed by the governing body.

• Service Value Chain: A flexible operating model that outlines the key activities required to respond to demand and create value.

• Practices: These are the sets of organisational resources designed for performing work or accomplishing an objective. ITIL v4 presents 34 practices that build on the processes from previous versions.

• Continual Improvement: A recurring activity that ensures the organisation is always enhancing its services and practices. This is a core theme throughout the entire framework.

2. The Guiding Principles

ITIL v4 has seven guiding principles that help organisations adopt and adapt the framework to their specific needs. These principles are designed to be practical and applicable in any situation:

1. Focus on Value: Everything you do should directly or indirectly create value for stakeholders.

2. Start Where You Are: Don’t rip and replace your existing systems. Instead, assess what you have and how it can be improved.

3. Progress Iteratively with Feedback: Implement changes in small, manageable steps and continuously gather feedback to refine your approach.

4. Collaborate and Promote Visibility: Encourage teamwork and transparency across all levels and departments to avoid silos.

5. Think and Work Holistically: Recognise that services are part of a larger, interconnected system. Consider all components and how they interact.

6. Keep It Simple and Practical: Avoid unnecessary complexity and bureaucracy. Focus on what is essential to achieve your objectives.

7. Optimise and Automate: Streamline manual processes and use automation where it makes sense to improve efficiency and reduce human error.

3. The Service Value Chain (SVC)

The Service Value Chain is a central element of the SVS. It is an operational model that consists of six activities that organisations can use to create value in response to demand. The SVC is highly flexible and can be adapted for any scenario. Its activities are:

• Plan: Understand the organisation’s vision, current status, and objectives, and create plans for improvement.

• Improve: Continuously enhance products, services, and practices across the value chain.

• Engage: Foster relationships with all stakeholders, including customers, suppliers, and partners, to understand their needs and requirements.

• Design and Transition: Develop and implement new or changed services, ensuring they meet expectations for quality, cost, and time.

• Obtain/Build: Acquire or develop the necessary resources, whether hardware, software, or personnel, for service delivery.

• Deliver and Support: Ensure services are delivered effectively and provide support to users, managing any incidents and requests.

4. The Practices

ITIL v4 expands on the traditional processes by introducing 34 practices that encompass various aspects of service management. These practices are sets of resources and capabilities that are flexible and can be tailored to an organisation’s specific needs. They are grouped into three main categories:

1. General Management Practices: These are practices adopted and adapted for service management from general business management domains (e.g., Change Enablement, Information Security Management).

2. Service Management Practices: These were developed specifically for service management and are based on a long history of best practices (e.g., Incident Management, Service Desk).

3. Technical Management Practices: These are adapted from the technology management domain for specific technical services (e.g., Infrastructure and Platform Management).

How ITIL v4 Works in an Organisation

Implementing ITIL v4 is a journey of continuous improvement, not a one-time project. It typically involves a few key steps:

1. Assessment: An organisation begins by assessing its current service management practices to understand its strengths and weaknesses, and to identify areas for improvement.

2. Training and Awareness: Staff members are trained on ITIL v4 principles and practices to ensure a common understanding and to get buy-in from all levels.

3. Adoption of Practices: Organisations select the most relevant practices from ITIL v4 and integrate them into their existing processes, tailoring them to their specific context.

4. Continual Improvement: An organisation establishes a culture of continual improvement, regularly reviewing and refining its practices based on feedback, performance metrics, and a changing business environment.

Conclusion

ITIL v4 provides a robust framework for organisations seeking to enhance their IT service management capabilities. By focusing on value creation, adopting the guiding principles, and using the Service Value Chain and practices, organisations can align their IT services with business objectives, boost efficiency, and foster better collaboration. As the digital landscape continues to evolve, ITIL v4 remains a vital and flexible tool for organisations aiming to thrive in a competitive environment.

In the world of IT,  whether we’re on the front lines of helpdesk support, managing critical infrastructure, building automation pipelines, or writing integrations, it’s easy to prioritise doing over explaining. We troubleshoot, we fix, we deploy, and we move on. Documentation often feels like red tape, a slowdown we can’t afford.

But what if documentation isn’t a burden? What if it’s a force multiplier i.e, a way to increase the value of the work we’ve already done?

What Good Documentation Looks Like

Good documentation isn’t about writing War and Peace for every single task. It’s about creating clear, concise, and easily accessible resources that help ourselves and our colleagues understand:

• What was done: The exact steps taken to configure a system, resolve an issue, or implement a change.

• Why it was done: The reasoning behind decisions, the context of the problem, and the intended outcome.

• How it was done: The specific tools, commands, and configurations used.

• Where to find it: A centralised and organised system for storing and retrieving information.

A Real-World Process for Writing Better Documentation

Creating documentation isn’t about perfection, it’s more about clarity, consistency, and actionability. The flow below outlines a practical approach I use to create high-impact, team-friendly documentation.

Documentation can take many forms:

• Knowledge base articles.

• How-to guides.

• Workflows.

• Troubleshooting guides.

• Release notes.

• Onboarding/Off-boarding processes.

• User manuals.

• Infrastructure diagrams and playbooks for operations teams.

The key is to tailor the format and depth to suit the audience and purpose   without compromising clarity.

The Hidden Power of Documented Processes

Just as analysis paralysis can stem from a desire to “get it right,” the reluctance to document can sometimes come from a feeling that “it’s faster if I just do it myself.” While this might be true in the short term, it creates significant long-term risks.

Preventing the Single Point of Failure:

One of the most critical benefits of thorough documentation is its ability to mitigate the risk of a single point of failure. Imagine a scenario where only one person on your team knows how to troubleshoot a critical system or perform a key deployment. What happens when that person is unavailable due to illness, vacation, or a change in employment?

Suddenly, the team is scrambling, productivity grinds to a halt, and stress levels skyrocket. This is where documentation acts as a vital safety net. By clearly outlining processes and solutions, we empower the entire team to:

• Troubleshoot independently: When issues arise, well-documented procedures allow other team members to diagnose and resolve problems without relying solely on the “expert.”

• Onboard new team members efficiently: Comprehensive documentation provides a valuable resource for new hires to quickly get up to speed on systems and processes.

• Maintain consistency: Documented standards and procedures ensure that tasks are performed consistently, reducing errors and improving reliability.

• Share knowledge and learn from each other: Documentation becomes a living repository of team knowledge, fostering collaboration and continuous learning.

• Reduce reliance on tribal knowledge: Tacit knowledge held only by individuals is a significant risk. Documentation helps to codify this knowledge and make it accessible to everyone.

My Journey Towards Documentation Discipline

Like many, I used to view documentation as a necessary evil. It felt time-consuming and often got pushed to the bottom of the priority list. However, after experiencing firsthand the chaos and frustration caused by a lack of documentation, I’ve come to see it as an indispensable part of effective IT practice.

I’ve started making a conscious effort to document as I go, even for seemingly small tasks. I’ve also championed the creation of a centralised knowledge base for my team. The initial investment of time has already paid dividends in terms of reduced support requests, faster troubleshooting, and a more resilient team.

A Call to Document: Empower Yourself and Your Team

It’s time we shift our perspective on documentation because it’s an investment in our collective knowledge, our team’s resilience, and our own future success.

Just as we challenged ourselves to embrace “comfortable incompletion” in the pursuit of progress, let’s commit to embracing consistent and clear documentation. It’s a simple yet powerful way to prevent bottlenecks, empower our colleagues, and ensure that the knowledge we gain doesn’t walk out the door with any single individual.

Start small. Document one key process this week. Share your knowledge. You’ll be surprised by the positive impact it has on yourself and your team.🙂

This guide breaks down those differences clearly, and more importantly, shows why an old desktop or laptop can still become a powerful asset in a home lab.

Desktops: The Personal Productivity Machine

What is a Desktop?
A desktop computer is designed for individual use. It’s your daily driver for tasks like browsing, editing documents, gaming, content creation, or video conferencing. It prioritises user experience, responsiveness, and visual performance.

Typical Hardware Features:

• CPU: High-clock-speed processors like Intel Core i5/i7/i9 or AMD Ryzen  which is great for single-threaded workloads

• RAM: 8–32GB (non-ECC), optimised for general productivity

• Storage: Fast SSDs for OS/apps + optional HDDs for data. Usually no RAID

• GPU: Often dedicated, supporting gaming, design, and media workloads

• Networking: Single Gigabit Ethernet port and Wi-Fi

• Redundancy: Minimal—hardware failure usually means downtime

• Form Factor: Towers, small form factor (SFF), or all-in-one

• Operating Systems: Windows, macOS, or Linux distros with a GUI

Common Use Cases

• Browsing, email and office work

• Gaming and creative content

• Media streaming and light personal hosting

• Development and learning environments

Laptops: Portable, But Compromised

What is a Laptop?

A laptop delivers desktop-like functionality in a portable form. It’s designed for mobility, not sustained performance or long-term uptime.

Hardware Characteristics

• CPU: Power-efficient versions of desktop processors

• RAM: Typically 8–32GB, often soldered or limited in upgradeability

• Storage: Usually a single SSD/NVMe slot

• GPU: Integrated or lower-tier dedicated GPU.

• Networking: Wi-Fi primary, sometimes Ethernet (less common in newer models).

• Redundancy: None.

• Battery: Built-in UPS equivalent, but not suited for continuous 24/7 operation

• Form Factor: Compact, all-in-one design

• Operating Systems: Same as desktops

Common Use Cases

• Mobile productivity and remote work

• Learning and experimentation

• Remote administration of servers

• Light-duty home lab workloads

Servers: Built for Reliability & Scale

What is a Server?
A server is purpose-built to deliver services to other systems over a network. It’s designed for continuous operation, high reliability, and scalability under load. This is where critical infrastructure lives—web apps, databases, authentication systems, and more.

Typical Hardware Characteristics

• CPU: Multi-core, multi-socket processors (Intel Xeon, AMD EPYC)

• RAM: 64GB to 1TB+ with ECC for data integrity

• Storage: RAID arrays, hot-swappable drives, enterprise-grade disks

• GPU: Minimal or none unless required for specialised workloads

• Networking: Multiple NICs, often 10GbE+, with redundancy and bonding

• Redundancy: Dual PSUs, redundant cooling, failover systems

• Form Factor: Rack-mounted or enterprise towers (loud, heavy, and built for data centres)

• Operating Systems: Ubuntu Server, Debian, RHEL, and others
  Note: I’m not a big Windows fan so you won’t be seeing that much content relating to Windows OS, you’re most welcome 😄).

Common Use Cases

• Hosting web applications and APIs

• Running databases and storage systems

• Virtualisation and container platforms

• Identity services (LDAP/AD), backups, and monitoring

The Key Difference

A desktop or laptop is built for one user, interactive workloads, and visual output.
A server is built for many users, continuous workloads, and service delivery.

Turning Desktops and Laptops into Home Lab Servers

I came to find that in resource-constrained environments, repurposing a desktop or laptop as a home lab server is a practical and effective approach which I've been doing since 2020.

• Low upfront cost: Leverage hardware you already own instead of investing in new equipment (at least for now)

• Reduced power consumption: More efficient than enterprise gear, especially where electricity costs are high

• Hands-on learning: Ideal for building real-world skills with Linux, containerisation, and virtualisation platforms such as Docker and Proxmox

Practical Repurposing Tips

When converting a desktop or laptop into a server, treat it like a production system with the following best practices:

Optimisation

• Remove unnecessary peripherals (webcams, audio devices)

• Disable unused hardware in BIOS

• Replace GPU (if unused): Lower idle power, less heat

Power & Stability

• Use a UPS  especially in power-unstable regions(load shedding)

• Configure automatic power-on after outages in BIOS

• Clean regularly  as dust kills airflow and shortens lifespan

Cooling & Noise

• Improve airflow or run side-panel open

• Monitor thermals under load

Understand the Limitations

• Software RAID instead of hardware.

• Accept lack of ECC RAM  -  mitigate with backups.

• No hot-swap? Keep backups and spare parts.

Final Thoughts
A desktop/laptop is your personal workstation, responsive and graphics-ready. A server is designed for non-stop, multi-user workloads. But when approached intelligently(do your research), a desktop/laptop can be used as a lab-grade server  giving you a platform to learn, experiment, and even deploy services that you’d use in the real-world.

A Real Example

This entire philosophy isn’t theoretical.

Below are some pictures of a Dell Latitude 5500 (8th Gen Core i5), that I purchased in July 2024 for just 750 ZAR, has been running Proxmox VE reliably ever since.

It started with:

• 256GB NVMe SSD

• 4GB RAM

And was gradually upgraded to:

• 512GB NVMe SSD

• 32GB RAM

It’s neither pretty (or is it? check the last picture), nor does it look like a “real” server. However, it works and that's what matters most.

My creative work

In constrained environments—whether limited by budget, power, or access to enterprise hardware—waiting for the “ideal” setup only slows progress.

Start with what you have.
Observe how systems behave under real conditions.
Build something that works.

That repurposed machine on your desk may not look like enterprise infrastructure—but the experience you gain from running, breaking, and improving it is far more valuable than idle hardware sitting in a rack.

Virtualisation: The Power of the Virtual Machine

What it is:
At its core, virtualisation is the technology that allows you to create software-based, or “virtual,” versions of computing resources, such as servers, storage devices, networks, and even operating systems. Imagine having a single powerful physical server, and being able to run multiple, independent “virtual machines” (VMs) on it, each behaving like a completely separate physical computer.

This magic is performed by a piece of software called a hypervisor. The hypervisor sits directly on the physical hardware (Type-1, or bare-metal, like Proxmox VE(my favorite) or VMware ESXi) or on top of an existing operating system (Type-2, or hosted, like VirtualBox or VMware Workstation). It allocates the physical resources (CPU, RAM, storage, network) to each VM and manages their execution, ensuring they run in isolation from each other. Each VM includes its own operating system (the “guest OS”) and applications.

Problems it solves:
Before virtualisation, deploying a new application often meant dedicating a physical server to it which led to:

• Underutilisation of hardware: Most servers are not constantly running at 100% capacity, meaning significant computational power was often wasted.

• Server sprawl: A growing number of physical servers meant increased power consumption, cooling costs, and physical space requirements.

• Deployment complexity: Setting up a new server, installing the OS, and configuring applications was a time-consuming process.

• Resource conflicts: Different applications on the same physical server could have conflicting software dependencies, leading to instability.

• Disaster recovery challenges: Recovering a failed physical server and its applications could be a lengthy and complex ordeal.

Virtualisation directly addresses these issues by:

• Maximising hardware utilisation: Multiple VMs can share the same physical hardware, significantly increasing the return on investment for server infrastructure.

• Reducing physical infrastructure: Fewer physical servers mean lower power consumption, reduced cooling costs, and a smaller data center footprint.

• Faster provisioning: VMs can be quickly cloned, deployed from templates, or spun up on demand, drastically reducing deployment times.

• Enhanced isolation: Each VM operates in its own isolated environment, preventing conflicts between applications and ensuring stability.

• Improved disaster recovery: VMs can be easily backed up, replicated, and restored, leading to quicker recovery times in the event of hardware failure or data loss.

Containerisation: The Lightweight Revolution

What it is:
Containerisation is a more lightweight form of virtualisation that packages an application and all its dependencies (code, runtime, libraries, configuration files) into a single, self-contained unit called a “container.” Unlike VMs, containers do not include a full operating system. Instead, they share the host operating system’s kernel.

A “container engine” (like Docker) manages these containers, providing the necessary isolation and resource management. Think of it as a highly efficient, portable, and isolated environment specifically for running applications.

Problems it solves:

While virtualisation solved many problems, new challenges emerged, particularly in the realm of application development and deployment:

• “It works on my machine” syndrome: Developers often faced issues where applications ran perfectly on their local development environment but failed in testing or production environments due to subtle differences in underlying configurations or dependencies.

• Slower deployment and startup: Even with VMs, booting a full operating system for each application could be time-consuming.

• Resource overhead for microservices: As applications became more modular (microservices), spinning up a separate VM for each small service was resource-intensive and inefficient.

• Portability across environments: Ensuring an application behaved consistently across different cloud providers or on-premises infrastructure could be challenging.

Containerisation tackles these problems head-on:

• Environmental consistency: By bundling all dependencies, containers ensure that an application runs consistently from development to testing to production, eliminating environment-related bugs.

• Rapid deployment and startup: Containers start up in seconds (or even milliseconds) because they don’t need to boot an entire OS, enabling faster development cycles and quicker scaling.

• Lightweight and efficient: Sharing the host kernel means containers consume significantly fewer resources than VMs, allowing for higher density of applications on a single server.

• Unparalleled portability: A container can run on any system that has a compatible container engine, regardless of the underlying infrastructure, making it ideal for hybrid and multi-cloud strategies.

• Simplified dependency management: All application dependencies are packaged within the container, simplifying installation and preventing conflicts with other applications on the host system.

Key Differences: A Side-by-Side Comparison:

While both technologies abstract resources, their approach and scope differ fundamentally:

Conclusion

Neither virtualisation nor containerisation is inherently “better” than the other. They are powerful tools that solve different problems and excel in different scenarios.
Virtualisation provides robust isolation and the flexibility to run diverse operating systems, making it a cornerstone of cloud computing and traditional server consolidation.
Containerisation, with its lightweight nature and rapid deployment capabilities, has become the de facto standard for modern, agile application development and microservices architectures.

Understanding their distinct characteristics allow us to choose the right tool for the job, building efficient, scalable, and resilient IT infrastructure in our homelabs or business.

What is ISO 27001?

ISO 27001 is part of the ISO/IEC 27000 family of standards, which focuses on Information Security Management. The standard outlines the requirements for establishing, implementing, maintaining, and continually improving an ISMS. It is designed to help organisations manage their information security risks effectively, ensuring that they can protect their data from unauthorised access, breaches, and other threats.

Key Components of ISO 27001

1. Information Security Management System (ISMS)

At the core of ISO 27001 is the ISMS, which is a systematic approach to managing sensitive information. It encompasses people, processes, and technology, ensuring that all aspects of information security are addressed. The ISMS is designed to identify, assess, and manage information security risks, providing a framework for continuous improvement.

2. Risk Assessment and Treatment

ISO 27001 emphasises the importance of risk assessment and treatment. Organisations must identify potential security risks, evaluate their impact, and determine appropriate measures to mitigate them. This process involves:

• Risk Identification: Recognising potential threats and vulnerabilities.

• Risk Analysis: Evaluating the likelihood and impact of identified risks.

• Risk Evaluation: Prioritising risks based on their significance.

• Risk Treatment: Implementing controls to manage and mitigate risks.

3. Control Objectives and Controls

ISO 27001 includes a comprehensive set of control objectives and controls that organisations can implement to address identified risks. These controls are categorised into various domains, such as:

• Access Control: Ensuring that only authorised personnel can access sensitive information.

• Asset Management: Identifying and managing information assets to protect their value.

• Incident Management: Establishing procedures for responding to information security incidents.

• Compliance: Ensuring adherence to legal, regulatory, and contractual obligations.

4. Continual Improvement

A fundamental principle of ISO 27001 is the concept of continual improvement. Organisations are encouraged to regularly review and update their ISMS to adapt to changing risks and business environments. This involves conducting internal audits, management reviews, and ongoing training for staff.

Implementation Process

Implementing ISO 27001 involves several key steps:

1. Define the Scope: Determine the boundaries of the ISMS, including the information assets to be protected.

2. Conduct a Risk Assessment: Identify and assess risks to information security.

3. Develop a Risk Treatment Plan: Outline the controls to be implemented to mitigate identified risks.

4. Implement Controls: Put in place the necessary security measures and policies.

5. Monitor and Review: Continuously monitor the effectiveness of the ISMS and make adjustments as needed.

6. Internal Audit: Conduct regular audits to ensure compliance with ISO 27001 requirements.

7. Management Review: Senior management should review the ISMS to ensure it remains effective and aligned with organisational goals.

8. Certification: Organisations can seek certification from an accredited body to demonstrate compliance with ISO 27001.

Benefits of ISO 27001

Implementing ISO 27001 offers numerous benefits, including:

• Enhanced Security: A structured approach to managing information security risks leads to improved protection of sensitive data.

• Regulatory Compliance: Helps organisations comply with legal and regulatory requirements related to information security.

• Increased Trust: Certification can enhance an organisation’s reputation and build trust with clients and stakeholders.

• Operational Efficiency: Streamlined processes and improved risk management can lead to greater operational efficiency.

• Competitive Advantage: Organisations that demonstrate a commitment to information security can differentiate themselves in the marketplace.

Conclusion

ISO 27001 is a vital standard for organisations seeking to establish a robust Information Security Management System. By understanding its framework, implementing its principles, and committing to continual improvement, organisations can effectively manage their information security risks and protect their valuable data assets. The journey towards ISO 27001 certification not only enhances security but also fosters a culture of accountability and resilience in the face of evolving threats.

If you’ve ever gone down a rabbit hole trying to find the “perfect” resolution for a challenging ticket, rewritten your troubleshooting notes five times just to make it sound right, or delayed starting a certification because you didn’t feel 100% ready, you’re not the only one. Most of us in IT have been there. It’s not laziness or lack of discipline. It’s analysis paralysis which is a common experience among professionals in all areas of IT.

This article explores how overthinking can subtly stall career growth, personal development, and technical confidence. More importantly, it offers practical strategies I’m using to break through it.

What Is Analysis Paralysis?

Analysis paralysis is a state of inaction caused by over-analysing choices, potential outcomes, or the fear of making the wrong decision. It’s often mistaken for diligence or caution, but in reality, it undermines progress.

In IT, it typically shows up as:

• Constantly switching between tools, methods, or documentation without actually resolving the issue.

• Obsessing over the “perfect” solution instead of implementing a working fix.

• Consuming endless content but producing no tangible results.

Over time, this leads to frustration, imposter syndrome, and burnout. Not from working too hard, but from overthinking for too long.

Why It’s Common in IT Roles

IT professionals, especially those who are detail-oriented, introverted, and/or self-taught are particularly vulnerable to this trap. We’re trained to anticipate failure scenarios, weigh up options, and avoid misconfiguration. However, that mindset, when applied to every single task, can become counterproductive.

Contributing Factors:

• Perfectionism: The belief that only flawless work is worth sharing or implementing.

• Fear of failure: Especially in front of a user or a manager.

• Tool overload: The paralysis that comes from having too many options for a given task.

• Imposter syndrome: Feeling the need to “know more” before helping a user or starting a project.

When these factors combine, even small decisions such as choosing the best approach to a ticket or deciding on a new piece of software to test  can feel overwhelming especially when it impacts the business.

How I’m Working Through It

I haven’t completely overcome this, but I’ve developed practical strategies coupled with mindfulness that help me take consistent action while staying technically disciplined. The working methods listed below is what I‘ve been using daily in my work and personal projects.

1. Prioritise Delivery Over Perfection: Rather than waiting until something is “perfectly documented” or “fully automated,” I commit to delivering a first iteration. A working solution however basic , creates momentum, builds confidence, and uncovers genuine problems worth solving.

2. Impose Intentional Constraints: Rather than keeping all options open, an approach that often leads to decision fatigue ,  I intentionally narrow my choices. For each project, I commit to a single scripting language, one troubleshooting methodology, or one specific tool. This practice prevents me from falling into the “shiny object syndrome” trap, where chasing new technologies distracts from execution. Clear constraints reduce cognitive overhead and force deeper focus, leading to better outcomes and a more disciplined workflow.

3. Document While You Learn : Creating documentation  whether it be a ticketing system, a team wiki, or a personal notebook  forces structure into learning. It transforms passive reading into active knowledge-building. If I can explain a concept or a solution clearly, I understand it well enough to act on it.

4. Set External Accountability: Self-imposed deadlines are easy to ignore. External ones are harder. I’ve started sharing ticket progress or project updates with colleagues. It creates a gentle pressure to follow through.

5. Normalise Imperfect Output: It’s tempting to compare ourselves to polished help guides or perfectly organised repositories. But what actually earns respect in the industry is consistently turning up, visibly solving problems, and documenting the journey.

The Core Skill: Comfortable Incompletion

In an environment saturated with tools, knowledge bases, and endless updates, the most valuable skill is the ability to act without knowing everything(which is impossible anyway).

Progress usually comes from execution under uncertainty.
In other words: start first. Refine later.

A Challenge, If You’re Currently Stuck

If you’ve been delaying a project, ticket or are stuck in research mode, try this:

• Choose one task you’ve postponed.

• Ask yourself: “Realistically, how long would this take me if I focused on just getting it done?” This simple question helps cut through overthinking and gives you a rough timebox to work within. It brings clarity to what might otherwise feel vague or overwhelming.

• Use Pomofocus to help you get the ball rolling.

• DON’T be afraid to ask for help. 🙂

• Write a short summary of what you learned or struggled with.

Do this not to impress anyone, but to rewire the habit.

Conclusion

Overthinking is a symptom of caring deeply about doing things right. This same drive, when channeled into action, becomes a powerful strength.

To unlock this strength, we must shift our focus from seeking perfection to embracing progress. We can achieve this by designing, documenting, testing, and iterating, even when things aren’t perfect. By normalising building before we feel completely ready, we can transform our tendency to overthink into a powerful force for creation and innovation.

Inspired by n8n’s official documentation, this workflow ensures your Ubuntu server stays updated with the latest software patches and security enhancements  without the hassle of manual checks.

Overview

Keeping your server secure and up to date is crucial, but constantly checking for package upgrades can be time-consuming. This automated workflow streamlines the process by running a daily script that scans for available updates and instantly notifies you via email, ensuring you never miss a critical update.

How It Works

This workflow checks for upgradable packages and sends instant email notifications.

Daily Monitoring

• The workflow connects to your Ubuntu server once a day and checks for any upgradable packages.

Instant Email Alerts

• If updates are available, the system triggers an automatic email notification with details of the pending upgrades.

Getting Started

Setting up this workflow requires just two key steps:

Configuring SSH Access  -  Allow the workflow to securely connect to your Ubuntu server and check for updates.

Setting Up Email Notifications  - Enable automated alerts by providing SMTP credentials.

1. Configure SSH Access

Provide your Ubuntu server’s SSH credentials so the workflow can securely check for available updates. I’ll be using a username/password, but you can also import your private key for authentication.name/password but you can import your private key as well:

This command checks for packages that are ready to be upgraded.

2. Set Up Email Notifications

Enter your SMTP credentials to enable the system to send real-time email alerts whenever updates are available.

Testing the Workflow

Once everything is set up, it’s time to test the workflow and ensure it’s working as expected.

1. Running the Workflow

• Manually trigger the workflow in n8n or wait for the scheduled execution.

• The workflow connects to your Ubuntu server and checks for available package updates.

2. Checking the Output

• If upgradable packages are found, an email notification should be sent to your inbox.

• Verify that the email contains a list of pending updates.

3. Confirming Success

• SSH Connection Successful  - The workflow successfully accessed the Ubuntu server.

• Update Check Completed  - The script detected available upgrades.

• Email Notification Received  - An alert was delivered with the update details.

Results: The workflow ran smoothly, automatically monitoring and notifying about pending updates.

Email containing the list of packages ready to be upgraded.

Why Use This Workflow?

Stay Secure & Up to Date
Receive instant notifications about available software updates, ensuring your server remains secure and performs optimally.

Hands-Free Automation
No more manual checks  -  This workflow continuously monitors and alerts you about upgrades, saving you time and effort.

Fully Customisable
Easily adjust the check frequency and fine-tune notification settings to match your specific needs.

With this n8n-powered automation, you can focus on critical tasks while keeping your Ubuntu servers secure and up to date.

Conclusion

By setting up a workflow to monitor and notify you about available package upgrades, you can ensure your server remains secure and up to date.

This workflow is fully customisable, allowing you to adjust the frequency of checks and notification settings to fit your needs.

This setup showcases a real-world integration that streamlines incident management by ensuring downtime alerts are promptly turned into actionable tickets, reducing manual intervention and improving response times.

Prerequisites

• Before we begin, ensure you have the following:

• Docker & Docker Compose installed on an Ubuntu 22.04 server.

• A Freshdesk account (Free plan  - simply  scroll to the bottom of their website to sign up).

• A custom Freshdesk email address for ticket creation (e.g., support@yourcompany.freshdesk.com).

• SMTP credentials for sending emails from Uptime Kuma.

What is Uptime Kuma?

A self-hosted monitoring tool that allows you to track the uptime and performance of your websites, APIs, and services.

Key Features:

• Supports multiple monitoring options: HTTP, HTTPS, TCP, ICMP Ping, DNS, and more.

• Customisable alerts:

• Email, webhooks, Slack, Discord, etc.

• User-friendly web UI for viewing uptime history and logs.

• Multi-user support for team-based monitoring.

• Easy Docker deployment for quick setup.

Problem Statement

Manual system monitoring is inefficient, if your system goes down, you need to be notified immediately.

How This Automation Works:

• Uptime Kuma detects downtime and sends an alert email to Freshdesk.

• Freshdesk automatically creates a ticket based on the alert.

• An automation rule in Freshdesk ensures that:

1. The ticket priority is set to Urgent.

2. The ticket type is classified as an Incident.

3. The ticket is assigned to a specific group for streamlined handling.

4. The ticket is automatically assigned to a designated agent.

This setup removes the need for manual intervention, ensuring that critical system outages are promptly addressed by the right team. It also enhances incident response time by guaranteeing that no downtime goes unnoticed.

Step 1: Deploy Uptime Kuma with Docker Compose

Create a directory for Uptime Kuma and a docker-compose.yml file:

mkdir -p ~/uptime-kuma && cd ~/uptime-kuma

nano docker-compose.yml

Paste the following configuration in your docker-compose.yml file:

---
services:
  uptime-kuma:
    image: louislam/uptime-kuma:1  # NB: ALWAYS use pinned versions
    container_name: uptime-kuma
    restart: always

    ports:
      - "3001:3001"

    volumes:
      - uptime-kuma-data:/app/data  # persistent storage

    environment:
      - TZ=Africa/Johannesburg  # set to your local timezone
      - UMASK=0022  # file permission control

    networks:
      - kuma_network

    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:3001"]
      interval: 30s
      retries: 3
      start_period: 10s
      timeout: 5s

    logging:
      driver: "json-file"
      options:
        max-size: "10m"
        max-file: "3"

volumes:
  uptime-kuma-data:

networks:
  kuma_network:
    driver: bridge

Save and exit (CTRL+X, Y, Enter), then start the container:

docker compose up -d

Make sure uptime kuma is running:

docker ps

Container status is healthy

Access Uptime Kuma at:
http://<your-host-ip>:3001

Create your admin account:

Step 2: Adding a system to monitor

1. Click on the “Add New Monitor” button at the top-left.

2. In the “Add New Monitor” window, fill in the details:

3. Monitor Type: Choose HTTP(s) for website monitoring.

4. Name: Enter a descriptive name for your monitor (e.g., Network IP Scanner).

5. URL: Enter your website URL (e.g., [https://mylan.com].

6. Method: Select GET (default).

7. Heartbeat Interval: Set the time interval for Uptime Kuma to check your site (e.g., 30 seconds).

8. Retries: Configure how many times Kuma should retry if the check fails.

9. Notification Settings: Choose the method you want to use for your alerts, in this demo, I’m using Email(SMTP).

10. Tags: (Optional) Add tags to organise your monitors.

11. Click “Save” to start monitoring.

12. The monitor should now appear in your Uptime Kuma dashboard.

13. If the site is online, it should show a green “UP” status(screenshot below):

Step 3: Configure Notifications (Email)

1. Go to Settings > Notification.

2. Click Add New Notification and select a notification method (Email SMTP), this requires a valid user mailbox along with your SMTP provider settings.

Note: I’ve added my Freshdesk email address in the To: field.

3. Follow your email provider setup instructions and save the settings.

4. Link the notification to the service you want to monitor.

Verifying ticket creation after an outage(screenshot below)

As you can see, Uptime Kuma has successfully created a ticket. However, Freshdesk applies default settings, requiring manual updates that can be easily overlooked as more tickets come in. Let’s automate this to streamline the process.

Uptime Kuma ticket created in Freshdesk with default settings.

Step 4: Automatically Assign Tickets and Set Priority to Urgent

To ensure downtime alerts are handled efficiently, we’ll create an automation rule in Freshdesk to automatically assign tickets and set the appropriate priority.

Steps to Create the Rule:

1. In Freshdesk, navigate to Admin → Automations.

2. Click New Rule and give it a name, e.g., “Uptime Kuma Alerts”.

3. Apply the following conditions and actions:

Rule Configuration:

Event:

• When a ticket is created.

Conditions:

If Requester Email is *uptime_kuma@yourdomain.com*

• AND if Subject contains [? Down]

Actions:

• Set Type to Incident

• Set Priority to Urgent

• Assign to Group: Technical Support

• Assign to Agent: Luqmaan

Note: Before creating this rule, identify a consistent part of the subject line that never changes (e.g., *[? Down]*). First, test how Uptime Kuma formats its email subjects by allowing it to generate a ticket. Then, use that fixed pattern in your rule to ensure accuracy.

After previewing, saving, and enabling the rule, your configuration should look like this:

You can create multiple rules to customise ticket handling for different services, ensuring that only specific alerts have predefined priorities.

Final Testing

The automation is now in action. After testing, the rules worked exactly as expected where tickets were created with the correct priority, type, and assignments. Your system is now set up for seamless incident management.

Our automation rules are now in action, ensuring immediate response when a critical system goes offline.

Taking It a Step Further

To fully automate the incident lifecycle, feel free to create another Freshdesk automation rule that automatically closes tickets when Uptime Kuma detects the service is back online. Since Uptime Kuma raises a separate alert when the system recovers, you can use a similar rule to match the subject line and set the ticket status to Closed.

Conclusion

Integrating Uptime Kuma with Freshdesk creates a basic incident workflow where downtime is detected, a ticket is generated, and ownership is assigned without manual handling.

This reduces the need for constant monitoring and keeps incident tracking consistent.

The same approach applies beyond this specific setup. The core value is in understanding how systems can communicate, trigger actions, and remove manual steps from operational workflows.

The Architectural Differences Between Type 2 and Type 1 Hypervisors

VirtualBox operates as a Type 2 hypervisor, similar to VMware Workstation. It requires an underlying host operating system to function. This architecture inherently introduces a layer of software abstraction between the virtual machines and the physical hardware. Hardware resource allocation is brokered through the host operating system kernel. When running multiple intensive virtual machines concurrently, this brokering process creates noticeable performance bottlenecks. Specifically, I experienced significant latency with disk I/O operations and restricted network throughput, even when the underlying physical hardware had ample resources available.

Conversely, Proxmox VE operates as a Type 1 bare metal hypervisor based on Debian Linux. It installs directly onto the hardware, bypassing the need for a separate desktop host operating system. This architecture allows the hypervisor to allocate CPU cycles, memory, and storage directly to the virtual machines. The reduction in software overhead translates directly into measurable improvements in performance, lower system latency, and highly efficient resource utilisation. This bare metal approach is critical when simulating production environments accurately for application development and testing.

Integrating Kernel based Virtual Machines and Linux Containers

A primary technical driver for adopting Proxmox VE was its native, dual support for both Kernel based Virtual Machines (KVM) and Linux Containers (LXC). While VirtualBox is restricted to full hardware virtualisation, Proxmox VE provides the flexibility to choose the most appropriate isolation method for a specific workload.

LXC containers offer a significantly lighter footprint compared to traditional virtual machines. Because containers share the host system kernel and isolate processes via cgroups and namespaces, they consume a fraction of the CPU and RAM. Boot times are nearly instantaneous. This architecture is optimal for deploying independent microservices, database instances, or continuous integration runners where the overhead of an entire guest operating system is redundant. Managing both full KVM instances for legacy applications and LXC containers for modern, lightweight services from a unified platform has drastically improved my deployment workflow and maximised hardware efficiency.

Advanced Networking and Storage Capabilities

Beyond basic compute resource allocation, Proxmox VE excels in network and storage management. For application development, replicating complex network topologies is often necessary. Proxmox natively supports Linux bridges, Open vSwitch, and VLAN tagging. This allows for the logical segmentation of development, testing, and production simulation environments, mimicking real world network constraints and security policies.

Storage management is equally robust. While VirtualBox relies heavily on standard virtual disk images stored on a standard file system, Proxmox VE integrates deeply with advanced storage technologies. The native support for ZFS (Zettabyte File System) is particularly advantageous. ZFS provides software defined RAID, continuous integrity checking, and instantaneous snapshots. The ability to take immediate, block level snapshots of a database server before running a risky database migration script provides a highly resilient and forgiving development environment.

Centralised Management and Automation via API

Managing a growing fleet of virtual machines via the VirtualBox GUI or basic CLI tools becomes inefficient at scale. Proxmox VE resolves this through a comprehensive web based management interface that handles clustering, storage, networking, and virtual machine state from a single control panel.

More importantly for a software development context, Proxmox VE is built around a fully functional REST API. Every action available in the web interface can be executed programmatically. This capability facilitates Infrastructure as Code (IaC) practices. By integrating tools like Terraform or Ansible, it becomes possible to define infrastructure requirements in code, version control those definitions, and provision identical development environments automatically. This level of automation is not feasible with standard desktop virtualisation tools and is a fundamental requirement for modern application development lifecycles.

Enterprise Grade Features for Development Environments

The platform also includes several enterprise grade features natively:

• Live Migration: Virtual machines can be migrated between physical nodes in a cluster without interrupting service availability, which is useful for testing high availability application architectures.

• High Availability (HA): Critical services can be configured to restart automatically on surviving nodes if a physical server fails.

• Integrated Backup and Restore: Proxmox Backup Server integration or native VZDump capabilities allow for scheduled, deduplicated backups at the hypervisor level. This ensures rapid disaster recovery without relying on guest operating system agents.

The Community and Future-Proofing

Finally, the strong and active community surrounding Proxmox VE was a significant draw. When encountering challenges or seeking best practices, the wealth of information available through forums, wikis, and documentation is immense. This vibrant ecosystem provides a sense of confidence that the platform will continue to evolve and be well-supported in the long term.

While VirtualBox remains an excellent tool for quick, single-user virtualisation on a desktop, for anyone looking to build a more robust, scalable, and efficient home lab or small-scale server environment, Proxmox VE is a clear winner. The transition was a learning curve, but the benefits in performance, flexibility, and management have been undeniable. My home lab has truly found its new, more powerful home and it’s very unlikely that I’ll be turning back.

Introduction

While keeping a physical workspace tidy is essential for focus and productivity, the same principles apply to our digital environments. Over time, I realised that having multiple browser tabs open, scattered bookmarks, and disorganised files slowed me down just as much as a cluttered desk. To streamline my workflow, I explored Homepage, a self-hosted dashboard that centralises access to all essential work resources.

Why Use a Self-Hosted Dashboard?

If you frequently juggle multiple tools, platforms, and websites, a dashboard can significantly improve efficiency. Instead of rummaging through bookmarks or typing URLs manually, everything is accessible in one place. Here’s how Homepage helped me bring order to my digital workspace:

“What’s this ‘Homepage’ you speak of?”

• It’s a lightweight, highly customisable dashboard that acts as a central hub for quick access to applications, services, and web links.

Let’s dive into it*..*

1. Deploying with Docker

Since I run most of my self-hosted services in Docker, setting up Homepage is pretty straightforward.

Here’s how you can deploy it:

# create a directory called homepage and cd into it. 
mkdir -p ~/dashboard/homepage && cd ~/dashboard/homepage

#create a docker-compose.yml file 
nano docker-compose.yml

Paste the following configuration(be sure to read the comments):

---
services:
  homepage:
    image: ghcr.io/gethomepage/homepage:v0.9.2
    container_name: homepage
    ports:
      - 3000:3000
    env_file: .env # Make sure to create this .env file in your current working directory (use touch .env)
    volumes:
      - ./config:/app/config # Homepage will create this for you.
      - /var/run/docker.sock:/var/run/docker.sock # (optional) For docker integrations, see alternative methods
    environment:
      PUID: $PUID # Set this to your user ID (you can find it by running `id -u`)
      PGID: $PGID # Set this to your group ID (you can find it by running `id -g`)
      TZ: Africa/Johannesburg # set to your own timezone
    restart: unless-stopped

2. Accessing the default dashboard

Once deployed, you can access the dashboard via [http://<your-server-ip>:3000]

Homepage has a user-friendly YAML-based configuration file, making it easy to customise layouts, themes, categories and all sorts*.*

Note: The icons we will be using are sourced from Homarr Labs Dashboard Icons, where you can explore a wide variety of icons to further personalise your dashboard.

Your default dashboard should look like this:

3. Updating the services.yaml File

Now let’s customise the dashboard with your own services.

Step 1: Locate the services.yaml file in the config directory:

cd ~/dashboard/homepage/config && nano services.yaml

Step 2: Add Your Services

Now, you can copy and paste the following configuration into the services.yaml file. The example config below will organise your dashboard with categories for project management, automation, cloud services, and networking but feel free to customise it according to your needs:

services:
  - Project Management:
      - Asana:
          icon: https://cdn.jsdelivr.net/gh/homarr-labs/dashboard-icons/png/asana.png
          href: http://app.asana.com
          description: Task & project management
      - Jira:
          icon: https://cdn.jsdelivr.net/gh/walkxcode/dashboard-icons/png/jira.png
          href: http://your-jira-link-here
          description: Agile project tracking
      - Notion:
          icon: https://cdn.jsdelivr.net/gh/walkxcode/dashboard-icons/png/notion.png
          href: http://your-notion-link-here
          description: Notes, docs, and collaboration

  - Automation & Workflows:
      - n8n:
          icon: https://cdn.jsdelivr.net/gh/walkxcode/dashboard-icons/png/n8n.png
          href: http://your-n8n-link-here
          description: Workflow automation

  - Cloud Services:
      - Azure:
          icon: https://cdn.jsdelivr.net/gh/walkxcode/dashboard-icons/png/azure.png
          href: http://portal.azure.com
          description: Microsoft cloud platform
      - Microsoft 365:
          icon: https://cdn.jsdelivr.net/gh/homarr-labs/dashboard-icons/png/microsoft-365.png
          href: http://your-microsoft-365-link-here
          description: Cloud productivity suite
      - SharePoint:
          icon: https://cdn.jsdelivr.net/gh/homarr-labs/dashboard-icons/png/microsoft-sharepoint.png
          href: http://your-sharepoint-link-here
          description: Document management & collaboration

  - Networking & Proxy:
      - Nginx Proxy Manager:
          icon: https://cdn.jsdelivr.net/gh/walkxcode/dashboard-icons/png/nginx-proxy-manager.png
          href: http://your-nginx-proxy-manager-link-here
          description: Reverse proxy & SSL management

Step 3: Save and Close the File

Save and close the file (in nano: press Ctrl + O, Enter to save, then Ctrl + X to exit).

Step 4: Reload the page or restart the container:

# make sure you're in the homepage directory
docker compose restart

Tools and services all neatly organised into categories.

4. Adding a Background Image

Homepage allows you to easily add a custom background image via the settings.yaml file. This is a great way to personalise your dashboard further. Follow these steps to add your background image:

Step 1: Locate the settings.yaml file:

cd ~/dashboard/homepage/config && nano settings.yaml

Step 2: Add the Background Image Setting:

background:
  image: https://images.unsplash.com/photo-1502790671504-542ad42d5189?auto=format&fit=crop&w=2560&q=80

You can also adjust filters (blur, brightness, saturation) to achieve the look you want. These settings are based on Tailwind CSS classes, so you can use the values described in the Tailwind CSS documentation.

P.S I’m no expert in this regard, just following the documentation 🙂

For more detailed information on background image settings, including filter options, check out the Homepage docs and Unsplash (make sure to copy the image URL when referencing it in your settings.yaml file):

Step 3: Save and Close the File

Step 4: Restart Homepage:

docker compose restart

Conclusion

Just as a tidy desk improves focus, an organised digital environment boosts productivity.

Don’t shy away from exploring more customisations, integrations, and features to truly tailor your dashboard to fit your needs. The possibilities are endless, and with Homepage, you have the control to make your workspace as productive and personalised as you want it to be.

Have you ever considered self-hosting your own apps but got overwhelmed by endless Docker commands, YAML files, and troubleshooting? You’re not alone. While the reward of getting everything to work is great, the journey can be frustrating. I know the pain of trying to set up a simple service, only to hit roadblocks that eat up hours of time.

That’s where Runtipi comes in. It eliminates the hassle and lets you deploy self-hosted apps with ease, even if you’ve never touched Docker before(you’re missing out though 😄).

What is Runtipi, and Why Should You Care?

Runtipi simplifies self-hosting by handling container management, reverse proxy setup, SSL certificates, and app installations , all from an easy-to-use web dashboard. No need to get lost in config files or manually install dependencies. Just choose an app, hit install, and you’re good to go.

Who’s Runtipi For? (Spoiler: Almost Everyone 🙂)

1. Newbies Who Want a Frictionless Start

Want to self-host without feeling like you need a degree in DevOps? Runtipi has your back.

2. Techies Who Don’t Want to Waste Time

You know your way around a terminal, but you don’t always have time to manually configure docker-compose.yml files for every app.

3. Home Lab Enthusiasts Who Value Simplicity

Tinkering is fun, but spending hours debugging container issues is the worst. Runtipi keeps things simple so you can spend more time USING your apps.

Getting started:

Step 1: Installing Runtipi

Run this single command on your Linux server:

curl -L https://setup.runtipi.io | bash

Step 2: Open the Web Dashboard

Once installed, navigate to http://your-server-ip in your browser to access the Runtipi web dashboard (it uses the default HTTP protocol, so there’s no need to specify a port).

Step 3: Demo

For a quick overview, check out the demo here. Note that during this demo, I wasn’t prompted to set up an account, as I had already tested the setup prior to posting this blog. If you’re setting it up fresh, you might be asked to create an account, which is part of the usual process.

Step 3: Deploy an App

Choose any app from the list and install it with just one click. It’s that easy! Of course, you can always add extra layers of security if you want.

Example of how easy it is to install an app.

Runtipi Makes Self-Hosting Easier, But Challenges are Worth Embracing

While Runtipi simplifies the process of deploying self-hosted applications with its one-click install feature, it’s important to remember that there’s value in tackling challenges. Efficient workflows are essential, but embracing complex problems and finding innovative solutions also leads to growth. This setup makes it easier for everyone, from newcomers to seasoned pros, but don’t shy away from opportunities to expand your skills by tackling more intricate tasks.

Ready to Give It a Shot?

Head over to Runtipi’s official website and see for yourself. Self-hosting doesn’t have to be complicated! 🙂🕺💃

Introduction

When the shift to hybrid and remote work took place during COVID, I found myself working from home more often than not. While this offered flexibility, it also presented the unexpected challenge of keeping my workspace tidy and organised. Over time, I discovered just how much my physical environment affected my focus, productivity, and overall well-being.

In this blog, I’ll share my personal experience with maintaining an organised workspace, the negative impact of clutter, and how I extended this organisation into my digital workflow.

Note: Part 1 is aimed at a general audience, but Part 2, which will be published in my upcoming blog, is more intended for a technical audience or anyone curious about exploring the technical side of things. In Part 2, we’ll dive into setting up Homepage, a self-hosted dashboard to help streamline navigation across work tools so stay tuned! 🙂

Why a Tidy Office Space is so important

A clean workspace isn’t just about aesthetics; it directly impacts productivity and mental clarity. Here’s how keeping an organised office has personally helped me and how it can benefit you:

1. Increased Productivity

A clutter-free desk means fewer distractions, allowing for deeper focus. When everything is in its place, you don’t waste time searching for documents, cables, or notes.

2. Reduced Stress and Anxiety

At one point, my workspace became overwhelming. Papers, filled with mostly scribbled notes and research books I use, began to pile up. Cables were tangled (and still are to some extent, though I’m making progress with better cable management 🙂), and my desk just felt chaotic. After decluttering, I immediately noticed a reduction in stress.

Studies show that cluttered environments contribute to anxiety, and I can certainly attest to that (Verywell Mind).

3. Better Time Management

Once I organised my space, I realised how much time I had been wasting searching for misplaced items. Keeping things tidy naturally led to better time management.

4. Improved Professionalism

Working remotely means being on video calls often. A clean background not only makes a strong impression but also reflects an organised approach to work.

5. Better Physical Health

Dust and clutter can lead to allergies and poor air quality. Cleaning regularly improved my workspace’s air quality, which in turn boosted my energy levels.

The Negative Impact of a Cluttered Office

From my experience, a disorganised office can lead to:

• Reduced efficiency  - Wasting time searching for things.

• Mental overload  - Clutter can overwhelm your brain, making it harder to focus.

• Missed deadlines  -  Important tasks get buried in the chaos.

• Increased frustration  - A messy environment can create unnecessary stress.

By tidying up my workspace(both physical and digital), I felt more in control of my day.

The initial plan proposed by the team was entirely manual. We were going to create the Microsoft accounts with temporary passwords, divide the user list into batches, and have the engineering team manually share the credentials one by one via a password manager.

With a workload full of higher-priority tasks, spending a day manually distributing credentials felt like a poor use of time. The goal was to find a secure way to handle distribution without the manual overhead.

Scripting the Process with Python and GAM CLI

Instead of generating and distributing secure links, I used an environment users were already authenticated into: their existing Google Drive.

The approach was straightforward. Generate the credentials, write them to a per-user text file, and upload each file directly into the corresponding Google Drive account under the appropriate ownership.

Generating the Data

The first step was preparing a clean CSV mapping staff to their new email addresses and temporary passwords. Simple scripts often fail when dealing with multi-part surnames, so I used a small Python script to parse the names.txt file, normalise the formatting, and generate a 16-character temporary password for each user.

import csv
import random
import string

# Generate a normalised email using first initial + last name and a random domain
def generate_email(first_name, last_name):
    domains = ["tech-journey.co.za", "example.com", "test.com", "company.com"]
    username = f"{first_name[0].lower()}{last_name.lower()}"
    username = ''.join(e for e in username if e.isalnum())  # sanitize username
    return f"{username}@{random.choice(domains)}"

# Generate a 16-character password using letters and special characters
def generate_random_password():
    characters = string.ascii_letters + "!@%^$&*#"
    return ''.join(random.choices(characters, k=16))

# Read and clean input names
with open('names.txt', 'r') as file:
    names = file.readlines()

data = []
for name in names:
    name = name.strip()
    if not name:
        continue  # skip empty lines

    parts = name.split()
    if len(parts) < 2:
        print(f"Skipping invalid line: {name}")  # enforce first + last name
        continue

    first_name = parts[0]
    last_name = ' '.join(parts[1:])  # support multi-part surnames

    data.append({
        "email": generate_email(first_name, last_name),
        "password": generate_random_password()
    })

# Write results to CSV with fixed schema
with open('generated_email_password_pairs.csv', mode='w', newline='') as file:
    writer = csv.DictWriter(file, fieldnames=["email", "password"])
    writer.writeheader()
    writer.writerows(data)

print("Email and password pairs added to generated_email_password_pairs.csv")

Example Output:

The script outputs a generated_email_password_pairs.csv file, which is then used in the next step.

Delivering the Credentials via GAM

With the CSV prepared, I used the GAM CLI (Google Apps Manager) to handle distribution.

GAM is an incredibly powerful command-line tool for managing G-Suite. If you haven't got it set up yet, you'll need to configure your API access and service accounts first. I highly recommend following the official GAM setup instructions to get that running.

By iterating through the CSV using a simple Bash loop, I used GAM to generate a text file containing each password and upload it directly into the user’s Google Drive root directory, assigning ownership to the corresponding account.

The Payoff

Writing and testing the script, along with the GAM commands , took a few hours. Rolling it out to 100+ users took around 15 minutes.

There was no manual copying into a password manager, no credentials passed through Slack or email, and no additional handling once the process was in place. Users signed into Google and retrieved their Microsoft credentials directly from their own drives.

The full Python script is available on GitHub here.

Getting started

• In order to create a special repository i.e having the README.md file to appear on our Github profile, we need to ensure our repo name matches our username:

• As seen in the message displayed above, we need to set the visibility of our repo to Public.

• Add a README.md file to this repository which we’ll use to showcase our skills & link our projects.

Note: Even if you don’t have any projects to showcase yet, setting up an attractive profile is still a good starting point so let’s keep going 🙂.

• Click Create repository.

Once done, it’s time to spice up our README.md file:

When clicking on Edit README or the pen (🖊️) icon, you will see an auto-generated template we can use to add our info. However, if you’re looking to make it more eye-catching, I’ve included a few sites to help you generate your Github Readme according to your needs: 🙂

Profile Readme Generator(option 1)

Profile Readme Generator(option 2)

Profile Readme Generator(option 3)

If you want to get the image URLs or GIFs, you can use your preferred search engine or even utilise ChatGPT to help generate the proper URL that you can add to your README.md file.

Another useful site to check out is Shields.io to edit static badges with customised text and colors.

Once you’re happy, go ahead and commit the changes to see how your profile looks (this is what your potential employer would be seeing and I’m sure they would be impressed 🙂):

Github profile(preview)

Below is what the code looks like so please feel free to use it and customise it according to your needs:

# Hi there, I'm [Your_Name] 👋


## About Me
As a Desktop Support Manager, I am deeply motivated to progress into more technical roles within the industry whilst actively assisting others in their career transitions. With a blend of foundational and advanced experience across various tools and technologies, I am here to share my journey, skills, and projects, aiming to inspire and support anyone seeking to maximize their potential.

## 🛠 Tools & Technologies

![AWS](https://img.shields.io/badge/AWS-232F3E?style=for-the-badge&logo=amazon-aws&logoColor=white)
![Azure](https://img.shields.io/badge/Azure-0078D4?style=for-the-badge&logo=microsoft-azure&logoColor=white)
![Google Workspace](https://img.shields.io/badge/Google_Workspace-4285F4?style=for-the-badge&logo=google&logoColor=white)
![GAM Tool](https://img.shields.io/badge/GAM-00A82D?style=for-the-badge&logoColor=white)
![imapsync](https://img.shields.io/badge/imapsync-24A1C1?style=for-the-badge&logo=imapsync&logoColor=white)
![Zoom](https://img.shields.io/badge/Zoom-2D8CFF?style=for-the-badge&logo=zoom&logoColor=white)
![Asana](https://img.shields.io/badge/Asana-FC636B?style=for-the-badge&logo=asana&logoColor=white)
![Freshdesk](https://img.shields.io/badge/Freshdesk-2B79D8?style=for-the-badge&logo=freshdesk&logoColor=white)
![Bitdefender](https://img.shields.io/badge/Bitdefender-FF1100?style=for-the-badge&logo=bitdefender&logoColor=white)
![AnyDesk](https://img.shields.io/badge/AnyDesk-EA1F24?style=for-the-badge&logo=anydesk&logoColor=white)
![TeamViewer](https://img.shields.io/badge/TeamViewer-0E8EE9?style=for-the-badge&logo=teamviewer&logoColor=white)
![Docker](https://img.shields.io/badge/Docker-2496ED?style=for-the-badge&logo=docker&logoColor=white)
![Python](https://img.shields.io/badge/Python-3776AB?style=for-the-badge&logo=python&logoColor=white)
![Bash](https://img.shields.io/badge/Bash-4EAA25?style=for-the-badge&logo=gnu-bash&logoColor=white)
![UniFi](https://img.shields.io/badge/UniFi-0559C9?style=for-the-badge&logo=ubiquiti&logoColor=white)
![Ubuntu](https://img.shields.io/badge/Ubuntu-E95420?style=for-the-badge&logo=ubuntu&logoColor=white)
![Debian](https://img.shields.io/badge/Debian-A81D33?style=for-the-badge&logo=debian&logoColor=white)
![Windows](https://img.shields.io/badge/Windows_10-0078D6?style=for-the-badge&logo=windows&logoColor=white)
![Windows](https://img.shields.io/badge/Windows_11-0078D6?style=for-the-badge&logo=windows&logoColor=white)
![macOS](https://img.shields.io/badge/macOS-000000?style=for-the-badge&logo=apple&logoColor=white)
![pfSense](https://img.shields.io/badge/pfSense-336791?style=for-the-badge&logo=pfsense&logoColor=white)
![OPNsense](https://img.shields.io/badge/OPNsense-342B0E?style=for-the-badge&logoColor=white)
![Grafana](https://img.shields.io/badge/Grafana-F46800?style=for-the-badge&logo=grafana&logoColor=white)
![Zabbix](https://img.shields.io/badge/Zabbix-00BFFF?style=for-the-badge&logo=zabbix&logoColor=white)
![OpenLDAP](https://img.shields.io/badge/OpenLDAP-2C2255?style=for-the-badge&logo=openldap&logoColor=white)
![Prometheus](https://img.shields.io/badge/Prometheus-E6522C?style=for-the-badge&logo=prometheus&logoColor=white)
![Pi-hole](https://img.shields.io/badge/Pi--hole-F60D1A?style=for-the-badge&logo=pihole&logoColor=white)
![Traefik](https://img.shields.io/badge/Traefik-24A1C1?style=for-the-badge&logo=traefik&logoColor=white)

## 🔧 Projects
Here are some of the projects I've worked on:

### [Project Name](https://github.com/yourusername/projectname)
![Project Screenshot](https://via.placeholder.com/600x400.png?text=Project+Screenshot) <!-- Replace with your image URL -->
- **Description:** A brief description of the project.
- **Technologies Used:** List the technologies used in the project.
- **Features:** Highlight key features of the project.

### [Another Project](https://github.com/yourusername/anotherproject)
![Project Screenshot](https://via.placeholder.com/600x400.png?text=Project+Screenshot) <!-- Replace with your image URL -->
- **Description:** A brief description of the project.
- **Technologies Used:** List the technologies used in the project.
- **Features:** Highlight key features of the project.

## 🌱 Currently Learning
I'm currently expanding my knowledge in:
- Advanced Docker
- Cloud Security
- Python
- Working with APIs
- Powershell

## 📫 How to Reach Me

![Contact Me](https://via.placeholder.com/1200x300.png?text=Contact+Me) <!-- Replace with your image URL -->

- **Email:** your.email@example.com
- **LinkedIn:** [Your LinkedIn Profile](https://linkedin.com/in/yourprofile)
- **Twitter:** [@yourhandle](https://twitter.com/yourhandle)
- **Blog:** [Tech-Journey](https://yourblog.com)

## 📈 GitHub Stats
![Your GitHub Stats](https://github-readme-stats.vercel.app/api?username=yourusername&show_icons=true&theme=radical)
![Top Languages](https://github-readme-stats.vercel.app/api/top-langs/?username=yourusername&layout=compact&theme=radical)

## 🏆 Achievements
![Achievements](https://via.placeholder.com/1200x300.png?text=Achievements) <!-- Replace with your image URL -->
- GitHub Star
- Open Source Contributor

## 🖥️ Setup
Here are some of the tools and environments I work with:
![Setup](https://via.placeholder.com/1200x300.png?text=Setup) <!-- Replace with your image URL -->

- **Editors:** VSCode
- **Version Control:** Git, GitHub, GitLab
- **CI/CD:** GitHub Actions

Thank you for visiting my profile! Feel free to check out my repositories and connect with me.

Well done!

We’ve covered how to enhance our Github Readme profile to showcase our skills, experience and projects effectively. It’s important to note that your README is not just a technical document but also an opportunity to share your journey which will most likely open more doors of opportunity to climb up the ladder either at your current workplace or at a new company and as an added bonus, you’re inspiring others to do the same.

In short, Google workspace is a popular business suite consisting of world class productivity & collaboration apps and tools which includes a professional business email service that lets you use your own domain name, your own email addresses in the Google ecosystem.

To get started, you need to have an existing domain or you would have to purchase one from a domain registrar, however, in this guide we’ll assume you already have one.

Once you have our domain, head to https://workspace.google.com .

Next, follow the on-screen prompts as seen below:

Create your Business name, add the Number of employees & select your Region:

In the next step, you’ll need to provide your contact info and then click Next:

Since you have an existing domain, select Yes:

You will then go ahead and add your existing domain and click Next:

As you can see, emails sent to our domain won’t be affected until you’ve set up your email with your new account:

Create a username to sign into your Google Workspace account:

After agreeing to the Ts & Cs, you’ll be asked to sign into your Google workspace account.

Next, you’ll need to verify your Identity:

After you’ve verified your number, agree to the Ts & Cs and select the 14 day free trial which requires your credit card information.

Important note: If this is for testing purposes, I would strongly suggest setting a reminder to delete your account before the trial period expires.

Now it’s time for the “fun” part 🙂

Before proceeding to step two, follow the on-screen prompt that’s instructing you to log into your Domain registrar’s website where you’ve purchased your domain from.

Next, you’ve guessed it, you need to add Google’s MX records as per the instructions seen below under your domain:

Here’s an example of what it should look like:

As per the instructions, you need to add another MX record with the priority set to 15 and the unique Verification code.

Once you’ve added these two entries, go back to the admin console and click Activate Gmail. If all is correct, you should see the following window and then click Finish:

Next steps

Now that you’ve completed setting up your Google Workspace account with your own domain, you can go ahead and create users, groups etc. and explore all the features this suite has to offer.

Overcoming these obstacles required thorough research & perseverance, qualities I strongly encourage you to embrace when confronted with similar challenges. Demonstrating resourcefulness in this manner can lead to successful outcomes as long as you don’t give up.

Purpose

Eager to get this system up & running with minimal steps involved, the goals I had in mind was being able to streamline the setup process, ensure consistency & easily reproduce the installation on multiple servers to manage my network infrastructure.

With that being said, let’s move on to the good stuff :)

Script overview:

Our script performs the following actions:

• Temporarily adding the Focal security repository to resolve unmet dependencies for libssl1.1.

• Update package lists & upgrades installed packages on our system.

• Adds the Unifi repository to the sources list for easy access to Unifi packages.

• Download the Unifi repository GPG key to verify the authenticity of the downloaded packages.

• Install MongoDB 4.4 to meet the Unifi controller’s dependencies.

• Install the Unifi controller package.

• Initiate & enables the Unifi service to ensure it runs automatically.

• Verifying the status of the Unifi service to ensure it’s running properly.

• Writes the output to the screen as well as a log file in our current directory.

Running the script:

To utilise the script, we need to:

1. Copy/paste the script into your preferred text editor.

2. Customise the script as needed(if you know what you’re doing).

3. Make the script executable by running chmod +x name_of_your_script[.sh](http://script.sh).

4. Run the script with ./name_of_your_script[.sh](http://script.sh).

5. Follow the on-screen prompts for installation.

6. Ensure port 8443 is open for Unifi controller access.
   The Unifi controller runs on port 8443 so make sure the port is open (if ufw is active, simply run sudo ufw allow 8443 && ufw reload)

#!/bin/bash

#Write the output to a log file (Optional)
LOG_FILE="unifi_installation.log"

#Set the script to exit immediately if any command returns a non-zero status
set -e

#print error message & exit
print_error_and_exit() {
echo "Error: \(1" | tee -a "\)LOG_FILE"
exit 1
}

#check whether the command was successful.
check_success() {
if [ $? -ne 0 ]; then
print_error_and_exit "$1"
fi
}

#Here we create a function to log messages which can be very useful for troubleshooting.
log_message() {
echo "\(1" | tee -a "\)LOG_FILE"
}

#Add Focal security repository temporarily to fix unmet dependencies.
log_message "Adding Focal security repository temporarily to fix unmet dependencies..."
echo "deb http://security.ubuntu.com/ubuntu focal-security main" | sudo tee /etc/apt/sources.list.d/focal-security.list | tee -a "$LOG_FILE"
check_success "Failed to add Focal security repository."
sudo apt update
check_success "Failed to update packages."

#Install dependency(update this line if any additional dependencies are required or remove or comment it out if you already have this library installed.)
sudo apt install -y libssl1.1
check_success "Failed to install libssl1.1."
sudo rm /etc/apt/sources.list.d/focal-security.list
check_success "Failed to remove Focal security repository."
sudo apt update
check_success "Failed to update packages after removing Focal security repository."

#Update package lists & upgrade installed packages
log_message "Updating package lists & upgrading installed packages..."
sudo apt update && sudo apt upgrade -y | tee -a "$LOG_FILE"
check_success "Failed to update and upgrade packages."

#Add Unifi's repository to sources list.
log_message "Adding Unifi repository to sources list..."
echo 'deb https://www.ui.com/downloads/unifi/debian stable ubiquiti' | sudo tee /etc/apt/sources.list.d/100-ubnt-unifi.list | tee -a "$LOG_FILE"
check_success "Failed to add Unifi's repository to sources list."

#Download Unifi's repository GPG key.
log_message "Downloading Unifi's repository GPG key..."
wget -qO - https://dl.ui.com/unifi/unifi-repo.gpg | sudo gpg --dearmor -o /etc/apt/trusted.gpg.d/unifi-repo.gpg | tee -a "$LOG_FILE"
check_success "Failed to download Unifi's repository GPG key."

# Install MongoDB 4.4
log_message "Installing MongoDB 4.4..."
sudo apt install gnupg -y
wget -qO - https://www.mongodb.org/static/pgp/server-4.4.asc | sudo gpg --dearmor -o /etc/apt/trusted.gpg.d/mongodb-org-4.4.gpg
echo "deb [ arch=amd64,arm64 ] https://repo.mongodb.org/apt/ubuntu focal/mongodb-org/4.4 multiverse" | sudo tee /etc/apt/sources.list.d/mongodb-org-4.4.list | tee -a "$LOG_FILE"
sudo apt update
sudo apt install -y mongodb-org
check_success "Failed to install MongoDB 4.4."

# Install the Unifi package
log_message "Installing UniFi..."
sudo apt update && sudo apt install unifi -y | tee -a "$LOG_FILE"
check_success "Failed to install Unifi."

# Start & enable the Unifi service
log_message "Starting & enabling Unifi service..."
sudo systemctl start unifi
check_success "Failed to start Unifi service."
sudo systemctl enable unifi
check_success "Failed to enable Unifi service."

# Check the status of the Unifi service
log_message "Checking the status of the Unifi service..."
if systemctl is-active --quiet unifi; then
log_message "Unifi service is running."
else
print_error_and_exit "Unifi service failed to start."
fi

# Output the web interface URL to the screen.
log_message "Unifi installation complete. Browse to https://localhost:8443/ to access the Unifi web interface."

Output & results:

After our script has finished, we should see a log file in our present working directory that provides transparency throughout the installation process:

If the script executed successfully, browse to https://<your_server_ip>:8443/ to access the Unifi web interface.

Configuring the unifi controller

Since this is a Homelab, you might have your own requirements so I won’t be diving too deep but it will be enough to get you up & running.

The first few on-screen prompts is self explanatory but I’ll add some screenshots as we go through the setup process.

Step 1 — Setting up your controller

Complete the below & click Next.

Step 2 — Sign-in options

Here I’ll be creating a local account but feel free to read up on the options listed below or check out: Connecting to and Managing Unifi Deployments.

Step 3 — Set credentials

Click Finish after filling in your credentials.

Step 4 — Configuring our network

The steps below is where we’ll set our SSID(Wifi Name) & Pre-Shared Key(Wifi Password).

Under the Advanced options, the only change I’ve made was deselecting BandSteering as not all my devices are in close range to where my access point is placed.

As you scroll down, make sure to select WPA2 as the security protocol or WPA2/WPA3 depending whether your clients supports it.

There’s a list of options you can read up on & play around with to figure out what works best for you.

After successfully creating our Network, it should look like this:

Step 5 — Adopting our unifi devices

In this example, I will be connecting a UAP-AC-PRO.

In order to adopt the device, we need to reset it by navigating to the left pane under Unifi Devices => Click to Learn More:

After successfully resetting our Unifi device/s, proceed with the adoption process & wait until it finishes.

Once done, you should see the following:

Step 6 — Testing our access point

Use your Mobile/PC to connect to your access point & run a speed test:

To view connected devices, click on Client Devices.

Well done! you’ve successfully installed & configured your Unifi controller as well as setting up your Unifi device/s.

Step 7 — Assigning a static IP Address(Recommended)

If you don’t want dynamic IPs assigned to your Unifi device/s, you can set a static one which is what I’ll be demonstrating as an optional but recommended step: There’s more options available in the Settings menu that you can adjust based on your specific requirements.

After applying the changes, it’s safe to say our Unifi controller now stands ready for deployment & offering a scalable solution to manage our network infrastructure.

Final thoughts

As technology evolves & software dependencies change, it’s essential to adapt & find innovative solutions to navigate these challenges. If you’re looking into expanding your horizons & dedicated in becoming the IT wizard your were destined to be, DON’T stop learning/exploring or back down from any challenges that could help further your career.

By sharing my experience on the challenges I encountered, I hope to empower other IT professionals or someone looking to break into the Tech industry facing similar obstacles in their IT endeavours.

With the proper tools, right attitude & determination, any obstacle can be overcome, paving the way to success in the ever-evolving landscape of technology.