Forem: Alex Umansky

How to collect system, service and kernel logs using Alloy, Loki and Grafana.

Alex Umansky — Sat, 18 Apr 2026 16:44:26 +0000

Who am I?

Hello dear users, my name is Alex Umansky aka TheBlueDrara, I'm 25 years young and I've been working in a big Neo Cloud HPC Data Center for quite a while now.

One of my biggest projects is being the eyes and ears of the DC, and as time passes I found myself adding more and more tools to my monitoring stack to be able to see as much data as I can.

And you guessed it, there are not many guides and detailed documentation out there that would help me accomplish this task.

So I decided to take the time and share my knowledge and try to make my dear readers' lives easier in setting up their own monitoring system.

Going forward, I'll be documenting and writing guides about my monitoring projects.

You can start by viewing my first monitoring guide on how to use SNMP exporter with Prometheus and Grafana to pull server and hardware health state via BMCs in an Out of Band network here

Overview

In this guide I will talk about how to pull system, service and kernel logs from the hosts on the network via in-band networking, using Alloy and Loki as our main stack, and visualize the logs with Grafana.

We will start by shallow diving into what Alloy and Loki are, our main tools to capture and make the logs usable, and continue on to deploying the tools in our environment in a containerized state.

So let's not delay any further and jump into the guide.

Note: I will not show how to deploy Grafana, as it's quite basic. To make this guide not too long I will focus only on Alloy and Loki.

Prerequisites

For this setup we will need 3 main tools. I have added a link where you can find the needed image.

Loki — grafana/loki:2.9.17 — image
Alloy — grafana/alloy:v1.11.3 — image
Grafana — grafana/grafana:12.0.0 — image

Architecture

The architecture is quite simple: Client-Server, Push-Based module.

On each node we want to monitor we need to run an Alloy container that will collect our host logs and push the logs to a main Loki server.

And one main Loki server that will listen to logs being pushed.

Grafana will query and visualize the logs from Loki.

[Host 1 + Alloy] ──┐
[Host 2 + Alloy] ──┼──push──> [Loki] <──query── [Grafana]
[Host N + Alloy] ──┘

The How To

Run a Loki Server

We will start by creating a Loki config file config.yaml.

This file is responsible for configuring where to store the logs and for how long Loki will store them.

To make it short and simple, I'll go in general over each block:

auth_enabled: false — Disables multi-tenancy; uses a default tenant.
server — Sets the HTTP port Loki listens on, the default is 3100.
common — Shared default configs for all jobs.
schema_config — Defines how data is indexed and stored from a given date.
storage_config — Specifies where chunks (actual log data) are physically written on disk when using filesystem storage. This is important — I recommend creating a volume so it won't get deleted if the container fails.
limits_config — Per-tenant limits: for example, 7-day retention.
chunk_store_config — Caps how far back queries can look, preventing reads beyond the retention window.

auth_enabled: false

server:
  http_listen_port: 3100

common:
  path_prefix: /loki
  replication_factor: 1
  ring:
    kvstore:
      store: inmemory

schema_config:
  configs:
    - from: 2024-01-01
      store: boltdb-shipper
      object_store: filesystem
      schema: v13
      index:
        prefix: index_
        period: 24h

storage_config:
  filesystem:
    directory: /loki

limits_config:
  retention_period: 168h   # 7 days
  allow_structured_metadata: false

chunk_store_config:
  max_look_back_period: 168h

Now after we created the config file, let's run the container:

docker run -d \
  --name loki \
  -p 3100:3100 \
  -v $(pwd)/config.yaml:/etc/loki/config.yaml \
  -v loki-data:/loki \
  grafana/loki:2.9.17 \
  -config.file=/etc/loki/config.yaml

Running Alloy on the host

Before running the Alloy container we need to understand how to tell Alloy how and what logs we want to pull. For that we have the config.alloy file.

The hardest part in this stack is that the config file is written in a DSL called "River", which is a Grafana config language.

But there is also a simple solution: you can use this generator to create a simple config file for your needs.

For example, you can use this file. I will break it up a little as we need to understand what we are up to.

loki.write "local_host" {
  endpoint {
    url = "http://<LOKI_SERVER_IP>:3100/loki/api/v1/push"
  }
}

