Thank you for the response. After some further investigation, I discovered that Samba 3.0.3 behaves correctly (i.e. the %U substitution works). Samba 3.0.7 is ignoring the %U substitution. This would fit in with your comment about jumping to 3.0.6. Will someone likely be addressing this issue, or would it be proper for me to make a propsed fix and submit the diff?
Oh - and my apologies for submitting quoted-printable (i.e. the wide-screen version) on my original post. -Jerry
----- Original Message ----- From: "Mac" <[EMAIL PROTECTED]>
To: "Jerry Askew" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Tuesday, October 05, 2004 3:06 AM
Subject: Re: [Samba] Using parameters in lpq command conflicts with
background
Hi Jerry, (and rest of list)
I have an application than makes use of the "lpq command" and uses the %U parameter in the command string. The application returns a personalized queue list based on the value of %U. This technique worked well in older versions of Samba (circa RedHat 8), but I have run into some trouble with Samba 3. The issue appears to be twofold.
1) The lpq command is now run from the background lpq monitoring process, which does not have a "user" (%U) per-se associated with it.
2) The background lpq process maintains its cache(s) based on the service name. IIRC, the older caching system maintained a cache for each unique "lpq command" line.
Indeed it did. In fact the whole (tdb-based) lpq monitoring system has a whole heap of changes from previous Samba versions (we jumped from 1.9.18p8 to 3.0.6) and all sorts of strange things happen now.
I've temporarily solved the problem by running smbd from inetd - this prevents the background lpq process from running and causes each user's process to invoke their own lpq command (complete with %U substitution).
Fab! Thanks for finding this workaround. I'll give it a shot.
Would it be possible to update the background lpq code to use the (fully substituted) lpq command as the cache identifier instead of (or in addition to) the service name? My application aside, I think it would be best if Samba's behavior was consistent in both daemon and non-daemon modes. I'd be willing to lend my mediocre programming skills to the task if it would help.
I agree about the damon vs. non-daemon mode, very odd that the behaviour is inconsistent.
Mac Assistant Systems Adminstrator @nibsc.ac.uk [EMAIL PROTECTED] Work: +44 1707 641565 Everything else: +44 7956 237670 (anytime)
-- To unsubscribe from this list go to the following URL and read the instructions: http://lists.samba.org/mailman/listinfo/samba
