Stații de lucru

OS - Windows 9087 Solutii

Reguli si plangeri 11 Solutii

OS - OS X 410 Solutii

Reguli de configurare 12 Solutii

Licentiere 18 Solutii

Securitate 182 Solutii

Copie de rezerva (Backup) 68 Solutii

Antivirus 72 Solutii

Aplicatii specifice 5243 Solutii

Hardware 291 Solutii

Self-Hosted Telegram SysAdmin Bot with Ollama

A Telegram sysadmin bot connects a chat interface to a local LLM and, optionally, to real system operations. The design challenge is not “how do I call the Telegram API,” it is “how do I let a chat message trigger AI reasoning and system actions without creating an unauthenticated remote-control channel into my infrastructure.” Treat this project as an API security exercise wrapped around a convenient chat frontend.

Telegram supports two mutually exclusive update mechanisms: long polling with getUpdates, and webhooks with setWebhook. getUpdates is a pull method where your bot repeatedly asks Telegram’s servers for new messages, and it cannot be used while a webhook is active. setWebhook is a push method: Telegram sends an HTTPS POST containing a JSON Update object to your specified URL whenever a message arrives.core.telegram+1

For a homelab or single-admin bot behind NAT, long polling is simpler because it needs no public inbound port. For a bot exposed through your own domain and reverse proxy, a webhook avoids constant polling and reacts faster. If you switch between the two, call deleteWebhook before starting getUpdates, since Telegram returns a conflict error if both are configured at once.

Long Polling Version

This is the easier starting point for a private admin bot with no public exposure.

python
import time
import requests

TELEGRAM_TOKEN = “YOUR_BOT_TOKEN”
API_BASE = f”https://api.telegram.org/bot{TELEGRAM_TOKEN}
ALLOWED_CHAT_IDS = {123456789}

def get_updates(offset=None):
params = {“timeout”: 30, “allowed_updates”: [“message”]}
if offset:
params[“offset”] = offset
resp = requests.get(f”{API_BASE}/getUpdates”, params=params, timeout=35)
resp.raise_for_status()
return resp.json()[“result”]

def send_message(chat_id, text):
requests.post(f”{API_BASE}/sendMessage”, json={“chat_id”: chat_id, “text”: text})

def ask_ollama(prompt):
resp = requests.post(
“http://127.0.0.1:11434/api/chat”,
json={
“model”: “llama3.2”,
“messages”: [{“role”: “user”, “content”: prompt}],
“stream”: False,
},
timeout=60,
)
resp.raise_for_status()
return resp.json()[“message”][“content”]

def main():
offset = None
while True:
updates = get_updates(offset)
for update in updates:
offset = update[“update_id”] + 1
message = update.get(“message”)
if not message:
continue
chat_id = message[“chat”][“id”]
if chat_id not in ALLOWED_CHAT_IDS:
continue
text = message.get(“text”, “”)
reply = ask_ollama(text)
send_message(chat_id, reply)
time.sleep(1)

if __name__ == “__main__”:
main()

Ollama’s chat endpoint accepts a model name and a list of role-tagged messages, and returns the model’s reply; setting stream to false gives one complete response object instead of a token stream. The offset parameter in getUpdates must be one greater than the last processed, update_id or Telegram will resend already-handled messages.

If you expose the bot through a domain with a reverse proxy, register the webhook once:

bash
curl -F "url=https://bot.example.internal/telegram/webhook" \
-F "secret_token=YOUR_RANDOM_SECRET" \
"https://api.telegram.org/bot${TELEGRAM_TOKEN}/setWebhook"

Telegram lets you set a secret_token so incoming POST requests carry a header you can verify, confirming the request actually originated from your webhook configuration. Your Nginx layer should terminate TLS and forward only to your bot service, following the same reverse-proxy hardening pattern used for any self-hosted API: private-network binding for the backend, rate limiting, and access logging.

python
from fastapi import FastAPI, Header, HTTPException, Request

app = FastAPI()
WEBHOOK_SECRET = “YOUR_RANDOM_SECRET”

@app.post(“/telegram/webhook”)
async def telegram_webhook(request: Request, x_telegram_bot_api_secret_token: str = Header(None)):
if x_telegram_bot_api_secret_token != WEBHOOK_SECRET:
raise HTTPException(status_code=403, detail=“Invalid secret token”)

update = await request.json()
message = update.get(“message”)
if not message:
return {“ok”: True}

chat_id = message[“chat”][“id”]
if chat_id not in ALLOWED_CHAT_IDS:
return {“ok”: True}

reply = ask_ollama(message.get(“text”, “”))
send_message(chat_id, reply)
return {“ok”: True}

