Good morning. My name is Gordon Shukwit, and I'm here to introduce to you Richard Glazer from the University of Utah and Philip Rinehart from Yale University. So the first thing we want to announce was that the Mac OS X labs project is now moving to becoming Mac OS X Enterprise Project, and you'll find it at macenterprise.org.

What you're going to see is that there's an increased work that's going to be going on where they're changing from just primarily looking at lab deployments to looking at how you deploy Macs completely in the whole lab. And they'll be looking for some additional participation outside of just higher education. So with that, let me turn it over to Richard, and we'll go from there. Richard Giaser, Philip Rinehart Okay. Today, what you'll learn are we're going to cover some basics on application distribution.

Next, we're going to cover things you should know, commonly overlooked issues that admins should know about. Next, we're going to cover how to track an application, what does an installer application really do to your file system. Next, we're going to cover finding solutions, how to make the application work in an environment. And lastly, we're going to cover distributing the application, what tools and solutions are available.

So why is this important? That's probably the most important question that you should probably ask yourself. First thing is security, so you can find and fix security issues. The next thing is flexibility. It allows an administrator to easily add, remove, upgrade, or downgrade applications. It also allows for speed, so it means that you don't have to spend your time developing new systems, and you can quickly distribute application fixes and their updates.

It also allows for granularity, because I can control that distribution on a per-machine, per-user, or group, or for the entire enterprise. And lastly, it allows me to log complex installs with abstract names. It allows me to control the setup details and the customizations to distribute the application properly.

So let's talk a little bit about the deployment lifecycle. It's what we all deal with every day. The first thing that we do when we get a new machine in the door is we assess the needs. What does this Mac need to do? What application load set does it need to have? The next logical step is the creation, building, and testing of that load set that you're going to apply to the machine. So you have to figure out, what am I going to put and where am I going to put it? The next step is actually deploying the application load set and deploying it in your enterprise environment.

And the next and last step is to patch and update it, basically to address security needs or application needs. And then the process begins again with the assessment of needs as new machines come in or as machines are retired. So let's talk about some of the factors in management.

First thing, and probably the most important thing, is security. By doing this, it allows us to find and fix potential security issues. It means that more and more, most of us have an enterprise security policy, which we need to meet, and I can meet that policy by controlling my application distribution. It also minimizes the impact on the network. I don't have to worry about my machine affecting other machines, and it minimizes the risk of my machine being compromised by a hacker or some other user.

Also, it gives a uniform experience for all end users. This is titled security, but it actually isn't security. It should be consistency. It means that I can give a uniform experience for all end users so that when a user sits down to their machine, they know where things are and they have certain expectations that are met. It also means that things break consistently and can be fixed consistently, and that's equally important because it means if a user calls me up and says something has broken, I know where to begin to look. and it makes the troubleshooting of applications simpler.

The next thing, and this is probably one of the best benefits of this, is it gives me efficiency. It means my time, I can use tools to control and manage that distribution, I can reduce my time spent developing a new system, and I can minimize the downtime of my systems, so essentially they're up 24 by 7.

And the last thing, and probably the thing that will make your enterprise managers the most happy, is cost. It reduces the time you spend managing. It means I can use open source and free tools. There are many open source and free tools used to manage systems. I can also leverage existing technologies, and I can deploy in minutes instead of hours. So let's go back to the Create, Build, and Test phase, the deployment lifecycle. So what we're really going to focus on today is Create, Build, and Test. What we're going to talk about is what you should look for when you're deploying applications in your environment.

Things you should know. This will be a basic guide to what you need to worry about for distributing an application. This flowchart gives you a basic flowchart of the process. The first thing is kind of obvious. You install the software. Next thing, you set the application, enter any serial numbers, do any default installation. Third, you customize the application depending on your environment.

Fourth, you track and debug what you've installed and what you've customized, and then make modifications to get the application to work properly based on your customizations. And then lastly, you distribute and also debug, because certain distribution tools might cause certain issues with some applications. You might have to make some modifications.

Next on the cover, you shouldn't always entrust installers. The first issue is sometimes installers will install insecure permissions. Sometimes installers will not install the installer correctly or properly. And also sometimes installers will install binaries with elevated privileges. The next issue that arises sometimes is sometimes installers require administrative privileges.

A lot of times this isn't necessary for installs. Also overuse of the admin credentials can make it cause people to be careless in just automatically entering those in, and that can become a security risk. Lastly, if you require admin for installers, it also could stop non-admin users from installing the software.

