From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6803687032751128576 X-Received: by 2002:ac2:4832:: with SMTP id 18mr5723612lft.162.1587032268806; Thu, 16 Apr 2020 03:17:48 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a2e:86cf:: with SMTP id n15ls435295ljj.11.gmail; Thu, 16 Apr 2020 03:17:48 -0700 (PDT) X-Google-Smtp-Source: APiQypIdJpyGSbeWTrzyX+2BvPqLm5dpnY6qHthxv54fjuDp+9ZSW5A7S6mBP7GAGz1MDLvYkjX0 X-Received: by 2002:a2e:9682:: with SMTP id q2mr6273370lji.289.1587032268070; Thu, 16 Apr 2020 03:17:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1587032268; cv=none; d=google.com; s=arc-20160816; b=Zhf7FIAoqPYOFZxjKRuuNj6YbWaDBgw2FHINzmy+dKv7NNAu01f5Ac6yMPQdgHfkn9 J6zJpG3LJjhMSWE6HyurBmgnik2ytidRm9HnMPzT7fYjJGde6qZ0yxdn0YZ8nIphnXnb WiHSMklhqR9CdKDeUJNRBvpdu1rKkuyrju6nX22LB2rMUPrVUV/8H/czt8n0OMb1kmXJ sa/aQW/lGnRMViBZ5qHCvhvL/I4pKdkoY0nfNkXgtzOsO2/QtdoWcosOiK0kTwYaQoSJ 4pD8H3nK0x4J47ZIOiaO+ZUCc7cV+Al4Gg8i7wbSoc2h0AYkSECRQsQr/VGISAX3wGrR Rxbg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=user-agent:in-reply-to:content-disposition:mime-version:references :mail-followup-to:message-id:subject:to:from:date; bh=pYe+L4bUBhtExRtGvkZlFwsbpEf4Twfmmua4bya1Rlk=; b=AI4kaHBeQOpY4YCLv9KTV+85FVvEAnsfcoDp5us2BET4XsThuTpfyW8zq1XwddZFXf JYitcGH65n848fSVDIER3YljnG8A5yVGuNwG7hl646HjdooVOJ/mAMCPft9kx02hXZkC zhrU6kPIBz8FZeOXUDEDyeQsbmHRM68x35ogbTBGuXiLZI+UlMIdETcPsXMRihncl3sl p54SZ7AM1ZFa+sUjz0VNBQ2HEm7OSHqCDiwggbRvI0Zn/eh8f0eo2MhAvClMKqE7BKsw 10C5jhCfu3m30QwgPJZ3EnELAxYCLjCk1BVJOsUq15O+b54HYrs9X7r/cWQPx6eDg3WF 8FPw== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=neutral (google.com: 85.214.156.166 is neither permitted nor denied by best guess record for domain of ibr@radix50.net) smtp.mailfrom=ibr@radix50.net Return-Path: Received: from shymkent.ilbers.de (shymkent.ilbers.de. [85.214.156.166]) by gmr-mx.google.com with ESMTPS id p5si1073420ljj.3.2020.04.16.03.17.47 for (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Thu, 16 Apr 2020 03:17:47 -0700 (PDT) Received-SPF: neutral (google.com: 85.214.156.166 is neither permitted nor denied by best guess record for domain of ibr@radix50.net) client-ip=85.214.156.166; Authentication-Results: gmr-mx.google.com; spf=neutral (google.com: 85.214.156.166 is neither permitted nor denied by best guess record for domain of ibr@radix50.net) smtp.mailfrom=ibr@radix50.net Received: from yssyq.m.ilbers.de (host-80-81-17-52.static.customer.m-online.net [80.81.17.52]) (authenticated bits=0) by shymkent.ilbers.de (8.15.2/8.15.2/Debian-8) with ESMTPSA id 03GAHi97017039 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 16 Apr 2020 12:17:46 +0200 Date: Thu, 16 Apr 2020 12:17:44 +0200 From: Baurzhan Ismagulov To: isar-users@googlegroups.com Subject: Re: [RFC PATCH 1/1] image-postproc-extension: remove ssh-host-keys Message-ID: <20200416101744.3bjlmwn35bjopz5d@yssyq.m.ilbers.de> Mail-Followup-To: isar-users@googlegroups.com References: <20200313134028.28650-1-Quirin.Gylstorff@siemens.com> <20200313134028.28650-2-Quirin.Gylstorff@siemens.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200313134028.28650-2-Quirin.Gylstorff@siemens.com> User-Agent: NeoMutt/20180716 X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=unavailable autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on shymkent.ilbers.de X-TUID: UXcxv9qLWyW1 Hello Quirin, On Fri, Mar 13, 2020 at 02:40:28PM +0100, Q. Gylstorff wrote: > Add the option to remove all ssh_host_keys during image_postprocessing. > This ensures that images with read-only rootfs or overlays use the > keys generated during the image generation. > > sshd-regen-keys: create new ssh keys if the keys do not exit The change makes sense to me. Normally I prefer static generation, but this isn't possible, since the image should be flashed to multiple devices. In that case, keeping keys in the image doesn't make sense. Given that, should this be an IMAGE_FEATURE? Does anything speak against always removing the sshd keys during the image generation? Opinions welcome. If it remains an IMAGE_FEATURE, I think we should describe it in the user manual. Regarding the patch: We've fixed the following issues, I'll send a v2 suggestion. * Commit comment: "exit" -> "exist". * Inconsistent indentation in meta/classes/image-postproc-extension.bbclass: Fixed to 4. * meta/recipes-support/sshd-regen-keys/files/sshd-regen-keys.sh: echo "Removing keys ..." doesn't apply anymore: Removed. With kind regards, Baurzhan.