PriorProject

@PriorProject@lemmy.world

• ⁨Comment⁩ on ⁨Performance, memory and CPU usage tests of Tailscale, Netbird, Zerotier⁩ ⁨⁨1⁩ ⁨year⁩ ago⁩:

  Another user posted the blog where they discuss their speedup techniques: tailscale.com/blog/more-throughput/

  It’s likely that the kernel version can use similar techniques to surpass the performance of the userspace version that tailscale uses, but no one has put in the work to to make the kernel implementation as sophisticated as the userspace one.

• ⁨Comment⁩ on ⁨How to help the community⁩ ⁨⁨1⁩ ⁨year⁩ ago⁩:

  Like helping to find a bug, discussing about how to setup an application for a certain use case or anything like that? Answering questions on Stack overflow is an example but is that the best way?

  Generally the best way to help out is to do a thing that’s needed and that you can figure out how to do. Your list includes a bunch of good options, and I’ve been thanked for doing all those things at one point or another. Some common growth paths include:

  1. Using the software
  2. Encountering bugs, problems, or small opportunities for improvement.
  3. Discussing those informally in forums and helping people find workarounds.
  4. Identifying some of those issues as common things other things experience as well, so filing bugs for them with clear explanations and links to related forum discussions.
  5. Reading source code to better understand bugs.
  6. Discussing potential fixes in developer bug threads (or in GitHub or whatever).
  7. Submitting small fixes for simple bugs as pull requests.

  Another path might be:

  1. Using the software and reading forums/docs for help.
  2. Answering basic questions on forums, looking to old threads and relevant docs.
  3. Learning about common questions.
  4. Writing blogs or forum posts about common questions.
  5. Submitting improvements to official docs to clarify common areas of confusion.

  There are other paths as well, the main thing is to use a thing so you learn about it and then use that knowledge to make it a little easier for the next person. Good luck!

• ⁨Comment⁩ on ⁨HyperDX – open-source dev-friendly Datadog alternative⁩ ⁨⁨1⁩ ⁨year⁩ ago⁩:

  I had a look through the comments on this HN thread the other day and came away more intrigued by github.com/openobserve/openobserve than hyperdx. Hyperdx is built on top of clickhouse whereas open observe has it’s own storage engines based on parquet files that can be accessed from local disk, S3, or a few other protocols.

  I haven’t tried either option yet… I’m, currently using netdata for metrics and don’t do anything special for logs or tracing, but at tiny self-hosting scale I often find software with it’s own storage engines (often sqlite) to be extra hassle-free. I’m curious to kick the tires on openobserve for that reason.

• ⁨Comment⁩ on ⁨What was your experience climbing the career ladder in tech?⁩ ⁨⁨1⁩ ⁨year⁩ ago⁩:

  I don’t think titles directly transfer between companies, and yet the industry allows it. It’s a very useful tool for advancement.

  This may be true on some corners of the industry, but at the more competitive end (both in terms of competitive pay, and a competitive pool of candidates)… I believe it’s common to relevel on hire. I’ve seen folks go from director to senior and from senior to junior at my org. The candidates being offered those seemingly big “demotions” often seem to be somewhere between unphased and enthusiastic about the change, presumably because the compensation package we offer at the lower level beats what they were getting with an inflated title and because they know their inflated title is nonsense and they’re frustrated with the other aspects of organizational dysfunction that accompany title inflation at their current company.

  What you say is real, and sometimes a promotion in one org can help bridge you into an org that would have been hard to get hired into as a junior, or harder to get promoted in. It’s not without risk though. All things being equal, I’d much rather spend my time working on a strong team and learning a lot and being challenged than to be in a weaker org that’s handing out inflated titles. Getting gud isn’t a guarantee of advancement, but it’s at least as reliable over the long haul as title inflation.

• ⁨Comment⁩ on ⁨Mullvad and Tailscale Announce Partnership⁩ ⁨⁨1⁩ ⁨year⁩ ago⁩:

  I don’t know what’s up on your case, but I would not jump to the conclusion that it’s impossible to use tailscale with any other VPN in any circumstance.

  Rather, tailscale and Mullvad will now work easily and out of the box. For other VPNs, you may need to do understand the topology and routing of virtual devices and have the technical ability and system permissions to make deep networking changes.

  So I’d expect one can probably find a way for most things to coexist on a Linux server. On a non-rootrr android phone? I’m less confident.

