|< Day Day Up >|
Locating the Mac OS X Configuration Files
Locating Mac OS X configuration files and figuring out what can be put in them can sometimes be a bit of an adventure. It's difficult to determine the correct information to provide for some items in this chapter. Many configuration options and files that exist in Mac OS X are not actually intended for you to use in the Mac OS X client version. These parts of the configuration system are actually managed by tools provided only (for the moment, at least) by Mac OS X Server. It's possible to diddle around with them, and to do some interesting things, but Mac OS X doesn't provide the tools or the information to do a complete job of documentation or configuration. We'll do our best to provide you with up-to-the-minute information on what's been discovered to be tweakable in the system as of when this book hits the shelves. Do check online information sources such as http://www.macosxunleashed.com/ and http://www.macosxhints.com/, and understand that it seems clear that Apple doesn't intend for the user to ever understand or modify some of these things.
Unlike previous versions of Mac OS, which kept almost all its preferences in the Preferences folder of the System folder, Mac OS X keeps its preferences in several different locations. Primarily these are the /etc/ folder, the NetInfo database, the /System/Library/LaunchDaemons/ folder and the ~/Library/Preferences/ folders. Many preferences that affect the running of the system, such as what network services are started, the machine name, and global information that does not change from login to login, are kept in the /etc/ folder or its subfolders or in /System/Library/LaunchDaemons/. Other preferences of this nature are kept in the NetInfo database. Preferences that affect individual user configuration are primarily kept in files stored in ~/Library/Preferences/.
Preferences stored in files in the /etc/ directory generally follow long-standing Unix tradition and are formatted according to their own individual file formats. The /etc/inetd.conf and /etc/xinetd.d files are discussed in depth later in the chapter.
Other /etc/ directory preference and configuration files that you should be familiar with are
All these files use specific configuration formats rooted in Unix tradition and documented in the man pages. In Mac OS X, these files are directly used only in single-user mode because Apple has replaced their use with databases from NetInfo. Learning about them isn't completely irrelevant, though. It's often much easier to load the NetInfo database from these files with well-defined formats than it is to enter the data directly into NetInfo. In Chapter 20, we show how to use the traditional /etc/ configuration file formats to load data into NetInfo.
You might also want to be familiar with the formats for /etc/fstab and /etc/exports. These files traditionally control the mounting of disks and the serving of disks, respectively. Apple, however, doesn't seem to use them even in single-user mode. But the NetInfo server can load data from these file formats, so it might be useful to learn them if you will be interacting with other types of Unix machines.
One of the more significant /etc/ preferences files in Mac SO X, however, is not a common file in the Unix world. This file, /etc/hostconfig, contains a number of variable assignments that provide information to assorted programs that run on your behalf. We will also take an in-depth look at this file later in the chapter.
Files contained in /System/Library/LaunchDaemons and in ~/Library/Preferences are mostly stored in XML (Extensible Markup Language), an emerging data storage standard. Readers familiar with HTML (Hypertext Markup Language) will find many similarities in the structure of the HTML document and of documents written in XML. The primary differences are that HTML is intended to be (but has wandered away from being) a structurally tagged language in a specified tag set, whereas XML is a language in which structural tagging can be arbitrarily defined. Specifically, these preferences are stored as plist files, which are XML files with unstructured data about a file or application.
For those unfamiliar with either language, both are essentially languages in which the content of a document is indicated by surrounding content items with tags. The beginning tag is usually of the form <TAGNAME>, where the < and > are required parts of the tag. The ending tag is of the form </TAGNAME> where the TAGNAME part of the begin/end pair must match. Tags in both languages can be nested, but neither supports tag pairs that overlap. (That is, <TAG1> some data <TAG2> more data</TAG1> and more data</TAG2> is not acceptable.) HTML has a defined set of tags that are part of the language, but XML is actually a language in which arbitrary tags can be defined. HTML tags also imply to a browser that the data enclosed by the tags has certain intended display characteristics. XML tags, however, imply only document structure and require an additional style definition to provide display properties. Finally, through design and through degeneration by lack of standards, HTML has come to include a number of tags with purposes and syntaxes outside the logic described earlier. For example, HTML allows "half tags" for certain types of tags because it uses some tags exclusively for display control, rather than for structural tagging. HTML's <P> (paragraph) tag, for instance, can be used alone with no closing </P> tag because it specifies only that the browser should move down and start a new line with the next text. It does not delimit the boundaries of a paragraph.
Where HTML allows implicitly closed tags for items such as <P> (paragraph), XML requires explicitly closed tags. For completely nonenclosing tags, such as HTML's <HR> tag (horizontal line), XML substitutes a tag type that is understood to open and close itself in the statement. The XML equivalent would look like <HR/>, which is read by the parser as <HR></HR>. Apple uses this type of tagging frequently in its XML preferences files.
The plist files can contain portions that aren't human readable or easily guessable as to how they relate to preference settings. The plist files are more readable using the Property List Editor that is included in the Developer Tools. If you would like to learn more about property lists, check http://developer.apple.com/documentation/CoreFoundation/Conceptual/CFPropertyLists/index.html.
|< Day Day Up >|