Samba + CUPS
in [Samba]
|
From: Mike Rambo on 19 May 2010 16:10 Nick Couchman wrote: > I'm attempting to configure Samba with CUPS as a centralized print server. I've done this in the past - my current production server is running Samba 3.2.14. On my current production server, I have several users set up as either "admin users" or "print admin" users so that they can manage the drivers, etc., on the Samba server. In setting up my new server, I'm running into some issues with this. The main problem is that, no matter what options I change for the printers and print$ shares, and no matter what users I add in as either admin users or printer admin users, when I go to the properties of either a printer or the entire server, everything is read-only. I cannot add/upload drivers to the server, etc. I've even manually gone to the \\<servername>\print$ share and verified that I have write access to that folder. But, for some reason, I cannot add drivers, change settings, etc., on the new server. Differences are: > - Old Server: Gentoo; New Server: openSuSE 11.2 > - Old Server: Samba 3.2.14; New Server: Samba 3.5.3 > - Old Server: NT4 Domain Member; New Server: ADS Member > > As far as the differences go, I've already verified that the same behavior occurs when the new server is part of the NT4 domain instead of the AD domain. So, I'm really down to either something having changed in Samba versions sometime after 3.2, or something about how the packages are compiled. Perhaps someone can help me figure out what I'm missing that's causing this behavior? Find my smb.conf file below... > > Thanks - Nick Have you looked at granting rights like: net -U"ADuser" rpc rights grant "ADdomaingroup" SePrintOperatorPrivilege There are several different privileges that can be granted in this manner. -- Mike Rambo NOTE: In order to control energy costs the light at the end of the tunnel has been shut off until further notice... -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
From: Nick Couchman on 20 May 2010 14:20 > > Have you looked at granting rights like: > > net -U"ADuser" rpc rights grant "ADdomaingroup" SePrintOperatorPrivilege > > There are several different privileges that can be granted in this manner. Thanks, Mike, I actually figured out the issue, thought I'm not sure why this is the case. According to the current Samba startup and documentation, the "printer admin" option is deprecated; however, setting this option (in addition to admin users) seemed to make things work. So, I'm not sure what is supposed to replace the "printer admin" option (perhaps the RPC rights you mention above??), but it seems it's still necessary to make things work correctly. By the way, the user account in AD (and NT4) is in the Domain Admins group and the Enterprise Admins group, so these rights should already be granted. I'll double-check when I get a second, though. On to my next question. I'm in an enterprise environment where I'm using CUPS + Samba to serve out printers to my entire organization. Most of these printers are network-attached, and some of the more recent drivers expect to be able to communicate directly with the printer, instead of talking through the CIFS service. Some of the drivers allow you to point it at a specific IP/hostname, however, others try to communicate automatically by grabbing the Port information from the printer. Since Samba doesn't truly give the port that the printer is connected to, this is proving to be problematic for a couple of my printers. When you use Windows Server as a print server, it seems like, instead of directing printing through it, all it does is give the printer definitions to the client, and allows the client to communicate directly with the printer. I can see where this behavior would be undesirable in many situations - if you're truly trying to control printing, manage access, and centralize things, this doesn't really accomplish that task. However, with the issue I mention above with printer drivers requiring bi-directional communication to function properly, it seems this is the behavior that I actually need. Does anyone know if it's possible to have Samba pass through the "real" port information? I've tried to use the "enumports command=" option in smb.conf and list out ports, but this just seems to give a short list of Local Ports to the computer, and doesn't really allow you to enumerate things like Standard TCP/IP Ports. Ideas? Suggestions? Work-arounds? Advice? Thanks! -Nick -------- This e-mail may contain confidential and privileged material for the sole use of the intended recipient. If this email is not intended for you, or you are not responsible for the delivery of this message to the intended recipient, please note that this message may contain SEAKR Engineering (SEAKR) Privileged/Proprietary Information. In such a case, you are strictly prohibited from downloading, photocopying, distributing or otherwise using this message, its contents or attachments in any way. If you have received this message in error, please notify us immediately by replying to this e-mail and delete the message from your mailbox. Information contained in this message that does not relate to the business of SEAKR is neither endorsed by nor attributable to SEAKR. -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
From: Nick Couchman on 20 May 2010 15:40 >>> On 2010/05/20 at 13:43, Damien J Dye <damien.j.dye(a)googlemail.com> wrote: > Why are you not using the cups printer drivers in the cups enviroment there > are both x64 and i386 versions and gets round the issues with broken drivers > and allows cups features to be passed to windows. > There are several "special" function of my printers (networked copiers, actually) that need to be supported, and I don't believe the CUPS driver contains this support. Things like sending the printout to a storage box on the copier that waits for someone to walk up and print it (Mailbox/Document Server), duplexing, hole punching, stapling, N-up, etc. I have not tried the CUPS printer drivers, yet, so perhaps these features get passed through, but some of those features aren't even present in the PPD file that I use for CUPS. -Nick -------- This e-mail may contain confidential and privileged material for the sole use of the intended recipient. If this email is not intended for you, or you are not responsible for the delivery of this message to the intended recipient, please note that this message may contain SEAKR Engineering (SEAKR) Privileged/Proprietary Information. In such a case, you are strictly prohibited from downloading, photocopying, distributing or otherwise using this message, its contents or attachments in any way. If you have received this message in error, please notify us immediately by replying to this e-mail and delete the message from your mailbox. Information contained in this message that does not relate to the business of SEAKR is neither endorsed by nor attributable to SEAKR. -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
From: Damien J Dye on 20 May 2010 15:40 Why are you not using the cups printer drivers in the cups enviroment there are both x64 and i386 versions and gets round the issues with broken drivers and allows cups features to be passed to windows. -----Original Message----- From: Nick Couchman <Nick.Couchman(a)seakr.com> Sent: 20 May 2010 19:10 To: samba(a)lists.samba.org; Mike Rambo <mrambo(a)lsd.k12.mi.us> Subject: Re: [Samba] Samba + CUPS > > Have you looked at granting rights like: > > net -U"ADuser" rpc rights grant "ADdomaingroup" SePrintOperatorPrivilege > > There are several different privileges that can be granted in this manner. Thanks, Mike, I actually figured out the issue, thought I'm not sure why this is the case. According to the current Samba startup and documentation, the "printer admin" option is deprecated; however, setting this option (in addition to admin users) seemed to make things work. So, I'm not sure what is supposed to replace the "printer admin" option (perhaps the RPC rights you mention above??), but it seems it's still necessary to make things work correctly. By the way, the user account in AD (and NT4) is in the Domain Admins group and the Enterprise Admins group, so these rights should already be granted. I'll double-check when I get a second, though. On to my next question. I'm in an enterprise environment where I'm using CUPS + Samba to serve out printers to my entire organization. Most of these printers are network-attached, and some of the more recent drivers expect to be able to communicate directly with the printer, instead of talking through the CIFS service. Some of the drivers allow you to point it at a specific IP/hostname, however, others try to communicate automatically by grabbing the Port information from the printer. Since Samba doesn't truly give the port that the printer is connected to, this is proving to be problematic for a couple of my printers. When you use Windows Server as a print server, it seems like, instead of directing printing through it, all it does is give the printer definitions to the client, and allows the client to communicate directly with the printer. I can see where this behavior would be undesirable in many situations - if you're truly trying to control printing, manage access, and centralize things, this doesn't really accomplish that task. However, with the issue I mention above with printer drivers requiring bi-directional communication to function properly, it seems this is the behavior that I actually need. Does anyone know if it's possible to have Samba pass through the "real" port information? I've tried to use the "enumports command=" option in smb.conf and list out ports, but this just seems to give a short list of Local Ports to the computer, and doesn't really allow you to enumerate things like Standard TCP/IP Ports. Ideas? Suggestions? Work-arounds? Advice? Thanks! -Nick -------- This e-mail may contain confidential and privileged material for the sole use of the intended recipient. If this email is not intended for you, or you are not responsible for the delivery of this message to the intended recipient, please note that this message may contain SEAKR Engineering (SEAKR) Privileged/Proprietary Information. In such a case, you are strictly prohibited from downloading, photocopying, distributing or otherwise using this message, its contents or attachments in any way. If you have received this message in error, please notify us immediately by replying to this e-mail and delete the message from your mailbox. Information contained in this message that does not relate to the business of SEAKR is neither endorsed by nor attributable to SEAKR. -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
From: Ryan Suarez on 21 May 2010 11:00
Nick Couchman wrote > On to my next question. I'm in an enterprise environment where I'm using CUPS + Samba to serve out printers to my entire organization. Most of these printers are network-attached, and some of the more recent drivers expect to be able to communicate directly with the printer, instead of talking through the CIFS service. Some of the drivers allow you to point it at a specific IP/hostname, however, others try to communicate automatically by grabbing the Port information from the printer. Since Samba doesn't truly give the port that the printer is connected to, this is proving to be problematic for a couple of my printers. > Which driver are you referring to? Does the driver not have options to disable printer communication? -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba |