Package Details: ypbind-mt 2.6.1-2

Git Clone URL: (read-only, click to copy)
Package Base: ypbind-mt
Description: Linux NIS daemon
Upstream URL:
Licenses: GPL2
Submitter: arojas
Maintainer: bidulock
Last Packager: bidulock
Votes: 5
Popularity: 0.000000
First Submitted: 2017-07-06 19:22
Last Updated: 2021-09-13 01:13

Latest Comments

1 2 Next › Last »

bidulock commented on 2019-11-01 16:15

Fixed. That you @arbalest for reporting it.

arbalest commented on 2019-11-01 04:08

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.

sebstar commented on 2018-05-08 13:49

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 and

lisaev commented on 2018-01-09 10:27

@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.

sebstar commented on 2017-11-07 17:43

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?

lisaev commented on 2017-10-10 15:50

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.

bidulock commented on 2017-10-10 12:52

Maybe start a ypbind-mt2 and yp-tools4 for that. Binding to an ipv6 NIS server is not something anyone really needs I don't suppose.

lisaev commented on 2017-10-08 21:13

(sorry, forgot in the previous post) I can upload and maintain libnsl2 if you'd be interested (I don't see much use of it for anything else except NIS/YP). FYI, the corresponding package in fedora is

lisaev commented on 2017-10-08 21:10

Also, would you be interested in upgrading all YP/NIS tools to their latest versions? They require libnsl v2 (v1 is included in our glibc).

I have ypserv, ypbind-mt, yp-tools and libnsl built and working on our infrastructure. So far so good, even in a mixed environment (ypserv and yp-tools from current git on NIS master/slave and ypbind-1.38 on fedora clients)...

lisaev commented on 2017-10-08 21:05

@bidulock: Of course yp-tools builds fine without ypbind, but I think so does ypbint-mt without yp-tools... However, ypbind-mt needs domainname.service from yp-tools and yp-tools are useless without binding to a YP domain.

Therefore, yp-tools should express an optdepend on ypbind-mt.