Chapter 3. Setting up Netatalk

Table of Contents

Appletalk
To use AppleTalk or not
No AppleTalk routing
atalkd acting as an AppleTalk router
File Services
Setting up the AFP file server
Printing
Setting up the PAP print server
Using AppleTalk printers
Time Services
Using Netatalk as a time server for Macintoshs
Starting and stopping Netatalk

Appletalk

AppleTalk, the network protocol family founded by Apple, contains different protocols for different uses (address resolution, address/name mapping, service location, establishing connections, and the like)

A complete overview can be found inside the developer documentation

To use AppleTalk or not

You'll need the AppleTalk support built into netatalk in case you want to provide printing services via PAP by papd(8) or file services via AppleTalk via afpd(8) for older AFP clients not capable of using AFP over TCP. You'll need it also, if you want to use the deprecated AppleTalk-based timeserver timelord(8) for older Mac clients

But even if you don't need PAP or AFP over AppleTalk, you might consider using AppleTalk for service propagation/location, having the ease of use for your network clients in mind. The Apple engineers implemented a way to easily locate an AFP server via AppleTalk but establishing the AFP connection itself via AFP over TCP (see the developer documentation for details on this cool feature, too)

To use the different base AppleTalk protocols with netatalk, one has to use atalkd(8). It can also be used as an AppleTalk router to connect different independent network segments to each other.

To use AppleTalk/atalkd, your system has to have kernel support for AppleTalk. On some systems, that netatalk supports, this isn't currently true (notably True64 Unix) so you can use only netatalk services that do not rely on AppleTalk (which means "AFP over TCP" and requires the -noddp switch in afpd.conf )

No AppleTalk routing

This is the most simple form, you can use AppleTalk with netatalk. In case, you have only one network interface up and running, you haven't to deal with atalkd's config at all: atalkd will use AppleTalk's self-configuration features to get an AppleTalk address and to register itself in the network automagically.

In case, you have more than one active network interface, you have to make a decision:

  • Using only one interface: You've to add the interface's name (en1, le0, eth2, ... for example) to atalkd.conf on a single line. Do only list one here.

    Example 3.1. atalkd.conf containing one entry

    eth0

    Appletalk networking should be enabled on eth0 interface. All the necessary configuration will be fetched from the network

    After startup, atalkd will add the real settings (address and network and eventually a zone) to atalkd.conf on its own

    Example 3.2. atalkd.conf containing one entry after atalkd started

    eth0 -phase 2 -net 0-65534 -addr 65280.166

    atalkd filled in the AppleTalk settings that apply to this network segment. A netrange of 0-65534 is a sign that there is no AppleTalk router present, so atalkd will fetch an address that matches the following criteria: netrange from inside the so called "startup range" 65280-65533 and a node address between 142 and 255

  • When using several interfaces you have to add them line by line following the "-dontroute" switch in atalkd.conf

    Example 3.3. atalkd.conf containing several entries with the -dontroute option

    eth0 -dontroute
    eth1 -dontroute
    eth2 -dontroute

    Appletalk networking should be enabled on all three interfaces but no routing should be done between the different segments. Again, all the necessary configuration will be fetched from the connected networks

    Example 3.4. atalkd.conf containing several entries with the -dontroute option after atalkd started

    eth0 -dontroute -phase 2 -net 0-65534 -addr 65280.152
    eth1 -dontroute -phase 2 -net 0-65534 -addr 65280.208
    eth2 -dontroute -phase 2 -net 1-1000 -addr 10.142 -zone "Printers"

    On eth0 and eth1 no other routers are present, so atalkd chooses an address from within the startup range. But on eth2 there lives an already connected AppleTalk router, publishing one zone called "Printers" and forcing clients to assign theirselves an address in a netrange between 1 and 1000

    In this case atalkd will handle each interface as it would be the only active one. This can have some side effects when it comes to the point where AFP clients want to do the magic switch from AppleTalk to TCP, so use this with caution

In case, you have more than one active network interface and do not take special precautions as outlined above, then autoconfiguration of the interfaces might fail in a situation where one of your network interfaces is connected to a network where no other active AppleTalk router is present and supplies appropriate routing settings.

For further information see atalkd.conf(5) and the developer documentation

atalkd acting as an AppleTalk router

There exist several types of AppleTalk routers: seed, non-seed and so called soft-seed routers.

  • A seed router has its own configuration and publishes this into the network segments it is configured for

  • A non-seed router needs a seed router on the interface to which it is connected to learn the network configuration. So this type of AppleTalk router can work completely without manual configuration.

  • A so called soft-seed router is exactly the same as a non-seed router except the fact, that it can also remember the configuration of a seed router and act as a replacement in case, the real seed router disappears from the net.

Netatalk's atalkd can act as both a seed and a soft-seed router, even in a mixed mode, where it acts on one interface in this way and on the other in another.

If you leave your atalkd.conf completely empty or simply add all active interfaces line by line without using seed settings (atalkd will act identically in both cases) then atalkd is forced to act as a soft-seed router on each interface, so it will fail on the first interface, where no seed router is accessible to fetch routing information from.

In this case other services, that depend on atalkd, might also fail.

So you should have atalkd act as a seed router on one or all active interfaces. A seed router has to supply informations about:

  • The specific netrange on this segment

  • The own AppleTalk address

  • The zones (one to many) available in this segment

  • The so called "default zone" for this segment

Unless you are the network admin yourself, consider asking her/him before changing anything related to AppleTalk routing, as changing these settings might have side effects for all of your AppleTalk network clients

In an AppleTalk network netranges have to be unique and must not overlap each other. Fortunately netatalk's atalkd is polite enough to check whether your settings are in conflict with already existing ones on the net. In such a case it simply discards your settings and tries to adapt the already established ones on the net (if in doubt, always check syslog for details).

Netranges, you can use, include pretty small ones, eg. 42-42, to very large ones, eg. 1-65279 - the latter one representing the maximum. In routed environments you can use any numbers in the range between 1 and 65279 unless they do not overlap with settings of other connected subnets.

The own AppleTalk address consists of a net part and a node part (the former 16 bit, the latter 8 bit, for example 12057.143). Apple recommends using node addresses of 128 or above for servers, letting client Macs assign themselves an address faster (as they will primarily search for a node address within 1-127 in the supplied netrange). As we don't want to get in conflict with Apple servers, we prefer using node addresses of 142 or above.

AppleTalk zones have nothing to do with physical networks. They're just a hint for your client's convenience, letting them locate network ressources in a more comfortable/faster way. You can either use one zone name accross multiple physical segments as well as more than one zone name on a single segment (and various combinations of this)

So all you have to do is to draw a network chart containing the physical segments, the netranges you want to assign to each one, the zone names you want to publish in which segments and the default zone per segment (this is always the first zone name, you supply with the "-zone" switch in atalkd.conf)

Given, you finished the steps outlined above, you might want to edit atalkd.conf to fit your needs.

You'll have to set the following options in atalkd.conf:

  • -net (use reasonable values between 1-65279 for each interface)

    In case, this value is suppressed but -addr is present, the netrange from this specific address will be used

  • -addr (the net part must match the -net settings if present, the node address should be between 142 and 255)

  • -zone (can be used multiple times in one single line, the first entry is the default zone)

Note that you are able to set up "zone mapping", that means publishing exactly the same zone name on all AppleTalk segments, as well as providing more than one single zone name per interface. Dumb AppleTalk devices, like LaserWriters, will always register themselves in the default zone (the first zone entry you use in atalkd.conf per interface), more intelligent ones will have the ability to choose one specific zone via a user interface.

Example 3.5. atalkd.conf making netatalk a seed router on two interfaces

eth0 -seed -phase 2 -net 1-1000 -addr 1000.142 -zone "Printers" -zone "Spoolers"
eth1 -seed -phase 2 -net 1001-2000 -addr 2000.142 -zone "Macs" -zone "Servers"