Never skip the secret-token check. Without it, anyone who discovers your webhook URL can submit forged Telegram-shaped JSON payloads directly to your bot.

A sysadmin bot is a privileged interface, so authorization must happen before any AI call or system action, not after. Maintain an explicit allowlist of Telegram chat IDs or user IDs, reject everything else silently or with a generic denial, and log rejected attempts. Do not rely on “security through obscurity” from an unlisted bot username; bot usernames and tokens can leak through screenshots, shared chats, or repository history.

Layer authorization by role if multiple admins use the bot:

json
{
"chat_id": 123456789,
"role": "read-only",
"allowed_commands": ["status", "ask"]
}
{
"chat_id": 987654321,
"role": "operator",
"allowed_commands": ["status", "ask", "restart-service", "run-backup"]
}

Route every command through this permission table before execution. A “read-only” user should never reach a code path that can restart a service or touch a database.

Follow the same separation you’d apply to any AI-driven automation: the model can draft, explain, and suggest, but a structured, validated, allowlisted function should perform any real action. Do not let free-text bot input be interpolated directly into a shell command.

python
ALLOWED_ACTIONS = {
"status": lambda: run_readonly_check("systemctl status nginx"),
"disk": lambda: run_readonly_check("df -h"),
"restart_nginx": lambda: run_privileged_action("systemctl restart nginx"),
}

def handle_command(role, command):
if command not in ALLOWED_ACTIONS:
return “Unknown or unauthorized command.”
if command.startswith(“restart”) and role != “operator”:
return “You do not have permission for this action.”
return ALLOWED_ACTIONS[command]()

Use this pattern instead of asking the LLM to “generate and run whatever shell command answers the question.” Free-form command generation from a chat message is a direct path to remote code execution if the bot, token, or Telegram account is ever compromised.

Protect Secrets and the Runtime

Store the Telegram bot token, webhook secret, and any service credentials in environment variables or a secrets manager, never hardcoded or committed to a repository. Run the bot process under a dedicated, unprivileged Linux user, restrict its filesystem access, and grant it sudo rights only for the exact commands it must run, ideally via a tightly scoped sudoers entry rather than full root access.

Keep Ollama bound to 127.0.0.1 so only the bot process can reach it, matching the same loopback-binding pattern used for any self-hosted inference API. If the bot and Ollama run in separate containers, use an internal Docker network instead of exposing Ollama’s port to the host or LAN.

Log every command with timestamp, chat ID, role, command name, and outcome, but avoid logging full LLM prompts or responses by default if users might paste sensitive infrastructure details. Add a simple in-memory or Redis-backed rate limiter per chat ID to prevent one user or a compromised token from flooding Ollama with requests or triggering repeated privileged actions.

python
from collections import defaultdict
import time

_last_call = defaultdict(float)
MIN_INTERVAL_SECONDS = 3

def rate_limited(chat_id):
now = time.time()
if now _last_call[chat_id] < MIN_INTERVAL_SECONDS:
return True
_last_call[chat_id] = now
return False

[mai mult...]

Cum pot primi notificări pe Slack pentru e-mailurile urgente din Gmail fără să folosesc cod?

Verificarea constantă a inbox-ului pentru e-mailuri urgente (de la un anumit client, manager sau cu un anumit subiect) consumă foarte mult timp și scade productivitatea. Există o metodă prin care pot automatiza acest proces, astfel încât să primesc o alertă instantanee pe Slack doar pentru mesajele prioritare, fără să fie nevoie să scriu scripturi sau să folosesc API-uri prin cod?

[mai mult...]

Slackware Linux guide

Slackware deliberately keeps the operating system relatively simple and transparent. Its installer is primarily text-based, package management does not automatically resolve dependencies, and system configuration is generally performed through straightforward configuration files and scripts.

That gives you considerable control, but it also means that you should understand what you’re doing rather than expecting the installer to make every decision for you.

A typical installation looks roughly like this:

Firmware
├── UEFI
Slackware installer
├── Partition disk
├── Create swap
├── Install packages
├── Configure network
├── Configure bootloader
└── Create users
First boot
├── Configure networking
├── Configure package management
├── Install updates
├── Configure X/Wayland
├── Configure desktop
├── Configure services
└── Harden system

The official Slackware documentation is worth keeping nearby throughout the installation.

2. Decide what you’re installing

For a modern Intel or AMD computer, you almost certainly want:

Slackware64 15.0

rather than 32-bit Slackware.

For a normal desktop:

  • UEFI firmware
  • GPT partition table
  • Slackware64
  • EFI System Partition
  • swap
  • root filesystem
  • optionally a separate /home

For a server, you might instead use:

  • EFI System Partition
  • swap
  • /
  • perhaps separate /var, /home, or storage partitions depending on the workload.

