Admin Artistry

In addition to the maintenance-related tasks I've been talking about, there are a few other tips I'd like to point out that are administrator-related; specifically, how to schedule events and actions, how to adjust application priorities, and how to better work with OS X's log files.

Automating Admin Actions

User Level:

normal or admin

Affects:

user or computer

Terminal:

possibly

I mentioned earlier in the chapter that OS X's cleanup scripts are run by the Unix utility cron. This utility runs in the background whenever your computer is running. Every minute, it checks schedules called crontabs (short for cron tables) to see if any command or script is supposed to be run at that time; if it finds one (or more), it runs them. Although most users don't even realize that cron exists, now that you do, you can use it to your advantage.

In theory, cron can only execute commands that you would type into Terminal; however, since you can run complex shell scripts from the command line, cron can launch them, too. In addition, OS X includes a special Terminal command, open, that allows you to open any file or document as if you'd double-clicked on it in the Finder. This adds a whole 'nother level of power to the cron utility—AppleScripts can be saved as stand-alone applications, and can themselves run shell scripts, so the cron utility in OS X can schedule and automate pretty much anything you want to do in the Finder, in scriptable applications, and in Terminal (the shell)—or any combination of the three.

I'm not going to get into super-complex shell/AppleScript automation here, but I do want to give you a few (simple) examples of how you might take advantage of cron on your own computer. Because cron is a command-line program, its syntax can get pretty messy; however, like many other command-line applications in OS X, someone has put a nice face on it and made it easy to use. CronniX (http://www.koch-schmidt.de/cronnix/) is a donationware utility that lets you edit the system-level crontab, as well as additional user-level crontabs.

Note 

In general, you only want to edit the system's crontab in CronniX if you need to execute a command that requires root access. For all other uses, you should edit your own user-level crontab. If you're curious, the system's crontab is actually located at /etc/crontab; Individual user crontabs are located in /var/cron.

