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
[global]
workgroup = MYDOMAIN
passdb backend = tdbsam
printing = cups
printcap name = cups
printcap cache time = 750
cups options = raw
map to guest = Never
domain logons = No
domain master = No
security = domain
admin users = @wheel
log file = /var/log/samba/%m.log
log level = 2
wins server = 1.2.3.4 5.6.7.8
[printers]
comment = All Printers
path = /var/tmp
printable = Yes
create mask = 0600
browseable = No
[print$]
comment = Printer Drivers
path = /var/lib/samba/drivers
write list = @ntadmin @wheel root
force group = wheel
create mask = 0664
directory mask = 0775
--------
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.
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 - NickHave 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...
> > 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.
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 at seakr.com> Sent: 20 May 2010 19:10 To: samba at lists.samba.org; Mike Rambo <mrambo at 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
> for printer queue holding managed by cups so can be deployed on any printer.> have a look at the following cups options> Holding Jobs for Later Printing> The -o job-hold-until=when option tells CUPS to delay printing until the > "when" time, which can be one of the following:> * -o job-hold-until=indefinite; print only after released by the user or> an administrator> * -o job-hold-until=day-time; print from 6am to 6pm local time > * -o job-hold-until=night; print from 6pm to 6am local time > * -o job-hold-until=second-shift; print from 4pm to 12am local time > * -o job-hold-until=third-shift; print from 12am to 8am local time > * -o job-hold-until=weekend; print on Saturday or Sunday > * -o job-hold-until=HH:MM; print at the specified UTC time Okay - I'm definitely open to this possibility. Do the CUPS Windows drivers support the use of these options? The main place where I need the job hold support is for Windows-based clients, so I need to make sure it works okay there. 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.
> The -o job-hold-until=when option tells CUPS to delay printing until the > "when" time, which can be one of the following:Well, I found the option in the Printing Preferences under the Windows driver, but setting it has no effect - the job prints immediately. Something else I need to do? -------- 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.
Nick if it going on for all printers add to smb.conf cups options = "job-hold-until=indefinite" -- Damien Dye BSC(hon) On 25 May 2010 00:47, Nick Couchman <Nick.Couchman at seakr.com> wrote:>> The -o job-hold-until=when option tells CUPS to delay printing until the >> "when" time, which can be one of the following: > > ? ?Well, I found the option in the Printing Preferences under the Windows driver, but setting it has no effect - the job prints immediately. ?Something else I need to do? > > > > -------- > 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. >
> if it going on for all printers add to smb.conf> cups options = "job-hold-until=indefinite"I don't mean to be difficult, but, if I read the smb.conf man page correctly, this means that all jobs printed through Samba to CUPS will be held indefinitely. This is not the behavior I'm looking for - I need users to be able to choose for jobs to be held, otherwise they need to be printed immediately. If I indicated elsewhere that I was looking for this all of the time, I apologize for the confusion. Right now, we use the "hold" feature of our Canon-based copiers for folks who need to print out sensitive documents - e.g. personnel reviews - so that they have a place to print it to that is password protected and so that it's not sitting on the printer. Most of the printing we do does not fall under that heading, so having it print immediately is desirable. -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.