starkzarn

joined 2 years ago
[–] starkzarn 1 points 1 month ago

That's a super valid question, as it seems sometimes that some of these things are configured in a way that begs the question "why?" As far as contributing to documentation, that's a moot point. This is already in the man pages, and that's exactly what I referenced in writing this post, in addition to some empirical testing of course. As far as implementation goes, I think that probably lies at a per distribution level, where not one size fits all. Although I don't know of it off the top of my head, I'm sure there's a security centric distro out there that implements more of these sandboxing options by default.

[–] starkzarn 3 points 1 month ago

Excellent! There's certainly a lot to unpack, but being able to twist all these little knobs is part of the beauty of Linux.

[–] starkzarn 2 points 1 month ago

Very glad to gear it! Learning new stuff with Linux is the fun part of the journey.

[–] starkzarn 15 points 1 month ago

Hey, much appreciated!

[–] starkzarn 3 points 2 months ago (4 children)

What... This isn't true at all.

[–] starkzarn 1 points 2 months ago

The primary thing is rather than "dumb" flood routing, you can choose the path your message takes to its destination; as a repeater operator you can also choose the path it takes to repeat out. Its a slight compensation to people carelessly placing infrastructure nodes with poor configurations in poor places. Not perfect, but better. Adoption is much, much lower though, and the licensing is not copyleft.

[–] starkzarn 2 points 2 months ago

My pleasure. It was a good question, I think I'll even include a note on that in the post when I get home this evening and can edit.

Cheers!

[–] starkzarn 2 points 2 months ago (2 children)

That's a great question!

No, blocking a node -- router or other -- will only block packets originating from that node. All traffic that is forwarded by that node, but originating from others will still be received.

Ultimately, the only place that blocking nodes strategically makes sense is on high utilization routers. If you're just blocking nodes on a client, it's not changing channel or airtime utilization for the rest of the mesh. That said though, if someone is harassing you then a block on a client is still fully worth it. 🙂

[–] starkzarn 2 points 2 months ago (3 children)

Meshcore does address some of the biggest shortfalls of Meshtastic, but I absolutely HATE that they're positioned to either rugpull, or setup a perpetual "freemium" model. It's also not interoperable, so if Meshcore is to work, it needs the numbers like Meshtastic has.

[–] starkzarn 3 points 2 months ago (5 children)

Yeah, so far the most prevalent thing around my area has been "it's a hobby for the sake of being a hobby." No one does anything terribly useful or important with it. I can tell you that I would certainly never rely on it as a form of emergency communication.

[–] starkzarn 2 points 2 months ago

La Marzocco

[–] starkzarn 7 points 2 months ago (1 children)

It's not about user-led synergy. The personal data market is slurped up by those that already have and are building correlations. Just because a user didn't report anything to their insurer doesn't mean an insurer sure as shit isn't going to want the data if they can link it to the user whatsoever, so long as it will make them more money.

This is hypothetical, of course, but it's the way the market of data brokers works.

 

Another post in the records for the tech blog, this time all about opensource network monitoring with LibreNMS!

 

For those that were interested in my PART 1 post of the Grafana Loki OPNSense firewall log monitoring, I present you: PART 2! This one is the good one (albeit less technical) where we get the eye candy after getting the log ingestion pipeline already setup in part 1.

 

cross-posted from: https://infosec.pub/post/27200076

My first blog series on headscale with traefik through podman quadlets was pretty well received on here. I'm just getting started with this blog, and thought the second topic I recently worked on might be popular in this crowd too: a lower resource method of centralizing logs for OPNSense with Grafana Loki (and Alloy) including geoIP!

 

My first blog series on headscale with traefik through podman quadlets was pretty well received on here. I'm just getting started with this blog, and thought the second topic I recently worked on might be popular in this crowd too: a lower resource method of centralizing logs for OPNSense with Grafana Loki (and Alloy) including geoIP!

 

About a month ago I switched from Google Fi to Mint Mobile. I figured since they were both T-Mobile MVNOs the service would the same, and it was a way for me to move away from the Google Fi app requirement, and this the play services requirement on my graphene pixel 8 pro. Everything initially seemed to be working great, then I realized I only ever have LTE. I've tried all the APN settings, auto discovered, manually configured in accordance with the mint documentation, and the T-Mobile APN. They all give me good service, but only ever LTE. Previously on both T-Mobile and Fi, on the same cell towers, I had 5g, so I know it's not a service issue. Mint support is the worst thing I've ever encountered in my life and they're useless as far as troubleshooting. Notably, the other phone on the plan is a stock pixel 7 pro and has the same issue, so I think it's a provisioning issue not a graphene issue, but I figured I'd ask the crowd here because of the general level of aptitude.

 

Part 1 of my Headscale and Traefik blog post seems to have gotten some good traction, so I just wanted to share with the community that I just published part 2!

 

Shameless self-plug here. I wrote a blog post to document my methodology after having some issues with publicly available examples of using Podman and traefik in a best-practices config. Hopefully this finds the one other person that was in my shoes and helps them out. Super happy for feedback if others care to share.

view more: ‹ prev next ›