I've been coding like *crazy* since this past Friday (got myself addicted to it somehow) and things for a "2.0" or a new project look good. The design of this version involves a complete re-write - separating the NSS API into the nss library and the MySQL calls into a multi-threaded daemon. In short:
1) Instead of each process handling its own connections to the server, they'll talk to the daemon via Unix sockets - open, talk, close; this is *far* easier to code
2) Instead of hundreds of MySQL connections, you'll only have as many connections open as you need to handle your query load. For example, the daemon may have 5 threads, also meaning 5 simultaneous connections the MySQL server. Queries are doled out between each thread as requests come in.
So far this has proven effective and fast. I'm really happy with the results so far. Right now I have passwd and groups (the hardest to get going) working with some minor testing under the hood. Right now I'm going to work on cleaning the code up, implementing shadow support, logging, and error handling. I'd like to publish a beta version soon.. if I keep this coding streak up, that should happen this week!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
sounds great... I'd vote for 2.0 since the "old project" should really never be used again (or be updated) as long as the "new project" works ok. I'd be willing to test beta versions if you'd like (heavily loaded mail server which sometimes can take 1000s of mails per mysql-timeout period, likes to push up the load via mysql processes).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The only reason I think about "new project" is because I can much more easily create daemons that talk to different SQL servers - e.g. postgres. I also want to implement a PAM module at some point .. and both of those go beyond the specific area that "libnss-mysql" implies ... But you're right, this new version really superscedes 1.3 ...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've got a functioning version in /home/groups/l/li/libnss-mysql/htdocs/new
You need to use 'nsvs' in /etc/nsswitch.conf, Edit /etc/nsvsd.conf to your needs, add the user 'nsvsd', and run /sbin/nsvsd ... nsvsd and user commands should log errors to /var/log/messages.
Let me know if you have any questions.
This "Release" doesn't do any sort of keepalive on the mysql connections .. I don't yet know what'll happen if one or more of the nsvsd threads loses contact with the MySQL server.
I've done some basic testing to make sure it works under various conditions, but it's definitely beta quality. I'm trying to figure out a project name for sourceforge ..
BTW "nsvs" stands for Name Service Via Sockets" .. the new project's scope may be as wide as an extensible, modular auth system for unix .. that goes beyond the current NSS (and possibly PAM) APIs. NSS just doesn't lend itself to network backends such as MySQL. We'll see ...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
How about /FSSOS/ - Flexible Single Sign-on Solutions - for a project name? I'm trying to think of something as generic as possible which could even encompass PAM modules and all different kinds of database backends.
I've continued working on the code, and discovered that 0.1 can block on socket read/write which could cause hung processes and thread starvation in nsvsd. It's not likely to happen under normal circumstances, however. I may post 0.2 tonight .. though I'd like to get command-line options for nsvsd first.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I will try it tomorrow in dev environment! Thanks!
Just one small suggestion (from "Missing arguments..." thread). Please try to think about new functionality. To catch some arguments by nss (e.g. to allowe someone to be authorized or not depend on service or some extra argument like domain). As you said nss "is stupid" so maybe it is senseless to do without PAM module (some modification of pam_unix). Any idea? It could be very great improvment for new project (and Flexible ;) )
New name is good. I like it. Or... what about remove "Single". I understand the idea of "single" but "Flexible Sign-on Solution" is easier to remember and more human readable ;)
Best regards,
Mszutko
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'll probably stick to FSSOS since that name's pretty unique (Doesn't show up on Google much ...)
Maybe I could add the ability to pass the current process name into the query string .. and maybe other stuff like hostname ... I can get the pid of the calling process, so if it's not too slow to get the basename of that pid, I could probably add that in ...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I just uploaded 0.2; the sample config should have had nss-root/rootpass .. socket communication is more robust, there are command-line options now (including debug/foreground ability), better syslogging, and who knows what else I changed :-)
Definitely use this version over 0.1
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I just submitted an sf.net registration request for a new project - fssos .. assuming that goes through (2 business days), I'll move stuff there .. I'll let you know.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Project FSSOS created and mostly ready to go. I posted 0.3 over there. CVS is ready and I've got a snapshot going. http://fssos.sf.net/
I'm removing the /new/ directory from this project ...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've been coding like *crazy* since this past Friday (got myself addicted to it somehow) and things for a "2.0" or a new project look good. The design of this version involves a complete re-write - separating the NSS API into the nss library and the MySQL calls into a multi-threaded daemon. In short:
1) Instead of each process handling its own connections to the server, they'll talk to the daemon via Unix sockets - open, talk, close; this is *far* easier to code
2) Instead of hundreds of MySQL connections, you'll only have as many connections open as you need to handle your query load. For example, the daemon may have 5 threads, also meaning 5 simultaneous connections the MySQL server. Queries are doled out between each thread as requests come in.
So far this has proven effective and fast. I'm really happy with the results so far. Right now I have passwd and groups (the hardest to get going) working with some minor testing under the hood. Right now I'm going to work on cleaning the code up, implementing shadow support, logging, and error handling. I'd like to publish a beta version soon.. if I keep this coding streak up, that should happen this week!
sounds great... I'd vote for 2.0 since the "old project" should really never be used again (or be updated) as long as the "new project" works ok. I'd be willing to test beta versions if you'd like (heavily loaded mail server which sometimes can take 1000s of mails per mysql-timeout period, likes to push up the load via mysql processes).
The only reason I think about "new project" is because I can much more easily create daemons that talk to different SQL servers - e.g. postgres. I also want to implement a PAM module at some point .. and both of those go beyond the specific area that "libnss-mysql" implies ... But you're right, this new version really superscedes 1.3 ...
project libpamnss-mysql-or-postgres :)
project librdbms-userinfo?
who knows, but good luck with it. just to be sure to put a link to the current page so we may help with beta testing.
I've got a functioning version in /home/groups/l/li/libnss-mysql/htdocs/new
You need to use 'nsvs' in /etc/nsswitch.conf, Edit /etc/nsvsd.conf to your needs, add the user 'nsvsd', and run /sbin/nsvsd ... nsvsd and user commands should log errors to /var/log/messages.
Let me know if you have any questions.
This "Release" doesn't do any sort of keepalive on the mysql connections .. I don't yet know what'll happen if one or more of the nsvsd threads loses contact with the MySQL server.
I've done some basic testing to make sure it works under various conditions, but it's definitely beta quality. I'm trying to figure out a project name for sourceforge ..
BTW "nsvs" stands for Name Service Via Sockets" .. the new project's scope may be as wide as an extensible, modular auth system for unix .. that goes beyond the current NSS (and possibly PAM) APIs. NSS just doesn't lend itself to network backends such as MySQL. We'll see ...
Woops, let me give you a URL not a directory lol
http://libnss-mysql.sourceforge.net/new/
How about /FSSOS/ - Flexible Single Sign-on Solutions - for a project name? I'm trying to think of something as generic as possible which could even encompass PAM modules and all different kinds of database backends.
I've continued working on the code, and discovered that 0.1 can block on socket read/write which could cause hung processes and thread starvation in nsvsd. It's not likely to happen under normal circumstances, however. I may post 0.2 tonight .. though I'd like to get command-line options for nsvsd first.
Hi,
I will try it tomorrow in dev environment! Thanks!
Just one small suggestion (from "Missing arguments..." thread). Please try to think about new functionality. To catch some arguments by nss (e.g. to allowe someone to be authorized or not depend on service or some extra argument like domain). As you said nss "is stupid" so maybe it is senseless to do without PAM module (some modification of pam_unix). Any idea? It could be very great improvment for new project (and Flexible ;) )
New name is good. I like it. Or... what about remove "Single". I understand the idea of "single" but "Flexible Sign-on Solution" is easier to remember and more human readable ;)
Best regards,
Mszutko
I'll probably stick to FSSOS since that name's pretty unique (Doesn't show up on Google much ...)
Maybe I could add the ability to pass the current process name into the query string .. and maybe other stuff like hostname ... I can get the pid of the calling process, so if it's not too slow to get the basename of that pid, I could probably add that in ...
I just uploaded 0.2; the sample config should have had nss-root/rootpass .. socket communication is more robust, there are command-line options now (including debug/foreground ability), better syslogging, and who knows what else I changed :-)
Definitely use this version over 0.1
I just submitted an sf.net registration request for a new project - fssos .. assuming that goes through (2 business days), I'll move stuff there .. I'll let you know.
*cough* I just uploaded 0.3 .. 0.2 had a stupid bug WRT default configuration variables and I cleaned up errors and warnings with newer GCC's ...
Project FSSOS created and mostly ready to go. I posted 0.3 over there. CVS is ready and I've got a snapshot going.
http://fssos.sf.net/
I'm removing the /new/ directory from this project ...
There's a mailing list for FSSOS now... I'm moving *all* discussion there. Please join up so I'm not talking to a wall :-D
I'm in... ;)
Mszutko