Quoth "Keith Stevenson":
> (Mark Murray: jump in here if I get this wrong)
>
> The way I understand it, a PAM module (pam_unix?) would need to be able to
> look at the password hash and figure out which of the crypt functions to
> call. Ideally, the PAM configuration would be able to specify whi
Quoth "Keith Stevenson":
> (Mark Murray: jump in here if I get this wrong)
>
> The way I understand it, a PAM module (pam_unix?) would need to be able to
> look at the password hash and figure out which of the crypt functions to
> call. Ideally, the PAM configuration would be able to specify wh
On Thu, Jul 22, 1999 at 10:58:59PM -0700, John Polstra wrote:
> In article <19990722111605.c49...@palmerharvey.co.uk>,
> Dominic Mitchell 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
> >
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
> > > q
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 binar
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 bina
In article <19990722111605.c49...@palmerharvey.co.uk>,
Dominic Mitchell 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
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 wo
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
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 lib
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
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 li
On Wed, 21 Jul 1999, Oscar Bonilla wrote:
> Ok, here goes my understanding of how things should be, please correct me
> if i'm wrong.
>
> There are three parts to the problem:
>
> 1. Where do we get the databases from? I mean, where do we get passwd, group,
>hosts, ethers, etc from.
>
>
On Thu, 22 Jul 1999, Daniel C. Sobral wrote:
> Oscar Bonilla wrote:
> >
> > There are three parts to the problem:
> >
> > 1. Where do we get the databases from? I mean, where do we get passwd,
> > group,
> >hosts, ethers, etc from.
> >
> >This should be handled by a name service switch
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
On Wed, 21 Jul 1999, Oscar Bonilla wrote:
> Ok, here goes my understanding of how things should be, please correct me
> if i'm wrong.
>
> There are three parts to the problem:
>
> 1. Where do we get the databases from? I mean, where do we get passwd, group,
>hosts, ethers, etc from.
>
>
On Thu, 22 Jul 1999, Daniel C. Sobral wrote:
> Oscar Bonilla wrote:
> >
> > There are three parts to the problem:
> >
> > 1. Where do we get the databases from? I mean, where do we get passwd, group,
> >hosts, ethers, etc from.
> >
> >This should be handled by a name service switch a l
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
hi, there!
On Mon, 19 Jul 1999, Oscar Bonilla wrote:
> On Mon, Jul 19, 1999 at 04:51:12PM -0600, Wes Peters wrote:
> > The implementation details are as unimportant as ever: they have to work
> > and be maintainable. Following prior art remains a good idea; the Solaris
> > "name service switch"
hi, there!
On Tue, 20 Jul 1999, Oscar Bonilla wrote:
> > It looks like we've got some good concurrent projects happening at the
> > moment - markm and co working on PAM, the nsswitch.conf project you're
> > talking about, and the stuff I'm working on with modularizing crypt() and
> > supporting p
hi, there!
On Thu, 22 Jul 1999, Daniel C. Sobral wrote:
> I perceive here an unfair biasing toward nss. Someone mentioned
> defining where to get the passwords from based on the login class.
> This is a very interesting option, that doesn't seem to be well
> served by nss.
there is already nss_l
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.
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
hi, there!
On Fri, 16 Jul 1999, Oscar Bonilla wrote:
> Following up on my own post:
>
> For LDAP to be seamlessly integrated into the system some of the libraries
> have to be changed. Specifically the ones dealing with /etc/passwd and
> user information.
>
> I've decided the best way to do th
hi, there!
On Mon, 19 Jul 1999, Oscar Bonilla wrote:
> On Mon, Jul 19, 1999 at 04:51:12PM -0600, Wes Peters wrote:
> > The implementation details are as unimportant as ever: they have to work
> > and be maintainable. Following prior art remains a good idea; the Solaris
> > "name service switch"
hi, there!
On Tue, 20 Jul 1999, Oscar Bonilla wrote:
> > It looks like we've got some good concurrent projects happening at the
> > moment - markm and co working on PAM, the nsswitch.conf project you're
> > talking about, and the stuff I'm working on with modularizing crypt() and
> > supporting
hi, there!
On Thu, 22 Jul 1999, Daniel C. Sobral wrote:
> I perceive here an unfair biasing toward nss. Someone mentioned
> defining where to get the passwords from based on the login class.
> This is a very interesting option, that doesn't seem to be well
> served by nss.
there is already nss_
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
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 'ns
hi, there!
On Fri, 16 Jul 1999, Oscar Bonilla wrote:
> Following up on my own post:
>
> For LDAP to be seamlessly integrated into the system some of the libraries
> have to be changed. Specifically the ones dealing with /etc/passwd and
> user information.
>
> I've decided the best way to do t
On Wed, Jul 21, 1999 at 10:57:24AM -0600, Oscar Bonilla wrote:
>
> I don't see where the modularized crypt would fit in then...
> i totally agree that pam has this capability i was just trying to fit
> in the crypt stuff people have been working on.
(Mark Murray: jump in here if I get this wr
On Wed, Jul 21, 1999 at 10:57:24AM -0600, Oscar Bonilla wrote:
>
> I don't see where the modularized crypt would fit in then...
> i totally agree that pam has this capability i was just trying to fit
> in the crypt stuff people have been working on.
(Mark Murray: jump in here if I get this w
On Wed, Jul 21, 1999 at 06:22:39PM +, Niall Smart wrote:
> [ CC list nuked ]
good! :)
>> Ok, here goes my understanding of how things should be, please correct me
>> if i'm wrong.
>>
>> There are three parts to the problem:
>>
>> 1. Where do we get the databases from? I mean, where do we ge
[ CC list nuked ]
> Ok, here goes my understanding of how things should be, please correct me
> if i'm wrong.
>
> There are three parts to the problem:
>
> 1. Where do we get the databases from? I mean, where do we get passwd, group,
>hosts, ethers, etc from.
>
>This should be handled b
On Thu, Jul 22, 1999 at 01:00:57AM +0900, Daniel C. Sobral wrote:
> Oscar Bonilla wrote:
>>
>> There are three parts to the problem:
>>
>> 1. Where do we get the databases from? I mean, where do we get passwd, group,
>>hosts, ethers, etc from.
>>
>>This should be handled by a name servic
Oscar Bonilla wrote:
>
> There are three parts to the problem:
>
> 1. Where do we get the databases from? I mean, where do we get passwd, group,
>hosts, ethers, etc from.
>
>This should be handled by a name service switch a la solaris. Basically
>we want to be able to tell the system
On Wed, Jul 21, 1999 at 06:22:39PM +, Niall Smart wrote:
> [ CC list nuked ]
good! :)
>> Ok, here goes my understanding of how things should be, please correct me
>> if i'm wrong.
>>
>> There are three parts to the problem:
>>
>> 1. Where do we get the databases from? I mean, where do we g
On Wed, Jul 21, 1999 at 01:46:56AM +0930, Kris Kennaway wrote:
> It looks like we've got some good concurrent projects happening at the
> moment - markm and co working on PAM, the nsswitch.conf project you're
> talking about, and the stuff I'm working on with modularizing crypt() and
> supporting p
[ CC list nuked ]
> Ok, here goes my understanding of how things should be, please correct me
> if i'm wrong.
>
> There are three parts to the problem:
>
> 1. Where do we get the databases from? I mean, where do we get passwd, group,
>hosts, ethers, etc from.
>
>This should be handled
On Thu, Jul 22, 1999 at 01:00:57AM +0900, Daniel C. Sobral wrote:
> Oscar Bonilla wrote:
>>
>> There are three parts to the problem:
>>
>> 1. Where do we get the databases from? I mean, where do we get passwd, group,
>>hosts, ethers, etc from.
>>
>>This should be handled by a name servi
Oscar Bonilla wrote:
>
> There are three parts to the problem:
>
> 1. Where do we get the databases from? I mean, where do we get passwd, group,
>hosts, ethers, etc from.
>
>This should be handled by a name service switch a la solaris. Basically
>we want to be able to tell the syste
On Wed, Jul 21, 1999 at 01:46:56AM +0930, Kris Kennaway wrote:
> It looks like we've got some good concurrent projects happening at the
> moment - markm and co working on PAM, the nsswitch.conf project you're
> talking about, and the stuff I'm working on with modularizing crypt() and
> supporting
Wes Peters wrote:
>
>The implementation details are as unimportant as ever: they have to work
>and be maintainable. Following prior art remains a good idea; the Solaris
>"name service switch" implementation is a good starting point to consider.
What about using the IRS library from bind?
Tony.
Wes Peters <[EMAIL PROTECTED]> wrote:
>
>The implementation details are as unimportant as ever: they have to work
>and be maintainable. Following prior art remains a good idea; the Solaris
>"name service switch" implementation is a good starting point to consider.
What about using the IRS librar
Oscar Bonilla wrote:
>
> ok, so this clarifies a lot of things... let's get rid of /etc/auth.conf
> and go with /etc/pam.conf for the authentication and /etc/nsswitch.conf
> for the info on where to obtain the databases from.
That seems reasonable to me.
PAM actually is designed to serve four se
Oscar Bonilla wrote:
>
> ok, so this clarifies a lot of things... let's get rid of /etc/auth.conf
> and go with /etc/pam.conf for the authentication and /etc/nsswitch.conf
> for the info on where to obtain the databases from.
That seems reasonable to me.
PAM actually is designed to serve four s
On Tue, Jul 20, 1999 at 11:49:42AM -0700, John Polstra wrote:
> In article <19990720082825.b...@fisicc-ufm.edu>,
> Oscar Bonilla wrote:
>
> > Couldn't we do this with /etc/auth.conf?
>
> The plan when PAM was brought in was to eliminate auth.conf. I don't
> think we should be looking for new u
> It looks like we've got some good concurrent projects happening at the
> moment - markm and co working on PAM, the nsswitch.conf project you're
> talking about, and the stuff I'm working on with modularizing crypt() and
> supporting per-login class password hashes (I've rewritten the library
> si
On Tue, Jul 20, 1999 at 11:49:42AM -0700, John Polstra wrote:
> In article <[EMAIL PROTECTED]>,
> Oscar Bonilla <[EMAIL PROTECTED]> wrote:
>
> > Couldn't we do this with /etc/auth.conf?
>
> The plan when PAM was brought in was to eliminate auth.conf. I don't
> think we should be looking for ne
> It looks like we've got some good concurrent projects happening at the
> moment - markm and co working on PAM, the nsswitch.conf project you're
> talking about, and the stuff I'm working on with modularizing crypt() and
> supporting per-login class password hashes (I've rewritten the library
> s
In article <19990720082825.b...@fisicc-ufm.edu>,
Oscar Bonilla wrote:
> Couldn't we do this with /etc/auth.conf?
The plan when PAM was brought in was to eliminate auth.conf. I don't
think we should be looking for new uses for it.
John
--
John Polstra
In article <[EMAIL PROTECTED]>,
Oscar Bonilla <[EMAIL PROTECTED]> wrote:
> Couldn't we do this with /etc/auth.conf?
The plan when PAM was brought in was to eliminate auth.conf. I don't
think we should be looking for new uses for it.
John
--
John Polstra
On Tue, 20 Jul 1999 10:02:43 +0100
Dominic Mitchell 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 bus
On Tue, 20 Jul 1999, David E. Cross wrote:
> > Couldn't we do this with /etc/auth.conf? What's the real purpose of this
> > file? From the man page: "auth.conf contains various attributes important
> > to
> > the authentication code, most notably kerberos(5) for the time being."
> > Isn't this w
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
> q
On Tue, 20 Jul 1999, David E. Cross wrote:
> > Couldn't we do this with /etc/auth.conf? What's the real purpose of this
> > file? From the man page: "auth.conf contains various attributes important to
> > the authentication code, most notably kerberos(5) for the time being."
> > Isn't this what
> Couldn't we do this with /etc/auth.conf? What's the real purpose of this
> file? From the man page: "auth.conf contains various attributes important to
> the authentication code, most notably kerberos(5) for the time being."
> Isn't this what PAM is about? authentication? or does auth.conf cover
On Tue, Jul 20, 1999 at 10:59:30PM +1200, Joe Abley wrote:
> On Mon, Jul 19, 1999 at 06:00:26PM -0600, Oscar Bonilla wrote:
> > I agree. In solaris (and linux by the way) all you do is set
> > passwd ldap files
> > in /etc/nsswitch.conf
> > and that's it.
>
> In Solaris, it's
>
> passwd: lda
> Couldn't we do this with /etc/auth.conf? What's the real purpose of this
> file? From the man page: "auth.conf contains various attributes important to
> the authentication code, most notably kerberos(5) for the time being."
> Isn't this what PAM is about? authentication? or does auth.conf cove
On Tue, Jul 20, 1999 at 10:59:30PM +1200, Joe Abley wrote:
> On Mon, Jul 19, 1999 at 06:00:26PM -0600, Oscar Bonilla wrote:
> > I agree. In solaris (and linux by the way) all you do is set
> > passwd ldap files
> > in /etc/nsswitch.conf
> > and that's it.
>
> In Solaris, it's
>
> passwd: ld
On Mon, Jul 19, 1999 at 06:00:26PM -0600, Oscar Bonilla wrote:
> I agree. In solaris (and linux by the way) all you do is set
> passwdldap files
> in /etc/nsswitch.conf
> and that's it.
In Solaris, it's
passwd: ldap files
^
nsswitch.conf(4), SunOS 5.5.1:
...
There is an
On Mon, Jul 19, 1999 at 06:00:26PM -0600, Oscar Bonilla wrote:
> I agree. In solaris (and linux by the way) all you do is set
> passwdldap files
> in /etc/nsswitch.conf
> and that's it.
In Solaris, it's
passwd: ldap files
^
nsswitch.conf(4), SunOS 5.5.1:
...
There is an
On Mon, Jul 19, 1999 at 12:55:19PM -0700, Jason Thorpe wrote:
> On Mon, 19 Jul 1999 20:44:18 +0100
> 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 ma
On Mon, Jul 19, 1999 at 12:55:19PM -0700, Jason Thorpe wrote:
> 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
> >
On Mon, Jul 19, 1999 at 04:51:12PM -0600, Wes Peters wrote:
> The implementation details are as unimportant as ever: they have to work
> and be maintainable. Following prior art remains a good idea; the Solaris
> "name service switch" implementation is a good starting point to consider.
>
I agre
On Mon, Jul 19, 1999 at 04:51:12PM -0600, Wes Peters wrote:
> The implementation details are as unimportant as ever: they have to work
> and be maintainable. Following prior art remains a good idea; the Solaris
> "name service switch" implementation is a good starting point to consider.
>
I agr
On Mon, 19 Jul 1999, Wes Peters wrote:
> > Given that this is a PAM module, wouldn't /etc/pam.conf be more appropriate?
>
> /etc/pam.conf would be appropriate for configuring the behavior of PAM
> modules. /etc/auth.conf would be appropriate for configuring WHICH
> authentication method to use.
On Mon, 19 Jul 1999, Wes Peters wrote:
> > Given that this is a PAM module, wouldn't /etc/pam.conf be more appropriate?
>
> /etc/pam.conf would be appropriate for configuring the behavior of PAM
> modules. /etc/auth.conf would be appropriate for configuring WHICH
> authentication method to use.
Mike Smith wrote:
>
> > > > > > ldap:*:389:389:o=My Organization, c=BR:uid:ldap.myorg.com
> > > > >
> > > > > Horrible idea.
> > > > >
> > > >
> > > > suggestions?
> > >
> > > Use PAM.
> >
> > PAM isn't going to cut it. This is outside of its realm. Things like ps,
> > top, ls, chown, chmod, lpr
On Fri, Jul 16, 1999 at 12:36:48PM -0600, Oscar Bonilla wrote:
> For LDAP to be seamlessly integrated into the system some of the libraries
> have to be changed. Specifically the ones dealing with /etc/passwd and
> user information.
<...>
I haven't seen him post to this thread yet, but you might
Keith Stevenson wrote:
>
> On Mon, Jul 19, 1999 at 06:22:17PM +0200, Dag-Erling Smorgrav wrote:
> > Oscar Bonilla writes:
> > > On Mon, Jul 19, 1999 at 06:13:51PM +0200, Dag-Erling Smorgrav wrote:
> > > > Oscar Bonilla writes:
> > > > > the idea is to have an entry in the /etc/passwd enabling LD
Mike Smith wrote:
>
> > > > > > ldap:*:389:389:o=My Organization, c=BR:uid:ldap.myorg.com
> > > > >
> > > > > Horrible idea.
> > > > >
> > > >
> > > > suggestions?
> > >
> > > Use PAM.
> >
> > PAM isn't going to cut it. This is outside of its realm. Things like ps,
> > top, ls, chown, chmod, lp
On Fri, Jul 16, 1999 at 12:36:48PM -0600, Oscar Bonilla wrote:
> For LDAP to be seamlessly integrated into the system some of the libraries
> have to be changed. Specifically the ones dealing with /etc/passwd and
> user information.
<...>
I haven't seen him post to this thread yet, but you migh
> > > > > ldap:*:389:389:o=My Organization, c=BR:uid:ldap.myorg.com
> > > >
> > > > Horrible idea.
> > > >
> > >
> > > suggestions?
> >
> > Use PAM.
>
> PAM isn't going to cut it. This is outside of its realm. Things like ps,
> top, ls, chown, chmod, lpr, rcmd, who, w, (the list goes on) nee
Keith Stevenson wrote:
>
> On Mon, Jul 19, 1999 at 06:22:17PM +0200, Dag-Erling Smorgrav wrote:
> > Oscar Bonilla <[EMAIL PROTECTED]> writes:
> > > On Mon, Jul 19, 1999 at 06:13:51PM +0200, Dag-Erling Smorgrav wrote:
> > > > Oscar Bonilla <[EMAIL PROTECTED]> writes:
> > > > > the idea is to have
> > > > > ldap:*:389:389:o=My Organization, c=BR:uid:ldap.myorg.com
> > > >
> > > > Horrible idea.
> > > >
> > >
> > > suggestions?
> >
> > Use PAM.
>
> PAM isn't going to cut it. This is outside of its realm. Things like ps,
> top, ls, chown, chmod, lpr, rcmd, who, w, (the list goes on) ne
> > 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 mo
On Mon, 19 Jul 1999 15:47:33 -0400
"David E. Cross" wrote:
> PAM isn't going to cut it. This is outside of its realm. Things like ps,
> top, ls, chown, chmod, lpr, rcmd, who, w, (the list goes on) need to be able
> to pull 'passwd' entries from the LDAP server, and unless we PAM all of tho
On Mon, 19 Jul 1999 20:44:18 +0100
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...
The plan for NetBSD is that things will a
> Mike Smith wrote:
> > On Mon, Jul 19, 1999 at 06:13:51PM +0200, Dag-Erling Smorgrav wrote:
> > > Oscar Bonilla writes:
> > > > the idea is to have an entry in the /etc/passwd enabling LDAP lookups.
> > > > the Entry would be of the form
> > > >
> > > > ldap:*:389:389:o=My Organization, c=BR:uid
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,
> On Mon, Jul 19, 1999 at 06:13:51PM +0200, Dag-Erling Smorgrav wrote:
> > Oscar Bonilla writes:
> > > the idea is to have an entry in the /etc/passwd enabling LDAP lookups.
> > > the Entry would be of the form
> > >
> > > ldap:*:389:389:o=My Organization, c=BR:uid:ldap.myorg.com
> >
> > Horribl
> > 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 m
On Mon, 19 Jul 1999 15:47:33 -0400
"David E. Cross" <[EMAIL PROTECTED]> wrote:
> PAM isn't going to cut it. This is outside of its realm. Things like ps,
> top, ls, chown, chmod, lpr, rcmd, who, w, (the list goes on) need to be able
> to pull 'passwd' entries from the LDAP server, and unle
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 i
> Mike Smith wrote:
> > On Mon, Jul 19, 1999 at 06:13:51PM +0200, Dag-Erling Smorgrav wrote:
> > > Oscar Bonilla <[EMAIL PROTECTED]> writes:
> > > > the idea is to have an entry in the /etc/passwd enabling LDAP lookups.
> > > > the Entry would be of the form
> > > >
> > > > ldap:*:389:389:o=My Or
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
> On Mon, Jul 19, 1999 at 06:13:51PM +0200, Dag-Erling Smorgrav wrote:
> > Oscar Bonilla <[EMAIL PROTECTED]> writes:
> > > the idea is to have an entry in the /etc/passwd enabling LDAP lookups.
> > > the Entry would be of the form
> > >
> > > ldap:*:389:389:o=My Organization, c=BR:uid:ldap.myorg.
On Mon, Jul 19, 1999 at 06:22:17PM +0200, Dag-Erling Smorgrav wrote:
> Oscar Bonilla writes:
> > On Mon, Jul 19, 1999 at 06:13:51PM +0200, Dag-Erling Smorgrav wrote:
> > > Oscar Bonilla writes:
> > > > the idea is to have an entry in the /etc/passwd enabling LDAP lookups.
> > > > the Entry would
On Mon, Jul 19, 1999 at 06:22:17PM +0200, Dag-Erling Smorgrav wrote:
> Oscar Bonilla <[EMAIL PROTECTED]> writes:
> > On Mon, Jul 19, 1999 at 06:13:51PM +0200, Dag-Erling Smorgrav wrote:
> > > Oscar Bonilla <[EMAIL PROTECTED]> writes:
> > > > the idea is to have an entry in the /etc/passwd enabling
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.
Th
Oscar Bonilla writes:
> On Mon, Jul 19, 1999 at 06:13:51PM +0200, Dag-Erling Smorgrav wrote:
> > Oscar Bonilla writes:
> > > the idea is to have an entry in the /etc/passwd enabling LDAP lookups.
> > > the Entry would be of the form
> > >
> > > ldap:*:389:389:o=My Organization, c=BR:uid:ldap.myo
On Mon, Jul 19, 1999 at 06:13:51PM +0200, Dag-Erling Smorgrav wrote:
> Oscar Bonilla writes:
> > the idea is to have an entry in the /etc/passwd enabling LDAP lookups.
> > the Entry would be of the form
> >
> > ldap:*:389:389:o=My Organization, c=BR:uid:ldap.myorg.com
>
> Horrible idea.
>
sugg
Oscar Bonilla writes:
> the idea is to have an entry in the /etc/passwd enabling LDAP lookups.
> the Entry would be of the form
>
> ldap:*:389:389:o=My Organization, c=BR:uid:ldap.myorg.com
Horrible idea.
DES
--
Dag-Erling Smorgrav - d...@flood.ping.uio.no
To Unsubscribe: send mail to major
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.
T
Oscar Bonilla <[EMAIL PROTECTED]> writes:
> On Mon, Jul 19, 1999 at 06:13:51PM +0200, Dag-Erling Smorgrav wrote:
> > Oscar Bonilla <[EMAIL PROTECTED]> writes:
> > > the idea is to have an entry in the /etc/passwd enabling LDAP lookups.
> > > the Entry would be of the form
> > >
> > > ldap:*:389:3
On Mon, Jul 19, 1999 at 06:13:51PM +0200, Dag-Erling Smorgrav wrote:
> Oscar Bonilla <[EMAIL PROTECTED]> writes:
> > the idea is to have an entry in the /etc/passwd enabling LDAP lookups.
> > the Entry would be of the form
> >
> > ldap:*:389:389:o=My Organization, c=BR:uid:ldap.myorg.com
>
> Hor
Oscar Bonilla <[EMAIL PROTECTED]> writes:
> the idea is to have an entry in the /etc/passwd enabling LDAP lookups.
> the Entry would be of the form
>
> ldap:*:389:389:o=My Organization, c=BR:uid:ldap.myorg.com
Horrible idea.
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
To Unsubscribe: sen
Following up on my own post:
For LDAP to be seamlessly integrated into the system some of the libraries
have to be changed. Specifically the ones dealing with /etc/passwd and
user information.
I've decided the best way to do this is to do what's done with NIS.
Basically handle the case where the
Following up on my own post:
For LDAP to be seamlessly integrated into the system some of the libraries
have to be changed. Specifically the ones dealing with /etc/passwd and
user information.
I've decided the best way to do this is to do what's done with NIS.
Basically handle the case where th
1 - 100 of 102 matches
Mail list logo
