Tech Administration

A Linux gateway began dropping new connections even though CPU usage was low, memory looked healthy, disks were almost idle, and the application itself continued responding normally. The same failure was reproduced twice in a small lab and investigated using two completely different approaches. The first run relied on tools that would have been familiar to a Linux sysadmin in 2008: top, vmstat, dmesg, proc, sysctl, netstat, and tcpdump. The second run started with Prometheus, Grafana, historical metrics, and modern observability. Both approaches eventually reached the same kernel-level problem, but the path to the answer was very different.

An uncensored ai chatbot sounds like a product category, but from an engineering perspective it describes an implementation detail badly. When an LLM refuses a request, the refusal may originate in the model weights, a system prompt, an input classifier, an output classifier, or an application policy enforced outside inference entirely.

I needed 100 disposable Linux machines for a test environment, so cloning one prepared VM looked like the fastest option. The clones received different MAC addresses, IP addresses and hostnames, booted normally and appeared as separate hosts in monitoring.

Then I started checking the identities stored inside the operating system itself. Across the whole fleet I found the same system machine ID, the same SSH host key, the same filesystem UUID, inherited cloud‑init state and the same WireGuard identity. What looked like 100 independent VMs from the outside was still one machine copied 100 times at several lower layers.

The idea appeared after a normal working evening went slightly wrong.

I opened a repository, started a build, and noticed that nearly every useful action required a connection to somebody else’s server. The source code was hosted remotely. The CI runner was remote. Package metadata came from remote registries. Test files were downloaded from object storage. API collections were synchronized through a cloud account. Documentation lived in another browser tab. Even code completion waited for a remote model.

My laptop was powerful enough to compile the project, run several databases, and heat the room better than the radiator. Still, it behaved more like a terminal connected to a collection of external services.

So I made a simple rule for one month:

The main development workflow had to remain usable with the network disconnected.

I did not try to recreate the entire Internet in Docker. Public package registries, operating system updates, and communication tools were still allowed during planned synchronization periods. But coding, commits, builds, tests, documentation, API experiments, and basic code review had to work locally.

The first assumption was that this would mostly be a Docker Compose exercise.

It was not.

The containers were the easy part. The difficult part was discovering all the invisible contracts hidden inside a normal cloud-based workflow.

Our office has roughly one hundred employees, but for a long time we had no proper help desk process. Requests arrived through email, corporate chat, phone calls, and random conversations in the hallway. It always felt as if most of the day was spent dealing with servers, networks, backups, and serious incidents.

To check whether that impression was accurate, I logged every support request for one month. I measured active work time, recorded the cause of recurring problems, tracked waiting periods, and counted how often a new request interrupted something already in progress.

Over 22 working days, I recorded 496 contacts. After merging duplicate reports related to the same issue, those contacts became 421 separate support episodes.

The most surprising result was not the total number of requests. It was the damage caused by short five‑minute tasks constantly breaking longer technical work into small, nearly useless fragments.

This article explains how I collected the data, why average resolution time is often misleading, how I automated Windows workstation diagnostics with PowerShell, and how I processed the resulting event log using Python and PostgreSQL.

How we turned a NAS control panel into an extension platform, why Log Manager was needed, and what the Plugin Template is for.

In the previous article (Mini Bucket 3.6.2: from beta to release), I showed how the panel matured to a stable state: we patched holes, separated databases, and added HTTPS.

But it’s still just a panel. SMB, FTP, and the rest are standard features found in almost any admin panel. It’s time to expand the functionality.

The best solution turned out to be: .....

Hey you. Yes you. Do you have more routers than you can reasonably explain? Do you flash custom firmware for fun? Have you ever spent an entire evening troubleshooting an issue with router, then called it “relaxing”?

Xeovo is looking for you and your router, network and technical knowledge. We are going to give an opportunity for our community members to expand guides for routers, earn money and get recognition on Hub.

Our router tutorial section has the biggest gaps. Let's change this together.

Why Debian 9, PHP 7.0, and no frameworks. And how to set up HTTPS in 5 minutes.

Foreword for those who haven't read the first article

Last time, I told the story of how I wanted to make a couple of pages for SAMBA and NFS, but ended up with a NAS control panel of 20+ pages. I named the project Mini Bucket.

Important: That version was a beta. Raw, with rough edges, but alive. Its goal was to demonstrate the concept. And people got interested. So, it needs to be polished.

Now – version 3.6.2. A ton of problems have been fixed, security has been added, a separate domain, forum, and wiki have appeared. Today, I'll walk you through the installation step-by-step with screenshots.

But first – a quick summary of what has changed. Then – pure practice.

Fair warning right away: I'm not a programmer. The code could be prettier, the architecture more elegant. But my goal was different – to make a convenient tool for myself as a system administrator. What came out came out. Don't judge too harshly, it's beta.

How it all started

I had some free time. I had an old Netgear Stora MS2000 lying around – I'd installed Debian 7 and OpenMediaVault on it back in the day. Then a disk crashed, I reinstalled Debian 9, but OMV turned out to be too heavy for this hardware.

Editing configs in the console every time was tedious. And all I really needed was SAMBA and NFS. So I thought, why bother? I'll write a couple of PHP scripts to create and edit shares.

And so Mini Bucket began.

The first two pages – and off we went

