On Tue, Feb 02, 2021 at 01:21:24PM +0100, Thomas Lange wrote:
On Tue, 2 Feb 2021 12:35:29 +0100, "Francesco P. Lovergine"
<fran...@debian.org> said:
> /usr/share/yp/templates/var_yp_nicknames
Hi Francesco,
Ah, I didn't saw this.
Yep, maybe adding a note about templates available under
/usr/share/yp/templates could be useful for most people, just in case.
> In postinst ucf should manage the update of that file. Did you upgrade or
> install from scratch? If upgraded, did you upgrade from nis 3.x or had a
> previous version of yp-tools installed (that was available at least in the
> last pair of years as a separate package). All that should be evident
> from dpkg logs. That's just to understand where the problem could be.
I've upgraded a bullseye system which was runnning nis 3.x as a nis client, and
I got 4.x.
This is a nis client, but when upgrading the packages it also
installed the ypserv package. I had to manually fix some nis
things. ypbind was not started automatically.
Eh, at upgrade time there is no way to know in advance if your box is a
client, a server or both. You can eventually remove the `nis` package and
`ypserv` after the upgrade. Note that even /etc/default/nis is now optional.
If you had not 'true' for NISCLIENT in /etc/default/nis then the ypbind
service is not started automagically - as expected - and you need to
enable+start ypbind.service via systemctl, after checking for domainname and
yp.conf setup. In bookworm I'll introduce a nis-doc package and drop
definitively the old nis package which is perfectly unuseful, but for the howto doc.
This is completely uncorrelated with the nicknames drop anyway.
This is not problem for me, because I usually do a complete reinstall
and no dist-upgrade.
I'm not sure if I wil lbe able to check again if an upgrade break in
my environment. Feel free to close the bug.
Well, I checked multiple times upgrades of nis for stable, and never
saw that type of behavior, I guess you stopped at ucf prompt to check the
situation and never continued after: that could be one (the only?) reason
for the missing file. I'll check again to verify that no latest change
altered the upgrade path somehow before closing this bug. Thanks.
--
Francesco P. Lovergine
