irmadlad

u/irmadlad@lemmy.world
53 posts · 2.7k comments

Recent posts

Recent comments

I like it. The OCD in me is screaming why you didn't use a dremel tool to cut the slot for the USB ports instead of using a rusty, dull, steak knife from the junk drawer, but that's just me. LOL

on Why homelab? · c/selfhosted · 5 pts · 7d

I was reading a homelab discussion about NUTs (Network UPS Tools) that left me scratching my head and wondering "…why? Is complexity for complexities sake part of homelabs? Isn’t this a huge overkill for one machine? Just…use a UPS? "

I think it's like anything else people do. Some are quite satisfied at a moderately basic level. Others tho, implement K8 clusters, etc, a complexity level I have no interest in. Take golf for example. I used to play quite regularly. I had a raggedy old bag and some beginner level clubs I bought third hand. My buddy had every golf gadget you could possibly imagine. Thousands of dollars to whack a ball around a course and into a hole, on an amateur level. I'm thinking, 'Dude, this isn't the Masters Tournament at the Augusta National. We're just whacking balls into holes and having a few beers on the weekend' . But, every time we got together, he just had to show me his new gadget that cost him hundreds of dollars and added even more complexity to the game.

Yeah, I'm familiar with the GPS modules. They just look a bit bulky. Of course, if you have your DSLR, a high performance telephoto lens, and other gadgetry attached, then what's another gadget. LOL I know that some DSLR have wireless capabilities, and even if they don't you can get a wireless SD card to interface with a wireless SSD pack. I have a friend who is a professional photographer who shoots all manner of photos for news stories, etc. He uses a bluetooth SSD setup, that is backed up to his official FTP site. He needs a backpack to haul all the stuff around tho, which might be cumbersome for casual photography.

It was just a fleeting thought to somehow combine existing hardware like the GPS capabilities of a mobile phone with a DSLR.

Monitoring firewall logs would show calls to suspicious IPs and domains after you pulled the Docker container. A MiTM attack is usually conducted between two communicating parties, rather than inside the server itself. The attacker intercepts traffic as it travels across a network or service path. MiTM are not always done exterior of the server, but usually. Strong ciphers are your friend. Although MiTM and PIC events can overlap, a PIC is usually an attacker gaining unauthorized access to a system. A PIC compromise occurs outside the public facing server, through a stolen administrator password, compromised developer workstation, exposed API key, or hijacked cloud account. Securing API, devices, frequent password rotation are good practices. Again, not always exterior of the server, but usually.

What do you (or does your org do) to ensure that you’re not using maliciously-modified containers after pulling a new docker image?

I don't run a complex setup as it seems you do, but if I pull a new Docker container, I closely monitor my pfsense firewall logs. A lot of times, I'll deploy a recently released container on a small test server and just observe as I run it through it's paces. Also, I like containers that have a rather established history. I look at things like stars, how they handle bug complaints, etc. Even when updates come out, unless it's a dire security patch, I'll wait until all the early adopters work out the bugs and do my work for me. Early adopters are a valuable resource.

I guess you could say it all comes down to calculated risk.

on VyOS or Opnsense · c/selfhosted · 2 pts · 11d

Opensense is often bound by single-core operations depending on where a network packet may plumb itself through the kernel

Didn't downvote, but when would this become an issue? Pfsense is about the same way as far as single-core operations, tho IDS/IPS like Suricata can utilize multiple threads. My standalone pfsense box sits between my modem and the rest of the network. I haven't noticed any sluggishness or stuttering. Throughput seems quite reasonable, and supports a diverse group of devices attached to the network.

Pay no attention to the old fart yammering on. I'm surprised I didn't throw in a couple 'well, back in my day'. lol I hope you get it all worked out tho.

I don't run Jellyfin, so take this as is. From what I understand tho, Jellyfin does take a fair amount of resources to run in an ideal situation. Meaning it takes some RAM for multiple simultaneous transcodes, several users, large libraries, etc. A lot of the cheaper Stick PCs come with less than stellar specs. The Stick PC I just randomly picked because it was 8 GB RAM is a MeLE Business Grade PCG02 Fanless N100 Mini Stick PC 8GB. It retails for $350 USD. For half of that price, you could opt for an SFF Optiplex, bump the DDR3 RAM to max the mobo, and DDR3 is fairly cheap, and still have resources to run other Docker containers if you wanted. For example I run an Optiplex SFF with the i7-4790 chip and 32 GB DDR3 RAM. Currently I have 53 total containers running and it really doesn't break a sweat. Total cost of the box plus RAM was about $175 USD.

If you are going for the portability aspect, that's where I think a Stick PC would function best. All that being said, you have options just depending on what your criteria are for running Jellyfin.