The settings for eth0 force AppleTalk devices within the connected network to assign theirselves an address in the netrange 1-1000. Two zone names are published into this segment, "Printers" being the so called "standard zone", forcing dumb AppleTalk devices like Laserprinters to show up automatically into this zone. AppleTalk printer queues supplied by netatalk's papd can be registered into the zone "Spoolers" simply by adjusting the settings in papd.conf(5). On eth1 we use the different and non-overlapping netrange 1001-2000, set the default zone to "Macs" and publish a fourth zone name "Servers".

Example 3.6. atalkd.conf configured for "zone mapping"

eth0 -seed -phase 2 -net 1-1000 -addr 1000.142 -zone "foo"
lo0 -phase 1 -net 1 -addr 1.142 -zone "foo"

We use the same network settings as in the example above but let atalkd publish the same zone name on both segments. As the same zone name will be used on all segments of the AppleTalk network no zone names will show up at all... but AppleTalk routing will still be active. In this case, we connect a so called "non-extended" LocalTalk network (phase 1) to an EtherTalk "extended" network (phase 2) transparently.

Example 3.7. atalkd.conf for a soft-seed router configuration

eth0
eth1
eth2

As we have more than one interface, atalkd will try to act as an AppleTalk router between both segments. As we don't supply any network configuration on our own we depend on the availability of seed routers in every connected segment. If only one segment is without such an available seed router the whole thing will fail.

Example 3.8. atalkd.conf for a soft-seed router configuration after atalkd started

eth0 -phase 2 -net 10-10 -addr 10.166 -zone "Parking"
eth1 -phase 2 -net 10000-11000 -addr 10324.151 -zone "No Parking" -zone "Parking"
eth2 -phase 2 -net 65279-65279 -addr 65279.142 -zone "Parking" -zone "No Parking"

In this case, active seed routers are present in all three connected networks, so atalkd was able to fetch the network configuration from them and, since the settings do not conflict, act as a soft-seed router from now on between the segments. So even in case, all of the three seed routers would disappear from the net, atalkd would still supply the connected network with the network configuration once learned from them. Only in case, atalkd would be restarted afterwards, the routing information will be lost (as we're not acting as seed router).

Example 3.9. atalkd.conf ready for mixed seed/soft-seed mode

eth0
eth1 -seed -phase 2 -net 99-100 -addr 99.200 -zone "Testing"

In case in the network connected to eth0 lives no active seed router or one with a mismatching configuration (eg. an overlapping netrange of 1-200) atalkd will fail. Otherwise it will fetch the configuration from this machine and will route between eth0 and eth1, on the latter acting as a seed router itself.

By the way: it is perfectly legal to have more than one seed router connected to a network segment. But in this case, you should take care that the configuration of all connected routers is exactly the same regarding netranges, published zone names and also the "standard zone" per segment

File Services

Netatalk supplies two different transport protocols for AFP services and both can run at the same time. Classic AFP over AppleTalk requires the afpd and atalkd daemons. AFP over IP only requires afpd.

Setting up the AFP file server

AFP (the Apple Filing Protocol) is the protocol Apple Macintoshs use for file services. The protocol has evolved over the years, at the time of this writing 7 different "versions" exist. The latest changes to the protocol, called "AFP 3.1", were added with the release of Panther (Mac OS X 10.3).

AFP3 brought some big changes. For the first time, AppleShare Clients can use filenames up to 255 characters (actually 255 bytes leading to 85-255 chars depending on the glyphs used), UTF-8 is used on the wire and large files (>4GB) are supported.

The afpd deamon offers the fileservices to Apple Clients. It's configured using the afpd.conf and the AppleVolumes.* files.

afpd.conf

afpd.conf is the configuration file used by afpd to determine the behavior and configuration of the different virtual file servers that it provides. Any line not prefixed with '#' is interpreted.

If afpd switches set on the command line are in conflict with afpd.conf settings, the latter will have higher priority

Format: - [options] to specify options for the default server and/or "Server name" [options] to specify an additional server

Leaving the afpd.conf file empty equals to the following configuration:

- -transall -uamlist uams_guest.so,uams_clrtxt.so,uams_dhx.so -nosavepassword

For a more detailed explanation of the available options, please refer to the afpd.conf(5) man page.

AppleVolumes.default

The AppleVolumes.default file is used to define volumes that will by default be shown to all users, including users logged in as guest. A volume will not be presented in the chooser, if the user has no read access to the specified volume path.

You can limit access to a specific volume by using the allow and deny options.

For a more detailed explanation of the available options, please refer to the AppleVolumes.default(5) man page.

CNID backends

Unlike other protocols like smb or nfs, the AFP protocol mostly refers to files and directories by ID and not by a path. A typical AFP request uses a directory ID and a filename, something like "server, please open the file named 'Test' in the directory with id 167". For example "Aliases" on the Mac basically work by ID (with a fallback to the absolute path in more recent AFP clients. But this applies only to Finder, not to applications).

Every file in an AFP volume has to have a unique file ID, IDs must, according to the specs, never be reused, and IDs are 32 bit numbers (Directory IDs use the same ID pool). So, after ~4 billion files/folders have been written to an AFP volume, the ID pool is depleted and no new file can be written to the volume. No whining please :-)

