Hi, I think it's time to retire NIS. The current code is now over 25 years old, and the protocol had already 25 years ago big drawbacks. Which SUN tried to solve with NIS+, but that wasn't really successful. Which leads to the problem that the few NIS users run more and more into problems, since NIS doesn't fit anymore together with current network technologies, security requirements and in general modern technologies like Container and k8s. Additional quite some of the features don't work anymore in most networks or at all and we had to patch several core libraries so that NIS can still work. RPC itself, the base service, also has many limitations and was never designed for current network technologies and is creating more and more problems today. So the increasing work is not because of bugs in the code, but because the technology around changed incompatible. My plan is: - drop ypserv from Factory - remove our own changes for NIS from the code - drop ypbind/yp-tools/libnss_nis/... from Factory Of course, the code will still exist in the network:NIS devel project and continues to stay there, at least as long as it works without major efford. But we will not revert new changes in core libraries only to keep NIS working. And we will of course not patch upstream tools having NIS support like the dhcp server and clients, but you will have to configure this yourself. So if you are still using NIS, you should think about switching to something more modern and secure, e.g. LDAP. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Ivo Totev (HRB 36809, AG Nürnberg)
Am 2022-02-04 12:32, schrieb Thorsten Kukuk:
Hi,
I think it's time to retire NIS.
I disagree. NIS still works, and does what it is supposed to.
The current code is now over 25 years old, and the protocol had already 25 years ago big drawbacks. Which SUN tried to solve with NIS+, but that wasn't really successful.
Which leads to the problem that the few NIS users run more and more into problems, since NIS doesn't fit anymore together with current network technologies, security requirements and in general modern technologies like Container and k8s.
I can't really confirm that. I have my network here based around a nis+autofs+nfs setup, and everything including "barebone" containers on several hosts and my K3s are playing along just fine.
Additional quite some of the features don't work anymore in most networks or at all and we had to patch several core libraries so that NIS can still work.
RPC itself, the base service, also has many limitations and was never designed for current network technologies and is creating more and more problems today. So the increasing work is not because of bugs in the code, but because the technology around changed incompatible.
My plan is: - drop ypserv from Factory
Not without a replacement, please.
- remove our own changes for NIS from the code - drop ypbind/yp-tools/libnss_nis/... from Factory
And what is going to be the replacement? Will there be something included in Leap/TW that is easy to use? Like, FreeIPA?
Of course, the code will still exist in the network:NIS devel project and continues to stay there, at least as long as it works without major efford. But we will not revert new changes in core libraries only to keep NIS working. And we will of course not patch upstream tools having NIS support like the dhcp server and clients, but you will have to configure this yourself.
So if you are still using NIS, you should think about switching to something more modern and secure, e.g. LDAP.
You mean, run a fullsized IPA server just because I want to hand out a few userIDs and automounter maps? Please provide FreeIPA early enough before dropping NIS. There are packages in security:idm but I haven't tried them yet. Cheers MH -- Mathias Homann Mathias.Homann@openSUSE.org xmpp: lemmy@tuxonline.tech matrix: @mathias:eregion.de irc: [Lemmy] on liberachat and ircnet obs/pmbs: lemmy04 gpg key fingerprint: 8029 2240 F4DD 7776 E7D2 C042 6B8E 029E 13F2 C102
On 04.02.22 12:52, Mathias Homann wrote:
Am 2022-02-04 12:32, schrieb Thorsten Kukuk:
Hi,
I think it's time to retire NIS.
I disagree. NIS still works, and does what it is supposed to.
I agree with the disagreement ;-) My usecase here: propagate user ids and automounter maps for nfs mounts (home and some file shares) from my central server to all machines in the network. Security is not really a concern in this setup, and NIS / ypbind is simple and "just works". LDAP for this usecase was a major PITA last I looked (ok, 15 years back), even the userid lookup was orders of magnitude slower (and this was in a professionally managed corporate setup, I did not even have to care for the LDAP server setup. Still it worked much better with NIS than with LDAP back in the nürnberg suse network). Let's assume that this gets dropped from openSUSE: Is there a replacement that's simple to set up? something like dnsmasq is for dhcp, just for LDAP? Just to publish a central /etc/passwd into the network, I don't really want to research database layouts, LDAP schemes, object classes and whatever. So like dnsmasq simply uses /etc/hosts to configure its name server, is there something similar for LDAP that just reads /etc/passwd and friends and publishes this in a ready-to-use LDAP format? If not, this will be hard loss. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman
On Friday 2022-02-04 13:21, Stefan Seyfried wrote:
I disagree. NIS still works, and does what it is supposed to.
LDAP for this usecase was a major PITA last I looked (ok, 15 years back), even the userid lookup was orders of magnitude slower (and this was in a
Isn't that because NIS copies the user database to where it is used? LDAP doesn't, by default. You have to explicitly make a replica if indeed you want such. Alternatively, there is sssd, and sssd has caching, so it's only slow on the very first load.
389DS + sssd probably are the best replacements, especially given they are supported by SUSE - however they understandably add a lot of overhead for people coming from pure NIS. I understand both sides here and I think it comes down to it not being feasible to maintain NIS further whilst there not being a similarly legacy alternative to NIS - nowadays, local networks either run LDAP/Kerberos, use some configuration management software taking care of updating /etc/[passwd|group|sudoers], or shift to cloud services. :-( On 2/4/22 13:35, Jan Engelhardt wrote:
On Friday 2022-02-04 13:21, Stefan Seyfried wrote:
I disagree. NIS still works, and does what it is supposed to.
LDAP for this usecase was a major PITA last I looked (ok, 15 years back), even the userid lookup was orders of magnitude slower (and this was in a
Isn't that because NIS copies the user database to where it is used? LDAP doesn't, by default. You have to explicitly make a replica if indeed you want such.
Alternatively, there is sssd, and sssd has caching, so it's only slow on the very first load.
On Fri, Feb 04, Jan Engelhardt wrote:
On Friday 2022-02-04 13:21, Stefan Seyfried wrote:
I disagree. NIS still works, and does what it is supposed to.
LDAP for this usecase was a major PITA last I looked (ok, 15 years back), even the userid lookup was orders of magnitude slower (and this was in a
Isn't that because NIS copies the user database to where it is used? LDAP doesn't, by default. You have to explicitly make a replica if indeed you want such.
No, NIS does not copy the user database. Ok, 25 years ago there were some commercial UNIX, where the "NIS implementation" was to copy the passwd database to the client via cron job. But luckily none of this systems did survive for long ;) NIS also makes a query from the client side on the server for every single lookup. Plain NIS is much slower than LDAP. But 25 years ago I added some special support in glibc and RPC for Linux-NIS and I wrote nscd for this reason :)
Alternatively, there is sssd, and sssd has caching, so it's only slow on the very first load.
Correct, sssd is the way to go today if you use LDAP. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Ivo Totev (HRB 36809, AG Nürnberg)
Am 2022-02-04 13:21, schrieb Stefan Seyfried:
On 04.02.22 12:52, Mathias Homann wrote:
Am 2022-02-04 12:32, schrieb Thorsten Kukuk:
Hi,
I think it's time to retire NIS.
I disagree. NIS still works, and does what it is supposed to.
I agree with the disagreement ;-)
My usecase here: propagate user ids and automounter maps for nfs mounts (home and some file shares) from my central server to all machines in the network.
Security is not really a concern in this setup, and NIS / ypbind is simple and "just works".
LDAP for this usecase was a major PITA last I looked (ok, 15 years back), even the userid lookup was orders of magnitude slower (and this was in a professionally managed corporate setup, I did not even have to care for the LDAP server setup. Still it worked much better with NIS than with LDAP back in the nürnberg suse network).
Let's assume that this gets dropped from openSUSE: Is there a replacement that's simple to set up? something like dnsmasq is for dhcp, just for LDAP? Just to publish a central /etc/passwd into the network, I don't really want to research database layouts, LDAP schemes, object classes and whatever. So like dnsmasq simply uses /etc/hosts to configure its name server, is there something similar for LDAP that just reads /etc/passwd and friends and publishes this in a ready-to-use LDAP format?
If not, this will be hard loss.
I've been teaching people how to set up and use FreeIPA for five years in RH413, and I've been pondering switching from NIS to FreeIPA ever since I first saw it - and every time I hit that "NFSv4 fro kerberized NFS" part I realize that NFSv4 has no support for standard linux ACLs, and does NFS ACLs *instead* which would mean that for each file I'd have TWO sets of ACLs (for NFS and for SMB), and that usually is when I quote that line from game of thrones... "not today." Seriously, completely dropping nis would be a seriously hard loss. Cheers MH -- Mathias Homann Mathias.Homann@openSUSE.org xmpp: lemmy@tuxonline.tech matrix: @mathias:eregion.de irc: [Lemmy] on liberachat and ircnet obs/pmbs: lemmy04 gpg key fingerprint: 8029 2240 F4DD 7776 E7D2 C042 6B8E 029E 13F2 C102
On Fri, Feb 04, Mathias Homann wrote:
Am 2022-02-04 12:32, schrieb Thorsten Kukuk:
Hi,
I think it's time to retire NIS.
I disagree. NIS still works, and does what it is supposed to.
Some of the features don't work anymore since years, and the full client side is only working because we actively have to track down changes in core libraries and have to revert them. Which then introduces security risks, missing or broken features and maintenance burdens for others. And the people impacted by this are much more than the NIS users.
The current code is now over 25 years old, and the protocol had already 25 years ago big drawbacks. Which SUN tried to solve with NIS+, but that wasn't really successful.
Which leads to the problem that the few NIS users run more and more into problems, since NIS doesn't fit anymore together with current network technologies, security requirements and in general modern technologies like Container and k8s.
I can't really confirm that. I have my network here based around a nis+autofs+nfs setup, and everything including "barebone" containers on several hosts and my K3s are playing along just fine.
I heavily doubt that you use NIS inside the containers or K8S for authentication. I'm pretty sure you only use it for the users on your Container Host OS. Ever tried to connect a postfix, roundcube or any other container to NIS for user authentication? It will not work without killing your container network. K8S to my knowledge still has no real UDP support and the socket shortcut for performance reasons will not work in containers. Without this shortcuts, the NIS protocol will open and close many UDP ports very fast...
Additional quite some of the features don't work anymore in most networks or at all and we had to patch several core libraries so that NIS can still work.
RPC itself, the base service, also has many limitations and was never designed for current network technologies and is creating more and more problems today. So the increasing work is not because of bugs in the code, but because the technology around changed incompatible.
My plan is: - drop ypserv from Factory
Not without a replacement, please.
- remove our own changes for NIS from the code - drop ypbind/yp-tools/libnss_nis/... from Factory
And what is going to be the replacement?
A possible replacement is already there since a long time: LDAP. There are several LDAP daemons available on Tumbleweed, and I use a container for my small home network: https://en.opensuse.org/Portal:Container/Image/openldap https://github.com/thkukuk/containers-mailserver/blob/master/openldap/README... It's really simple to add the few users you need. And even much easier to attach a postfix and roundcube container to it for user authentication :) And it's secure. I don't regret to take the little time to learn the LDAP basics and replace NIS at home. Solved many problems.
Will there be something included in Leap/TW that is easy to use? Like, FreeIPA?
Of course, the code will still exist in the network:NIS devel project and continues to stay there, at least as long as it works without major efford. But we will not revert new changes in core libraries only to keep NIS working. And we will of course not patch upstream tools having NIS support like the dhcp server and clients, but you will have to configure this yourself.
So if you are still using NIS, you should think about switching to something more modern and secure, e.g. LDAP.
You mean, run a fullsized IPA server just because I want to hand out a few userIDs and automounter maps?
You don't need an IPA server or anything similar complex and big as NIS replacement. Thorsten
Please provide FreeIPA early enough before dropping NIS.
There are packages in security:idm but I haven't tried them yet.
Cheers MH
-- Mathias Homann Mathias.Homann@openSUSE.org xmpp: lemmy@tuxonline.tech matrix: @mathias:eregion.de irc: [Lemmy] on liberachat and ircnet obs/pmbs: lemmy04 gpg key fingerprint: 8029 2240 F4DD 7776 E7D2 C042 6B8E 029E 13F2 C102
-- Thorsten Kukuk, Distinguished Engineer, Senior Architect SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Ivo Totev (HRB 36809, AG Nürnberg)
On Fri, 2022-02-04 at 14:04 +0100, Thorsten Kukuk wrote:
A possible replacement is already there since a long time: LDAP. There are several LDAP daemons available on Tumbleweed, and I use a container for my small home network: https://en.opensuse.org/Portal:Container/Image/openlda
I'd recommend avoiding straight-LDAP; the management tools are weak, making changes can be tedious. Creating a Active Directory domain with Samba4 is almost effortless. It provides a robust set of commands for managing users. It is fast, and clients [members] will cache. It is also something almost all other tools are familiar with. -- Adam Tauno Williams, awilliam@whitemice.org Multi-Modal Activists Against Auto Dependent Development resisting the unAmerican socialists of the Motorist hegemony http://www.mmaaadd.org
Mathias Homann wrote:
Please provide FreeIPA early enough before dropping NIS. There are packages in security:idm but I haven't tried them yet.
On that note, I have a freeipa server now (running on docker, using the official, stable image published by freeipa.org), and I had quite the mixed bag of results trying to hook up all my different 'puters... - debian buster: no problems. - RHEL 8 and RHEL 9 Beta: no problems. - Various different flavours of raspbian: no problems - openSUSE Leap 15.3: no joy. Tried with yast, tried with the freeipa packages from OBS, it simply fails and tries to tell me that it can't talk to my ipa. What's even more fun: if I try only yast and no freeipa-client from OBS it doesn't even automatically install the krb5 tools... (kinit: command not found). - openSUSE Tumbleweed: after three different machines initially failing in three different ways when I ran "ipa-client-install -U -N --no-nisdomain -p *** -w ***" I found that after that you have to still go into yast2 auth-client to actually enable domain logins, but then it works fine. Still - way too painful to be fun. On that note, has anyone else managed to hook a Leap 15.3 to ipa? Cheers MH -- Mathias Homann Mathias.Homann@openSUSE.org Jabber (XMPP): lemmy@tuxonline.tech Matrix: @mathias:eregion.de IRC: [Lemmy] on freenode and ircnet (bouncer active) keybase: https://keybase.io/lemmy gpg key fingerprint: 8029 2240 F4DD 7776 E7D2 C042 6B8E 029E 13F2 C102
On Do, Mai 12 2022 at 17:19:02 -0000, Mathias Homann <mathias.homann@opensuse.org> wrote:
- openSUSE Leap 15.3: no joy. Tried with yast, tried with the freeipa packages from OBS, it simply fails and tries to tell me that it can't talk to my ipa. What's even more fun: if I try only yast and no freeipa-client from OBS it doesn't even automatically install the krb5 tools... (kinit: command not found). - openSUSE Tumbleweed: after three different machines initially failing in three different ways when I ran "ipa-client-install -U -N --no-nisdomain -p *** -w ***" I found that after that you have to still go into yast2 auth-client to actually enable domain logins, but then it works fine.
That's expected, if it worked, it would be on Tumbleweed, and even then, it's not ready due to some things in release management that are still getting figured out. We wanted to get it going before Leap 16, since it requires deep changes to the distro, but that's getting delayed all the time too ;) LCP [Sasi] https://lcp.world/
participants (8)
-
Adam Tauno Williams -
Georg Pfuetzenreuter -
Jan Engelhardt -
Mathias Homann -
Mathias Homann
-
Sasi Olin -
Stefan Seyfried -
Thorsten Kukuk