Arch Linux User Repository

Another trick I have come to use is to set up a local ypserv on each client machine that slaves from the master that it would normally ypbind to. That way ypbind can bind to the local server on the loopback interface and the local ypserv will slave to the master whenever it can contact it. This is much more usable for user logins that need to occur with or without a network connection.

@hfath, that problem is one of dhcpcd, not ypbind. I found that the following service files works better than the dhcpcd.service that comes with dhcpcd.

[Unit]
Description=DHCP Client Daemon on all interfaces
Documentation=man:dhcpcd(8)
Wants=network.target
Before=network.target

[Service]
Type=simple
ExecStart=/usr/bin/dhcpcd -q -t 0 -B
ExecStop=/usr/bin/dhcpcd -x

[Install]
WantedBy=multi-user.target

The forking version supplied with dhcpcd allows systemd to proceed and reach network.target before dhcpcd acquires a lease, causing ypbind.service to start before there is a network interface. This simple version works better.

Another trick is to start ypbind from dhcpcd hook script instead of having it run by default. Doing that, ypbind does not start until a lease has already been acquired and the network interface configured. This latter trick works best.

On recent hardware, I find that the Arch startup is much faster than the network response, despite having dhcpcd(8) block for an IP.

The 10 sec timeout in ypbind.service are way too short. Autofs then fails to come up, giving a bad user experience.

I ended up with a generous back-stop of

ExecStartPost=/bin/sh -c "for i in `seq 1 300` ; do ypwhich >/dev/null && break; sleep 1; done"

since systemd will give the service 120 sec max., of which in my network occasionally >60 sec are required.

Fixed. That you @arbalest for reporting it.

The ypbind-mt package currently won't compile, due to a local gettid conflict with libc. This has been corrected in rev 2.6.1 of the source, have flagged the package as outdated.

Apologies for for any newbie offenses, I just registered to report this. Really appreciate the work done to maintain all these packages.

Warning to all users of server-side port security: Due to a problem in libtirpc 1.0.3, ypbind-mt won't be able to retrieve port-secured content anymore. Downgrading to libtirpc-1.0.2-3 fixes the issue for now. See https://github.com/thkukuk/ypbind-mt/issues/1 and https://bugs.archlinux.org/index.php?do=details&action=details.addvote&task_id=58502

@sebstar: In Arch, packages are moved whenever no developer wants to maintain them. The logic here is that packages should not rot in the repos, and if devs don't want to maintain them, the community will. In case of yp-* tools, the packages in [extra] were unmaintained for a long time...

NIS/YP is becoming rare due to protocol weaknesses. However, it is still being used in small setups due to its simplicity and when you can ensure that the network is secure. Also, there are cases when an Arch machine must be a part of an existing domain...

There are many alternatives to NIS, but I think the "most direct" successor is LDAP. It is more difficult to setup though.

Maybe a stupid question, but why were ypbind-mt and yp-tools moved out of the official repositories? Nothing about it is mentioned in the wiki? Is it so rare nowadays to use YP? What's the 'modern' alternative?

Or ypbind-ipv6 :) However, pls keep in mind that the version that you maintain here is not maintained upstream. Just to clarify, all our machines boot with ipv6.disable=1, and yet we use NIS utilities from git master because they work in ipv4 environment just fine. The current development of NIS utils involves bugfixes in addition to ipv6 support.