1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
|
From monad.swb.de!okir@aichan.swb.de Mon Dec 30 16:05:55 1996
Return-path: <monad.swb.de!okir@aichan.swb.de>
Envelope-to: clameter@waterf.org
Delivery-date: Mon, 30 Dec 1996 16:05:55 -0800
Received: from aichan.swb.de [193.175.30.7] (root)
by waterf.org with esmtp (Exim 1.59 #1)
id 0verhr-0000ED-00 (Debian); Mon, 30 Dec 1996 16:05:41 -0800
Received: by aichan.swb.de
id m0verbd-0007V5C
(ChiBi Smail-3.2 1996-Jul-4 #2); Tue, 31 Dec 1996 00:58:57 +0100 (MET)
Received: by monad.swb.de with smtp (smail3.2 #3)
id m0vetGd-000HRmC; Tue, 31 Dec 1996 02:45:23 +0100 (MET)
Message-Id: <m0vetGd-000HRmC@monad.swb.de>
To: linux-kernel@vger.rutgers.edu
Cc: Christoph Lameter <clameter@waterf.org>
Subject: Re: NFS Problem in Kernel 2.0.27: inode status not updated
Date: Tue, 31 Dec 1996 02:45:23 +0100
From: Olaf Kirch <okir@monad.swb.de>
Status: RO
X-Status:
On Sat, 28 Dec 1996 10:25:29 PST, Christoph Lameter wrote:
> It first opens a lockfile with a unique name and then links that one
> to the classic /var/spool/mail/username.lock lockfile. Then it checks the
> number of links on that file. If there are two then the lock is
> successful. Problem is Linux fstat call always returns 1 for the number of
> links even though a link() was done immediately prior.
There is nothing in the NFS spec that requires the client to update its
cached link count[*]. So I would assume the author's claim means that this
locking technique `works better over NFS on the systems I tested it on.'
Nevertheless, I guess I'll have to support this in the upcoming NFS
code... For the time being, I suggest exim users apply the following
patch to fs/nfs/dir.c, function nfs_link:
-------- fake patch -----
nfs_lookup_cache_remove(dir, oldinode, NULL);
+ NFS_CACHEINV(oldinode);
iput(oldinode);
-------------------------
IMHO, mounting your mail spool with the noac mount option is not a
very good idea.
Olaf
[*] The NFS spec is deliberately vague about how and to which extent
the client caches information. Vague being an overstatement here.
For those interested, the bare-bones protocol spec is available as
RFC 1094. There's also a (fairly expensive) specification available
from X/Open that also discusses some implementation issues as well as
the side effects on various system calls and utility programs. Some
information about current implementation practice can also be found in
the NFSv3 spec (available as RFC, and as postscript file all over the
net--archie for nfsv3.ps).
--
Olaf Kirch | --- o --- Nous sommes du soleil we love when we play
okir@monad.swb.de | / | \ sol.dhoop.naytheet.ah kin.ir.samse.qurax
For my PGP public key, finger okir@brewhq.swb.de.
From jake@ibmpcug.co.uk Tue Feb 18 10:06:34 1997
Return-path: <jake@ibmpcug.co.uk>
Envelope-to: clameter@waterf.org
Delivery-date: Tue, 18 Feb 1997 10:06:34 -0800
Received: from nora.pcug.co.uk [192.68.174.71]
by waterf.org with smtp (Exim 1.596 #1)
id 0vwtwG-0001jR-00 (Debian); Tue, 18 Feb 1997 10:06:29 -0800
Received: from kate.pcug.co.uk by nora.pcug.co.uk id aa18513;
18 Feb 97 18:05 GMT
Subject: Re: UUCP
To: Christoph Lameter <clameter@waterf.org>
Date: Tue, 18 Feb 1997 18:05:18 +0000 (GMT)
In-Reply-To: <Pine.LNX.3.95q.970218094917.6433B-100000@waterf.org> from "Christoph Lameter" at Feb 18, 97 09:50:12 am
From: jake@pcug.co.uk
X-Organisation: The PC User Group, Harrow, UK
X-Address: 84-88 Pinner Road, Harrow, HA1 4LF, UK
X-Phone: +44 181 863 1191
X-Mailer: ELM [version 2.4 PL2]
Content-Type: text
Content-Length: 1071
Sender: jake@ibmpcug.co.uk
Message-ID: <9702181805.aa13929@kate.ibmPCUG.CO.UK>
Status: RO
X-Status:
> I saw a discussion a while back regarding UUCP feeds with exim (domain
> based of course). Has anyone successfully done so? I would like to set up
> a small UUCP batch feed and would like to have some examples.
> --- +++ --- +++ --- +++ --- +++ --- +++ --- +++ --- +++ ---
> Please always CC me when replying to posts on mailing lists.
"standard" rmail uucp is easy..
use something like this..
# a transport
uucp_pipe:
driver = pipe;
#ignore_status,
user = uucp,
directory = "/tmp",
restrict_to_path,
path = "/usr/bin:/bin",
command = "uux - -a$sender_address -r $host\!rmail ($local_part@$domain)",
return_output
# a router example entry
uucpdomainlist:
driver = domainlist,
transport = uucp_pipe;
search_type = dbm,
route_file = "/usr/exim/table/uucpdom";
# the uucpdom file is like "wibble.com: wibblesys"
Batched SMTP over uucp is also possible, I have not tried it yet.
regards,
--
Jake Dias
jake@pcug.co.uk ...!ibmpcug!jake
My PGP Key? - finger jake@pcug.co.uk or email with Subject: get pgp key
From exim-users-request@lists.cam.ac.uk Wed Feb 19 08:01:21 1997
Return-path: <exim-users-request@lists.cam.ac.uk>
Envelope-to: clameter@waterf.org
Delivery-date: Wed, 19 Feb 1997 08:01:21 -0800
Received: from jethro.fuller.edu [206.1.27.7] (mail)
by waterf.org with smtp (Exim 1.596 #1)
id 0vxESi-0002zo-00 (Debian); Wed, 19 Feb 1997 08:01:20 -0800
Received: from lilac.csi.cam.ac.uk [131.111.8.44] (exim)
by jethro.fuller.edu with smtp (Exim 1.596 #1)
id 0vxENJ-0001TB-00 (Debian); Wed, 19 Feb 1997 07:56:06 -0800
Received: from most.weird.com [204.92.254.2] (root)
by lilac.csi.cam.ac.uk with esmtp (Exim 1.58 #1)
id 0vxE5j-0004YC-00; Wed, 19 Feb 1997 15:37:56 +0000
Received: by most.weird.com
via sendmail with stdio
id <m0vxE5K-00076wC@most.weird.com>
for exim-users@lists.cam.ac.uk; Wed, 19 Feb 1997 10:37:30 -0500 (EST)
(Smail-3.2.0.92-pre 1997-Jan-21 #8 built 1997-Jan-21)
Message-Id: <m0vxE5K-00076wC@most.weird.com>
Date: Wed, 19 Feb 1997 10:37:30 -0500 (EST)
From: woods@most.weird.com (Greg A. Woods)
To: exim-users@lists.cam.ac.uk
Subject: Re: UUCP
In-Reply-To: Philip Hazel's message
of "Wed, February 19, 1997 09:21:33 +0000"
regarding "Re: UUCP"
id <Pine.SOL.3.95.970219091410.18975C-100000@taurus.cus.cam.ac.uk>
References: <Pine.LNX.3.95q.970218094917.6433B-100000@waterf.org>
<Pine.SOL.3.95.970219091410.18975C-100000@taurus.cus.cam.ac.uk>
Reply-To: woods@weird.com (Greg A. Woods)
X-Mailer: ViewMail (vm) Version 5.96 (beta)
with GNU Emacs 19.34.1 (m68k.68881-sun-sunos4.1.1, X toolkit) of Thu Sep 12 1996 on most
Organization: Planix, Inc.; Toronto, Ontario; Canada
Status: RO
X-Status:
[ On Wed, February 19, 1997 at 09:21:33 (+0000), Philip Hazel wrote: ]
> Subject: Re: UUCP
>
> People are certainly doing this, but I have no examples myself. I have
> added some extra features to the 1.60 release that may make this easier.
> It is possible in that release to cause batching of messages to local
> transports without the use of batch SMTP, and the list of addresses is
> available in a variable. So you can arrange, for example, for a message
> with addresses in some specific domain to cause one execution of a pipe
> command such as
>
> |uux hostname!rmail address1 address2 ...
>
> which I understand is the way UUCP is frequently run.
Just FYI: One of the important configuration options (compile-time,
unfortunately) in the ancient smail-2.x was a limit to the total length
of the argument list passed to uux(1). In some older UUCP's this limit
was as low as 127 characters. It might be of some value to see if there
is any limit in the Taylor-UUCP (GNU) implementation of uux or uuxqt
(other than the maximum command-line limits which unfortunately may be
different in the remote machine, though in theory uuxqt could cause
multiple invocations of rmail to cope, though this breaks the uux
interface just a bit).
BTW, the 1.60 mechanisms seem generally applicable to many uses!
--
Greg A. Woods
+1 416 443-1734 VE3TCP robohack!woods
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>
|
