Re: [OpenAFS] Migrating from Transarc to OpenAFS client on Windows
Nancy: Both the MSI and EXE installers distributed from openafs.org are designed to upgrade previous IBM AFS clients. Of course, it is preferable to perform a clean uninstall of IBM AFS first. Performing an uninstall via Add/Remove Programs of the IBM AFS client should be successful unless it is old. There is strong evidence to indicate that IBM AFS 3.6.5 does not uninstall properly. The most important thing to check after an uninstall is that the PATH environment variable in the System control panel no longer includes the IBM AFS path. That way even if there are old binaries left behind they won't be picked up when OpenAFS is starting. There should be no parts of an uninstall of IBM AFS that is Windows version dependent. Be aware that you should wait for the announcement of OpenAFS 1.4.0 this week before installing clients on Windows XP SP2 or Windows 2003 SP1. There was a bug in the Windows Internet Connection Firewall processing that prevented the firewall from being properly configured to allow AFS callbacks to be passed through. Also note that if your machines are part of a domain the best way to distribute OpenAFS for Windows is via a MSI transformed to include the configuration specific to your environment. See the release notes for details on how to generate a transform. Secure Endpoints Inc. can be hired to assist you in developing transforms or providing additional support. Jeffrey Altman Secure Endpoints Inc. Nancy Wallace wrote: > Hello, > > We have a large user base for AFS, some of whom are using the last > version of the Transarc client. We'd like to migrate all of them to > OpenAFS if possible. My two main questions at this point are: > > * Is it possible to do a clean uninstall of the Transarc client without > having to completely re-install Windows? > > * Are there any parts of the removal process that are Windows > version-specific? (Most of our users are on XP, but there are some on > 2000 and a few departments that may be on even older systems.) > > Any advice would be appreciated. Thanks! > > smime.p7s Description: S/MIME Cryptographic Signature
[OpenAFS] Migrating from Transarc to OpenAFS client on Windows
Hello, We have a large user base for AFS, some of whom are using the last version of the Transarc client. We'd like to migrate all of them to OpenAFS if possible. My two main questions at this point are: * Is it possible to do a clean uninstall of the Transarc client without having to completely re-install Windows? * Are there any parts of the removal process that are Windows version-specific? (Most of our users are on XP, but there are some on 2000 and a few departments that may be on even older systems.) Any advice would be appreciated. Thanks! -- Nancy Wallace IT Express [EMAIL PROTECTED] ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
[OpenAFS] AFS Workshop at LISA 2005
AFS administrators attending the LISA 2005 conference in San Diego are invited to participate in a one-day AFS workshop. The workshop will be held on Tuesday, December 6; the LISA conference is December 7-9. The AFS workshop at LISA is designed for experienced AFS administrators to share information and ideas about AFS and Arla. Active participation in the workshop is required. Due to space limitations, registration is set at 35 people. To apply to attend the AFS workshop at LISA 2005, send email to [EMAIL PROTECTED], with at least one of: - a list of topics you would like to see discussed at the workshop - a brief summary of a paper or talk you would like to present at the workshop You *MUST* be a registered attendee of LISA to attend the workshop. Additionally, this year, LISA is charging $100 for each workshop. This fee can only be paid on-site at the conference. For more information about the workshop at LISA, see http://grand.central.org/workshop . For more information about the LISA 2005 conference, see http://www.usenix.org/events/lisa05/ . ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] setting up AFS server on Panther Q
On 10/27/05, aK <[EMAIL PROTECTED]> wrote: > any links do you know where I can get a doc on how to setup a afs server on > Panther? > To my knowledge there is no Panther specific AFS documentation at this time. ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] /afs permissions
Todd M. Lewis wrote: > Unfortunately, the only available "someplace" to turn on encryption is > on the client. Turning on encryption on a client encrypts all traffic > bound to that client (most of it unnecessarily). Yet the same data > passes in the clear if another client accesses it. > > It would be a Good Thing if encryption were a per directory thing like > an ACL, enforced by the server, so you could make sure your sensitive > information was never passed in the clear. I have no idea how hard it > would be to implement an "encrypted directory" flag, but I suspect it > would mean breaking things. Would this be a reasonable thing to put on > the wish list? It is a reasonable thing to add to the wish list. I want to see an ability to add at the directory, volume and file server level the ability to specify acceptable security classes and modes. Today we have: none rxkad, clear rxkad, encrypted If the client request does not satisfy the security requirements, an error is returned. Jeffrey Altman smime.p7s Description: S/MIME Cryptographic Signature
Re: [OpenAFS] /afs permissions
>It would be a Good Thing if encryption were a per directory thing like >an ACL, enforced by the server, so you could make sure your sensitive >information was never passed in the clear. I have no idea how hard it >would be to implement an "encrypted directory" flag, but I suspect it >would mean breaking things. Would this be a reasonable thing to put on >the wish list? I remember being at an AFS Workshop where someone suggested enforcing encryption on the server (I think his suggestion was at the volume level) ... boy, did that poor guy get crucified by the workshop participants. Personally, I think it's a good idea ... I'm not sure whether or not it would be easier to do it from an implementation standpoint at the volume or directory level, though. --Ken ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] /afs permissions
[EMAIL PROTECTED] wrote: On 10/28/05, Joe Buehler <[EMAIL PROTECTED]> wrote: Something of importance, is putting sensitive information like ssh private keys and PGP keys, etc in AFS is a bad idea unless you have encryption in there someplace. Same is true for any network based filesystem. Unfortunately, the only available "someplace" to turn on encryption is on the client. Turning on encryption on a client encrypts all traffic bound to that client (most of it unnecessarily). Yet the same data passes in the clear if another client accesses it. It would be a Good Thing if encryption were a per directory thing like an ACL, enforced by the server, so you could make sure your sensitive information was never passed in the clear. I have no idea how hard it would be to implement an "encrypted directory" flag, but I suspect it would mean breaking things. Would this be a reasonable thing to put on the wish list? -- +--+ / [EMAIL PROTECTED] 919-962-5273 http://www.unc.edu/~utoddl / / A bicycle can't stand alone because it is two-tired. / +--+ ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
[OpenAFS] Re: /afs permissions
Jim Rees wrote: > > You need "StrictModes no" in sshd_config. > This seems like a bad idea for security reasons... > > Why? Not everyone on the machine has his .ssh under /afs. -- Joe Buehler ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
[OpenAFS] Release of Kvibille - ACL editor for Gnome
I'd like to announce the first release of an AFS ACL extension for Gnome's file manager Nautilus. The ACL editor will turn up as a tab in the properties dialog of a directory in AFS. Kvibille 0.1 can be found through various means: /afs/nada.kth.se/misc/hacks/ftp/kvibille/kvibille-0.1.tar.bz2 ftp://ftp.nada.kth.se/pub/hacks/kvibille/kvibille-0.1.tar.bz2 http://www.nada.kth.se/hacks/kvibille-0.1.tar.bz2 Release notes: --- It requires gtkmm 2.4 to compile. It can be run as a stand alone appliacation, but to use it as a Nautilus extension you need Nautilus extensions library, which was first released with Gnome 2.10. It works best when compiled with kafs/krbafs. It can make use of the "fs la" and "fs sa" commands instead, though this is not as thoroughly tested. When coding I started out from Eiciel 0.8.4, a POSIX ACL editor from http://rofi.pinchito.com/eiciel/ Unfortunately you can not have Eiciel and Kvibille installed as Nautilus extensions at the same time, since this cause Nautilus to hang. Hopefully I will figure out how soon... It haven't got any web page, cvs repository or bugzilla yet. Neither is the name fixed. The current name follows the naming convention of Arla: "Swedish dairy business". Kvibille is dairy making excellent cheese; their cheddar is my favourite. It is owned by Arla. But since there is no requirement to use Kvibille with Arla I might change the name in the future. -- Cheers -Mårten mail: [EMAIL PROTECTED] *** ICQ: 4356928 *** mobile: +46 (0)707390385 ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
[OpenAFS] Re: /afs permissions
[EMAIL PROTECTED] wrote: > Something of importance, is putting sensitive information like ssh > private keys and PGP keys, etc in AFS is a bad idea unless you have > encryption in there someplace. Same is true for any network based > filesystem. Yes -- the private keys are encrypted and the directory is rl to the unprivileged. -- Joe Buehler ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
[OpenAFS] Re: /afs permissions
Hendrik Hoeth wrote: > [10:38] [EMAIL PROTECTED]:~ $ ls -dl /afs > drwxr-xr-x 2 root root 4096 Nov 9 2004 /afs > [10:38] [EMAIL PROTECTED]:~ $ > > Works for me ... ;-) What are your afsd options and what OS is this? Some OS's are fine -- AIX 5.2 isn't, in our case. -- Joe Buehler ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Re: /afs permissions
Thus spake Joe Buehler ([EMAIL PROTECTED]): > Jim Rees wrote: > > You need "StrictModes no" in sshd_config. > > This seems like a bad idea for security reasons... Well ... erm ... since afs doesn't care about these permissions anyhow you're talking about the security-by-obscurity concept, without even being too obscure. Storing ssh keys in afs might be, as Jay said, a bad idea in the first place, depending on what exactly you're doing. -- Consistency: Every time you release an apple over Sir Isaac Newton, it will drop on his head. That's good. ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Re: /afs permissions
> You need "StrictModes no" in sshd_config. This seems like a bad idea for security reasons... Why? ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
[OpenAFS] Re: /afs permissions
Jim Rees wrote: > You need "StrictModes no" in sshd_config. This seems like a bad idea for security reasons... > As far as I know, there is nothing special about the mode on /afs. You > could probably have your admin chmod it. Can't do that -- EROFS -- Joe Buehler ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] /afs permissions
On 10/28/05, Joe Buehler <[EMAIL PROTECTED]> wrote: > The default afsd options (for AIX machines at least) end up > producing a /afs directory that is mode 777. This causes > sshd to refuse to use public key files stored in .ssh > directories somewhere under /afs. Something of importance, is putting sensitive information like ssh private keys and PGP keys, etc in AFS is a bad idea unless you have encryption in there someplace. Same is true for any network based filesystem. -- Jay Kline http://www.slushpupie.com/ ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] /afs permissions
Thus spake Joe Buehler ([EMAIL PROTECTED]): > My question is, where does the mode 777 come from? Well, who created the directory? > Is there any real reason for it to be 777 given that it's the AFS > mount point? Wouldn't 755 be a better mode? [10:38] [EMAIL PROTECTED]:~ $ ls -dl /afs drwxr-xr-x 2 root root 4096 Nov 9 2004 /afs [10:38] [EMAIL PROTECTED]:~ $ Works for me ... ;-) -- Consistency: Every time you release an apple over Sir Isaac Newton, it will drop on his head. That's good. ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] /afs permissions
The default afsd options (for AIX machines at least) end up producing a /afs directory that is mode 777. This causes sshd to refuse to use public key files stored in .ssh directories somewhere under /afs. You need "StrictModes no" in sshd_config. My question is, where does the mode 777 come from? As far as I know, there is nothing special about the mode on /afs. You could probably have your admin chmod it. ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
[OpenAFS] /afs permissions
The default afsd options (for AIX machines at least) end up producing a /afs directory that is mode 777. This causes sshd to refuse to use public key files stored in .ssh directories somewhere under /afs. Adding -afsdb -dynroot -fakestat causes the mode to change to 755, which works properly. I haven't checked to see which option causes the mode change. My question is, where does the mode 777 come from? Is there any real reason for it to be 777 given that it's the AFS mount point? Wouldn't 755 be a better mode? -- Joe Buehler ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Stopping afsd on Solaris?
* Derrick J Brashear [2005-10-28 08:51:46 -0400]: > On Fri, 28 Oct 2005, Sergio Gelato wrote: > >Precisely. Having recently tried to upgrade OpenAFS on a Solaris 8 > >test system via the modunload route, I can say that if AFS is in active > >use there is a good chance of the modunload approach triggering a > >kernel panic. So I prefer to upgrade with a clean reboot instead. > > umount should fail if something is accessing AFS. If umount fails, afsd > -shutdown should fail, as should unloading the module. Well, then it probably depends on which version one is upgrading from. I don't suppose 1.2.9 was bugfree? But point taken, if I ever reproduce this with the current version I'll file a bug report. ... I think I just reproduced my problem with 1.4.0-rc4. Will try a newer RC (or 1.4.0 final) one of these days. Here is what I did: # /etc/init.d/afs unload Killing inetd.afs Unmounting /afs Unloading afs module (98) afsd: Shutting down all afs processes and afs state # mount / on /dev/dsk/c0t0d0s0 read/write/setuid/intr/largefiles/onerror=panic/dev=220 on Sun Oct 9 01:14:59 2005 /proc on /proc read/write/setuid/dev=3e4 on Sun Oct 9 01:14:57 2005 /dev/fd on fd read/write/setuid/dev=3f0 on Sun Oct 9 01:15:01 2005 /etc/mnttab on mnttab read/write/setuid/dev=400 on Sun Oct 9 01:15:06 2005 /var/run on swap read/write/setuid/dev=1 on Sun Oct 9 01:15:06 2005 /tmp on swap read/write/setuid/dev=2 on Sun Oct 9 01:15:08 2005 (plus some other stuff but no AFS) # modinfo | grep afs (no output) # pgrep -fl afsd (system panics and reboots) >From the logs: BAD TRAP: type=31 rp=2a100591430 addr=78128c48 mmu_fsr=0 unix:die+a4 (31, 2a100591430, 78128c48, 0, 2a100591430, e058a030) unix:trap+8b8 (78128000, 1, 6, 0, 2a100591430, 0) unix:sfmmu_tsb_miss+66c (104293b0, 0, 304ff88, 0, 304ff88, 0) unix:prom_rtt+0 (3c10e80, 2a100591588, 2a100591580, 338d328, 1000c36c, 0) genunix:rm_assize+120 (42c8, 1, 3000117e2a8, 1fff, 104305a8, 34f9c88) procfs:prgetpsinfo32+37c (34f9c88, 2a100591770, 30001077520, 30001077520, 2a100591770, 30001383b20) procfs:pr_read_psinfo_32+3c (30001077520, 2a100591978, 30001db23a0, 338d328, 30001fae0a0, 30001fae000) genunix:read+25c (0, 0, 1, 30001512e70, 4, 150) genunix:read32+30 (4, ffbef2f8, 150, ff33c008, 21440, 1176c) This was SunOS Release 5.8 Version Generic_117350-25 64-bit . All right, the panic is actually triggered by pgrep; if I skip that step and do an "/etc/init.d/afs start" instead, I am at least sometimes able to get by without a panic. So my initial claim wasn't accurate, in that the problem manifests itself when AFS is inactive and the module is unloaded normally. >From a practical point of view, this is still annoying since I have no control over what background processes might look at psinfo during the time when no afs module is loaded. I have no idea whether OpenAFS or Solaris is to blame for this one. ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Re: Maximum disk cache size
In message <[EMAIL PROTECTED]>,Joe Buehler writes: >In that case, is there any documentation regarding how big a >cache is supported and what to set the various afsd parameters >to? I lack understanding of the cache data structures and >what chunksize is etc. i believe everything is counted in blocks, where a block is 1024 bytes. signed 32-bit numbers are used to store block counts. this would give an upper limit around 2T for the cache. there have been some discussions on the openafs-devel list recently about cache tuning. check the archives. the 1.4.x branch also has the "new" default cache tuning (auto chunksize selection and different assumption for average file size). if you gave us a little more information some others might be able to make some educated guesses. ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Stopping afsd on Solaris?
On Fri, 28 Oct 2005, Sergio Gelato wrote: One caveat though is that if things are trying to access files in AFS on the client while you shutdown the client, the afsd processes won't die. Precisely. Having recently tried to upgrade OpenAFS on a Solaris 8 test system via the modunload route, I can say that if AFS is in active use there is a good chance of the modunload approach triggering a kernel panic. So I prefer to upgrade with a clean reboot instead. umount should fail if something is accessing AFS. If umount fails, afsd -shutdown should fail, as should unloading the module. Derrick ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] afs-client on W2K Terminalservers
W. Aufsattler wrote: > we have a strange problem with afsd on our Windows 2003-Terminalservers. > I guess it isn't a bug but maybe we have overseen something. > > We run several Windows 2003-Terminalservers with Citrix for a pool with > 120 Thin-Clients. > Home-directories (and profiles) are in AFS-Land and are accessed via the > openafs 1.3.87 client installed on the terminalservers. > > Everything is fine as long as there are less than (28-30) users logged > in on one server. > Above that "limit" we notice that newly logged in users don't get their > Home-directories > connected and fs checkservers says that probably the afs-service isn't > running (which is not true). > At the same time users that were logged in earlier have full access to > their Home-dirs. > > Since there seem to be no limits on the maximum number of concurrent > users in the windows afs-client I wonder what the problem is. Has anyone > seen similar problems and knows a solution ? I am not aware of this problem. I know of at least one site that is using Windows 2000 Citrix with over 200 simultaneous users and they have the user profiles stored in AFS. If things were not working, I'm sure I would have heard screams by now. I do not know if there is something different about Windows 2003 Citrix. The first question I would ask is, "is an authentication request even making it to the AFS Client Service". In the release notes there is a section on debugging. I suggest you capture some trace log output and watch the connections. Also use the SysInternal's FileMon tool and the AFS pioctl debugging to see what happens when you attempt to access the service. Jeffrey Altman smime.p7s Description: S/MIME Cryptographic Signature
[OpenAFS] Re: Maximum disk cache size
chas williams - CONTRACTOR wrote: > its in the head and the openafs-stable-1_4_x branch. Great! I'm using 1.4.x. In that case, is there any documentation regarding how big a cache is supported and what to set the various afsd parameters to? I lack understanding of the cache data structures and what chunksize is etc. -- Joe Buehler ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
[OpenAFS] afs-client on W2K Terminalservers
we have a strange problem with afsd on our Windows 2003-Terminalservers. I guess it isn't a bug but maybe we have overseen something. We run several Windows 2003-Terminalservers with Citrix for a pool with 120 Thin-Clients. Home-directories (and profiles) are in AFS-Land and are accessed via the openafs 1.3.87 client installed on the terminalservers. Everything is fine as long as there are less than (28-30) users logged in on one server. Above that "limit" we notice that newly logged in users don't get their Home-directories connected and fs checkservers says that probably the afs-service isn't running (which is not true). At the same time users that were logged in earlier have full access to their Home-dirs. Since there seem to be no limits on the maximum number of concurrent users in the windows afs-client I wonder what the problem is. Has anyone seen similar problems and knows a solution ? begin:vcard fn:Werner Aufsattler n:Aufsattler;Werner email;internet:[EMAIL PROTECTED] tel;work:+49 621 / 181-3191 version:2.1 end:vcard
Re: [OpenAFS] Stopping afsd on Solaris?
* Coy Hile [2005-10-27 12:19:30 -0700]: > On Thu, 27 Oct 2005, E. Chris Garrison wrote: > > > > Thanks for the suggestions, Coy. > > > > It doesn't complain about any of those, but the afsd processes are > > still running and 'modinfo' still shows the module. > > > > I've seen the same thing here on my systems. When the processes are stuck > (I think they're waiting for kernel threads or something so they can't be > killed), the only recourse I've had is to reboot. But, I've also found > that when I shutdown the client first, then the server using the process > I listed (though if the machine in question is running both the client and > server, don't modunload until the end), the afsd processes shutdown. > > One caveat though is that if things are trying to access files in AFS on > the client while you shutdown the client, the afsd processes won't die. Precisely. Having recently tried to upgrade OpenAFS on a Solaris 8 test system via the modunload route, I can say that if AFS is in active use there is a good chance of the modunload approach triggering a kernel panic. So I prefer to upgrade with a clean reboot instead. As for the frequency of reboots, I find myself upgrading AFS so rarely that it isn't a serious issue for me. I normally apply "reboot required" patches from Sun every three months or so, and am still running OpenAFS 1.2.9 on most Solaris clients (will switch to 1.4.0 in the next round of reboots). ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