I whipped up the first two pages quickly: shares started working. Then I thought, "It would be nice to have a dashboard to see all the stats." A third page appeared – a dashboard with graphs.

Then I figured: since I've got SMB and NFS, might as well add rsync and FTP too. Added them.

Day by day, my "two-page panel" grew into a project now called Mini Bucket – NAS Control Panel.

And you know what? It actually works. On hardware where modern panels simply won't start or slow to a crawl.

What is this thing?

Mini Bucket is a web-based NAS control panel focused on resource efficiency. It runs on:

It was 10 PM on a Tuesday. An employee sent a message: "I lost my laptop. Somewhere in the city. I have no idea where it is."

Inside that laptop: access to work tools, internal conversations, probably cached authentication tokens. Potentially a way into systems that had nothing to do with the device itself.

We locked it remotely in a few minutes. No panic. No emergency calls. No incident post-mortem the next morning.

And then we just went to sleep.

That's what MDM actually is — not technology for technology's sake, but the ability to not turn a bad moment into a crisis. The difference between "we handled it" and "we need to talk about what happened."

I've run both platforms in a real production environment — 600+ users, 50+ SaaS platforms, an international software company with distributed teams across multiple timezones. This isn't a vendor comparison page. This is what I actually experienced running both, migrating between them, and managing the transition in parallel.

The question "JumpCloud or Okta?" comes up constantly in IT communities. It almost always gets the same frustrating non-answer: "it depends." That's technically true — but let me break down exactly what it depends on, and why.

There are things in the IT industry whose even existence has become a beautiful myth.

The knowledge described in this article is extremely rare, as it has previously been held by individuals with an academic degree, special training, and, most importantly, access to the necessary equipment.

How we transformed stressful manual releases into a dependable, one-click process using GitOps and automation. 50+ modules, auditors and regulators—in a single template that scaled across more than 30 services. No magic, an engineering discipline.

Hello, Habr! I once conducted a small test of virtual machines from various hosting providers and compared them with each other — it turns out that five years have passed since then. And in that test, the conditions for all servers were the same, as similar configurations were being tested.

Today I'd like to talk about how the cheapest (in the price range of 100 to 300 rubles) offers from popular hosting providers behave.

Page pruning (HOT cleanup) is an optimization allowing to efficiently remove old row versions (tuples) from table blocks. The freed space will be reused for new row versions. The only space occupied by row versions beyond the database's xmin horizon is reclaimed. This article examines the algorithm behind a similar optimization for indexes. If the xmin horizon is held back - by a long-running query or transaction - neither page pruning nor VACUUM can reclaim space, forcing new row versions to be inserted into different blocks. With the standard pgbench test, we demonstrate how significantly performance can degrade when the database horizon is held back, and we analyze the underlying causes. 

We were asked to talk about the protocol technology XHTTP in the context of XRay, VLESS, and others. You asked for it, so here it is!

First, a bit of history. The classic use of VLESS and similar proxy protocols (including with XTLS-Reality) involves the client connecting directly to a proxy server running on some VPS. However, in many countries (including Russia), entire subnets of popular hosting providers have started to be blocked (or throttled), and in other countries, censors have begun to monitor connections to 'single' addresses with high traffic volumes. Therefore, for a long time, ideas of connecting to proxy servers through CDNs (Content Delivery Networks) have been considered and tested. Most often, the websocket transport was used for this, but this option has two major drawbacks: it has one characteristic feature (I won't specify it here to not make the RKN's job easier), and secondly, the number of CDNs that support websocket proxying is not that large, and it would be desirable to be able to proxy through those that do not.

Therefore, first in the well-known Tor project for bridges, the meek transport was invented, which allowed data to be transmitted using numerous HTTP request-response pairs, thus allowing connections to bridges (proxies) through any CDN. A little later, the same transport was implemented in the briefly resurrected V2Ray. But meek has two very significant drawbacks that stem from its operating principle: the speed is very low (in fact, we have half-duplex transmission and huge overhead from constant requests-responses), and due to the huge number of GET/POST requests every second, free CDNs can quickly kick us out, and paid ones can present a hefty bill.

Hello, Habr!

Today we'll look at how to install the network packet modification utility Zapret on Keenetic routers. Unlike using it on specific devices, installing it on a router allows you to process traffic from all devices connected to your home local network (PCs, smartphones, and smart TVs).

Do you switch between Linux and Windows in dual-boot? Then you're probably familiar with this problem: you have to reconnect all your Bluetooth devices every time. Headphones, mouse, keyboard, gamepad — everything has to be reconnected.

It's scary to even think about it:
3 devices × 90 seconds × 3 switches per day × 250 days = 56 hours wasted per year.

I spent a month solving this problem and wrote BlueVein — a utility for automatically synchronizing Bluetooth keys between operating systems.

Throughout their careers engineers build systems that protect data and guard it against corruption. But what if the right approach is the opposite: deliberately corrupting data, generating it out of thin air, and creating forgeries indistinguishable from the real thing?

Maksim Gramin, systems analyst at Postgres Professional, explains why creating fake data is a critical skill for testing, security, and development — and how to do it properly without turning your database into a junkyard of “John Smith” entries.

Hello, Habr! I'd like to share my experience developing such a system.
The defining parameters of a domain-specific system are: