On Fri, Apr 22, 2022 at 01:41:50PM -0700, Steve Langasek wrote:
>...
> On Fri, Apr 22, 2022 at 10:07:52PM +0200, la...@debian.org wrote:
> > I'm using NIS since 20+ years in a small network with about 60 computers.
> > Since I manage all computers and the physical network can be seen as secure
> >
> On Fri, 22 Apr 2022 13:41:50 -0700, Steve Langasek
> said:
> If your users are using yppasswd on the NIS master for changing passwords,
> then evidently you are not relying on support for NIS in PAM. (yppasswd
> doesn't even link against libpam.)
Thanks for clarifying
> On Fri, 22 Apr 2022 13:41:50 -0700, Steve Langasek
> said:
> NIS also dates from a period when rsh was considered acceptable, and unless
> I'm mistaken, has a comparable level of security. Allowing access to
> password hashes for users based on the IP of the machine you are querying
> On Fri, 22 Apr 2022 13:41:50 -0700, Steve Langasek
> said:
> If your users are using yppasswd on the NIS master for changing passwords,
> then evidently you are not relying on support for NIS in PAM. (yppasswd
> doesn't even link against libpam.)
Thanks for clarifying
Hi Thomas,
On Fri, Apr 22, 2022 at 10:07:52PM +0200, la...@debian.org wrote:
> I'm using NIS since 20+ years in a small network with about 60 computers.
> Since I manage all computers and the physical network can be seen as secure
> (I know it's not perfect secure) I do not need the additional
Hi,
I'm using NIS since 20+ years in a small network with about 60 computers.
Since I manage all computers and the physical network can be seen as secure
(I know it's not perfect secure) I do not need the additional crypto
features of NIS+ or LDAP, which would be overkill. All my users use
On Thu, Apr 21, 2022 at 03:30:55PM +0300, Dmitry Baryshkov wrote:
> > > Before any discussion takes place, I would like to point out a previous
> > > attempt of Fedora trying to get rid of NIS/NIS+ back in 2021. Please
> > > check out
> > > the LWN article at https://lwn.net/Articles/874174/ ,
On Wed, Apr 20, 2022 at 10:23:06PM +0200, Gabor Gombas wrote:
> Doing a quick check, PAM only seems to rely on the RPC libraries for
> changing NIS passwords. Personally, I think losing that would not be a
> big deal. While I can still see NIS being useful in some corners of the
> world, I cannot
чт, 21 апр. 2022 г. в 11:04, Gabor Gombas :
>
> Hi,
>
> On Wed, Apr 20, 2022 at 04:26:02PM -0400, Boyuan Yang wrote:
>
> > Before any discussion takes place, I would like to point out a previous
> > attempt of Fedora trying to get rid of NIS/NIS+ back in 2021. Please check
> > out
> > the LWN
Hi,
On Wed, Apr 20, 2022 at 04:26:02PM -0400, Boyuan Yang wrote:
> Before any discussion takes place, I would like to point out a previous
> attempt of Fedora trying to get rid of NIS/NIS+ back in 2021. Please check out
> the LWN article at https://lwn.net/Articles/874174/ , which would
Hi,
On Wed, Apr 20, 2022 at 10:57:58AM -0700, Steve Langasek wrote:
> So I'd like to take a step back and challenge an underlying assumption by
> asking: do any of our users actually *need* this functionality? The RPC
> functionality is only used for NIS and NIS+. NIS is historically quite
>
Hi,
在 2022-04-20星期三的 10:57 -0700，Steve Langasek写道：
> Hi folks,
>
> As of glibc 2.32, upstream has split out RPC support; if you want RPC
> functionality, you now need to link against libtirpc instead, which is a
> superior, more featureful implementation.
>
> This is a good thing
Hi folks,
As of glibc 2.32, upstream has split out RPC support; if you want RPC
functionality, you now need to link against libtirpc instead, which is a
superior, more featureful implementation.
This is a good thing architecturally, but one of the side effects for us is
that, via PAM, we are now
13 matches
Mail list logo
