Network login script

I think there's only two choices:

1.) Use MCX (Managed Client X) - You need a Directory Server with the MCX attributes in it. This is usually a Mac OS X Server, but can be a 3rd party server with modifications. Login scripts are only available to Computer MCX settings on Tiger clients.

2.) Create a loginwindow.plist file with the correct info and place a copy of this in all users' home directories (in their ~/Library/Preferences). This one is hard work if you've got lots of users.

What about an automounted /Network/Library ?

Technically anything usually found in /Library can be put in this and shared. It's primary use is for fonts.

You'd put a Preferences folder in there with a appropriately configured loginwindow.plist file.

I'd deploy the actual script (or AppleScript) on each of the workstations in /Library/Scripts.

When I did this for a local education district we used an AppleScript application (designed to mount two SMB shares on the desktop) as a login item. Setting this as the login item wrote a loginwindow.plist file to ~/Library/Preferences. I simply copied this plist to /Library/Preferences and it went on to apply the login item to all logins. We put this into the deployment image. We couldn't use automounts because the servers were AD and not Mac.

It might just work.

2.) Create a loginwindow.plist file with the correct info and place a copy of this in all users' home directories (in their ~/Library/Preferences). This one is hard work if you've got lots of users.

It's not that much work. Just modify /var/root/Library/Preferences/com.apple.loginwindow.plist on the client, and set to point to the correct login hook. In our case, for example, we have an automount at /usr/local/mounts/administration (you'll have to create /usr/local/mounts), with the login hook script within that directory.

Thus, for example, your loginwindow.plist file would contain a key for LoginHook, set to

/usr/local/mounts/administration/loginhook.sh

and that script would be run for EVERY user who logs in on that client.

Incidentally, if you need to copy something into every user's home directory, it's trivial to do that using a shell script.

David Walton

I would not recommend this because it would also affect local accounts on the clients. This isn't often desirable but does depend on the script's actions. Normally you only want to target network logins. The Apple-approved way to do it is via MCX. That way you have proper control over who is affected by the script.

How much work it is depends on the end user's skillset. Sticking to the Apple way of doing things is often the safest way. You never know when the next system update alters things just enough to break your "workaround".

Gow much work it is depends on the end user's skillset. Sticking to the Apple way of doing things is often the safest way. You never know when the next system update alters things just enough to break your "workaround".

Client-based login scripts are hardly a workaround--they've been officially sanctioned by Apple through at least three major OS revisions (I don't know about 10.1), and they continue to be officially sanctioned in 10.4. If you set things up correctly from the start (for example, reserving different ranges of uidNumbers for local versus network users), distinguishing between users who are local and who are on your server is trivial--just check the uidNumber and exit the script. Besides which, there are plenty of cases where you want the same behavior for network and local users.

MCX-based preferences may do exactly what you need in your installtion, and that's fine. But there are plenty of folks out there who have lots of experience using client-based login hook scripts, who have good reasons for using them. You might want to ask them about it before you issue blanket proclamations about what is and isn't acceptable. And your admonition about doing things the Apple way doesn't apply here, because MCX-based login hook preferences are not the only officially sanctioned way.

David Walton

So how do I automount an SMB share (and unmount it
after the script is done running?)

I haven't done this with an SMB share, but I have done it with AFP, and from the mount_smbfs man page, it looks like the basic principle is the same. Here's a script to mount and unmount an AFP share point. The user is "user", password is "pass", the share point is "share", and the server is "myserver.mydomain.edu."

mkdir /Volumes/share
mount_afp "afp://user:pass@myserver.mydomain.edu/share" /Volumes/share
# Now, run your script: e.g.,
/Volumes/share/scripts/myscript.sh
# Finally, unmount the share
umount /Volumes/share
rmdir /Volumes/share

