Re: [OpenAFS] file ownership for root (UID 0)
On 01/12/2010 02:50 AM, Karl Tißner sent: Since it is not possible to create an user with AFS UID 0, all files created by root are not owned by root (Debian Linux, root has UID 0): # pts createuser -name testtest -id 0 0 isn't a valid user id; aborting What is the standard way to handle this problem? By declaring it not a problem, but desired behavior. Root is a local id, not a network id. A member of system:administrators can chown existing files to root, but that's as close as you're going to get I think. That's not really a satisfying solution. I'm forced to use the root account, since I chroot into an AFS directory, which is the root directory on a server using AFS mounted clients (for network boot). Files created by root should be owned by root immediately. I'd feel more pressed to help find a satisfying solution if I were convinced there was really problem. What specific root owned file needs are you running into? I'm not saying you're wrong, but you haven't presented a compelling use case. Convince me. How do others handle this? I really can not imagine, that I am the only one using such a configuration. AFS isn't a Swiss Army hammer, and this may be an application that it's not particularly well suited for. It's quite a bit different from local file systems, and it may not meet all the needs of your chrooted environment. Or perhaps it just doesn't meet some common conventions that aren't really requirements. Either way, it seems an interesting problem to me. I'd like to know more about the issues you're trying to deal with. -- +--+ / todd_le...@unc.edu 919-445-9302 http://www.unc.edu/~utoddl / / Santa's helpers are subordinate clauses. / +--+ ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] file ownership for root (UID 0)
On 01/11/2010 05:21 AM, Karl Tißner sent: Hello openafs-info, This seems to me like an frequently asked question, but I didn't find the answer searching the web. When writing into an AFS directory, the file ownership is set to the appropriate AFS id, not the Unix UID of the the user, who is creating a file (as described in http://docs.openafs.org/AdminGuide/ch02s08.html) As long as the AFS and the Unix UID match, this behaviour does not lead to problems. But is there an way to automatically use the Unix UID for newly created files? No. Since it is not possible to create an user with AFS UID 0, all files created by root are not owned by root (Debian Linux, root has UID 0): # pts createuser -name testtest -id 0 0 isn't a valid user id; aborting What is the standard way to handle this problem? By declaring it not a problem, but desired behavior. Root is a local id, not a network id. A member of system:administrators can chown existing files to root, but that's as close as you're going to get I think. Thank you, Karl Cheers, -- +--+ / todd_le...@unc.edu 919-445-9302 http://www.unc.edu/~utoddl / /He had a photographic memory which was never developed. / +--+ ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
[OpenAFS] order of directory entries re: creat() vs readdir()
We have a process that may run on any number of clients and at various times, the result of each run is to drop a small file into a common directory. These files represent queued work requests that get done in batches about once per hour by another process running on a single server. That process deletes the files it has processed. The clients include a time stamp in the file names. However, because of client clock skew (which was more of an issue many years ago when this was set up), rather than sorting the files by time stamp, the server process uses other heuristics to determine the order in which to process requests based on the nature of the requests themselves -- creates, mods, deletes, etc. falling into a hierarchy that almost always does the Right Thing. The preferred order would be the actual order the files were created in. My question then is about the order of entries as files are created in AFS directories. It occurs to me that even though the clients' clocks may be out of sync, the files' actual creation order may be reflected in the order directory entries are returned from readdir() since that happens on the server. A few tests seem to show that this is the case, but... are there any guarantees about the order directory entries are created and returned from readdir(), all else being equal (by which I mean, starting from an empty directory)? If not guarantees, how about in terms of emergent properties due to current implementation? That's subject to change of course, but these aren't life or death critical operations and they are already questionably ordered in some circumstances with our current scheme. So, would this be a reasonable way to improve our processing order? Obviously we'd need to pay attention to how we deleted these files to reduce create/delete ordering issues. Thoughts? Comments? -- todd_le...@unc.edu ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] user-visible change suggestion for fs setacl
Would it make sense to say f'rinstance +w rather than w+ to keep it similar to chown? Seems like having two different ways to accomplish such similar ideas is just the sort of thing that keeps the WIMP crowd shaking their heads at the command-liners. -- todd_le...@unc.edu On 12/16/2008 01:42 PM, Derrick J Brashear sent: The provided patch adds the ability to add or subtract rights from an acl element, e.g. a+ or a- to add or subtract the administer bit from an acl, like fs sa . shadow a+ would give shadow the a bit in addition to whatever bits he already had. It's user-visible. Before we go anywhere with it, ignoring code issues, what UI should this have, assuming we do want this feature (I certianly see the utility) https://rt.central.org/rt/Ticket/Display.html?id=123962 -- +--+ / todd_le...@unc.edu 919-445-9302 http://www.unc.edu/~utoddl / / He has no enemies, but is intensely disliked/ /by his friends. - Oscar Wilde/ +--+ ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] flock on AFS files
I've got quite a bit of code that does flock() on files in AFS, but I've always worked under the assumption that this would only work if a single client is doing the writing. I don't recall whether that assumption was based on empirical testing, reading it somewhere, or being told. In those few cases where this is not practical, I have a designated writer client that other clients connect to through other means (sockets) and coordinate the updates that way. That's reasonably straightforward, but painful enough that I avoid it whenever possible. Probably not the answer you wanted... -- [EMAIL PROTECTED] On 10/27/2008 12:16 PM, Hans-Werner Paulsen wrote: Hello, today I am totally confused how the flock(2) call should work on AFS files. Normally locking works in the following way: 1fd = open(afs-file,O_RDWR) do something 2flock(fd,LOCK_EX) do something with afs-file 3flock(fd,LOCK_UN) do something 4close(fd) When there are two processes (on different machines) executing that code, the (2) flock call has to update the local copy of the afs-file, otherwise locking is useless. And the (3) flock call has to sync the local copy with the fileserver. Writing a small test program I see that this synchronization isn't done. How can I use the flock(2) call on AFS files? Thank you for any help, HW ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Version of du that doesn't traverse AFS mount points?
Simon Wilkinson wrote: On 27 Aug 2008, at 02:18, Chas Williams (CONTRACTOR) wrote: In message [EMAIL PROTECTED],Mike Shaddock writes: I'm looking for a version of du where the -x option (skip directories on different file systems) doesn't traverse an AFS mount poi nt. Haven't been able to find anything via searching, so I thought I'd ask here. i have an interesting idea. on linux this would be pretty easy. after generic_fill_attr() we could encode the volumeid in the i_dev field instead of the s_dev field from the superblock. this should make this work. i cant think of anything it would break. Unless I'm missing something, this breaks anything that relies on stat's st_dev field to determine whether a file is in AFS or not. Filedrawers is one example, and I'm sure there are others. It also breaks anybody who expects -x to traverse the whole filesystem. mountpoint != filesystem The OpenAFS up utility has an explicit flag for stopping its traversal at mountpoints. I don't see a cheap way to conflate the two meanings with one flag and not break somebody. ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] best practice for salvage
Jeffrey Altman wrote: The way I would have implemented this functionality would be for the file to be moved into the local client's cache and removed from the file server since the file has now been unlinked and can therefore not be referenced by other clients. It would then be the client's responsibility to clean up after itself. Some files are larger than local client caches. ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Strange access problems on one client
Harald Barth wrote: [EMAIL PROTECTED] ~ % LANG= ll /afs/grand.central.org/ ls: cannot access /afs/grand.central.org/local: No such file or directory ls: cannot access /afs/grand.central.org/software: No such file or directory total 14K drwxrwxrwx 3 root root 2.0K Jun 17 2004 archive/ drwxrwxrwx 2 root root 2.0K May 7 2006 cvs/ drwxrwxrwx 3 root root 2.0K Mar 21 2003 doc/ ?? ? ?? ?? local drwxrwxrwx 2 root root 2.0K Jun 17 2005 project/ drwxrwxrwx 5 root root 2.0K Jan 30 2007 service/ ?? ? ?? ?? software drwxrwxrwx 2 root root 2.0K Aug 25 00:15 user/ drwxrwxrwx 5 root root 2.0K Aug 24 20:10 www/ That is really strange because I can't see why doc should differ from software. Both are mountpoints with similar ACL and permissions. If I had to take a wild guess, I'd say clock drift. Your client's clock is far enough off that your token is seen as valid for some servers, but invalid for others. I'm guessing that your servers are not totally in sync either, maybe just a few seconds or a couple of minutes off, but your client's clock is probably right at the edge of too far off. You may not have access to the servers themselves, but before you go fixing anything else it would be interesting to know what servers doc and software are on vs. the other mountpoints that listed okay. -- +--+ / [EMAIL PROTECTED] 919-445-9302 http://www.unc.edu/~utoddl / / I have never killed a man, but I have read many / / obituaries with great pleasure. - Clarence Darrow / +--+ ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] transitive fs la?
Todd M. Lewis wrote: Derrick J Brashear wrote: On Sun, 2 Sep 2007, Adam Megacz wrote: A user's rights on a directory are effectively moot unless s/he has l permissions on every ancestor directory (up to the volume root). So you could say that the transitive acl of a directory is its acl minus permissions which cannot currently be exercised by virtue of the acls on its ancestors. I'm interested in a simple utility to print out this sort of effective acl. For bonus points, query the pts database and factor in group membership (for example, a group you belong to has l on parent and you personally have l on the directory itself). Has anybody written this already, or should I take a crack at it? You can probably use ws as a basis. See ws.c in my homedir in the andrew cell. Go ahead, knock yourself out. Just keep in mind that the volume containing the directory you're interested in may be mounted in multiple places, and while the user may not have l rights all the way up the tree from one mountpoint, she might well have them from another. For this reason, you might want to include in your results two distinct reports: whether l is available from the given directory up to the root level of the containing volume, and a separate indication of whether the user has l rights up the tree in the given path to /afs. You might also want to make some decisions before you start writing code about how this would work when run by an admin (who could see all the ACLs) vs. a generic user (who may not). One more thing. The generic user running this utility may or may not be the subject of the query. For example, I may want to check whether I have l all the way up from a given spot. Alternatively I might occasionally want to grant Doug access to some directory, but I'd need to run your utility on that directory with Doug as the subject user rather than myself to see if he can in fact get to the data. So that's three scenarios: Admin testing a directory wrt an arbitrary subject user, Joe user testing a directory wrt himself, and Joe user testing a directory wrt some other user. Or a group. Ooooh, with groups, that's, like, six scenarios. Or multiple users and/or groups at once. Gee, I didn't realize how badly I need this utility. I'll stop now, or you may never get it written. :) -- [EMAIL PROTECTED] ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] transitive fs la?
Derrick J Brashear wrote: On Sun, 2 Sep 2007, Adam Megacz wrote: A user's rights on a directory are effectively moot unless s/he has l permissions on every ancestor directory (up to the volume root). So you could say that the transitive acl of a directory is its acl minus permissions which cannot currently be exercised by virtue of the acls on its ancestors. I'm interested in a simple utility to print out this sort of effective acl. For bonus points, query the pts database and factor in group membership (for example, a group you belong to has l on parent and you personally have l on the directory itself). Has anybody written this already, or should I take a crack at it? You can probably use ws as a basis. See ws.c in my homedir in the andrew cell. Go ahead, knock yourself out. Just keep in mind that the volume containing the directory you're interested in may be mounted in multiple places, and while the user may not have l rights all the way up the tree from one mountpoint, she might well have them from another. For this reason, you might want to include in your results two distinct reports: whether l is available from the given directory up to the root level of the containing volume, and a separate indication of whether the user has l rights up the tree in the given path to /afs. You might also want to make some decisions before you start writing code about how this would work when run by an admin (who could see all the ACLs) vs. a generic user (who may not). -- [EMAIL PROTECTED] ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] 1.4.2 fileserver keep getting large number of blocked connections
Is there a way to tell the fileservers not to talk to clients below a certain rev, or only allow reads? That should encourage them to upgrade. Or leave. Not nice maybe, but if old clients can DoS your servers... Jeffrey Altman wrote: Matthew Cocker wrote: I wish. I still have people using 1.3.64. They refuse to upgrade despite my efforts to show them the benefits of the upgrade. Alot of people on campus feel that the new clients are not as stable as the old ones. Probably because they all have the same uuid. 1.3.64 clients will take down your file servers having nothing to do with multiple uuids. Clients older than 1.3.80 have a bug the generates a new rx connection per authenticated request. Client's older than 1.3.80 do not support UUIDs. 1.4.1 or later will prevent the cloning of UUIDs. 1.5.12 or later use a CIFS server implementation that passes Microsoft's protocol tests. 1.5.21 is current. If your users have stability problems, then should file bug reports. Otherwise, we won't know there are issues that need to be fixed. ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] AFS and XEN Virtualization
Zach wrote: On 7/9/07, Thomas Kula [EMAIL PROTECTED] wrote: AFS does not do read/write replicas. Why can't/doesn't it do this? Just curious. Several possible answers. (1) It's a _really_ hard problem (with surprisingly little payoff IMHO; better to put that effort into buying and maintaining reliable systems and networks). (2) It wasn't the interesting problem that AFS was designed to solve. The interesting problem AFS was designed to solve is, How do you support N clients accessing the same data when existing systems can only support M connections and N is much greater than M? AFS lets you replicate fairly static parts of your file name space across multiple servers so that you can (a) support more simultaneous clients than a single server could handle, and (b) have the beneficial side effect some degree of redundancy in the face of network flakiness. The fact that this latter feature compensates somewhat when the inaccessibility of a read-only server is be due to server trouble and not network instabilities is also just a fortunate side effect; it shouldn't be misconstrued as a High Availability design feature of the AFS server software. In other words, My servers are unreliable so I'd better run AFS on them isn't a plan for long term happiness. Other neat things that you get with it (single name space, a real authentication system, user manageable and useful ACLs, semi-transparent support for multiple architectures in the name space via the nifty @sys hack, etc.) are icing on the cake, but they fell out of the design process (I think; I wasn't there). The point of starting the design, however, was to answer the question of N clients on M-connection servers. Read/write replication was never on the table. -- +--+ / [EMAIL PROTECTED] 919-445-9302 http://www.unc.edu/~utoddl / / He is not only dull himself, he is the cause of / / dullness in others. - Samuel Johnson/ +--+ ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] cgi and afs?
Zach wrote: I was talking to our sys admin. about allowing us users to run cgi programs from our afs accounts (served from $HOME/www which has system:anyuser rl) and asked if the web server could do this and was told first that the CMU AFS team was working on a way to make CGI principles for andrew (AFS realm) users so we can support them on contrib (AFS realm) and then later told they ran into a problem with permissions but had to work on the code a bit more. This was 8 months ago and still waiting for this to be finished. [...] You might want to look at https://lists.openafs.org/pipermail/openafs-info/2002-May/004471.html to see how we run our GCI scripts out of AFS. It lacks some of the elegance of http://www.umbc.edu/oit/iss/syscore/wiki/Mod_waklog, but it has served us very well. Whereas Mod_waklog uses a real Apache module, we use a ScriptAlias to an external program to fix up the runtime environment for user's scripts. Cheers, -- +--+ / [EMAIL PROTECTED] 919-445-9302 http://www.unc.edu/~utoddl / / There but for the grace of God, goes God. / /- Winston Churchill, on Stafford Cripps / +--+ ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Problem with IP-Based ACLs
Adnoh wrote: Hello @all I'm new to afs and have a litte problem which I'm not able to solve: I'm using openafs 1.4.1-r1 on a Gentoo-Linux box. I've created a folder /afs/.mydomain/test and a pts user 192.168.0.1 + 192.168.10.1 and a pts group afshosts with these users as members. then I fs setacl /afs/.mydomain/test afshosts all when I try to get to that dir from one of these hosts (unauthenticated) i come to /afs/.mydomain/ but when I wanne to get infos on test i get permission denied. can someone explain me why? maybe I've missunderstood something...? Just wanne to allow every daemon running on that 2 hosts full access to that test - folder. Thanks for responses It can take a couple of hours for file servers to become aware of IP group members. The process is fundamentally different for authenticated users vs. unauthenticated hosts, but think about it this way: if the file servers were to check every access for changes in IP group memberships in every directory, they would basically melt down your network and performance would fall through the floor. Instead, they slowly over time pick up those changes in what is generally an slow moving target set of data, and after a couple of hours they have a pretty complete picture of what IP entities are in which groups. Or think about it another way. When you become a member of a new group, you (may) have to re-authenticate for the change to take effect for ACLs in a given directory. Your group memberships are refreshed when you authenticate. Hosts don't authenticate, so there's no event to trigger refreshing their group memberships. So the file servers pick that up over time. Or maybe I'm blowing smoke, but that's what I was told once. -- +--+ / [EMAIL PROTECTED] 919-445-9302 http://www.unc.edu/~utoddl / /Atheism is a non-prophet organization./ +--+ -- +--+ / [EMAIL PROTECTED] 919-445-9302 http://www.unc.edu/~utoddl / / He who laughs last thinks slowest. / +--+ ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Backup methods
On Thu, Mar 29, 2007 at 10:07:42AM +0200, Gert Burger wrote: We are currently switching to openafs but are concerned about how to backup our data. My problem with dumping a volume and doing a backup of that is that it seems difficult to do incrementals. We only have enough space for about 3x the amount of data we on our backup server and we dont use tapes at all. Therefore we need to optimize our disk space usage so that we can keep daily incrementals for up to a month(We do a full backup monthly). Currently I am considering just to backup the files and lose the ACL's, seeing as we wont have complicated ACLs in anycase. Okay, consider it, but also consider that the big wins that AFS/OpenAFS gives you come from volume management and ACLs, both of which will be lost in your backups if you only backup files. I appreciate your dilemma though. If you're going to end up scripting things, why not take the extra step when you backup a directory to create a file in each directory, say .__vol_acl_info maybe, that contains the volume name, the path from the root of the volume to this directory, the owner of the root of the volume, the directory's owner and mode, and a dump of the directory's ACLs. This should give you enough information to restore a volume from your file-based incremental backups. Because these files would rarely change, they should have minimal impact on your backup store. Plus, sometimes what you really need to restore isn't the files but the ACLs themselves, and this would let you do that. It might be a bit of work, but it's probably worth it. -- +--+ / [EMAIL PROTECTED] 919-445-9302 http://www.unc.edu/~utoddl / /Atheism is a non-prophet organization./ +--+ ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Big Initial Question about OpenAFS
I'm afraid you're going to be disappointed, unless you have only one OpenAFS server. The OpenAFS clients communicate with whichever server(s) house the volumes they are trying to use. Volumes contain what looks like a directory of subtrees with files, directories, and symbolic links, but they can also contain mountpoints (which look like directories) for other volumes in the same or other cells. Those other volumes may well be on other servers (and certainly will be if they are out of the parent volume's cell, as a server can only serve one cell). Yes, this means that a given volume can be mounted (referenced as a subtree really) from multiple places. Try not to make loops, 'kay. Robinson, Eric wrote: Network connectivity differs significantly between NFS and Samba. With CIFS/Samba, shares may participate in a DFS tree and appear to the client as a single unified tree. However, when the client actually connects to a resource, he is redirected to the IP address of the server that holds the resource, so he ends up communicating with multiple hosts. With NFS, a server mounts the remote filesystem(s) and the client communicates only with one machine. Which is OpenAFS more like? I am hoping it is more like NFS because I have to work around firewall limitations. I am hoping that I can communicate solely with the OpenAFS server, and it will in turn communicate with other servers that it has mounted. Is that the way it works? -- Eric Robinson Director of Information Technology Physician Select Management, LLC 775.720.2082 Disclaimer - March 14, 2007 This email and any files transmitted with it are confidential and intended solely for [EMAIL PROTECTED] If you are not the named addressee you should not disseminate, distribute, copy or alter this email. Any views or opinions presented in this email are solely those of the author. Warning: Although the message sender has taken reasonable precautions to ensure no viruses are present in this email, neither Physician Select Management nor Physician's Managed Care can accept responsibility for any loss or damage arising from the use of this email or attachments. -- +--+ / [EMAIL PROTECTED] 919-445-9302 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: fs setacl and permissions
I see a need for both solutions. Would it be possible to change the behaviour on a per-fileserver basis? That you could allow one scenario on volumes on fileserver a and allow the other on fileserver b. Perhaps a flag to the fileserver on start-up to select which method the cell admin would like? the problem is the right way is per-volume, but per-fileserver is probably the best we can do today. anyone want to code it? (i can code it, it's like 5 minutes work, but testing is a little more) Is this really a good idea? Will vos move give a warning when moving a volume from one flavor of server to another? What happens when a server is rebooted with the flag switched? Would we need some kind of flag on the volume itself to say what kind of behavior is expected? This may be a 5 minute change, but recovery may take years. Maybe with a little more thought we can come up with a way to get the specific desired behavior without making multiple flavors of file servers (and avoid the resulting confusion that will ensue). -- +--+ / [EMAIL PROTECTED] 919-445-9302 http://www.unc.edu/~utoddl / / A modest little person, with much to be / / modest about. - Winston Churchill / +--+ ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Undelete support feedback request
Life gets interesting when multiple files with the same name have been deleted, but maybe you don't care about that (I would). Not so interesting. The function to list the entries reports multiple files with the same name. ... and how do you pick which one you're undeleting? I mean, I know how to do this at the RPC layer - you just undelete by FID. But what is the UI going to look like? Anybody remember VMS? When you replaced a file, it kept the old version around. If you didn't specify which version of a file you wanted, it would default to the current version, but you could just as easily specify the one, say, five versions back. I think you had some control over how many versions of a given file it would keep for you. Deleting a file just meant you didn't want to see version 0 anymore. I think DEC sold a lot of storage because of this... I don't remember what this looked like exactly, but I do remember the UI was so overwhelmingly upper-case that I didn't care for it at all. [BTW, two prominent Jeffreys and a Derek/Derrick pair -- I need pictures to keep you guys straight.] -- +--+ / [EMAIL PROTECTED] 919-445-9302 http://www.unc.edu/~utoddl / / A good pun is its own reword./ +--+ ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Some advice please
Matt Hampton wrote: Hi I have probably missed this whilst looking through the FAQ so forgive me if I am asking stupid questions. These are good questions, but I don't think you'll like these answers. I am looking to migrate to a DFS to provide increased resilience to our business and to allow us to scale as required. Beware: Distributed != Redundant; Scalability != Resilience. For the problems that AFS addresses well, those of us who use it don't want to give it up. But it's not a silver bullet. We provide distributed email filtering (i.e. anti-spam etc) and need to start provide archiving. We also host email accounts (in Maildir format) which we would also like to move to a more distributed architecture. So my questions are as follows: 1. Can I configure AFS to always store a file on at least two servers. No. And, maybe. Probably not the way you want. AFS stores volumes on servers, and these volumes contain the files. Some volumes are read-only, while others are read-write. Read-only volumes can live on multiple servers, and thus you get the benefits of redundant servers for those volumes (and thus, for those files). Read-write volumes live on one server at a time. They are easy to move from one server to another, but the holy grail of distributed files systems -- magically storing live read-write files in multiple places -- is not something AFS was designed to achieve. If you want something like raid5 bumped up to the server level, AFS is not your answer. 2. If I store files in /afs/My.Identifier/archive and need to increase space is it as simple as introducing a new server. Again, AFS stores volumes (which contain files). You need to think of these problems in terms of manipulating volumes. Each volume has a quota independent of other volumes. So you could simply bump up the quota for the volume containing /afs/My.Identifier/archive (or in AFS speak, /afs/@cell/archive). Typically, AFS servers store volumes on one or more dedicated partitions. Obviously, the server partition in question must have the space available to hold whatever you try to actually put in all the volumes on that partition. You _don't_ have to have as much space as the sum of all the volumes' quotas -- you can overbook quota. If your partition is too small, you can set up another partition on the same or another server and move volumes to the new partition(s) as you see fit. User's typically need not be bothered by such behind-the-scenes manipulations. 3. I know there are issues with any DFS and simultaneous access to files (e.g. when using shared IMAP folders based on mailbox) but by using Maildir have I reduced this issue? No. 4. I am intending to have a number of IMAP/POP3 servers which would be round robin load balanced with about an hour TTL would this also help with the issue in 3? No. Typically, cooperating processes on one client can use advisory locks and do whatever they want with expected results (they all share the same cache manager, and thus the same view of the file system state), but processes hitting the same read-write files and directories from different clients generally need to be written to be aware of the effects they can have on each other or you will lose joy. Any other suggestions would be welcomed! Finally We have are servers on rented dedicated servers which we do not have physical or console access to. They are all based on CentOS and do not have partitions available - could someone point me in the direction on how to move these servers to be AFS clients only using SSH access? Installing (and even building if necessary) the OpenAFS client is pretty straightforward. You will have to update it (or recompile) after each kernel upgrade, which is only mildly painful, but it also keeps you fresh on the technique. :^/ There's not much more to setting up an AFS _client_ than that. Your bigger problem is going to be setting up and learning to manage OpenAFS _servers_ -- the boxen that store the volumes, the vldb (volume location data base, the pts (protection server), kerberos -- and figuring out how to think about your storage issues in OpenAFS terms. AFS is different enough (it doesn't behave like, say, ext3) that getting a feel for what it can do for you vs. what it doesn't affect vs. where you're trying to fight against it for your particular needs is going to take some time and testing on your part... ...and of course, being willing to ask what may feel like stupid questions in public occasionally. Thanks for any help, regards Matt Cheers, -- +-+ / [EMAIL PROTECTED] 919-445-9302 http://www.unc.edu/~utoddl / / A Freudian slip is when you say one thing but mean your mother. / +-+ ___ OpenAFS-info mailing list OpenAFS-info@openafs.org
Re: [OpenAFS] access control lists
Daniel Miller wrote: Is there a way to do fs setacl recursively? -Daniel Here's a recursive fs sa for afs using xargs: find . -noleaf -type d -print0 | xargs -0 -n 2 fs sa -acl XX YY -dir A few things to notice: * -noleaf in AFS makes find do the Right Thing at the root of volumes. * -print0 instead of -print makes find do the Right Thing wrt names with spaces and other weird characters that we normally eschew. * The -0 makes xargs do the Right Thing wrt find's -print0. (They were literally made for each other.) * The 2 after -n could be 20 or 50 or whatever. I made it small just to make sure it was doing the Right Thing in limiting the number of parameters it tried to do on each command. * The normal order of -dir and -acl has been reversed so that -dir is on the end. This lets xargs put a bunch of directories on the end as the last parameters. * The XX and YY are supposed to be the principal and the permissions, respectively (like daniel and write). * This still makes the mistake of traversing AFS volume mount points, which can lead to iniquity. -- +--+ / [EMAIL PROTECTED] 919-445-9302 http://www.unc.edu/~utoddl / / He is not only dull himself, he is the cause of / / dullness in others. - Samuel Johnson/ +--+ ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
[OpenAFS] Choosing Cell Names (was Re: Changing AFS database server names)
Brian Sebby wrote: We're going to be upgrading our AFS cell in the coming months, and my boss has informed me that he wants to change the names of our AFS database servers from their current domain (which is our old department name) to our new server subdomain. This question got me thinking about guidelines for picking cell names. I've cruised the TWiki at http://www.dementia.org/twiki/bin/view/AFSLore (which is back up now, and looks beautiful, btw; I must have blinked when that was announced), but I didn't see any topic that dealt with choosing a name for a new cell. http://openafs.org/pages/doc/AdminGuide/auagd007.htm#HDRWQ34 and http://openafs.org/pages/doc/AdminGuide/auagd007.htm#HDRWQ35 give a little guidance, but misses an important point that was brought to mind by Brian's question. That point is, names change. Servers get life-cycled, departments get renamed, divisions get reorganized, etc. But the name of an AFS cell tends to find its way into the darkest corners of documentation and code that could take a long time to find and replace whenever one of these transient names transits. Changing a cell's name is not trivial, and is to be avoided if possible. Perhaps the best way to avoid having to change a cell's name is to name it well to start with. Somebody made a good decision when our cell was named. They gave it a name (isis) that didn't have anything to do with our current organization (except the top levels of course: unc.edu). The cell's name was its own; it didn't reflect who owned it, who ran it, or who used it. The initial reaction to the name was, as I recall, a collective question mark above everybody's heads. But it's been a good name. Besides being short and easy to type, the cell's administering entity has undergone several reorganizations, renamings, and consolidations, and the user base has shifted quite a bit, all without having to consider renaming the cell. Although the crystal ball is rather cloudy at the moment, it appears that the cell's name will endure, largely because it's not heavily intertwingled with the transient names surrounding it. Would it be worth having some text along these lines in the TWiki? I tend to be a bit wordy; perhaps a good editor could cut it down to about 30 well-chosen words? -- +--+ / [EMAIL PROTECTED] 919-445-9302 http://www.unc.edu/~utoddl / /I didn't attend the funeral, but I sent a nice letter/ /saying I approved of it. - Mark Twain/ +--+ ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
[OpenAFS] Re: OpenAfs and MS Office: Delayed Write Failed
Jeffrey Altman wrote: With the deadlock removed, saving files from Microsoft Office applications in Frank's environment does not result in a delayed write error. [...] This fix will appear in 1.4.2 and 1.5.2. Jeffrey Altman Just to be clear, is this a server fix or a client fix? -- +--+ / [EMAIL PROTECTED] 919-445-9302 http://www.unc.edu/~utoddl / / He has no enemies, but is intensely disliked/ /by his friends. - Oscar Wilde/ +--+ ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] multiple afs client, or have two caches
You might be surprised at the differences between what you think should be in the cache and what actually should be there. But in any case, the client doesn't have any sort of multi-policy cache capabilities that I'm aware of. If you've got a list of files that you really want to keep cached, just put the file names into a list and do something like this: while (1) ; do for f in `cat ~/.afs.cache.list` ; do head $f /dev/null sleep 10 done sleep 600 done That's just off the top of my head and may be busted or dead wrong here and there (I have no intention of trying to run it), but you get the idea, which is to keep using the files you want to keep in the cache. The cache does a pretty good job. It's not usually worth trying to outsmart it, but then I haven't really had the need to try. YMMV. (Oh BTW, your shift key seems to be malfunctioning a lot, too. :^) -- +--+ / [EMAIL PROTECTED] 919-445-9302 http://www.unc.edu/~utoddl / / I just got lost in thought. It was unfamiliar territory. / +--+ ted leslie wrote: i'd like to take advantage of the afs caching for added performance, is it possible to have two seperate caches? that is, i know there will be a common set of files used over and over again, that really should remain in RAM cache all the time, but other large files may also be cached and wipe out the other ones that i'd like to always have cached. One way I can fix this , is if i could have two afs clients on the same workstation, one that has access to the afs that have the very popular files, and other that has access to the infrequent, but large files that otherwise would spoil the cache. Can one have two seperate afs clients running on a workstation? Another sol'n might be , to be able to control what is and isn't cachable ? any ideas/thought/sol'n would be appreciated. thanks, -tl ___ 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] Windows Client, quota and filemanager - no warning!
Jeffrey Altman wrote: I have tested the functionality on Windows 2003 SP1 and everything behaves exactly as it should. It doesn't matter whether I copy or move from the command line or whether I drag/drop 1000 files or whether I copy/paste files. It all works just fine. So as far as I am concerned there is no bug [...] Great. Now this thread began with Lars Schimmer indicating that he was experiencing problems with two third party applications: TotalCommander and Xplorer2. [...] I misinterpreted the message title (...and filemanager) and Xplorer2 as the Windows Explorer. My bad. I had not run the test myself, and based on your report above, there's no point. Sorry for the waste of bandwidth, brainwaves, good will, etc. -- +--+ / [EMAIL PROTECTED] 919-445-9302 http://www.unc.edu/~utoddl / / A gossip is someone with a great sense of rumor. / +--+ ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] apache and home directories on with 1.4 client
Perhaps it's related to home directory issues, but based on my experience, I think you're running into an issue with SELinux. The default SELinux policies make /afs basically invisible to httpd. As a quick test, you can disable SELinux enforcement (see /etc/selinux/config), reboot, and see if stuff in AFS shows up through httpd. If so, then you can either * leave it that way (not a good idea) * learn just enough about selinux to make it work (another not good idea) * learn a whole bunch about selinux so that you really understand what it's doing and why (not a particularly attractive agenda for a long night), then make it do the Right Thing on purpose. BTW, If you end up taking the third option, I'd like to know what you had to do to make httpd do the Right Thing in AFS. :-) -- [EMAIL PROTECTED] Ron Croonenberg wrote: Hello all, I installed the OpenAFS client 1.4 on an FC3 machine. I created a symbolic link /home to /afs/mycell/home but if I try to point a browser to someone's public_html directory in /home/~userid it says it cannot find that url. (On other machines running the OpenAFS client 1.2.13 it just seems to work) I remember seeing a few msgs a few days ago about some homedirectory issues ? is this related ? thanks, Ron -- +--+ / [EMAIL PROTECTED] 919-445-9302 http://www.unc.edu/~utoddl / / When an actress saw her first strands/ / of gray hair she thought she'd dye / +--+ ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Windows Client, quota and filemanager - no warning!
Jeffrey, Your explanation of the error flows through the various levels is informative, and I believe you are 100% right on the level you are talking about. From the user's perspective, however, all he sees is that he goes to move/copy a file with the standard tools the Desktop provides, and the operation goes on forever. I agree with you that the Application -- in this case Microsoft's Drag'n'drop dead GUI -- is not doing what needs to be done, and it's clearly at fault. I'll go further and say that the few kludges I've thought up to somehow detect this problem and mitigate its effects (like noticing that we're getting gobs of VOVERQUOTA in a short period and perhaps putting up a message box to that effect on the screen) are just that -- horrible hacks that anybody with any sense of design would like to avoid. Maybe Vista will do the Right Thing, or perhaps something right enough, so that the user gets a clue. In the mean time, the current system as a whole behaves badly in this circumstance, and the user doesn't particularly care which component is at fault. There's a subtle difference between being right and being correct. I think your components are right, but the system as a whole is not correct, and fixing the user level application(s) in this case is not an option. Given that, and the fact that, as you explained, passing errors up the chain isn't solving the problem, the question then becomes, Is there anything else, within reason, that can be done to inform the user that there may be something amiss? The answer may very well be, Not really, and I'd be surprised if there's anybody else on the list (or OpenAFS-devel, which is where this should probably be anyway) in a better position -- either skill-set or experience-wise -- to answer that question than you. But restating with increasing degrees of detail that the existing OpenAFS components are handling return codes properly doesn't really address the larger issue. -- [EMAIL PROTECTED] Jeffrey Altman wrote: The AFS Cache Manager cannot speak directly to the user. When the VOVERQUOTA is received it is delivered to the application in this manner: VOVERQUOTA | | +-+ |AFS Cache Manager| +-+ | +---+ |SMB/CIFS Server| +---.---+ | ' STATUS_DISK_FULL | | +--'+ |Windows CIFS Client| +---+ | +-+ |Win32 API| +-+ | +---+ |Application| +---+ It is not possible for the AFS Cache Manager to determine what the application does with errors. If you have some evidence that the AFS Cache Manager is ignoring errors from the AFS File Server, please provide some evidence. Otherwise, you should speak with the developers of your applications. Jeffrey Altman ted creedon wrote: It appears that windows does not correctly pass the message on to the user, therefore it would be convenient if the client did. As I recall, the message box is indecipherable. ted -- +--+ / [EMAIL PROTECTED] 919-445-9302 http://www.unc.edu/~utoddl / / With her marriage she got a new name and a dress. / +--+ ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] AFS and Apache Virtual Directory
If you're running Apache on Fedore Core 4 and SELinux is enabled, Apache won't be able to see anything in AFS. The easiest solution is to disable SELinux, but then you don't get any of SELinux's protections. Alternatively, you can use audit2why to find out what it is about your SELinux policy that's keeping it from working. /usr/sbin/audit2why /var/log/audit/audit.log This will produce a lot of stuff if audit.log is very large. It explains what's wrong. Another utility, audit2allow, tells you what you need to change to make the entries in audit.log go away in the future. SELinux is cool, but there's a whole new level of security to learn about. And of course, if you aren't running SELinux, none of this matters... Suman Kansakar wrote: Does anybody have any experience with using an AFS directory as a virtual directory of an Apache server running on Linux? If yes, could you give me some pointers on making this work? Just for the sake of trying, I created a symlink inside the /var/www/html directory that points to the AFS directory. I can browse the directory fine as a root or any other user, but Apache refuses to recognize it. It has to do with authentication I believe, but not sure on how to tackle this problem. Thanks. ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info -- +--+ / [EMAIL PROTECTED] 919-962-5273 http://www.unc.edu/~utoddl / / A chicken crossing the road is poultry in motion. / +--+ ___ 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
Re: [OpenAFS] pam and OpenAFS
That's not a problem; that's how it's supposed to work. Think about it this way. Say you have a cell with, oh, 40,000 active users (like us), and your desktop machine is an AFS client. How do you control which of those 40,000 people can login to your machine? You only put in /etc/passwd those people you want to be able to login. [You old timers who've heard this propup bit before can stop reading. Bye.] However, sometimes you set up a machine that you want anybody in your cell to be able to login to. In that case, you can update your /etc/passwd whenever you add people to your cell. Or you can make a variant of http://www.unc.edu/~utoddl/propup.tar.gz. Propup is a little pam module that reads a list of valid ids from a file in AFS and if necessary updates your /etc/passwd file with a new entry if the user trying to login is not already there and he should be. Feel free to modify it to get its data from wherever you like. This was a quick-n-dirty excuse to play with pam, and although it works, it's still dirty. :) Cheers, -- +--+ / [EMAIL PROTECTED] 919-962-5273 http://www.unc.edu/~utoddl / /Those who jump off a Paris bridge are in Seine. / +--+ Ron Croonenberg wrote: Hi Derrick, yes then it works. (and yes I use shadow) When the username is in /etc/passwd and nthe password is different then the afs password it does get logged in, get's an afs token and get's the uid homedirectory shell info etc from ldap. However, when I don't have a local userid, it doesn't work. (Sounds like it is not an OpenAFS issue, but there must be more people that ran into that problem) Ron Derrick J Brashear [EMAIL PROTECTED] 10/27/05 12:48 PM And the username in question is listed in /etc/passwd (and /etc/shadow if you use shadow) right? On Thu, 27 Oct 2005, Ron Croonenberg wrote: I am trying to debug pam loging in to afs. Before pam_afs and pam_unix are used sshd already complains that the user that I try to login with is an illegal user. (oort sshd[68250]: Illegal user cowboy from aaa.bbb.ccc.ddd) Does that mean that sshd is not aware that there are other accounts, OpenAFS accounts, then local accounts ? If that's the case how do I make sshd afs aware ? (on other linux machines I never ran into that problem) thanks, Ron ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Firewall politics and AFS deployment
Simeon Miteff wrote: [...] Looking at the public CellServDB, I can't help wondering how AFS servers are connected at other universities? Are we overly firewalled? Yes. Do other HPC centres maintain separate AFS cells for cluster users? No. Any thoughts? You gain nothing by replicating the 4 NFS domains as 4 AFS cells. As long as you're going through the pain of an NFS-AFS transition, go all the way. Admining one cell with n users is more that four times easier than admining four cells with n/4 users each. AFS lets things scale, so take advantage of that. As for the firewall politics, you obviously have some entrenched interests to contend with, but I'd be concerned that UP might be creating more problems than it's solving by depending on the firewall. I'm sure there are plenty of articulate folks who will argue just the opposite, but I usually read firewall as abrogated responsibility. But maybe that's a good thing... -- +--+ / [EMAIL PROTECTED] 919-962-5273 http://www.unc.edu/~utoddl / / A gossip is someone with a great sense of rumor. / +--+ ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] OpenAFS in a production environment
Lester Barrows wrote: In an out-of-band discussion, Jeffrey Altman has managed to convince me (not an easy task mind you!) that Transarc AFS servers are more likely the cause of our NAT troubles with AFS clients. For this reason I'm amending my initial statement to say that if you access Transarc AFS servers, you should not put AFS clients behind a NAT. This is apparently due to IBM/Transarc AFS servers' UUID tracking not behaving correctly when multiple clients come from the same IP. [...] As long as you brought it up, IBM/Transarc AFS servers don't behave so hot when the (apparently) same client suddenly shows up coming from lots of different IP addresses either. I don't know whether OpenAFS servers deal with it any better. Not trying to embarrass myself or my colleagues, but if you (like us) deploy thousands of new OpenAFS Windows clients every year and you build those disks from the same image, you really want to remove the AFSCache file (and hence the no-longer-unique UUID) from the master before you start cloning disks. I'm just saying -- +--+ / [EMAIL PROTECTED] 919-962-5273 http://www.unc.edu/~utoddl / / When a clock is hungry it goes back four seconds. / +--+ ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] mount points and replication problems
Cédric CACHAT wrote: Hello, this is the first time I write and I am pretty new to AFS. I have a question regarding mount points in AFS. Here is what I'm trying to achieve: I want all my users to have their home directory in AFS, the plan is to set an AFS tree looking like: /afs/cell/usr/homes/user1 I created the following volumes on my primary server: root.afs root.cell common.usr common.homes user.user1 and then I mounted them using the fs command : *# fs mkm /afs/cell/usr common.usr* and so on... (I didnt use *# fs mkm /afs/_._cell/usr common.usr *maybe my problem comes from here?) So far everything is under control. Since I have many sites, I have set up one AFS server on each site. Because all users don't work on the same site I decided to create user.* volumes on their closest server, so I created volume user.user1 on the primary server and user.user2 on the secondary server. Up to this point, you've done everything wonderfully. Congratulations. Without any replication it works perfectly if BOTH servers are running. If one is down, say the master, then acces to a user's home-dir is impossible. Now you've got to the point where you have to distinguish between distributed file servers (which AFS provides) vs. high availability (which AFS does not provide). Thats's were it's getting complicated for me: I then set up replication to the second site so that I have: primary server secondary server root.afs (RW) root.afs (RO) root.cell (RW) root.cell (RO) common.usr (RW) common.usr (RO) common.homes (RW) common.homes (RO) user.user1 (RW) user.user1 (RO) user.user2 (RO) user.user2 (RW) Looking at the array above, if the primary server is down, user1 should be able to access is home dir but Read Only whereas user2 should be able to read/write to his home directory. That's exactly what I want. The problem is user2 can only read and not write (il I try ls /afs/.cell, it hangs then says timeout). Is it normal or did I miss a thing? This is normal. That's exactly what you would want if you had a static volume (containing data archives, a software package, etc.) that you wanted to be efficiently accessed from either site. AFS lets you distribute and serve such volumes efficiently. Home directories are not static, and are not good candidates for replication. The only real answer here is the same for almost any other file system housing a user's home directory: if you want to keep the directory accessible, keep the server running. In other words, this is not the problem that AFS solves. Second question, I don't know what to set their homedirectory to (read from LDAP at login), do I have to use /afs/_cell_/usr/homes/user1 or /afs/_.cell_/usr/homes/user1. The former. If you set it to the latter, and the server containing the RW volume (the one you get when you use the '.') is down, you're still in the same boat: the user's home directory is still not available. [Completely aesthetic aside: I'd make it home, not homes. But hey, it's your cell!] If I use the former, when both servers are running they can't write to their directory, they have to cd to /afs/.cell/usr/homes/user1 in order to write which is not practical; if I use the latter, it works all right when both servers are running but when the primary is down, it fails to acces the home directory (server timeout, the branch /afs/.cell is down). This has to do with the servers not being able to reach a quorum when one goes down. You need three or more servers for that to work. But that isn't going to solve the home directory accessibility problem. * Any RW volumes on a down server are going to be inaccessible. * Don't replicate volumes with dynamic data (like home directories). * The highest availability of AFS volumes is achieved through the use of reliable servers, not through replication. Did someone ever try to set up such a network, or is it impossible? Many have tried to solve the availability problem with replication. None have succeeded. Could you tell me then how should I mount my tree? You had it right to start with. The problem is you don't have enough servers to reach a quorum when a server goes down. I think my problems come from the .cell and cell, I don't quite understand the impact it has on the rest of the tree. As you descend your tree, you're looking at RO volumes unless/until you hit a RW volume that isn't replicated. From that point downward, you're looking in the RW volumes. Using the .cell forces your topmost access in your tree to be RW, so you're looking at RWs from there on down. Generally, you want to use RO wherever possible because you can distribute them among servers (and, thus, distribute the load among servers). But some leaf volumes in your tree just don't lend themselves to replication because the files and directories are just too dynamic, so replication becomes impractical. The art in setting up
Re: [OpenAFS] HP-UX file systems on client
rogbazan wrote: Hi, i´m installing a client on a HP-UX, i knew that the file system type where /usr/vice and /usr/vice/etc will be has to be (and only) hfs, is that correct? Could i create those dirs on a volume manager FS? This is my first time on the issue (HP-UX). I´ve been trying to find that info on the documentation, but nothing. Please help me. thanx a lot. http://grand.central.org/twiki/bin/view/AFSLore/SupportedConfigurations is supposed to have all the known-to-work and known-to-fail file system types for both client caches and server /vicepXes. It's probably pretty close to correct, but I see vxfs listed as working for sun4x_5[789] client caches while vxfs (HP-UX, Solaris) is listed under These Don't Work for client caches. Would somebody who knows the status of vxfs for client cache on Solaris please update the above linked twiki page? -- +--+ / [EMAIL PROTECTED] 919-962-5273 http://www.unc.edu/~utoddl / /Banning the bra was a big flop. / +--+ ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Linux client and find command in AFS
Rodney M Dyer wrote: At 01:49 PM 4/5/2005, Derrick J Brashear wrote: use the -noleaf option to find. it's not an afs bug, so you found no bug. Actually, why isn't this a bug? He doesn't need the -noleaf option if there is at least one other real directory in the root of the directory he is testing. Because that just masks the problem; it didn't make it go away. The real problem is that 'find' assumes there is a . and .. entry in every directory, so for a directory with n directory entries, 'find' only recurses through n-2 entries because somebody thought the miniscule efficiency of actually checking if the directories it was skipping were . and .. would outweigh the hours upon hours of time lost by newbies to this problem. When 'find' encounters a directory where there aren't . or .. entries (like the root of afs volumes), it does the wrong thing. It would fail on any filesystem that didn't have those entries because it assumes something that isn't true. The '-noleaf' hack glosses over the problem rather than fixes it. -- +--+ / [EMAIL PROTECTED] 919-962-5273 http://www.unc.edu/~utoddl / /I used to be a lumberjack, but I just couldn't hack it, / / so they gave me the axe. / +--+ ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] OpenAFS dup partition to different servers
Andrew Velikoredchanin [EMAIL PROTECTED] wrote: This meen - I can not update files on replication valumes? That's correct. I need generaly add new files and remove old files on this valumes - no need change files. It doesn't matter. The replication is not at the file level, it's at the volume level. When you replicate a volume, a snapshot is taken of the whole volume, and that gets sent out to all the servers that host one of the read-only replicas. (There was some talk about only sending out deltas if the volume had been replicated before, but I don't think that's been implemented.) Frankly, replication may not seem very important to you if you only have one or two servers and not many users. We have thousands of users and dozens of servers. When we install a software package in our cell, we create a volume just for that package, get it all configured and built and installed so it works properly in AFS, then we replicate it to at least four servers. When a client goes to use that package, it might use any one of those four servers, and if one happens to be down (which almost never happens -- are servers are typically up 200 to 300 days at a time) the client using one of those servers for that package quietly fails over to another server, and the user typically never knows something went wrong. The real beauty comes in when we go to update or reconfigure a package, or change some of its default settings. We can play with the read-write copy all we want, break it a few times and fix it, all without impacting users who are using the read-only replicas because those haven't changed. Once we get it like we want it, we do the vos release volume.name -verbose thing and everybody picks up the changes. That's what replication gets you. It doesn't do anything about solving the how do I write to files when the server hosting those r-w files goes down problem. It seems like everybody wants multiple read-write volumes when they first encounter AFS, but it doesn't work that way. If it did, then the servers hosting the r-w volumes would have to be in constant contact with each other, and performance would be terrible. You really don't want that. You don't even want to want that. :( May by you know - what distributed filesystems support rw replications? As far as I know, none. Not any. It's a really hard problem. Think about the failure modes and what the servers would have do to -- reliably -- in the background to make that work. It's the reliably part that makes it almost impossible. The reason you want rw replicas is because you're worried that something will fail. But if something's failing, it's likely to keep the servers from coordinating updates anyway. Think about it: for multiple r-w to work, a whole lot more has to work than simply keeping one rw server working; multiple servers have to keep working as well as the interconnects between them. And what about when one client is updating a file on one server, and another client is updating _the same file_ through another server? The coordination problems would be enormous. It just isn't worth the complexity. You (as a network/file system administrator) are better off having a robust single server that either works (and therefore doesn't lose users' data) or fails outright (and doesn't lose users' data). The added complexity of having multiple servers trying to coordinate disparate writes greatly increases the risk of users losing data. Replication is a great way to spread out access (and thus load) to static parts of your tree among multiple servers, but that's all it does. OK. I undestend. Replications in OpenAFS usage for load balancing. Right. But as handy as replication is, there are other things that make AFS cool. Users can create their own groups, add whomever they want to them, and set directory ACLs to do just the right level of protection. You, as the administrator, can get out of the managing-groups-for-users business. (You still might manage some groups for administrative purposes, but that's different.) Also -- this is the coolest thing in AFS from my perspective (as one who has to deploy packages for multiple architectures) -- the @sys macro allows you to have architecture-specific things show up in the directory tree in the same place regardless of what type of system you are on. For example, in our cell (isis.unc.edu), we have a bunch of packages installed in our /afs/isis.unc.edu/pkg directory (or just /afs/isis/pkg for short). Take as a typical package ne -- a little text editor that I maintain locally. It's available for 9 different architectures in our cell. But no matter which type of system you login to, the full path is /afs/isis.unc.edu/pkg/ne/bin/ne. How? Well, first, /afs/isis/pkg/ne is a symbolic link to /afs/isis/pkg/ne-136. BTW, older versions -- ne-119 and ne-133 -- are still around if anybody's interested. Without the version number on any of our packages, you
Re: [OpenAFS] Question about append-only directories and ownership of files
Derrick J Brashear wrote: On Tue, 22 Mar 2005, Bob Cook wrote: On Monday, March 21, 2005, Todd Lewis wrote: Not quite. The owner of a directory has implied administrator rights in that directory. [...] although Todd is right about the behavior, Derrick Brashear acknowledged at last year's Best Practices workshop that the behavior is a bug. The intent was that the owner of the top directory in a volume have implicit admin rights in the volume, but not that the owner of each directory have such rights in their directories. (Derrick: Any guess as to when this will be fixed? It looks like people are getting used to it, which I would claim is a not-good thing!) IIRC it's been fixed in 1.3 for months. Great! However, people use the list archives as canonical information (probably because patching docs just isn't as interesting as patching code; go figure). In https://lists.openafs.org/pipermail/openafs-info/2001-July/001623.html, Jeffrey Hutzelman gave a nugget of cleanly distilled information that clearly deserves to be updated on the list and put into the wiki. He said: FWIW, there are three cases where someone gets implicit 'a' rights: - the owner of a directory gets implicit 'a' rights on that directory - the owner of a volume (same as the owner of its root directory) gets implicit 'a' rights on every directory in that volume. - members of system:administrators get implicit 'a' rights on every directory in every volume In light of the fixes in 1.3, would somebody be willing to amend this information so that (1) the list has the corrected/updated info somewhere in its archive and (2) we've got something concise to put into the wiki? Free karma boost for any takers... :-) Q. Where is this enforced? Specifically, what's different about implicit 'a' rights if somebody is running a 1.2 server with a 1.3 client? How about a 1.3 server and a 1.2 client? Mixed servers? Other relevant factors? -- +--+ / [EMAIL PROTECTED] 919-962-5273 http://www.unc.edu/~utoddl / / If you don't pay your exorcist you get repossessed. / +--+ ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] ports used by OpenAFS?
[EMAIL PROTECTED] wrote: Hello everybody, I'm setting up an OpenAFS-cell, now I want to configure my firewall but don't know wich ports are used by OpenAFS. Can someone help me? You didn't indicate what type of firewall you are configuring. However, here are the relevant lines from my /etc/sysconfig/iptables file on a RedHat 9 AFS client-only system. Perhaps this will at least give you some hints: :KERBEROS-INPUT - [0:0] :AFS-INPUT - [0:0] -A INPUT -j KERBEROS-INPUT -A INPUT -j AFS-INPUT -A AFS-INPUT -p udp -m udp --dport 7001 --sport 7000 -j ACCEPT -A AFS-INPUT -p udp -m state --state ESTABLISHED \ -m udp --sport 7002:7009 --dport 1025: -j ACCEPT -A KERBEROS-INPUT -p udp -m state --state ESTABLISHED \ -m udp --sport kerberos --dport 1025: -j ACCEPT -A KERBEROS-INPUT -p udp -m state --state ESTABLISHED \ -m udp --sport kerberos4 --dport 1025: -j ACCEPT -A KERBEROS-INPUT -p udp -m state --state ESTABLISHED \ -m udp --sport krb524 --dport 1025: -j ACCEPT And is it possible to specify the processes that use these ports? Not that I'm aware of, but that would depend on your firewall. Thanx! Greetz Loretto -- +--+ / [EMAIL PROTECTED] 919-962-5273 http://www.unc.edu/~utoddl / +--+ ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Question about append-only directories and ownership of files
Dexter 'Kim' Kimball wrote: In general AFS doesn't care about ownership/mode bits -- ignores them entirely on directories, Not quite. The owner of a directory has implied administrator rights in that directory. That may be relevant here. Or not. Whatever. -- +--+ / [EMAIL PROTECTED] 919-962-5273 http://www.unc.edu/~utoddl / / Bakers trade bread recipes on a knead to know basis. / +--+ ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Evaluating OpenAFS: Questions
Jeffrey Altman wrote: Rolandas Naujikas wrote: P.S. Sorry for not be able support the efforts to improve code, but I have too much work. I'm not sympathetic. We all have too much work. If you are going to rely on an open source technology and its community to provide services to your end users, then you should find the time to help. This is my personal opinion and I know there are others here that disagree with me. At the risk of sounding waffle-ish in what amounts to a me too post (and knowing full well I have not contributed code to OpenAFS in a long time), let me just chime in here and say... You're both right! We all have too much work to do. Not taking the time to report bugs insures that all of us will spend more time dealing with the consequences of old bugs rather than moving on to more interesting problems. In other words, you have too much work to justify _not_ supporting efforts to improve code -- i.e. reporting bugs with the tools provided. Um, yeah. Me too. -- +--+ / [EMAIL PROTECTED] 919-962-5273 http://www.unc.edu/~utoddl / / A chicken crossing the road is poultry in motion. / +--+ ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] PTS groups
Derek Atkins wrote: Matthew Cocker [EMAIL PROTECTED] writes: v) are groups of groups possible? I know there were patches available to make this happen. I do not know if they were ever merged back into the openafs mainline. Wow. Was this a server- or client-side thing? Would this cause strangeness in a mixed OpenAFS/TransarcAFS environment (like ours), our would groups-of-groups play nice but with limited utility on the TransarcAFS clients? -- +--+ / [EMAIL PROTECTED] 919-962-5273 http://www.unc.edu/~utoddl / / The man who fell into an upholstery / / machine is fully recovered. / +--+ ___ OpenAFS-info mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Read-only issues
Derek Harkness wrote: Correct I'm replicating my home volumes. My solution to not having read-write replication is just releasing the volumes every couple of minutes or whenever they need to be released. [Sigh] This is not recommended. But if that isn't possible or not recommended then AFS is really quite useless for user home directories. Actually, AFS is really quite usefull for user home directories for a host of reasons you may not be aware of yet. But it doesn't do what you're trying to do in this case. The whole we're moving to AFS was to offer fully redundant home space, if a server crashed the rw volumes on would go off-line and the users would switch to the read-only copies allowing them to at least read the files. That would be a good solution if (1) servers were unreliable enough to justify that kind of effort and (2) AFS worked that way. Neither of those things is true. -- +--+ / [EMAIL PROTECTED] 919-962-5273 http://www.unc.edu/~utoddl / / My wife really likes to make pottery,/ /but to me it's just kiln time./ +--+ ___ OpenAFS-info mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Pro's Con's of /usr/local on AFS....
Jeffrey Hutzelman wrote: [...] Don't use them in [...] email messages [...]. Otherwise you _will_ regret it later. Yup. I sure do regret putting one in the email to this list that lit the fuse on this discussion. My mozilla's delete button is 'bout wore out. -- +--+ / [EMAIL PROTECTED] 919-962-5273 http://www.unc.edu/~utoddl / / Energizer Bunny arrested - charged with battery. / +--+ ___ OpenAFS-info mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Pro's Con's of /usr/local on AFS....
Joshua Johnson wrote: So, at the risk of starting something here, I am going to ask what other peoples experiences are with placing /usr/local in AFS and sharing among machines of same @sys type (much like the AdminGuide suggests). I think it depends on how much administrative control you expect to have over the machines in your local cell. When we first put our cell together, we had complete control and put /usr/local in AFS. (We made a complete mess of it, too, but it was totally our mess, so we could deal with it. That's another story though.) Eventually, however, other research groups and departments joined the cell and local admins had their own notion of what the local in /usr/local meant. At least one group already had a shared /usr/local that wasn't in AFS... So we bit the bullet and converted everything to what in retrospect seems an obvious better alternative. /afs is a global name space, and as Jim Rees already pointed out, packages have to be tweaked to work well in almost any non-default tree. So we make our stuff self consistent in the /afs tree without trying to make it look like part of something more familiar. It's the only name space where we can be sure of not colliding with a local system or system administrator. Draw your own conclusions, your millage may vary, etc., but we're happy with what we've got now. I don't want to create too large of a thread so if this has been discussed, and there are pointers to studies/whitepapers/etc., please feel free to post/send links to me. I don't know of any, but it sounds like a good topic for a wiki page. Go for it. At the risk of bloating an already too long message, here's how we put packages together in our cell. Let's take the case of ne (yet another text editor that I happen to have contributed code to; std. self horn-blowing disclaimers here, see http://ne.dsi.unimi.it/ if you're that bored). In our cell, /afs/isis/pkg/ne/bin/ne is the path to the current default ne binary regardless of the architecture you happen to be on. '/afs/isis' is a symbolic link, leading to a mount point for volume 'root.cell'. /afs/isis/pkg/ne is a symbolic link to /afs/isis/pkg/ne-136, 'cause 1.36 is the current version. There's also ne-119 and ne-133 in /afs/isis, so we're doing package versioning that way. Each of those is a mount point for the volumes pkg.ne-119, pkg.ne-133, and pkg.ne-136. The directory structure within, say ne-136 looks like this: lrwxr-xr-x bin - .install/@sys/bin lrwxr-xr-x build - .build/@sys drwxr-xr-x .build lrwxr-xr-x common - .install/common lrwxr-xr-x dist - .build/dist lrwxr-xr-x doc - .install/common/doc lrwxr-xr-x etc - .install/@sys/etc lrwxr-xr-x include - .install/@sys/include drwxr-xr-x .info lrwxr-xr-x install - .install/@sys drwxr-xr-x .install lrwxr-xr-x lib - .install/@sys/lib lrwxr-xr-x libexec - .install/@sys/libexec lrwxr-xr-x man - .install/common/man lrwxr-xr-x sbin - .install/@sys/sbin lrwxr-xr-x share - .install/common/share lrwxr-xr-x src - .build/src The extensive use of the @sys macro and symbolic links lets us keep architecture specific stuff separate, but use the same paths anyway. Note that '.build' is a mount point for volume 'pkg.nE-136', which is not replicated since it only contains what we need to build the package and isn't used otherwise. Volume pkg.ne-136 is replicated. Of course, this is way to complicated to do by hand; we've got a script that sets this structure up and handles the tricky parts. (It's at /afs/isis.unc.edu/pkg/admin/bin/pkg if you want it, but be warned it taylored for our cell.) We've currently got about 314 packages built this way, most of which have more that one version online. It's a pain to manage (and not my pain btw; somebody else in our group handles most of it), but per package deployment effort on individual machines is zero most of the time. -- +--+ / [EMAIL PROTECTED] 919-962-5273 http://www.unc.edu/~utoddl / / A hangover is the wrath of grapes. / +--+ ___ OpenAFS-info mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Pro's Con's of /usr/local on AFS....
Jim Rees wrote: '/afs/isis' is a symbolic link, leading to a mount point for volume 'root.cell'. So you broke one of the most important features of afs, the global name space. Why? 'Cause we're stupid? 'Cause I didn't want to make an already too long message even longer? Actually, we thought it was convenient at first, and it's come back to bite us repeatedly. We try very hard to make all the references in packages spell the cell name out -- isis.unc.edu -- and I think we've got it that way almost everywhere. It's convenient not to type .unc.edu a couple hundred times a day. Whether it's worth it is an open question. (BTW, '/afs/isis.unc.edu' is also a mount point for volume 'root.cell'.) -- +--+ / [EMAIL PROTECTED] 919-962-5273 http://www.unc.edu/~utoddl / / A man's home is his castle, in a manor of speaking. / +--+ ___ OpenAFS-info mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] pts and nsswitch
This is a follow-up to a message (below) from September 2002, in case anybody is interested. As of this morning the nsswitch module mentioned below now works with Solaris as well as Linux. I randomly bumped the version from 0.1 to 0.2 to confuse the innocent. Grab http://www.unc.edu/~utoddl/nss_pts_0.2.tgz if you're interested. It's GPL'd, 'cause it uses code from samba, so I don't know how that mixes/matches with other OpenAFS contribs. Just do the Right Thing. Happy computing, -- [EMAIL PROTECTED] In September, 2002, Todd M. Lewis wrote: Greetings, I've often wished ls -l would list the pts names of files' owners instead of their uids for people not in my password file. So I wrote up http://www.unc.edu/~utoddl/nss_pts_0.1.tgz which implements a simple now http://www.unc.edu/~utoddl/nss_pts_0.2.tgz Unpack in AFS for that wholesome @sys goodness. :-) nsswitch module that does exactly that. At least it does on Linux, and it might on Solaris, though I don't have a Sun box I can hack on to thrash out the details. [FYI: nsswitch in a nutshell is a set of hooks into how the system looks up things -- about users, groups, hosts, services, networks, whatever. nss_pts adds a hook that makes getpwuid() know how to look in your cell's ptserver if it can't find the uid in, for example, /etc/passwd and NIS.] In retrospect, I'm not so sure this was a good idea, but I'm putting the code out there in case someone else wants to play with it and doesn't want to start from scratch. Go ahead; knock yourself out. So why isn't this such a good idea? Well, for one thing, if you're looking at files in some other cell, it still does the lookups against your ptserver. Also, if a uid happens to map to one of your cell's non-null instances, then you might get back a struct passwd with a pw_name that's longer than 8 characters, which could cause some programs to choke. N.B.: It now truncates the pw_name to 8 characters. I've been running this thing several days and it hasn't caused me any problems that I know of, but I wouldn't want to deploy a production server based on that. Well, actually, we have deployed it on production servers since then, and they seem happy. Think of it as a proof of concept -- maybe an ill-conceived one -- but it sure adds some meaning to most of my ls snooping around my cell. And if someone gets it working under Solaris, I'd like to know what you did. As mentioned above, it now works on Solaris. The trick is/was, Solaris has a couple of additional fields (pw_comment and pw_age) that needed to be initialized to keep nscd from dying. It's happy now. Happy computing, -- +--+ / [EMAIL PROTECTED] 919-962-5273 http://www.unc.edu/~utoddl / / A hangover is the wrath of grapes. / +--+ ___ OpenAFS-info mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] 'split' a tree of directory into volumes?
Lester Barrows wrote: [... good stuff about 'up' not preserving directory timestamps...] It seems to work as-is, but begs the question: If it's that easy, do you (or does anyone) know why this isn't done already? Sure: Nobody's contributed the code. Seriously. When I added the bits to make it aware of mount points, I had a particular itch to scratch that day. The fact that directory time stamps weren't preserved just didn't itch me then, and evidently hasn't bothered anybody else enough to do something about it... ...until you came along, of course! I'm looking forward to your patches. :-) Is there a reason that in general we don't want to preserve directory timestamps when duplicating a directory? Or is it possible for this to somehow blow up on me in an obscure fashion? :-) I can't think of any reason not to preserve timestamps. OTOH, I couldn't imagine why you'd ever want the old, non-mount point aware behavior either, but I made it an option with the old behavior as the default anyway. I guess that was not to surprise either one of the regular 'up' users who might have a script that depends on the old behavior. I still can't decide if that was a mistake. Does 'up' preserve timestamps on files? If so, it should preserve them on directories too. My opinion, ymmv, etc. Cheers, Regards, Lester Barrows Asani Solutions, LLC Code IC Systems Group NASA Ames Research Center Voice: 650-604-2639 -- +--+ / [EMAIL PROTECTED] 919-962-5273 http://www.unc.edu/~utoddl / / A gossip is someone with a great sense of rumor. / +--+ ___ OpenAFS-info mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] OpenAFS volumes filesystem
http://grand.central.org/twiki/bin/view/AFSLore/AdminFAQ#3_29_What_underlying_filesystems http://grand.central.org/twiki/bin/view/AFSLore/SupportedConfigurations yam wrote: Hello, I'm starting up an OpenAFS installation, and I've arrived to my first dilema... What filesystem to use for openafs volumes? Ext2? Ext3? ReiserFS? XFS? Any hint? Shouldnt use any of the above? beter performance with any of those? Only ext2 is the way to go? Thanks in advance. PD: Haven't found information about this anywhere. /Yam ___ OpenAFS-info mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-info -- ++ / [EMAIL PROTECTED] http://www.unc.edu/~utoddl / /(919) 962-5273 Linux - It's now safe to turn on your computer. / ++ ___ OpenAFS-info mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-info
[OpenAFS] Re: State of OpenAFS
Todd M. Lewis wrote: Wout Mertens wrote: Anything else that is different versus 'regular' unix filesystems? * ACLs apply to whole directories * Only the first 3 bits of a file's permissions are relevant (which gives you 6 free bits to do with whatever crazy things you want -- not that I'd ever do such a thing :-) * A cell-wide switch for support of AFS suid/sgid executables * volume mount points are just specially formatted symlinks, so volumes can be mounted almost anywhere any number of times * @sys macro expansion makes serious architecture magic possible * PTS cool/weird (groups in groups, IP ACLs, user-defined groups) I left out one that really came as a shocker the first time I encountered it: * AFS does not update/maintain last access times. Cheers, -- ++ / [EMAIL PROTECTED] http://www.unc.edu/~utoddl / /(919) 962-5273 Linux - It's now safe to turn on your computer. / ++ ___ OpenAFS-info mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] small problems with openafs rpm, 1.2 w/ redhat 7.1
[EMAIL PROTECTED] wrote:
I believe kpasswd should be kapasswd. kpwvalid is because I don't have
the server installed.
kpwvalid is used by kapasswd to ensure the new password meets
requirements of the local site. By default, it only tests password
length, but you could add further tests (as we have done on occasion).
If I recall correctly, it only comes into play if it's in the same
directory as the kapasswd program and that directory is only writable by
system:administrators.
[...] I assume up might be one of the up commands in the server
(upclient, upserver)
The 'up' utility is a recursive cp that copies ACLs as well as
files/directories. I presume it's called up because by default it has
the nasty side effect of sucking up entire volumes mounted under
volumes mounted under volumes and spitting the whole sucked up tree into
the target volume/directory. Later versions in OpenAFS have a switch
('-m' I believe) that causes 'up' to recognize and duplicate mount
points rather than traversing them like plain old directories.
--
++
/ [EMAIL PROTECTED] http://www.unc.edu/~utoddl /
/(919) 962-5273 Lord, give me patience... Now! /
++
___
OpenAFS-info mailing list
[EMAIL PROTECTED]
https://lists.openafs.org/mailman/listinfo/openafs-info