loki.relabel "journal" {
  forward_to = []

  rule {
    source_labels = ["__journal__systemd_unit"]
    target_label  = "service_name"
  }

  rule {
    source_labels = ["__journal__transport"]
    target_label  = "transport"
  }

  rule {
    source_labels = ["__journal_priority_keyword"]
    target_label  = "level"
  }

  rule {
    source_labels = ["__journal__hostname"]
    target_label  = "host_name"
  }
}

loki.source.journal "read" {
  forward_to    = [loki.write.local_host.receiver]
  relabel_rules = loki.relabel.journal.rules
  labels        = { job = "log_collection" }
}

loki.write

This block creates an object to where we push the logs. We will need to give it our Loki server DNS or IP address to send the logs.

You can change the local_host to anything you like, it's just a label. We will see this nature in the other blocks too.

loki.write "local_host" {
  endpoint {
    url = "http://<Loki_Server_IP>:3100/loki/api/v1/push"
  }
}

loki.relabel

This block is all about relabeling.
When Loki receives journal logs, they will have specific initial names that start with __journal_<service_name> like __journal__systemd_unit. So to make our life easier, we create certain rules to relabel them into our own groups so we will have a simpler way to query them later.

Each rule relabels a certain log group into a target_label. You can change the value to any label you want, e.g. target_label = "ninja".

loki.relabel "journal" {
  forward_to = []

  rule {
    source_labels = ["__journal__systemd_unit"]
    target_label  = "service_name"
  }

  rule {
    source_labels = ["__journal__transport"]
    target_label  = "transport"
  }

  rule {
    source_labels = ["__journal_priority_keyword"]
    target_label  = "level"
  }

  rule {
    source_labels = ["__journal__hostname"]
    target_label  = "host_name"
  }
}

loki.source.journal

The final block is getting the input. It uses the journal's API under the hood to collect our logs.
It configures which block to send the data to, which block is used to relabel our data, and finally just a small label that is added, which will be the main label for all data coming from Alloy.

loki.source.journal "read" {
  forward_to    = [loki.write.local_host.receiver]
  relabel_rules = loki.relabel.journal.rules
  labels        = { job = "log_collection" }
}

After we created our config file, we will need to pull the Alloy image to the host. I will leave this part to you, as it differs by environment.

I will jump straight into running the container.

IMPORTANT NOTE! If using automation and deploying too many containers of Alloy at once, it may crash Loki's max streaming amount, so start with one container and then deploy the rest.

To make the Alloy container read the journal logs, we need to mount the journal logs directories and add the container root user to the group ID of the journal group of the host, so it will have permissions.

So we run this command:

Note: the journald group ID may vary, please give the parameter the correct ID. To find the ID on the host, run:

getent group systemd-journal | cut -d: -f3

docker run -d \
  --name alloy \
  --network host \
  --restart unless-stopped \
  --group-add <JOURNAL_GROUP_ID> \
  -v <Path_To_Config_File>:/etc/alloy/config.alloy:ro \
  -v /run/log/journal:/run/log/journal:ro \
  -v /var/log/journal:/var/log/journal:ro \
  -v /etc/machine-id:/etc/machine-id:ro \
  grafana/alloy:v1.11.3 \
  run --server.http.listen-addr=0.0.0.0:12345 /etc/alloy/config.alloy

Verify it works

Before moving on to Grafana, let's make sure everything is running as expected.

On the Loki host, check that Loki is ready:

curl http://<LOKI_SERVER_IP>:3100/ready

You should get back ready.

On the Alloy host, check the container logs for any errors:

docker logs alloy

If Alloy is shipping logs successfully, you can confirm Loki is receiving them by querying for our job label:

curl -G -s "http://<LOKI_SERVER_IP>:3100/loki/api/v1/labels" | grep job

If all three checks pass, you're good to go.

Grafana

From now on, you can set Loki as a Grafana data source and create dashboards for the logs.

Thank You

And that's a wrap!

Thank you so much for taking the time to read my guide — it really means a lot. I hope it saved you some of the headache I went through figuring this out, and that you now have a working Alloy + Loki stack pulling logs from your hosts.

If you spotted something that could be improved, have a question, or just want to share how your own monitoring setup looks, I'd love to hear from you in the comments.

Stay tuned — more monitoring guides are on the way.

— Alex (TheBlueDrara)

How to Monitor Network Device Health Using SNMP Exporter and Prometheus

Alex Umansky — Sun, 16 Nov 2025 17:22:55 +0000