Recommended beginner layout

For a computer with a 500 GB SSD:

/dev/nvme0n1
├── /dev/nvme0n1p1 EFI System Partition 512 MB
├── /dev/nvme0n1p2 swap 8 GB
├── /dev/nvme0n1p3 / 80 GB
└── /dev/nvme0n1p4 /home remainder

You don’t have to use this layout.

A single root filesystem is perfectly reasonable for a first Slackware installation:

EFI 512 MB
swap 4–16 GB
/ remainder

In fact, I’d recommend keeping your first installation simple.

3. Back up your existing data

This is the most important step.

If you are installing Slackware onto a disk containing Windows, another Linux distribution, or personal data, partitioning can destroy the existing installation.

Before touching the installer:

  1. Back up important files.
  2. Verify that the backup actually works.
  3. Make sure you have Windows recovery media if Windows is staying on the machine.
  4. Record your existing partition layout.
  5. If you’re replacing the entire disk, verify once more that you have everything you need.

If you don’t need anything currently on the disk, the installation is considerably simpler.

4. Download Slackware

Use an official Slackware mirror to obtain the installation media. The official mirror tree contains the Slackware 15.0 installation files, README files, kernels, packages, patches, and USB/PXE installation material.

Official Slackware mirror

  • Look for the appropriate Slackware64 15.0 installation media.
  • You will generally want the ISO and its associated checksum/signature information.
  • After downloading the ISO, verify it rather than blindly trusting a corrupted download.
  • On another Linux system you can use something along the lines of:
sha256sum slackware64-15.0-install-dvd.iso

Compare the result against the checksum supplied by Slackware.

5. Create a bootable USB

On Linux, you can write the ISO directly to a USB drive.

Be extremely careful with /dev/sdX.

For example:

lsblk

Identify the USB device.

Suppose it is /dev/sdb.

Unmount its partitions:

sudo umount /dev/sdb1

Then write the image:

sudo dd if=slackware64-15.0-install-dvd.iso \
of=/dev/sdb \
bs=4M \
status=progress \
oflag=sync

Then:

sync

Do not accidentally use:

/dev/sda

if /dev/sda is your operating-system disk.

6. Boot the Slackware installer

Insert the USB and reboot.

Enter your firmware’s boot menu. Common keys include:

F12
F11
F8
Esc
Delete
  • The exact key depends on the motherboard.
  • Select the USB device.
  • On a modern machine, prefer the UEFI boot entry.

Slackware supports UEFI installations. For a UEFI installation, an EFI System Partition is required, and Slackware’s documentation recommends using the ELILO option rather than LILO during the installation process.

7. The Slackware installer

The installer initially gives you a console prompt.

You may see something similar to:

boot:

For a normal installation, simply press:

Enter

The installer will boot.

You will eventually reach the keyboard selection. If you’re using a standard US keyboard, you can usually accept the default. For other layouts, select the appropriate keymap.

8. Partition the disk

This is the first genuinely important part of the installation.

You can use:

cfdisk

or:

fdisk

For a modern UEFI system, I recommend:

cfdisk /dev/nvme0n1

Your disk might instead be:

/dev/sda

or something else.

Check first:

lsblk

GPT partition table

For a new UEFI installation, use GPT.

Your final layout might look like:

Device Size Type
————————————————
/dev/nvme0n1p1 512M EFI System
/dev/nvme0n1p2 8G Linux swap
/dev/nvme0n1p3 80G Linux filesystem
/dev/nvme0n1p4 remainder Linux filesystem

EFI System Partition

Create approximately:

512 MB

and mark it as:

EFI System

It should be formatted FAT32.

Swap

A reasonable desktop value is:

4–16 GB

If you intend to use hibernation, swap sizing becomes more important because the system needs enough swap to hold the relevant memory state.

Root

For /, I would give a desktop installation at least:

40–60 GB

I’d personally choose around:

80 GB

if disk space isn’t a concern.

/home

A separate /home is optional.

It can be useful because reinstalling the operating system doesn’t necessarily require destroying your personal data.

9. Activate swap

After partitioning, return to the Slackware installer menu.

Choose:

ADDSWAP

The installer should find your swap partition.

Allow it to activate the partition and add the appropriate entry to /etc/fstab.

The traditional Slackware installation sequence starts with ADDSWAP and then proceeds through TARGET, SOURCE, SELECT, INSTALL, and CONFIGURE.

10. Select the target partitions

Choose:

TARGET

Select your root partition.

For example:

/dev/nvme0n1p3

The installer will ask how it should be formatted.

For a straightforward installation:

ext4

is an excellent choice. You could also use other filesystems, but there’s no compelling reason to complicate your first Slackware installation.

If you created a separate /home, assign that partition as well.