By choosing File Open System Crontab, you can view and edit the main system-level crontab (you'll need to provide your admin password to edit it). In addition, by choosing File Open for User and typing in a username, you can view and edit any user-level crontab (again, to edit another user's crontab, you'll need to provide your admin password).

Unless another utility has scheduled an event, your own user-level crontab is likely to be empty. To see what a crontab entry looks like, open your own crontab, and then choose File New Default Task. CronniX will create a new sample task that displays the text "Happy New Year!" (Figure 14.4).

click to expand
Figure 14.4: A sample crontab entry in CronniX

What this entry says is that at the time 0:00 (cron uses 24-hour time, so 0:00 is midnight), on the first day of the first month, the text "Happy New Year!" should be "displayed." (I put displayed in quotes because what really happens is that an e-mail message is sent to the local sendmail spool, which on most Macs isn't going to do anything you'll ever see. But at least it's a good example for seeing the format of a crontab entry in CronniX.) You can double-click on any field and edit its value; when you're finished editing, click the Save button in the toolbar.

Tip 

CronniX has an excellent online manual that I highly recommend reading at http://www.koch-schmidt.de/cronnix/docs/index.html.

If you're curious what a system-level crontab looks like, open the file /etc/crontab in a text editor (or type more /etc/crontab <RETURN> in Terminal, which is a bit easier). At the very least, it will contain three scheduled events:

     15   3   *   *   *   root   periodic daily     30   4   *   *   6   root   periodic weekly     30   5   1   *   *   root   periodic monthly 

If the names of the commands look familiar, it's because each of these lines is the schedule for the cleaning scripts I talked about earlier in the chapter; the periodic command runs scripts located in the daily, weekly, and monthly folders I pointed out. In fact, if you look at the first five columns, you'll see that they correspond to the minute, hour, day of the month, month, and day of the week fields in CronniX, and, in the context of those fields, correspond to the days and times I told you that these scripts are scheduled to run.

Here are a couple of examples of ways to use CronniX and cron that you might find useful.

Note 

As I previously mentioned, if your computer is asleep (or off), cron does not run, nor does it check to see if it "missed" any scheduled events while your computer was asleep or shutdown. So in order for an event to be executed, your computer must be running and awake at its scheduled execution time. (With respect to OS X's cleanup scripts, which don't get run if you turn your Mac off at night, if you're feeling adventurous you can use CronniX to edit their cron entries—via the System Crontab—so that they run during the day instead.)

Getting a Daily Report of Free Space

This is very simple example that shows you how you can run a command-line program using cron, and have its output saved to a text file. It may not be useful to you, but it's good for demonstration purposes. Suppose that you do a lot of work with big files, and you want to check how much room you have on your hard drive each morning. You could manually get info on the drive in the Finder, but wouldn't it be nice if your computer checked for you and put the results in a text file on your Desktop? Let's say, just for the sake of argument, that you think this is a neat idea. Here's how you can do it.

  1. Launch CronniX and choose File Open Crontab for User... and click Default. (You could also enter your own username and click Open).

  2. Choose File New Task. You'll be presented with an event editing sheet (Figure 14.5).

    click to expand
    Figure 14.5: Creating a new cron task in CronniX

  3. Choose the time you want the disk info to be gathered—if you want it to happen every day, check the boxes next to "Day of month" and "Month" (this tells cron you don't care what day of the month or month it is) and the Any box next to "Day of week." In my example in Figure 14.5, I told cron to execute the command every day at 9 A.M..

  4. In the command field, type /usr/sbin/diskutil info / > /Users/username/Desktop/ filename.txt, where username is your username, and filename is the name you want the output file saved as. The first part of this command, /usr/sbin/diskutil, is the path to the diskutil program (the same one you'd be using if you typed diskutil in Terminal). The info argument tells diskutil to get info on the drive specified (/ means the boot volume). Finally, the last part of the command specifies the name of the output file, and where it should be saved.

  5. Click New to create the new task.

  6. Click the Save button in the toolbar.

Now every morning at 9 A.M., a new text file will be created on your Desktop that contains information about the boot volume, including the amount of free space remaining. This is admittedly a very simple event, but it shows you the kind of things that you can do with cron.

Repairing Permissions Periodically

Earlier in the chapter I recommended periodically running OS X's Repair Disk Permissions functions to keep things running smoothly. You can actually use a simple AppleScript to run Repair Disk Permissions. However, since you can also run AppleScripts from the command line, you can actually schedule AppleScripts using cron. Here's how to have Repair Disk Permissions run automatically in the background, on a schedule you decide.

First, you need to create the AppleScript:

  1. Launch the Script Editor application (in /Applications/AppleScript).

  2. Create a new script by choosing File New Script, and then typing the following bit of AppleScript code into the lower text field (the upper field is for comments):

         do shell script     'sudo diskutil repairPermissions / >     /Users/username/Desktop/repairpermissions.txt'     password yourpassword with administrator privileges 

    where username is your username, and yourpassword is your admin password. (Those are three separate lines, starting with "do," "sudo," and "password.") This AppleScript executes a shell script (the text in quotes) that runs the Repair Disk Permissions utility and then saves the log of repairs to your Desktop in a file called "repairpermissions.txt." Since the utility requires administrator access to run, the AppleScript also provides your password.

  3. Choose File Save As In the Save dialog, select "Application" from the Format pop-up menu, and check the box next to Never Show Startup Screen. Give the AppleScript a name and save it to your ~/Applications folder.

Note 

I strongly recommend saving this script in your own Applications folder because it contains your admin password. Saving the script in a publicly accessible directory means that any other user could open the script and get your password.

The next thing to do is to create a new crontab entry for your script. Fortunately, using an AppleScript is much easier than entering a Terminal command:

  1. Open the System Crontab in CronniX and then drag your newly created script into the System Crontab window. A new event will be created that runs your script.

  2. Select the new event, and then click the Edit item in the toolbar to edit the event.

  3. In the Schedule section, select the times and days you want the script to be run. I personally have this script set to run once per week, which may be overkill. You can instead choose to run it once a month by checking the box next to Month (which tells cron to run the script regardless of the month) and entering a date (1–31) in the field to the right. (I recommend using 1–28, since using a date of 29, 30, or 31 means that the script won't run in months with fewer days.) In the Hour and Minute fields, enter a time of day that your computer is likely to be running (hours are in 24-hour format).

  4. Click Apply to apply your edits to the entry.

  5. Click the Save toolbar item to save your changes to the System Crontab; provide your admin password when prompted.

Adjusting Application Priorities

User Level:

normal or admin

Affects:

user or computer

Terminal:

no

One of the things that make OS X so much more powerful than OS 9 is that it doesn't allow a single application to monopolize your computer. The downside to this is that sometimes you want a single application to be able to monopolize your computer. For example, Connectix's Virtual PC (http://www.connectix.com/) emulates a complete Windows PC on your Mac, which takes a lot of processing power. To get the best performance possible, you want Virtual PC to be able to get as much of the processor as possible.

Unix allows an admin user to change application priorities—via the renice command—so that applications that are given higher priority can take more than their normal share of system resources, and those given lower priority have to wait in line, so to speak, until applications with higher priorities can spare some. Unfortunately, changing application priorities in Terminal is a bit messy; on the few occasions when I need to do it, I use a third-party utility like the freeware ProcessWizard (http://www.lachoseinteractive.net/) or the shareware Renicer (http://www.northernsoftworks.com/).

ProcessWizard is probably a better choice if you want to manually assign higher or lower priorities to specific applications. It sits in the menu bar, and when you click on its icon a sheet drops down listing all applications (or, via the pop-up menu, background apps, user-level system processes, or non-user system processes) (Figure 14.6). By dragging the slider next to a process to the right, you're increasing its priority; if you drag a slider to the left, that application's priority is reduced. (After changing a priority, you're asked for your admin password.)

click to expand
Figure 14.6: ProcessWizard lets you "renice" any running process.

Note 

Process/application priorities can range from -20 to 20, with zero being the default value for every process when it's first launched.

Renicer works a bit differently than ProcessWizard, and is what you should use if you want behavior similar to the way OS 9 used to work—that is, for the frontmost application to have the highest priority. When you launch Renicer and provide your admin password, it sits in the background and automatically increases the priority of the frontmost application, in order to increase its performance relative to other processes. When you switch to a different application, the prior application's priority is reset to zero, and the new frontmost application is "reniced" to a higher priority, and so on—the frontmost application will always have the highest priority. You can also specify particular applications so that they always get high priority, even when they're in the background (or so that they always get low priority, even when they're in the foreground). Finally, you can also choose the priority value given to the frontmost app, from 0 to 20, and the value given to "low priority" processes, from -20 to 0.

Looking over Log Files

User Level:

any

Affects:

NA

Terminal:

no

I mentioned in Chapter 7 that many applications, as well as OS X itself, generate logs of their activity. Although most of the time log files aren't too useful for the average user, if you're experiencing problems they sometimes provide information that can help you (or the developer of an application) track down the cause.

As I mentioned in Chapter 7, you can use OS X's Console application, as well as Apple System Profiler, to view log files. However, if you want a better interface (trust me, if you ever need to actually read these things, you want a better interface), the shareware LogMaster (http://www.nucleus.com/~fenn/soft.html) is a significant improvement over Console or Apple System Profiler (Figure 14.7). Logs are organized in groups, represented by icons (System, Apache, CUPS, Samba, CrashReporter, and User); within each group of logs, the pop-up menu on the right allows you to select a particular log to view.

click to expand
Figure 14.7: LogMaster provides advanced log viewing features.

Once you're viewing a log, you can choose to filter lines containing (or not containing) particular strings of text using the middle pop-up menu and text field. In addition, the text field on the right allows you to search for a text string; any lines in the log that contain that string will be highlighted. You can also select individual or multiple lines and then copy them for pasting into an e-mail or text document, or choose File Mail Log or Mail Selection to e-mail the entire log or just the highlighted portion. (You'll be asked for a recipient, title, and any comments, and then LogMaster will use the settings in the Email tab of Internet preferences to send the e-mail—you don't even need to have your e-mail client running.)

Finally, for advanced users LogMaster offers features like listen daemons that listen to a particular port and log incoming traffic, a web server that allows you to view logs in any web browser, and automated actions that are triggered when a specific string is detected in a new log entry.




Mac OS X Power Tools
Mac OS X Power Tools
ISBN: 0782141927
EAN: 2147483647
Year: 2005
Pages: 152
Authors: Dan Frakes

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net