[OpenAFS] AFS on MacOSX: Finder doesn't like big files
Hi, when I try to copy a 16.2GB-file (I bet the magic limit is 1600kB) from a local disk into AFS, the finder fails with an Out of space error (I don't know the exact error message in english - it's a german MacOSX 10.3). Yes - I know, it's the finder's fault and the mail should better be sent to [EMAIL PROTECTED] But is there any chance to solve the problem - i.e. by increasing the fake free-space value of /afs ? BTW: Why is this fake-value 16GB only and not i.e. 2048GB? Regards, Frank ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] AFS on MacOSX: Finder doesn't like big files
On Mon, 24 Oct 2005, Frank Burkhardt wrote: Hi, when I try to copy a 16.2GB-file (I bet the magic limit is 1600kB) from a local disk into AFS, the finder fails with an Out of space error (I don't know the exact error message in english - it's a german MacOSX 10.3). And I suppose you'd like us to guess what OpenAFS version? Derrick ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
[OpenAFS] Re: [OpenAFS-announce] OpenAFS 1.4.1 Release Candidate 1 now available
Jean-Claude: Please send bug reports to [EMAIL PROTECTED] Thank you. Jeffrey Altman Jean-Claude Eischen wrote: - Support for MacOS X 10.4 (Tiger) Thanks to Chas Grundman and Derrick Brashear for all of their hard work. Hello Jeffery, I have a feedback on the MacOSX-Version of OpenAFS. In our directoty hierarchy /afs/ethz.ch/groups/agr/server I only have l-Privileges on the groups-Folder whereas I heave rl on all other folders. With the older version of AFS I was able to read the contents of the agr-Folder and its descendents. With the new version (1.4.1 rc1) I am unable to do so. The Finder only lists the contents of the groups-Folder but as soon as I click on a subfolder (e.g. agr) this subfolder disappears. In the shell I get an error message job-working-directory: could not get current directory: getcwd: cannot access parent directories: Permission denied. I am still able to open a file if I enter the specific path. I do not know if this behaviour is intended or not. The Windows-Version does nor behave this way. Regards, Jean-Claude Eischen smime.p7s Description: S/MIME Cryptographic Signature
Re: [OpenAFS] AFS on MacOSX: Finder doesn't like big files
On Mon, Oct 24, 2005 at 08:47:20AM -0400, Derrick J Brashear wrote: On Mon, 24 Oct 2005, Frank Burkhardt wrote: Hi, when I try to copy a 16.2GB-file (I bet the magic limit is 1600kB) from a local disk into AFS, the finder fails with an Out of space error (I don't know the exact error message in english - it's a german MacOSX 10.3). And I suppose you'd like us to guess what OpenAFS version? No I don't - sorry. It's 1.3.82 - the latest one I found precompiled for MacOSX. Regards, Frank ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] AFS on MacOSX: Finder doesn't like big files
Frank Burkhardt wrote: It's 1.3.82 - the latest one I found precompiled for MacOSX. The latest version pre-compiled for MacOS X is http://dl.openafs.org/dl/openafs/candidate/1.4.1-rc1/macos-10.4/OpenAFS-1.4.1-rc1.dmg Jeffrey Altman smime.p7s Description: S/MIME Cryptographic Signature
Re: [OpenAFS] AFS on MacOSX: Finder doesn't like big files
But he has 10.3. Derrick On Mon, 24 Oct 2005, Jeffrey Altman wrote: Frank Burkhardt wrote: It's 1.3.82 - the latest one I found precompiled for MacOSX. The latest version pre-compiled for MacOS X is http://dl.openafs.org/dl/openafs/candidate/1.4.1-rc1/macos-10.4/OpenAFS-1.4.1-rc1.dmg Jeffrey Altman ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
[OpenAFS] klog seems to work.. loging in with ssh doesn't
Hello, klog seems to work on the OpenSSI machine and I do seem to get tokens and have access to volumes. However when I try to ssh to the OpenSSI machine I get : [EMAIL PROTECTED]'s password: Permission denied (publickey,password,keyboard-interactive). And on the OpenSSI machine in /var/log/messages: Oct 24 09:38:59 oort sshd(pam_unix)[67791]: check pass; user unknown Oct 24 09:38:59 oort pam_afs[67795]: AFS Authentication failed for user NOUSER. user doesn't exist any ideas where to start looking ? thanks, Ron ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] klog seems to work.. loging in with ssh doesn't
How about... the passwd file. pam_unix isn't afs aware and says the user doesn't exist. So, make the user exist. Derrick On Mon, 24 Oct 2005, Ron Croonenberg wrote: Hello, klog seems to work on the OpenSSI machine and I do seem to get tokens and have access to volumes. However when I try to ssh to the OpenSSI machine I get : [EMAIL PROTECTED]'s password: Permission denied (publickey,password,keyboard-interactive). And on the OpenSSI machine in /var/log/messages: Oct 24 09:38:59 oort sshd(pam_unix)[67791]: check pass; user unknown Oct 24 09:38:59 oort pam_afs[67795]: AFS Authentication failed for user NOUSER. user doesn't exist any ideas where to start looking ? thanks, Ron ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] klog seems to work.. loging in with ssh doesn't
Ok, I created the uid. I can login now, but don't get a token. When logged in and I klog with that uid I do get a token and everything seems to work. So I guess I am experiencing PAM issues on OpenSSI (I have it setup the same way as on other linux machines, and on those that just works.) thanks, Ron Derrick J Brashear [EMAIL PROTECTED] 10/24/05 10:05 AM How about... the passwd file. pam_unix isn't afs aware and says the user doesn't exist. So, make the user exist. Derrick On Mon, 24 Oct 2005, Ron Croonenberg wrote: Hello, klog seems to work on the OpenSSI machine and I do seem to get tokens and have access to volumes. However when I try to ssh to the OpenSSI machine I get : [EMAIL PROTECTED]'s password: Permission denied (publickey,password,keyboard-interactive). And on the OpenSSI machine in /var/log/messages: Oct 24 09:38:59 oort sshd(pam_unix)[67791]: check pass; user unknown Oct 24 09:38:59 oort pam_afs[67795]: AFS Authentication failed for user NOUSER. user doesn't exist any ideas where to start looking ? thanks, Ron ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
[OpenAFS] OpenAFS 1.4.1 RC1 Cache on OS X 10.4.2
I just finished installing a test OS X 10.4.2 client with 1.4.1-rc1, and I seem to be having some strange caching issues. Basically, on the server, I have a public/ directory, and within that directory is a scripts/ directory. Well, what happened was I tried to run the script from the Mac, it failed, so I tweaked it on the server, and then tried to re-run it on the Mac, and then it reported 'script.sh not found'. Even weirder is that if I did an 'ls' it listed it, but if I did a 'ls -al' it listed all the other files in there, but that one file, and reported an error 'ls: script not found' So, I did some testing and basically it seems there is a caching problem. If I create one file on the server, cat it on the client, modify it on the server, and then re-cat it on the client, the changes aren't acknowledged. My question is, before I submit a bug report, what's the proper way to clear the cache on the Mac client? I see you can delete the cache/ items, but everything I've seen says to be sure afsd isn't running, which I don't know the proper way to shut it down on the Mac clients (no init script). Any ideas? Rebooting is a pain :) -Mike ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] OpenAFS 1.4.1 RC1 Cache on OS X 10.4.2
Mike Bydalek wrote: I just finished installing a test OS X 10.4.2 client with 1.4.1-rc1, and I seem to be having some strange caching issues. Basically, on the server, I have a public/ directory, and within that directory is a scripts/ directory. Well, what happened was I tried to run the script from the Mac, it failed, so I tweaked it on the server, and then tried to re-run it on the Mac, and then it reported 'script.sh not found'. Even weirder is that if I did an 'ls' it listed it, but if I did a 'ls -al' it listed all the other files in there, but that one file, and reported an error 'ls: script not found' So, I did some testing and basically it seems there is a caching problem. If I create one file on the server, cat it on the client, modify it on the server, and then re-cat it on the client, the changes aren't acknowledged. My question is, before I submit a bug report, what's the proper way to clear the cache on the Mac client? I see you can delete the cache/ items, but everything I've seen says to be sure afsd isn't running, which I don't know the proper way to shut it down on the Mac clients (no init script). Any ideas? Rebooting is a pain :) -Mike fs flushvolume path-to-dir fs flush path-to-file Check to make sure you are not behind a firewall/NAT that is blocking the callback break messages from the server. Jeffrey Altman smime.p7s Description: S/MIME Cryptographic Signature
Re: [OpenAFS] OpenAFS 1.4.1 RC1 Cache on OS X 10.4.2
I doubt it's an AFS cache problem as opposed to an issue where permission denied is being misinterpreted and the result cache in either internal AFS or MacOS kernel filesystem code On Mon, 24 Oct 2005, Mike Bydalek wrote: I just finished installing a test OS X 10.4.2 client with 1.4.1-rc1, and I seem to be having some strange caching issues. Basically, on the server, I have a public/ directory, and within that directory is a scripts/ directory. Well, what happened was I tried to run the script from the Mac, it failed, so I tweaked it on the server, and then tried to re-run it on the Mac, and then it reported 'script.sh not found'. Even weirder is that if I did an 'ls' it listed it, but if I did a 'ls -al' it listed all the other files in there, but that one file, and reported an error 'ls: script not found' So, I did some testing and basically it seems there is a caching problem. If I create one file on the server, cat it on the client, modify it on the server, and then re-cat it on the client, the changes aren't acknowledged. My question is, before I submit a bug report, what's the proper way to clear the cache on the Mac client? I see you can delete the cache/ items, but everything I've seen says to be sure afsd isn't running, which I don't know the proper way to shut it down on the Mac clients (no init script). Any ideas? Rebooting is a pain :) -Mike ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] OpenAFS 1.4.1 RC1 Cache on OS X 10.4.2
Jeffrey Altman wrote: Mike Bydalek wrote: My question is, before I submit a bug report, what's the proper way to clear the cache on the Mac client? I see you can delete the cache/ items, but everything I've seen says to be sure afsd isn't running, which I don't know the proper way to shut it down on the Mac clients (no init script). fs flushvolume path-to-dir fs flush path-to-file I tried running 'fs flushvolume /var/db/openafs/cache/' but I get an error saying invalid argument. I am assuming you do that against the cache volume, of course, based on my cacheinfo file, which contains: /afs:/var/db/openafs/cache:3 Just to verify whether or not this is a caching issue, per the admin documentation, I tried the following, but it looks like it never resets the cache: # fs getcacheparms AFS using 289 of the cache's available 3 1K byte blocks. # fs setcachesize 0 New cache size set. # fs setcachesize -reset New cache size set. # fs getcacheparms AFS using 289 of the cache's available 3 1K byte blocks. Am I doing all this right, or am I way off? Check to make sure you are not behind a firewall/NAT that is blocking the callback break messages from the server. I'm not, this is a pure LAN test environment that I'm using. -Mike ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] OpenAFS 1.4.1 RC1 Cache on OS X 10.4.2
Derrick J Brashear wrote: I doubt it's an AFS cache problem as opposed to an issue where permission denied is being misinterpreted and the result cache in either internal AFS or MacOS kernel filesystem code What's the proper way to test this out? I don't see how this can be a permission denied as I have system:anyuser rl set. Thanks, Mike ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] OpenAFS 1.4.1 RC1 Cache on OS X 10.4.2
Mike Bydalek wrote: Jeffrey Altman wrote: fs flushvolume path-to-dir fs flush path-to-file I tried running 'fs flushvolume /var/db/openafs/cache/' but I get an error saying invalid argument. I am assuming you do that against the cache volume, of course, based on my cacheinfo file, which contains: /afs:/var/db/openafs/cache:3 The paths are destinations in AFS that you want to have flushed. smime.p7s Description: S/MIME Cryptographic Signature
Re: [OpenAFS] OpenAFS 1.4.1 RC1 Cache on OS X 10.4.2
On Mon, 24 Oct 2005, Mike Bydalek wrote: Derrick J Brashear wrote: I doubt it's an AFS cache problem as opposed to an issue where permission denied is being misinterpreted and the result cache in either internal AFS or MacOS kernel filesystem code What's the proper way to test this out? I don't see how this can be a permission denied as I have system:anyuser rl set. The proper way is probably fstrace, but I don't know if Chaskiel finished it. You can also try tcpdump and do a verbose capture (-vv -s 1500) and see if there are any errors which come in over the network. Derrick ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] OpenAFS 1.4.1 RC1 Cache on OS X 10.4.2
Jeffrey Altman wrote: Mike Bydalek wrote: Jeffrey Altman wrote: fs flushvolume path-to-dir fs flush path-to-file I tried running 'fs flushvolume /var/db/openafs/cache/' but I get an error saying invalid argument. I am assuming you do that against the cache volume, of course, based on my cacheinfo file, which contains: /afs:/var/db/openafs/cache:3 The paths are destinations in AFS that you want to have flushed. That makes sense then. When I do that, weird things happen: # fs flushvolume /afs/contentconnections.com/public/testdir/ # ls MyFile.txt # ls -al ls: MyFile.txt: No such file or directory total 12 drwxrwxrwx 2 mbydalek DomainUs 2048 Oct 24 10:50 . drwxrwxrwx 6 daemonwheel 2048 Oct 24 09:53 .. # Should I just bug report this? Or what else can I do to test some things out, or see what's going on, etc.? Thanks, Mike ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] OpenAFS 1.4.1 RC1 Cache on OS X 10.4.2
On Mon, 24 Oct 2005, Mike Bydalek wrote: fs flushvolume path-to-dir fs flush path-to-file I tried running 'fs flushvolume /var/db/openafs/cache/' but I get an error saying invalid argument. I am assuming you do that against the cache volume, That's because that's nonsensical. That's not a volume. That's the cache. Derrick ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] OpenAFS 1.4.1 RC1 Cache on OS X 10.4.2
Derrick J Brashear wrote: On Mon, 24 Oct 2005, Mike Bydalek wrote: fs flushvolume path-to-dir fs flush path-to-file I tried running 'fs flushvolume /var/db/openafs/cache/' but I get an error saying invalid argument. I am assuming you do that against the cache volume, That's because that's nonsensical. That's not a volume. That's the cache. Well, the reason I thought that was because on Linux the cache is mounted as a volume. I guess OS X doesn't do that ... -Mike ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] OpenAFS 1.4.1 RC1 Cache on OS X 10.4.2
Well, the reason I thought that was because on Linux the cache is mounted as a volume. I guess OS X doesn't do that ... Not as an AFS volume it isn't. And not necessarily as any at all. Derrick ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
[OpenAFS] Re: OpenAFS 1.4.1 RC1 Cache on OS X 10.4.2
[EMAIL PROTECTED] wrote: Date: Mon, 24 Oct 2005 11:06:10 -0700 From: Mike Bydalek [EMAIL PROTECTED] To: Derrick J Brashear [EMAIL PROTECTED] Cc: OpenAFS-info@openafs.org Subject: Re: [OpenAFS] OpenAFS 1.4.1 RC1 Cache on OS X 10.4.2 Derrick J Brashear wrote: I doubt it's an AFS cache problem as opposed to an issue where permission denied is being misinterpreted and the result cache in either internal AFS or MacOS kernel filesystem code I should note that on MacOS 10.3.9, I've had this problem, reliably, after extended use (e.g., several days of reads/writes). For me, it's tended to cooccur with random crap at the beginning of files (e.g., the name of the AFS volume overwriting the corresponding initial characters of the file). I've confirmed that these problems only appear in the AFS volume as viewed on the Mac, not as viewed from other platforms. Cheers, Sam Bayer [EMAIL PROTECTED] ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Re: OpenAFS 1.4.1 RC1 Cache on OS X 10.4.2
On Mon, 24 Oct 2005, Samuel L. Bayer wrote: [EMAIL PROTECTED] wrote: Date: Mon, 24 Oct 2005 11:06:10 -0700 From: Mike Bydalek [EMAIL PROTECTED] To: Derrick J Brashear [EMAIL PROTECTED] Cc: OpenAFS-info@openafs.org Subject: Re: [OpenAFS] OpenAFS 1.4.1 RC1 Cache on OS X 10.4.2 Derrick J Brashear wrote: I doubt it's an AFS cache problem as opposed to an issue where permission denied is being misinterpreted and the result cache in either internal AFS or MacOS kernel filesystem code I should note that on MacOS 10.3.9, I've had this problem, reliably, after extended use (e.g., several days of reads/writes). For me, it's tended to cooccur with random crap at the beginning of files (e.g., the name of the AFS volume overwriting the corresponding initial characters of the file). I've confirmed that these problems only appear in the AFS volume as viewed on the Mac, not as viewed from other platforms. That's not this problem. You're confused. Derrick ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
[OpenAFS] Re: OpenAFS 1.4.1 RC1 Cache on OS X 10.4.2
Derrick Brashear asked: And also... SMP only or uniprocessor also? Only on my dual-processor machine. I'm the heaviest user of AFS by far in my department, for various reasons. The various problems I see invariably result in a kernel panic on shutdown, which I've described in bug 21046. Cheers, Sam ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Re: OpenAFS 1.4.1 RC1 Cache on OS X 10.4.2
On Mon, 24 Oct 2005, Samuel L. Bayer wrote: Derrick Brashear asked: And also... SMP only or uniprocessor also? Only on my dual-processor machine. I'm the heaviest user of AFS by far in my department, for various reasons. The various problems I see invariably result in a kernel panic on shutdown, which I've described in bug 21046. Right. That's not the bug he's seeing, but I'm aware of it. In his bug, the files simply cease to be visible to the client. No corruption. And It's likely specific to 10.4 Derrick ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Openafs 1.4.0-rc7 Success on Redhat Enterprise 4 EM64T
Derek Atkins said: Could you try the rc5 candidate RPMs from http://www.openafs.org/dl/candidate and let me know if they work for you? (You might just need to grab the SRPM and rebuild). Thanks, -derek I didn't want to try 1.4.0-rc5 on a system already running 1.4.0-rc7, But I did try the 1.4.0-rc5 rpms on a system running 1.3.85, which is the version I have already made available to our user community, of which there are over 100 systems deployed already with it. It did not install particularly well on top of the 1.3.85 system built with the umich spec file, which I kind of guessed would happen, mostly because the names of the script files changed from afs to openafs-client, and the uninstall logic of the 1.3.85 did not do a chkconfig --del because the name of the rpm package was the same, but the chkconfig files were different. This made it impossible to shutdown the system cleanly for a reboot, though if I had thought about it, I would have shutdown afs before, and avoided the problem. This wouldn't be too bad, and could have been handled by stopping afs and doing chkconfig --del afs before installing the 1.4.0-rc5 rpms. However, given I already have over 100 systems installed with 1.3.85, and they are installed via up2date from our proxy server, and would cause quite a bit of disruption. There would also probably be some disruption due to having separate rpms for each kernel version as well, this doesn't cause a problem manually installing the rpms, but it is likely to cause at least many warnings from up2date, which will want to install the latest rpm, and if the system doesn't have the latest kernel installed, up2date will complain. Other things about the 1.4.0-rc5 rpms: - The openafs-client rc script doesn't provide the cache and afsd configuration that the rc script that has been supplied with openafs previously, and only provides 2 configuration parameters, AFSD_ARGS and BOSSERVER_ARGS in /etc/sysconfig/openafs, not all the various parameter settings for routines in /etc/init.d/afs, which I found very convenient for providing a simple way to configure afsd. I hope these are put back in before 1.4.x goes GA. If they don't, I will have to put them back in myself and rebuild the rpms. - I noticed that these rpms install the aklog from the afs-krb5 package, and not the aklog from the openafs source, the two are about equivalent in function, so its not a really big deal. - The README in the openafs-kernel-source is quite out of date as far as telling how to install a rebuilt openafs kernel module, which is obviouly different now the the openafs kernel modules are actually being installed in /lib/modules, instead of in /usr/vice/etc/modload. - to reiterate, the multiple openafs-kernel modules will cause a problem with up2date, and I realize why that was done, but the only way I can see is to put only the lowest kernel versions on the proxy server and force everyone to recompile their own openafs kernel module for newer kernels, which isn't as good as it works now. Other than the above, openafs 1.4.0-rc5 seems to be working on: [EMAIL PROTECTED] uname -a Linux motley.ait.iastate.edu 2.6.9-22.EL #1 Mon Sep 19 18:20:28 EDT 2005 i686 i686 i386 GNU/Linux [EMAIL PROTECTED] rxdebug motley.ait.iastate.edu 7001 -version Trying 129.186.145.100 (port 7001): AFS version: OpenAFS 1.4.0-rc5 built 2005-10-21 - Karl Karl E. Kelley [EMAIL PROTECTED] writes: I have installed openafs 1.4.0-rc7 on an EM64T machine running [EMAIL PROTECTED] uname -a Linux foolery.ait.iastate.edu 2.6.9-22.ELsmp #1 SMP Mon Sep 19 18:00:54 E DT 2005 x86_64 x86_64 x86_64 GNU/Linux It was installed using the rpm build strategy from http://www-personal.engin.umich.edu/~wingc/openafs/dist/ using his spec file and other auxilliary files, but built on my system. [EMAIL PROTECTED] rxdebug foolery.ait.iastate.edu 7001 -version Trying 129.186.145.188 (port 7001): AFS version: OpenAFS 1.4.0-rc7 built 2005-10-13 This is only a client and not a server, and had been running rc4 successf ully for quite some time before installing rc7. Karl Kelley -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available -- Karl E. Kelley [EMAIL PROTECTED] Systems Programmer Iowa State University Information Technology Services Phone (515) 294-0005 Ames, Iowa 50011 ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Openafs 1.4.0-rc7 Success on Redhat Enterprise 4 EM64T
I didn't want to try 1.4.0-rc5 on a system already running 1.4.0-rc7, But I did try the 1.4.0-rc5 rpms on a system running 1.3.85, which is the version I have already made available to our user community, of which there are over 100 systems deployed already with it. It did not install particularly well on top of the 1.3.85 system built with the umich spec file, which I kind of guessed would happen, mostly because the names of the script files changed from afs to openafs-client, and the uninstall logic of the 1.3.85 did not So it's not really an upgrade, because they aren't the same series of RPMs. - The openafs-client rc script doesn't provide the cache and afsd configuration that the rc script that has been supplied with openafs previously, and only provides 2 configuration parameters, AFSD_ARGS and BOSSERVER_ARGS in /etc/sysconfig/openafs, not all the various parameter settings for routines in /etc/init.d/afs, which I found very convenient for providing a simple way to configure afsd. I hope these are put back in before 1.4.x goes GA. If they don't, I will have to put them back in myself and rebuild the rpms. Realize the 1.4.0 final source has already been sent to binary builders, so it's on the late side to be noticing that. Derek will have to comment as to whether that can be accomodated at this point. If I seem snippy, well, I'm not. My network connection at the moment is poor Derrick ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Openafs 1.4.0-rc7 Success on Redhat Enterprise 4 EM64T
Karl E. Kelley wrote: There would also probably be some disruption due to having separate rpms for each kernel version as well, this doesn't cause a problem manually installing the rpms, but it is likely to cause at least many warnings from up2date, which will want to install the latest rpm, and if the system doesn't have the latest kernel installed, up2date will complain. It almost sounds like it might be interesting to try to build a DKMS package for OpenAFS to automate this process [installing a precompiled binary for the active kernel if available, compiling one if not]. ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Openafs 1.4.0-rc7 Success on Redhat Enterprise 4 EM64T
Quoting Charles Duffy [EMAIL PROTECTED]: Karl E. Kelley wrote: There would also probably be some disruption due to having separate rpms for each kernel version as well, this doesn't cause a problem manually installing the rpms, but it is likely to cause at least many warnings from up2date, which will want to install the latest rpm, and if the system doesn't have the latest kernel installed, up2date will complain. It almost sounds like it might be interesting to try to build a DKMS package for OpenAFS to automate this process [installing a precompiled binary for the active kernel if available, compiling one if not]. One could certainly posit a return to the single RPM of all kernel modules approach. It all depends on the target audience of the RPMs. Considering that up2date will also install updated kernels I see little reason to not put all the openafs modules there, too. I mean, how does up2date deal with the various redhat-distributed LKM RPMs? -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Openafs 1.4.0-rc7 Success on Redhat Enterprise 4 EM64T
Quoting Karl E. Kelley [EMAIL PROTECTED]: I didn't want to try 1.4.0-rc5 on a system already running 1.4.0-rc7, Well, you could try the 1.4.0 RPMs, as they've been finished. However the real point was to make sure that you could rebuild my RPMS on x86_64 and that they would work. Also, the 1.4.0 RPMS are done. There's time to get changes into the 1.4.1 RPMs - The openafs-client rc script doesn't provide the cache and afsd configuration that the rc script that has been supplied with openafs previously, and only provides 2 configuration parameters, AFSD_ARGS and BOSSERVER_ARGS in /etc/sysconfig/openafs, not all the various parameter settings for routines in /etc/init.d/afs, which I found very convenient for providing a simple way to configure afsd. I hope these are put back in before 1.4.x goes GA. If they don't, I will have to put them back in myself and rebuild the rpms. I dont understand what configuration you think you need that you can't set in the AFSD_ARGS and BOSSERVER_ARGS. Could you please let me know? - The README in the openafs-kernel-source is quite out of date as far as telling how to install a rebuilt openafs kernel module, which is obviouly different now the the openafs kernel modules are actually being installed in /lib/modules, instead of in /usr/vice/etc/modload. Can you send me a patch for this, or at least suggest better text? There's also the rpmbuild -bb --target=i686 openafs...src.rpm to build a kernel-module RPM for the currently-running kernel. - to reiterate, the multiple openafs-kernel modules will cause a problem with up2date, and I realize why that was done, but the only way I can see is to put only the lowest kernel versions on the proxy server and force everyone to recompile their own openafs kernel module for newer kernels, which isn't as good as it works now. Why will this cause a problem with up2date? Wont up2date already try to install the most-recent kernel? As I asked in my last email, how does up2date deal with the redhat-distributed LKM RPMS? Red hat must have already solved this problem Other than the above, openafs 1.4.0-rc5 seems to be working on: [EMAIL PROTECTED] uname -a Linux motley.ait.iastate.edu 2.6.9-22.EL #1 Mon Sep 19 18:20:28 EDT 2005 i686 i686 i386 GNU/Linux I was hoping to get an answer about x86_64, not x86. But thanks. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Openafs 1.4.0-rc7 Success on Redhat Enterprise 4 EM64T
I haven't been following this thread at all but if you want I can try to build these RPMs on the x86_64 box I'm playing with. I don't have a lot of time to translate instructions in an entire mail thread but if you have a cookbook you want tested I'm available. nomad Derek Atkins wrote: Quoting Karl E. Kelley [EMAIL PROTECTED]: I didn't want to try 1.4.0-rc5 on a system already running 1.4.0-rc7, Well, you could try the 1.4.0 RPMs, as they've been finished. However the real point was to make sure that you could rebuild my RPMS on x86_64 and that they would work. Also, the 1.4.0 RPMS are done. There's time to get changes into the 1.4.1 RPMs - The openafs-client rc script doesn't provide the cache and afsd configuration that the rc script that has been supplied with openafs previously, and only provides 2 configuration parameters, AFSD_ARGS and BOSSERVER_ARGS in /etc/sysconfig/openafs, not all the various parameter settings for routines in /etc/init.d/afs, which I found very convenient for providing a simple way to configure afsd. I hope these are put back in before 1.4.x goes GA. If they don't, I will have to put them back in myself and rebuild the rpms. I dont understand what configuration you think you need that you can't set in the AFSD_ARGS and BOSSERVER_ARGS. Could you please let me know? - The README in the openafs-kernel-source is quite out of date as far as telling how to install a rebuilt openafs kernel module, which is obviouly different now the the openafs kernel modules are actually being installed in /lib/modules, instead of in /usr/vice/etc/modload. Can you send me a patch for this, or at least suggest better text? There's also the rpmbuild -bb --target=i686 openafs...src.rpm to build a kernel-module RPM for the currently-running kernel. - to reiterate, the multiple openafs-kernel modules will cause a problem with up2date, and I realize why that was done, but the only way I can see is to put only the lowest kernel versions on the proxy server and force everyone to recompile their own openafs kernel module for newer kernels, which isn't as good as it works now. Why will this cause a problem with up2date? Wont up2date already try to install the most-recent kernel? As I asked in my last email, how does up2date deal with the redhat-distributed LKM RPMS? Red hat must have already solved this problem Other than the above, openafs 1.4.0-rc5 seems to be working on: [EMAIL PROTECTED] uname -a Linux motley.ait.iastate.edu 2.6.9-22.EL #1 Mon Sep 19 18:20:28 EDT 2005 i686 i686 i386 GNU/Linux I was hoping to get an answer about x86_64, not x86. But thanks. -derek ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Openafs 1.4.0-rc7 Success on Redhat Enterprise 4 EM64T
Um, rpmbuild --rebuild should be a sufficient test. Well, that and then testing the RPMs. ;) -derek Quoting Lee Damon [EMAIL PROTECTED]: I haven't been following this thread at all but if you want I can try to build these RPMs on the x86_64 box I'm playing with. I don't have a lot of time to translate instructions in an entire mail thread but if you have a cookbook you want tested I'm available. nomad Derek Atkins wrote: Quoting Karl E. Kelley [EMAIL PROTECTED]: I didn't want to try 1.4.0-rc5 on a system already running 1.4.0-rc7, Well, you could try the 1.4.0 RPMs, as they've been finished. However the real point was to make sure that you could rebuild my RPMS on x86_64 and that they would work. Also, the 1.4.0 RPMS are done. There's time to get changes into the 1.4.1 RPMs - The openafs-client rc script doesn't provide the cache and afsd configuration that the rc script that has been supplied with openafs previously, and only provides 2 configuration parameters, AFSD_ARGS and BOSSERVER_ARGS in /etc/sysconfig/openafs, not all the various parameter settings for routines in /etc/init.d/afs, which I found very convenient for providing a simple way to configure afsd. I hope these are put back in before 1.4.x goes GA. If they don't, I will have to put them back in myself and rebuild the rpms. I dont understand what configuration you think you need that you can't set in the AFSD_ARGS and BOSSERVER_ARGS. Could you please let me know? - The README in the openafs-kernel-source is quite out of date as far as telling how to install a rebuilt openafs kernel module, which is obviouly different now the the openafs kernel modules are actually being installed in /lib/modules, instead of in /usr/vice/etc/modload. Can you send me a patch for this, or at least suggest better text? There's also the rpmbuild -bb --target=i686 openafs...src.rpm to build a kernel-module RPM for the currently-running kernel. - to reiterate, the multiple openafs-kernel modules will cause a problem with up2date, and I realize why that was done, but the only way I can see is to put only the lowest kernel versions on the proxy server and force everyone to recompile their own openafs kernel module for newer kernels, which isn't as good as it works now. Why will this cause a problem with up2date? Wont up2date already try to install the most-recent kernel? As I asked in my last email, how does up2date deal with the redhat-distributed LKM RPMS? Red hat must have already solved this problem Other than the above, openafs 1.4.0-rc5 seems to be working on: [EMAIL PROTECTED] uname -a Linux motley.ait.iastate.edu 2.6.9-22.EL #1 Mon Sep 19 18:20:28 EDT 2005 i686 i686 i386 GNU/Linux I was hoping to get an answer about x86_64, not x86. But thanks. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
[OpenAFS] /etc/mtab
hello, Can the afs client be started without creating an entry in /etc/mtab ? If not, where can I find the code that puts an entry in /etc/mtab ? thanks, Ron ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] /etc/mtab
On Mon, 24 Oct 2005, Ron Croonenberg wrote: hello, Can the afs client be started without creating an entry in /etc/mtab ? You mean by you putting an entry there? Where'd you get that idea? It seems like if you're trying to understand why some openssi thing breaks, if you try it on a non-openssi machine it should work the same way with openssi, and if it doesn't, you're having an openssi problem. But I will grant you I'm making wild guesses at your motivation. Derrick ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
