Univention Bugzilla – Bug 30432
UMC module computer room can cause printers to be unavailable after samba restart
Last modified: 2013-11-19 06:42:21 CET
Printer access control using the Computer room UMC module writes incomplete printer share configuration include files in /etc/samba/local.config.d/printer.*.local.config.conf, which cause a somewhat complex pattern of unavailable printers. This was reported on Ticket#: 2013020621000851 for the case of UCS@school 3.0. The main bug is in steps two and three of this scenario: 1. A printer share was created without specifying a dedicated Samba share name. In this case, Samba dynamically loads the printer share definitions from the cups backend. After this, CLI printing via smbclient works on the DC. 2. On the DC hosting the printer the Computer room UMC module was used to configure the Print Mode to allowed/possible (for some room). Since the DC was not part of the room, CLI printing via smbclient now is denied on the DC, after the listener module triggered the smbd reload ("as expected"). =========================================================================== root@slave42:~# echo foo | smbclient //slave42/drucker1 -Uuser1%univention -c 'print -' Domain=[AR24SCHOOL] OS=[Unix] Server=[Samba 3.5.11] tree connect failed: NT_STATUS_ACCESS_DENIED =========================================================================== But in this situation testparm -sv already reports, that the printer share is marked unavailable =========================================================================== Processing section "[drucker1]" WARNING: No path in service drucker1 - making it unavailable! NOTE: Service drucker1 is flagged unavailable. =========================================================================== and =========================================================================== [drucker1] hosts allow = 10.200.32.238 available = No =========================================================================== Curious side note: In this situation it is possible to modify this "hosts allow" list in the /etc/samba/local.config.d/printer.drucker1.local.config.conf file and it becomes active "on the fly" without reloading samba. =========================================================================== [drucker1] hosts allow = 10.200.32.238, 10.200.32.42 ; only IP-Adresses.. =========================================================================== ...and CLI printing works directly on the DC. 3. If samba is *restarted* now in this configuration, the printer vanishes from the list of accessable samba shares (smbclient -L) and the printer becomes unaccessable even for the hosts that are in the "hosts allow" list: root@slave42:~# echo foo | smbclient //slave42/drucker1 -Uuser1%univention -c 'print -' Domain=[AR24SCHOOL] OS=[Unix] Server=[Samba 3.5.11] tree connect failed: NT_STATUS_BAD_NETWORK_NAME 4. When the time scheduled for this romm configuration is up, an at-job is triggered which runs the script /usr/share/ucs-school-umc-computerroom/ucs-school-deactivate-rules to unset some UCR variables, which e.g. triggers the removal of the configuration subfile, but finally does not reload the samba configuration. In this situation, the printers are accessable again for the systems listed in "hosts allow", but they are not advertised in "smbclient -L" (thus probably not browsable on windows clients). At some as yet undetermined point of time later, the printers reappear in the output of "smbclient -L".
Workaround: Define a printer share name for all printers. # udm shares/printer list --filter cn=* | sed -ne 's/^DN: //p' | while read dn; do udm shares/printer modify --dn "$dn" --set sambaName="$(echo $dn | sed 's/cn=\ (.*\),cn=printers.*/\1/')"; done
Probably point four of the scenario above should be split off into a separate bug. I guess /etc/univention/templates/scripts/samba.local.config.py somehow should trigger a samba reload..
(In reply to comment #1) > Workaround: Define a printer share name for all printers. > > # udm shares/printer list --filter cn=* | sed -ne 's/^DN: //p' | while read dn; > do udm shares/printer modify --dn "$dn" --set sambaName="$(echo $dn | sed > 's/cn=\ > (.*\),cn=printers.*/\1/')"; done The workaround is OK for UCS@school 3.0. If we provide an errata update for UCS@school 3.1, we should fix it. @Janis, if the workaround is not acceptable for the customer we should provide an erratum for UCS@school 3.0 as well.
If I understand correctly, at least some of the mentioned problems would be avoided if the printer share control was removed from the computer room module (see also Bug 30450). Is this correct?
univention/lib/share_restrictions.py should write [sharename] headers in /etc/samba/local.config.d/*.
(In reply to comment #4) > If I understand correctly, at least some of the mentioned problems would be > avoided if the printer share control was removed from the computer room module > (see also Bug 30450). Is this correct? Bug 30450 has been fixed by adding an empty "hosts deny" list, so the printer share control element doesn't have to be removed. (In reply to comment #5) > univention/lib/share_restrictions.py should write [sharename] headers in > /etc/samba/local.config.d/*. This seems to be the case (or am I missing something?): root@slave12:~# cat /etc/samba/local.config.d/printer.PDFDrucker.local.config.conf [PDFDrucker] hosts deny = "" root@slave12:~# It should be rechecked if reload/restart problem after changing access to printer shares is still a problem.
> > univention/lib/share_restrictions.py should write [sharename] headers in > > /etc/samba/local.config.d/*. > > This seems to be the case (or am I missing something?): Absolutely right, I mixed that up. I was refering to > WARNING: No path in service drucker1 - making it unavailable! So the path needs to be added.
I tagged the bug for Erratum, as this problem lies in the UCS Samba4 scope.
In my tests it works like expected. The only problem is that the Samba reload does not change the behavior of running Samba processes. A reload only infects new connections. This is default by design and we should not change it. From my point of view the only thing we can do is killing the running smbd processes of the user, but that is a task of the UCS@school computer room. (In reply to comment #7) > > > univention/lib/share_restrictions.py should write [sharename] headers in > > > /etc/samba/local.config.d/*. > > > > This seems to be the case (or am I missing something?): > > Absolutely right, I mixed that up. I was refering to > > > WARNING: No path in service drucker1 - making it unavailable! > > So the path needs to be added. I'm not able to reproduce it. The path of the printer is already defined in /etc/samba/printers.conf.d/*. Or is there any case in which it is different?
(In reply to comment #9) > In my tests it works like expected. The only problem is that the Samba reload > does not change the behavior of running Samba processes. A reload only infects > new connections. This is default by design and we should not change it. > > From my point of view the only thing we can do is killing the running smbd > processes of the user, but that is a task of the UCS@school computer room. OK, it worked but it took about 15 seconds before the process will be killed. Moved back to UCS@school.
(In reply to comment #9) > ... > I'm not able to reproduce it. The path of the printer is already defined in > /etc/samba/printers.conf.d/*. Or is there any case in which it is different? If I change in the computer room the printer access, the following file is generated... it contains no "path" value: > root@master40:~# cat /etc/samba/local.config.d/printer.PDFDrucker.local.config.conf > [PDFDrucker] > hosts deny = "" > hosts allow = 10.200.26.101 10.200.26.131
(In reply to comment #11) > If I change in the computer room the printer access, the following file is > generated... it contains no "path" value: > > > root@master40:~# cat /etc/samba/local.config.d/printer.PDFDrucker.local.config.conf > > [PDFDrucker] > > hosts deny = "" > > hosts allow = 10.200.26.101 10.200.26.131 The path is defined in a different file. As settings from both files are cumulated, everything seems to be fine then: > root@master40:~# cat /etc/samba/printers.conf.d/PDFDrucker > [PDFDrucker] > printer name = PDFDrucker > path = /tmp > guest ok = yes > printable = yes > use client driver = yes
I'm not completely convinced yet. The problem is that: > root@master40:~# cat /etc/samba/local.config.d/printer.PDFDrucker.local.config.conf > [PDFDrucker] > hosts deny = "" > hosts allow = 10.200.26.101 10.200.26.131 does not contain a dummy "path = /tmp" which leads to the error > =========================================================================== > Processing section "[drucker1]" > WARNING: No path in service drucker1 - making it unavailable! > NOTE: Service drucker1 is flagged unavailable. > =========================================================================== As stated above, specifying a dedicated Samba share name in UMC generates a valid share definition in: > /etc/samba/printers.conf.d/PDFDrucker But this is the workaround. The problem discussed on this bug is about: > 1. A printer share was created without specifying a dedicated Samba share name.
OK, currently we set "use client driver" by default. In this case the /etc/samba/printers.conf.d/ config will be written. I think we should remove this test in cups-printers.py and write the config in any case: if new.get('univentionPrinterSambaName') or \ new.get('univentionPrinterACLtype', EMPTY)[0] in ("allow", "deny") or \ new.get('univentionPrinterUseClientDriver', EMPTY)[0] == '1':
The test has been removed and the config file will be created in any case. fix: r40793 changelog: r40807
We will not ship a UCS 3.1-2 release; the next UCS release will be UCS 3.2. As such, this bug is moved to the new target milestone.
OK - the samba config in /etc/samba/printers.conf.d is now created for every printer (regardless if SambaName, ACL or UseClientDrive is set) OK - Changelog
UCS 3.2 has been released: http://docs.univention.de/release-notes-3.2-en.html http://docs.univention.de/release-notes-3.2-de.html If this error occurs again, please use "Clone This Bug".