I am Ihar Petushkou, a Linux engineer who automates with Python and AI.
Norboten is my pet
project: nobody pays for it and nobody asked for it.
The rest of what I do — the work I take on, the projects behind it, my CV and how to hire me — is on my own site.
Over the last years I have gathered a lot of know-how about keeping Linux machines alive: what breaks them, how you find out why, and which fix still holds after a reboot. Norboten puts that in one place, in a form you can use. Every lab is a machine I broke on purpose, every check is how I would confirm the fix, and every journal is what I would tell a colleague afterwards. It is also the honest way to show that expertise: a project you can install, read and break yourself, not a list of claims.
I have been a freelancer for many years: thousands of hours and dozens of projects on Upwork, and plenty of work before that. At its core that work has been Linux administration, DevOps, and Python automation of both: setting up, securing and fixing the servers, building the pipelines that deploy to them, and writing the Python and Bash that take the manual steps away. Around it, often end to end, came the products those servers run — mobile apps, websites, backends in several languages and their databases. Some of it lived on private on-premises Linux servers, some in the cloud — Firebase and Google Cloud — and in recent years mostly on AWS.
Today it is Linux engineering automated with Ansible, Terraform and Python, and AI agents on Claude Code and MCP that do real engineering chores. Norboten uses all of it: QEMU and Lima for the machines, Ansible for the images, FastAPI and PostgreSQL on the server, and Claude Code jobs in CI.
Broke a machine in a way no lab has yet? Found a check that let a wrong fix through? Have a failure from real life that deserves to become a lab? Bring it to the community or open a GitHub issue — the best labs start as someone's bad day. What the site and the server keep about you is in the privacy policy.