The next thing that's another issue with installers is sometimes they install in non-standard locations. So, for example, the root of the file system, USRBIN. Also, installers sometimes will modify critical files. So, for example, sometimes installers to make certain binaries or application launch on login will modify the user's login window .plist or the host-based library preferences login window .plist. This can cause a burden for the IT to manage because you either have to manage multiple login .plists or cause problems based on which user logs in might not have the application experience they need.

Next, I'm going to cover some topics on insecure permissions. The first one we're concerned about are world or group writable. This is an issue because this can cause security problems. Sometimes an application will require these for the application to run properly. The next are special modes. You have SUID or SETID.

This can cause problems because the application or the binary an application uses will run with the privileges of the owner of that application. This, if the application is not properly set up, could allow another user to compromise your system. Also, the last, SET Group ID, you also have similar issues where it basically runs with the privileges of that group.

So here's a basic example of the issue with SUID application. So you have an SUID application, and then the next screen, it's owned by root. Any user comes in, Joe Blow, is a non-admin, launches the application. Basically, that binary application runs with root privileges, and if the application does something improperly, it could be used to either delete files or compromise the file system. This is a real big concern to enterprise.

Next, I'm going to cover the process of doing some simple tracking. The first option is readmes. You see if the installer package has a readme. Rarely, in my experience, does that give you any detailed information, but it's your first option. Next, after you've done the installation, you could always look at the log file and see exactly what it's installed and see if it gives you any details.

Third, you have multiple options with package installers. The first I'm going to cover is Apple's installer utility. The second I'm going to cover is a GUI application called Pacifist, which is a package utility. The third one I'm going to cover is LSBOM, which is a command line utility that allows you to view package installers. And again, note, these only work with .pkg installers.

So here's an example of using Apple's installer. So basically you launch Apple's installer utility, launch the installer, then what you have to do is go step through until you select the destination. Then what you'll see is under the file menu you have a show files option. This will basically show you all the files the installer will install before you install. Again, this doesn't give you a lot of detailed information you really should have, but it's a good first start.

Another option with the Apple's installer utility is the show logs option. The show log option is good because you can actually watch scripts process. A lot of times installers either have pre, post scripts that do certain things, and you can actually watch actions they are doing. Again, this doesn't give you all the details you need, but it's a next step.

Next I'm going to cover Pacifis, which is a GUI package installer utility. If you see from the screen here, Pacifis gives you a list of all the file system items installers can install, but also gives you some detailed information it's really important to have. For example, you have permissions, and you also have attributes like owner and group. Also, Pacifis is really useful. You can verify, take an install, and verify what's installed on your system. It supports checksumming.

Another item that we do a lot is if you need to custom install an installer or a piece of an installer in a certain location, you can use Pacifis to force it to install to a custom location. Also, Pacifis is good to detect if something's been deleted on your machine that you need from an installer.

Next, there's LSBOM, which is a command line utility that allows you to view package installers. So this first section here at the top, basically what you want to do usually on package installers, you want to go into content slash resources. And, for example, you could do an LS and look for the .BOM files. And here in this example, I'm showing iTunes. So that's the file you want to find.

Then the next thing you want to do is list the bill of materials or the BOM materials to show all the contents the installers can install. So you basically run this command, the BOM, LSBOM, minus P, M-U-G-T, S-F-C, and then the BOM file you want to use. And it'll basically give you a list of permissions, attributes, and et cetera.

Next, there's some options for drag-and-drop installers. So basically use the ls or list command. So here, for example, I have a drag-and-drop installer, Fugu, which is a SFTP, SCP application. I download it. It launches a disk image, and then I just drag the application package to wherever I want in the file system. But if I want to see what permissions has, I basically run the command below, ls, and I use the parameters l, a, t, r, and then it'll give me a list of permissions, attributes, etc.

Next, we're going to have Philip is going to do a demo of some of the items I talked about. Could we switch to demo two? - Demo one. - Or it's demo one, sorry. So basically I'm going to take our, one of our favorite apps, iTunes, and going to show you how we can do some of the simple things with Installer and how we can, some of the things that Richard just explained. So I pre-launched this so you can kind of see some of the things that happen.

So when you launch Installer, there's an option in the file menu that says, right now it's hide log, but if I go to the file menu and I say show log, it brings up a log. And if you notice, I've actually got information here already, and it's basically, what this has done is run, it's called the pre-flight script, and you can see the results of that.