Instead of mount_afp, you'll use mount_smbfs. From the man page, it's not clear to me how you include user name AND password in the mount request (I'm not sure what the separator is), but if you were using guest access on the share point, it would look something like this:

mount_smbfs -I myserver.mydomain.edu //guest@myserver/share /Volumes/share

Getting this to work is left as an exercise to the reader. 🙂 Note that there's no error-checking in the code above: if you want to mount your share point at /Volumes, for example, you should check to see if there's already a volume mounted there.

David Walton

I didn't know Joe's skillset and as an Apple trainer I am in the habit of playing it safe with customers - otherwise they rely on me where they don't have the skillset. I would never be so arrogant as to suggest I was giving the only and correct answer.

Admittedly, the term "Apple way" could be read as only sanctioned way, but this wasn't what I meant. The "Apple way" is more or less saying the easy way, the way the GUI does it, the way someone with limited skills should do it because it is the most friendly-documented. That way I don't have to take them through the whole thing step by step, which if I didn't would simply be irresponsible IMHO. But as I say it's just IMHO. IMHO that's what discussion forums are all about. Freedom of speech.

Nobody said there wouldn't be plenty of cases where you want the same behaviour to affect local accounts. I just know most of the customers in my country using Macs and Mac Servers and they do not. It depends on where you're coming from.

I don't issue "blanket proclaimations" or admonition anything. You're the one making blanket proclaimations that there is plenty usage of client-based loginhooks. Sounds more like a humble opinion to me. Have you taken a poll to verify your point? (rhetorical joke) No one said something was or wasn't acceptable. I was only trying to be helpful, in a safe way. I don't have a problem with being wrong or insufficient.

IMHO Apple Discussions is mainly for general users. IMHO advanced users should really be looking for help on more advanced sites such as afp548.com and macenterprise.org.


According to Apple Training the syntax for mounting remote file systems via the command line of Mac OS X v10.3 and later, is as follows:

AFP:

mount -t afp afp://username:password@hostname/sharename /mountpoint/sharename

SMB:

mount -t smbfs //username@hostname/sharename /mountpoint/sharename

NFS:

mount -t nfs hostname:/sharename /mountpoint

If necessary, refresh the Finder with:

disktool -r

This information is gleaned from Apple's Certified System Administrator training material. http://train.apple.com/ In the v10.2 material they used to use the specific mount tools directly. I believe there is some reason why not to use them with v10.3 and later.

In my experience there were issues with the mounting of SMB shares via the command line. In particular, refusal to unmount. These may have been rectified in the latest system update; I do not know. AppleScript may be an alternative (again I wouldn't claim to know for sure) because it uses the Finder to do the mounting of the share. This works really nicely with Kerberos. I do not know if the mount command can also use Kerberos.

I didn't know Joe's skillset and as an Apple trainer I am in the habit of playing it safe with customers - otherwise they rely on me where they don't have the skillset

In a server discussion forum?

From what I've seen here, the skill level does vary widely, but anybody who knows much about the login hook mechanism is most likely savvy enough to write or at least edit shell scripts, so it's a decent assumption that he or she can master the defaults command or edit /etc/ttys. It's not as if setting scripts via MCX is much easier (see below). And frankly, it can be a disservice to pretend that there's an easy, GUI-based way of doing this stuff. If you need to debug your login scripts, Workgroup Manager won't help you much.

I don't issue "blanket proclaimations" or admonition anything. You're the one making blanket proclaimations that there is plenty usage of client-based loginhooks.

Could we try to not let this discussion devolve into a bunch of tu coque responses?

To start with, you incorrectly said that there were only two ways of doing login hooks. When I corrected you, you replied with some more incorrect information, and then finished with this:

Sticking to the Apple way of doing things is often the safest way. You never know when the next system update alters things just enough to break your "workaround".

Perhaps what you said wasn't a blanket proclamation. But sniffing that alterntives to your solution are 'workarounds' (with the implication that they're not Apple-sanctioned) is ridiculous. Client-based scripts are not a workaround. If you look at the documentation (more below), Apple hardly mentions MCX preferences as a login hook mechanism at all. And the client-based 'workaround' has been an officially sanctioned way of doing things since at least back to 10.2 (don't know about 10.1, as I said before). It continues to be officially sanctioned in 10.4. So let's can it with the scare quotes and the snark, shall we?

As far as me making blanket proclamations, I said:

MCX-based preferences may do exactly what you need in your installtion [sp], and that's fine. But there are plenty of folks out there who have lots of experience using client-based login hook scripts, who have good reasons for using them.

Note the phrase "plenty of folks." Sound like a universal generalization to you?

Finally, a last nugget, after which I will abandon this back-and-forth:

Sounds more like a humble opinion to me. Have you taken a poll to verify your point?

It's not an opinion. I've spent three years interacting with people who manage installations of Mac OS X and Mac OS X Server as part of their work. I've read their posts, replied to them, and asked questions of my own. I've done this on Apple Discussions, www.bombich.com, afp548.com, and Mac OS X Labs/MacEnterprise.org. I've interacted with Apple SEs. I make my claim on the basis of a good deal of personal experience and interactions with other folks--it's not just snark. Finally, if you look at the differences between the various options, and how Apple has publicized them, you'll see that there are good reasons to make the claim:

- Before 10.4, there was no such MCX setting for login/logout hooks. As you can tell from reading the posts here, a number of people are still running 10.3.9 (or mixed 10.3/10.4) installations. Even those who are using 10.4 may not be using MCX at all, and may not want to.
- The MCX preferences settings is not well-documented. If you do a search for login hook on Apple's support site, the one KB article that comes up doesn't even allude to it--it only discusses /etc/ttys and root's loginwindow.plist file. The only place I've found MCX prefs mentioned for this, even in the manuals, is in the User Administration guide--a grand total of about six paragraphs.
- Using MCX doesn't really simplify things that much. You have to use the defaults command to enable MCX prefs on the client, which is about the same as...using the defaults command to specify the client's login hook in the first place. The main difference with the MCX approach is that the scripts live on the server, not on the client--a problem that the rest of us dealt with way back in 10.2 by dispatching from local scripts to scripts on a static automount. Plus, if your dispatch script is local, you can still run scripts even when the server's not available.

THAT is why I say that there are plenty of folks who use client-based login hooks.

In the v10.2 material they used to use the specific mount tools directly. I believe there is some reason why not to use them with v10.3 and later.

That's interesting. I wonder if that means they officially deprecate the protocol-specific versions, and why (I presumed that commands like mount_afp were completely transparent wrappers for mount, but perhaps I was mistaken). Certainly there's no reason that I can see not to use the generic mount command, as you describe. Your allusion to problems unmounting SMB filesystems from the command line tickles a memory from some time ago, but I don't know the exact nature of the problem, or whether it got fixed.

Perhaps it's time go through and change my mount_afp calls....

David Walton

I know it's gauche to respond to one's own posts, but this has to be said.

I said:

In a server discussion forum?

To which, of course, the answer is no, David, you idiot: this isn't a server forum. I found this thread while doing a search on something else, so I didn't even pay much attention to the fact that this was a 10.4 Administration forum, nothing to do with server. So Andrew, your assumption about the skill level was perfectly reasonable.

My apologies.

David Walton