Bug 32749

Summary:	Can not install HP Smart Tank 7600 printer in mga9
Product:	Mageia	Reporter:	Tom Cox <tomc>
Component:	RPM Packages	Assignee:	Base system maintainers <basesystem>
Status:	NEW ---	QA Contact:
Severity:	major
Priority:	Normal	CC:	fri, mageiatools
Version:	9	Keywords:	FOR_ERRATA9
Target Milestone:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Source RPM:	glibc-2.36-51.mga9.src.rpm	CVE:
Status comment:

Description Tom Cox 2024-01-19 19:42:35 CET

I recently performed a urpmi inplace upgrade from mga8 to mag9. Everything went well and I noted my HP Smart Tank 7600 printer was still in the cups list. However, it was disabled and could not be enabled. I just figured it was some minor issue, and that removing it and adding it back would fix things. That's when all the trouble started. I could not add the printer using any conventional methods.

Checking the Mageia bugs list showed some similar problems with other printers in mga9, but no specific solutions for mine. I did eventually work around the problem by manually specifying the printer (DHCP) IP address and using the specific, not driverless, HP driver. It solved the print problem, but xsane still couldn't talk to the printer and it did not show up in the HP Device Manager. The hp-setup command would not work either. I also tried the cups web interface, but no joy there either when using the driverless drivers.

Through all of this, I was watching the system logs. I noticed there were IPP errors indicating it could not talk to the printer, yet IPP was working because I could print. After digging around, I finally realized that the system was not resolving mDNS host names which meant the printer installation would fail any time you tried to install a printer in a way that would need the installation process to talk to the printer using the mDNS host name. For example, selecting one of the driverless CUPS drivers would do this. I came to realize that resolving mDNS host names was not fully functional. I found the problem.

There have been changes in the way host lookups have been performed. Linux is slowly changing from relying on /etc/resolv.conf to using /etc/nsswitch.conf. In the latter file, I made a simple change. I added mdns to the hosts: entry.

hosts: files mdns nis dns wins myhostname

I can now install the printer correctly. Instead of having the specify the Device URI manually, if finds the printer and uses the mDNS entry to create the Device URI. So now, instead of "ipps://192.168.2.204", it reads "hp:/net/Smart_Tank_7600_series?hostname=HP38CA84944D88.local" The HP Device Manager and xsane both see the printer now as well.

The bug is that this change in mDNS host name lookups has changed and should be documented in the release notes. I'd also suggest the default nsswitch.conf file be changed to include mdns or one of its specific relatives.

Comment 1 Morgan Leijström 2024-01-21 22:52:05 CET

Thank you for the input.

Yes sells like for release notes, and probably a link in errata too to dorect users to it as i think there is where they look.

This is not my cup of tea, so leaving for others to decide and write the advice.

CC tools maintainers for consideration of solution.

Keywords: (none) => FOR_RELEASENOTES9
CC: (none) => fri, mageiatools

Comment 2 Lewis Smith 2024-01-22 14:59:10 CET

Thank you Tom for your lengthy and well described detective work. It looked as if the simple change:
> /etc/nsswitch.conf.  In the latter file, I made a simple change.
> I added mdns to the hosts: entry.
> hosts: files mdns nis dns wins myhostname
sorted the issue.

You said "printer installation would fail any time you tried to install a printer in a way that would need the installation process to talk to the printer using the mDNS host name. For example, selecting one of the driverless CUPS drivers would do this".

I would be surprised if that last point has not been hit elsewhere.

Apart from the example you cite, can you suggest a more general way of indicating when the problem would arise?

For the record:
/etc/nsswitch.conf is noted against glibc.
/usr/share/factory/etc/nsswitch.conf is noted against systemd.

@Morgan: It is too late for the Release Notes, it will have to be Errata. This should be fixed for M10:
> I'd also suggest the default nsswitch.conf file be changed to include
> mdns or one of its specific relatives.

Keywords: FOR_RELEASENOTES9 => FOR_ERRATA9
CC: (none) => lewyssmith