• ⁨Comment⁩ on ⁨Question about Vaultwarden⁩ ⁨⁨1⁩ ⁨year⁩ ago⁩:

  So I have a question, what can I do to prevent that from happening? Apart from hosting everything on my own hardware of course, for now I prefer to use VPS for different reasons.

  Others have mentioned that client-caching can act as a read-only stopgap while you restore Vaultwarden.

  But otherwise the solution is backup/restore. If you run Vaultwarden in docker or podman container using volumes to hold state… then you know that as long as you can restart Vaultwarden without losing data that you also know exactly what data needs to be backed up and what needs to be done to restore it. Set up a nightly cron job somewhere (your laptop is fine enough if you don’t have somewhere better) to shut down Vaultwarden, rsync it’s volume dirs, and start it up again. If you VPS explodes, copy these directories to a new VPS at the same DNS name and restart Vaultwarden using the same podman or docker-compose setup.

  All that said, keeypass+filesync is a great solution as well. The reason I moved to Vaultwarden was so I could share passwords with others in a controlled way. For single-user, I probably wouldn’t have botherer to stop using ng keypass. For a single-user setup, I prefer how keypass folders work and keepass generally has better organization features.

• ⁨Comment⁩ on ⁨Does anyone know why lemmy.world is not appearing on lemmyverse?⁩ ⁨⁨1⁩ ⁨year⁩ ago⁩:

  And just today with a comment by a world admin! Hopefully they’ll get it sorted soon.

• ⁨Comment⁩ on ⁨"Support" containers - centralized or separate per service?⁩ ⁨⁨1⁩ ⁨year⁩ ago⁩:
  1. If a service supports sqlite, I often will use that option. It provides everything a self-hoster needs from a DB with basically no operational overhead.
  2. If I do need a proper RDBMS (because the software I’m using doesn’t support sqlite), I’m going to use…
     1. A single Postgres container.
     2. Configured with multiple logical “databases” (the container for schemas and tables), one DB for each app connecting.

  I do this because I’m always memory constrained and the rdbms is generally the most memory-hungry part of any software stack. By sharing one db-process across all the apps that need it I get the most out of my db cache memory, etc. And by using multiple logical db’s, I get good separation between my apps, and they’re straightforward to migrate to a truly isolated physical DB if needed… but that’s never been needed.

• ⁨Comment⁩ on ⁨Vaultwarden Users: Folder Unassignment Bug?⁩ ⁨⁨1⁩ ⁨year⁩ ago⁩:

  I use postgres for my install and had a similar thing happen to me. I tried moving an org credential to a folder, which moved the folder to the org, and kicked all other credentials to “no folder”.

  Thanks for confirming with your DB. That saves me sweating whether I should rebuild on PG at least, and also makes me feel better that it’s a folder bug and not generalized database corruption.

  Having finished the heavy organizing, my rate of big org transfers has slowed and I haven’t reproduced again yet. Hopefully this will be uncommon enough to be a non-issue. Thanks again for the info.

• ⁨Comment⁩ on ⁨Vaultwarden Users: Folder Unassignment Bug?⁩ ⁨⁨1⁩ ⁨year⁩ ago⁩:

  Thanks for the suggestion, but Sync seems to be working ok… at least on the read side. I was able to verify the pre-existing good state and the bad state afterward from multiple clients. If sync played into it, it must have been on a write somehow.

• Vaultwarden Users: Folder Unassignment Bug?
  Submitted ⁨⁨1⁩ ⁨year⁩ ago⁩ to ⁨selfhosted@lemmy.world⁩ | ⁨4⁩ ⁨comments⁩
