I want to fix our severely fragmented internal systems in a way to address the major inefficiencies we currently struggle with. Presently, everything is disjointed and you must join/sign up for every system separately. We use Freshbooks – an accounting system – to be our source of truth for whether or not a member is active and it’s disconnected from everything else including our key fob system, email lists, etc. This has made it difficult for us to do simple things quickly like add every active member directly to Skedda, our new schedule software. It also makes it painstakingly difficult and manual to figure out exactly who is or isn’t a B-share member.
@elrod started building us an LDAP system a while back and I’m eager to get a few more people working on the project to see this to fruition. The vision – all interactions with account(s) occur through the LDAP. LDAP is the source of truth for all member info including active billing, B-share, contact info, etc. Accurate info, easily accessible.
There are a few main components I see in this project; @elrod may have some other things to add from the work he’s done so far.
Establish LDAP system and document how backend interface for linking systems works. We can’t rely on the campfire lute stories forever and need to have some minimum knowledge so others can easily jump in to assist where needed. I think this part may already be done or close to done by @elrod.
Develop API scripts linked to actions that can be initiated in the LDAP for each of our systems. Scripts should be developed around actions that would be taken and be linked in the system in a way that makes taking action easy (I’m not familiar with LDAP systems, so not sure what this part would look like exactly). For example:
New member joining - create Freshbooks account with new user profile and recurring invoice profile, create Skedda account, add to atxhs-announce Google Groups, add to Mailchimp update list, create Discourse account and add to hax0r group, and assign key fob number.
Member pausing account - update associated recurring invoice profile in Freshbooks, disable Skedda account, update Discourse group from hax0r to hax0ris, and disable key fob. Similar but opposite for unpausing account.
B-share status - when requesting to become a B-share member, send invoice in Freshbooks; when requesting refund of B-share, send email to treasurer@atxhs.org to initiate refund. Potentially another action – verify B-share? A flag added to confirm payment based on status of Freshbooks invoice.
There are many other actions we could create in here as well, but I think these are the core 3 we should start with. Documenting any important lessons along the way (or even better, having a boilerplate script for future development) would be essential to make sure this project can be easily sustained in the future as new people work on it.
Develop new join form for our website that interacts with LDAP instead of Freshbooks. In addition to actions originating from LDAP to update other places described above, we need to develop the means to add into the LDAP via a form similar to what we have at https://join.atxhs.org/. We will have to add some additional fields like username and any other info needed to feed into the other systems created.
I’m able to serve as project manager on this – organize tasks, provide API keys/doc, code review/repo management, and anything else needed – I just don’t have the bandwidth to do the scripting myself and I lack a lot of knowledge when it comes to LDAP systems.
This is a vital project that is going to set us up to properly handle the kind of growth we really want to see for the space. If you are at all interested, speak up!
Historically the never implemented idea/construct of an authentication system for the hackerspace has been called BatPass. This LDAP system, that’s what it is. If I mention BatPass anywhere I’m talking about LDAP+whatever additions to it we had for it’s functionality, for example an interface or triggers and their scripts to get run to make changes on systems such as Freshbooks.
We currently have an LDAP backend using a bundle of software called FreeIPA. It is running and operational. The primary issues with it are the interface, which is very feature rich but a little excessive for the day to day responsibilities involved in member management. This can be fixed by creating a separate front end that calls the pretty straight forward api commands of FreeIPA to take care of user management. That management being creation, user enable/disable, groups, password resets, keycard assignment, and member information. Another must have interface would be one for password resets. Again, also not really complicated.
These features will obviously take more work to get going than wrapping up item #1. Creating the triggers to execute these wont be an issue, but writing the scripts to do the work will take some effort. Someone is going to have to learn a bunch of different APIs to make this happen. As long as they’re well documented that shouldn’t be terrible though.
This shouldn’t be very difficult. With item #1 completed most of the required utilities to make this work will be in place.
As for what I can contribute, I’m not sure. I’m getting to the point where I can finally get back to working on my own personal projects, I’m hoping with that I’ll be able to dedicate sometime each week, such as Software Saturday, in the pre-quarantine days.
When it comes to item #2, that’s where I feel most technically capable to contribute – I’ve done a good bit of work with REST APIs and Python scripting – but my big drawback is time. I’ve been looking at a lot of the relevant API docs already, so at the very least I can map out endpoints with params and docs for each action script and provide API keys. Hoping we’ve got another member familiar with scripting and APIs who would be interested in the helping with the coding there.
I have some familiarity with FreeIPA in a homelab context–I wanted to set up Kerberos-backed NFSv4 /home automounts but found the performance out of the box wasn’t good, didn’t feel like tuning it, and set it aside as too much effort for the return at the time. Similarly some LDAP experience through work & the Debian project, though those are generally AD, and OpenLDAP, respectively.
Anyway, I would be capable of helping out with this but also find myself rather time-limited, so I don’t want to overcommit to anything. I think I could have something rudimentary-looking but functionally OK in short time using my weapon of choice for this sort of thing, Python & Flask.
In my mind this would look like an LDAP-backed login page which allows admin users further access. Then, there would be a very simple landing page, with, say, a link to a new user form, search form, etc.
By the way, is there any intent for these password resets to be self-service, or something only done by an admin?
To me, the big remaining unknown for this project is the particular contents of all the forms. If that were to be nailed down, this seems to me like it would be a weekend-sized project.* Besides getting the forms hooked up to actually do everything, of course, as there could be a bit of a long tail there.
* The idealized kind where life doesn’t get in the way and you can actually dedicate the whole weekend to getting one thing done
That sounds pretty great to me @kkremitzki. I’m also familiar with Python and Flask so that perks my ears. I’ll go ahead and start mapping out the needed info for various forms we would be pushing to along with endpoints and docs, and maybe spin up a GitHub repo for this over the next week. It seems like time continues to be the most challenging piece here. This project is big and important enough that we’ve got on the agenda for our next board meeting to discuss whether this could be a paid gig or not. Would be good to know if some form of compensation would allow for a potentially accelerated timeline (which understandably it may not with other commitments).
Kurt would you be willing to do the API layer? I could help with an Expp/React front end on things, and would love to have a demo app I could open-source that was meaty enough to show “here’s how you set things up for a real productionizable app” but not so big that it’s hard to grok.
(Like Kurt, I’m a professional software engineer so the code would be reasonably clean, but like Kurt I couldn’t promise more than the barn-raising part.) I’ve done one-weekend builds successfully in the past, and if we can get a spec together that would be a lot of fun. As long as what we have is readable, decoupled and built on standard technologies, there are usually enough members who can come in to tweak or deal with a package upgrade though.
Sounds like the pieces are:
data store and ops
API layer
user-facing front end
connectors to e.g. trigger invoicing a member
(can be done manually) (admin interface for setting roles & approving accounts)
(I think this is done) (making the keyfob system work off the LDAP)
If a couple other people would commit to doing a two-day hackathon on some weekend next month, or one day on each of two weekends, I would as well.
A weekend hackathon sounds like a more plausible project for me than an open-ended implementation and support job, though I’d probably wind up doing more testing than actual implementation. I too am a professional software engineer – my current real-life project has the unheard-of luxury of 144kB of PROM, a web-scale thing is a little out of my wheelhouse
I’ve dabbled in google app engine and know just enough python to break things, but I write a mean bugreport.
That brings up an important question, is there hardware in the hackerspace on which this sort of thing would run? If not there, where? And if not there now, could there be in the future? Related: the recent discussion of aggregating 3D printer status, or e.g. sensor data (air quality is one aspect I’m interested in) and making that sort of data available for a hackerspace status page or dashboard.
144kB — living the high life over there! Testing is a super important aspect here so I think you’d still bring a lot to the table there @Jon.
I believe we have a server stack in the lounge by the coworking door that could do hosting (maybe already is), but @elrod would know the true answer on all that. A worthy thing to setup alongside this that would take hardly any time is adding the devices responsible (and any others) into my LogicMonitor portal where we can setup a dashboard with relevant metrics and alert routing for key systems. Once devices are in the portal, it’s easy for me to work on alerting and dashboard type stuff during my work day as I can justify it as working with the product . That would be useful in quickly knowing when something may be wrong with the system before someone has to report it. If anyone is interested in taking a deeper look at that, I’m happy to create read-only accounts for anyone that wants it. Just DM me the email you would want to use and I’ll make you one. I already put our logo in my portal and have RBAC set up with areas partitioned off ready to become ATXHS only.
Absolutely @Jon (re: volunteers doing middle of the night maintenance). Alerting could be set for any specific hours people are comfortable with and it’d also be a totally opt in sort of thing. We could also just use dashboards and not do alerting at all.
Our Discourse is indeed outside hosted. Not sure about other stuff. Key fob system is on an internal network, so that’s definitely hosted in-house.
sorry, I didn’t mean to disparage your LogicMonitor suggestion. It’s a good one, and I agree - we need to know things are working, and dashboards are cool.
I’m just voting that we minimize owned/onsite hardware that we have to maintain ourselves.
No worries @Jon, I didn’t take it that way I agree with what you’re saying. I don’t want to create longterm work for anyone as a result of anything we set up. My main goal is to minimize effort needed longterm and maximize capabilities. Right now, I don’t think we’re well equipped from an administrative standpoint to handle a lot of growth. This LDAP project is a key factor in that IMO.
new members may have already been hax0rish Discourse users, so “New user created in Discourse and assigned to hax0r group” should have an alternative action like “move existing Discourse user from hax0rish to hax0r”
Ah, good point @Jon. That should check for membership in hax0rish or Member2B and remove either/both of those. Good catch, updating…
Realizing there is another complication of the potential they are already a user in Discourse, in which case it wouldn’t be a new user at all. It would probably be good for us to have on the join form a checkbox to say whether or not you already have an account on Discourse and ask for the username so we have that linked in the LDAP. We could then use that to query what groups they belong to.
Also, we should keep in the backs of our minds that we’ll want to add classes to this system at some point. There’s only so long (from a growth perspective) we can keep access control on the honor system.
For example: When I complete the Red laser class, the instructor adds me to the Red group, which gives me access permission to the Red PC (and allows my keyfob to power up the machine, if we go that route) and allows me to book Red time on Skedda.
Very true! I’m thinking longterm we’ll utilize tags in Skedda to limit who has access to what spaces for scheduling (since we’ve decided to keep this new system moving forward to replace the Google calendars for lasers, CNC, etc.). Maybe there would be an additional level of user login to the LDAP for teachers where they could mark students as having completed a class? We’ve moved towards putting more responsibility in the hands of teachers (as well as more money – currently class fees are 90/10 split for teacher/ATXHS) which means there isn’t currently a centralized system everyone is asked to use. Maybe that will change in the future, but that’s where things currently stand there.
Testing is a super important aspect here so I think you’d still bring a lot to the table there 
. That would be useful in quickly knowing when something may be wrong with the system before someone has to report it. If anyone is interested in taking a deeper look at that, I’m happy to create read-only accounts for anyone that wants it. Just DM me the email you would want to use and I’ll make you one. I already put our logo in my portal and have RBAC set up with areas partitioned off ready to become ATXHS only.