Hi Stefan, I just had installed this softlinks ebuild package but was surprised to have this: >>> Merging net-fs/openafs-legacy-0.1 to / --- /usr/ >>> /usr/vice/ >>> /usr/vice/etc -> /etc/openafs >>> /usr/afs/ >>> /usr/afs/bin -> /usr/libexec/openafs >>> /usr/afs/etc -> /etc/openafs/server >>> /usr/afs/local -> /var/lib/openafs >>> /usr/afs/db -> /var/lib/openafs/db >>> /usr/afs/logs -> /var/lib/openafs/logs --- /usr/libexec/ --- /usr/libexec/openafs/ >>> /usr/libexec/openafs/bosserver -> /usr/sbin/bosserver --- /var/ --- /var/lib/ --- /var/lib/openafs/ >>> /var/lib/openafs/BosConfig -> /etc/openafs/BosConfig >>> Regenerating /etc/ld.so.cache... >>> net-fs/openafs-legacy-0.1 merged. phylo openafs-1.4.0-rc6 # ls -la /etc/openafs total 220 drwxr-xr-x 3 root root 4096 Oct 9 04:00 . drwxr-xr-x 58 root root 4096 Oct 10 17:32 .. -rw-r--r-- 1 root root 0 Sep 22 18:06 .keep -rw------- 1 root root 0 Sep 22 02:39 AFSLog -rw-r--r-- 1 root root 298 Oct 9 04:00 BosConfig -rw-r--r-- 1 root root 29944 Sep 22 18:06 CellServDB -rw------- 1 root root 16 Sep 22 02:39 KeyFile -rw-r--r-- 1 root root 20 Sep 22 09:54 ThisCell -rw-r--r-- 1 root root 4588 Sep 22 02:39 afs.conf -rwxr-xr-x 1 root root 8392 Sep 22 02:39 afs.rc -rwxr-xr-x 1 root root 137776 Sep 22 02:39 afsd -rw-r--r-- 1 root root 32 Sep 22 17:08 cacheinfo -rw-r--r-- 1 root root 33 Sep 22 17:07 cacheinfo-bad drwxr-xr-x 2 root root 94 Sep 22 02:39 server phylo openafs-1.4.0-rc6 # ls -la /etc/openafs/server/ total 52 drwxr-xr-x 2 root root 94 Sep 22 02:39 . drwxr-xr-x 3 root root 4096 Oct 9 04:00 .. -rw-r--r-- 1 root root 0 Sep 22 18:06 .keep -rw-r--r-- 1 root root 29944 Sep 22 16:51 CellServDB -rw------- 1 root root 16 Sep 22 02:39 KeyFile -rw-r--r-- 1 root root 19 Sep 22 13:04 ThisCell -rw-r--r-- 1 root root 15 Sep 22 02:39 UserList -rw-r--r-- 1 root root 20 Sep 22 02:39 krb.conf phylo openafs-1.4.0-rc6 # Few comments. 1. The KeyFile is only necessary on the server, not on a client. 2. Why are there two CellServDB file instead of one file and one symlink? Make just CellServDB.sample part of teh install process and ask user to rename the file and make a symlink if it does not exist yet. The user will thus take care whether a server or client or both are running. 3. /usr/vice/etc/modload should be asymlink to some location, so that I could use the old manual installation procedure and the files would overwrite the files in Gentoo FHS places. 4. /usr/afs/logs -> /var/lib/openafs/logs. Why isn't there /var/log/openafs/? 5. /var/lib/openafs/BosConfig -> /etc/openafs/BosConfig Do you mean that '/var/lib/openafs/BosConfig' was the typical OpenAFS location for the config file? I don't think so, I think BosConfig used to reside somewhere else. 6. /usr/libexec/openafs/ also isn't resembling the TransArc original location either.
(In reply to comment #0) > 1. The KeyFile is only necessary on the server, not on a client. I think this is a fault in your local configuration then. The softlink list makes it seem you have a /usr/vice/etc/KeyFile. As /usr/vice/etc is the client configuration directory, according to your own explanation, it shouldn't be there. At least I haven't got it there. Maybe it's a leftover from your earlier installations? If you think this is a failure in the upgrade script, you're welcome to report it as such, but I doubt it. > 2. Why are there two CellServDB file instead of one file and one symlink? > Make just CellServDB.sample part of teh install process and ask user to > rename the file and make a symlink if it does not exist yet. The user will thus > take care whether a server or client or both are running. Personally, I prefer to keep the configuration for client and server quite seperate, so I don't think a symlink is per se the way to go here. The openafs ebuild doesn't put anything in /etc/openafs/server as far as I know. I suppose you had a softlink in /usr/afs/etc previously. In that case, the upgrade procedure has copied the contents, not the link. I think this is desired behaviour, as a link to /usr/vice/etc would turn out to be non-functional after the upgrade. > 3. /usr/vice/etc/modload should be asymlink to some location, so that I could > use the old manual installation procedure and the files would overwrite the > files in Gentoo FHS places. It would be quite cumbersome to do so. We have chosen to put the modules in standard locations, with standard file names. You're asking to create links with names dependant on the kernel version for which openafs-kernel is compiled. This would require the openafs-kernel ebuild to know about openafs-legacy. Do you really need this? I don't see how this symlink could be useful at all. After all, accessing the module is only necessary while starting the openafs client, which is done by the new init script. That init script knows about the FHS layout. > 4. /usr/afs/logs -> /var/lib/openafs/logs. Why isn't there /var/log/openafs/? Because the openafs documentation states that /usr/afs/logs is the transarc path for the logs. Please consult the README or the configure file in the openafs distribution. > 5. /var/lib/openafs/BosConfig -> /etc/openafs/BosConfig > Do you mean that '/var/lib/openafs/BosConfig' was the typical OpenAFS > location for the config file? I don't think so, I think BosConfig used to reside > somewhere else. This may be misleading, but I mean that /usr/afs/local/BosConfig was the transarc location for the config file. As openafs-legacy creates a symlink >>> /usr/afs/local -> /var/lib/openafs this amounts to the same. > 6. /usr/libexec/openafs/ also isn't resembling the TransArc original location > either. This can be, because I suppose you go looking for other server binaries (like bosserver maybe) in /usr/afs/bin as well? All these can currently be found in /sbin. If you think specific symlinks are in order here, you're welcome tell me (please also explain why the symlinks should be that way, point to documentation if possible), and I'll happily include them in the openafs-legacy ebuild. I still have to see the first sensible use of this ebuild. You're still welcome to report binary-only applications or tools that require this ebuild. It would be nice to put them in the ebuild's description. Thanks, Stefaan
>> 1. The KeyFile is only necessary on the server, not on a client. > > I think this is a fault in your local configuration then. The > softlink list makes it seem you have a /usr/vice/etc/KeyFile. As > /usr/vice/etc is the client configuration directory, according to > your own explanation, it shouldn't be there. At least I haven't got > it there. Maybe it's a leftover from your earlier installations? If > you think this is a failure in the upgrade script, you're welcome to > report it as such, but I doubt it. I know why I had to place it there, the -localauth command switches use the file in that location (like bos/vos/fs commands). >> 2. Why are there two CellServDB file instead of one file and one >> symlink? Make just CellServDB.sample part of teh install process >> and ask user to rename the file and make a symlink if it does not >> exist yet. The user will thus take care whether a server or client >> or both are running. > > Personally, I prefer to keep the configuration for client and server > quite seperate, so I don't think a symlink is per se the way to go > here. The openafs ebuild doesn't put anything in /etc/openafs/server > as far as I know. I suppose you had a softlink in /usr/afs/etc > previously. In that case, the upgrade procedure has copied the > contents, not the link. I think this is desired Why doesn't it preserve softlinks? > behaviour, as a link to /usr/vice/etc would turn out to be > non-functional after the upgrade. The softlinks are I think recommended by the official docs to keep the CellServDB files in sync. It must have been in the IBM Install docs. Make the softlinks to the new locations. ;) I think 'basename' and ln -s /etc/openafs/$blah would do. >> 3. /usr/vice/etc/modload should be asymlink to some location, so >> that I could use the old manual installation procedure and the >> files would overwrite the files in Gentoo FHS places. > > It would be quite cumbersome to do so. We have chosen to put the > modules in standard locations, with standard file names. You're > asking to create links with names dependant on the kernel version for > which openafs-kernel is compiled. This would require the > openafs-kernel ebuild to know about openafs-legacy. Do you really > need this? I don't see how this symlink could be useful at all. > After all, accessing the module is only necessary while starting the > openafs client, which is done by the new init script. That init > script knows about the FHS layout. Just point ./modload to the /lib/modules/x.x.x.x/openafs directory. Yes, it would be nice to have the openafs-kernel ebuild to overwrite the modload symlink and point to the current location. >> 4. /usr/afs/logs -> /var/lib/openafs/logs. Why isn't there >> /var/log/openafs/? > > Because the openafs documentation states that /usr/afs/logs is the > transarc path for the logs. Please consult the README or the > configure file in the openafs distribution. Sure, my objection was why did you invent /var/lib/openafs/logs instead of the /var/log/openafs? Just because it is typicall not syslogged? >> 5. /var/lib/openafs/BosConfig -> /etc/openafs/BosConfig Do you mean >> that '/var/lib/openafs/BosConfig' was the typical OpenAFS location >> for the config file? I don't think so, I think BosConfig used to >> reside somewhere else. > > This may be misleading, but I mean that /usr/afs/local/BosConfig was > the transarc location for the config file. As openafs-legacy creates > a symlink > >>>> /usr/afs/local -> /var/lib/openafs > > this amounts to the same. I thought the whole point for the extra package was to make softlinks from the old places and point to the new files. I know it does somehow but what I would be really like to be sure is that I can copy files to the original target location and overwrite the actual FHS-placed files. You know, sometimes I want to install my own files from newer sources but want to overwrite the existing files to be sure I don't end-up with messy installation of two versions. That my objection. As long as I manage to tweak the .ebuild files it is probably not that necessary, but I just thought that this is why you made the openafs-legacy package, right? ;) >> 6. /usr/libexec/openafs/ also isn't resembling the TransArc >> original location either. > > This can be, because I suppose you go looking for other server > binaries (like bosserver maybe) in /usr/afs/bin as well? All these > can currently be found in /sbin. If you think specific symlinks are > in order here, you're welcome tell me I'm perfectly happy with /bin and /sbin if the are no filename clashes ... I just thought we don't need the /usr/libexec/openafs/ at all. > (please also explain why the symlinks should be that way, point to > documentation if possible), and I'll happily include them in the > openafs-legacy ebuild. > > I still have to see the first sensible use of this ebuild. You're > still welcome to report binary-only applications or tools that > require this ebuild. It would be nice to put them in the ebuild's > description. Well, you know I was quite happy with the TransArc paths. But I thought well, I could give you some feedback and see if I could use the legacy package to mimic the old style for myself. Thanks to you as well! P.S.: In general, do whatever you wish with this bugreport, it is just a feedback.
> You know, sometimes I want > to install my own files from newer sources but want to overwrite the existing files > to be sure I don't end-up with messy installation of two versions. That my > objection. As long as I manage to tweak the .ebuild files it is probably > not that necessary, but I just thought that this is why you made the openafs-legacy > package, right? ;) No, I didn't create it so you could try overwriting files installed by the openafs-ebuild by writing files to old locations. It is meant for old applications to find the files in the new places, nothing more, nothing less. Resolving bug as invalid, as I think this is an issue of having different goals.
