snapstore VS pbis-open

- from https://github.com/noise/snapstore/

the snapstore demonstrated there is no longer in the github repo, or compatible with snapd anymore https://github.com/noise/snapstore

The current Snap Store is not open source. The one you referenced is dead as proven by the repo you're article refers to: https://github.com/noise/snapstore/

If you're referring to the old HOWTO article for hosting your own snap store server, the software it used to do that stopped working several years ago.

That's nice and all, but besides the complete lack of official serversoftware that can be hosted by anyone, I'm going to guess that forcing another URL would mean that it uses that repo INSTEAD OF the official one. With regular package managers and Flatpaks, that's not the case. You can add repo's in ADDITION to the originals with those. The only mention of a self-hostable snap server that I can find, is this one. However, it is an unofficial server and has been depreciated. In other words: it's not compatible/functional with the latest version of Snapd (the clientside) anymore and will remain like that.

They used to have an example implementation here, though: https://ubuntu.com/blog/howto-host-your-own-snap-store https://github.com/noise/snapstore

interesting read. unfortunately, the 'snapstore' github project (here) that it links to now says:

Your link is an blogpost from 2016 that points to: https://github.com/noise/snapstore README: snapstore was a minimalist example of a "store" for snaps, but is not compatible with the current snapd implementation. As a result I have removed the contents here to avoid further confusion.

In fact, Bret Barker has published an open source (Apache License) SNAP store on GitHub. We’re already looking at how to flesh out his proof-of-concept and bring it into snapcore itself.

https://github.com/noise/snapstore/

Alright, so there's a lot of folks that are really happy joining Linux machines to AD Domains with https://github.com/BeyondTrust/pbis-open --- and up till kinda recently, that was a really reliable, viable way of allowing linux servers in a primarily Windows environment to benefit from AD Domain Login, including things like restricting login to certain groups, etc. From a higher-ed perspective, where the vast majority of systems (at least endpoints) are Windows and rely on AD for SSO login, this seems like an ideal solution.

I would say the same but for authentication.

We have linux servers on our domain, specifically becaeuse there are certain things they do better than windows, and im a tool for a trade kinda guy.

But authentication and management of creds is a hard requirement.

The rest i can work with. We setup Ansible to handle much of the day to day config things. GPO"s might be nice.

At one and for years i was using PBIS, and whatever it was called before it was bought out, forked and named PBIS - https://github.com/BeyondTrust/pbis-open

I liked it because it kept GID/UID's consistent across the domain. But it was flaky for samba shares specifically ad group enumeration. There are paid add-ons that leverage GPO but never went that route.

More recently we are just leveraging SSSD/Chrony/Smb/Nmb to do the same, there are a few tweaks, but its solid. Its actually more stable now.

Some GPO's would be nice I supposed.