So watch how it happens now when I hit continue. It's actually going to do, as it runs the scripts, it will actually do, fill that log. And there you go. You see that it says show everything. I typically want to see everything that happens because it's going to talk about everything that it does.

Now, Richard said that show files only begins to appear after you've selected a destination. So in this case, I've selected original. And then all I have to do is go to the file windows and say show files. And notice that this deals with not only packages but also meta packages, and I can basically show you all the files that are installed. So that's a useful first start. But what it doesn't do is it actually misses the checksum.

It misses the permissions. It misses a lot of things that can be useful. So I'm going to show you the other tool that is the next logical step after you use installer, which is Pacifist. And Pacifist looks at packages or meta package files and basically provides you a lot more information. So notice here that I've brought out the package, and the contents of the iTunes 4 package shows me a ton of information. I get to see the size of it.

I know the owner of it. I know the group of it. And notice that I see the permissions. I also see the original modification date. So this allows me to take this and view all of the things that might be important to me. And this little button right here, extract to, is also really useful because, as Richard said, if I want to install it in a location other than the default location that installer might put it in, I don't have to depend on that anymore.

I can now extract it to any place across the file system that I have permissions to extract to. And the other thing is notice that it also has the authorization dialog. So in case you would want to put it in some place that you may not normally have access to, you can do that.

Now, what I'm going to do is, Pacifist is a great GUI tool. You could do the same thing. With command line. And here's the example of the command that Richard listed, listbomb-p. And you'll notice when I do this, I get a ton of information. A little bit hard to read right now because of the way the line wraps happen, but essentially it gives me all the same sort of information that I just saw in Pacifist. So if you're more comfortable with the command line, it's one way to do it. Now, the other thing is for drag and drop installers. I'll get it right once.

So, I listed a lot there. But, as you can see, when I do list-LAT capital R, what I do now is it actually gives me all the permissions information for a drag-and-drop installer, gives me the group, everything else. The one thing it doesn't do is a checksum because there's really no way that lists can support checksums.

So, it gives me an insight to what the application actually might be doing because a lot of drag-and-drop installers, because of the ignore ownership flag that is set often, when a developer drags that over and creates it when you first open, it's going to come down to your file system with it being completely open and having world-right permissions set. So, it's just a good idea to check it before you drag-and-drop it or when you drag-and-drop it, then you can check it. So, back to Richard. Yep. Thanks, Philip. Back to slides.

Next I'm going to cover things you might not know but we think are important to know about. Here's a list of some commonly overlooked issues. The first issue that we've run into are broken links, symlinks, or aliases with applications. Applications that do not follow the preference hierarchy. By host preferences, which are host-specific file naming and preferences. Hard-coded pass. Directory location limitations, either restricting you to either the root of the file system, root of applications, etc. file or finder attributes.

Broken links. The first thing you have are sometimes applications will depend on symlinks, and sometimes they'll use absolute pass. This will cause issues if the admin or user moves a folder or renames a folder or moves the parent folder or renames the parent folder. Aliases. Prior to Mac OS X2, aliases resolved based on unique ID.

And X2 and higher, they use the path name similar to symlinks and then use the unique identity second. Again, problems arise when either the user or admin renames the application folder or moves it to a different location. Then the issue where the unique identity will not resolve is when you use a cloning software like ASR.

Preference hierarchy. This is an OS system where applications can depend on the OS to resolve separate scopes to find preferences. An issue sometimes happens when an application requires a specific location or restricts to a specific location. You have options for separate scopes. The first scope you have, user space, where you can install the preferences and users slash username slash library slash preferences. This restricts the preferences just to that specific user. Next, you have host-based scopes, which could be stored in library preferences, and this is limited to users of that particular machine. Next, you have network scopes, which are stored in network library preferences.

So here's an example of a quote-unquote flexible app and a problematic app. The first app uses the OS's preference hierarchy. So the admin or user can basically install, based on their needs and their environment, it can install the preferences in separate scopes. So if the admin wants to install in the user scope, they can do that, and the application will work properly. Else, if the admin wants to instead say they have limited disk space and don't want to duplicate preferences, if there's a lot of preferences, could put it in the host-based scope.

And then an example of a problematic app, app basically requires you to use the user space scope. This might cause some problems if you have, for example, an application that has a lot of user-specific files, and it's not easy for them to move it to host or network-based.

