Ineiev wrote: > Bob Proulx wrote: > > The problem with libnss-extrausers is that it works from files. It > > does not use the database. It requires the database to be dumped at > > some periodic frequency into files in order for those files to be > > updated from the live database with current. > > > > This introduces a delay between someone, say, adding a new member to > > their project group to give them commit access and then having that > > access available. > > No, it doesn't, because frontend code updates the file when new members > are added to the group.
There are several problems with requiring coupled database updates and external actions where both are needed. One is that it is difficult to scale. If implemented that way then currently this would need to push updates to vcs0, vcs1, vcs2, vcs3, download0, download1 for a total of 6 locations. That number is not always going to be the same number as we add new systems and obsolete old systems. It might be practical to put the file on a shared NFS mount but then that might introduce problems with NFS cache coherency across the systems. Ask anyone who has worked in such a space about "Stale NFS file handle" problems. I think this becomes a DRY Don't Repeat Yourself issue later if we ever introduce additional ways to modify the database. If the user account database were extended to cover other GNU projects. Such as if it were extended to audio-video which has added an additional server and is planning on moving over to the new system at some point. Currently this is shared on download0. But if the user account database is extended to other GNU systems like this then it means that those other systems if manipulating the database those would also have to be coded and given access to update those 6 (currently) other systems too. Centralized push actions almost always run into problems with not being able to push to all of the collection at some point. Invariably the network will be down or a system will be offline and it will miss a required update. That's one of the reasons pull systems are more robust. Usually a push system is augmented by also using a periodic pull to sync up. This also violates the paradigm of "LAMP" (or any variation of the concepts) with a web server executing a programming language using a database software stack. It introduces another required action step in that paradigm. One of the reasons that paradigm is so often implemented is that it is time tested robust paradigm. Requiring additional push actions to be taken after a database update creates a more complex system moving toward a Rube Goldberg system with many required parts that all much operate correctly. It's more complicated than just using the database directly. Simpler is most often the better design. Oftentimes when implementing something like this we just have to do it because there is no other way to do it. Or no other way to do so within our resources available. We do a lot of actions by cronjob for example which is one of the most terrible ways to do things but we do because we don't have a better way of doing them available. But in this case we do have direct database access available. When implementing a complex design of many interacting parts it's always problematic to document the design such that newcomers who arrive later can understand it. Other people will need to work with whatever is used and they will need to be able to understand it. Other people will need to be able to make future changes. Other people will need to be able to make future extensions. With a LAMP type of design they already know how things work and how to work with it. When there are special requirements implemented then being able to bring newcomers online becomes more of a learning problem. If there was a reason not to continue the libnss MariaDB library another well tested alternative is the libnss LDAP library. People already use that library other places. It's well tested. In discussion it is often asked why it isn't already being used. Since it is so typically used. We could move our user account data to an LDAP service. Then convert all of our services to using LDAP. A lot of people will probably wonder why we haven't done that already. For one it would be pretty disruptive to do it. It would be a lot of change all at once. And conceptually the result would be pretty much what we already have with the SQL database. So maybe one day. But it would be a lot of work to get there. > > Worse is if someone needs to REMOVE a > > malicious member from a project. In which case there would be a delay > > before that removal became in effect. > > My experience doesn't suggest that removing members is really more > urgent; however, the file is updated the same way when the members > are removed. I have been fortunate not to have a fire in my kitchen but just the same I still keep a fire extinguisher available for quick access. But unfortunately I have been called upon to immediately stop a malicious person from continuing activities ASAP. Security issues such as this is something that should be thought about. If there are multiple ways of implementing something and one of them has better security features, or the other worse, then that should push on the decision. > > Introducing user seen delays such as that would be a regression of > > functionality over not having any delays at all. Plus the > > libnss-mysql library already exists as a mature code base > > It's an unmaintained code base---you had to fix it, whereas > libnss-extrausers works out of box. Should I feel insulted that my maintenance is not acceptable? I have already been maintaining a local build of it for the past several Trisquel releases. The code is mature clean and well tested code already. It needs very little work. The environment around it changes. One of the most changing things is autoconf macros. The autoconf macros changing are the main source of required changes. And there are always going to be other things that one wants to improve. But the most important part of maintenance is not to screw it up! The APIs being used are mature and stable. The API that changed and is most likely to change again is the MariaDB client programming API and it also highly values backward compatibility and stability. MariaDB is an active community and if support for it were needed there is much support available. > > that we have been using (and therefore testing) for many years. > > Agreed. > > > Both the nss and > > the mariadb interfaces are mature, documented, relatively easy > > interfaces to use making this an easy code base to maintain locally. > > libnss-extrausers also uses the nss interface, and the file system > interface must be as mature and easy to use as mariadb; > libnss-extrausers-based setup is considerably simpler (e.g. > as a side effect, it avoids exposing the database access password > in yet another place). Using files and avoiding a database password to be present on the system is one less secret on the system. And the database password is one of the few Savannah unique secrets. But it does not eliminate the other system level secrets which must also be maintained. We must maintain the private ssh host keys. We must maintain the private system passwords. We must maintain the private https certificates. All of those things remain. The database password is only one of the entire collection of systems secrets. Bob