Netatalk needs to map IDs to files and folders in the host filesystem. To achieve this, several different CNID backends are available. A CNID backend is basically a database storing ID <-> name mappings.

In the past, many users used the so called "last" CNID scheme. However, this scheme has some serious drawbacks, as it is based on the device and inode of a file. Therefore, IDs will be eventually be reused and you can get duplicate IDs as well.

The CNID Databases are by default located in the .AppleDB folder in every afpd volume root. With the new ADv2 format, afpd stores the files/directories ID in the corresponding .AppleDouble file as well.

Note

There are some CNID related things you should keep in mind when working with netatalk:

  • Don't use unix symlinks. Just don't. With a symlink a file/directory "exists" twice, something AFP doesn't allow. There's currently no way this can be resolved, as we either end up with two file/dirs having the same id, or a file having two parents. If you still insist on using them, be aware you're heavily violating the specs. You have been warned...

  • Don't nest volumes.

  • CNID backends are databases, so they turn afpd into a file server/database mix. Keep this in mind, killing an afpd process with kill -9 will likely leave the database unusable.

  • If there's no more space on the filesystem left, the database will get corrupted. You can work around this by either using the -dbpath option and put the database files into another location or, if you use quotas, make sure the .AppleDB folder is owned by a user/group without a quota.

  • Be careful with CNID databases for volumes that are mounted via NFS. That is a pretty audacious decision to make anyway, but putting a database there as well is really asking for trouble, i.e. database corruption. Use the dbpath: directive in the AppleVolumes.* configuration files to put the databases onto a local disk if you must use NFS mounted volumes.

cdb

The "concurrent database" backend is based on sleepycat's Berkeley DB. With this backend several afpd deamons access the CNID database directly. Berkeley DB locking is used to synchronize access, if more than one afpd process is active for a volume. The drawback is, that the crash of a single afpd process might corrupt the database.

dbd

Access to the CNID database is restricted to the cnid_dbd daemon process. afpd processes communicate with the daemon for database reads and updates. If built with Berkeley DB transactions the probability for database corruption is practically zero, but performance can be slower than with cdb. As a database process gets spawned for each volume, you're probably better off using cdb for sharing home directories for a larger number of users.

last

The last backend is a semi persistent backend. ID's will be reused and, what is much worse, you can get duplicate IDs. You should use it for sharing cdroms only, don't use it for sharing normal volumes.

Charsets/Unicode

Why Unicode?

Internally computers don't know anything about characters and texts, they only know numbers. Therefore, each letter is assigned a number. A character set, often referred to as charset or codepage, defines the mappings between numbers and letters.

