non_burglar

I ran a linux box with two gigabit Intel NICs for years with iptables. Almost any device can do it.

Like others say, opnsense is prob your best bet unless you like the abstraction of iptables

1. Obtain flac cd-ripped originals
2. Convert to 256bit center-weighted opus
3. Use Picard to tag music, save to artist - album/song file & folder pattern
4. Sync to my subsonic-compatible server

Uhh… That’s a repackage of Lidarr in docker, and based on the commits only to comments and to the packager’s Discord server, I would say they probably aren’t adding any actual functional changes.

This is the actual Lidarr repo: github.com/Lidarr/Lidarr

I don’t think there is anything, really.

Radarr and Sonarr work because the naming conventions for videos are more or less established.

With music, everyone has a different philosophy for tagging, renaming files, transcoding, how to handle best-of albums, compilations, etc. So what works for you probably doesn’t work for me and vice versa.

Lidarr gets very few updates, I don’t think anyone is working on it anymore. I remember the problem was keeping up with metadata handling.

Lidarr is pretty much dead, just so you know. The problem became managing metadata sources and assignment to media.

telling me what’s wrong

How do you verify the accuracy?

I have been in IT for 30 years, and in security for the last 16.

You’ll find lots of arguments from a productivity and removing barriers point of view that say don’t bother with strict user access controls, just layer on other security measures. Others (usually older-school sysadmins) preach “doing the work”, meaning secure your users well and audit access often. There are advantages and disadvantages to both approaches.

I personally do a bit of both. The old way of being meticulous with access works, but not without diligence and self-audit. The newer devops way if doing things with secrets management and treating everyone as untrusted works too, as long as you document the automation.

Maybe one suggestion about user control in a homelab setting is not to use the same username across multiple services, but rather name your users something like name.of.service.admin so that you a) don’t forget where you are and b) if you start collecting logs centrally, you can easily identify which system the logs came from.

It’s not super difficult. They provide setup instructions and then you just connect to your new instance instead of the public one.

Eleventy works for me.

Op specifically asked for resources for learning and not sparse answers from users.

research on your own

Come on, man. Did you even read the post.

I’ll have to check this out, I use Kobo sync extensively.

I had some catastrophic docker updates that destroyed my wanderer instance, forcing me to revert to backups. Twice, I’ve had to export all my tracks, reinstall, and re-import the tracks. Both times, fhe web component broke.

Have these breaking changes been addressed?

From a security perspective, it’s a big mess of inputs and can have really inappropriate access to local filesystem on the web server unless you really know what you’re doing. Combine that with Perl (also a pita to secure), and it’s now a liability.

These are good tech, I used them a lot myself. But the structure of a language and how it builds things is important too, and that’s why very few ppl bother with Perl or CGI now (besides them also being fails on certain security audits.)

Sorry, no disrespect intended, but I’m shocked. It’s like hearing someone say they drive a 1988 Toyota Cressida because it’s great… It was great at the time, but we’ve moved on and the smokeping website should tell you how ancient it is; sponsors from 2007 by companies that don’t exist anymore.

Still alive & still maintained

Alive, maybe. I think any maintenance is down to bodges to keep it running in modern environments. Neither Toby nor Niko have worked on sp in over a decade.

Smokeping is fine if all you do is look at its own graphs and you have enough traffic to see patterns in latency.

But:

• more or less unmaintained for a long time
• cgi scripts and scraping
• jitter is estimated from rping, not calculated with real values from more than one point on a route (that means a lot when you have a DMZ)
• Perl
• rrd tool is… Not great. Not very configurable, also unmaintained, lua support is not good, etc
• difficult to customize unless you use their submenu system
• no reporting, you get what you get with smokeping

I had to retire 2 smokeping monitors because their CGI implementations were security risks. That was 2015. Not a good reason for homelab, but CGI is a pretty ancient and insecure way to interact with the web server.

Smokeping is good in a big organization with lots of traffic and a few broadcast domains. It isn’t really great at monitoring remote sites because ICMP doesn’t tell you what segment in route is causing the issue, even with rping.

I used smokeping a lot in my career from about 2005 to 2015, when security audits made me retire it. Just even using rrdtool with an exporter and graphana would be preferable to smokeping itself.

Smokeping? In 2026? Jesus…

I deploy with ansible keys and install ssh with a keys-only config and only ansible access.

Then I run some standard installs and configs with ansible and all future updates to apt, apk and docker are done with one ansible playbook.

I don’t include the ansible host itself in the automation, nor my workstation, just to prevent everything from being broken at once if something goes wrong.

Nice.

There is often a check for battery that is effectively a check of resistance between sense and ground. Looks like that battery is labelled, you might be able to bodge a resistor between sense and ground on the phone and get it to boot without the battery?

I’ll say again, I love this.

I think you should keep posting these, I’d like to see more guerrilla servers.

I moved away from proxmox about 3 years ago to incus, primarily because Proxmox has a lot going on that I don’t need, but also incus is much more amenable to configuration with ansible. Also, and maybe this has changed recently, but passing through PCI devices to incus is much easier.

jumbo frames (mtu 9000) to get the most out of it

On dedicated network segments where only jumbo frames are configured at broadcast points, like a dedicated SAN, sure.

Not the best for multi-mode networks like most home labs.

iSCSI is already good at shoveling frames. The tiny benefit one can get from using jumbo frames isn’t really worth the problems it causes in multi mode networks.

I mean, you say contradictory things in your post: you don’t want to manage a db, but you want to assign tags and categorize the photos, which would need a db of some kind.

If you really, really don’t want a db but you want web access to your pics, just rename them so they sort alphabetically the way you want and drop them in the doc root of a www server, apache or nginx would work. Do note that you will have no sorting or tagging options, but it will be dead simple. This is what the copyparty option would give you.

Not sure what you mean about “a whole Linux container”, the majority of my alpine images run in under 100MB memory and use less than 0.1% CPU, so it’s not clear to me what your objection is.

The idea would be to put something like postmarketos or armbian on it so it actually is a supported platform.

OK? By all means, use what works for you.

I personally wouldn’t go around using copy party’s initials liberally like that.

It does nothing but serve photo. Background tasks are minimal and many of them only run once on new photos.

Yeah, I keep a oneplus 6t to test Linux images, but maybe it can do other things for a bit…

Postmarketos runs well on it.

I love this.

As I get older, I realize that the miriad of lower-power devices I have a perfectly suitable to fill roles in my infra in this way.

Be aware that there are still some bugs to workout, the menu options break some of the yaml configs if you had those already.

I’ve been down this rabbit hole and it’s not a good option for standard matx or mini itx. Best I did was get a supermicro board and a supermicro 1u half-depth chassis. It was OK for a while, but the HDDs did not cool off very well.

I’ve now not got a nas just as fast with a radxa rock 2a, a penta sata hat, some FPC cables between them and some cable bodging in a jonsbo n1 case. Drives are happy, less power consumed.

Do you mean we Lemmy users shouldn’t do this, or IaC shouldn’t be done in homelab? I don’t understand your objection.

Ansible with incus, be still my heart!