[OpenAFS] IP-address-based ACLs not working for a specific host
We use IP-address-based ACLs on one of our Solaris 9 clients with no problems. This Linux box we're trying to set up the same way is having none of it. The admin work: ADMIN% pts creategroup silkhosts group silkhosts has id -1594 ADMIN% pts adduser X.Y.11.70 silkhosts ADMIN% pts adduser X.Y.11.39 silkhosts ADMIN% pwd /afs/whee/project/silk ADMIN% fs sa . silkhosts rlidwk ADMIN% The failure: OpenAFS 1.4.7 client Linux coll 2.6.18-92.el5 #1 SMP x86_64 x86_64 x86_64 GNU/Linux ~:coll ifconfig -a | grep 129 inet addr:X.Y.11.39 Bcast:X.Y.11.255 Mask:255.255.254.0 ~:coll ~:coll cd /afs/whee/project ~:coll cd silk -bash: cd: silk: Permission denied ~:coll ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] IP-address-based ACLs not working for a specific host
Btw, that's not to say you're having the same problem here. Sorry if I jumped the gun. You may want to try giving the client a new UUID, esp. if you've cloned the client rather than installing from scratch. Kevin Sumner ITS Enterprise Storage Management University of North Carolina at Chapel Hill CB# 1150, 440 W. Franklin Street, Office G408 Chapel Hill, NC 27599-1150 ksum...@unc.edu 919.962.1547 (office) 919.259.9734 (mobile) 919.445.9485 (fax) Kevin Sumner wrote: We had a problem with this at the last place I worked -- turned out to be the Linux clients getting an all-zero UUID on startup. When somebody without permission with the same UUID would auth to the cell and start doing file IO, our machines would quit being able to use IP-based ACLs. I thought there was a fix in the 1.4 branch at some point, but we got around it quickly by running fs uuid -generate on startup after the link came up. Kevin Sumner ITS Enterprise Storage Management University of North Carolina at Chapel Hill CB# 1150, 440 W. Franklin Street, Office G408 Chapel Hill, NC 27599-1150 ksum...@unc.edu 919.962.1547 (office) 919.259.9734 (mobile) 919.445.9485 (fax) Jeff Blaine wrote: We use IP-address-based ACLs on one of our Solaris 9 clients with no problems. This Linux box we're trying to set up the same way is having none of it. The admin work: ADMIN% pts creategroup silkhosts group silkhosts has id -1594 ADMIN% pts adduser X.Y.11.70 silkhosts ADMIN% pts adduser X.Y.11.39 silkhosts ADMIN% pwd /afs/whee/project/silk ADMIN% fs sa . silkhosts rlidwk ADMIN% The failure: OpenAFS 1.4.7 client Linux coll 2.6.18-92.el5 #1 SMP x86_64 x86_64 x86_64 GNU/Linux ~:coll ifconfig -a | grep 129 inet addr:X.Y.11.39 Bcast:X.Y.11.255 Mask:255.255.254.0 ~:coll ~:coll cd /afs/whee/project ~:coll cd silk -bash: cd: silk: Permission denied ~:coll ___ 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] IP-address-based ACLs not working for a specific host
We had a problem with this at the last place I worked -- turned out to be the Linux clients getting an all-zero UUID on startup. When somebody without permission with the same UUID would auth to the cell and start doing file IO, our machines would quit being able to use IP-based ACLs. I thought there was a fix in the 1.4 branch at some point, but we got around it quickly by running fs uuid -generate on startup after the link came up. Kevin Sumner ITS Enterprise Storage Management University of North Carolina at Chapel Hill CB# 1150, 440 W. Franklin Street, Office G408 Chapel Hill, NC 27599-1150 ksum...@unc.edu 919.962.1547 (office) 919.259.9734 (mobile) 919.445.9485 (fax) Jeff Blaine wrote: We use IP-address-based ACLs on one of our Solaris 9 clients with no problems. This Linux box we're trying to set up the same way is having none of it. The admin work: ADMIN% pts creategroup silkhosts group silkhosts has id -1594 ADMIN% pts adduser X.Y.11.70 silkhosts ADMIN% pts adduser X.Y.11.39 silkhosts ADMIN% pwd /afs/whee/project/silk ADMIN% fs sa . silkhosts rlidwk ADMIN% The failure: OpenAFS 1.4.7 client Linux coll 2.6.18-92.el5 #1 SMP x86_64 x86_64 x86_64 GNU/Linux ~:coll ifconfig -a | grep 129 inet addr:X.Y.11.39 Bcast:X.Y.11.255 Mask:255.255.254.0 ~:coll ~:coll cd /afs/whee/project ~:coll cd silk -bash: cd: silk: Permission denied ~:coll ___ 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] Current Limits of OpenAfs ?
Hi, Is there a place I can find the current file, directory, volume and partition limits for OpenAfs ? I'm not sure which values are current. This is what I found searching: Max Number of Volumes Per Server: ? Max partition size in 1.4.x is 2TB Max partition size in 1.5.x is max signed int64 Max Number of files in a volume: ? Max Number of files in a directories (Something to do with 64K slots and 16 chars per slot) Max File Name Size: 255 chars -- Does it include the entire name space ? Max ACLs Per Directory: ? No ACLs per file: 0 I haven't found anything on the client side... Is there a limit on the size of the volume a client can attach? -cheers gary
Re: [OpenAFS] vos split interface question
I think there is overall consensus that volume splitting functionality is a good idea. I would like to recommend that we avoid focusing on any particular implementation of the idea at the moment and discuss the use cases for which a user interface and implementations are required. There are two different groups of users for which I can imagine volume splitting (or combining) would be of interest. Obviously there are afs administrators but there are also end users and I'm sure that afs administrators would like to be able to permit a subset of their users to be able to split or combine their volumes. For the afs administrator it is perfectly reasonable to assume a vos command interface which should not be tied to a cache manager. The afs administrator is comfortable working with the concept of volumes. It is therefore not unreasonable to require the administrator to refer to volume ids and paths relative to the volume root directory. For an end user, I would believe that an fs command would be more appropriate. The fs command can rely on a cache manager to take more general paths in the name space and resolve them into the necessary volume and relative path. The code could be implemented as common library that is shared by both interfaces. Proposals might include fs volsplit and fs voljoin. The concerns I would have with end user splitting of volumes are: how does the volume id and name allocation get done in such a way that it doesn't violate organizational policies? is being a volume owner sufficient privilege to permit splitting? perhaps volume flags need to be specified to indicate whether a volume is permitted to be split or joined? Jeffrey Altman smime.p7s Description: S/MIME Cryptographic Signature
Re: [OpenAFS] vos split interface question
Jeffrey Altman jalt...@secure-endpoints.com writes: For the afs administrator it is perfectly reasonable to assume a vos command interface which should not be tied to a cache manager. The afs administrator is comfortable working with the concept of volumes. It is therefore not unreasonable to require the administrator to refer to volume ids and paths relative to the volume root directory. Hm. I think you may have a higher expectation of what AFS administrators are likely to understand than I do. I think they will be able to figure out paths relative to the root directory, but I think it's extremely unintuitive for the path to be relative to the volume root directory and not the current location. I'm not sure there's much point in implementing relative paths to the volume root if we can't implement arbitrary paths. I would lean towards just requiring fs getfid untli we can implement arbitrary paths. At the least, we should reserve the more intuitive -dir option for arbitrary paths and use a different option for paths relative to the volume root. For an end user, I would believe that an fs command would be more appropriate. The fs command can rely on a cache manager to take more general paths in the name space and resolve them into the necessary volume and relative path. I cannot imagine ever allowing an end user to split volumes at Stanford. We draw a hard management line at volume creation. If we were to provide this functionality to end users, we would do so via a remctl interface to a system with AFS administrator privileges that would impose our naming standards. For example, we require registration of all volumes in a database as part of the creation, which is handled by the wrappers that we use. I'm not sure that's really a useful path to explore. It feels to me like a significant change in the AFS authorization model, given that it means VLDB changes which I believe currently can only be done by people in UserList. -- Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/ ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Current Limits of OpenAfs ?
On Fri, Jan 9, 2009 at 2:19 PM, Esther Filderman mizmo...@gmail.com wrote: On Fri, Jan 9, 2009 at 11:31 AM, gary mazzaferro ga...@oedata.com wrote: Hi, Is there a place I can find the current file, directory, volume and partition limits for OpenAfs ? I'm not sure which values are current. This is what I found searching: Max Number of Volumes Per Server: ? Max partition size in 1.4.x is 2TB in 1.4.8 it's max signed int64 ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] IP-address-based ACLs not working for a specific host
Solution: Wait 3 hours. ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
[OpenAFS] Re: [OpenAFS-devel] interface for vos split
--On Thursday, January 08, 2009 12:32:20 PM -0800 Russ Allbery r...@stanford.edu wrote: Steven Jenkins steven.jenk...@gmail.com writes: fs getfid (like virtually all of the fs subcommands) is implemented by marshalling arguments and then making a PIOCTL call into the kernel. Without a cache manager, you can't get a response to that PIOCTL. Even with a cache manager running, you would need to marshal up the arguments and make a PIOCTL, which means linking vos.c in with new libraries. vos is already huge; I think making it understand how to do PIOCTL calls would be significant enough to where we would look at getting rid of fs entirely (i.e., if vos can do one PIOCTL, adding the rest is relatively straightforward). These are all reasonable arguments from a code perspective Except, of course, that vos already depends on libsys, and already contains the (relatively trivial) code required to make AFS system calls, including pioctl. The additional code required to call VIOCGETFID is something like half a dozen lines: struct ViceIoctl blob; struct VenusFid fid; blob.out = blob; blob.out_size = sizeof(blob); blob.in_size = 0; pioctl(path, VIOCGETFID, blob, 1); Thus it seems to me most straightforward from a user-experience viewpoint to require the vnode. Straightforward, but difficult to use. Vnode numbers are an implementation detail that we should not depend on making visible to users. aI think the above would be less confusing than an implementation that sort of supports directory names but doesn't in a way that users expect. Agree ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Current Limits of OpenAfs ?
Thanks so much !!! I'm evaluating different distributed file systems for a cloud file system Yes, I said it, cloud. I've always admired the Andrew concept from the early/mid 80's. I like that AFS doesn't attempt to wide stripe data across servers. This company's model, they have lots of users (maybe 10million) with lots of small files that don't need to xfered at 1TB/s. AFS fits that model much better than Lustre, GPFS, GFS or any of the other supercompute systems. I have a few more questions Can anyone tell me how to calculate the memory requirement for each client on a server ? Are the file ACLs the underlying native ux ACLs or are AFS's file ACLs layered on top ? The question is really for eval'ing AFS over ZFS and direct support for WIndows/Samba ACLs. Is there a time table for the file ACL support ? thanks again -g On Fri, Jan 9, 2009 at 11:59 AM, Derrick Brashear sha...@gmail.com wrote: On Fri, Jan 9, 2009 at 2:19 PM, Esther Filderman mizmo...@gmail.com wrote: On Fri, Jan 9, 2009 at 11:31 AM, gary mazzaferro ga...@oedata.com wrote: Hi, Is there a place I can find the current file, directory, volume and partition limits for OpenAfs ? I'm not sure which values are current. This is what I found searching: Max Number of Volumes Per Server: ? Max partition size in 1.4.x is 2TB in 1.4.8 it's max signed int64 ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
