| Gabriel Nagy, I agree that using binaries from 2 different packages in the same provider seems wrong. That's the primary reason why I think there should be two separate providers, even though there is a lot of overlap between the functionality of the providers. Upon reflection, I will walk back my "If both the libuser provider and the groupadd provider are available, prefer the libuser provider" assertion. But I'm not sure that the minor differences in functionality are appropriate selection criteria to prefer one provider over the other, either. As you noted, libuser doesn't support NIS (which shadow supports). But shadow doesn't support LDAP (which libuser supports). How about this: for any system where groupadd is currently the default provider, it should remain the default provider, even if the libuser provider is available. This will make the libuser provider available for those who specifically want it (most likely for the manages_members feature), but it will avoid potential disruption by exposing Puppet users to subtle differences between the groupadd and libuser providers. But I still think that once the libuser provider is available, the forcelocal parameter should be deprecated, and should emit a warning that 1) the forcelocal parameter will be removed in a future Puppet release, and 2) to use the libuser provider instead if the goal is have the manages_members feature. Finally, I wouldn't put much stock in the 2013 comment 2 in Red Hat BZ#1028544 about libuser going away. A lot of what libuser was planned to do was subsumed by the sssd project, which is why development on libuser has slowed. But both the shadow project and the libuser project are active. As another metric, Red Hat Enterprise Linux 8 shipped with libuser. Since libuser was created by Red Hat developers and is maintained by Red Hat developers, that means libuser isn't going anywhere for the lifetime of RHEL8, which doesn't end until May 2029. And libuser is still in Fedora, which is (essentially) the upstream for RHEL. |