So following on Richard's talk about the preferences hierarchy, the other thing that we need to talk about when we talk about preferences, by-host preferences. Now, by-host preferences are a unique case because they use a particular machine-specific hierarchy. The Prefs file contains the Mac address of the machine or the host name of the machine. The preferences are typically stored in the user scope at ~library_preferences_by_host or in the global directory of library preferences by host. So as an example, in our test Mac machine, I've set up my machine that I want to deploy.

I set it up exactly like I want, but in the by_host folder, it has the setup Mac's host name or the setup Mac's hardware address. So what happens when I now deploy this? When I deploy it and I put it on my cloned Mac, now the setup Mac host name is different and the setup hardware address is different, and so no longer are those preferences actually preserved.

So let's move to something different that we talked about, hard-coded paths. Often hard-code paths tie an application to a default location with a default name. And some apps actually expect the default install pathway. So they might expect it to be at the My Applications, My App Folder, My App. If they're not there, they may not work properly. So when the parent folder is moved or renamed for clarity, it may actually break the application.

We also have directory location limitations, which is also related to hard code pass, that some apps may require installation at a specific location, such as the root level of the hard disk or the root level of the applications folder. And many installers and applications don't support the special characters, such as spaces or the option six character or other characters that can be added to it. And this particularly causes issues when you try to update the application or use features of the application.

Last thing that we're going to talk about is file or finder attributes. Some applications use file attributes, Carbon file attributes for setup, and some distribution tools don't support this information. Typically, the way that you use this is within the developer tools directory. There's a tool called get file info, and the get file info actually looks at the Carbon resource file and basically tells you what is stored in that file, and particularly the attributes. And it could be also the creation and the modification date.

Next on the cover, tracking installation. What does the installer really do? We've covered some simple tracking options, read me logs using Apple's installer utility, Pacifist LS Bomb. Now we're going to cover some more complex tracking options, uncover utilities like FileBuddy, a command line tool called LogGen, and a suite of tools called RadMine.

First, what method should you use? The first option depends on the technical ability of the admin. Do they know command line? Next, do you want to use a GUI or command line? Some of the tools do have GUI friends, some don't. Some maybe not offer all the features with the GUI that they do with the command line. So you have choices there. Also, the accuracy of the tool you want to use.

Some tools don't track as well as other or as accurately as others. Lastly, how does the tool you're using for tracking installation integrate into your overall distribution model? Again, simple tracking. It works great with packages and drag-and-drop installers. Complex tracking you can use with packages and drag-and-drop installers. You can also use with non-Apple installers, so like VICE, install anywhere.

So here's an example of FileBuddy. FileBuddy was a popular Mac OS 9 file utility that was ported to Mac OS X. FileBuddy has an option where it allows you to capture a snapshot before and after install. And then you create a comparison of the before and after install, and it'll give you a list of added items, modified items, deleted items, etc. The cons against using FileBuddy doesn't support the detailed information that you usually need, like permissions and attributes, and also doesn't support file checksums.

So below, here's a graphic. If people haven't used FileBuddy, basically you launch FileBuddy utility. There's an option, create a snapshot. You take a before snapshot, you install your software, set it up, do any installation customization. You do an after snapshot, and then you compare the before and after, and then it'll output the files listed below.

LogGen. LogGen is a command line utility. It's open source. It depends on Perl modules and Mac OS XIII. And it does support detailed information like permissions and attributes. It also does support file checksums. And it uses a similar method as FileBuddy. So you basically take a snapshot of the file system before, install your software, set it up, do any customization, and then do a scan after, and it creates a logs of what's been different in the file system.

So here's a quick example of Loggen. Basically, you, Loggen, you store an S-bin, so you run the utility Loggen, you name whatever you want to call the before snapshot, then you install the software, set it up, then you basically run Loggen again, you name the after snapshot, and you also select the before snapshot, and you can either output it to screen or output it here to changes.txt. And then the output below, you'll get something similar. So it shows you new files, changed files, or deleted files.

RadMine. RadMine is a suite of command line tools. RadMine is a really powerful file system management tool that can be used to manage the whole file system from tracking to also distribution. RadMine does support detailed information like permission and attributes on a group and also supports checksum. The process of RadMine is slightly different than the other tools.

What you have to do is set up a managed file system. You update the client to that managed file system. You install the software, set it up. Then you run the RadMine tools. The RadMine tools will scan the file system, compare it to the managed file system, and log any differences.

So we're going to talk about advanced troubleshooting. And this kind of might seem a little bit out of place in tracking, but it really isn't. Because typically, we want to run the application as a non-admin user. And so sometimes the application may not work as a non-admin user, so we have to have a way of tracking what that application is trying to do so that we know what to do with the application for deployment.

