This one time, at band camp, Marc Haber said: > The package itself caters only for presenter and collector on the same > machine, which is done to give a working setup after installation. The > package is not likely to be used in this configuration in any > productive environment. ssh is one of the variants that is offered to > the admin as optional, local configuration. So she needs to manually > touch ssh stuff. I'd argue you're Doing It Wrong, putting this stuff in a system account user's $HOME. Have sshd look in /etc/ssh/userkeys for an additional authorized_keys file, and set up an /etc/ssh/known_hosts for the hosts you want the machine to log into. The machines that need the private key part can use a key stored anywhere on the system with ssh -i. There is no need to go into complicated backbends about policy to support local misconfiguration. I think it's fairly clear that in this case, the package doesn't depend on anything in $HOME, so it doesn't matter where it goes, except as Russ points out, for practical reasons (nfs mounted /home with root_squash, eg). I'd even argue that this is a site policy decision - where adduser puts new home directories by default is configurable, and if you decide to nfs mount /home you should probably change the default to something that will work. If you find a package that, out of the box, depends on something in $HOME and places $HOME under /home, please file a bug on that package. That is fairly obviously buggy. Cheers, -- ----------------------------------------------------------------- | ,''`. Stephen Gran | | : :' : sgran@debian.org | | `. `' Debian user, admin, and developer | | `- http://www.debian.org | -----------------------------------------------------------------
Attachment:
signature.asc
Description: Digital signature