I feel like this needs a bit more polish before you start telling users it is ready. I see double menus, random logouts, and a bare bones feature set. Basically just a list of users with ability to send emails?
The monthly cost is mainly for support, hosting and email delivery. The support includes security updates for server and Drupal libraries, customer support via email and helping with import / export of member data (of course, due to GDPR and sensitive contact information, a processing agreement has to be signed and agreed upon)
Is there a repository (like an awesome-* list) of open-source self-hosted appliance apps like this? I'm sure there's an awesome-drupal list, but I'm thinking more like a list that might also include this and Discord.
It always baffles me when people don't do their research before releasing a project / product. A few months ago there was a guy releasing his own language called Flux...
> managing our associations' members with a spreadsheet program just wasn't suitable and we needed something better and easier
ok... what about not reinventing the wheel and using something like LDAP[0] and one of its many, many UIs? How is this different from all the other solutions?
You could probably hack something in day, hardcoding things like schemas, fields, and things like that.
But having something that is reusable requires more work than a day.
Just as an example, even handling ssl/tls is far from trivial (plain ssl vs startls, with certificate validation or not, with a custom CA or not), it took me easily a few days to understand the options python-ldap provides, expose the options in a clear manner in the config file, deal with errors to provide meaningful logs and properly test everything.
my guess is that many people/orgs they don't use LDAP directly: it's used as the backend to manage permissions, groups, metadata, etc. They prob use their own system that relies on LDAP to manage the details of their org.
And if you are a user, a new version with numerous fixes (including security ones) was just released.
Disclaimer: I'm the author of ldapcherry.
My motivation was indeed that the go to solution is phpLdapAdmin, which is basically ldapsearch/modify in a web UI. It's a bit too rough and open for general users IMHO.
Hopefully ldapcherry provides something simpler and a bit prettier for the users.
Also, it's quite common for IT environments to have an ldap server (OpenLdap or 389 directory) and Active Directory (or samba 4 in AD mode). A secondary goal was to manage both at the same time.
ldapcherry works both with AD and ldap, creating/modifying a given user in both directories. And it can actually be extended to support other backends.
A third motivation was to be able to manage "roles". It's quite common to have ldap/AD groups triggering access to one specific resource (ssh into prod servers with or without root access, access to the git repositories, access to log indexer, etc).
But requesting each group individually is a pain, and you end-up with a wild variety of groups set even between members of a given team. That's why ldapcherry has a notion of "roles" (group of groups): for example you click the "sysadmin" role and it will put you in the groups that grant you access to ssh, monitoring, logs, etc.
That being said, it has some limitations:
* The groups/roles are statically defined in a yaml file, so it's not really dynamic
* There is no real tooling to audit/normalize the backends content (for example after a role definition change)
* There is no mechanism to temporary delegate a role to a person
* There is only one "big" admin group, no notion of "this role can be set by this group, and this other role by this other group"
* There is no request/notification mechanism when a user requests approval for being member of a role
* I'm not completely sure how I could handle forgotten password for users more cleanly
* I'm not sure how the UI would look with hundreds of roles (probably not great since all roles will be displayed...)
These are clear limitations that makes ldapcherry not suited for large organizations, but it should work OK for small ones.
Also, right now, ldapcherry is mostly stateless. It doesn't need a DB, you just configure it and plug it to your ldap/AD, which means it's fairly simple to deploy. If I were to implement the previously mentioned items, it would probably require a DB, which would increase complexity, and I'm reluctant to do so. Maybe a pluggable module could do the trick, but I would have to create an API for such module in the existing code.
Lastly I'm a lone developer with limited skills, and this is a side project, so I don't always have the motivation/time to work on it.
I think these few explanations kind of illustrate why there is no decent ldap web UI ^^.
Hah, actually not, never heard of GoMembers before. I of course wanted to have as short url as possible, but "pino" with all common TLDs were taken. So putting "members" to the end seemed to make sense to me.
I feel like this needs a bit more polish before you start telling users it is ready. I see double menus, random logouts, and a bare bones feature set. Basically just a list of users with ability to send emails?
Wouldn't be more appropriate to describe this as a drupal plugin / extension?
Also, why would a extension / plugin cost monthly for CRUD type application? What kind of support do you provide?
The term that Drupal uses for these "full website" packages are "distributions": https://www.drupal.org/docs/8/distributions
The monthly cost is mainly for support, hosting and email delivery. The support includes security updates for server and Drupal libraries, customer support via email and helping with import / export of member data (of course, due to GDPR and sensitive contact information, a processing agreement has to be signed and agreed upon)
Is there a repository (like an awesome-* list) of open-source self-hosted appliance apps like this? I'm sure there's an awesome-drupal list, but I'm thinking more like a list that might also include this and Discord.
Edit: I meant Discourse. and I also answered my own question: https://github.com/unicodeveloper/awesome-opensource-apps
+1, a repository with proper indexing would be nice, but also a place where people can request such applications or find contributors.
search for awesome-selfhosted. one of the most comprehensive lists
Does the demo reset? Clicking around trying stuff resulted in the landing page showing not found?
Worth disabling the https://demo.pinomembers.com/admin/structure/member/settings page for the demo perhaps?
Yes, the site should reset every 15 minutes, please try again soon.
Not to be confused with the relatively well-known JavaScript logging library called Pino.
It always baffles me when people don't do their research before releasing a project / product. A few months ago there was a guy releasing his own language called Flux...
Or the Japanese chocolate.
In what format are the users stored? Is it just another custom database schema?
It's kind of pointless when it can't be integrated with bunch of other infrastructures that support common protocols like LDAP.
1. anything similar in python?
2. what is so special, about yet another membership management solution?
1. There is at least Tendenci: https://github.com/tendenci/tendenci
2. It's open source and Drupal 8-based, meaning it's easy to extend with current selection of Drupal modules and PHP libraries
> Pino is an open source web app built on Drupal
closes tab
I do love me a hint of scandal, but the whole "thou shalt not BDSM in your spare time" thing is a major turnoff.
Can you provide more context about whatever you're talking about?
They are referring to this.
https://www.inc.com/sonya-mann/drupal-larry-garfield-gor.htm...
http://lmgtfy.com/?q=drupal+sex+scandal
Having used drupal back in the day they definitely got the SM part right.
Never again.
> managing our associations' members with a spreadsheet program just wasn't suitable and we needed something better and easier
ok... what about not reinventing the wheel and using something like LDAP[0] and one of its many, many UIs? How is this different from all the other solutions?
[0]: https://en.wikipedia.org/wiki/Lightweight_Directory_Access_P...
I have been using OpenLDAP to manage users for like 10 years but what GUI/web based tool do you suggest for managing its data?
The only non complicated solution looks to be PHPLdapAdmin which I use but it is pretty much abandoned and a fork is keeping it alive.
Here's a new one (that I haven't personally used): https://github.com/kakwa/ldapcherry
You said many many UI but that one looks to be very basic which anyone can build in a day.
I really find it hard to manage LDAP without a intuitive clean UI and wonder why there aren't much demand for it.
Not really in a day.
You could probably hack something in day, hardcoding things like schemas, fields, and things like that.
But having something that is reusable requires more work than a day.
Just as an example, even handling ssl/tls is far from trivial (plain ssl vs startls, with certificate validation or not, with a custom CA or not), it took me easily a few days to understand the options python-ldap provides, expose the options in a clear manner in the config file, deal with errors to provide meaningful logs and properly test everything.
my guess is that many people/orgs they don't use LDAP directly: it's used as the backend to manage permissions, groups, metadata, etc. They prob use their own system that relies on LDAP to manage the details of their org.
And if you are a user, a new version with numerous fixes (including security ones) was just released.
Disclaimer: I'm the author of ldapcherry.
My motivation was indeed that the go to solution is phpLdapAdmin, which is basically ldapsearch/modify in a web UI. It's a bit too rough and open for general users IMHO.
Hopefully ldapcherry provides something simpler and a bit prettier for the users.
Also, it's quite common for IT environments to have an ldap server (OpenLdap or 389 directory) and Active Directory (or samba 4 in AD mode). A secondary goal was to manage both at the same time. ldapcherry works both with AD and ldap, creating/modifying a given user in both directories. And it can actually be extended to support other backends.
A third motivation was to be able to manage "roles". It's quite common to have ldap/AD groups triggering access to one specific resource (ssh into prod servers with or without root access, access to the git repositories, access to log indexer, etc). But requesting each group individually is a pain, and you end-up with a wild variety of groups set even between members of a given team. That's why ldapcherry has a notion of "roles" (group of groups): for example you click the "sysadmin" role and it will put you in the groups that grant you access to ssh, monitoring, logs, etc.
That being said, it has some limitations:
* The groups/roles are statically defined in a yaml file, so it's not really dynamic
* There is no real tooling to audit/normalize the backends content (for example after a role definition change)
* There is no mechanism to temporary delegate a role to a person
* There is only one "big" admin group, no notion of "this role can be set by this group, and this other role by this other group"
* There is no request/notification mechanism when a user requests approval for being member of a role
* I'm not completely sure how I could handle forgotten password for users more cleanly
* I'm not sure how the UI would look with hundreds of roles (probably not great since all roles will be displayed...)
These are clear limitations that makes ldapcherry not suited for large organizations, but it should work OK for small ones.
Also, right now, ldapcherry is mostly stateless. It doesn't need a DB, you just configure it and plug it to your ldap/AD, which means it's fairly simple to deploy. If I were to implement the previously mentioned items, it would probably require a DB, which would increase complexity, and I'm reluctant to do so. Maybe a pluggable module could do the trick, but I would have to create an API for such module in the existing code.
Lastly I'm a lone developer with limited skills, and this is a side project, so I don't always have the motivation/time to work on it.
I think these few explanations kind of illustrate why there is no decent ldap web UI ^^.
This site can’t be reached: demo.pinomembers.com unexpectedly closed the connection.
Is the domain name a play on GoMembers?
Hah, actually not, never heard of GoMembers before. I of course wanted to have as short url as possible, but "pino" with all common TLDs were taken. So putting "members" to the end seemed to make sense to me.
User / pass doesn't work.
Heh, someone decided to be funny and changed it. It should be fixed, please try again.
looks like bulma css