s.
Right. In the meantime hosts has been implemented in nss-pam-ldapd but
currently does not work (at least on 9). It's been the author's concern
too whether services/protocols etc is a needed feature, but I guess you
won't find that out until you provide the feature. At least it seems
logi
> Hi,
>
> I'm currently implementing support for more NSS databases in
> net/nss-pamd-ldapd and I've started to wonder why there's only the group
> and password support in lib/libc/net/nss_compat.c?
>
> Is there a specific reason for it or is this a classic case
Hi,
I'm currently implementing support for more NSS databases in
net/nss-pamd-ldapd and I've started to wonder why there's only the group
and password support in lib/libc/net/nss_compat.c?
Is there a specific reason for it or is this a classic case of "patches
welcom
The only documentation I can really find for writing NSS stuff is the
stuff for glibc. Any differences or the like I need to be aware of in
regards to FreeBSD?
http://www.gnu.org/software/libtool/manual/libc/Name-Service-Switch.html#Name-Service-Switch
On Tue, 03 Jul 2007 11:04:17 +0200
Ivan Voras <[EMAIL PROTECTED]> mentioned:
> Z.C.B. wrote:
> > Have just been looking at sitting down and looking at writing a few
> > things, but I am a bit lost on where to start. Any suggestions on
> > things to read in regard
Z.C.B. wrote:
Have just been looking at sitting down and looking at writing a few
things, but I am a bit lost on where to start. Any suggestions on
things to read in regards to NSS and writing kernel modules?
These are not similar things and you don't need kernel modules for NSS.
For k
Have just been looking at sitting down and looking at writing a few
things, but I am a bit lost on where to start. Any suggestions on
things to read in regards to NSS and writing kernel modules?
___
freebsd-hackers@freebsd.org mailing list
http
* Joerg Sonnenberger <[EMAIL PROTECTED]> [1043 12:43]:
> On Sat, Oct 30, 2004 at 12:20:58PM +0100, Dick Davies wrote:
> > Trouble is openldap is one of those things everyone wants to configure
> > themselves - do you enable SASL support or not, what backends do you use
> > etc?
>
> IIRC SASL is pr
On Sat, Oct 30, 2004 at 12:20:58PM +0100, Dick Davies wrote:
> Trouble is openldap is one of those things everyone wants to configure
> themselves - do you enable SASL support or not, what backends do you use
> etc?
IIRC SASL is pretty mandatory to correctly implement LDAP v3. Bigger
question is G
On Sat, Oct 30, 2004 at 11:56:48AM +0200, Dag-Erling Sm?rgrav wrote:
> Eric Masson <[EMAIL PROTECTED]> writes:
> > Doesn't Heimdal partly solve this issue (lookup of SRV records in the
> > dns zone corresponding to the realm) ?
>
> Sure, provided you know which realm you're in...
It tries the hos
> "DES" == Dag-Erling Smørgrav <[EMAIL PROTECTED]> writes:
DES> Sure, provided you know which realm you're in...
Dhcp, maybe ?
DES> Ideally, I'd like to be able to install FreeBSD on a desktop box
DES> in a Windows shop and have it Just Work[tm] with Active Directory
DES> and Kerberos au
* Patrick Dung <[EMAIL PROTECTED]> [1045 03:45]:
> So my suggestion is: integrate pam_ldap, nss_ldap, nsswitch support
> with ldap and lookupd (ie LDAP client support) into the OS.
Trouble is openldap is one of those things everyone wants to configure
themselves - do you enable SASL support or no
e
an Active Directory infrastructure at work, our goal in finding funding
for the NSS work was specifically to facilitate this happening. While
some will undoubtably complain, supporting immediate and tight integration
with active directory would be quite useful.
Robert N M Watson FreeBS
--- Dag-Erling Sm鷨grav <[EMAIL PROTECTED]> wrotes:
> Patrick Dung <[EMAIL PROTECTED]> writes:
> > So my suggestion is: integrate pam_ldap, nss_ldap, nsswitch support
> > with ldap and lookupd (ie LDAP client support) into the OS.
>
> I'm already thinking about that, and about Kerberos autoconfigu
Eric Masson <[EMAIL PROTECTED]> writes:
> Doesn't Heimdal partly solve this issue (lookup of SRV records in the
> dns zone corresponding to the realm) ?
Sure, provided you know which realm you're in...
Ideally, I'd like to be able to install FreeBSD on a desktop box in a
Windows shop and have it
> "DES" == Dag-Erling Smørgrav <[EMAIL PROTECTED]> writes:
DES> I'm already thinking about that, and about Kerberos
DES> autoconfiguration (aka KDC discovery, very useful for FreeBSD
DES> clients in Windows networks).
Doesn't Heimdal partly solve this issue (lookup of SRV records in the
dn
Patrick Dung <[EMAIL PROTECTED]> writes:
> So my suggestion is: integrate pam_ldap, nss_ldap, nsswitch support
> with ldap and lookupd (ie LDAP client support) into the OS.
I'm already thinking about that, and about Kerberos autoconfiguration
(aka KDC discovery, very useful for FreeBSD clients in
Hi
First of all, I know that most committers or contributors contribute
their work in their free time.
I am not asking for any promise but I just want to discuss a possible
improvement for FreeBSD.
So my suggestion is: integrate pam_ldap, nss_ldap, nsswitch support
with ldap and lookupd (ie LDAP
I've completed the port (not to be confused with FreeBSD ports) of
libnss-mysql to FreeBSD. It seems to work well on my system. I've gone
ahead and released libnss-mysql 1.0 which includes said port. Let me know
how it goes. If someone wants to create a FreeBSD ports/package of it, that
would b
> You can still test for whether or not it is defined.
>
> #if defined(__FreeBSD__)
> /* Do freebsd-specific stuff */
> #else
> /* Other systems? */
> #endif
*nod* I was just worried about the tests required for Solaris using either
gcc or sun's cc .. looks like
#if defined(sun)
does the t
> have a look at :
> http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/51768
> (sorry I dirt your code :))
> It's *really* dirty :) but it works :-)
It's actually a pretty good hack :-) I actually forgot that I'd run across
this port earlier.
It doesn't link on my system (removed -Bgroup to get it
On Thu, Jul 10, 2003 at 05:12:03PM -0400, Ben Goodwin wrote:
> I'd like to support Sun's cc, however .. so I'm betting that isn't defined
> (I will check) ... I figured that would be available under gcc but assumed
> it wasn't "portable enough" ...
You can still test for whether or not it is d
On Wed, 9 Jul 2003 18:27:21 -0400
"Ben Goodwin" <[EMAIL PROTECTED]> wrote:
> Hi guys ...
>
> I thought I'd give you a heads-up that I'm porting libnss-mysql to the NSS
> API that FreeBSD 5.1 has adopted in case anyone has input, suggestions,
> want
I'd like to support Sun's cc, however .. so I'm betting that isn't defined
(I will check) ... I figured that would be available under gcc but assumed
it wasn't "portable enough" ...
And yes, one API would be nice. Each OS has their own :-\
Thanks!
-=| Ben
> You should be able to do:
>
>
On Wed, Jul 09, 2003 at 06:27:21PM -0400, Ben Goodwin wrote:
> Hi guys ...
>
> I thought I'd give you a heads-up that I'm porting libnss-mysql to the NSS
> API that FreeBSD 5.1 has adopted in case anyone has input, suggestions,
> wants to test, etc..
> I'
Hi guys ...
I thought I'd give you a heads-up that I'm porting libnss-mysql to the NSS
API that FreeBSD 5.1 has adopted in case anyone has input, suggestions,
wants to test, etc..
I'm also curious about including it eventually .. via ports or something
perhaps?
Is anyone else
hi,
I have a FreeBSD 5.1 box running with ldap authentication... is fine.
The only problem is about the groups.
I have one ldap server, and linux clients and FreeBSD ones. The ldap.conf
file that i have in the FreeBSD 5.1 machines is the same of the linux clients.
In the linux clients environm
What is the current status of using an LDAP server together with
PAM for authentication in FreeBSD? Has anybody got around to
implement a working solution for configuring the name service
information routines in libc (e.g. nsswitch.conf or something
similar)?
Search in the mailing list archives s
[ long email --- there's a specific question at the end ]
I've started work a couple of weeks ago to port the NSS implementation
from NetBSD to FreeBSD. This is needed for things like authenticating
with an LDAP server, etc. If you search for LDAP in Hackers you'll find
a thread
Good morning,
I plan to experiment with LDAP, especially using it for
distributing the userdb.
On the lists I found that some approaches were already
discussed. The two major candidates were NSS and userfs,
while for the NSS solution someone already posted some
initial code (porting NSS fom
Is
> there a website that goes in depth about the project.
>
>
I've been very busy and seem to be the only one doing something
along this line. As I said earlier, I've ported the nss stuff from
NetBSD and posted some patches to the list a while back that
had the nsdispatch fun
Is
> there a website that goes in depth about the project.
>
>
I've been very busy and seem to be the only one doing something
along this line. As I said earlier, I've ported the nss stuff from
NetBSD and posted some patches to the list a while back that
had the nsdispatch fun
the NSS (Name Service Switch):
> *Step One: I ported the NetBSD implementation of nsdispatch(3) as
> implemented
> by Luke Mewburn. See attached patch to libc and new header file. I'm also
> attaching the man page for /etc/nsswitch.conf. Right now it compiles,
> installs, an
on the NSS (Name Service Switch):
> *Step One: I ported the NetBSD implementation of nsdispatch(3) as implemented
> by Luke Mewburn. See attached patch to libc and new header file. I'm also
> attaching the man page for /etc/nsswitch.conf. Right now it compiles,
> installs, and w
On Thu, 5 Aug 1999, Jordan K. Hubbard wrote:
> > Mm-hmm. ld -Bshareable as opposed to ar rc.
>
> This demonstrates a superficial understanding of the process, nothing
> more.
I know exactly how an ar archive is made of all the non-PIC .o files and
a ranlib works. I know what happens when ld puts
> Mm-hmm. ld -Bshareable as opposed to ar rc.
This demonstrates a superficial understanding of the process, nothing
more.
> I just think we're not seeing eye to eye.
I'd be more inclined to say that John simply understands this where
you don't. Go study up, then come back and engage the poor gu
On Thu, 5 Aug 1999, Jordan K. Hubbard wrote:
> > Mm-hmm. ld -Bshareable as opposed to ar rc.
>
> This demonstrates a superficial understanding of the process, nothing
> more.
I know exactly how an ar archive is made of all the non-PIC .o files and
a ranlib works. I know what happens when ld put
> Mm-hmm. ld -Bshareable as opposed to ar rc.
This demonstrates a superficial understanding of the process, nothing
more.
> I just think we're not seeing eye to eye.
I'd be more inclined to say that John simply understands this where
you don't. Go study up, then come back and engage the poor g
On Thu, 5 Aug 1999, John Polstra wrote:
> In article ,
> Brian F. Feldman wrote:
> >
> > Mind pointing me to the technical reason why (I'm sure you've explained
> > it before) we can't use the dl* calls in any way without linking
> > against ld-elf.so.1? I mean, have them in libc, for instance..
In article ,
Brian F. Feldman wrote:
>
> Mind pointing me to the technical reason why (I'm sure you've explained
> it before) we can't use the dl* calls in any way without linking
> against ld-elf.so.1? I mean, have them in libc, for instance...
The versions in libc are just stubs. Take a look
On Thu, 5 Aug 1999, John Polstra wrote:
> In article <[EMAIL PROTECTED]>,
> Brian F. Feldman <[EMAIL PROTECTED]> wrote:
> >
> > Mind pointing me to the technical reason why (I'm sure you've explained
> > it before) we can't use the dl* calls in any way without linking
> > against ld-elf.so.1? I
In article <[EMAIL PROTECTED]>,
Brian F. Feldman <[EMAIL PROTECTED]> wrote:
>
> Mind pointing me to the technical reason why (I'm sure you've explained
> it before) we can't use the dl* calls in any way without linking
> against ld-elf.so.1? I mean, have them in libc, for instance...
The version
On Thu, 5 Aug 1999, John Polstra wrote:
>
> > My position was (and still is) that for most purposes dynamic
> > linking is a definite advantage, but we should continue to permit
> > static linking for applications that want it (which Sun doesn't).
>
> I generally agree, except I feel that when t
On Thu, 5 Aug 1999, John Polstra wrote:
>
> > My position was (and still is) that for most purposes dynamic
> > linking is a definite advantage, but we should continue to permit
> > static linking for applications that want it (which Sun doesn't).
>
> I generally agree, except I feel that when
Peter Jeremy wrote:
> I apologize if I gave anyone the impression that you couldn't build
> statically linked executables with libpam.
Sorry I was so prickly about it.
> I recall having a similar static-vs-dynamic discussion with you a couple
> of years ago.
Yow, your memory is better than mine
Peter Jeremy wrote:
> I apologize if I gave anyone the impression that you couldn't build
> statically linked executables with libpam.
Sorry I was so prickly about it.
> I recall having a similar static-vs-dynamic discussion with you a couple
> of years ago.
Yow, your memory is better than min
out or keep quiet
>on the mailing list.
Maybe I should have worded it differently: In order to build statically
linked applications, both PAM and NSS have to solve a similar problem.
If it can or has been solved for PAM (which I wasn't sure about), the
same (or a very similar) solution will work
PAM, so I can't be sure.
>
>When you're not sure, it's really best to find out or keep quiet
>on the mailing list.
Maybe I should have worded it differently: In order to build statically
linked applications, both PAM and NSS have to solve a similar problem.
If it can or ha
t happened, it would have to be considered a severe design
error.
> (or has been corrupted somehow).
Many things can get corrupted to make the system unrecoverable. For
example: the kernel, init itself, entries in the /dev directory, and
various combinations of cp, fsck, newfs, restore, ...
>
s combinations of cp, fsck, newfs, restore, ...
> The idea of being able to dynamically add new password encrytion
> schemes (PAM) or database access methods (NSS) is generally good.
> The problems appear when you try to marry these schemes with the
> system security and initialisatio
On Wed, 4 Aug 1999, Oscar Bonilla wrote:
[skip]
> 2. Make the C library nsdispatch aware. The dtab[] array will be
>filled dynamicaly from the contents of /etc/nsswitch.conf.
>I'm still not sure if this has to be done "whithin" the C library
>or if nsdispatch should fill the dtab[] arr
On Wed, 4 Aug 1999, Oscar Bonilla wrote:
[skip]
> 2. Make the C library nsdispatch aware. The dtab[] array will be
>filled dynamicaly from the contents of /etc/nsswitch.conf.
>I'm still not sure if this has to be done "whithin" the C library
>or if nsdispatch should fill the dtab[] ar
a partition that isn't mounted yet (or has
been corrupted somehow).
The idea of being able to dynamically add new password encrytion
schemes (PAM) or database access methods (NSS) is generally good.
The problems appear when you try to marry these schemes with the
system security and initialisati
ecause the appropriate
encryption library is on a partition that isn't mounted yet (or has
been corrupted somehow).
The idea of being able to dynamically add new password encrytion
schemes (PAM) or database access methods (NSS) is generally good.
The problems appear when you try to marry th
After collecting a bunch of emails from the list, this is the
approach I'll be taking:
1. use the existing nsdispatch code obtained from NetBSD as a base
for parsing the /etc/nsswitch.conf file.
2. Make the C library nsdispatch aware. The dtab[] array will be
filled dynamicaly from the cont
After collecting a bunch of emails from the list, this is the
approach I'll be taking:
1. use the existing nsdispatch code obtained from NetBSD as a base
for parsing the /etc/nsswitch.conf file.
2. Make the C library nsdispatch aware. The dtab[] array will be
filled dynamicaly from the con
Peter Jeremy writes:
> We need to be able to build an application that has no dynamically
> loaded code for recovery purposes (/stand and /sbin) as well as for
> security.
Isn't that the same problem as with PAM?
/assar
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freeb
Peter Jeremy <[EMAIL PROTECTED]> writes:
> We need to be able to build an application that has no dynamically
> loaded code for recovery purposes (/stand and /sbin) as well as for
> security.
Isn't that the same problem as with PAM?
/assar
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "u
On Wed, 4 Aug 1999, Peter Jeremy wrote:
> Oscar Bonilla wrote:
> >If anyone has any comments, suggestions, etc. I would appreciate it.
>
> Overall, I like the idea of NSS. But, having worked on Solaris 2.x
> for some time, we need to avoid some of the blunders Sun made: The
On Wed, 4 Aug 1999, Peter Jeremy wrote:
> Oscar Bonilla <[EMAIL PROTECTED]> wrote:
> >If anyone has any comments, suggestions, etc. I would appreciate it.
>
> Overall, I like the idea of NSS. But, having worked on Solaris 2.x
> for some time, we need to avoid some of th
e we have to implement _local_getpw, _dns_getpw, _nis_getpw,
> and _compat_getpwent and make them behave as expected.
> NetBSD seems to support having the passwd database on DNS using something
> called HESIOD (I hadn't heard about it before). I don't think FreeBSD
> *Step Three
to implement _local_getpw, _dns_getpw, _nis_getpw,
> and _compat_getpwent and make them behave as expected.
> NetBSD seems to support having the passwd database on DNS using something
> called HESIOD (I hadn't heard about it before). I don't think FreeBSD
> *Step Three: I
Oscar Bonilla wrote:
>If anyone has any comments, suggestions, etc. I would appreciate it.
Overall, I like the idea of NSS. But, having worked on Solaris 2.x
for some time, we need to avoid some of the blunders Sun made: The
biggest problem with Sun's NSS implementation is that it
Oscar Bonilla <[EMAIL PROTECTED]> wrote:
>If anyone has any comments, suggestions, etc. I would appreciate it.
Overall, I like the idea of NSS. But, having worked on Solaris 2.x
for some time, we need to avoid some of the blunders Sun made: The
biggest problem with Sun's NSS imp
> From: Jason Thorpe
> Date: 1999-08-03 12:04:48 -0700
> To: Oscar Bonilla
> Subject: Re: Berkeley IRS and NSS
> Cc: freebsd-hackers@FreeBSD.ORG
> Delivered-to: freebsd-hackers@freebsd.org
> X-Loop: FreeBSD.ORG
>
> On Tue, 3 Aug 1999 11:28:29 -0600
> Oscar Bonil
On Tue, 3 Aug 1999 11:28:29 -0600
Oscar Bonilla wrote:
> Anyone knows about the BSD Information Retrieval Service (IRS)
> mentioned in http://www.padl.com/nss_ldap.html ?
> It seems to accomplish the same thing as the NSS stuff we've been
> talking about.
In NetBSD, we sp
> From: Jason Thorpe <[EMAIL PROTECTED]>
> Date: 1999-08-03 12:04:48 -0700
> To: Oscar Bonilla <[EMAIL PROTECTED]>
> Subject: Re: Berkeley IRS and NSS
> Cc: [EMAIL PROTECTED]
> Delivered-to: [EMAIL PROTECTED]
> X-Loop: FreeBSD.ORG
>
> On Tue, 3 Aug 1999
On Tue, 3 Aug 1999 11:28:29 -0600
Oscar Bonilla <[EMAIL PROTECTED]> wrote:
> Anyone knows about the BSD Information Retrieval Service (IRS)
> mentioned in http://www.padl.com/nss_ldap.html ?
> It seems to accomplish the same thing as the NSS stuff we've been
> talkin
Anyone knows about the BSD Information Retrieval Service (IRS)
mentioned in http://www.padl.com/nss_ldap.html ?
It seems to accomplish the same thing as the NSS stuff we've been
talking about.
Regards,
-Oscar
--
For PGP Public Key: finger oboni...@fisicc-ufm.edu
To Unsubscribe: send ma
Anyone knows about the BSD Information Retrieval Service (IRS)
mentioned in http://www.padl.com/nss_ldap.html ?
It seems to accomplish the same thing as the NSS stuff we've been
talking about.
Regards,
-Oscar
--
For PGP Public Key: finger [EMAIL PROTECTED]
To Unsubscribe: send ma
On Tue, 3 Aug 1999, Oscar Bonilla wrote:
>
> Following on the NSS (Name Service Switch):
>
> *Step One: I ported the NetBSD implementation of nsdispatch(3) as
> implemented
> by Luke Mewburn. See attached patch to libc and new header file. I'm also
> attac
Following on the NSS (Name Service Switch):
*Step One: I ported the NetBSD implementation of nsdispatch(3) as implemented
by Luke Mewburn. See attached patch to libc and new header file. I'm also
attaching the man page for /etc/nsswitch.conf. Right now it compiles,
installs, and works for
On Tue, 3 Aug 1999, Oscar Bonilla wrote:
>
> Following on the NSS (Name Service Switch):
>
> *Step One: I ported the NetBSD implementation of nsdispatch(3) as implemented
> by Luke Mewburn. See attached patch to libc and new header file. I'm also
> attachin
Following on the NSS (Name Service Switch):
*Step One: I ported the NetBSD implementation of nsdispatch(3) as implemented
by Luke Mewburn. See attached patch to libc and new header file. I'm also
attaching the man page for /etc/nsswitch.conf. Right now it compiles,
installs, and work
hi, there!
So what is the "official" status of NSS impl.?
Are there any takers?
/fjoe
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
hi, there!
So what is the "official" status of NSS impl.?
Are there any takers?
/fjoe
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
NetBSD has had this for a while.
- ad
On Fri, 28 May 1999, Max Khon wrote:
> hi, there!
>
> On Thu, 27 May 1999, Chuck Robey wrote:
>
> > > Are there any projects to implement NSS under FreeBSD (or other *BSDs)?
> >
> > Might be courteous of you, if you coul
hi, there!
On Thu, 27 May 1999, Chuck Robey wrote:
> > Are there any projects to implement NSS under FreeBSD (or other *BSDs)?
>
> Might be courteous of you, if you could at least include *some* kind of
> definition of what NSS is (like maybe a web pointer?)
ah, I'm sorry.
On Fri, 28 May 1999, Max Khon wrote:
> hi, there!
>
> Are there any projects to implement NSS under FreeBSD (or other *BSDs)?
Might be courteous of you, if you could at least include *some* kind of
definition of what NSS is (like maybe a we
hi, there!
Are there any projects to implement NSS under FreeBSD (or other *BSDs)?
/fjoe
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
80 matches
Mail list logo