Richard Giaser, Philip Rinehart So most of these are command line tools. Some do have GUI interfaces, but most are accessed from the command line. The first one is LSOF, which lists all open files. The next one is FS underscore usage, which monitors kernel-level system calls and file system activity. And the last one is K-trace, which is kernel tracing, and it's a very low-level tracking mechanism.

So let's talk about the first place that you should probably start. List open files. This lists open files by processes and has many command line switches. The first one that I have highlighted here is list open files with the dash C switch. And what the dash C switch does is tells it to pay attention only to an application that I'm interested in. In this case, I've said I only care about mail.app. And so what it simply does is it tells me all the activity that's going on on the file system with mail. but only with open files.

The other thing that you can do, and is another useful switch, is if it's trying to do something to a particular directory, you can pay attention to just that application directory with the plus capital D switch. So I can say list open files, plus capital D, pay attention only to the mail.app directory. So if a normal user is trying to write to some place that I don't understand where it's trying to write to, I may capture that with this command.

Sloth is a GUI for list open files. It makes it a little bit easier because I don't know if you can actually see it. Yes, you can see it. It has a number of checkboxes that basically encapsulate the command line switches. And you can also set a filter on it so that you can really pay attention.

So let's move to the next level. This is the next level that you go if list open files doesn't give you enough information. You use file system usage. It has to be run as root, and it's more advanced than LSOF because it basically tells you every file that's trying to be accessed across the entire file system. It also reports in real time, and the output is very, very verbose.

So I've listed the command here, which is fsusage, followed by the dash w, which tells me wide output so that I can see the entire path. I next tell it that I only care about file system objects. I don't care about anything else. I next attach to the process identifier of the application, so that's what I mean by command.

I next use grep to omit cache hits. If you don't do this, you're going to find that you have a ton of output that you actually have to deal with. You have to pay attention to, and it can actually get very chatty and makes it hard to find what you actually are looking for.

The last thing that you should use is kernel trace utility. And this is when you have an application that's doing something and you cannot solve it in any other way. It handles all calls directly from the kernel. The output is not readable by a text editor. It actually stores it in machine format. And it provides the most complete set of information. So notice that I have ktrace-ti-p to the process identifier of the application. Then to read that, I use kdump. It's going to put a file called ktrace.out.

And the directory that you start, typically this is your home directory. And then you can pipe that to a text file. And then you can read it. But as you notice from the example here, it's actually fairly complex and it's not easy to read. If you're going to use ktrace, I would suggest reading the manual page because it will provide you most information that you need. The next thing that I should say is when you run ktrace, it's actually very important that after you have tracked the application, that you actually turn it off. If you don't turn it off, it will continue to monitor until basically your file system is full.

So I actually accidentally forgot to shut it off once and filled up a 60-gig car drive in about four hours because it basically just continues to monitor every single kernel-level call. So read the manual page if you want more information. So Richard's going to do a demo over on demo two.

What I'm going to show is two of the utilities we talked about, FileBuddy and RadMine. Note, just for sake of speed and for demo purposes, I'm basically going to use a disk image to show the demo. But you could basically use our entire file system on a real large hard drive, but if you guys want to wait 40 minutes while I do stuff, we could.

But anyways, so what I'm going to do is, here's the disk image. I have basically an app on it. This could be the OS, could be whatever you want. I could have a real diverse file system here. But for simplicity and sake of time, it's just real simple. So basically, I have chess, and what I want to do is I'm going to show FileBuddy.

So I want to do a file scan, a snapshot of the file system. So I launch FileBuddy, and I select take a snapshot. Then I select the volume on it. So I want to take a snapshot of, which is the disk image, and I name it. So I'll name it before. and Outputs.

Next, I'm going to install an application. Again, for sake of time, I'm just going to do a drag and drop with my app. So I just drag this over to this image. This could be an installer, could be a vice installer, could be complex. File system could put the pieces wherever you want on the file system. Again, for sake of time, just do a drag and drop. So next, again, I did the install.

I did any customization I wanted. Then I take a snapshot again. And I call this one after. And outputs it. And the next thing I want to do is compare the before and after snapshots. And what it'll do is output a folder that basically has these files listed in here, and I'm going to display those.