• ⁨Comment⁩ on ⁨Have I been DoS'd?⁩ ⁨⁨1⁩ ⁨year⁩ ago⁩:

  A very common DDoS attack uses UDP services to amplify your request to a bigger response, but then spoof your src ip to the target.

  Having followed many reports of denial of service activity of Lemmy, I don’t think this is the common mode. Attacks I’d heard of involve:

  • Using regular lemmy APIs backed by heavy database queries. I haven’t heard discussion of query rates, but Lemmy instances are typically single-machine deployments on modest 4-core to 32-core hardware. Dozens to thousands of queries per second to the heaviest API endpoints are sufficient to saturate them.
  • Uploading garbage images to fill storage.

  Essentially the low-hanging fruit is low enough that distributed attacks, amplification, and attacks on bandwidth or the networking stack itself are just unnecessary. A WAF is still a good if indeed OPs instance is getting attacked, but I’d be surprised if wafs has built-in rules for lemmy yet. I somewhat suspect one would have to do the DB query analysis to identify slow queries and then write custom waf rules to rate limit the corresponding API calls. But it’s worth noting that OP has provided no evidence of an attack. It’s at least equally likely that they dos’ed themselves by running too many services on a crappy VPS and running out of ram. The place to start is probably basic capacity analysis.

  Some recent sources:

  • sh.itjust.works/post/2732891
  • lemmy.world/post/2923697
• ⁨Comment⁩ on ⁨Nextcloud on VM or Docker? Best set-up for proper backups?⁩ ⁨⁨1⁩ ⁨year⁩ ago⁩:

  Docker is a powerful tool to increase confidence in your backups.

  • In a VM, the way you figure out which files to backup is to read the docs. If they’re wrong or you misread them, the only way you’ll find out is by doing a full restore test… which is often painful and complex in home setups.
  • In docker, the filesystem outside volumes is destroyed between every container restart. If your volume setup is insufficient, you’ll repeatedly lose state during your initial installation process between container restarts. You’ll continually test your state management throughout the lifetime of the service during restarts. This leaves a much smaller window for backup mistakes.

  The tradeoff with docker is that the networking is complex (well, everything is complex… but the networking is where it often hurts). But if you’re able to deal with that one-time pain, it’s superior almost all the time for home setups. I think the only things I run outside docker are ssh and netdata. SSH because it’s stateless and works perfectly out of the box, and netdata because it wants permissions to everything… and is functionally stateless for me because I don’t care if I drop my observability data.

• ⁨Comment⁩ on ⁨Jitsi meet...what are the advantages of self-hosted in this case?⁩ ⁨⁨1⁩ ⁨year⁩ ago⁩:

  The Foundry VTT community frequently uses video conferencing for tabletop roleplaying games and initially Jitsi was the recommended self-hosted video option, but the community has since moved on and now recommends livekit.io. I didn’t set up either and don’t have deep insights into what drove the shift, but it’s an interesting data point around a community that tried both shifting focus away from Jitsi.

• ⁨Comment⁩ on ⁨Caddy subdomain reverse proxy performance⁩ ⁨⁨1⁩ ⁨year⁩ ago⁩:

  I can’t remember if it’s enabled by default or not, but it’s easy enough to enable pprof and get a helpful performance profile from /debug/pprof. See caddy.community/t/hangs-on-reload/12010/18 for an example.

  I’ve found that even being unfamiliar with the codebase, it’s often pretty easy to identify what part of the call stack is being slow and file a very useful performance but report in GitHub. Check out the profile and see if it leads to any obvious conclusions about why domains are so much slower. There may be some function that’s trivial to cache the results of that brings things back to the expected performance.

• ⁨Comment⁩ on ⁨fediverse services - links⁩ ⁨⁨1⁩ ⁨year⁩ ago⁩:

  It’s not guaranteed that every federated app integrates with every other federated app in a particularly useful way. You kind of need to take it on an app by app basis:

  • Kbin and lemmy integrate very well. “Magazines” on kbin show up as communities in lemmy. You have almost certainly already read and responded to posts and comments from kbin users, and you may have subscribed to communities on kbin.social, the largest kbin instance. Interacting between the two is pretty much seamless.
  • Mastodon and Lemmy integrate, but less completely. If you’ve seen a post full of #hashtags and with an @thecommunity@instance mention, that’s probably from a mastodon user. I’m not sure how a lemmy user can initiate contact with a mastodon user, but a mastodon user can at-mention a lemmy community as if it were a mastodon user and doing that will create a lemmy post. Comments on the lemmy post look like replies to the mastodon toot.

  Other fediverse projects will interact in varying specific ways, and you need to figure each pair out individually.

