_lpadmin problem

[thegooch49]

Hello, I saw a problem come up with an image I created with instaDMG (10.5.7). When I go to add a printer, it’s asking me for credentials for a user in _lpadmin. When I enter my creds for an admin user (myself) it’s not accepted. I have to enter the PW for my local admin account to accept. When I hit id for my local admin account, I see that it’s in _lpadmin (98). I am not however. Wouldn’t anyone in admin (80) automatically be in _lpadmin?

Anyone seen this? This hasn’t come up in older versions of my instaDMG created images. Thanks for the help.

[knowmad]

I saw something similar a very long time ago… any chance you randomly assigning UID to your admin account? This happened (something similar actually) to me when I had my UID randomly assigned for supposed security reasons (not my decision) and it landed on one of the prebuilt admin accounts…. created havoc.

[Patrick Gallagher]

I’ve been seeing this problem ever since 10.5.7 came out, I don’t think it is because of InstaDMG but I’m not 100% sure. The problem I think is because I have/had a modifed /etc/authorization which conflicted with cups changes in 10.5.7. The fix has been to add the user to the _lpadmin group:

dscl . -append /Groups/_lpadmin users

[thegooch49]

Yeah, thanks for the replies. My previous images were built with a 10.5.0 disk, upgraded to 10.5.7. This last one, I used an OEM 10.6, upgraded to 10.5.7. That seems to be the difference in what I did in creating these images. Odd.

[knowmad]

[QUOTE][u]Quote by: thegooch49[/u][p]Yeah, thanks for the replies. My previous images were built with a 10.5.0 disk, upgraded to 10.5.7. This last one, I used an OEM 10.6, upgraded to 10.5.7. That seems to be the difference in what I did in creating these images. Odd.

[/p][/QUOTE]

I am assuming you mistyped something… “upgraded 10.6 to 10.5.7” either that, or you have clearly stated why your build has issues….
my assumption is the first.
Oddly, I have been using an oem disk for a while now and gotten no issues with printers, whatsoever.

[dead2sin]

I had this issue as well and I have resolved it on my build train.

I am now adding the printers on first boot (first boot script) instead of copying the whole /etc/cups/blah stuff over to the image via a package. This has resolved the issue where it would say I wasn’t in the _lpadmin group and it also resolved an issue I had been having printing in photoshop.

Here is the example I put into my wiki so I wouldn’t forget 😀

[code] lpadmin -p “HiddenSystemName” -L “Location” -D “Display Name”-E -v lpd://olorin/queuename -P “/Library/Printers/PPDs/Contents/Resources/en.lproj/correctppd.ppd.gz”[/code]

Rules for using this command:

-p “HiddenSystemName” cannot have any spaces or symbols in the name. (Underscore _ is acceptable).

-L “Location” Should be a human readable description of the location such as “Computer Lab” or “Pharos Station”

-D “Display Name” Should also be human readable and it can contain spaces. This is what OS X Displays in Printers and Faxes within System Preferences.

-E Enables the printer

-v Specifies the queue name. For our printers, they are all on lpd://olorin/printername.

-P Specifies the print driver. This can be a*.ppd, *.gz or any unix compatible format. Most commonly found in /usr/share/cups/model and /Library/Printers/PPDs/Contents/Resources/en.lproj/

Hope this helps someone else out as well!

Nate

[dead2sin]

Alright, that command didn’t totally fix the issue. Looking into this some more…

[zanzan42]

I looked in this thread because of a weirdness I experienced recently, which might be related to what you’re seeing.

I had to rebuild my own machine a week ago because of a drive failure, so I took the opportunity to drop a clean image on it rather than restore from Time Machine backup. I use a post imaging script to do a number of things, among them a bind to Active Directory (mobile account with forced local home directory). Under normal circumstances, a tech would set up an end user machine, log the user in to cache their AD credentials, then login with the local admin account and make the user an administrator by clicking the admin button in the Accounts pref pane before delivering the machine to the user.

I wanted to test adding a dseditgroup statement to the scripted process and remove the manual process of making the intended end user an admin. So I tested this process on my own machine. Running the dseditgroup command and adding my AD account to the admin group was successful (even before I had cached AD credentials). Once I logged in with my AD account, I showed up in the Accounts pref pane as an admin (and the box was checked already). So far, so good.

Until I tried to add a printer. Same problem you saw. My cached AD account, even though it was a member of the admin group and showed up as an administrator in Accounts, was not a member of lpadmin. I had to auth using the local admin account. I haven’t had a chance yet to take a look at this further, but hope to this week.

It leaves me with questions: why isn’t membership in admin granting full rights? Does clicking the box in the gui add you to more groups than just admin, and was my use of dseditgroup the problem? or is there something going on with (in this case) 10.5.8 that is different from previous versions?

Allan

[zanzan42]

Ok, I just tested this.

I logged into the machine with the local admin account and removed the admin rights from my AD account using the Accounts pref pane. Here’s what I end up with:

101(com.apple.sharepoint.group.1),20(staff)

I then granted admin rights again using Accounts, and ended up with this:

98(_lpadmin),81(_appserveradm),101(com.apple.sharepoint.group.1),79(_appserverusr),80(admin),20(staff)

So it looks like clicking the button in Accounts does a couple of things which I wasn’t accounting for with dseditgroup. In order to get the same result I’m also going to have to script the command for _lpadmin, _appserveradm, and _appserverusr if I want it to do the same thing.

The weird thing is that my local admin account only has this:

20(staff),98(_lpadmin),80(admin)

Of course, that account got created prior to the machine being bound to AD, so maybe that makes a difference. The Accounts pref pane might be doing different things depending upon whether it’s acting upon a local account vs. an AD account.

Allan

[Rusty Myers]

Allan, Great work. I’m really glad to hear what you found. Will you be able to share your scripts either now or when your completely finished? Thanks!
Rusty

[Author]

Posts