If two or more computer systems need to communicate with each other, the have to use the same charater set. In the 1960s the ASCII (American Standard Code for Information Interchange) character set was defined by the American Standards Association. The original form of ASCII represented 128 characters, more than enough to cover the English alphabet and numerals. Up to date, ASCII has been the normative character scheme used by computers.

Later versions defined 256 characters to produce a more international fluency and to include some slightly esoteric graphical characters. Using this mode of encoding each character takes exactly one byte. Obviously, 256 characters still wasn't enough to map all the characters used in the various languages into one character set.

As a result localized character sets were defined later, e.g the ISO-8859 character sets. Most operating system vendors introduced their own characters sets to satisfy their needs, e.g. IBM defined the codepage 437 (DOSLatinUS), Apple introduced the MacRoman codepage and so on. The characters that were assigned number larger than 127 were referred to as extended characters. These character sets conflict with another, as they use the same number for different characters, or vice versa.

Almost all of those characters sets defined 256 characters, where the first 128 (0-127) character mappings are identical to ASCII. As a result, communication between systems using different codepages was effectivly limited to the ASCII charset.

To solve this problem new, larger character sets were defined. To make room for more character mappings, these character sets use at least 2 bytes to store a character. They are therefore referred to as multibyte character sets.

One standardized multibyte charset encoding scheme is known as unicode. A big advantage of using a multibyte charset is that you only need one. There is no need to make sure two computers use the same charset when they are communicating.

character sets used by Apple

In the past, Apple clients used single-byte charsets to communicate over the network. Over the years Apple defined a number of codepages, western users will most likely be using the MacRoman codepage.

Codepages defined by Apple include:

  • MacArabic, MacFarsi

  • MacCentralEurope

  • MacChineseSimple

  • MacChineseTraditional

  • MacCroation

  • MacCyrillic

  • MacDevanagari

  • MacGreek

  • MacHebrew

  • MacIcelandic

  • MacKorean

  • MacJapanese

  • MacRoman

  • MacRomanian

  • MacThai

  • MacTurkish

Starting with Mac OS X and AFP3, UTF-8 is used. UTF-8 encodes Unicode characters in an ASCII compatible way, each Unicode character is encoded into 1-6 ASCII characters. UTF-8 is therefore not really a charset itself, it's an encoding of the Unicode charset.

To complicate things, Unicode defines several normalization forms. While samba uses precomposed Unicode, which most Unix tools prefer as well, Apple decided to use the decomposed normalization.

For example lets take the German character 'ä'. Using the precomposed normalization, Unicode maps this character to 0xE4. In decomposed normalization, 'ä' is actually mapped to two characters, 0x61 and 0x308. 0x61 is the mapping for an 'a', 0x308 is the mapping for a COMBINING DIAERESIS.

Netatalk referres to precomposed UTF-8 as UTF8 and to decomposed UTF-8 as UTF8-MAC.

afpd and character sets

To support new AFP 3.x and older AFP 2.x clients at the same time, afpd needs to be able to convert between the various charsets used. AFP 3.x clients always use UTF-8, AFP 2.2 clients use one of the Apple codepages.

At the time of this writing, netatalk supports the following Apple codepages:

  • MAC_CENTRALEUROPE

  • MAC_CYRILLIC

  • MAC_HEBREW

  • MAC_ROMAN

  • MAC_TURKISH

afpd handles three different character set options:

unixcodepage

This is the codepage used internally by your operating system. If not specified and your system support Unix locales, afpd tries to detect the codepage, otherwise it defaults to ASCII. afpd uses this codepage to read its configuration files, so you can use extended characters for volume names, login messages, etc. see afpd.conf(5)

maccodepage

As already mentioned, older MacOS clients ( up to AFP 2.2) use codepages to communicate with afpd. However, there is no support for negotiating the codepage used by the client in the AFP protocol. If not specified otherwise, afpd assumes the MacRoman codepage is used. In case you're clients use another codepage, e.g. MacCyrillic, you'll have to explicitly configure this. see afpd.conf(5)

