Re: PAM LDAP in FreeBSD, and userfs too.
On Thu, Jul 22, 1999 at 10:58:59PM -0700, John Polstra wrote: In article [EMAIL PROTECTED], Dominic Mitchell [EMAIL PROTECTED] wrote: On Thu, Jul 22, 1999 at 04:59:59PM +0700, Max Khon wrote: PAM is also "using masses of weird shared objects" but nevertheless it's quite usable By statically linked binaries? Our PAM implementation works for static binaries too. See the sources for the gory details. Basically it creates a library that includes all the possible modules, and selects the right one at runtime. There's some linker set magic involved. Ooh! Cunning! Concerning "masses of weird shared objects," you'd really better get used to it. It was the wave of the future 10 years ago. It's not going away. Dynamic linking provides flexibility and modularity that you just can't get from static linking. Very right. I didn't say it was a bad thing, just confused me for a while when I first saw it... However, I still (personally) prefer the idea of a filesystem interface... -- Dom Mitchell -- Palmer Harvey McLane -- Unix Systems Administrator In Mountain View did Larry Wall Sedately launch a quiet plea: That DOS, the ancient system, shall On boxes pleasureless to all Run Perl though lack they C. -- ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. ** To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PAM LDAP in FreeBSD, and userfs too.
In article 19990722111605.c49...@palmerharvey.co.uk, Dominic Mitchell dom.mitch...@palmerharvey.co.uk wrote: On Thu, Jul 22, 1999 at 04:59:59PM +0700, Max Khon wrote: PAM is also using masses of weird shared objects but nevertheless it's quite usable By statically linked binaries? Our PAM implementation works for static binaries too. See the sources for the gory details. Basically it creates a library that includes all the possible modules, and selects the right one at runtime. There's some linker set magic involved. Concerning masses of weird shared objects, you'd really better get used to it. It was the wave of the future 10 years ago. It's not going away. Dynamic linking provides flexibility and modularity that you just can't get from static linking. John -- John Polstra j...@polstra.com John D. Polstra Co., Inc.Seattle, Washington USA No matter how cynical I get, I just can't keep up.-- Nora Ephron To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: PAM LDAP in FreeBSD, and userfs too.
On Thu, 22 Jul 1999, John Polstra wrote: On Thu, Jul 22, 1999 at 04:59:59PM +0700, Max Khon wrote: PAM is also using masses of weird shared objects but nevertheless it's quite usable By statically linked binaries? Our PAM implementation works for static binaries too. See the sources for the gory details. Basically it creates a library that includes all the possible modules, and selects the right one at runtime. There's some linker set magic involved. This means you can't add in a new module without recompiling the static library, correct? That seems to defeat the purpose of PAM being modular for the static case :-( Kris To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: PAM LDAP in FreeBSD, and userfs too.
On Thu, Jul 22, 1999 at 10:58:59PM -0700, John Polstra wrote: In article 19990722111605.c49...@palmerharvey.co.uk, Dominic Mitchell dom.mitch...@palmerharvey.co.uk wrote: On Thu, Jul 22, 1999 at 04:59:59PM +0700, Max Khon wrote: PAM is also using masses of weird shared objects but nevertheless it's quite usable By statically linked binaries? Our PAM implementation works for static binaries too. See the sources for the gory details. Basically it creates a library that includes all the possible modules, and selects the right one at runtime. There's some linker set magic involved. Ooh! Cunning! Concerning masses of weird shared objects, you'd really better get used to it. It was the wave of the future 10 years ago. It's not going away. Dynamic linking provides flexibility and modularity that you just can't get from static linking. Very right. I didn't say it was a bad thing, just confused me for a while when I first saw it... However, I still (personally) prefer the idea of a filesystem interface... -- Dom Mitchell -- Palmer Harvey McLane -- Unix Systems Administrator In Mountain View did Larry Wall Sedately launch a quiet plea: That DOS, the ancient system, shall On boxes pleasureless to all Run Perl though lack they C. -- ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. ** To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: PAM LDAP in FreeBSD, and userfs too.
hi, there! On Mon, 19 Jul 1999, Dominic Mitchell wrote: On Mon, Jul 19, 1999 at 12:29:48PM -0400, David E. Cross wrote: I thought now would be a good time to chime in on some of my wild schemes... The reason I am interested in 'userfs' is to enable me to write a version of 'nsd'. [...] Lovely. Sounds like a much better way to do the Solaris/Linux (and NetBSD?) /etc/nsswitch.conf stuff. On Solaris at least, this is implemented using masses of weird shared objects... PAM is also "using masses of weird shared objects" but nevertheless it's quite usable /fjoe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PAM LDAP in FreeBSD, and userfs too.
On Thu, Jul 22, 1999 at 04:59:59PM +0700, Max Khon wrote: On Mon, 19 Jul 1999, Dominic Mitchell wrote: Lovely. Sounds like a much better way to do the Solaris/Linux (and NetBSD?) /etc/nsswitch.conf stuff. On Solaris at least, this is implemented using masses of weird shared objects... PAM is also "using masses of weird shared objects" but nevertheless it's quite usable By statically linked binaries? -- Dom Mitchell -- Palmer Harvey McLane -- Unix Systems Administrator In Mountain View did Larry Wall Sedately launch a quiet plea: That DOS, the ancient system, shall On boxes pleasureless to all Run Perl though lack they C. -- ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. ** To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PAM LDAP in FreeBSD, and userfs too.
On Thu, 22 Jul 1999, Dominic Mitchell wrote: PAM is also "using masses of weird shared objects" but nevertheless it's quite usable By statically linked binaries? This is also an issue for a modularized libcrypt(). Peter Wemm suggested having the library fork and exec a static helper binary module and communicate via a pipe. So essentially you'd have two files for each module, one which is a shared library and loaded via dlopen() and one which is the same code with a small amount of wrapper (main() etc) to make it into a standalone binary. Solaris seem to be deprecating static libraries; you cannot have a fully static libc and they have to resort to keeping (a copy of) libdl (and presumably the run-time linker) under /etc so it's available on the root partition. Kris To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PAM LDAP in FreeBSD, and userfs too.
On Thu, Jul 22, 1999 at 11:19:35PM +0930, Kris Kennaway wrote: On Thu, 22 Jul 1999, Dominic Mitchell wrote: PAM is also "using masses of weird shared objects" but nevertheless it's quite usable By statically linked binaries? This is also an issue for a modularized libcrypt(). Peter Wemm suggested having the library fork and exec a static helper binary module and communicate via a pipe. So essentially you'd have two files for each module, one which is a shared library and loaded via dlopen() and one which is the same code with a small amount of wrapper (main() etc) to make it into a standalone binary. This is starting to get icky. This is also where the earlier idea of a userspace filesystem would probably fare better, in terms of both performance and simplicity. Solaris seem to be deprecating static libraries; you cannot have a fully static libc and they have to resort to keeping (a copy of) libdl (and presumably the run-time linker) under /etc so it's available on the root partition. Solaris hasn't supported static linking for some time. If you have a look at Casper Dik's FAQ, it goes into more detail. They do keep stuff on the root partition: admin# ls -l /etc/lib total 644 -rwxr-xr-x 1 bin bin 155060 Jul 1 1998 ld.so.1* -rwxr-xr-x 1 bin bin 4284 Jul 1 1998 libdl.so.1* -rwxr-xr-x 1 bin bin25468 Jul 16 1997 nss_files.so.1* lrwxrwxrwx 1 root root 17 Sep 14 1998 pam_authen.so - ./pam_authen.so.1* -rwxr-xr-x 1 root sys14516 Jul 16 1997 pam_authen.so.1* lrwxrwxrwx 1 root root 16 Sep 14 1998 pam_entry.so - ./pam_entry.so.1* -rwxr-xr-x 1 root sys11540 Jul 16 1997 pam_entry.so.1* lrwxrwxrwx 1 root root 17 Sep 14 1998 pam_extern.so - ./pam_extern.so.1* -rwxr-xr-x 1 root sys11044 Jul 16 1997 pam_extern.so.1* lrwxrwxrwx 1 root root 16 Sep 14 1998 pam_pwmgt.so - ./pam_pwmgt.so.1* -rwxr-xr-x 1 root sys85764 Jul 16 1997 pam_pwmgt.so.1* lrwxrwxrwx 1 root root 18 Sep 14 1998 pam_session.so - ./pam_session.so.1* -rwxr-xr-x 1 root sys 4748 Jul 16 1997 pam_session.so.1* -- Dom Mitchell -- Palmer Harvey McLane -- Unix Systems Administrator In Mountain View did Larry Wall Sedately launch a quiet plea: That DOS, the ancient system, shall On boxes pleasureless to all Run Perl though lack they C. -- ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. ** To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PAM LDAP in FreeBSD, and userfs too.
On Thu, 22 Jul 1999, Dominic Mitchell wrote: This is starting to get icky. This is also where the earlier idea of a userspace filesystem would probably fare better, in terms of both performance and simplicity. Maybe I don't get how this userspace filesystem is going to be set out (for the case of the nss stuff), but I don't see this. Kris -- The Feynman Problem-Solving Algorithm: (1) Write down the problem (2) Think real hard (3) Write down the answer -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PAM LDAP in FreeBSD, and userfs too.
In article [EMAIL PROTECTED], Dominic Mitchell [EMAIL PROTECTED] wrote: On Thu, Jul 22, 1999 at 04:59:59PM +0700, Max Khon wrote: PAM is also "using masses of weird shared objects" but nevertheless it's quite usable By statically linked binaries? Our PAM implementation works for static binaries too. See the sources for the gory details. Basically it creates a library that includes all the possible modules, and selects the right one at runtime. There's some linker set magic involved. Concerning "masses of weird shared objects," you'd really better get used to it. It was the wave of the future 10 years ago. It's not going away. Dynamic linking provides flexibility and modularity that you just can't get from static linking. John -- John Polstra [EMAIL PROTECTED] John D. Polstra Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PAM LDAP in FreeBSD, and userfs too.
hi, there! On Mon, 19 Jul 1999, Dominic Mitchell wrote: On Mon, Jul 19, 1999 at 12:29:48PM -0400, David E. Cross wrote: I thought now would be a good time to chime in on some of my wild schemes... The reason I am interested in 'userfs' is to enable me to write a version of 'nsd'. [...] Lovely. Sounds like a much better way to do the Solaris/Linux (and NetBSD?) /etc/nsswitch.conf stuff. On Solaris at least, this is implemented using masses of weird shared objects... PAM is also using masses of weird shared objects but nevertheless it's quite usable /fjoe To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: PAM LDAP in FreeBSD, and userfs too.
On Thu, Jul 22, 1999 at 04:59:59PM +0700, Max Khon wrote: On Mon, 19 Jul 1999, Dominic Mitchell wrote: Lovely. Sounds like a much better way to do the Solaris/Linux (and NetBSD?) /etc/nsswitch.conf stuff. On Solaris at least, this is implemented using masses of weird shared objects... PAM is also using masses of weird shared objects but nevertheless it's quite usable By statically linked binaries? -- Dom Mitchell -- Palmer Harvey McLane -- Unix Systems Administrator In Mountain View did Larry Wall Sedately launch a quiet plea: That DOS, the ancient system, shall On boxes pleasureless to all Run Perl though lack they C. -- ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. ** To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: PAM LDAP in FreeBSD, and userfs too.
On Thu, 22 Jul 1999, Dominic Mitchell wrote: PAM is also using masses of weird shared objects but nevertheless it's quite usable By statically linked binaries? This is also an issue for a modularized libcrypt(). Peter Wemm suggested having the library fork and exec a static helper binary module and communicate via a pipe. So essentially you'd have two files for each module, one which is a shared library and loaded via dlopen() and one which is the same code with a small amount of wrapper (main() etc) to make it into a standalone binary. Solaris seem to be deprecating static libraries; you cannot have a fully static libc and they have to resort to keeping (a copy of) libdl (and presumably the run-time linker) under /etc so it's available on the root partition. Kris To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: PAM LDAP in FreeBSD, and userfs too.
On Thu, Jul 22, 1999 at 11:19:35PM +0930, Kris Kennaway wrote: On Thu, 22 Jul 1999, Dominic Mitchell wrote: PAM is also using masses of weird shared objects but nevertheless it's quite usable By statically linked binaries? This is also an issue for a modularized libcrypt(). Peter Wemm suggested having the library fork and exec a static helper binary module and communicate via a pipe. So essentially you'd have two files for each module, one which is a shared library and loaded via dlopen() and one which is the same code with a small amount of wrapper (main() etc) to make it into a standalone binary. This is starting to get icky. This is also where the earlier idea of a userspace filesystem would probably fare better, in terms of both performance and simplicity. Solaris seem to be deprecating static libraries; you cannot have a fully static libc and they have to resort to keeping (a copy of) libdl (and presumably the run-time linker) under /etc so it's available on the root partition. Solaris hasn't supported static linking for some time. If you have a look at Casper Dik's FAQ, it goes into more detail. They do keep stuff on the root partition: admin# ls -l /etc/lib total 644 -rwxr-xr-x 1 bin bin 155060 Jul 1 1998 ld.so.1* -rwxr-xr-x 1 bin bin 4284 Jul 1 1998 libdl.so.1* -rwxr-xr-x 1 bin bin25468 Jul 16 1997 nss_files.so.1* lrwxrwxrwx 1 root root 17 Sep 14 1998 pam_authen.so - ./pam_authen.so.1* -rwxr-xr-x 1 root sys14516 Jul 16 1997 pam_authen.so.1* lrwxrwxrwx 1 root root 16 Sep 14 1998 pam_entry.so - ./pam_entry.so.1* -rwxr-xr-x 1 root sys11540 Jul 16 1997 pam_entry.so.1* lrwxrwxrwx 1 root root 17 Sep 14 1998 pam_extern.so - ./pam_extern.so.1* -rwxr-xr-x 1 root sys11044 Jul 16 1997 pam_extern.so.1* lrwxrwxrwx 1 root root 16 Sep 14 1998 pam_pwmgt.so - ./pam_pwmgt.so.1* -rwxr-xr-x 1 root sys85764 Jul 16 1997 pam_pwmgt.so.1* lrwxrwxrwx 1 root root 18 Sep 14 1998 pam_session.so - ./pam_session.so.1* -rwxr-xr-x 1 root sys 4748 Jul 16 1997 pam_session.so.1* -- Dom Mitchell -- Palmer Harvey McLane -- Unix Systems Administrator In Mountain View did Larry Wall Sedately launch a quiet plea: That DOS, the ancient system, shall On boxes pleasureless to all Run Perl though lack they C. -- ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. ** To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: PAM LDAP in FreeBSD, and userfs too.
On Thu, 22 Jul 1999, Dominic Mitchell wrote: This is starting to get icky. This is also where the earlier idea of a userspace filesystem would probably fare better, in terms of both performance and simplicity. Maybe I don't get how this userspace filesystem is going to be set out (for the case of the nss stuff), but I don't see this. Kris -- The Feynman Problem-Solving Algorithm: (1) Write down the problem (2) Think real hard (3) Write down the answer -- To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: PAM LDAP in FreeBSD, and userfs too.
On Tue, 20 Jul 1999 10:02:43 +0100 Dominic Mitchell [EMAIL PROTECTED] wrote: How will you get around one of the major bugbears of the Solaris implementation, that is nscd serialises access to these databases? I understand that the caching will allow you to return most responses quickly, but on a busy system (web cache doing dns requests?) it might well bog down... Yes, that is a known issue, and one of the things we're hoping to avoid, but just how that will be done is as-of-yet-undetermined. -- Jason R. Thorpe [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PAM LDAP in FreeBSD, and userfs too.
On Mon, Jul 19, 1999 at 12:55:19PM -0700, Jason Thorpe wrote: On Mon, 19 Jul 1999 20:44:18 +0100 Dominic Mitchell dom.mitch...@palmerharvey.co.uk wrote: Lovely. Sounds like a much better way to do the Solaris/Linux (and NetBSD?) /etc/nsswitch.conf stuff. On Solaris at least, this is implemented using masses of weird shared objects... The plan for NetBSD is that things will also be handled with dynamic modules, but those dynamic modules will be glued into a `nscd'[*] (if you use Solaris, you're familiar with the name :-). [*] We are planning on not having all of the problems that the Solaris nscd has, and that people often complain about. This will allow libc to simply make a call to nscd (or fallback onto traditional `files' lookup), and nscd will handle all but the `files' case. This allows system-wide caching, and puts all of the complexity in one place. How will you get around one of the major bugbears of the Solaris implementation, that is nscd serialises access to these databases? I understand that the caching will allow you to return most responses quickly, but on a busy system (web cache doing dns requests?) it might well bog down... -- Dom Mitchell -- Palmer Harvey McLane -- Unix Systems Administrator In Mountain View did Larry Wall Sedately launch a quiet plea: That DOS, the ancient system, shall On boxes pleasureless to all Run Perl though lack they C. -- ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. ** To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: PAM LDAP in FreeBSD, and userfs too.
On Tue, 20 Jul 1999 10:02:43 +0100 Dominic Mitchell dom.mitch...@palmerharvey.co.uk wrote: How will you get around one of the major bugbears of the Solaris implementation, that is nscd serialises access to these databases? I understand that the caching will allow you to return most responses quickly, but on a busy system (web cache doing dns requests?) it might well bog down... Yes, that is a known issue, and one of the things we're hoping to avoid, but just how that will be done is as-of-yet-undetermined. -- Jason R. Thorpe thor...@nas.nasa.gov To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: PAM LDAP in FreeBSD, and userfs too.
I thought now would be a good time to chime in on some of my wild schemes... The reason I am interested in 'userfs' is to enable me to write a version of 'nsd'. Those of you familiar with Irix will recognize it. For others, what it does is to present the name-space on a machine as filespace. The advantages of this is that we can greatly simplify out libc to use the file/namespace that nsd provides. For example 'getpwent()' now becomes file accesses to /ns/.local/passwd/NAME. Another advantage that this abstraction provides is that it allows transparent alterations of the databases in use, even to the extent of NOT having to restart each client that may be using a specific database. -- David Cross | email: [EMAIL PROTECTED] Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd Rensselaer Polytechnic Institute, | Ph: 518.276.2860 Department of Computer Science| Fax: 518.276.4033 I speak only for myself. | WinNT:Linux::Linux:FreeBSD To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PAM LDAP in FreeBSD, and userfs too.
On Mon, Jul 19, 1999 at 12:29:48PM -0400, David E. Cross wrote: I thought now would be a good time to chime in on some of my wild schemes... The reason I am interested in 'userfs' is to enable me to write a version of 'nsd'. Those of you familiar with Irix will recognize it. For others, what it does is to present the name-space on a machine as filespace. The advantages of this is that we can greatly simplify out libc to use the file/namespace that nsd provides. For example 'getpwent()' now becomes file accesses to /ns/.local/passwd/NAME. Another advantage that this abstraction provides is that it allows transparent alterations of the databases in use, even to the extent of NOT having to restart each client that may be using a specific database. Lovely. Sounds like a much better way to do the Solaris/Linux (and NetBSD?) /etc/nsswitch.conf stuff. On Solaris at least, this is implemented using masses of weird shared objects... -- Dom Mitchell -- Palmer Harvey McLane -- Unix Systems Administrator In Mountain View did Larry Wall Sedately launch a quiet plea: That DOS, the ancient system, shall On boxes pleasureless to all Run Perl though lack they C. -- ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. ** To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PAM LDAP in FreeBSD, and userfs too.
On Mon, 19 Jul 1999 20:44:18 +0100 Dominic Mitchell [EMAIL PROTECTED] wrote: Lovely. Sounds like a much better way to do the Solaris/Linux (and NetBSD?) /etc/nsswitch.conf stuff. On Solaris at least, this is implemented using masses of weird shared objects... The plan for NetBSD is that things will also be handled with dynamic modules, but those dynamic modules will be glued into a `nscd'[*] (if you use Solaris, you're familiar with the name :-). [*] We are planning on not having all of the problems that the Solaris nscd has, and that people often complain about. This will allow libc to simply make a call to nscd (or fallback onto traditional `files' lookup), and nscd will handle all but the `files' case. This allows system-wide caching, and puts all of the complexity in one place. Involving one or more user mode file systems seems like ... the wrong approach for a name service switch. -- Jason R. Thorpe [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PAM LDAP in FreeBSD, and userfs too.
Lovely. Sounds like a much better way to do the Solaris/Linux (and NetBSD?) /etc/nsswitch.conf stuff. On Solaris at least, this is implemented using masses of weird shared objects... The plan for NetBSD is that things will also be handled with dynamic modules, but those dynamic modules will be glued into a `nscd'[*] (if you use Solaris, you're familiar with the name :-). [*] We are planning on not having all of the problems that the Solaris nscd has, and that people often complain about. This will allow libc to simply make a call to nscd (or fallback onto traditional `files' lookup), and nscd will handle all but the `files' case. This allows system-wide caching, and puts all of the complexity in one place. Involving one or more user mode file systems seems like ... the wrong approach for a name service switch. Tomato, Tomatoe. The difference between the 2 methods is in their interaction with the database itself. You will be providing a socket-ish interface to the cache, my plan is for a filesystem interface, heck it could probably do both. I personally prefer the FS approach in dealing with both on Solaris and Irix. What Irix does well, Irix does very well. The FS method also allows more complex permission checking on access to various databases, like shadow, because the node in a directory had the added granularity of being group readable. It also gives you the flexibility of the shell, or a web-browser, to get at the data. Another idea I had considered was placing something ala 'rc.conf' into a database to allow easy distribution throughout many computers (this would obviously be configuration later in the boot process). Having a FS style interface makes it much easier for programs to get at the data in a clear, consistent manor. These are just my ramblinngs, and it seems we are quickly converging on the same basic idea with slightly different (but perhaps compatible) implementations. -- David Cross | email: [EMAIL PROTECTED] Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd Rensselaer Polytechnic Institute, | Ph: 518.276.2860 Department of Computer Science| Fax: 518.276.4033 I speak only for myself. | WinNT:Linux::Linux:FreeBSD To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PAM LDAP in FreeBSD, and userfs too.
I thought now would be a good time to chime in on some of my wild schemes... The reason I am interested in 'userfs' is to enable me to write a version of 'nsd'. Those of you familiar with Irix will recognize it. For others, what it does is to present the name-space on a machine as filespace. The advantages of this is that we can greatly simplify out libc to use the file/namespace that nsd provides. For example 'getpwent()' now becomes file accesses to /ns/.local/passwd/NAME. Another advantage that this abstraction provides is that it allows transparent alterations of the databases in use, even to the extent of NOT having to restart each client that may be using a specific database. -- David Cross | email: cro...@cs.rpi.edu Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd Rensselaer Polytechnic Institute, | Ph: 518.276.2860 Department of Computer Science| Fax: 518.276.4033 I speak only for myself. | WinNT:Linux::Linux:FreeBSD To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: PAM LDAP in FreeBSD, and userfs too.
On Mon, Jul 19, 1999 at 12:29:48PM -0400, David E. Cross wrote: I thought now would be a good time to chime in on some of my wild schemes... The reason I am interested in 'userfs' is to enable me to write a version of 'nsd'. Those of you familiar with Irix will recognize it. For others, what it does is to present the name-space on a machine as filespace. The advantages of this is that we can greatly simplify out libc to use the file/namespace that nsd provides. For example 'getpwent()' now becomes file accesses to /ns/.local/passwd/NAME. Another advantage that this abstraction provides is that it allows transparent alterations of the databases in use, even to the extent of NOT having to restart each client that may be using a specific database. Lovely. Sounds like a much better way to do the Solaris/Linux (and NetBSD?) /etc/nsswitch.conf stuff. On Solaris at least, this is implemented using masses of weird shared objects... -- Dom Mitchell -- Palmer Harvey McLane -- Unix Systems Administrator In Mountain View did Larry Wall Sedately launch a quiet plea: That DOS, the ancient system, shall On boxes pleasureless to all Run Perl though lack they C. -- ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. ** To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: PAM LDAP in FreeBSD, and userfs too.
On Mon, 19 Jul 1999 20:44:18 +0100 Dominic Mitchell dom.mitch...@palmerharvey.co.uk wrote: Lovely. Sounds like a much better way to do the Solaris/Linux (and NetBSD?) /etc/nsswitch.conf stuff. On Solaris at least, this is implemented using masses of weird shared objects... The plan for NetBSD is that things will also be handled with dynamic modules, but those dynamic modules will be glued into a `nscd'[*] (if you use Solaris, you're familiar with the name :-). [*] We are planning on not having all of the problems that the Solaris nscd has, and that people often complain about. This will allow libc to simply make a call to nscd (or fallback onto traditional `files' lookup), and nscd will handle all but the `files' case. This allows system-wide caching, and puts all of the complexity in one place. Involving one or more user mode file systems seems like ... the wrong approach for a name service switch. -- Jason R. Thorpe thor...@nas.nasa.gov To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: PAM LDAP in FreeBSD, and userfs too.
Lovely. Sounds like a much better way to do the Solaris/Linux (and NetBSD?) /etc/nsswitch.conf stuff. On Solaris at least, this is implemented using masses of weird shared objects... The plan for NetBSD is that things will also be handled with dynamic modules, but those dynamic modules will be glued into a `nscd'[*] (if you use Solaris, you're familiar with the name :-). [*] We are planning on not having all of the problems that the Solaris nscd has, and that people often complain about. This will allow libc to simply make a call to nscd (or fallback onto traditional `files' lookup), and nscd will handle all but the `files' case. This allows system-wide caching, and puts all of the complexity in one place. Involving one or more user mode file systems seems like ... the wrong approach for a name service switch. Tomato, Tomatoe. The difference between the 2 methods is in their interaction with the database itself. You will be providing a socket-ish interface to the cache, my plan is for a filesystem interface, heck it could probably do both. I personally prefer the FS approach in dealing with both on Solaris and Irix. What Irix does well, Irix does very well. The FS method also allows more complex permission checking on access to various databases, like shadow, because the node in a directory had the added granularity of being group readable. It also gives you the flexibility of the shell, or a web-browser, to get at the data. Another idea I had considered was placing something ala 'rc.conf' into a database to allow easy distribution throughout many computers (this would obviously be configuration later in the boot process). Having a FS style interface makes it much easier for programs to get at the data in a clear, consistent manor. These are just my ramblinngs, and it seems we are quickly converging on the same basic idea with slightly different (but perhaps compatible) implementations. -- David Cross | email: cro...@cs.rpi.edu Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd Rensselaer Polytechnic Institute, | Ph: 518.276.2860 Department of Computer Science| Fax: 518.276.4033 I speak only for myself. | WinNT:Linux::Linux:FreeBSD To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
