Re: [OpenAFS] Pro's Con's of /usr/local on AFS....
Norman, There's nothing wrong with a short name symlink to your cell's fully qualified path per se, but it's incredibly difficult to keep it from creeping into places is shouldn't be: hard-coded paths in package builds, scripts, documentation and services that might eventually be available to -- but broken for -- people coming in from foreign cells. If you don't believe me, and your cell has been up for any length of time (like since before breakfast), try deleting that link for a day and see how much stuff quits working. That's what you're going to run into when your visit another site and say to your new friends there Let me show you how we do thus-n-such in our cell, authenticate to your cell, cd there, and try to run something. Been there, got the t-shirt. It doesn't make for a good demo. -- [EMAIL PROTECTED] (who first posted the line below that Jim Rees replied to, not that I'm proud of it. Ugh, on the contrary.) Norman P. B. Joseph wrote: Excuse me for being dense, (and I was in one of those Transarc training classes back in the day), but what's the harm in that symbolic link? -norm On Wed, 2004-10-27 at 11:34, Mitch Collinsworth wrote: On Wed, 27 Oct 2004, 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? Huh? Transarc trainers specifically taught to do exactly this 15 years ago. The recommendation was there to still use the FQDN in all symlinks, scripts, etc. But it was recommended to have it for typing ease. Remember /afs/tr ? -Mitch ___ OpenAFS-info mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-info ___ 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....
Excuse me for being dense, (and I was in one of those Transarc training classes back in the day), but what's the harm in that symbolic link? -norm On Wed, 2004-10-27 at 11:34, Mitch Collinsworth wrote: On Wed, 27 Oct 2004, 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? Huh? Transarc trainers specifically taught to do exactly this 15 years ago. The recommendation was there to still use the FQDN in all symlinks, scripts, etc. But it was recommended to have it for typing ease. Remember /afs/tr ? -Mitch ___ OpenAFS-info mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-info -- Norman Joseph, System Engineer [EMAIL PROTECTED]IC|XC Concurrent Technologies Corporation 814/269.2633 --+-- Federal Systems Group/IT Systems Engineering NI|KA * If we don't change the direction we are headed, * we will end up where we are going. ___ 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....
* Derek Atkins [2004-10-28 00:18:36 -0400]: tab requires stat'ing the directory which has always been a no-no in /afs... With dynroot it's a bit better, but it's still an issue if you're not using dynroot. I think you meant to write fakestat instead of dynroot. ___ 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....
On Wednesday, October 27, 2004 12:37:52 -0400 Derrick J Brashear [EMAIL PROTECTED] wrote: On Wed, 27 Oct 2004, Derek Atkins wrote: Jim Rees [EMAIL PROTECTED] writes: 3. (Optional) Create a symbolic link to a shortened cell name, to reduce the length of pathnames for users in the local cell. For example, in the abc.com cell, /afs/abc is a link to /afs/abc.com. That really needs to be removed from the documentation. Why? It's extremely useful. I like using /afs/athena, /afs/dev, /afs/sipb Which cell is /afs/cs? Mine, obviously. :-) But that doesn't make tab-completion work for me. Seriously, having short-name aliases in /afs is convenient for typing commands interactively, but such names should _never_ be used in any kind of reference that is expected to be portable. Don't use them in scripts, or programs, or symlinks, or email messages, or IM, or anyplace else where they might be used other than on your workstation the way it looks right now. Otherwise you _will_ regret it later. -- Jeff ___ 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: Mount points is worse. At least with a symlink you can pwd and get a correct global name. But if you are going through a local mount point, that won't work. Ken Hornstein and I checked the Unix dynamic roots mode. It supports a static symlink like functionality through the CellAlias file. This allows you to name/value pair which points to a complex path. Symlinks can also be created on the fly for the length of the current session. For Windows, I have now added the ability to use the symlink.exe tool to create symlinks to directories and files. These will be maintained in the registry to survive service session restart. Jeffrey Altman smime.p7s Description: S/MIME Cryptographic Signature
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....
'/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? ___ 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] Pro's Con's of /usr/local on AFS....
Todd M. Lewis wrote: 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). Rather then /usr/local we have a /usr/afsws/local where /usr/afsws - /afs/anl.gov/@sys/usr/afsws. We have a local volume for each arch. Users then just add /usr/afsws/local/bin in their path. We use depot to populate local volume with symlinks into AFS. This does require us to build the packages and to use --prefix and DESTDIR= to get all package references to point into AFS, but depot has made this quite easy. For security realted or packages including shared libs, we have these local on a machine. -- Douglas E. Engert [EMAIL PROTECTED] Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 ___ 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....
Todd M. Lewis wrote: 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? 'Cause you followed the documentation? http://www.openafs.org/pages/doc/QuickStartUnix/auqbg002.htm#ToC_87 3. (Optional) Create a symbolic link to a shortened cell name, to reduce the length of pathnames for users in the local cell. For example, in the abc.com cell, /afs/abc is a link to /afs/abc.com. Steve - Stephen G. Roseman Lehigh University [EMAIL PROTECTED] ___ 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....
3. (Optional) Create a symbolic link to a shortened cell name, to reduce the length of pathnames for users in the local cell. For example, in the abc.com cell, /afs/abc is a link to /afs/abc.com. That really needs to be removed from the documentation. ___ 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....
On Wed, 27 Oct 2004, 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? Huh? Transarc trainers specifically taught to do exactly this 15 years ago. The recommendation was there to still use the FQDN in all symlinks, scripts, etc. But it was recommended to have it for typing ease. Remember /afs/tr ? -Mitch ___ 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....
That really needs to be removed from the documentation. I don't agree at all. It's listed as optional and has been there for ages. It perhaps needs additional wording about the ramifications, but should not be deleted IMO. Not a single cell in our internal network will ever participate in the global AFS namespace. We've used that optional step as part of our cells for 12 years now. Global namespace as one of the most important features of AFS is incredibly subjective. ___ 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 [EMAIL PROTECTED] writes: 3. (Optional) Create a symbolic link to a shortened cell name, to reduce the length of pathnames for users in the local cell. For example, in the abc.com cell, /afs/abc is a link to /afs/abc.com. That really needs to be removed from the documentation. Why? It's extremely useful. I like using /afs/athena, /afs/dev, /afs/sipb -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available ___ OpenAFS-info mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Pro's Con's of /usr/local on AFS....
Derek Atkins wrote: Jim Rees [EMAIL PROTECTED] writes: 3. (Optional) Create a symbolic link to a shortened cell name, to reduce the length of pathnames for users in the local cell. For example, in the abc.com cell, /afs/abc is a link to /afs/abc.com. That really needs to be removed from the documentation. Why? It's extremely useful. I like using /afs/athena, /afs/dev, /afs/sipb Is there a good reason why /afs/athena should be a symlink and not a second mount point? Something that has come up with respect to the use of dynamic roots is that the dynamic roots support mountpoints but not symlinks. Organizations which have symlinks in their root.afs find using dynamic roots on laptops to be extremely difficult if not impossible. Some organizations have done something similar to Doug except that instead of /usr/afsws - /afs/anl.gov/@sys/usr/afsws being a symlink in the local file system they are creating afsws - anl.gov/@sys/usr/afsws in the root.afs volume. Maybe the answer is to add symlink support to dynamic roots but I think we want to document that this kind of setup should be avoided. Or am I completely nuts? Jeffrey Altman smime.p7s Description: S/MIME Cryptographic Signature
Re: [OpenAFS] Pro's Con's of /usr/local on AFS....
Mount points is worse. At least with a symlink you can pwd and get a correct global name. But if you are going through a local mount point, that won't work. ___ 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....
On Oct 27, 2004, at 5:34 AM, Todd M. Lewis wrote: 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... That's really the age-old question of what does the local in /usr/local mean? The last two places that I have worked have decided that: - /usr/local means local to the corner of the network we control. It points into a particular spot in our AFS cell isn't advertised to the other departments (and that we refuse to answer questions about if they find it). - Some people insist that it should be local to the machine itself ... for that we use /local. Those utilities are installed on the machine itself, and are things that we feel should NEVER live in any kind of network location (kerberos and ssh being the big ones, but also things which are essential to the stand-alone operation of the system so that it doesn't hang or become useless if AFS goes down, or becomes unreachable, for those systems we feel need to stay up even when AFS is down). - For local to the larger concept of our site and things we have to let sysadmins and maybe users in other departments look at, there's something that gets referenced as /usr/athena which is then a symlink out into AFS space. It's called that because we have been using athena, but in the future we could decide to call it /usr/ucsc or something. Putting the 1st and 3rd out in AFS has worked pretty well for us. What didn't work for us was having certain key utilities in AFS (before I got here, the /local thing didn't exist, yet we had machines leaving a lot of their main functionality out in AFS, which caused us no end of headaches -- not being able to access a machine to shut it down because its kerberos libraries are out in AFS , and there's some problem interfering with the network which keeps it from accessing its kerberos libraries, is just WRONG). ___ 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....
On Wed, 27 Oct 2004, Derek Atkins wrote: Jim Rees [EMAIL PROTECTED] writes: 3. (Optional) Create a symbolic link to a shortened cell name, to reduce the length of pathnames for users in the local cell. For example, in the abc.com cell, /afs/abc is a link to /afs/abc.com. That really needs to be removed from the documentation. Why? It's extremely useful. I like using /afs/athena, /afs/dev, /afs/sipb Which cell is /afs/cs? ___ 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....
Something that has come up with respect to the use of dynamic roots is that the dynamic roots support mountpoints but not symlinks. Organizations which have symlinks in their root.afs find using dynamic roots on laptops to be extremely difficult if not impossible. There is (at least on Unix systems) a CellAlias file for use with dynroot. We use that for a few local cells. --Ken ___ 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....
Derrick J Brashear [EMAIL PROTECTED] writes: Which cell is /afs/cs? That's local policy. But that's fine. Real references should use the full path. The shorthand is for user convenience. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available ___ OpenAFS-info mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Pro's Con's of /usr/local on AFS....
Todd M. Lewis [EMAIL PROTECTED] writes: 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'.) And I thought that was what the TAB key was for. -- /Ian D [EMAIL PROTECTED] - www.assv.net ___ 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....
Ian Delahorne [EMAIL PROTECTED] writes: Todd M. Lewis [EMAIL PROTECTED] writes: 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'.) And I thought that was what the TAB key was for. tab requires stat'ing the directory which has always been a no-no in /afs... With dynroot it's a bit better, but it's still an issue if you're not using dynroot. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available ___ OpenAFS-info mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Pro's Con's of /usr/local on AFS....
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). We've always run that way. The biggest problem, at least on OpenBSD, is that ports and packages like to install into /usr/local (that's good) but then keep some important info about the installation in /var/db (that's bad). We deal with this manually but you really should fix the ports and packages. Other minor problems include apps that install into /usr/local but keep little pieces elsewhere (/etc/gimp). And sometimes you'll find machine dependent stuff installed into /usr/local. So it's possible, and it's certainly more convenient than keeping a separate /usr/local on each machine. But you will run into irritating problems. ___ OpenAFS-info mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-info
