> What it means is that if I am going to bring up a cell, I _really_ > want administrative control of the corresponding DNS domain. That relationship between cells and domains has allready grown in a way that this seems to match quite well. The few non matchig cells can be taken care of by a configuration file like CellServDB. If we want OpenAFS fo spread, it is important that new cells can be started without hassle. Step 1 is AFSDB, step 2 is dynroot and step 3 is (as Nathan wrote) some kind of automounter that populates /afs as you go. Example: Think of some guest researcher visiting your facilities. Both places run AFS. With steps 1 to 3 enabled as above the guest researcher can find his files without needing to bother any sysadmins at all. I'd like that. Harald.
- Re: AFS backup/restore using ADSM Russ Allbery
- Re: AFS backup/restore using ADSM Harald Barth
- Re: AFS backup/restore using ADSM Russ Allbery
- Re: AFS backup/restore using AD... Susan Feng
- Re: AFS backup/restore usin... Nathan Neulinger
- Re: AFS backup/restore usin... Harald Barth
- Re: AFS backup/restore usin... Earl R Shannon
- Re: AFS backup/restore usin... David Thompson
- Re: AFS backup/restore usin... Harald Barth
- Re: AFS backup/restore usin... David Thompson
- OpenAFS enhancements wishli... Harald Barth
- OpenAFS enhancements wishli... Mitch Collinsworth
- Re: OpenAFS enhancements wi... Norman P. B. Joseph
- Re: AFS backup/restore usin... Paul Blackburn
- Re: AFS backup/restore usin... Brian T. Huntley
- RE: AFS backup/restore using ADSM Neulinger, Nathan R.
- Re: AFS backup/restore using ADSM David Thompson
- RE: AFS backup/restore using ADSM Mitch Collinsworth
- RE: AFS backup/restore using ADSM Harald Barth
- RE: AFS backup/restore using ADSM Neulinger, Nathan R.
- Re: AFS backup/restore using ADSM Harald Barth
