Dax Kelson wrote: > Bob Proulx wrote: > > I am thinking that the most portable way would be to actually chgrp > > and chown something and create the group and user if it fails. > > Ugly. When I first started doing the getent checks, I examined many > different UNIX flavors from the open source BSDs, to Solaris, HP-UX and > several Linux distros going back to 1998. They all had getent. That is > portable enough for me. HP-UX does not have getent. You must have installed it yourself. I don't know about the other systems. As near as I can tell getent is a GNU glibc'ism. Since HP-UX is one of my primary platforms and it does not have getent I can't use it there. That prompted my comment about chown. Looking at vendor packages I see that they just call useradd unconditionally and ignore all output and errors from it in the case that there is an already existing account. > > On at least one of my systems the useradd command fails if the user > > exists in NIS/YP regardless of it not existing in /etc/passwd. > > Probably because useradd is doing the same getpwent/getgrent calls that > getent is doing. But probably doing it natively with getpwnam(3). > > Which I think is not good IMNHO because later if you disable NIS > > you are left without a user for the daemon. > > Only root can disable NIS/LDAP. Yes. But I fail to see your point in mentioning that. The case would be that someone installs the os and enables NIS on a network. Then they install much software such as sendmail, postfix, bind, ntp, etc. Those all try to create local user accounts. But unknown to our poor befuddled sysadmin another sysadmin had already included those users in the NIS/YP datebase. So those packages did not create any of the required users locally. Later they find that their corporate policies say NIS is insecure for their application and so the turn off NIS. At that time their system is broken. They now need to reinstall a possibly long but unknown list of packages. > A network failure could make it unavailable as well. Or a boot ordering problem. If a package starts a daemon up before the network and ypbind is started up. > As you said, I would argue that this problem space is not something that > a RPM script should care about. Agreed. It would seem that the contents of NIS/YP must not collide with any local system accounts or it invites this problem. But that is not a relationship that is known by many people. I have for my own packages (I would not distribute them this way) when I knew I had this problem just grep'd /etc/passwd and installed the user there without useradd to ensure the behavior that I wanted of local /etc/passwd entries occurred. It just seems like the useradd behavior works against you instead of with you here. :-( Bob
