PriorProject @ PriorProject @lemmy.world

Just an explorer in the threadiverse.

---

Read more

Posts

9

Comments

266

Joined

2 yr. ago

I don't think it is more complicated than, e.g a VPS provider or a SaaS platform and a customer that wants to have run a server online or a managed application.

That's a very reasonable comparison, but to me the more relevant comparison is that of creating a commercial social media account or standard fediverse account today. This is much less accessible to users than that process, and also much more demanding on server admins.

I'd certainly be overjoyed to learn that I'm wrong and for this to revolutionize account mobility. But I don't see volunteer server admins lining up to facilitate DNS delegation for fun or users lining up to pay VPS prices for commercial hosting of their own social media domain. The bar for simplicity and usability for me is quite a lot higher than I see this sort of approach evolving to provide.

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.

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.

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.

Point 1 was indeed kinda a joke, but if you feel like that hurts the rule, I will remove it.

I feel like you wouldn't and shouldn't accept the justification from a commenter that their trolling was a joke. You also wouldn't consider it an improvement to make a racist joke alongside the rule against racism as a tongue in cheek way of illustrating the rule by counter-example. It simply is the thing the rule purports to disallow, which isn't a great joke and doesn't help the rule.

As stated in the rule, we will only remove posts if the title is wrong / incorrect, with that we mean that it misrepresents the article. The autobot can't sense that you editted the post to make it better, so I just wanted to make clear that the autobot will still message you.

I might suggest to extend the rule with something like: While de-clickbaiting and de-editorializing poor upstream titles with replacement factual titles is allowed, when in doubt using the upstream title is always sensible. Having the modbot inform people about title deviations by quoting the rule including the bit about de-editorializing seems reasonable.

Trolling is also not allowed, go back to reddit for that.

Telling someone to go back to reddit to troll is itself a mild form of trolling and fails to model the behavior the rule calls for. It contributes nothing to the meaning or clarity of the rule and the rule is better without it.

Sources should be as unbiased and reliable as possible Obvious right or left wing sources will be removed at the mods discretion.

This rule would be improved by listing media source bias/fact-checkers that the mods largely trust, even if they reserve the right to occasionally override public checkers. The ability to pre-screen a source with fair reliability is valuable to posters.

Post titles should be the same as the article used as source Posts which titles don't match the source won’t be removed, but the autoMod will notify you, and if your title is wrong / incorrect, the post will be deleted.

Even reliable news sources frequently editorialize their titles at this point. I'd appreciate a carve-out to de-editorialize a clickbait title, but I appreciate that title-matching is much easier to understand/enforce and that people are likely to try to abuse a de-clickbaiting clause to re-clickbait and bias their titles. If a culture where people modified titles to improve titles could be fostered, that would be neat.

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

Have you checked out the fanaticus.social communities here on Lemmy? They have a bot that scrapes some kind of data sources for multiple sports and posts game threads. Might not be what you're looking for, but might be interesting.

I went through that phase too, but people haven't widely adopted the idioms around immutable infrastructure for no reason. My LXC setup was more work to maintain and left me with much MUCH more upgrade uncertainty than my idiomatic/immutable container setup does. I have a deep understanding of both systems and both approaches and I would never go back to using LXC like VMs.

Others have pointed out that docker containers aren't idiomatically like VMs and you interact with them differently. Some workflow tips:

• Don't edit configs in containers. Mount your config files as a volume. Edit them from your host using your normal editor and restart your container when they change.
• Don't exec into your running container and then try to install debugging tools as you need them. Use a Dockerfile to build an image that has the debugging tools you need and launch your container using that.
• In general, mess with your container less while its running. Use dockerfiles, compose, and entry point scripts to set things up in your container so it's the way you want it on startup. While its running, just use docker logs to see what it's doing or run the occasional debugging command via exec if you must... but do more during container-build and startup and less after it's running. Rebuild and restart the container a lot during debugging to make your changes take effect.

The other issue in play here is that the fundamentals necessary to understand how docker containers run aren't actually docker fundamentals. They're:

• Networking fundamentals. The container networking stack is really configurable and really complicated.
• Volumes and config mounts are based on overlay filesystems.
• Lots of docker issues are related to complex security systems like Linux capabilities.
• All of these systems are configurable, and different docker setups use them different ways.

These things aren't trivial to learn, a thorough understanding of these things is the difference between a junior sysadmin and a senior one, and you WILL get exposed to them when things break. But step one in learning more is definitely to recognize that the hards parts of docker are rarely docker itself. Rather, the hard parts are their own thing. Figure out what Linux system you're struggling with and start learning about that and how docker uses it rather than narrowly focusing your research on docker itself. Anything focusing on the docker piece must necessarily gloss over the real foundations which are often very complex... so this will start you expose you to deeper material that you can assemble in your own mind into an understanding of your own specific docker setup.

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.

I don't recommend beginners to mess with rootless docker or rootless podman. Rootful podman is much more straightforward (though less well documented than docker).

Is there one bot account posting these, or one bot per community? Block the bot rather than the community.

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: https://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.

Another comment links an older article about freenom (the registrar that is having .ML taken away) losing .ga previously and a plan to delete millions of .ga domains that were being used for abuse. Presumably the .ML situation is another abuse cleanup, though I can't find confirmation.

That then leaves the question of whether the Lemmy instance that went down was correctly flagged for abuse (I heard it was focused on piracy?) or whether an appeal could get it back for them.

https://lemmy.world/comment/1547287

I've found several articles similar to this, but transfer of management of a TLD from one registrar to another generally shouldn't result in breakage of registered domains. And nothing in that article (nor any of the others I've found) suggest that Mali plans not to honor existing registrations (which all expire eventually anyway, so they have an orderly way to reclaim things by refusing renewal if they wish).

There's more going on here that hasn't been reported (or that I haven't found) yet.

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

I posted a comparison a short while ago: https://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.
• Tailscale has great client coverage for Linux, windows, Mac, android, and iOS.
• 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.

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.

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 semi-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 can 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. The app limitation again makes this a poor match for Nextcloud, but a good match for a standalone public filesharing system that you don't quite trust as much as your proxy.

Edit: If you want to get fancy you could even expose the same Nextcloud instance BOTH via tailscale for your own app use behind a basicauth proxy for semi-public sharing. It gets network protection in both cases, but basicauth is sort of kind of easy enough to grant semi-public access to.

This is the jerboa community, fwiw. Right-clicking and tabs are not things in Jerboa.