For example:

/dev/nvme0n1p3 → /
/dev/nvme0n1p4 → /home

Choose:

SOURCE

For a USB/DVD installation, select the appropriate local media.

The installer will locate the Slackware package tree.

You can also install through other methods, including network-based approaches. Slackware’s installation documentation describes USB and PXE installation material as well.

For your first installation, local installation media is easiest.

12. Choose the package sets

Slackware packages are organized into series.

You’ll encounter things such as:

A Base system
AP Applications
D Development
E Emacs
F FAQ/documentation
K Kernel
KDE KDE Plasma
KDEI KDE internationalization
L Libraries
N Networking
T TeX
TCL Tcl
X X Window System
XAP X applications
XFCE Xfce
Y Games

The exact package organization can vary somewhat by release.

Full installation

For a first installation, I strongly recommend installing essentially everything except things you have a specific reason to exclude. Slackware itself recommends a full installation when you have sufficient disk space, and this is particularly useful because Slackware’s package system does not automatically resolve dependencies.

This is one of the biggest differences between Slackware and distributions such as Debian or Fedora.

Suppose application A requires library B.

Slackware generally won’t automatically say:

“A requires B, so I’ll install B for you.”

You are expected to understand the relationship.

Consequently, a full installation avoids many dependency headaches.

13. Start the installation

Select:

INSTALL

For a first installation:

Full

is the easiest option.

The installer will copy the packages to the hard drive.

Depending on the machine and installation media, this may take some time.

14. Configure the kernel

After package installation, Slackware will ask about the kernel. For a modern 64-bit system, the generic kernel is generally the better long-term choice. Slackware traditionally provides both generic and huge kernels.

The “huge” kernel contains a very broad collection of drivers and is useful for bootstrapping. The generic kernel is more minimal.

For a normal modern system, I would generally choose the generic kernel and create/initiate the necessary initrd configuration if required.

15. Configure the network

You’ll be asked about networking. For a normal wired Ethernet connection, Slackware can generally configure the interface automatically through DHCP.

You might see something like:

eth0

or:

enp3s0

Modern Linux naming may produce names such as:

enp2s0
eno1
wlp3s0

For DHCP:

DHCP

is usually what you want.

If you’re configuring a server with a static IP, you’ll need something like:

IP address: 192.168.1.50
Netmask: 255.255.255.0
Gateway: 192.168.1.1
DNS: 192.168.1.1

The exact values obviously depend on your network.

16. Configure your hostname

Choose something meaningful.

For example:

Hostname:
slackbox

or:

server01

For a home computer:

desktop

is fine.

You can later change it in:

/etc/HOSTNAME

For example:

desktop.example.local

17. Configure the timezone

Select:

Europe/Bucharest

if your system is physically in Bucharest and that is your desired timezone.

For a generic machine, choose the timezone appropriate to its actual location.

You can verify it later with:

date

18. Configure the mouse

For a normal USB mouse:

USB

is usually appropriate.

19. Configure the hardware clock

If the computer is primarily running Linux, using local time for the hardware clock can work, but UTC is generally preferable.

If Windows is dual-booting on the same machine, be aware that Windows and Linux traditionally make different assumptions about the hardware clock.

A common modern configuration is:

Hardware clock → UTC

20. Configure the bootloader

This is especially important on UEFI systems.

For a legacy BIOS installation, Slackware traditionally uses:

LILO

For UEFI, Slackware’s installation documentation recommends bypassing the LILO installation and selecting ELILO.

If you’re installing Slackware64 15.0 in UEFI mode:

UEFI
EFI System Partition
ELILO
Slackware kernel

Make sure the EFI System Partition exists before reaching this stage.

21. Set the root password

The installer will ask you to establish the root password.

Use a strong password.

Do not make it something like:

root or:
password

Use a long, unique password.Slackware will initially leave you with the root account, which is the administrative account.

22. Reboot

When the installation is complete:

reboot

Remove the USB installation media when appropriate.Your system should now boot from the internal disk.

You should eventually see a login prompt similar to:

darkstar login:

Log in as:

root

using the password you created.

23. First things to do after booting

First inspect the system:

uname -a

Then:

cat /etc/slackware-version

And:

lsblk

Check networking:

ip addr

and:

ping -c 4 1.1.1.1

Then:

ping -c 4 slackware.com

If the first works but the second doesn’t, you probably have a DNS configuration problem.

24. Create your normal user account

Do not use root for ordinary desktop work.

Slackware provides:

adduser

Run:

adduser

You’ll be asked for a username.

For example:

Login name: john

Then provide the requested information.

Afterward:

passwd john

Set a strong password.

Your system should now have:

root
└── administrative account
john
└── normal user
[mai mult...]