From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6545397795972448256 X-Received: by 10.223.154.135 with SMTP id a7mr221397wrc.21.1523977775278; Tue, 17 Apr 2018 08:09:35 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 10.28.206.14 with SMTP id e14ls392365wmg.11.canary-gmail; Tue, 17 Apr 2018 08:09:34 -0700 (PDT) X-Google-Smtp-Source: AIpwx49eEyociyJ3tD9iX/lQtFiMVCmJth6JSMyi6d95vO2tx+VjUaoJ6V3iT7InRjXbqUXh1Cy9 X-Received: by 10.28.247.12 with SMTP id v12mr183010wmh.31.1523977774838; Tue, 17 Apr 2018 08:09:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1523977774; cv=none; d=google.com; s=arc-20160816; b=FrazQnGH5C4pcxW146B/fEamtIbKTgA2vOPoyM+TZxN636lOl8jhGjyeubbCdxyw2d nTLtChrtoGSlIdsUaNIxVwLDVcudiAKGAX7gY0xURPsa2XX0RtoLsjB0Mc6j3/Hmv1A3 KdHmeRtIJwNUjbKD3DVYURGTVb+DC0UjFzyDVKMRgEiOyNO12xRGYsEnXwUny+IqGA6A sGxfvGXrHkAgefJg7tOC8xvrx9pnzyYDnz7gjVqvejfZ0m8mJXCc6f9//YpPCl8fbzOX jYOUFjGg7R4q6hspWYNejZe9ndDAPvtObd2o+HYi8xDFeZhjvIOqk4mc2sT3rhp0BIMk LbNA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:arc-authentication-results; bh=zZhGVgDPhK0KvuCobwQLtII+a1Bej45/3VDYPwcRu1k=; b=l0krGhoHtoewdHwm0o0FcMBzxJfmEtbb2tsNjw7JrO1rghpfXvyodqkhB6PcnIE2H+ uwmrbGarlvPzy7eoq0hsRm1kW8As1RvGVYMndLbbh3UcBw47+5LGFeFawXozsSbu1tNI G7TH154vh36XQw0vEfhJBvnDlC/M07Za74cOAYCTHPvol306ehPw69vQZ+WA06gsx8s2 g1HuV8Xg7JwuqHN3MaITqjOI+va+Qb2A9J+DHLrYkSWyGNatT5PVFTuSfIQssqNif9Ow Y8WSXHA1pEEM7Cu9zxMMOkokuypvK3d/cQKTIyTa32NW1uc1MxmpghehefuHjQ8/fBqG VpIg== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of henning.schild@siemens.com designates 192.35.17.28 as permitted sender) smtp.mailfrom=henning.schild@siemens.com Return-Path: Received: from goliath.siemens.de (goliath.siemens.de. [192.35.17.28]) by gmr-mx.google.com with ESMTPS id m2si445445wmh.2.2018.04.17.08.09.34 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Apr 2018 08:09:34 -0700 (PDT) Received-SPF: pass (google.com: domain of henning.schild@siemens.com designates 192.35.17.28 as permitted sender) client-ip=192.35.17.28; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of henning.schild@siemens.com designates 192.35.17.28 as permitted sender) smtp.mailfrom=henning.schild@siemens.com Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by goliath.siemens.de (8.15.2/8.15.2) with ESMTPS id w3HF9Y8l012003 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Tue, 17 Apr 2018 17:09:34 +0200 Received: from mmd1pvb1c.ad001.siemens.net (md1pvb1c.ad001.siemens.net [139.25.68.40] (may be forged)) by mail2.siemens.de (8.15.2/8.15.2) with ESMTP id w3HF9Y7S006229; Tue, 17 Apr 2018 17:09:34 +0200 Date: Tue, 17 Apr 2018 17:09:32 +0200 From: Henning Schild To: Jan Kiszka Cc: , Subject: Re: [PATCH] meta-isar/example-raw: Remove /etc/resolv.conf in postinst Message-ID: <20180417170932.35f665c9@mmd1pvb1c.ad001.siemens.net> In-Reply-To: <9d44be9f-660d-d1c3-bc31-939c00f8d992@siemens.com> References: <20180417124618.30964-1-henning.schild@siemens.com> <9f1829c8-331e-031c-8c03-37cc5b76c44a@siemens.com> <20180417152040.5265bf7d@mmd1pvb1c.ad001.siemens.net> <9d44be9f-660d-d1c3-bc31-939c00f8d992@siemens.com> X-Mailer: Claws Mail 3.15.0-dirty (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-TUID: 9hvLhXAw8OLa Am Tue, 17 Apr 2018 15:23:55 +0200 schrieb Jan Kiszka : > 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. OK, came up with another approach that is still being tested. Stay tuned. Henning > Jan