The Art of Monitoring Your Network

Hello dear tech priest readers. My name is Alex Umansky, aka TheBlueDrara, and I welcome you to a small and simple guide I made about monitoring the different devices on my network.

This guide was inspired by a challenge I had to overcome on one of my projects.

I have been tasked to monitor the health state of different devices like servers and switches on my network using Prometheus and Grafana as my main monitoring tools.

So let’s jump right into the fun.

Overview

To begin with, let's start with a short overview of what we are going to learn here.

We will start by shallow diving into what the SNMP protocol is, and since we are using Prometheus as part of our stack for monitoring, we will focus on learning how to use and deploy the SNMP exporter with which we will be able to pull the needed metrics from our devices.

Prerequisites

For the pre-setup, we will need to install and acquire some tools and resources for our work.

We will need:

Docker
SNMP_exporter Docker image, you can get it here
SNMP_generator, using this GitHub repository and create the image from the Dockerfile here
Prometheus
Grafana
snmp-mibs-downloader
snmp
git

sudo apt-get install -y docker-ce snmp-mibs-downloader snmp git
docker pull prom/snmp-generator:v0.29.0
docker pull prom/snmp-exporter:v0.28.0
docker pull prom/prometheus:v3.5.0 
docker pull grafana/grafana:12.0.0

Prometheus - monitoring system that collects metrics Grafana - data visualization tool

SNMP exporter - acts as the SNMP manager, sends requests to devices, and collects data

SNMP generator - helps us create the SNMP exporter config file using a textual format

snmp-mibs-downloader - allows us to install the necessary MIB files

snmp - a utility tool for commands like snmpwalk

Before we begin

Before we jump into the setup, it is important to understand how the flow of our tools works.

I promise that I will cover every detail needed in the future, but for now, let's see the flow.

grafana => prometheus => snmp_exporter => hardware devices

We will use Grafana to visualize the data that Prometheus collected.

Prometheus will scrape data from the SNMP exporter that acts as an SNMP manager sending SNMP requests to its target agents (hardware devices).

Again, don't worry, everything will become clearer in the next parts.

Let's break everything up and begin!

In this guide, I won't dive deep into what the SNMP protocol is. For the sake of understanding, I'll simplify the explanation, but if you want to dive deeper into the protocol, there are amazing documents about it that you can read here.

So what is SNMP?

SNMP is quite an old protocol that, I quote, "created a universal language allowing IT teams to decode the operational state of network hardware regardless of manufacturer."

In simple words, we can use this protocol to pull specific metrics and data from our hardware devices regardless of the different vendors.

It works in a server-client architecture, where there is an SNMP manager (our SNMP exporter) and SNMP agents that come almost always preinstalled on modern hardware and just need to be enabled.

SNMP Agent

You need to check for each vendor how to enable SNMPv3 on the device, and you should create a read-only separate user for SNMPv3 metrics and use their credentials for authentication.

Else we won’t be able to pull metrics from the device.

What is SNMP Exporter?

A tool that translates data from network devices using SNMP into a format that Prometheus can understand.

We will need it if we want to use Prometheus as our monitoring tool.

The beauty of this exporter is that you can run the service in one place and just give it a target list of your hardware devices.

The manager will send requests to the agents to collect the data.

The SNMP exporter has two main files that we need to create:

snmp.yml - config file that defines which metrics the SNMP exporter should scrape
target_list.yml - a list of targets to scrape (hardware devices, switches, servers, etc.)

How to create snmp.yml file

This file holds the configuration that tells the SNMP exporter what metrics we want to pull from the agents.

The issue is that this file needs to be written with OIDs for best results.

Note, OIDs are a numeric tree structure. Each OID is unique and represents a single metric that can be pulled from a device.

To handle this problem, we will use the official SNMP generator.

It will take a bit of setup, but it should be simple.

How to set up the SNMP generator

Start by pulling the official generator repository and building the Docker image.

git clone https://github.com/prometheus/snmp_exporter.git
cd snmp_exporter/generator
docker build -t <image_name> -f generator/Dockerfile .

Now we need to provide the container with two things:

The generator.yaml file
The MIB files

Note, MIBs are text files that help us translate human-readable formats into OIDs.

Creating generator.yaml file

The generator config file is a YAML file that configures what metrics we want to pull that is written in a human-readable text format.

Here we just give it a whole module to "walk" (scrape).

