this post was submitted on 14 Aug 2023
506 points (96.5% liked)

Selfhosted

40394 readers
392 users here now

A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.

Rules:

  1. Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.

  2. No spam posting.

  3. Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.

  4. Don't duplicate the full text of your blog or github here. Just post the link for folks to click.

  5. Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).

  6. No trolling.

Resources:

Any issues on the community? Report it using the report flag.

Questions? DM the mods!

founded 2 years ago
MODERATORS
 

In the past two weeks I set up a new VPS, and I run a small experiment. I share the results for those who are curious.

Consider that this is a backup server only, meaning that there is no outgoing traffic unless a backup is actually to be recovered, or as we will see, because of sshd.

I initially left the standard "port 22 open to the world" for 4-5 days, I then moved sshd to a different port (still open to the whole world), and finally I closed everything and turned on tailscale. You find a visualization of the resulting egress traffic in the image. Different colors are different areas of the world. Ignore the orange spikes which were my own ssh connections to set up stuff.

Main points:

  • there were about 10 Mb of egress per day due just to sshd answering to scanners. Not to mention the cluttering of access logs.

  • moving to a non standard port is reasonably sufficient to avoid traffic and log cluttering even without IP restrictions

  • Tailscale causes a bit of traffic, negligible of course, but continuous.

you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 3 points 1 year ago* (last edited 1 year ago)

Not everyone in IT needs to fix tickets or work in a high-stress environment. In one of my previous roles, I was a projects engineer, and I was basically given a bunch of projects to work on (like there was a small python-based project - they needed to automate something; then there was one to get them into a hybrid cloud setup; another project to upgrade something and so on). I didn't really have any break-fix tickets to work on, although I was occasionally asked if I could help, when there was some spare time or if it was something high-level the ops guys couldn't fix. Basically a total chill job, I was free to allocate time on my projects as I saw fit, no hard deadlines, no SLAs to meet, and the best part - no users to deal with.

Of course, it wasn't always like this. To get here, I had to do those grunt roles first, those stressful jobs with tickets that needed to be fixed in minutes, dealing with angry users and stuff. But thankfully my career has progressed past that stage now.