Re: [OpenAFS] AFS version of sudo for admin ?
On Dec 17, 2010, at 2:24 PM, Chris (Ducky) Chapin wrote: Yeah, the auth is definitely a kluge and can't do anything kas releated, but it works for the ~500 requests/day it gets. Not sure how ready the code is for public consumption, though. ;) Several hundred of us think that it works pretty well... :) ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] fs setserverprefs and supernetting
On Nov 1, 2010, at 4:31 AM, Assarsson, Emil wrote: Hi all, I would just like to have your input on this method of setting serverprefs based on the supernet distance. The background is that we have a large WAN with high latencies. The default method of calculating the weight for serverprefs is not good. We could have done this with static weighting but we need to keep things really flexible and self-configuring. There's a built-in assumption here that IP address assignments have a clear relationship with latency. That's probably accurate in so far as your company uses supernetting for routing. If you hand off Wan connections to MPLS, for instance, that might no longer be a good assumption, and this approach may fall down. This algorithm does appear to be an improvement over the built-in one, though. ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Ideas for finer grain set acl controls
On Oct 30, 2009, at 7:54 AM, Michael Meffie wrote: Hello, Andrew, Tom, and I would like to discuss and solicit feedback on some ideas we have been considering to strengthen OpenAFS access controls, especially for sites which provide AFS service over the public internet. I like the additional capabilities offered by this concept. In one of my past lives I had a requirement (which went unfilled) for such controls. The examples you gave made sense, except that there seems to be a hole. We need to take into consideration nested groups (aka supergroups). For example, assume for some reason, the group system:anyuser is a member of the group project:mayhem. This creates a complication in that a user could set the ACLs for project:mayhem, and transitively effect members of system:anyuser. Consider a volume called project.mayhem, which is mounted at as /afs/example.com/project/mayhem. setpolicy -grant -user system:anyuser -set-rights rl -for-user system:anyuser -in-volume project.mayhem pts adduser example:staff project:mayhem pts adduser system:anyuser project:mayhem Since the pts group system:anyuser now a member of the project:mayhem group, then the setting of the ACLs for project:mayhem would also need to be restricted, cd /afs/example.com/project fs setacl mayhem project:secret rlidwk I think you meant "fs setacl mayhem project:mayhem rlidwk" fs: You don't have the required access rights on mayhem I don't think you've solved this part of the problem. I don't know how to solve it, either. Since the restrictive policy on adding ACLs is evaluated at the time that the ACL is modified, and the membership of the super-group can be modified either before or after that event, this approach isn't going to result in any reasonable level of assurance that the ACLs are enforcing the intended policy (regarding access to the filesystem). It seems that as long as supergroups are in use in the cell, this is a potential hole. In fact, this same issue exists with respect to individual members of a normal group as well. (A policy preventing people from giving jane write access to some object would be circumvented if jane was added after the fact to a group that is allowed to be given write access to that object.) ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Re: Connection Timed Out errors occasionally when accessing openafs drive
On Jun 7, 2009, at 1:32 PM, Russ Allbery wrote: We tracked a similar problem down to user programs who were trying to access directories to which they didn't have permission (in our case because their tokens had expired). Sufficient pounding on such directories will trigger the Rx backoff handling in the file server and start delaying Rx calls from that client, which can result in the client deciding the file server is down or no longer responding. How did you track that down? ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] AFS design question: implementing AFS over a highly-distributed, low-bandwidth network
On Jan 15, 2009, at 1:19 PM, anne salemme wrote: general advice: [elided a bunch of good advice...] In addition, it would be good to make sure that you have a way to ensure that the full path to any particular leaf volume is replicated to the number of sites that you desire. As you get more and more volumes in the path, it's quite easy to loose track of whether and how widely each of them is replicated. You can be unpleasantly surprised when you find that some volume along your path isn't replicated enough and goes unavailable, or the performance is wierd. ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Problem with OpenAFS on Vista x86
On Jan 1, 2009, at 12:11 PM, Paul Accisano wrote: Jeffrey Altman wrote: Paul Accisano wrote: Finally, here's an extremely telling bit of information: not only do I lose access to \\afs when I connect to VPN, but I also lose access to all other comptuers on my network except the only other one that's running Vista. What's more, I don't regain access even when I disconnect from VPN! Rebooting seems to be the only cure after I've connected to VPN once. Unfortunately, this suggests to me that it's some kind of Vista --><-- VPN conflict, which means I'm getting outside of your area of expertise here... Any ideas? Reconfigure the Cisco VPN entry for NJIT to permit access to the local area network. No change. I was pretty excited when I saw that check box in the VPN settings, but it doesn't seem to have any effect; I checked it, rebooted, VPN'ed, and the same thing happened. All my non-Vista computers vanish, along with \\afs, and don't come back until I reboot. --Paul Be aware that with at least some versions of Cisco VPN, the "allow access to local network" checkbox on the client can be overridden by server-provided profiles. I.e, your VPN admins may be making that checkbox be a no-op. I would expect that this practice is common. When the server is overriding it, there's no indication on the client that this has happened. You can select and deselect to your heart's desire, and the behavior will not change. Ask your VPN admins if they are overriding this setting. I believe you can find the setting if you dig in a text file on the client that is automatically downloaded from the server, but I forget the details. (The "doesn't come back until reboot" aspect seems strange to me, however...) Jim ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
[OpenAFS] collective wisdom about limits on volume sizes?
Hi, In the old days, AFS admins made lots of very small volumes. A few GB was considered large. One of the limits I was aware of was being able to get the volume successfully backed up, and another involved successfully moving it between servers. I'm out of touch with what the state-of-the-art allows today anyone care to offer advice? How big can we make volumes and have everything still "just work"? What issues might we run into as we grow volume sizes? (For this, let's presume that we're running some new version of openAFS; this is a hypothetical question...) Thanks! Jim ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Basic OpenAFS questions
On Jun 26, 2008, at 4:43 PM, outsider wrote: Well, maybe I should express what I am looking for, in hopes someone can suggest an alternative. - join multiple pre-formated (with the FS of my choosing) partitions on the same machine (on different sized drives) into one large accessible space. - If one drive dies, only the data on that drive is lost. All other data remains. - If I pull one drive/parttion out, it should be accessible like a regular partition on another system. (this means that the original FS is not modified, and remains accessible when the drive is removed) I know there's JBOD. What I 'm looking for is kinda like that, but not exactly. mkdir -p /place/a /place/b mount /dev/deva /place/a mount dev/edevb /place/b You can use any sort of native filesystem that your OS will support... All data in one contigous space. Loose a drive; loose only one directory tree... Pull the drive out and mount it on some other system elsewhere... What else are you missing? ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] File ownership/permissions semantics
Christopher D. Clausen wrote: Derek Atkins <[EMAIL PROTECTED]> wrote: This script could also touch a file in the class volume so the TAs have the list of users. A simple "rli" will let you do this. You could touch files for other students then. (I'm not sure if that would be a bad or not, it would depend if students can get negative points for turning in non-functioning code.) < If you use the file ownership, not the name, to identify the student then I don't see any chance for impersonation. ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