We can also specify which exact metrics we want from the module.

In this part, you start to shine — pull the exact metrics you need for your project.

For a simple example, we will use the IF-MIB module.

IF-MIB: network interfaces. SNMPv2-MIB, SNMPv2-SMI, SNMPv2-TC: standard objects, types, counters HOST-RESOURCES-MIB: CPU load, memory, storage.

cd ./snmp_exporter/generator
vim generator.yml

In this example, I want to pull two metrics from the IF-MIB module:

ifOperStatus
ifAdminStatus

The status of admin ports and operational status of ports of a switch.

  if_mib:
    walk:
      - IF-MIB::ifXTable
    overrides:
      IF-MIB::ifOperStatus:          { ignore: false }
      IF-MIB::ifAdminStatus:         { ignore: false }

Downloading MIBs

Now that we have our generator.yaml file, let's install our MIBs.

For that, we will use the snmp-mibs-downloader package.

Run this command to install the default MIBs (there are vendor-specific MIBs with specific metrics).

download-mibs

It will download the MIBs we need to this path: /usr/share/snmp/mibs/

Now let's generate our snmp.yml file.

We will create a directory that will contain our exact MIBs that we used in the generator file.

cd /snmp_exporter/generator
mkdir -p mibs
cp <MIBS> /mibs

Running the container

We will mount the two files to the container and configure two environment variables,

Which MIBs we used and where they are located in the container.

docker run --rm -v "$PWD:/work" -w /work -v "$PWD/mibs:/mibs:ro" -e MIBDIRS="/mibs" -e MIBS="<MIBS>" snmp-gen generate

We should now get an output of an snmp.yml file.

If not, the container will show an error and what is missing to complete the task.

Choosing SNMP version

We are not done yet! One small last thing — what version of SNMP should we use?

To choose what version we will use, we will need to set up an authentication code for our snmp.yml file.

In this guide, we will use SNMPv3 as it’s more secure.

For that, we need to add a small block of code to our snmp.yml file for authentication to our device.

auths:
  switches: # the name of the auth
    version: 3
    username: '<switch_username>'
    security_level: authPriv
    auth_protocol: SHA
    password: '<switch_password>'
    priv_protocol: AES
    priv_password: <PrivateProtocol_password>

Configuring target_list.yaml file

After we finally have the snmp.yaml file, we need a target list — which devices do we want to scrape?

In the target list, we will give a list of targets, what module we used, and what authentication from the snmp.yml file.

- targets: &switches_targets
    - 192.168.0.10
  labels: { module: 'if_mib', auth: 'switches' }
- targets: *switches_targets

Prometheus task

For Prometheus, we need to create a config file that will configure a scrape task from its exporters.

global:
  scrape_interval: 15s

scrape_configs:
  - job_name: 'snmp'
    scrape_interval: 30s
    scrape_timeout: 25s
    metrics_path: /snmp
    file_sd_configs:
      - files:
          - /prometheus/snmp_targets_list.yaml
        refresh_interval: 1m

A small recap of what we did so far and how everything comes together:

We installed the tools we need
We pulled all the necessary Docker images
We generated an snmp.yml using a generator image; for that, we downloaded the MIBs and configured a generator.yaml for our needs
We created a target list for the SNMP exporter
We enabled SNMPv3 on our hardware and created a read-only user for SNMPv3 metrics
We created a Prometheus scraping task

Now let's deploy all our services and make the config files take effect.

The Setup

Using Docker Compose, let's deploy our services with ease.

services:
  prometheus:
    image: prom/prometheus:v3.5.0
    container_name: prometheus
    ports:
      - "9090:9090"
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml
      - ./prometheus-data:/prometheus
    networks:
      - monitoring
    restart: always

  grafana:
    image: grafana/grafana:12.0.0
    container_name: grafana
    ports:
      - "3000:3000"
    volumes:
      - grafana-storage:/var/lib/grafana
    networks:
      - monitoring
    restart: always

  snmp-exporter:
    image: prom/snmp-exporter:v0.28.0
    container_name: snmp-exporter
    network_mode: "host"
    restart: always
    volumes:
      - ./snmp.yml:/etc/snmp_exporter/snmp.yml:ro
    command: --config.file=/etc/snmp_exporter/snmp.yml

volumes:
  grafana-storage:

networks:
  monitoring:
    external: true

