From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6545397795972448256 X-Received: by 10.28.144.147 with SMTP id s141mr128013wmd.16.1523971437188; Tue, 17 Apr 2018 06:23:57 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 10.28.13.196 with SMTP id 187ls368322wmn.2.canary-gmail; Tue, 17 Apr 2018 06:23:56 -0700 (PDT) X-Google-Smtp-Source: AIpwx482PjbjympACF7Spj3DGN4YOhuPkuJtPU/D7BSgGU6zJVwTFdNDdgHx+hjKxGbCPif3kqS9 X-Received: by 10.28.0.73 with SMTP id 70mr139805wma.0.1523971436611; Tue, 17 Apr 2018 06:23:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1523971436; cv=none; d=google.com; s=arc-20160816; b=Kf36L6JM6bneFdvfFzEIwwpUn8/TS0vQh45d4IyJYL0iupgb9m4672f8CUq2TCDle9 EgO9dUtqTPfo0wUyEKnWORLMp922Q/yKvue9q4lClb28xDNdYusoXIMO2KsQuKvrf9wM Us8pKugv+JsUVyk4y7zmWosXD2s2PHzwx3X8ay4fTWFBwpYL18OUy8VMMpR/aF74kQPu tz/RJxd4LGtlDElHFb7JihUSU/yFkOtSwjuEruKQMD5XoRoYUX6/bRNixd6RQ+AqyOu8 tOdOmepgr2ynochTKeAaM4d4UOrZ9pOfcq0Y5nfd/9YbkII4h1Dzl9uxbLphFsgaSr9i Ec5g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:content-language:in-reply-to:mime-version :user-agent:date:message-id:openpgp:from:references:cc:to:subject :arc-authentication-results; bh=NUfffxQ3GGiexzrtufc+IHMtzbog9IR8zh0IOJUwdU8=; b=b14undG8+8NZ0whYvHYn+ut/Sed0a6YUQB4LfTLwU7FMBpv1aNQl8oV/HSoGKXqOo3 VpPHPSIsBo+vmBXaXXQeKhIJttxpTrC28zYwW4RAC/rmj4sx0sTdgOVLpJ/xvES3n5yj kyIuUezDdOobXtd0v2S5+CqjPbqcjf8L3oUAfjST3/3wMTwrxsnAUYhM85Xu5n8Hs916 o/IOlmt308azYnfDWMHkiAsWoofH0w7xkEyPneigAz/s/o+3acI2r+sQelKTkpjfVYsq 3CbbpcrxtX3KY8d89Md/KyMgiqNa57Xq5MTer+OPwNWj68iYtd3GAIY1qHFq9t/W3YcL FT9Q== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of jan.kiszka@siemens.com designates 192.35.17.2 as permitted sender) smtp.mailfrom=jan.kiszka@siemens.com Return-Path: Received: from thoth.sbs.de (thoth.sbs.de. [192.35.17.2]) by gmr-mx.google.com with ESMTPS id u18si514755wrg.0.2018.04.17.06.23.56 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Apr 2018 06:23:56 -0700 (PDT) Received-SPF: pass (google.com: domain of jan.kiszka@siemens.com designates 192.35.17.2 as permitted sender) client-ip=192.35.17.2; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of jan.kiszka@siemens.com designates 192.35.17.2 as permitted sender) smtp.mailfrom=jan.kiszka@siemens.com Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by thoth.sbs.de (8.15.2/8.15.2) with ESMTPS id w3HDNtko023441 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Tue, 17 Apr 2018 15:23:55 +0200 Received: from [139.25.68.37] (md1q0hnc.ad001.siemens.net [139.25.68.37] (may be forged)) by mail1.siemens.de (8.15.2/8.15.2) with ESMTP id w3HDNtg9020552; Tue, 17 Apr 2018 15:23:55 +0200 Subject: Re: [PATCH] meta-isar/example-raw: Remove /etc/resolv.conf in postinst To: Henning Schild Cc: isar-users@googlegroups.com, claudius.heine.ext@siemens.com References: <20180417124618.30964-1-henning.schild@siemens.com> <9f1829c8-331e-031c-8c03-37cc5b76c44a@siemens.com> <20180417152040.5265bf7d@mmd1pvb1c.ad001.siemens.net> From: Jan Kiszka Openpgp: preference=signencrypt Message-ID: <9d44be9f-660d-d1c3-bc31-939c00f8d992@siemens.com> Date: Tue, 17 Apr 2018 15:23:55 +0200 User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666 MIME-Version: 1.0 In-Reply-To: <20180417152040.5265bf7d@mmd1pvb1c.ad001.siemens.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-TUID: fNq2aF1RGyy8 On 2018-04-17 15:20, Henning Schild wrote: > Am Tue, 17 Apr 2018 15:03:28 +0200 > schrieb Jan Kiszka : > >> On 2018-04-17 14:46, [ext] Henning Schild wrote: >>> Issue: debootstrap copies /etc/resolv.conf from the host into the >>> rootfs, and we need it there to use apt-get. But we do not always >>> want it there after we are done installing >>> >>> Fix: remove the leaked file in our image customization package, to >>> reach a defined state. That happens to be the state we had with >>> multistrap. >>> >>> Impact: images will not contain a resolv.conf anymore, just like in >>> the multistrap days. If you want one do not install example-raw and >>> customize in your own hook >>> >>> Signed-off-by: Henning Schild >>> --- >>> meta-isar/recipes-app/example-raw/files/postinst | 4 ++++ >>> 1 file changed, 4 insertions(+) >>> >>> diff --git a/meta-isar/recipes-app/example-raw/files/postinst >>> b/meta-isar/recipes-app/example-raw/files/postinst index >>> f60be8c..385473e 100644 --- >>> a/meta-isar/recipes-app/example-raw/files/postinst +++ >>> b/meta-isar/recipes-app/example-raw/files/postinst @@ -19,4 +19,8 >>> @@ chown -R isar:isar /var/lib/isar # but we take the same password >>> for this example echo "root:root" | chpasswd >>> >>> +# debootstrap will leak these two files from the build host, get >>> them +# into a defined state >>> +# every image will have to handle these two somehow >>> echo "isar" > /etc/hostname >>> +rm -f /etc/resolv.conf >> >> That cleaning should go into the generic images. It's not a >> customization. > > Just discussed that with Claudius offline. And we came to the > conclusion that it can not really go anywhere else. > > Instead our conclusion was, that these two files are special and every > image should contain a customization script to bring those two into a > defined state. We read debootstrap code and confirmed that it is these > two files only. In fact we found resolv.conf after a question around > hostname appeared. > > If you delete them in the image-recipe, you can not tune them in hooks > anymore. And the image needs them as long as it needs internet ... want > to use apt-get. > > We could handle them in a post do_rootfs task that end-users would > override to customize. The bb-task would not be very debian-like and > would open a tempting hack-vector that end-users might use to smuggle > rootfs-changes around apt. Host state shall not go into the image. Thus at least emptying that file is mandatory. In case someone forgets that or is in no need for networking, this should be done generically, not per customization. A customization package can still ship its own file, I don't see the problem here. Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux