From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Thompson Subject: Re: Manage ssh public keys? Date: Fri, 10 Apr 2015 10:24:48 -0400 Message-ID: <87egnsdpsf.fsf@fsf.org> References: <87oamxpl4o.fsf@gnu.org> <877ftlnlr1.fsf@gnu.org> <87wq1ks571.fsf@gmail.com> <87bniwm5cy.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:50401) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YgZrb-0006Eo-QW for guix-devel@gnu.org; Fri, 10 Apr 2015 10:24:56 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YgZrW-0001Yi-OA for guix-devel@gnu.org; Fri, 10 Apr 2015 10:24:55 -0400 In-Reply-To: <87bniwm5cy.fsf@gnu.org> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org To: Ludovic =?utf-8?Q?Court=C3=A8s?= , =?utf-8?B?5a6L5paH?= =?utf-8?B?5q2m?= Cc: guix-devel@gnu.org Ludovic Court=C3=A8s writes: > =E5=AE=8B=E6=96=87=E6=AD=A6 skribis: > >> Ludovic Court=C3=A8s writes: >> >>> As discussed on IRC, there are several issues, such as the choice of the >>> SSH implementation (lshd uses =E2=80=98lsh-authorize=E2=80=99 to add au= thorized keys, >>> not ~/.ssh/authorized_keys.) That complicates things. >>> >>> However, as David suggests, we could have a per-account list of files to >>> install. I can imagine something like: >>> >>> (user-account >>> (name "joe") >>> ;; ... >>> (files `((".ssh/authorized_keys" ,(local-file "my-authorized-keys")) >>> (".emacs.d/foo.el" ,(local-file "foo.el"))))) >>> >>> Now, how should that be handled upon =E2=80=98reconfigure=E2=80=99? By= just overriding >>> those files? Probably, I guess. >>> >>> Also, should they be symlinks to the store or copies? >> How about use symlinks, but: >> - create them if they are not exists. >> - update them if they are symlinks to /gnu/store. >> - warn and do nothing about them if they aren't symlinks to store. > > The problem is that that would be stateful, and thus not reproducible. > So I think conditionals like this are not desirable. +1 --=20 David Thompson Web Developer - Free Software Foundation - http://fsf.org GPG Key: 0FF1D807 Support the FSF: https://fsf.org/donate