Note, that SNMP does not work well with NAT, so in Docker Compose we set it to use Host network mode.

Now we will be able to reach promethuies UI by searching

http://<IP_of_service>:9090

Here we should see that the task we created able to pull the metrics we configured.

How to test if we enabled the SNMP agent

We can use the MIBs to run commands with the Net-SNMP tool like "snmpwalk" to scrape a device manually.

For that, we need to configure the path to the MIBs.

Edit this config file:

/etc/snmp/snmp.conf (system-wide defaults)

And add these lines.

They point to the MIBs directory and specify which MIBs are present and should be used.

mibs +All
mibdirs /usr/share/snmp/mibs:/usr/share/snmp/mibs/ietf:/usr/share/snmp/mibs/iana:/usr/share/snmp/mibs/net-snmp

If we did everything correctly, we should be able to visit Prometheus and see the task pulling metrics that we configured from our devices.

An easy way to manually check if you can pull data from a device is by running an snmpwalk command:

snmpwalk -v3 -u <switch_username> -l authPriv -a SHA -A '<switch_password>' -x AES -X '<PrivateProtocol_password>' <IP_of_device> -m <Module_name> #IF-MIB

You should see a long output of different metrics from the device.

Grafana

I will not go into building dashboards as it's an art of its own, and this guide is long enough.

I hope you enjoyed this guide. Feel free to comment and give me some feedback to keep learning and improving.

Sharing my small research and how I overcame challenges is a small gesture to the open-source community on my part, and it brings me a bit of joy.

Linux Repository Mirroring Made Simple

Alex Umansky — Sun, 07 Sep 2025 20:06:25 +0000

Mirror, mirror on the wall, apt-get won’t fail me at all

Hello dear reader, and as @silent_mobius refers to, gentle readers, welcome!

My name is Alex Umansky, aka TheBlueDrara, and I welcome you to a small and simple guide I wrote on Linux repository mirroring.

This guide was inspired by a task I received in a project where I had to localize many packages in my environment, as sooner or later the internet on my poor, poor Linux server would be cut off.

So here we are — shall we begin?

Overview

For starters, let’s understand what we are going to do here.

We will be creating a mirror of the official Ubuntu repository, so we can install packages in an offline environment.

And since not all packages come from the official Ubuntu repository, some packages will need to be downloaded manually and stored in our own repo — a so-called “flat” repository.

I’ll explain the difference between them in detail in the upcoming steps.

Prerequisites

Before we begin, we need to install some prerequisites to be able to mirror repositories and expose our local mirror so we can pull packages from our mirror server.

We will need:

apt-utils (to generate the files we need)
nginx (a web server to expose our local mirror)
debmirror (a tool to create a local Debian/Ubuntu mirror)
gnupg (to create and manage GPG keys)

apt-get update
apt-get install -y apt-utils nginx debmirror gnupg

We’ll start with the official Ubuntu mirror.

We’ll use debmirror, a tool that mirrors a remote repo using parameters and an upstream URL.

Important: This method works not only with the Ubuntu repository but also with other vendor repositories, as long as you have the repo URL and the GPG key.

Before mirroring, it’s useful to understand how Debian/Ubuntu repos are built.

They have a special file structure that we are keen to learn.

They are organized into Suites and Components.

Suites are distributions or releases of packages, for example:
- noble → The base release of Ubuntu 24.04
- noble-updates → Stable updates after the initial 24.04 release
Components are sections grouped by license/support status, such as:
- main → Official Canonical-supported open source
- restricted → Proprietary drivers/firmware
- universe → Community-maintained software
- multiverse → Non-free software

If you’re unsure what packages you need and have the storage space, you can simply mirror them all — but keep in mind the whole repo may take around ~2 TB of storage space.

Sometimes it’s better to start with a small mirror of the main component of each suite and see if you’re not missing any needed dependencies.

Creating a Debian Repository

Let’s start by creating a directory to store our repository structure:

sudo mkdir -p /storage/ubuntu

The official Ubuntu repo URL we will use is:

http://archive.ubuntu.com/ubuntu/

In this example, we’ll mirror the noble and noble-updates suites, and only the main component from each one:

debmirror /storage/ubuntu \
  --nosource \
  --progress \
  --host=archive.ubuntu.com \
  --root=ubuntu \
  --method=http \
  --dist=noble,noble-updates \
  --section=main \
  --arch=amd64 \
  --ignore-release-gpg

