Menu
▾
▴
[Netatalk-cvs] netatalk/doc README.AppleTalk, NONE, 1.1 README.platforms, 1.7, NONE
|
From: franklahm <fra...@us...> - 2010-03-30 14:11:58
|
Update of /cvsroot/netatalk/netatalk/doc In directory sfp-cvsdas-3.v30.ch3.sourceforge.com:/tmp/cvs-serv26407 Added Files: README.AppleTalk Removed Files: README.platforms Log Message: Rename README.platforms to README.AppleTalk as suggested by HAT --- README.platforms DELETED --- --- NEW FILE: README.AppleTalk --- This is a README for the major platforms where Netatalk is in use. Platforms Covered: A. Linux B. Tru64 C. Solaris D.I OpenBSD D.II Other BSDs E. SunOS F. Generic ---------------------------------------------------------------- A. Linux We no longer include linux kernel code with netatalk, since Linux now includes AppleTalk support. 1. MAKE CONFIG. Configure your kernel with "make config". Answer yes to "AppleTalk DDP" support. 2. INSTALL KERNEL. Make and install your kernel. Be sure to update your boot blocks! 3. Linux 2.2.x provides the sendfile() call. This reduces overhead when sending/copying files. This option will be autoconfigured on compile. NOTE: you might run into problems if you have this option compiled in and you switch to a machine running an os < 2.2.x. Netatalk supplies two different types of Appletalk servers and both can run at the same time. Classic Appletalk requires afpd and atalkd. Appletalk over IP only requires afpd. Classic Appletalk on GNU/Linux requires that CONFIG_ATALK is compiled into the kernel or as a kernel module. To check to see if the kernel has Appletalk installed: $> dmesg | grep Apple This just parses the boot messages for any line containing 'Apple'. To see all the loaded modules (as root): $> lsmod If you don't find it, you may have to compile a kernel and turn on Appletalk in Networking options -> Appletalk DDP. You have an option to install as a module or directly into the kernel. Some default distribution kernels have already compiled Appletalk DDP as a module, you may have to edit your /etc/modules.conf to include: "alias net-pf-5 appletalk ". Note: check your distribution documentation about editing /etc/modules.conf. For more complete information about the Linux kernel see the Kernel-HOWTO: http://www.linuxdoc.org/HOWTO/Kernel-HOWTO.html A note for RedHat users: You may need to install the glibc-devel package to be able to compile Netatalk correctly. ---------------------------------------------------------------- B. TRU64 This is the Tru64 README file for netatalk. 1. Unfortunately, AppleTalk is not available for Digital Unix or Tru64. The reason for this is the kernel patches which Netatalk requires cannot be ported to Tru64. If anyone has the kernel source of Tru64 they are welcomed to port the AppleTalk modules themselves. As a result, only AppleShare over IP (ASIP) works with Tru64. That is, the program afpd. papd and atalkd compile, but doesn't really work. Anything that requires AppleTalk doesn't work. 2. Netatalk compiles on Tru64 V4.0D or higher using either the built-in DEC C compiler or GCC V2.95.3. Also, either the Tru64 make command or GNU make can be used. Netatalk supports Tru64's Security Integration Architecture (SIA) and runs on machines configured for Base (BSD) or Enhanced (OSFC2) Security without recompilation. 3. A peculiar bug in Netatalk has been noticed on a single Tru64 machine. However, because other Tru64 machines have not affected, a patch will not be forthcoming until the circumstances where the bug hits is isolated and a more elegant and appropriate patch can be found. In the meantime, there is a description of the bug below. Any users affected can attempt the workarounds provided. The user is urged to report this to the mailing list so that this bug can be isolated and removed. HAVE_GCC_MEMCPY_BUG Description - It appears that memcpy() under Tru64 can fail under some circumstances. This maybe due to the fact that Netatalk is compiled with gcc, but since only gcc can compile Netatalk, this is a mute point. Symptoms - The symptoms of this bug is that a 18432 byte file uploaded to the server would upload correctly, but a 18433 byte file would result in a sparse file many megabytes big (16MB+). However, due to the low-level nature of memcpy(), there is no reason why other symptoms could not occur. Workarounds - There are two known workarounds at this stage. - The first is to #define the macro HAVE_GCC_MEMCPY_BUG. This forces netatalk to use bcopy() in a few (but not all) cases within the code and is enough to stop the bug from occurring. This is the easiest workaround and would merely alter the standard compilation steps to CFLAGS="-DHAVE_GCC_MEMCPY_BUG" ./configure [...] make make install - The second workaround is to manually remove the optimisation flag "-O2" from within configure and/or configure.in. Although, this isn't the preferred workaround, it shows that the compiler is (at least) partially at fault. ---------------------------------------------------------------- C. SOLARIS 1. SELECT COMPILER. This distribution is configured to build with gcc. It should also work with cc. At the present time only cc v5.0 and gcc 3.1 and above can build the 64-bit kernel module. 1a. SELECT KERNEL TYPE. Edit sys/solaris/Makefile.kernel and set KCFLAGS to include sparcv9 support if you run a 64-bit kernel, or leave it commented out for a 32-bit kernel. Only UltraSPARC systems running Solaris 7 and above support a 64-bit kernel. If you're not sure what kernel you use, run "isainfo -v". You're running a 64-bit kernel if the result includes 64-bit (sparcv9), otherwize it's 32-bit. NOTE: If you want both the 32-bit and 64-bit kernel modules to be installed, first compile and install the version appropriate to the kernel that you're currently running, then make clean, compile and install the other version. 2. EDIT NETCONFIG. Add the following line to /etc/netconfig: ddp tpi_clts - appletalk ddp /dev/ddp - This makes the socket library aware of the AppleTalk protocol family. 3. INSTALL DRIVER. Since the STREAMS ddp driver must be installed as root, we've separated that portion of the build. Type make -f Makefile.kernel kinstall to install the driver. This copies the driver and its config file into /usr/kernel/drv and /usr/kernel/strmod, runs "add_drv ddp" to make the kernel aware of the new driver, and adds an rc file to /etc/rc?.d. Watch out for error messages after it runs add_drv. If you see something like devfsadm: driver failed to attach: ddp Warning: Driver (ddp) successfully added to system but failed to attach then recheck sys/solaris/Makefile.kernel and/or try a different compiler. 4. ATALKD.CONF. Under Solaris, you must create atalkd.conf, since Solaris provides no method for determining the names of the available interfaces. It is sufficent to name the available interfaces in atalkd.conf, one per line. E.g. le0 on a line by itself on many Suns. hme0 on Ultras. See atalkd(8). 5. PRINTING. Netatalk can use any postscript printer that has been set up for use by Solaris. If you haven't already set up a printer, type admintool then select Browse --> Printers, and then Edit --> Add and fill in the form for either a local or remote printer. If adding a local printer, set the Printer Type to PostScript. Then find a postscript file and test your printer from the command line. For example if you created a printer called "fred" your print command would be something like: lp -d fred some_file.ps Once you have a printer that works under Solaris, you need to create a papd.conf file. For example MacLaserjet:\ :pr=|/usr/bin/lp -d fred:\ :op=nobody:\ :pd=/usr/local/etc/HPLJ_4M.PPD: See doc/CONFIGURE for more information on papd.conf. Once you have this set up, and assuming netatalk starts up after /etc/rc2.d/S79atalk start you should be able to see the printer from the Macintosh Chooser. ---------------------------------------------------------------- D.I OpenBSD 1. KERNEL SUPPORT. Note that kernel support for netatalk appears in OpenBSD 2.2, or openbsd-current dated after Aug 1, 1997. But the 'comment out' character must be removed and the kernel must be recompiled. The kernel file that needs to be edited is usually located in: /usr/src/sys/conf Remove the first comment (#) from this line: # option NETATALK # AppleTalk Generally this is the GENERIC kernal. If you decide to rename the kernel, don't forget to go to /usr/src/sys/arch/<your arch>/conf/NEWNAME, and change the ../../../conf/GENERIC line to your NEWNAME. See http://www.openbsd.org/faq/faq5.html for more information on compiling a new kernel. 2. STARTING NETATALK. The rc scripts that come with openbsd to start netatalk are specific to an older version of netatalk. So, if you use the initscript provided in a current netatalk's distrib/initscripts directory, you must either add the lines from rc.atalk.bsd by hand into /etc/rc.local (or wherever you want to launch the daemons from) or modify your /etc/rc.local file to read: (currently says) # Netatalk stuff if [ -f /etc/netatalk/rc.atalk ]; then . /etc/netatlk/rc.atalk fi (change to) # Netatalk stuff if [ -f /etc/rc.atalk ]; then . /etc/rc.atalk fi and copy netatalk/distrib/initscripts/rc.atalk.bsd to /etc/rc.atalk. D.II Other BSDs 1. KERNEL SUPPORT. Note that kernel support for netatalk appears in FreeBSD 2.2-current dated after 12 September 1996. Add the line options NETATALK to the config file for your kernel. Rebuild and install your kernel. Reboot. ---------------------------------------------------------------- E. SunOS 1. KERNEL MODULE. This version of netatalk requires that your kernel be configured with options VDDRV The loadable kernel module is made and installed during the normal make and make install. NOTE: Unloading the kernel module may not work correctly and may cause your kernel to panic, hang, or do other nasty things. ---------------------------------------------------------------- F. Generic (It's unknown how applicable this is compared to the current codebase) The generic system profile is for use on systems that don't have native appletalk support. For those systems, it should still be possible to get the AFP/tcp portion of netatalk to still work. To do that, you will need the following information: 1) Endian order: If your machine does not specify the byte-order in netinet/in.h, you may need to modify netatalk/endian.h. 2) Integer sizes: If your machine does not define intX_t and u_intX_t, you will need to define them in netatalk/endian.h. To ease matters, you can specify _ISOC9X_SOURCE if you have inttypes.h, HAVE_64BIT_LONGS for 64 bit machines, or HAVE_32BIT_LONGS for 32 bit machines. NOTE: you should only use HAVE_32/64BIT_LONGS on machines that don't have a header file somewhere with the integer sizes. If you have a file with all the relevant bits, modify netatalk/endian.h to include it. 3) Quota/statfs information: You may be able to get away with either BSD4_4 or __svr4__, but that's unlikely if your os is some bizarre hybrid. If you don't have quota support, just specify NO_QUOTA_SUPPORT. In addition, if you'll need to specify the include file that gets statfs() (usually either USE_VFS_H or USE_STATFS_H although BSD4_4 and __svr4__ bring in a set of include files for that). Look at etc/afpd/quota.c, unix.c, and unix.h for more information. Finally, if you have a really old version of rquota, you can define USE_OLD_RQUOTA as well. 4) path information for lock/spool/printer files. you'll need to specify -D_PATH_LOCKDIR if include/atalk/paths.h doesn't have the correct paths specified for printer info and lock files. Beyond that, you should make sure that your operating system looks and smells like a Un*x POSIXy operating system. The only operating systems that netatalk supports that don't quite fit that description are sunos 4 and ultrix. If your operating system is peculiar, you may need to add in compatibility routines (libatalk/compat, include/atalk/compat.h) to make it look more like the others. If you would like native AppleTalk support, you will need kernel support for your operating system. Look at the Solaris STREAMS module if your operating system supports that framework. Otherwise, look at the ddp code in FreeBSD, NetBSD, or OpenBSD if your operating system is BSDish in nature. If your operating system looks different than these two cases, you'll have to roll your own implementation. |