Is there a way to tell the fileservers not to talk to clients below a
certain rev, or only allow reads? That should encourage them to upgrade.
Or leave. Not nice maybe, but if old clients can DoS your servers...
Jeffrey Altman wrote:
Matthew Cocker wrote:
I wish. I still have people using
Todd M. Lewis wrote:
Is there a way to tell the fileservers not to talk to clients below a
certain rev, or only allow reads? That should encourage them to upgrade.
Or leave. Not nice maybe, but if old clients can DoS your servers...
Not directly, I don't think, but you could write a
Todd M. Lewis wrote:
Is there a way to tell the fileservers not to talk to clients below a
certain rev, or only allow reads? That should encourage them to upgrade.
Or leave. Not nice maybe, but if old clients can DoS your servers...
You could patch your file servers to call
On 8/1/07, Todd M. Lewis [EMAIL PROTECTED] wrote:
Is there a way to tell the fileservers not to talk to clients below a
certain rev, or only allow reads? That should encourage them to upgrade.
Or leave. Not nice maybe, but if old clients can DoS your servers...
The version probe is not
Derrick Brashear wrote:
On 8/1/07, *Todd M. Lewis* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
Is there a way to tell the fileservers not to talk to clients below a
certain rev, or only allow reads? That should encourage them to upgrade.
Or leave. Not nice maybe, but
Better than what I have now which is they break AFS for all the other users.
Cheers
Matt
On 8/2/07, Jeffrey Altman [EMAIL PROTECTED] wrote:
Matthew Cocker wrote:
We do a similar thing for our locally developed cost recover solution.
The clients pass the version over in the initial
We do a similar thing for our locally developed cost recover solution. The
clients pass the version over in the initial handshake. If the version is
less than our required minimum the server rejects with a you need to upgrade
message. The only way we have found to force standards in our lossely
Matthew Cocker wrote:
We do a similar thing for our locally developed cost recover solution.
The clients pass the version over in the initial handshake. If the
version is less than our required minimum the server rejects with a you
need to upgrade message. The only way we have found to force
Jeff
I dumped the ip addresses and checked. All the offending machines are
running 1.5.16
rxdebug 130.216.22.5 7001 -version
Trying 130.216.22.5 (port 7001):
AFS version: OpenAFS1.5.1600
Cheers
Matt
On 8/1/07, Jeffrey Altman [EMAIL PROTECTED] wrote:
Matthew Cocker wrote:
UUID:
Forgot reply-all again
On 8/1/07, Matthew Cocker [EMAIL PROTECTED] wrote:
The -p 128 flag alone has not solved the problem. I have a Filelog (from
one locked up server) and rxdebug output from all servers at the time when
lots locked up last night). They can be accessed via
What is the UUID that you see repeated?
smime.p7s
Description: S/MIME Cryptographic Signature
OK
I rushed when I saw the diff attached. But the test cut from the web page
seems to have the wrong line numbers in the diff etc and fails to add. will
add manually if need be
Thansk for the help
Cheers
Matt
UUID: e3586602-1240-4f07-b1-d7-1b72dc8e715d
UUID: ea457696-8eec-4e71-b3-74-a2164c09d96b
These coorelated to a set of ip addresses that belonged to one department
which had reimaged a lot of lab machines last week. They are fixing their
machines using the file they got from
Matthew Cocker wrote:
UUID: e3586602-1240-4f07-b1-d7-1b72dc8e715d
UUID: ea457696-8eec-4e71-b3-74-a2164c09d96b
These coorelated to a set of ip addresses that belonged to one
department which had reimaged a lot of lab machines last week. They are
fixing their machines using
I wish. I still have people using 1.3.64. They refuse to upgrade despite my
efforts to show them the benefits of the upgrade. Alot of people on campus
feel that the new clients are not as stable as the old ones. Probably
because they all have the same uuid.
Cheers
Matt
On 8/1/07, Jeffrey
Matthew Cocker wrote:
I wish. I still have people using 1.3.64. They refuse to upgrade despite
my efforts to show them the benefits of the upgrade. Alot of people on
campus feel that the new clients are not as stable as the old ones.
Probably because they all have the same uuid.
1.3.64
Tonight we had 10 of our afs fielserver lockup. I had upgraded so to
1.4.4but they dies as well. All run on redhat 3 up6. Only one process
shows in ps
listing and gcores on this process seem to give nothing. A pstack dump is
below. Is it any good. This is now a real disaster and very weird. I have
Matthew Cocker wrote:
Tonight we had 10 of our afs fielserver lockup. I had upgraded so to
1.4.4 but they dies as well. All run on redhat 3 up6. Only one process
shows in ps listing and gcores on this process seem to give nothing. A
pstack dump is below. Is it any good. This is now a real
Sorry realised I hit reply instead reply-all
-- Forwarded message --
From: Matthew Cocker [EMAIL PROTECTED]
Date: Jul 31, 2007 7:49 AM
Subject: Re: [OpenAFS] 1.4.2 fileserver keep getting large number of blocked
connections
To: [EMAIL PROTECTED]
You will need to rebuild
Hi
We are running about 20 redhat AS3 based openafs 1.4.2 fileservers. For the
last three days between 4pm-10pm we have been getting 4-6 fileserver stop
serving files with nagios monitoring warning of 200 blocked connections. I
have turned on debug for the fileserver prcoess and have a log file
use gdb's generate-core-file, or gcore, or pstack if you have it, and get a
backtrace.
On 7/27/07, Matthew Cocker [EMAIL PROTECTED] wrote:
Hi
We are running about 20 redhat AS3 based openafs 1.4.2 fileservers. For
the last three days between 4pm-10pm we have been getting 4-6 fileserver
stop
21 matches
Mail list logo