So you'll see in the new items that list my app and the package contents there, doesn't list any detailed information like permissions and attributes. There's also new and modified items. Nothing was modified. It was only new items on the file system. What I'm doing here, which we'll talk about later, is I'm running an Apple script to basically mount the disk image with the shadow file. I wrote the Apple script to remove the shadow so I could get back to a clean system. So basically what that did is dismounted the disk image, deleted the shadow file, and now I'm mounting it again. We'll talk about that a little bit more.

Okay, so the next tool I'm going to show is RadMine. Again, I'm back to my clean system. In RadMine, one note, I'll go over this a little quickly. RadMine, you set up a default managed file system, which is defined by this command.k. Again, for simplicity, this is a real basic. It doesn't have any unmanaged items on the file system.

The base image basically contains my default baseline image, which just contains chess. If you have questions, you can ask me after RadMine. It'll take a long time to talk about. So again, I do my install, do any customizations I want. RadMine does have command line, or GUI front end, but I'm gonna show the command line.

The first thing, again, I'm gonna basically CD to the root of the disk image. The next thing, I'm going to use a command line tool called fsdiff, file system differences. I use a minus uppercase C, which defines a creatable transcript. And a creatable transcript is when I want to create an overload to upload and distribute to other clients.

The next parameter is minus lowercase c, which defines checksum, and SHA-1 is one of the checksums RadMine supports. The next parameter is minus dot current path, and then I'm outputting the transcript that it creates or the modifications to the disk image to myapp.t. Let it run, and there it goes, and it'll create a file on my desktop, and I'll open that up for you.

So you'll notice kind of some differences here. FileBuddy only lists some of the contents. It uses the date and size modification date. RadMine uses checksums and gives me detailed information like permissions. So if I use FileBuddy, I wouldn't notice that this application installs with world rights, the 0777. So I'd miss that item. Also with RadMine, you can also check for SUID, and I can quickly scan through the transcript and find those items and be notified that there are some concerns here. So anyways, back to slides. Back to slides.

So let's talk about, now that I've actually tracked the installation and I know what it actually does, how do I actually make it work? Because often the developer may not have the time or it may be a fix that is coming down the road. How do I actually make the application work? So let's talk about modifying the default install.

There are solutions that you can use in Installer. We can solve the problems of installers installing with super user privileges. We can use tools to customize or extract the installer. There are also security solutions where we can modify the permissions and attributes to something more acceptable. We can use links to redirect to a user space instead of the global space. You can use a disk image with a shadow file, or you can use log in, log out, or startup scripts.

You can also affect the preferences by using login or startup scripts for by-host preferences. You can move the preferences to a different scope, so instead of being in the user scope, it probably or sometimes will work if you move it to the host or network scope. And the last thing we'll talk about is file and finder attributes.

So some installers actually require root privileges to install because they require writing to the file system in places that you cannot write as a normal user. So there are GUI and command line options. The probably easiest GUI one is called sudo, and all you do is you drag the installer on top of it, and then it installs as root, which means you have access to the entire file system. The other way you can do it, of course, is with the command line. You can use the sudo command and impersonate the root user. You can either open a Cocoa application, or you can use the carbon-based installer.

The other way that we talked about a little bit earlier, but this is the only solution with package installers, is to use Pacifist. And with Pacifist, it allows you to install to any location across the file system. And it also allows you to extract individual items. For example, if an application actually breaks and you need to get part of that application out, you can do that with Pacifist.

So permissions and attributes. What's the simplest way to actually look at permissions and attributes? Simplest methods to find are using the Git info. You can't set certain bits, you can't set the execute bit, and you don't have access to the special BSD bits, the set UID, the set GID bits. Those are not there.

So there is an application, Freeware, I believe, that's called X-Ray, and it allows you to see all the bits on a file. So if you notice, the orange box shows you the special bits, the set UID, the set GID, and the sticky bit. And the security bits, which are less familiar to some people, the BSD security bits of the user flags and the root flags, the append, all those type of flags are located in there, and you can modify these with X-Ray.

So what's the quickest way to reset file permissions? I don't really want to, let's say I don't really want to use a GUI, but I want to be able to go through and traverse either the application or the entire file system if I want to look for every set UID, world or group writable, or set GID app.

The easiest way is to use the Unix command line find utility. So I've highlighted some of the options so that you can see how this actually works. The first thing that I do is I do dash X. Dash X says I don't care about network file systems. Amen.

And in this case, I'm not going to start at the root level. I only care about my app, so I'm going to only look in the applications my app directory. So that becomes the first place that it looks. The next thing that I'm doing is I'm looking for World Right permissions, permissions of 0777.

