Hi,
It sounds like a permissions issue if the user can't run the software when its deployed.
I would focus on the running of the app as a student. A couple of questions around that:
- When the app is installed, where is it put (/applications, or somewhere else)
- Are there any restrictions that would prevent the student from running the app?
- Is the app set to launch at login? (I would imagine it would need to be running for the popup to work)
There a couple of interesting things here. 1) The "root" user doesn't have a standard "Home Directory" as we might normally think about it. and 2) Self-Service packages and other JSS policies are installed with root priv's unless you script a solution to counteract that.
With that said, can you post a screenshot of your Composer window? What's the software form Xerox?
Point 1
The app goes into a folder in the /applications called 'MyPrintsPopUpClient' which then has a subfolder called 'popup-browser' which then has some jar files in it.
When I install the applications under root and it works, all users including 'everyone' have 'Read & Write' permissions on the directory, sub-folders, contents etc. The same is true if I install the package I created as part of the imaging workflow when it doesn't work.
I looked on the Mac for any other software in user template for example, that might relate to the software but I can't see any.
Point 2
I can't see any difference in the 2 ways that the software is installed so no there are no other restrictions specifically that should cause issues for students. At this stage of testing I have not applied any Casper configuration policies that might restrict them.
Point 3
No it is not in login items but does fire (when it is working).
When you are packaging with Composer, are you doing a snapshot package?
I'm not sure if the package installs any other files elsewhere? If not, it should work if you just dragged the "MyPrintsPopUpClient" folder directly into the Composer sidebar and packaged it that way.
@davidacland I'm doing an installation snapshot.
If I try dragging the .app installer into composer, the package or DMG it creates does nothing once added to a workflow.
@Chris_Hafner The software is a simple java app i believe. It works in conjunction with Xerox's IGA software. It pops up in the bottom right corner after a print job is sent and simply allows a student to cancel or ok a print job. Effectively they are saying 'yes print this and my account will be charged'. I'm told by the Xerox tech that the window is a small web page.
This is the file name 'MyPrintsPopupClient_MAC_64.zip'
That's interesting. I've just been looking at whatever info I could find in a few moments online. Looks like a utility that's been packaged up to look a lot like PaperCut. Unfortunately, I've got nothing to test it with directly. That said, when you're performing your snapshot are you opening the client to see if any other files are being installed at that point? Beyond that, can you verify that you've been able to get this working on a student account when you've installed it as root (You've implied that but I want to make sure).
Hi @Chris_Hafner,
I can absolutely confirm that if I install the software under a regular admin account, the pop up software won't work for students, installed while logged in as ROOT user it works as expected.
I do not understand this question ...'when you're performing your snapshot are you opening the client to see if any other files are being installed at that point'.
Thanks.
NOTE: I've just had it confirmed by the Xerox techs that the documentation actually says the software has to be installed as ROOT user.
Is there a way to script this so the installation occurs under root user? I am a complete newbie when it comes to scripting on MAC :(
NOTE: I've just had it confirmed by the Xerox techs that the documentation actually says the software has to be installed as ROOT user.
No offense, but I would seriously find a way to kick this software to the curb and go with another product, if this is what they are telling you. There is no excuse for any software to need to be installed as the root user to work, other than complete laziness and/or incompetence. Package installers have the ability to escalate their privileges to root temporarily to do what they need to upon installation. Apparently the developers at Xerox haven't figured that out!
The act of enabling the root user just to install something is a risk in and of itself. Best practice from a security standpoint is to never enable the root account on OS X. A Mac ships with root disabled by default and for good reason.
FWIW, this isn't the first time I've heard of a product that asks for the root account to be enabled and for the software to be installed under that account. When I've run into this, I've basically told them to pound sand and come back when they've figured out how to make their software actually work correctly.
@mm2270 Yes I hear you, it seemed a bit ordinary when the Tech told me and my response was much the same as yours. Unfortunately we are not in a position to change the software :(
@HelpDeskWarrior I have to agree with @mm2270, but that doesn't necessarily help you if you're being told to ship this. My question regarding "opening" the application (your popup client) while in the middle of a snapshot, is to see if any additional files are created when the "app" is first launched. You may have done this already.
With all of this said, did Xerox recommend a deployment method? In my brief look I couldn't find much about this utility online.
Yes, my comment may not have been very helpful. Sorry for that. I just get a bit burned up when I hear about software that is deemed to be critical to an environment, as may be the case here, and the developer is clueless about how software works on OS X, and general common sense best practices, which makes things extremely difficult for you. I'm sorry you've been kind of saddled with this product and you need to find some way to make it work. FWIW, I also looked it over quickly and honestly it looks an awful lot like PaperCut.
I would second what @Chris_Hafner is asking about - both questions. Can you detect if anything is being added or installed when its launched the first time after being installed under root? And I would also kick this back to Xerox and explain to them its unreasonable for you to run around and install this software on everyone's Mac under the root account, so, what is their recommendation? Do they have any notion of how other customers have installed this in a large Mac environment? (if there even are any)
Last two things:
1- I would say the reason Composer might be hanging up during the capture under root is because it might be trying to locate the home folder in the /Users/ path. But the root account's home directory is located in the /private/var/ directory.
2 - A lot of newcomers don't realize this, but Composer does not have to do an actual snapshot to build a package. If you can figure out what files are being created during the install, you can build a package by manually dragging them into the Composer window to create a new Source. Keep dragging the files in you want to have in the package and when done, just build it and test. If you need help figuring out what gets created, you can try using Composer's "Monitor File System Changes" function instead of one of the regular Snapshot ones.
@mm2270 @Chris_Hafner This is the contents of the composed package when I create it with an admin account. The only files I am aware of being installed via manual method are those contained in the top section - Applications.
I couldn't identify any differences between admin installed version and root installed version regards, files or access permissions
At first glance it looks like its only the folders in /Applications that would be needed. The only other bit that would need checking is the .InstallAnywhere and .com.zerog.registry.xml folder and file in /Users/admin
I'm not sure if the Xerox popup software is using that in any way? If it is, that might explain whats going on.
According to their documentation, the user that installs the software, determines where it gets installed, which would in turn affect which user could run the software.
Could be a red herring, but worth checking though.
@HelpDeskWarrior I think @davidacland has it. You should be able to remove the following directories:
/ByHost/
/Users/Library/Application Support/
/Library/
leaving just:
/Applications/MyPrintsPopUpClient
/Applications/Uninstall_MyPrintsPopupClient
/Users/admin/.InstallAnywhere
/Users/admin/Library/Preferences/.com.zerog.registry.xml
I would ensure that everything in the /Applications directory be set so that the "MyPrintsPopUpClient" and "Uninstall_MyPrintsPopupClient" have the SAME permissions as the Applications folder which should be something like Owner=System (root) (Read, Write and Execute), Group=admin (Read, Write and execute), Everyone=Read and Execute only. You can leave the permissions for everything in /Users/admin alone. You just have to make sure that you select "FEU" and "FUT" for "Fill Existing User" and "Fill User Template" in both Casper Admin and the policy used to distribute it.
I tend to prefer packaging as .dmg so that I may index and later remove the client. That said, .pkg would be just fine for this as you SHOULD be able to utilize that included uninstaller should the need arise.
Someone may recommend different permission settings but that's how I'd put them out at first.
FWIW, I've seen this same "Verifying Home Directory Contents" indefinite delay when I package up a change while logged into any user without a standard Home directory in /Users (for instance, the hidden "casperadmin" user that lives in /var). I think it may be some kind of bug in Composer.
I've taken to building packages as outlined in the manual -- with "temp" or "test" user on the system.
Also, if we're ever having drinks together at JNUC, remind me to tell you about the disaster that befell me org in 2005 because of an unexpected software bug and because I'd gotten into the nasty habit of installing all my software while logged in as the root user. The phone call with their technical support was highly interesting. I can't name the company's name because they are HUGE and generally have pretty good Mac support and don't want to dis on them for what was clearly a software bug but also party my fault for not following industry standard best practices. Thank FSM for backups!
@damienbarrett Now I have my first reason to recommend attending the next JNUC! @HelpDeskWarrior This is part of the reason why @mm2270 and others recoil in shock whenever a developer starts telling you to install things as root. In any event, your Composer window seems to indicate that you handled that install as plain ol' "admin" right?
Oh I forgot to mention this ... I took our base Mac image and installed the Popup software as root, captured the image then restored a computer with that image. The popup software DIDN'T WORK!
Is it possible that the software somehow interacts with the Mac's Domain binding on installation?
It sounds like it might be related to the files in being added to the users home folder. When you tried the image, did you test it with the same user account that installed it?
If it was a different user, it would be missing some of the files and wouldn't be able to run.
@davidacland I installed it as ROOT for the image as this is the only way it can work. Obviously i didn't test it on the image as the image computer is not domain connected at that time.
I tried what @davidacland and @Chris_Hafner suggested. I composed the image while logged on as admin made the changes recommended to the composed image and retested...not working :(
In regards to a previous question, is there someway to script this?
Hi @HelpDeskWarrior. I can't be certain, but my gut feeling is telling me that would be a no, as far as scripting this install. If its really true the only way this software can work is by being installed while logged in as root, I can't imagine any way to script that.
This is why I said originally that I would go back to the software vendor and tell them that their product is impossible for you to deploy from your management solution. When developers make their products work in such a way, they are not at all thinking of large deployments. Its literally a small minded way of thinking when they do this.
OTOH, if you can find some way to make it work when installed as a regular user, there might be an option to script installing it using the .app installer bundle being run as the logged in user. Its seriously kludgy, but might work, but only IF you find that it will work if installed under a regular logged in admin account. So far it sounds like it doesn't work when installed this way though? :(
The only two possible explanations I can see are:
- The vendors installer is putting some files into a location that other users cannot access, or
- The vendors installer is running a script that is performing something that the snapshot package in composer is missing.
Given the symptoms, my feeling is that it is the first one.
If you want to share the installer via Dropbox or something similar then I can take a deeper look.
Sorry guys, school has started and we are super busy.
@davidacland Interesting about what you said in your 2nd bullet point. When I install the program and it completes, I press the final button on the installer and then a couple of small screens flash up with installer bars, like it is running some sort of post install script. It happens super quick and then its done.
When I get time I will definitely get back on to the Fuji Xerox guys, I am happy to send the installer to you somehow @davidacland
