Today's Deep-Dive: OliveTin

We've all been there, right?

You're running a personal server,

maybe for a small business,

and there's that one command you need to run.

It could be restarting a service,

maybe kicking off a backup.

But the command is long, it's complicated,

and if you get just one character wrong,

well, you could cause some serious downtime, or worse.

It's this weird paradox of server administration.

You need all this power, but for everyday stuff,

you just want simplicity and safety.

Today, we are diving deep into a tool

that was built to solve exactly that problem.

It's called OliveTin.

But before we get into how this amazing tool

balances that power with simple and safe access,

let's thank the supporter that makes this all possible,

SafeServer.

SafeServer handles the hosting of this software

and supports you in your digital transformation.

You can find out more over at www.safeserver.de.

So, OliveTin.

At its core, it's a web-based control panel,

but it's designed specifically for one thing,

running predefined Linux shell commands.

It takes these powerful, complex operations

that you'd normally do in a terminal.

Things you'd have to SSH in for.

Exactly, and it wraps them up into these really simple,

single-click buttons on a web page.

It's like putting, I don't know, permanent,

infallible guardrails around your most critical server

functions.

OK, let's unpack that a bit, that idea of safe simplicity,

because that seems to be the whole point.

For someone managing a server, how does OliveTin actually

achieve that balance?

Well, what's fascinating here is the dual focus.

The developers clearly put just as much thought into security

as they have into usability.

I mean, shell commands are powerful,

but let's be honest, they're often cryptic.

And dangerous if you don't know what you're doing.

Absolutely.

The biggest risk is just human error,

a simple typo, forgetting a flag,

running a command in the wrong place.

So OliveTin is basically mitigating

the risk of having to remember or type things out perfectly

every time?

Precisely.

The end user never even sees the command.

You, as the admin, you define it once in the configuration file

and that's it.

They can't edit it, they can't change its scope,

they can only click the button and run the exact operation

you defined.

I love the analogy of an engine room.

Instead of giving your assistant the master keys

and saying, please don't touch the big red lever,

you just install a button outside.

A button that says, run diagnostics.

The outcome is predictable, the risk is totally contained.

That's a perfect way to describe it.

And that safety also extends to permissions.

You can configure all of Tin to run a specific command

as a low-privilege user, even if the person clicking

the button has no special permissions at all.

It handles all that on the back end.

So it avoids that classic mistake

of just running everything as root because it's easier.

It completely avoids that.

OK, so we've got the theory down.

Safe simplicity.

But where does this actually shine in the real world?

Let's talk about some use cases.

Let's start with a really common one.

Home users, family members.

You're the family sysadmin, and the Plex server goes down again.

Oh, that's the perfect use case.

You get the text, Plex is broken instead

of trying to talk them through logging into something.

Or telling them to just wait until you get home.

Right, you just give them the link to a web page

with one button on it.

Restart Plex.

Under the hood, that button is running, say, Podman,

Restart Plex.

And for anyone who doesn't know, Podman is a lot like Docker.

It's a container tool.

So you're restarting a complex service.

But for your family, it's just a tap on their phone.

Zero technical knowledge required.

The time saving there is just massive.

Now, what about in a professional setting,

like with junior admins?

It scales up perfectly.

So imagine you have a custom backup script, BackupScript.esh.

But it needs a customer folder name every time it runs.

If a junior admin types that manually,

they might forget the folder flag or misspell

the customer's name.

And the backup fails.

Exactly.

With all of the 10, you define the command as BackupScript.esh

folder name.

That customer name part becomes a dropdown menu or a text box

in the web UI.

So it forces them to provide the right input.

It enforces correctness.

It makes the whole procedure repeatable

and basically error free.

You're moving the complexity from memory to configuration.

Let's talk security.

The source has mentioned a really clever one

for temporary access.

Yes.

Temporary SSH access.

This is brilliant.

Let's say you need to give a contractor access to a server.

The command you set up is firewall CMD add service

climb out 20 meters.

The key is that time out part.

20 minutes.

So the firewall rule just disappears after 20 minutes.

It automatically revokes itself.

The security benefit is huge.

You don't have to remember to log back in and turn it off.

The button does the whole cycle for you.

I can immediately see this being used in home automation, too,

like with those wall-mounted tablets.

Oh, absolutely.

You don't want to open a terminal on a touch screen.

No way.

So you have a button to run wake on LAN for a sleeping TC.

One tap, no typing an MC address.

And what about long-running tasks, like system updates?

That's always a pain over SSH.

It is.

You have to keep the session alive.

With this, you just hit a button that runs dnfupdate.you,