I then put the exclamation point and tell it that I don't care about sticky bit directories. And the reason is because sticky bit directories are traditionally considered as a safe measure of using something that needs to be world-right because you cannot delete other users' files. The next thing that I do is I also add the option of I don't care if it's a link because links don't matter so much if they're world-right.

The next and last thing is I actually am telling FIND that I want verification every time I go through the entire file system. And what I'm doing here is I'm using this change mode command, shmod, to remove the execute bit so it is no longer world or group writable.

Now, you can also do this with the set UID and set GID in the same manner, except this time I add the option of that I'm only looking for file types and that I only care about the set UID bit. And again, I'm using the OK so that it asks for verification so that when I actually change and remove the set UID bit, I have confirmation that it just doesn't do it. I actually like to be careful that I'm actually prompted for an OK. Could do the same thing with set GID. You just change it to 02000, does the same thing.

So let's talk a little bit about redirection so that you can leave an application in its default location. Symbolic links often will trick an application into working correctly. So as an example, in my applications, I have an application test WorldWrite folder. I have a WorldWrite folder. And in that folder, I basically want to not leave that folder there. I want to redirect it to a more benign space. So in this case, what I've done is I've actually symbolically linked that WorldWrite folder to a place that I can put WorldWrite folder that I trust it to be.

And so I've redirected to the user's shared directory, and that's where I leave the WorldWrite folder. You could also use aliases to fool an application, and sometimes that works as well. You can either use the finder to do it, or there are command line OS X utilities. It's a source forward project. If you just look for OS X utils, there's actually a make alias command. that's command line.

Using symbolic links also works for directory location because you can use them to preserve that location. You preserve it for upgrades, and you can give a custom name to an application without actually altering the original name. It's also safest to use the full path if you're using symbolic links, not to use relative links.

Next I'm going to cover other options when you've tried redirection, modifying permissions, and your application still does not work properly. The next option is to basically use a disk image and mount it read-write with a shadow file. So my example there where I had an Apple script to mount my disk image with a shadow file so I could write to it. All modifications I could basically pipe out to a shadow file and I could store those in user space or other locations.

I deem that wouldn't be an issue with the file system. These are really useful because sometimes you'll run into an application that basically requires write access to the same location. It uses a temp file, for example. What you can do is you'll see below there's an Apple script. What you want to do is use do shell script. You want to use the HDID tool. Then I give the pathway. To the disk image, so applications app.dmg. Then I use the parameter minus shadow.

Then the next step, I do the pathway, which I just have app shadow, so that could, I basically could do the path to the user space and save the shadow file to that location. I've used this on many applications, and it's an ideal solution. One thing to note, sometimes the shadow files become very large, so you want to either delete them on logout or on startup.

Next, if you can't solve an application's issues with any of those options we just talked about, one option is using scripts. With scripts, if an application needs certain files created, you could create those. You can remove certain files or folders that are world-right, so if an application does require world-rights, you can't use a shadow file, you could go back and remove those on logout or on SCARTA.

Also, you could modify preferences if an application requires certain file attributes, you can modify those with a script. Also, if you have an application that doesn't close properly, you can use a script to kill the application properly. Again, you can run these at login, logout, startup, or you can put a GUI wrapper in front of the script.

File attributes have revisited. Some applications depend on some file attributes or finder attributes that aren't supported by some distribution tools. So for example, we use the developer tool Get File Info. I get the information of the Carbon registration database to gather all the finder attributes. And then I notice there's one attribute the application depends on, else it'll reconfigure. So what I want to do is use the set file minus D parameter to force the application to have an attribute it won't have after I use a distribution tool. Next, I'm going to cover distributing the application, some tools and options, and some solutions.

First, how do you distribute software? If it's a package installer, you have multiple options from Apple. If you want to do network versus local installs, you can use NetInstall, ARD, and there's a lot of other options. Or simply download the installer to the local machine and install it. Then there's some options for managed versus unmanaged. Unmanaged options we would consider like Apple Remote Desktop. Managed options you could have open source tools like rsyncx and Radmine.

So let's talk a little bit about repackaging and why you would actually want to do this. The reason that we find repackaging to be a very useful tool is because you can take any installer from any third party or a drag-and-drop and you can repackage it. This also means that if I've modified an application and I put it in a certain directory, I can preserve my corrected permissions.