• ⁨Comment⁩ on ⁨Notes from a Mastodon migration⁩ ⁨⁨1⁩ ⁨year⁩ ago⁩:

  Fair enough. The level of close coordination required between takahe server admins and domain owners seems to make domain migration at-scale somewhere between very expensive and simply prohibitive relative to self-service account sign up though. And I’m not sure I see a clear path to resolving that issue, though it’s certainly an interesting project even if it can’t deliver domain mobility at scale.

• ⁨Comment⁩ on ⁨Source for tutorials and a question?⁩ ⁨⁨1⁩ ⁨year⁩ ago⁩:

  I acknowledge it’s all surely basic but I’m not sure where to find a comprehensive source of learning instead of googling bits and pieces.

  I think a challenge you are likely to run into is that self-hosting many services really ISN’T basic, and there simply aren’t comprehensive sources… and really can’t be. It’s too varied and complex. Every network environment is different, and every network environment is so complex that it takes a networking expert to understand. No tutorial can cover all the possibilities, or even help you figure out what scenario you’re in.

  As an example, I’m currently migrating from docker-compose to podman-kube-play for my container management. I’m a a professional engineer who works with containers every day, and I’ve spent the better part of a week trying to get my first non-trivial container to run.

  • I’ve had to read tutorials to see how to get started.
  • I’ve had to read podman docs to see what k8s config options are supported.
  • I’ve had to read bug reports and examples from people using podman to see how specific features get strung together for complex use-cases like mine.
  • Even after getting many things right, DNS resolution didn’t work in my container. I spent many hours researching and found nothing. I finally had to start installing debugging tools like dig and nmap in my container to find that I couldn’t speak to the DNS server at all. I eventually found firewall logs showing that UFW was blocking the traffic from the container to the DNS server. UFW has nothing to do with Podman. Arch and Fedora users would not have been affected by this issue. Ubuntu users like me still wouldn’t have been affected if they were using host-networking or rootless podman. My specific environment and use-case was affected.

  There is simply no single resource on the internet addressing my personal scenario. To get to the bottom of it, I had to know enough about podman, k8s, DNS, networking, firewalls, UFW specifically, where interesting data on my system tends to get logged, and enough about “normal” logs to sift through the garbage and find the logs that lead me to a solution.

  So I recommend switching your perspective. Stop looking for a one-stop-shop that doesn’t exist. Instead, try to learn when the thing you’re trying to do is really 5 different things lashed together with duct tape. Then start deep-diving on each piece until you know enough about that thing to relate it to your specific environment and move on to the next thing. This is time consuming, especially as you’re getting started… but it’s fractally deep and remains time consuming forever as you continue to learn new things and aspire to do more complicated stuff. This breaking down of complex topics into a series of simpler (but not necessarily simple) topics is the hallmark of every successful engineer I’ve ever met.

• ⁨Comment⁩ on ⁨Notes from a Mastodon migration⁩ ⁨⁨1⁩ ⁨year⁩ ago⁩:

  If you are not happy with the server, you just move to a different service and get your domain to point to the new server.

  I’m just learning about takahe now, but it very much looks like domains are the remit of server admins, not users. Setting up a domain appears to require admin-privileges on the computer running takahe, not something that an individual user or non-admin group of users can do. So it seems to me that takahe doesn’t facilitate users controlling domains and improving mobility of domains between different servers controlled by different admins, but rather appears to be a tool for a given admin-team to segment their users and move them around among the group of servers they control.

  I could very much be missing something here, this doesn’t seem to be a scalable approach to server mobility or a way to extricate yourself from an admin team you’re in conflict with.

• ⁨Comment⁩ on ⁨Mold: A Modern Linker⁩ ⁨⁨1⁩ ⁨year⁩ ago⁩:

  I read the design notes and found them pretty interesting even though I haven’t really been pining for a faster linker: github.com/rui314/mold/blob/main/docs/design.md