Comment 3 Tom Cox 2024-01-22 16:05:33 CET

(In reply to Lewis Smith from comment #2)

> You said "printer installation would fail any time you tried to install a
> printer in a way that would need the installation process to talk to the
> printer using the mDNS host name. For example, selecting one of the
> driverless CUPS drivers would do this".
> 
> I would be surprised if that last point has not been hit elsewhere.
> 
> Apart from the example you cite, can you suggest a more general way of
> indicating when the problem would arise?
> 
> For the record:
> /etc/nsswitch.conf is noted against glibc.
> /usr/share/factory/etc/nsswitch.conf is noted against systemd.
> 

Once I started thinking it might be a mDNS problem, I explored using ping and ssh with a .local name. I could ping other systems when I used their DNS name, but not their mDNS name. For example, 'ping peter' worked, but 'ping peter.local' would not. The same for ssh.

Using avahi-browse, I could see that peter.local existed and I could use the other avahi tools to resolve it. Once I discovered and changed nsswitch.conf, ping and ssh worked.

I was not aware of /usr/share/factory/etc/nsswitch.conf. I see that mine has a different hosts: entry compared to /etc/nsswitch.conf and that it doesn't contain mdns. It uses a different set of 'source' keywords, 'resolve' for example.  I can't find any documentation on this locally, so no idea if the systemd version has the same issue.

Comment 4 Tom Cox 2024-01-22 17:12:32 CET

I dug a little further into /usr/share/factory/etc/nsswitch.conf and nsswtich.conf in general. The 'source' keywords in the file are plugin names for libraries. I have the following:

/usr/lib64/libnss_compat.so
/usr/lib64/libnss_compat.so.2
/usr/lib64/libnss_db.so
/usr/lib64/libnss_db.so.2
/usr/lib64/libnss_dns.so.2
/usr/lib64/libnss_files.so.2
/usr/lib64/libnss_hesiod.so
/usr/lib64/libnss_hesiod.so.2
/usr/lib64/libnss_mdns4_minimal.so.2
/usr/lib64/libnss_mdns4.so.2
/usr/lib64/libnss_mdns6_minimal.so.2
/usr/lib64/libnss_mdns6.so.2
/usr/lib64/libnss_mdns_minimal.so.2
/usr/lib64/libnss_mdns.so.2
/usr/lib64/libnss_myhostname.so.2
/usr/lib64/libnss_mymachines.so.2
/usr/lib64/libnss_resolve.so.2
/usr/lib64/libnss_systemd.so.2
/usr/lib64/libnss_tcb.so.2
/usr/lib64/libnss_winbind.so.2
/usr/lib64/libnss_wins.so.2

A few have man pages.

/usr/share/man/man8/nss-myhostname.8.xz
/usr/share/man/man8/nss-mymachines.8.xz
/usr/share/man/man8/nss-resolve.8.xz
/usr/share/man/man8/nss-systemd.8.xz

The nss-resolve man page implies the plugin will return mDNS names, but that it can be disabled with a systemd environment variable. As best I can tell, that variable is not set anywhere in /etc/systemd.  Therefore nss_resolve should return nDNS names.

I was also curious about mdns_minimal. In searching, I saw examples like this:

hosts: mymachines mdns_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] files myhostname dns

The mdns_minimal plugin is authoritative for *.local domains only. That's OK, but the 'NOTFOUND=return' part causes the search to terminate. So the host 'peter' is not found because the search never reaches the dns plugin. The mdns_minimal plugin will work if you eliminate the 'NOTFOUND=return' part.  It could speed up lookups a tad if you do a lot of .local lookups. Still, I would recommend using the full mdns plugin.

katnatek 2024-01-22 18:19:07 CET

Summary: Can not install printer in mga9 => Can not install HP Smart Tank 7600 printer in mga9

Comment 5 Lewis Smith 2024-01-23 21:44:15 CET

Thank you again for your very detailed research.
Since this all hangs on ndns, I hope BaseSystem is the right place to assign it.

Severity: normal => major
Assignee: bugsquad => basesystem
CC: lewyssmith => (none)