• 1 Post
  • 13 Comments
Joined 4Y ago
cake
Cake day: Jan 21, 2021

help-circle
rss

The concern is that it would be nice if the UNIX users and LDAP is automatically in sync and managed from a version controlled source. I guess the answer is just build up a static LDAP database from my existing configs. It would be nice to have one authoritative system on the server but I guess as long as they are both built from one source of truth it shouldn’t be an issue.


Yes, LDAP is a general tool. But many applications that I am interested in using it for user information. That is what I want to use it for. I’m not really interested in storing other data.

I think you are sort of missing the goal of the question. I have a bunch of self-hosted services like Jellyfin, qBittorrent, PhotoPrism, Metabase … I want to avoid having to configure users in each one individually. I am considering LDAP because it is supported by many of these services. I’m not concerned about synchronizing UNIX users, I already have that solved. (If I need to move those to LDAP as well that can be considered, but isn’t a goal).


But the problem is that most self-hosted apps don’t integrate well with these. For example qBittorrent, Jellyfin, Metabase and many other common self-hosted apps.



LDAP to UNIX user proxy
Is there any service that will speak LDAP but just respond with the local UNIX users? Right now I have good management for local UNIX users but every service wants to do its own auth. This means that it is a pain of remembering different passwords, configuring passwords on setting up a new service and whatnot. I noticed that a lot of services support LDAP auth, but I don't want to make my UNIX user accounts depend on LDAP for simplicity. So I was wondering if there was some sort of shim that will talk the LDAP protocol but just do authentication against the regular user database (PAM). The closest I have seen is [the `services.openldap.declarativeContents` NixOS option](https://search.nixos.org/options?channel=unstable&show=services.openldap.declarativeContents&from=0&size=1000000&sort=alpha_asc&type=packages&query=services.openldap.declarativeContents) which I can probably use by transforming my regular UNIX settings into an LDAP config at build time, but I was wondering if there was anything simpler. (Related note: I really wish that services would let you specify the user via HTTP header, then I could just manage auth at the reverse-proxy without worrying about bugs in the service)
fedilink

This is my dream. However I think my target market is smaller and less willing to pay (personal rather than business). However maintenance is low effort and I want the product for myself. So even if it doesn’t make much or anything I think I will be happy to run it forever.

The ultimate dream would be to make enough to be able to employ someone else part time, so that there could be business continuity if I wasn’t able to run it anymore.


Video serving is a very sequential workload so hard drives will be more than sufficient and you can typically get storage at a lower price.

SSD may give you slightly faster start and seeking but it is unlikely to be noticeable.


If you want to serve multiple resolutions and bitrates you will probably want hardware that can do transcoding. However basically any graphics card (even integrated) will be able to transcode a video stream in real-time at a decent quality.

(If you wanted you can try to pre-transcode offline, but Jellyfin doesn’t support this well)


I ended up creating my own because I couldn’t find something that did what I want a few years ago when I started looking. My main requirement was easy scaling of ingredients. It has a handful of features around that such as scaling by specifying servings, scaling by setting the amount of a particular ingredient (example making pancakes with leftover buttermilk, pour the buttermilk into the bowl then scale the recipe based on how much was left) and ingredient conversion. In most other ways it is pretty basic and free-form but it does the job. It stores data in a user-provided provider so other people never send me their recipes.

https://recipes.kevincox.ca/


I don’t think you can pick out any one reason. XMPP is very old and has extensions for a huge variety of features. Many people have experience with older versions which had many major missing features (such as strong multi-device with offline support and server-side history) and a lot of the “hype” has died out long ago.

Matrix is new and made a lot of decisions that really helped its popularity.

  1. Having a HTTP-based client-to-server protocol makes web clients very easy to make.
  2. It is based on sync and merging rather than messages which moves some difficult problems (like multidevice and server-side history) into the core protocol meaning that it works well out of the box.
  3. Having HTTP based protocols make hosting it familiar for many people.
  4. The “default” Element clients have lots of features out of the box, features that for a long time were not always present on XMPP servers or clients. This gives a more consistent experience.

We will see what the history holds. Matrix is still very new and maybe the hype will die out and we end up moving back to XMPP. Or maybe something new. Overall I don’t think there are major fundamental differences. I think Matrix making graph sync the core primitive to build off of was a good idea, but in practice I don’t think it matters much.

You say that XMPP is much lighter. But I think that is mostly due to Synapse not being very efficient. Other implementations are fairly light. Even then my Synapse is using fairly small amounts of resources. You should also check that you are making an apples-to-apples comparison with large rooms, media and message history like you would typically see in a common Matrix server.


I would say podman by default. It has a better security architecture as it can run rootless.

However there are small differences from Docker so you may need use Docker if you are trying to run third-party services that rely on these differences.


You don’t need a domain. However it is probably a good idea.

  1. You can’t get a globally trusted SSL certificate for an IP address. So you will need to use a self-signed certificate and manage trusting it on every device.
  2. If you don’t have a stable IP you will need to update bookmarks whenever it changes and memorizing it may be a chore.

If you don’t want to purchase your own domain you can likely use a free subdomain, this will often come from a dynamic DNS provider.

However if you can I would strongly recommend getting your own domain sooner rather than later. If only because it means that you can own your email address which is basically the keys to all third-party services you use these days. Domains are pretty cheap, probably <$20/year for a generic like .com or the TLD of your country. Personally I would happy skip out on eating out once a year to have my domain.


The problem with separating Calendar + Mail + Contacts is that they work best together. Although to be far I am not aware of an open-source system that effectively combines them.

Calendar event invites an updates go over mail. So you want your calendar application to automatically be able to get those. Also options like “automatically add invites from contacts to my calendar” is an awesome feature. Contacts can also be used for spam filtering (although this integration is a bit easier to do externally).

So currently I am using Nextcloud (self-hosted) although I don’t really like it because it is pretty slow on my low-powered VPS. But even still it doesn’t actually have proper email integration. There are bugs open and slowly moving but I’m still using Thunderbird to process most of my calendar stuff.

Not to mention JMAP which is slowly progressing which would be a huge improvement, especially for mobile clients. It also combines these three services.


Well passwordless. But you can put it on an encrypted partition.