1Discusses: 2 1. Getting the lot to compile 3 2. IMPORTANT info for people with remote filesystems (like NFS) 4 3. DEBUGGING AID 5 4. Setting up the environment 6 5. Extra options if you are a system administrator 7 8 --- 9 101. Getting the lot to compile 11 -------------------------- 12 13To install procmail, lockfile and formail: edit Makefile & config.h accordingly 14and type 'make install'. 15Intended configurable options in Makefile are: 16 the install-destinations (primarily BASENAME) and the 17 LOCKINGTEST directories (you can optionally use something like 18 'make BASENAME=$HOME install' instead). 19Intended configurable options in config.h are: 20 MMDF support, standard environment presettings including PATH, 21 trusted userids, whether each user has their own group. 22 23If an older version of procmail is currently installed, you should 24review all the entries in the HISTORY file between that revision and 25this one. 26 27'make install' will: 28 - implicitly do a 'make init', which will check your basic utilities for 29 POSIX compliance, and generates correcting Makefiles accordingly 30 - execute autoconf (a shell script that repeatedly calls the C compiler 31 to determine if certain features/symbols are supported), which will 32 create a file named autoconf.h 33 - create three stripped binaries, a shell script and five man pages in 34 the new/ subdirectory (all that is needed to install): 35 procmail, lockfile, formail, mailstat, procmail.1, lockfile.1, 36 formail.1, procmailrc.5, procmailsc.5, procmailex.5 37 - copy these binaries and mailstat to $(BINDIR) 38 - copy the man pages to $(MAN1DIR) and $(MAN5DIR) 39 - BEWARE: the installation obeys the current umask setting. If you 40 want the files to be available to anyone, correct your umask first. 41 42'make deinstall' will: 43 - remove the just installed files in $(BINDIR) 44 - remove the just installed files in $(MAN1DIR) and $(MAN5DIR) 45 46 47Minimal requirements (for regular uses): 48 49procmail must be installed. 50 51Optional files (depending on your requirements): 52 53lockfile only needs to be installed if you plan to read several mailboxes 54 with one of the standard mailers that doesn't support lockfiles. 55formail only needs to be installed if mail sometimes arrives in nonstandard 56 mailbox format (or if you want to generate auto replies, split up 57 mailboxes/digests etc., see the man page of formail for more info). 58mailstat is an "example" shell script that can be used as is to produce 59 summaries of the procmail generated logfiles; it is not needed by 60 procmail itself in any way. 61 62procmail, lockfile, formail and mailstat are all *standalone* programs, i.e. 63they do *not* use any compiled-in paths or files that need to be there, they 64all can be used and installed independently without the need to install the 65others. 66 67If things don't compile automagically, I suggest you take a look at: 68src/autoconf, autoconf.h, config.h, src/includes.h 69 70For autoconf to work as intended, your compiler should either be fully ANSI 71compliant, or you should NOT turn off all warnings; enabling all warnings 72shouldn't hurt. In most cases the default options in the Makefile will do. 73 74The sources are supposed to be fully ANSI, K&R and POSIX compliant. 75 76N.B. If you encounter any difficulty at all in installing procmail (e.g. if you 77 had to change Makefile or config.h in unpredicted ways, or a simple 78 "make install" doesn't work), I'd very much like to hear about it; who 79 knows, next time you might be able to simply "make install" as well. 80 81 --- 82 832. IMPORTANT info for people with remote filesystems (like NFS) 84 ------------------------------------------------------------ 85 86The autoconf script tries to determine what kernel locking functions are 87available *and* reliable on your system. In order to do this it exercises 88all the available locking methods (fcntl(), lockf() and flock()) on some 89sample files extensively. 90 91These tests produce results which depend on the filesystem which is 92being used to perform the tests. If you haven't changed the definition 93of LOCKINGTEST in the Makefile (you can include as many directories as 94you want) autoconf will prompt you to enter any additional directories 95(preferably on distinct filesystems) you want it to run the tests on. 96 97When specifying directories to test, it would probably be advisable to 98pick exactly those directories which belong to a unique fileserver-fileclient 99pair. I.e. one local file system will suffice. Only if you have remote 100filesystems, you might have to specify several. 101This makes sure that the locking tests will properly reflect the (lowest common 102denominator) locking capabilities on all filesystems available. 103 104If you have a very heterogenous environment (like several OS versions 105on machines (perhaps even from different vendors) that have NFS mounted file 106systems all over each other), then it could happen that some tests which 107are reliable with one remote filesystem, turn out to be unreliable across 108another (it all depends on the OS versions of clients and servers). 109 110If do not want to perform the locking tests on all those filesystems, but 111if you know what locking methods are unreliable anyway, then you can edit 112some defines in the config.h file (NO_fcntl_LOCK, NO_lockf_LOCK and 113NO_flock_LOCK). These can be uncommented by hand to prevent procmail 114from using them. 115 116The most typical case would be if you happen to be using NFS. Autoconf 117normally is very well capable of finding out if your lockd is reliable enough. 118In a very heterogenous environment (many different servers, many different 119lockd's (of perhaps different version and patchlevel)) however, it might 120be hard to determine if all the lockd's are equally reliable. In such a 121case (typically on SunOS :-), you might consider uncommenting both 122NO_fcntl_LOCK and NO_lockf_LOCK (NO_flock_LOCK normally doesn't rely on the 123infamous lockd, so you can leave it commented out). But, only do so if you 124think you know it better than autoconf. 125 126 --- 127 1283. DEBUGGING AID 129 ------------- 130 131Since procmail is intended to run completely independent of any terminals, you 132will typically have difficulties seeing it display error messages on the stderr 133output. It is recommended, especially during debugging, to specify a LOGFILE 134(see the procmailrc(5) man page) in the rcfile or on the command line. 135Procmail will log all serious problems it encounters. Of course, instead of a 136regular file, one could also specify a terminal as the default logfile. 137 138Also, procmail can be persuaded to be a lot more verbose by inserting the 139following assignment at the top of your rcfile: 140 141 VERBOSE=on 142 143Therefore a suggested command line for your first trial run (no rcfiles 144needed) would be: 145 146 procmail VERBOSE=on 147 148(now type in a pseudo mail-message) 149 150If all else fails, you can try uncommenting the "#define console" entry 151in the config.h file. This will provide you with the most verbose procmail 152you can make. It is of course a good idea to comment out this line again 153after your troubles have been solved. 154 155If you run procmail by hand and pipe in some sample mail, then make 156sure that if you kill procmail, you use "kill pid" and NOT "kill -9 pid". 157Should procmail seem to hang, check if any lockfiles are still present. 158If you kill procmail with "kill pid" it will clean up any lockfiles it created 159itself. 160 161 --- 162 1634. Setting up the environment 164 -------------------------- 165 166Every user that wants to use procmail should have a .forward and a 167.procmailrc file in his HOME directory. For starters, you can look 168at the supplied example files in "examples" or the NOTES section in 169the procmail(1) man page. 170BTW, be sure to make .forward *world* readable. 171MMDF users should note that they need a .maildelivery file *instead* of the 172.forward file (see the procmail(1) man page for more information). 173 174 --- 175 1765. Extra options if you are a system administrator 177 ----------------------------------------------- 178 179If you are a system administrator you can decide to install procmail 180globally (i.e. as a more robust drop-in replacement for the local- 181maildelivery-capabilities of /bin/mail, this also gets rid of the known 182security holes in some /bin/mails), this has the advantage that users do 183not need to have a .forward file anymore that calls up procmail. Simply 184having a .procmailrc file in the HOME directory will suffice. Operation is 185transparent in this case (i.e. if no .procmailrc file is present in the HOME 186directory, mail will be delivered as usual and procmail behaves like a faster 187and more reliable /bin/mail substitute). 188 189For direct examples on how to do this, look at the examples/advanced file. 190 191******************************************************************************* 192HIGHLY RECOMMENDED: install "procmail" suid root (and/or sgid maildaemon) 193 install "lockfile" sgid maildaemon 194 195To obtain specific instructions on the best installation, type "make recommend" 196******************************************************************************* 197 198 --- 199 200For more info about the program, see the man pages or the FAQ list. 201