and it just runs the background on the server,

you can close the browser.

You can kick it off from your phone and not worry about it.

The source has also had a great example

of simplifying a really complex chain of commands, something

with Docker.

Right.

When you're updating a container,

you often have to stop it, remove the old one,

create a new one, and then start it.

That's, what, three or four steps?

All of which have to happen in the right order.

And it's so easy to mess up.

With all of 10, you can chain them into one single action,

Docker RM, and Docker Creator, and Docker Start.

And that contained part becomes a drop-down menu,

so the user picks from a list of approved containers.

Exactly.

It's such a powerful way to simplify daily operations.

OK, this brings up a really important question

for anyone listening.

If this thing is so powerful, how do you actually

configure these buttons?

The configuration is done using YAML.

And for anyone newer to this, YAML

is just a way to write configuration

in a structured, human-readable text file.

It's super common in the cloud-native world.

And using it here is a very deliberate choice.

It follows this modern idea of configuration as code.

You manage everything in a text file.

You can track, you can version, you can audit.

It's so much cleaner than clicking around

in some messy admin panel.

So in this YAML file, how do you actually define a button?

It's pretty simple.

Each action has three main parts, a title, which

is what the user sees on the button, an optional icon,

and then the shell command itself.

The actual command that's going to run.

Right.

And let's look at the ping host example,

because it shows the safety features really well.

The command is ping host-count, ping count.

OK, so host and count are the variables the user can change.

Correct.

And then in the argument section below,

you define what those variables are allowed to be.

For host, you might set its type to a site identifier.

For count, you set its type to an integer.

And that type definition is the security guardrail.

It's one of the most important ones.

By telling Oluften that count must be an integer,

you prevent a user from trying to inject some malicious text

or another command in that box.

It sanitizes the input before it ever gets to the shell.

That is clever.

So you, the owner, define the sandbox.

And the web UI makes sure the user can only play inside it.

Pertically put.

And it works for remote commands, too.

The example of restarting a remote web server is great.

The command is just source root at web server one service

HTTPD restart.

That whole thing is hidden.

The user just sees a button that says restart web server one.

You set up the complexity once.

And it's simple forever.

Exactly.

What about the footprint of this software?

A lot of people listening are running this stuff

on a Raspberry Pi or a small server.

It's incredibly lightweight.

The back end API is written in Go.

Which is known for being really fast and efficient.

Super efficient.

And the web interface is a modern single page app.

The whole thing uses just a few megabytes of RAM

and barely touches the CPU.

It's perfect for those small self-hosted setups.

So beyond just the tech, the source material

talks a lot about the philosophy behind all of 10.

They call it the no-nonsense software principles.

Yeah, and this is really refreshing.

It feels like a direct response to a lot

of the frustrations people have with software today.

First, it's completely open source and free software.

AGPL 3.0 license, all the code is right there for you to see.

And the second principle is inclusivity.

This one really stood out to me.

There's no pro or enterprise version.

No.

The virtue you download has every single feature.

They're not holding anything back

to try and upsell you later.

That builds a lot of trust.

It does.

And speaking of trust, their commitment to being invisible

is huge.

There is absolutely no tracking, no usage tracking, no ads,

no telemetry, nothing.

The sources even said they removed a simple update check

because they were worried it could be seen as phoning home.

Yeah, that shows a real dedication to privacy.

And finally, it's internal.

It doesn't need an internet connection to work at all.

It just runs on your network for your network.

We should also quickly mention the UI is responsive,

touch friendly.

It has a dark mode, all the modern comforts.

And high accessibility standards, which is great.

Plus, it's available as a Linux container,

which the self-hosted community loves.

So it's easy to get running.

Very easy.

And because it just runs shell commands,

you can integrate it with almost anything just

by writing a simple script.

OK, so to sum it all up.

All of 10 basically bridges that gap

between raw, powerful back end commands

and a simple, safe front end.

It does it by focusing on security through configuration.

And it operates under this really refreshing no-nonsense

philosophy.

You get everything with no tracking and no hidden costs.

So what does this all really mean for you, the listener?

I guess you have to think about it this way.

How many tiny, repetitive tasks do you do over SSH?

How many of those could just become a single button

on your phone, a button you could even

safely give to someone else?

That's the transformation all of 10 offers.

It turns assist admin chore into a simple, secure, repeatable

tap.

And on that note, a big thank you once again

to our supporter, SafeServer.

They handle the hosting of this kind of software

and support you in your digital transformation.

You can find more info and all their services

Until our next deep dive, keep digging for knowledge.

Until our next deep dive, keep digging for knowledge.