volcharset

This defines the charset afpd should use for filenames on disk. The default is UTF8. If you have iconv installed, you can use any iconv provided charset as well.

afpd needs a way to preserve extended macintosh characters, or characters illegal in unix filenames, when saving files on a unix filesystem. Earlier versions used the the so called CAP encoding. An extended character (>0x7F) would be converted to a :xx hex sequence, e.g. the Apple Logo (MacRoman: 0XF0) was saved as :f0. Some special characters will be converted as to :xx notation as well. '/' will be encoded to :2f, if -usedots is not specified, a leading dot '.' will be encoded as :2e. Even though this version now uses UTF-8 as the default encoding for filenames, special characters, like '/' and a leading '.' will still be CAP style encoded . For western users another useful setting could be -volcharset ISO-8859-15.

If a character cannot be converted from the mac codepage to the selected volcharset, afpd will save it as a CAP encoded character. For AFP3 clients, afpd will convert the UTF-8 character to maccodepage first. If this conversion fails, you'll receive a -50 error on the mac. Note: Whenever you can, please stick with the default UTF-8 volume format. see AppleVolumes.default(5)

Printing

Netatalk can act as both a PAP client to access AppleTalk-capable printers and a PAP server. The former by using the pap(1) utility and the latter by starting the papd(8) service.

The "Printer Access Protocol" as part of the AppleTalk protocol suite is a fully 8 bit aware and bidirectional printing protocol, developed by Apple in 1985. 8 bit aware means that the whole set of bytes can be used for printing (binary encoding). This has been a great advantage compared with other protocols like Adobe's Standard Protocol to drive serial and parallel PostScript printers (compare with Adobe TechNote 5009) or LPR which made only use of the lower 128 bytes for printing because the 8th bit has been reserved for control codes.

Bidirectional means that printing source (usually a Macintosh computer) and destination (a printer or spooler implementation) communicate about both destination's capabilities via feature queries (compare with Adobe TechNote 5133) and device status. This allows the LaserWriter driver on the Macintosh to generate appropriate device specific PostScript code (color or b/w, only embetting needed fonts, and so on) on the one hand and notifications about the printing process or problems (paper jam for example) on the other.

Setting up the PAP print server

Netatalk's papd is able to provide AppleTalk printing services for Macintoshes or, to be more precise, PAP clients in general. Netatalk does not contain a full-blown spooler implementation itself, papd only handles the bidirectional communication and submittance of printjobs from PAP clients. So normally one needs to integrate papd with a Unix printing system like eg. classic SysV lpd, BSD lpr, LPRng, CUPS or the like.

Since it is so important to answer the client's feature queries correctly, how does papd achieve this? By parsing the relevant keywords of the assigned PPD file. That said, it's always necessary to carefully choose the right PPD at the server's side.