• ⁨Comment⁩ on ⁨How to make players more averse to fights?⁩ ⁨⁨1⁩ ⁨year⁩ ago⁩:

  I’m struggling with overly confident players.

  Why do you say they’re overconfident? Are they consistently winning fights without an opportunity cost? If so, then I would say their confidence is well placed. The fact that you jumped straight from overconfidence to character death suggests to me that you may be missing a more progressive range of costs and therefore haven’t been giving them any reasons to consider alternative solutions.

  • Are enemies one-dimensional? Can the players imagine interacting with them in ways other than fighting? A powerful noble they suspect but cannot prove is breaking the law is a different kind of enemy than a slavering beast. One can easily imagine the downsides of walking into the nobles manor and slicing them in half.
  • Do enemies have value beyond the loot on their corpse? Information is a common prize to dangle, find a way to talk to them (perhaps still after non-lethal combat) to gain some critical insight. Bounties for capture alive can spark some out of the box thinking, as can humanizing some enemies and introducing allies who advocate for negotiation and reform over eradication… the value of a non-lethal approach may be the favor of a powerful ally.
  • Does time matter? Resting 10m to recover lost HP in the middle of a chase has consequences for the chase. Maybe we have more important things to do than murder every passerby when we’re on the clock.
  • Collateral damage? Force a fight on home turf on the enemies terms. Victory could have a serious cost when the fight has been brought to you.
  • Do you employ loss without death? A training-wheels consequence of underestimating danger is capture or loss of gear. There are lots of ways for a fight to go wrong that don’t result in character death.
  • Do you give rewards for non-combat solutions? Ensure that solving problems outside combat earns XP/loot on par with the violent approach unless it’s a rare quest with a theme of selflessness.

  Finally, consider just telling them that a fight would be dangerous and could result in death. We forget that the characters are seasoned adventurers and the players may not be. If the players lack an accurate intuition for the difficulty of a fight, let them know that their characters can judge the danger more accurately and fill them in. I did this without even a hint of an in-world justification with a first over-leveled dragon fight in a previous D&D campaign, warning the players directly that it wasn’t a fair fight and they would likely pay a serious price for rolling the dice an hoping their numbers were bigger. This really changed their mindset and they began gathering intel and negotiating and planning how to tip the odds back in their favor through skullduggery.

  In any case, I’d encourage to ask thoughtfully whether their confidence is genuinely misplaced or if you’d telegraphed to them that success is inevitable. If so, talk to them directly about a change in danger level, and start telegraphing it in multiple ways so they can see when other paths are available or advisable.

• ⁨Comment⁩ on ⁨Where can I learn Docker fundamentals?⁩ ⁨⁨1⁩ ⁨year⁩ ago⁩:

  Rootless podman (or docker) is a very different thing that adding yourself to the docker group. Rootless is an advanced topic that makes networking and other fundamental aspects of the container runtime work differently so it’s harder to exploit the runtime itself. Adding yourself to the docker group just gives your account permission access the docker daemon running as root… which is a much less fundamental change.

• ⁨Comment⁩ on ⁨How does having multiple lemmy servers spread the load?⁩ ⁨⁨1⁩ ⁨year⁩ ago⁩:

  A Lemmy server primarily does two kinds of work:

  • Serve browse traffic: This is what you’re familiar with, when you view your post feed or a single post, the server has to fetch those posts or comments from its database and send them to you. The resources required to do so depend on the total number of browse requests the server handles… roughly num_users * num_feed_refreshes_or_post_views_per_user_per_minute. If a server has a lot of users that view a lot of stuff, splitting some of them off to a second server (or just stopping signups) will help. Federated replication: This is what copies posts and comments from the server that hosts the community to the server that hosts your account, and what enables your account server to bear the browse load for communities hosted on this server. The resources required to do this work are roughly proportional to the total number of federation messages sent, or number_of_federated_peer_serverd * number_of_subscribed_communities_per_server * number_of_posts_comments_votes_edits_etc_per_community.

  What you may see here is that federation replication workload scales with the number of instances in the threadiverse and browse workload scales with the number of users per instance. This leads to a goldilocks problem. Ideally, you want a medium number of servers that each have a medium number of subscribers. Obviously no real world network scales in this ideal way, but some guidelines emerge:

  • Single user instances are probably only a net win if the user is very active. If you read every post your instance subscribes to then maybe your browse load is bigger than your instance’s federation load… but if you log in once a month and view 1% of the posts replicated to your instance… it’s still generating federation workload while you’re asleep for posts you’ll never read.
  • Single-user instances using scripts that mass subscribe to thousands of communities, while they make your all feed lively… make you a pretty terrible fediverse citizen. Your instance is now generating the federation load of a 5k user instance to copy posts and comments you’ll never read. BTW, your instance publicly serves copies of all the posts you subscribe to. So if one of these scripts subs porn, piracy, or hate speech communities on poorly admin’ed instances, it may be creating legal liability for you depending on your jurisdiction. Also, federated replication is pretty broky right now: github.com/LemmyNet/lemmy/issues/3101 (this recently got marked resolved but I continue to see replication issues daily and I expect similar but perhaps more targeted follow ups.to be filed soon)
  • Having an account on a Very Big Instance like lemmy.world or lemmy.ml is a bit of a personal risk. Those instances will always find the limits of both browse and federation scaling first because they have lots of active users and also lots of active communities that are widely subscribed by other instances. This will make them a bit unreliable as they’re at the tip of the efforts to fix scaling constraints.
