|
Bugzilla – Full Text Bug Listing |
| Summary: | yast2-printer: Add support for samba-krb-printing | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE 11.4 | Reporter: | Johannes Meixner <jsmeix> |
| Component: | Printing | Assignee: | Johannes Meixner <jsmeix> |
| Status: | RESOLVED FIXED | QA Contact: | Johannes Meixner <jsmeix> |
| Severity: | Enhancement | ||
| Priority: | P5 - None | CC: | ciaran.farrell, ke, lmuelle, rolf.schmidt |
| Version: | Factory | ||
| Target Milestone: | Factory | ||
| Hardware: | All | ||
| OS: | SUSE Other | ||
| Whiteboard: | |||
| Found By: | Development | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
Because of the link both cases exclude each other. Either one uses the traditional case via /usr/lib/cups/backend/smb -> /usr/bin/smbspool or ose uses the "AD" case via /usr/lib/cups/backend/smb -> /usr/bin/get_printing_ticket Even if both cases could not happen at the same time I think about a user with a laptop who uses it in his company in an AD environment and at home in a traditional environment. He may use one same user account or differnt accounts when working in his company and at home. This results more questions: 6. Is the "AD" case a true superset of the traditional case? I.e. would all printing to traditional SMB shares still work when smbspool runs via get_printing_ticket? (This is a more general question than question 3. above.) 7. If the "AD" case a true superset of the traditional case why not simply have only the "AD" case? I.e. what are the drawbacks when samba-krb-printing is installed? As soon as you have a valid kerberos ticket granting ticket (TGT) you no longer need a password to authenticate. _If_ the targeted service is kerberized. Instead of adding any additional question like "Do you like to install the samba-krb-printing package?" to the YaST printing dialog we should consider to add a recommenrds samba-krb-printing to the samba-winbind package. The TGT you get with the initial authentication via the display manager. We've tested this with the one from Gnome and KDE. Therefore usually a further input of a password isn't required. get_printing_ticket uses the username as offered as second argument after the DEVICE_URI For testing you have to prompt for a username and password while in this particular case the username is a construct of <DOMAIN_NAME><WINBIND_SEPARATOR><USER_NAME> The most common case for the winbind separator is the \ char. I would keep this as simple as possible and therefore only offer a username and password inout field. In the documentation to the username field we might offer an example like EXAMPLEDOM\joe I count the get_printing_ticket hack a superset but haven't tested this. The drawbacks are: This is hack and it's not upstream (well, this might change). As soon as the printer destination isn't the next hop (think of chained print servers) a forward able ticket would be required. I won't ask a question to install a particular package. But I think about to ask some kind of question like "Do you print in a Windows Active Directory (AD) environment?" e.g. implied via a check box like [ ] Printing in Windows Active Directory (AD) environment which is already checked if samba-krb-printing is already installed. If it is already checked but the user un-checked it, yast2-printer will uninstall samba-krb-printing. If it was not yet checked and the user checked it, yast2-printer will install samba-krb-printing. In both cases yast2-printer will tell the user in advance what it istalls or uninstalls and let the user confirm (or abort) the package installation. It is important for me to know whether or not there are differences to the traditional case so that I can adjust the dialog in yast2-printer where printing via the "smb" backend is set up. Have in mind that yast2-printer works sufficiently backward compatible for various older products (in particular for SLE11-SP1) so that I like to provide an explicit switch for the user to install (or uninstall) samba-krb-printing. Regarding issues like when "the printer destination isn't the next hop" I would like to provide sufficient help text in yast2-printer. Is samba-krb-printing somewhere documented? (The package itself does not contain documentation.) How could the user get "a forward able ticket"? Does this depend on the particular AD environment (e.g. via whatever setting on a Windows AD sever) or is this something which does not work currently or cannot work at all when using samba-krb-printing? An explicit switch in yast2-printer for the user to install or uninstall samba-krb-printing has the advantage that it is fail-safe: If printing via the "smb" backend does no longer work after samba-krb-printing was installed, the user can switch back to the traditional method and vice versa. This way we may get only a few bug reports when it does not work by default "out of the box" but there are hopefully less bug reports that it "does not work at all" (e.g. only because samba-krb-printing was not installed). There is no further documentation. All we're able to offer are the comments from the source code: /* Usage: * * get_printing_ticket <smbspool cups args.> * * The cups args look like : * * [DEVICE_URI] job-id user title copies options [file] · * Sets its uid to the given username and then invokes smbspool. */ That's very likely or must even be identical to what you know from other back ends. Suggested recommends got added to network:samba:STABLE and TESTING with build-source-timestamp 2480. Implemented in yast2-printer 2.20.4 (already available via the "Printing" project) and submitted to openSUSE:Factory via submitrequest 57971 There is now a check box in the "connection wizard" dialog for SMB: [ ] Support for Windows Active Directory It is checked if the link /usr/lib[64]/cups/backend/smb points to /usr/bin/get_printing_ticket If the user checks it, yast2-printer tests if the package samba-krb-printing is installed and if not it tries to install it. If the user unchecks it, yast2-printer only lets the link /usr/lib[64]/cups/backend/smb point to its traditional target /usr/bin/smbspool but yast2-printer does not remove the samba-krb-printing packet. If the user likes to test the SMB connection when the check box is checked, yast2-printer shows a popup which reads: ---------------------------------------------------------------------------- This is only a generic test which may untruly report failures if authentication via Windows Active Directory is required. In this case a particular user who is allowed to print via Active Directory should log in and test by himself if he can print from Gnome or KDE. ---------------------------------------------------------------------------- The help text in yast2-printer is: ------------------------------------------------------------------------ By default CUPS runs backends (here smbspool) as user 'lp'. When printing in a Windows Active Directory (AD) environment the user 'lp' is not allowed to print in this environment so that the traditional way to print via smbspool as user 'lp' would not work. For printing in an AD environment additionally the RPM package samba-krb-printing must be installed. In this case the CUPS backend 'smb' link is changed to /usr/bin/get_printing_ticket which is a wrapper to run smbspool as the original user who submitted a particular print job. When the Kerberos protocol is used for authentication in an AD environment, a user gets a ticket granting ticket (TGT) via the display manager during login at the Gnome or KDE desktop. When smbspool is run as the original user who submitted a particular print job, it can access the TGT of this user and use it to pass the printing data to the SMB printer share even in an AD environment with Kerberos authentication. In this case neither a fixed user name nor a fixed password has to be specified for authentication. A precondition is that get_printing_ticket runs on the same host where the user who submitted a particular print job is logged in. This means that it must be set up on the workstation for the particular user who will submit such print jobs and the user's workstation must send its printing data directly to the SMB printer share in the AD environment. In particular it does not work on a separated CUPS server machine where users who submit print jobs are not logged in. ------------------------------------------------------------------------ Lars, does this look o.k. for you? reopen to get legal review @Ciaran: Please see comments 8 ff. Submitrequest 57971 to openSUSE:Factory was rejected because of an issue with YaST tools which generate something wrong in the spec file. yast2-printer 2.20.4 with samba-krb-printing support is available via the "Printing" project so that our users can install it if they like. I will re-submit to openSUSE:Factory when the proper name issue in comment #8 is solved... Basically there are the following proper name questions: 1. Whether or not it is o.k. to use the plain word "Windows" in YaST help texts and YaST dialogs or must it be called "Microsoft Windows" in any case? 2. What is the right proper name of a thingy which is commonly called like "Windows Active Directory" or simply "AD"? 3. Must an official proper name used in any case? In particular also in YaST dialogs where the space is often very limited? E.g. a check box labeled like ------------------------------------------------------------------------------ [X] support for Microsoft Windows Server Active Directory Domain Services (tm) ------------------------------------------------------------------------------ would not fit inside the available space on a 80 characters wide ncurses YaST dialog because there are some frames around the check box widget so that the content of the check box label would be clipped. At least the above proper name question 1. is more general: 1a. Is it o.k. to use the plain word "Windows" in any help text e.g. in SDB articles like http://en.opensuse.org/SDB:Printing_from_Windows_to_Linux http://en.opensuse.org/SDB:Printing_via_SMB_%28Samba%29_Share_or_Windows_Share http://en.opensuse.org/Wine and many many more... 1b. Is soemthing like "MS-Windows" also o.k., see for example http://en.opensuse.org/Concepts_interface http://en.opensuse.org/Concepts_networking E.g. http://de.wikipedia.org/wiki/Windows reads (German only) ------------------------------------------------------------- Ursprünglich war "Microsoft Windows" eine grafische Erweiterung des Betriebssystems MS-DOS ... Inzwischen wurde dieser Entwicklungszweig zugunsten der Windows-NT-Produktlinie aufgegeben und "Windows" bezeichnet das Betriebssystem als Ganzes. ------------------------------------------------------------- This indicates that nowadays "Windows" is the right proper name when the "Windows" operating system is meant. [x] support for Microsoft (R) Active Directory (R) theoretically, you could drop Microsoft (R) as Active Directory is itself a registered trademark. You could also add descriptive language after the (R): [x] support for Active Directory (R) domain services In any event, the official Microsoft trademark guidelines are here: http://www.microsoft.com/about/legal/en/us/IntellectualProperty/Trademarks/Usage/General.aspx It is also good practice to include a reference to the trademark ownership in the documentation - our doc team already do this as far as I know. Karl may be able to provide more insight... Many Thanks for the info! I use now "Windows (R)" and "Active Directory (R)" according to http://www.microsoft.com/about/legal/en/us/IntellectualProperty/Trademarks/EN-US.aspx and added references to the trademark ownership as specified on http://www.microsoft.com/about/legal/en/us/IntellectualProperty/Trademarks/Usage/General.aspx Submitted yast2-printer 2.20.4 to YaST:Head via submitrequest 58705 and forwarded this to openSUSE:Factory via submitrequest 58707 |
I would like to add support for samba-krb-printing to yast2-printer so that it is easier for the users to set up printing in a Windows Active Directory (AD) environment. Printing to a SMB printer share in an AD environment requires the RPM package samba-krb-printing. As far as I know it should be sufficient to only install the samba-krb-printing RPM and then printing via a Device URI smb://username:password@workgroup/server[:port]/printer would also work in an AD environment. Background information: Without samba-krb-printing there is the symbolic link /usr/lib/cups/backend/smb -> /usr/bin/smbspool which is created by the RPM post install script in the samba-client package which provides smbspool. smbspool is used to pass the printing data to the final recipient i.e. to a SMB printer share. By default CUPS runs backends (here smbspool) as user "lp". But "lp" is not allowed to use the ticket granting ticket (TGT) of the user who had submitted the print job and who would be allowed to print via his tickets in the AD environment. The RPM post install script in samba-krb-printing changes the above mentioned link to /usr/lib/cups/backend/smb -> /usr/bin/get_printing_ticket get_printing_ticket is a set uid root wrapper binary to run smbspool with the original calling UID of the user who submitted the particular print job. This way smbspool can access the TGT of the user who had submitted the print job and use this ticket to pass the printing data to the SMB printer share even in an AD environment. Lars, I have several questions: 1. Is my understanding how it works correct? 2. Is a plain installation of samba-krb-printing sufficient? 3. Are all kind of DeviceURIs which are listed in "man smbspool" ----------------------------------------------------------------- smb://server[:port]/printer smb://workgroup/server[:port]/printer smb://username:password@server[:port]/printer smb://username:password@workgroup/server[:port]/printer ----------------------------------------------------------------- also valid in an AD environment or are ther restrictions? In particular: Is "username:password" required in an AD environment (is it perhaps needed to get a TGT?) or is it useless or even forbidden (e.g. because of security reasons) in an AD environment? 4. Does get_printing_ticket run smbspool with the UID of the user who submitted each individual print job (i.e. different UIDs when different users submit print jobs to the same print queue) or does get_printing_ticket perhaps use the fixed "username" if it is specified in the DeviceURI? 5. How could one test if printing in an AD environment works? Currently yast2-printer runs /usr/lib/YaST2/bin/test_remote_smb as "root" which basically runs this test command (where $HOST $SHARE $PASSWORD $USER $WORKGROUP are the values from the DeviceURI): ----------------------------------------------------------------------- echo -en "\r" \ | /usr/bin/smbclient "//$HOST/$SHARE" "$PASSWORD" \ -c "print -" -U "$USER" -W "$WORKGROUP" ----------------------------------------------------------------------- I assume this does no longer work in an AD environment when the user "root" is not allowed to print there.