Note: For safer practice, remove --ignore-release-gpg and instead add the vendor’s GPG key to /usr/share/keyrings so signatures are verified.

The mirroring process may take a while depending on what you mirrored.

Repository File Structure

Before we head forward, it is important to understand the file structure of a Debian repo.

Once finished downloading, you’ll see three main directories:

project → global metadata (mostly Debian-specific, so we will set this aside for now)
dists → contains the suites like noble, noble-updates
pool → contains all the .deb packages

`pool`

A directory that holds all of our .deb packages.

They can be sorted alphabetically in directories or simply stored together.

It doesn’t matter for APT — it only depends on your preference, nice and tidy like the Inquisition of Mankind, or chaotic like the Chaos Warbands.

`dists`

This directory contains:

suite directories (different releases like noble/), and inside each suite are component directories like main/, restricted/, etc.
repository metadata files: Packages, Release, InRelease, Release.gpg

The Heart of the APT Repo

As said before, inside each dists directory there are metadata files: Packages, Release, InRelease, Release.gpg.

These files are the beating heart of the repo. They are what make APT come alive.

Like my most favorite album, Holy Diver by Ronnie James Dio (bless his soul):

“Between the velvet lies, there’s a truth as hard as steel.”

Let’s find our truth.

`Packages` file

An index file that lists all .deb packages with:

names, file paths, checksums, dependencies

This file tells the repo what .deb packages exist, what they depend on, and where they are located in the repo.

If you add or remove packages from the pool directory, you must recreate the Packages file to re-index the packages.

`Release` file

Summarizes the repository:

checksums of .deb Packages
defined distributions/components that exist in the repo
references to the index files (like Packages)
contains metadata of the repo

Every change in the repo should be accompanied by regenerating the Release file.

`InRelease` and `Release.gpg`

Signed versions of the Release file:

Release.gpg → older detached signing method
InRelease → newer inline signing method

To summarize this important section: each time you run apt-get update, you are pulling two files from a remote repo: the signed InRelease and the Packages files — so you can install the packages inside those repos.

Exposing the Local Repo

If we want to be able to pull packages from our mirror, we need to make the repo available to others.

In this example we’ll expose it with Nginx.

Let’s create a config file for Nginx:

vim /etc/nginx/sites-available/ubuntu-mirror

Add:

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

    location /ubuntu {
        alias /storage/ubuntu;
        autoindex on;
        try_files $uri $uri/ @notfound;
    }

    location /my-local-repo {
        alias /storage/my-local-repo;
        autoindex on;
        try_files $uri $uri/ @notfound;
    }

    location @notfound {
        return 404;
    }
}

Enable it and restart the service:

sudo ln -s /etc/nginx/sites-available/ubuntu-mirror /etc/nginx/sites-enabled/
systemctl restart nginx

Now the repo is available and can be sourced. We’ll touch on how to source it soon.

Creating a GPG Key

Signing your repo is not strictly necessary, but it’s a nice practice for automation and branding your repo.

If you don’t want to do this step, you can skip ahead.

To sign the repo with our own key, we use the gnupg tool.

Generate a key:

gpg --gen-key

List the key to see the PUB KEY ID:

gpg --list-keys

Signing the Repo

Remember: in each dist (suite) there are its own metadata files you need to sign.

gpg --local-user "<PUB_KEY_ID>" --yes --clearsign -o dists/<dist_name>/InRelease dists/<dist_name>/Release

gpg --local-user "<PUB_KEY_ID>" --yes --detach-sign -o dists/<dist_name>/Release.gpg dists/<dist_name>/Release

Export the key into a file so we can pass it to the clients:

gpg --armor --export <KEY_PUB_ID> > <local_repo_key_name>.asc

sudo gpg --dearmor -o /usr/share/keyrings/<local_repo_key_name>.gpg <local_repo_key_name>.asc

sudo chmod 644 /usr/share/keyrings/<local_repo_key_name>.gpg

And… you sold your soul to the devil — congrats!

Let’s continue with the great work so far.

Client Setup

When you run apt-get update, how does APT know where to pull metadata files from?

Quite simply — there is a source file that APT reads.

On the client, let’s create or edit a source file:

vim /etc/apt/sources.list.d/ubuntu.sources

Add the config of our mirrored repo:

