import parental controls via a logon script?

[kaptagat]

Hi Everyone

I want to curtail the use by students of a certain web site (starts with f and ends with k). I set up a local user, and enabled parental controls where I blocked this particular web site.
I then mcx exported this setting into a plist file.

I then made a script to be called by loginwindow manager (so it runs as root when students logon) hoping that the script's mcx import command would import the parental settings into their account when they logon. Unfortunately, it doesn't seem to work. It does work, however, if I import the setting into another local user on the Macintosh, via the terminal, so I know the mcx settings plist and the syntax is OK.

Here is the logon script :-

#!/bin/sh
/usr/bin/dscl . -mcximport /Users/testmcx Library/management/settings.plist

The system log shows the following entry :-

parentalcontrolsd[1187]: _FCXMIGUserCanLogin [2201:] -- *** tracker for uid 0 was nil.

Can anybody show any light as to why this works as a terminal command but not when run as a logon script?

If I can get this test to work then I hope to develop it to work with our AD students.

thanks

[ambrose]

I'm not running sys admin tools, so this is not (by a long shot) anything but a guess. In fact, I kinda doubt it'll work, but maybe ...

Sometimes, when a /bin/sh shell script doesn't work but its clone entered directly via cli does, it's because of a difference in command-variables-options interpretation between /bin/sh and /bin/bash.

Try #!/bin/bash.

[tlarkin]

I use this method to deploy local MCX to student accounts, but I do it via a Casper polity post image like so


#!/bin/bash

# import student MCX file

/usr/bin/dscl . -mcximport /Users/student /Volumes/CasperShare/Scripts/studentmcx.plist

exit 0

[ganbustein]

What's your current directory when this script runs at login? Are you sure Library/management/settings.plist is in it? Try using an absolute path.

[kaptagat]

Thanks. The file is in the folder. How much more absolute can the path be?

[Hal Itosis]

The file is in the folder.
But that wasn't the question.

Question was: in which directory is the script currently working?

[i.e., if you put pwd in the script at that point, what would it print?]


How much more absolute can the path be?
absolute path = full path

To answer your question: much more.

[e.g., see tlarkin's example]

[kaptagat]

The script is in the same folder as the settings.plist file.

The path looks to me to be absolute, if I drag the settings.plist into a terminal window this is what comes back which is what I am using.

/usr/bin/dscl . -mcximport /Users/testmcx Library/management/settings.plist

[tlarkin]

The plist file has to be present on every machine when running the script. That is why I tossed mine into a Casper policy, because I know for a fact every time a Casper policy runs it mounts the share to run any scripts or install packages.

Are you deploying this plist on all machines first, doing this post image, or how exactly are you deploying your local MCX settings?

[Hal Itosis]

The path looks to me to be absolute, if I drag the settings.plist into a terminal window this is what comes back which is what I am using.

/usr/bin/dscl . -mcximport /Users/testmcx Library/management/settings.plist
How can a pathname that doesn't start with a / possibly look absolute?
Do you not understand the meaning of full path? [again, see tlarkin's version]


The script is in the same folder as the settings.plist file.
The "physical" location of a particular script file isn't necessarily the current working directory of that script at any given point in time while it's running. [edit: and that is especially true for scripts which auto-run at login]

[kaptagat]

Thanks Tlarkin but I am only testing at the moment so the script and the plist file is only on the test machine. If I can get it to work during a logon, then the script and the plist will be on every machine.

But it looks if I have run up against a brick wall with it.

[tlarkin]

login hooks run as root, how are you exactly trying to deploy the MCX settings, with a script? Can you post your code?

[kaptagat]

The script for my test user called testmcx is :-

#!/bin/sh
/usr/bin/dscl . -mcximport /Users/testmcx /Library/management/settings.plist

It is called by loginwindowmanager so runs as root for everyone who logs on.

Running the command from a terminal window does import the settings into the testmcx account but having it run on login by the script it fails.

The settings plist file is quite long but here is the relevant bit :-

<key>com.apple.familycontrols.contentfilter</key>
<dict>
<key>filterBlacklist</key>
<dict>
<key>state</key>
<string>always</string>
<key>value</key>
<array>
<string>http://www.facebook.com</string>
</array>
</dict>

[tlarkin]

Loginwindow Manager written by Mike Bombich? I think that is depreciated. You should have either launchd run the script or have the login window run it via a log in hook.

[kaptagat]

It may be depreciated but it still works perfectly. It runs all our other logon and logout scripts without any problems. We are only using 10.6 in our labs but I do realize that it doesn't work with 10.7 so then we will have to move to login hooks. A big backward step in my opinion.

[tlarkin]

The reason it is depreciated is that the loginwindow now runs login hooks, and it is quite simple.


sudo defaults write com.apple.loginwindow LoginHook /path/to/script


Then place your script where ever on the system and input the full file path to it's location. Do note that it will run at every log in, and MCX only needs to be applied once, unless you want to update policy.

Another option would be to look at server side solutions.

[kaptagat]

Just found out that the script works but only at the second logon! Say I make a local user called test7 and change the script to reflect this. The first time test7 logon on, he can access the site, however, if test7 then logs out and back in again, the settings are applied and the site is blocked.

Tried this with an AD student account (using a variable for the user, me=$(logname)) and it doesn't work after the second logon. Our students who logon through Active Directory (network accounts) get their home folders deleted when they logout so I don't think this is going to be possible for such accounts.

[tlarkin]

You may want to look at editing the user template then, so when a user gets a fresh set of prefs they are already set that way.