• ⁨Comment⁩ on ⁨Hey selfhosters, what are you selfhosting?⁩ ⁨⁨1⁩ ⁨year⁩ ago⁩:

  Thanks for the insights. I’ll see how it goes.

• ⁨Comment⁩ on ⁨Netbird vs. Tailscale⁩ ⁨⁨1⁩ ⁨year⁩ ago⁩:

  I posted a comparison a short while ago: lemmy.world/post/1452988

  I recently decided on headscale as a coordination server with tailscale apps/clients for my setup. My rationale was:

  • Tailscale seems to be dominating adoption. This isn’t a technical consideration but it often correlates with project velocity going forward.
  • Headscale the self-hosted server is unofficially but decently supported by tailscale the company. They employ the dev and don’t seem to be trying to kill the project or mess with it much. It includes most features useful to selfhosted installs, but reserves multi-network setups as the domain of the official tailscale coordination server which strikes me as a pretty reasonable way to segment the market.
  • I didn’t do a point by point feature comparison, but my sense was that tailscale/headscale meet or beat the featuresets of other projects, so I didn’t see any technical reasons to buck against community momentum.
• ⁨Comment⁩ on ⁨Hey selfhosters, what are you selfhosting?⁩ ⁨⁨1⁩ ⁨year⁩ ago⁩:

  Initially I was using rocky+podman but inevitably hit something I wanted to run that just straight up needed docker and was too much effort to try and get working. 🤷

  Can you clarify some of the things you got stuck on with podman? I currently have a docker-compose based setup that I’m pretty happy with, but am rebuilding and am planning to experiment with podman play with k8s-style manifests as an alternative to compose. It’s still not clear to me whether podman is going to simplify my life or make it worse compared to docker and compose, and I’m curious about your insights and why you backed off from that architecture.

• ⁨Comment⁩ on ⁨Two Nextcloud instances for security?⁩ ⁨⁨1⁩ ⁨year⁩ ago⁩:

  Thread parent’s approach is what I would use as well. It makes lot of sense to isolate something as sprawling and with as large an attack surface as nextcloud… but that implies you can’t use it for public sharing. Any use that that DOES involve public sharing creates an incentive to choose a smaller and more auditable codebase (not that you’ll necessarily audit it yourself, but simplicity does have benefits here).

  Another approach I’ve used with public services is to stick them behind a proxy I trust like Caddy or nginx and gate access to them with https basic auth. Basic auth rightfully gets dismissed in many security contexts, but in the case of personal self-hosting it case serve a useful purpose. The proxy handles the basic auth, and no network packets can reach the protected application until basic auth is complete, which completely protects against unathenticated exploits in the protected application (though obviously exploits against the proxy would still work, but major proxies are pretty well hardened). The major downside here is that you can’t really use mobile apps, as none of them support this niche and frankly dubious approach to network access control. But for public sharing, you’re almost certainly having folks use a browser as their client rather than an app, and for the small convenience overhead of the basicauth login you get a pretty significant reduction in unauthenticated attack surface.

• ⁨Comment⁩ on ⁨rule⁩ ⁨⁨1⁩ ⁨year⁩ ago⁩:

  I thought that was the first rule of rendering web content? Or was it protocol parsers?

  I remember, it was first rule of video game character creation screens:

  choose wisely: wisely