> I know... and I partially agree. But I think there is > a better solution > for this case. For example the "hosts" database file > lives physically in > /etc/inet/hosts and a symlink at /etc/hosts points to > that file. The > same could be done for "hosts.allow" and > "hosts.deny", e.g. put the > files physically into /etc/inet/ and provide symlinks > from /etc to those > files. That would honor the original SysV design > choice and gurantees > backwards-compatibilty to older Solaris releases and > other platforms > (anyone who wants to sponsor such a change/patch > please raise the > hand... :-) ).
In the case of /etc/hosts -> ./inet/hosts I've seen lots of trouble from that, anytime someone ran an editor on /etc/hosts that deletes and recreates files rather than (like vi) writing over them. It got to where the more senior admins had to put a script out that saved off a copy, fixed the symlink, and sent nasty email to the admin team. That _after_ everyone had been told more than once to edit /etc/inet/hosts, _not_ /etc/hosts. (the editor in question, in addition to being easier for some folks than vi, had the advantage of putting an advisory lock on the file so that no two instances of the editor could have write access at the same time, thus being more idiot-proof for people some of whom obviously needed all the idiot-proofing they could get. I think there _may_ have been a subsequent patch to the editor to recognize symlinks itself, so that such problems wouldn't happen. But the origin of the editor predated symlinks...) This message posted from opensolaris.org
