I don't know of any remaining IRIX deployments. Removing the IRIX-specific
docs section probably makes sense in light of the lack of official support.
-Original Message-
From: ka...@mit.edu
Sent: Mon, 3 Nov 2014 19:17:33 -0500 (EST)
To: openafs-info@openafs.org
Subject: IRIX
no objection here, esp. if there's anyone out there with the spare time for and
interest in testing them.
-Original Message-
From: ja...@rampaginggeek.com
Sent: Thu, 13 Sep 2012 20:21:08 -0400
To: sha...@gmail.com
Subject: Re: [OpenAFS] buildbot and packages
Are there any
I was wondering if the presentation slides might be available from this year's
BPW? Excited to read more about rxgk dafs (to name a few) and I hope others
are too!
Thanks,
-Chaz
Andrew Deason adea...@sinenomine.net wrote:
On Fri, 8 Jul 2011 15:46:48 -0600
Mark Henry mark.he...@infoprint.com
Also, does an OpenAFS file server only really take advantage of extra
memory if you configure a memory cache* for it?
A memory cache is a client-side thing. So although technically you could have
one on a server (if you also had the AFS cache manager, aka client, on there),
it would
Hi Derrick,
I've got the 1.6.0pre6 IRIX package ready for you here:
http://chaz.homeunix.com/downloads/openafs/sgi_65-1.6.0pre6.tar.gz
http://chaz.homeunix.com/downloads/openafs/sgi_65-1.6.0pre6.tar.gz.md5
Light testing, but seems to work.
-Chaz
On 06/04/2011 10:03 AM, Derrick J Brashear
Will there be an 'offline' / 'view later' option for those of us unable to tune
in to the events in real time?
-Chaz
Jeffrey Altman jalt...@secure-endpoints.com wrote:
The AFS and Kerberos Best Practices Workshop Committee is happy to
announce that registration for the 2011 AFS and Kerberos
Is there any problem connecting 1.6 clients with 1.4.14 servers?
Nope. Works fine. Overall, 1.6 clients seem to be working as well or
better than 1.4 clients, although someone has reported reproducible hangs
and crashes to me with 1.6 (and I've been trying to get him to file a bug
report).
This fails on both Irix and AIX, as they don't have preadv64 and pwritev64. I don't
have either of those platforms in front of me, so it's not clear whether the
correct thing to do is to just disable positional I/O if preadv64 and pwritev64
aren't found, or if the Irix AIX variants support
Integration with the Windows login system I believe is almost always
done via AD. I think it's possible to not use AD if someone wrote a
Kerberos pGina plugin (or maybe Samba, but that's just replacing AD, not
getting rid of its role), but as far as I know nobody does that. But if
you just want
I put together a brief description of how to set up your own OpenAFS BuildBot
build slave:
http://wiki.openafs.org/AFSLore/BuildbotSlaveHowto/
We have three platforms represented at the moment and could probably use a
wider variety of OS/architecture combinations. If you have a spare machine
XFS has got XFScheck and XFSrepair.
BUT if you have lots of file, xfscheck needs HUGE amount of memory to
run. Even with 24GB of memory my 2TB data directory (non OpenAFS) threw
a out of memory error on XFScheck.
True, but xfs_check != fsck_xfs, which is what would be run at boot.
On 03/03/10 12:31, Booker Bense wrote:
I've volunteered to take a poke at this and I'm using these guidelines.
1. Replace references to klog, with the kinit and aklog pair of
commands.
2. Delete all references to AFS enabled remote commands and replace with
references to equivalent
On 01/29/2010 05:56 AM, David Boyes wrote:
It's bothered me for some time that a basic infrastructure item like AFS is
distributed in a way that bypasses the OS software management system on most
platforms. I guess it's a time/resources thing, but still -- seems wrong,
somehow. It's not that
i think IRIX is dead enough this isnt going to be an issue. dead
enough that i cant see keeping support for IRIX much longer.
I think you could argue that from a business perspective, but let's not
pull the rug out from under it prematurely. It's working great now.
Derrick and others just
fine. but that doesnt mean it needs to be supported beyond that release.
if you want to continue to run irix 6.5 you will be stuck on an older
release of openafs (that will be bug fixes perhaps but not new features).
That would probably fine if older clients could still function just fine
Making it the default behavior might be OK, provided we add code to
make the fileserver recognize a vice partition containing existing
inode volumes and refuse to start.
Speaking of which, might now be the time to suggest that 1.6 default to
namei on IRIX? Especially since inode is very
Everyone I've heard from so far has strongly discourages the use of an inode
fileserver on IRIX 6.5. I think it would be worth considering changing the
default sgi_65 package release to namei. My impression so far is that the only
people using openafs fileservers on IRIX 6.5 build from source
What has been voiced as part of this thread by Chaz and Dave and perhaps
by Ragge (not sure yet) is that there is a desire to have an AFS
identity centric model in preference to a Kerberos v5 identity centric
model when it comes to authentication. ...
Yes, perhaps that's the best way to
-
From: sha...@gmail.com
Sent: Sat, 3 Oct 2009 03:39:49 -0400
To: cl...@inbox.com
Subject: Re: [OpenAFS] sgi_65: anyone still using inode fileserver?
On Fri, Oct 2, 2009 at 4:26 PM, Chaz Chandler cl...@inbox.com wrote:
After an unpleasant experience with the default (inode) sgi_65 package
?
On Fri, Oct 2, 2009 at 4:26 PM, Chaz Chandler cl...@inbox.com wrote:
After an unpleasant experience with the default (inode) sgi_65 package,
For which I'll find a bug in RT, right?
___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https
... From a conversation with the one other person I've found on this
list who (still) runs openafs on IRIX ...
We still run OpenAFS on ONE IRIX client.
The only reason to run it as server might be some MR-AFS functionality
together with DMF, but aside from that I wonder oh why oh why run
The person who would fix the bug would be me, and it wasn't known to
me. The report you did point at in your next message was lacking some
details but now I recall it and particularly wasn't able to reproduce
at the time. So, perhaps yes, we should be building namei binaries.
Yes, sorry,
After an unpleasant experience with the default (inode) sgi_65 package,
I'm wondering if anyone is actually using that configuration? I've been
able to get 1.4.8 to work with namei support (with some massaging), but
nothing newer. Is there any reason that the default package for IRIX
6.5 uses
to it and the
cost/benefit trade off.
Cheers!
-Chaz
Jeffrey Altman
Chaz Chandler wrote:
Perhaps it's just my setup, but I have on numerous occasions been able
to get tokens only through afscreds. netidmgr does work for this, but
occasionally not. I especially see issues when trying to get afs
I don't know if this is the same problem I have been experiencing, but
it sounds similar. I have no problem with permissions using 1.4.8 on
IRIX, which I built from source to enable namei (since I was having
serious issues with the stock inode version).
I have since attempted building 1.4.9,
You could do it another way: vos dump from source partition and vos restore to
destination. But generally the easiest way is addsite/remsite.
Note that vos remsite is the command to remove an RO volume, not vos remove.
The order doesn't matter, but you would vos addsite the volume on the
Thanks for everyone's replies!
So far, in summary:
1) There should be a separate cell at each site. This avoids quorum and and
local client server selection difficulties that arise in a VPN environment.
2) There is no good AFS-based solution for group shares in this scenario.
3) All volumes
2) There is no good AFS-based solution for group shares in this
scenario.
i don't agree with that, but it depends on your interpretation.
Ah, good. What would you recommend?
Further questions:
a) What is the best way to replicate a volume across cells?
b) How would the presence of
-bandwidth network
Chaz Chandler wrote:
2) There is no good AFS-based solution for group shares in this
scenario.
i don't agree with that, but it depends on your interpretation.
Ah, good. What would you recommend?
The problem you are facing is that OpenAFS does not support read-write
confined to a small set of small
files (usually less that 1MB each); sets change as projects change
(weekly/monthly). Still, it takes about 1 minute to transfer 1MB across the
VPN -- not insignificant.
-Chaz
Chaz Chandler wrote:
Hello all!
I am attempting to implement OpenAFS across a VPN
You can provide your users with scripts to run to prioritize the client
for their current location.
Okay, not a problem, but I take it that means there is no public repository for
scripts like these?
The way I understand the volume access is that even if a volume is
mounted R/W, its R/O
The issue I am running up against is how to organize the AFS volume
structure so that things like user home dirs, collaboration/group dirs,
and writable system items (like a Windows profile, for instance) are
optimally maintained in AFS.
The set-up is:
1) Each site has an OpenAFS server
Number five tops my list!
-Original Message-
From: steven.jenk...@gmail.com
Sent: Tue, 6 Jan 2009 13:03:16 -0500
To: openafs-info@openafs.org
Subject: [OpenAFS] Re: [OpenAFS-devel] Deadline- Jan 9! CFP: 2009 OpenAFS
Kerberos Best Practices Workshop
On Mon, Jan 5, 2009 at 5:16
:
Where should we go from here? Is our vpn bandwidth too low to support openafs?
Is there some additional analysis to perform? Is there a better afs setup to
use? Any hints on vpn tweaks to resolve the issue?
Thanks in advance,
-Chaz Chandler
___
OpenAFS
34 matches
Mail list logo