So if I don't like the way it came out of the box, I can modify it, repackage it, and now when I distribute it out, it actually has those permissions that are preserved or any modifications that I may have done. It also means that every time a user may perhaps, let's say we have in an enterprise environment a laptop user, if they run the utility repair permissions, it actually looks in the library receipts directory and pays attention to those permissions so that it recorrects them to the way that I originally intended it to be. And probably the best benefit of repackaging is it means that if I'm an Apple Remote Desktop or NetInstall user, I can now use those utilities to distribute the application, which in an enterprise is a big win.

So let's talk a little bit about Apple Remote Desktop. Now, Apple Remote Desktop with 1.2.1 actually included the ability to install a package. And this is really, really useful because it means that I now have a package, I select Install a Package, and I can install it to any group of machines that I've set up to do so.

I can also do it with a command line. So, for example, if I have Apple Remote Desktop turned on, I can actually, or actually even if I don't have Apple Remote Desktop turned on, I can SSH into that machine. I can then use the Kickstart tool, which I give the complete path there, but don't worry about writing it down because it's actually in an article, a knowledge base article.

You can use dash H with the help option. It gives you the complete sort of man page. There is no man page for Kickstart. You actually have to do the dash H option, and it spits out a long file. And the other thing is that you must use Apple Remote Desktop 1.2.1 or later. And the article number, and this is where it's probably, if you just write down 107837, that's the actual knowledge base article. And it's also in ARD2.

The other advantage of a package is if you're big in net install, you can actually use net install to distribute this package throughout the enterprise. So if I have mobile users who connect and let's say you've just purchased a site license for Macromedia MX, let's say you've got that license, well now that I've packaged it in a package installer, it means they can attach to that net install machine and they can install it and be within compliance if you have that site license.

Next, I'm going to talk about the open-source utility, rsyncx. rsyncx is basically HFS plus implementation of the rsync protocol. A developer has put a GUI front-end and a command line option to using this utility. This utility in the past has usually been used to sync, say, servers or things like that.

The rsync protocol is really very efficient at basically copying the differences between two file system options or items. So this is a great utility. It's been used a lot in Mac OS X deployment. One con against this utility, it doesn't give you granularity of some other options where you want maybe just to distribute one specific file.

RadMine, again, I talked about that. It's an open-source suite of tools. It comes with a lot of different GUI options. There's a RadMine Assistant that allows you to edit and view transcripts, which are basically portions of the file system. It also has a RadMine Assistant that allows you to run the command-line tools through a GUI interface, either creating overloads, which, again, would be, say, a particular application install.

They have some command-line interface tools. Two notable ones are FSDiff, File System Differences, LApply, LoadSetApply. RadMine is a very powerful tool. It can be used from the overall distribution. It can be used from tracking to also file system management. One thing to note about RadMine, it runs as a tripwire, and it can also detect differences and restore the machine base to that managed state. So it's a really useful tool if you're worried about security. The flexible runtime.

RadMine's command-line tools, it's basically dependent on how you want to script the tools, but we run it manually, start up, log in, schedule, single user mode, and conditional. So if you have certain areas of the file system that have been touched, you could actually have RadMine start running and restore the machine to a default state.

Next, we want to just highlight why you want to test when you're setting up your application. First, different environments, different tools you use to capture the install. You might run into certain issues depending on which tools you use to track the installation. So it's usually useful to have a test machine and another machine that you deploy the tool to.

Same thing with distribution methods. A lot of people use, there's a large variety of different methods from ASR using GUI front-ends like NetInstall, etc. And there's other tools like RSyncX and RadMine or just manually going around using either NetInstall or Apple Remote Desktop installing. Each of these methods might cause some problems when you're distributing. So you want to also have a machine to test those on. Things to test, a lot of these are kind of obvious, but a lot of times people forget to test these.

When you distribute application, you want to make sure help works, printing, spell check, you know, the pretty global options. And then if you have notable features of the application, you want to test. Also, if the application has any integration, so for example, iLife, you want to make sure you don't break that integration by customizing or modifying the application install.

So, we've covered a lot today, and I know that some of it probably went by pretty fast, so we're going to tell you where you can get more information. First of all, for Richard and my information, both of it's up there. That's our email addresses. We'll try to answer your question as best we can.

The other place that you should know about is MacOSXlabs.org. Both of us actually participate in this. We've written a white paper which actually talks about many of these issues and goes into more detail so that you actually have the time to look at it. There's also a website that we will try to keep more up-to-date than the white paper because it's just too hard to keep the white paper up-to-date all the time. And then Richard's institution, the University of Utah, has an application deployment problems and solutions pages which talks about applications that they've found which may or may not work particularly well in an enterprise.