Netatalk had built-in support for System V lpd printing in a way that papd saved the printed job directly into the spooldir and calls lpd afterwards, to pick up the file and do the rest. Due to incompatibilities with many lpd implementations the normal behaviour was to print directly into a pipe instead of specifying a printer by name and using lpd interaction. With Netatalk 2.0 another alternative has been implemented: directly integrating with CUPS (Note: when CUPS support is compiled in, then the SysV lpd support doesn't work at all). Detailed examples can be found in the papd.conf(5) manual page.

Integrating papd with SysV lpd

Unless CUPS support has been compiled in (which is default from Netatalk 2.0 on) one simply defines the lpd queue in question by setting the pr parameter to the queue name, in the following example "ps". If no pr parameter is set, the default printer will be used.

Using pipes with papd

An alternative to the technique outlined above is to direct papd's output via a pipe into another program. Using this mechanism almost all printing systems can be driven. Netatalk supplies three "wildcards" that get substituted with values of the already printed job:

%F

will be substituted with the contents of the %%For: comment in the PostScript stream.

%U

If authenticated printing has been enabled then this will be substituted with the user name of the printjob's originator.

%J

will be substituted with the contents of the %%Title: comment of the PostScript stream.

Using these wildcards, one can pass those parameters directly to programs or implement small wrapper scripts to call the printing system in question.

Using direct CUPS support

Starting with Netatalk 2.0 direct CUPS integration is available. In this case, defining only a queue name as pr parameter won't invoke the SysV lpd daemon but uses CUPS instead. Unless a specific PPD has been assigned using the pd switch, the PPD configured in CUPS will be used by papd, too.

There exists one special share named "cupsautoadd". If this is present as the first entry of papd.conf then all available CUPS queues will be served automagically using the parameters assigned to this global share. But subsequent printer definitions can be used to override these global settings for individual spoolers.

Using AppleTalk printers

Netatalk's papstatus(8) can be used to query AppleTalk printers, pap(1) to print to them. With psf(8) there exists a lpd filter program suitable for converting other formats (like text) to PostScript output, do page accounting and eventually change the page order using psorder(1). But these days, modern printing systems like CUPS can do the latter tasks for themselves in a more realiable way.

pap can be used stand-alone or as part of an output filter or a CUPS backend (which is the preferred method since one does not have to deal with all the options).

Example 3.10. pap printing to a PostScript LaserWriter

pap -p"ColorLaserWriter 16/600@*" /usr/share/doc/gs/examples/tiger.ps

The file /usr/share/doc/gs/examples/tiger.ps is sent to a printer called "ColorLaserWriter 16/600" in the standard zone "*". The device type is "LaserWriter" (can be suppressed since it is the default).

Example 3.11. pap printing to a non-PostScript printer

gs -q -dNOPAUSE -sDEVICE=cdjcolor -sOutputFile=- test.ps | pap -E

GhostScript is used to convert a PostScript job to PCL3 output suitable for a Color DeskWriter. Since no file has been supplied on the command line, pap reads the data from stdin. The printer's address will be read from the .paprc file in the same directory, pap will be called (in our example simply containing "Color DeskWriter:DeskWriter@Printers"). The -E switch forces pap to not wait for an EOF from the printer.

Time Services

Using Netatalk as a time server for Macintoshs

"timelord", an AppleTalk based time server, is deprecated these days. Use NTP instead.

Starting and stopping Netatalk

The Netatalk distribution comes with several operating system specific startup script templates that are taylored according to the options given to the "configure" script before compiling. Currently, templates are provided for Netbsd, Bsd, Redhat, Suse and True64. You can select to install the generated startup script(s) by specifying a system type to "configure". To automatically install startup scripts for e.g. the Suse Linux distribution try to give the --enable-suse option to "configure". Some of the scripts can be further parametrized by the configuration file netatalk.conf (described in the netatalk.conf(5) manual page), some obtain that information in another, operating system specific way (like Netbsd).

Since new releases of Linux distributions appear all the time and the startup procedure for the other systems mentioned above might change as well, it is probably a good idea to not blindly install a startup script but to look at it first to see if it will work on your system. If you use Netatalk as part of a fixed setup, like a Linux distribution, an RPM or a BSD package, things will probably have been arranged properly for you. The following therefore applies mostly for people who have compiled Netatalk themselves.

The following daemons need to be started by whatever startup script mechanism is used:

  • atalkd (if you use the AppleTalk protocol)

  • afpd

  • cnid_metad (if the dbd CNID backend is used)

  • papd (if you want to provide print services via AppleTalk)

  • timelord (for old style time synchronisation via AppleTalk)

Additionally, make sure that the various configuration files (afpd.conf, AppleVolumes.default, papd.conf etc.) are in the right place and that netatalk.conf (if used) contains the right entries. If you want e.g. papd to be started using this mechanism, set the environment variable "PAPD_RUN" to "yes" in netatalk.conf. See the manual pages for details.