Types: deb
URIs: http://<IP_or_DNS_of_mirror_server>/ubuntu/
Suites: noble noble-updates
Components: main
Architectures: amd64
Signed-By: /usr/share/keyrings/<key_name>.gpg

Place the GPG key where APT expects it:

mv <my_local_repo_key>.gpg /usr/share/keyrings/

Update APT:

apt-get update

APT stores the metadata it pulls in:

/var/lib/apt/lists

You can check if packages are present in the repo with:

apt-cache search <package_name>
apt-cache show <package_name>

In the newer OS versions you should use

apt show
apt search

Note: make sure there is network connectivity to the server running the local repo.

Creating a Flat Repository

But what if I want to create a local stash of random .deb packages I need from vendors, tools, or my own creations?

A flat repo is your answer.

A flat repo is super simple: just a directory that contains .deb packages plus the metadata files we learned about before (Packages and Release), all in one place.

Messy? A bit. But it works.

Create `Packages`

Because this is a flat repo, we don’t get ready-made metadata. We need to create it ourselves.

Note: these steps also work for a Debian repo, just with different paths.

cd <flat_repo_dir>
apt-ftparchive packages <flat_repo_dir> | tee <flat_repo_dir>/Packages

For a Debian repo (pool-based):

cd <debian_repo_dir>
apt-ftparchive packages ./pool | tee dists/<suite>/<component>/binary-<Arch>/Packages

Sometimes we need to compress the file:

gzip -9c Packages > Packages.gz

Create `Release`

I like to create a template I can edit later for ease of use:

cat > release.conf <<'EOF'
APT::FTPArchive::Release {
  Origin "<Custom_Origin>";
  Label  "<Custom_Label>";
  Suite  "<Custom_Suite>";
  Version "<Version>";
  Codename "<Custom_Codename>";
  Architectures "<Architecture_for_example_amd64>";
  Components "main";
  Description "<Whatever_you_wish>";
}
EOF

Now generate the file:

cd <flat_repo_dir>
apt-ftparchive -c <Path_to_release.conf> release <path_to_root_directory> > <path_to_root_directory>/Release

Sign it:

gpg --local-user "<PUB_KEY_ID>" --yes --clearsign -o InRelease Release
gpg --local-user "<PUB_KEY_ID>" --yes --detach-sign -o Release.gpg Release

Exposing a Flat Repo

In the first step we already added to Nginx the configuration to expose this local flat repo.

Client Setup for Flat Repo

The source file looks a little different here.

We remove the component part, and for the suite we just mention ./ as the root.

Don’t forget to add your repo key!

vim /etc/apt/sources.list.d/flatrepo.sources

Add:

Types: deb
URIs: http://<IP_or_DNS_of_repo>/<Repo_name>
Suites: ./
Architectures: amd64
Signed-By: /usr/share/keyrings/<Key_name>.gpg

Update APT:

apt-get update

I hope my work and writing helped a hopeless soul somewhere in the vast DevOps universe. Thank you for taking the time to read my work!

TheBlueDrara

Forem: Alex Umansky

How to collect system, service and kernel logs using Alloy, Loki and Grafana.

Who am I?

Overview

Prerequisites

Architecture

The How To

Run a Loki Server

Running Alloy on the host

loki.write

loki.relabel

loki.source.journal

Verify it works

Grafana

Thank You

How to Monitor Network Device Health Using SNMP Exporter and Prometheus

The Art of Monitoring Your Network

Overview

Prerequisites

Before we begin

So what is SNMP?

SNMP Agent

What is SNMP Exporter?

How to create snmp.yml file

How to set up the SNMP generator

Creating generator.yaml file

Downloading MIBs

Running the container

Choosing SNMP version

Configuring target_list.yaml file

Prometheus task

The Setup

How to test if we enabled the SNMP agent

Grafana

Linux Repository Mirroring Made Simple

Mirror, mirror on the wall, apt-get won’t fail me at all

Overview

Prerequisites

Creating a Debian Repository

Repository File Structure

pool

dists

The Heart of the APT Repo

Packages file

Release file

InRelease and Release.gpg

Exposing the Local Repo

Creating a GPG Key

Signing the Repo

Client Setup

Creating a Flat Repository

Create Packages

Create Release

Exposing a Flat Repo

Client Setup for Flat Repo

`pool`

`dists`

`Packages` file

`Release` file

`InRelease` and `Release.gpg`

Create `Packages`

Create `Release`