Univention Bugzilla – Bug 34068
Clarify the need of 32bit drivers
Last modified: 2015-03-09 23:24:24 CET
We should check whether the is AD default. If not we should fix samba. +++ This bug was initially created as a clone of Bug #34018 +++ The driver assignment was improved at bug #30597 quite nicely. One last point should be clarified: "If you are using an environment in which 64-bit installations are used in addition to 32-bit versions of Windows, you will need both versions of the drivers." Could be confusing if you ONLY have 64bit machines - you ALWAYS need 32bit versions - otherwise the driver will not be shown in the drivers list.
requested by 2014110521000226 (one partner who had trouble with printer drivers at two customers) The documentation is often overlooked, and most windows clients are 64bit. So the current unexpected behaviour hits many admins.
Samba 4.2 has a new parameter for this, feedback welcome: ============================================================================ spoolss: architecture (G) Windows spoolss print clients only allow association of server-side drivers with printers when the driver architecture matches the advertised print server architecture. Samba's spoolss print server architecture can be changed using this parameter. Default: spoolss: architecture = Windows NT x86 Example: spoolss: architecture = Windows x64 ============================================================================ If trying this in local.conf please note that not al parts of samba smb.conf parsing consider a second [global] section. In most cases it currently still works though.
(In reply to Arvid Requate from comment #2) > Samba 4.2 has a new parameter for this, feedback welcome: [..] > Default: spoolss: architecture = Windows NT x86 > > Example: spoolss: architecture = Windows x64 [..] Maybe we should make it configurable and use the local UCR architecture as default? We should compare this with the behaviour of a Windows Server also.
A short followup just to clarify the purpose of the new samba option: With the classic old point-and-print serverside driver upload+distribution model the uploading Windows client seems to ask the server about his architecture and require upload of a driver matching that -- even if the client has a different architecture. Ths Administrator has to take care to *additionally* upload the driver in for the client architecture. The new option allows to adjust the spoolss/print server architecure, which simplifies matters in domains with predominant x64 client architecure. > Maybe we should make it configurable and use the local UCR architecture > as default? Maybe, but this alone could also lead to strange behaviour in a situation where UCS slave1 is x386 and UCS slave2 is x64. In that case one probably would like to deploy a domain wide default, e.g. via UDM/UCR policy. But generally, yes, we should do something in this direction. > We should compare this with the behaviour of a Windows Server also. It may be a client matter: The Printer Administration MMC snapin explicitly shows information messages telling that 32-bit drivers are strictly required. We should check if the messages change once the server architecture has been adjusted.
Tickets about this: 2014110521000226 + 2014112721000202 I think first of all we should re-check the AD behavior. Maybe there is something missing in Samba. If not, we should change the default to amd64 because new UCS 4 installations are always 64bit.
On native windows hosts serving a printer share this is not an issue, as the system always requires a printer driver for the local system architecture to be installed during printer share creation. So an x64 print server always has the x64 drivers downloadable for clients. I now adjusted the smb.conf UCR template to check the architecture of the local UCS server and set the parameter "spoolss: archicture" to "Windows x64" if it's found to be a 64 bit system. This value may be overridden manually via UCR samba/spoolss/architecture. Advisory: 2014-12-15-univention-samba4.yaml
(In reply to Arvid Requate from comment #6) > On native windows hosts serving a printer share this is not an issue, as the > system always requires a printer driver for the local system architecture to > be installed during printer share creation. So an x64 print server always > has the x64 drivers downloadable for clients. > > I now adjusted the smb.conf UCR template to check the architecture of the > local UCS server and set the parameter "spoolss: archicture" to "Windows > x64" if it's found to be a 64 bit system. This value may be overridden > manually via UCR samba/spoolss/architecture. > > Advisory: 2014-12-15-univention-samba4.yaml Does that mean that "spoolss: archicture" would change during the update? That would lead to disappearing printer drivers (from the users point of view) when only 32bit driver is installed on the server. IMHO systems should stay 32bit on updates, new installations should be 64bit if UCS is 64bit.
> IMHO systems should stay 32bit on updates Ok, adjusted: on updates the UCR variable gets set to the old value. Test: 53_samba-common/37_spoolss_architecture
r57215 | Bug #34068: 53_samba-common/37_spoolss_architecture FIXED SyntaxError: invalid syntax File "37_spoolss_architecture", line 23 if not os.path.exists(path_testparm)
> r57215 | Bug #34068: 53_samba-common/37_spoolss_architecture Thanks, must have been one of those days..
YAML: OK Tests: OK Code review: OK
<http://errata.univention.de/ucs/4.0/59.html>
*** Bug 34387 has been marked as a duplicate of this bug. ***