From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 7192512605249863680 X-Received: by 2002:a05:6000:18d0:b0:2bd:f43d:de0b with SMTP id w16-20020a05600018d000b002bdf43dde0bmr1342542wrq.326.1674727170879; Thu, 26 Jan 2023 01:59:30 -0800 (PST) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a05:600c:1c94:b0:3d1:be63:3b63 with SMTP id k20-20020a05600c1c9400b003d1be633b63ls2600718wms.1.-pod-canary-gmail; Thu, 26 Jan 2023 01:59:29 -0800 (PST) X-Google-Smtp-Source: AMrXdXsHQ82A64i6IXLzWq+fld4XEAVDCXs48A0gXjjbKqzJlf5Pscj8FLxcXMNLYtSry/hRsQ24 X-Received: by 2002:a05:600c:3489:b0:3db:695:461a with SMTP id a9-20020a05600c348900b003db0695461amr34277429wmq.7.1674727169662; Thu, 26 Jan 2023 01:59:29 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1674727169; cv=pass; d=google.com; s=arc-20160816; b=MfDbgMzvKw5diFr2FJRfpDF/kb4ogw0qMPO3qspdwr2dLMkz694DTWovVnw75BWU/O JpEa4Cmd3tgis/qqw0DTpQqCdAEAQtx77tZaIR7mG5vSfNmQx8hgH4+T0TFPKKMYADiJ Dx1XwfWQ6ZFYjZNs+IqbpWPc8ATXwxa0Dmt8o/Ym5Y/LCIDipuJx7kyFBZY0mfpZryaj zZobl0Np65buQShImUZVIHYxysyZJsQUtj6vv/qkbN5kvZ9IZ68YREr8jH9jjGCc4qWL ke/kGzWas3YYwggfmx2B2n70yzUOwcz3BMKjn5SYX7E+0hx2xCYVbrhHSQcafUKnPclu rxDw== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=mime-version:content-transfer-encoding:references:in-reply-to :message-id:subject:cc:to:from:date:dkim-signature; bh=WKC90PVfKny2LfpvMiGCtfIbl5cGVcSbKW25V5X52JA=; b=DQIghlaqYhe2+jbpr2syTr9oQiosD5gsk11HMWzuytd+gxkjqovKvgiUjFj9URY8e2 tGMcitKu2KYPlq4t07Gk5cu0+qKM+SkbpnM+hoZANt2DVy9jHXsW8sqG9F+yX7ag524v IuGTL7DApAGrbWkUug5Nd8phLoAMbP76ubw8wdsrv5u17Lh/m16Zcg9tMNBrJ9pnnq3e KaY1vYUK5qWpO6p1DGn25d8JP1kTFIPe8N9oKWBbYDXSC/Wld3IZlOMh2/zfFr3+wAOK ut45YUFZQnAhTRaCp9I1v3uMtkjgrneqlNCKEPt36f73sioIx3eBrAIvX9AsDH/Astc5 y5QA== ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@siemens.com header.s=selector2 header.b=vElgIXHa; arc=pass (i=1 spf=pass spfdomain=siemens.com dkim=pass dkdomain=siemens.com dmarc=pass fromdomain=siemens.com); spf=pass (google.com: domain of henning.schild@siemens.com designates 40.107.15.75 as permitted sender) smtp.mailfrom=henning.schild@siemens.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=siemens.com Return-Path: Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on2075.outbound.protection.outlook.com. [40.107.15.75]) by gmr-mx.google.com with ESMTPS id az13-20020a05600c600d00b003db0037852esi537978wmb.0.2023.01.26.01.59.29 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Jan 2023 01:59:29 -0800 (PST) Received-SPF: pass (google.com: domain of henning.schild@siemens.com designates 40.107.15.75 as permitted sender) client-ip=40.107.15.75; Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@siemens.com header.s=selector2 header.b=vElgIXHa; arc=pass (i=1 spf=pass spfdomain=siemens.com dkim=pass dkdomain=siemens.com dmarc=pass fromdomain=siemens.com); spf=pass (google.com: domain of henning.schild@siemens.com designates 40.107.15.75 as permitted sender) smtp.mailfrom=henning.schild@siemens.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=siemens.com ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Xe5Lw6CZ4GLUJ7aJ2nS7bqMsQFb/VfVFd5EVWwSoBNvvX5sURguk37bUeoIdwr1BCJv3pHQrljhznoA2acLhDkUkBBzmaoQ5LH7qpECOa84ve1fXhIDz5+uUCWR6uAqmxbM1ZY093e0s+M+/jeFAED7Wut/8Egp8B1lHLOvMBasSDVgW/UmWeWrvV5n3YXtmzNjD2k1RRdAfhXnkIkc6TeQLxwBXgwPnTwfRu2hb4xREUcQC8fHSvUCMlWVuFCXvdi1hmq+Y2lEW7/iZepEpm2N6ozQQKpuhQtgWcDOOr6rYGIDqovNdrQKKWQLY4dlNX4ZmB0g5DV7PO6Uw323X+Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=WKC90PVfKny2LfpvMiGCtfIbl5cGVcSbKW25V5X52JA=; b=nNcgFoKkhiM0nswHbMfG1FJ42I/uP9Tct0elgpEq5evo4CvtoUytN4c/XG4cKfZKjDJmNNTXNE8HPo2/w3+brODAfuiUhHQYdJKFyrCRaptALby99E9ilRMWeZ7ZIjyV8tpqdvjM12+qvxmE+gEMazVely93FlBgsOcN/LGuA5qsEMyjh0ZvDEaDRZxuDoul7BGtmoABURVoUDN7+LFl3fz8gbVEGEzypTzqz/RuaDZgulw/v4hiU/l/4y/3VT4vyASo1JkAcVhgq0QYQ/KzhacPKVn4U6R1Noxbpg7FnMpf6rsYcFx/F0MH4Cu2v79/k6g7fE7ODBWh856izfm6Fg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=siemens.com; dmarc=pass action=none header.from=siemens.com; dkim=pass header.d=siemens.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=siemens.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=WKC90PVfKny2LfpvMiGCtfIbl5cGVcSbKW25V5X52JA=; b=vElgIXHaaoEsWLg+O+E2anHB0xPKkKq29akSwK5cz/NFDiw23CrMu1JrgxoLcIWfx+v2RHLjKT1BDtB3ChUoy0D3aMsgxOkDjB8cCwO+M5ldtx6ZXX4nkSDVbySgynoqS2eDaVJRGwVa5rnuPyFUfFpDQBURB/8AypJSLqCbhAoqG6YXQw399Uq1vMFb1BPYe0ZT3wAkhNl5FLQKJg2yuqjU69W3yH5YcEUTz5b7Mfm382A+IQIDj1t01AopDc8/7tUIE/ZfEyrxJnfnKkfmxbASStJxmdwXv/CvCxOAF6yq0B7Ctk4sm7A9xDtHtw3Gu+HTsZB9OFYSksRF5SOpLw== Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=siemens.com; Received: from PA4PR10MB5780.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:102:269::8) by DU0PR10MB5606.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:10:318::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6002.33; Thu, 26 Jan 2023 09:59:27 +0000 Received: from PA4PR10MB5780.EURPRD10.PROD.OUTLOOK.COM ([fe80::bdf0:fdeb:f955:bc79]) by PA4PR10MB5780.EURPRD10.PROD.OUTLOOK.COM ([fe80::bdf0:fdeb:f955:bc79%4]) with mapi id 15.20.6002.033; Thu, 26 Jan 2023 09:59:27 +0000 Date: Thu, 26 Jan 2023 10:59:16 +0100 From: Henning Schild To: "Schaffner, Tobias (T CED SES-DE)" Cc: "Gylstorff, Quirin (T CED SES-DE)" , "isar-users@googlegroups.com" , "Adler, Michael (T CED SES-DE)" Subject: Re: [PATCH 0/5] allow creation of users/groups before rootfs creation Message-ID: <20230126105916.68311bbd@md1za8fc.ad001.siemens.net> In-Reply-To: <1b8a1db2-0390-8027-4a45-471f2385a50e@siemens.com> References: <20230125090156.284309-1-tobias.schaffner@siemens.com> <20230125142901.597613d7@md1za8fc.ad001.siemens.net> <20230125172916.0d49528f@md1za8fc.ad001.siemens.net> <73457b6d-c5cd-7e43-5142-2feab5caa54a@siemens.com> <20230125223848.6b911eb5@md1za8fc.ad001.siemens.net> <1b8a1db2-0390-8027-4a45-471f2385a50e@siemens.com> X-Mailer: Claws Mail 4.1.0 (GTK 3.24.35; x86_64-pc-linux-gnu) Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-ClientProxiedBy: CH0PR03CA0443.namprd03.prod.outlook.com (2603:10b6:610:10e::7) To PA4PR10MB5780.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:102:269::8) Return-Path: henning.schild@siemens.com MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: PA4PR10MB5780:EE_|DU0PR10MB5606:EE_ X-MS-Office365-Filtering-Correlation-Id: a5610ae9-3e28-4216-7346-08daff8402dc X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: zoNSs0nwu/evZdxV/bj04WVbIxonnJHsX1c6ZedM+5cjdwLTiEqyzO3SHpNuC//SMJJs6DTL64Mf/yDZafhibSaGK4YO42hYrjWRqLipgfS2BiP+qNR1aMFGORqxXu5zI5e5uaJ8EZrYs+rz+/4zPMGi9Jno8Rv+oL592O1QV2cKCB6RucwF6uo9IFeDE7IeFM30qqviC38kZUifPTRRpLUnQbPDuCAH6bLOp7VwZb6eWR7bzxf5nW2t04kcEgtS5zkEiVOwHDv1fKK/I7ZX/IDCKpHerXrK36atOV951yVa+Q20yiQ0dx/UU4RzDfRLa4pqkW5MAeuPYG9UwFrmmkaQuFWSlL/QgL7/ABhtLOAPwPsHRqzPRP8lEOYFYWo4ZQYf2RUj3NoixzXcOR+8NHCpkg7Apu3SlN4E7psoge+iz6BWExRnAVGpACAfuGeR8t7o2ZNgwQZy2XTWe1KABtp08Mjij7/VgWUfmvjAnGWra96GSpytkwgAKDJCrCym8ws40mS2sCrExiSsfLd2Vl8iOKMiv3PUU2EEJ8dW9EyHxhPBn2v12ksB0c8Oyr0aMytGfLm+DG6I8R+Dot/8udxBQ6wbebPdcbf4A3oaTal6gzIf/vhd/sNMkWJ/OEBygVf++A/EvCEyW7cHCNW26inYl9n185HWJmVyrNislj1HPkF/T+ieKTuZ7NxBnV4K X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PA4PR10MB5780.EURPRD10.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230025)(4636009)(376002)(366004)(136003)(39860400002)(396003)(346002)(451199018)(38100700002)(83380400001)(478600001)(54906003)(66556008)(8676002)(66476007)(186003)(107886003)(9686003)(6486002)(1076003)(66946007)(966005)(6636002)(53546011)(2906002)(41300700001)(86362001)(30864003)(82960400001)(5660300002)(6506007)(6862004)(6512007)(316002)(6666004)(44832011)(8936002)(4326008)(66899018);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?b4riBoct38IKr+VHPiKxYZGCjd+Pzbcf5ooaZvSzM8VpAl6nxrGpPWZnMG7i?= =?us-ascii?Q?hsSJYAuQ2lWP5JKl1nB9WkCKgZ89ck+42zLcmOtrr+JnSQ5EBrtIs+btzzzr?= =?us-ascii?Q?8gE0e9IELMvVH+utDCnkUroAr65ZWPoMxewO0fBkCLaareSIGu14DvoQ2/YA?= =?us-ascii?Q?kEcCHqq5L23Tgef1KY8G6mVLYGQqVtf8AucCSKevk5whdc06j6IEkTyBXyJN?= =?us-ascii?Q?peHDUdMjZn+/fw74kWzSSJ7UUW5ubPsSM1VNF0c38XziAvqYtWe2yW/CmnVG?= =?us-ascii?Q?dTtGu+RSs2zpEaJCn2T0sSE9UPBsJt2FWkCK4WLsWM2KzDvs1v0B47+B56Hw?= =?us-ascii?Q?c2wHmzUpnsoHKYrprzdcRmwAqkoScmbeejGgJ3kZ28cOgwdeTZLh9ZMfCK+f?= =?us-ascii?Q?eLYDBACfWnFW/rKjJWb1mYBtUSGSPZYbkIGJzRr8JW12N1LIjESf77tdJ8Qa?= =?us-ascii?Q?lOaUCiSDn1blbQelfBjy9b9gU5FuHXMPfeV3guCgepeP2m5+CK07C6w9IURT?= =?us-ascii?Q?ygiQ70wpVT6p9/R65fN2DKQxwrIaYCyamNxYM6wOrqFCdJpSdHQaCgq7Ee9Y?= =?us-ascii?Q?D9CfJbIv7g/gYnPjb2jkKjT56cW8dG5PenAY7/aaU3XYkARnjTH2heNcqU3h?= =?us-ascii?Q?PUP7+eGWSBRFvJlQZR6P15iknH8imvMafzjd7xV7OvYlqAiDHJQs5Kk3IwgU?= =?us-ascii?Q?0Kl3sX3gf1ZC8RdLS3RabzIG42n5NtGoAjVS19xUtdPEFH3tE4O2Pb2MfJtY?= =?us-ascii?Q?tcbh0ZzVAFc3fAhJi96FspA1PeCP7OWTC7vqYSVGOxMVnQ6C/7GNtCH6Ny5L?= =?us-ascii?Q?2Y4UKmBylJbbxLPLD57/prllIrxKmzggrVROV6f15Xy2JdFLmodwbQPHaBHN?= =?us-ascii?Q?mfFfnAPFuFkemTL4eZNVbzORYZoYk8Dk36xjhWRFYB6bL/0TonRCM+/arf3E?= =?us-ascii?Q?+4I+oN6wCeFJyKyDd8cZzSf5GKCtaVTQsPbquFWmW+KnPkwziZEnISSfMnqq?= =?us-ascii?Q?KX/E0Fervs8v8fffTH0FN3XDdOTBCMJX6tytKSlcFaXZK2rz91AqgcYo9dyl?= =?us-ascii?Q?LfBAN/w/Lm64rT+36kc9gEZuM/kQpYW47u7qX5Ol8jaBrIQgSEv5KjmK8evG?= =?us-ascii?Q?uTH8pXyzg2qk+ZXUr6aV2KazYNvMoS8mTbP5cwfnSxgl7NWBo4DgDC/gm4cu?= =?us-ascii?Q?iulGSVTH1/WwJ+eLWbiGieM5SNIK5X8MQSpVDfP3WxLdGWcxWIIk0rlTFKOX?= =?us-ascii?Q?pVos4nTxg0qwjYsVVBzyOW5ZUJ9TQ9rZcO51hse2mFhllooNLOqqrg/uqvla?= =?us-ascii?Q?NAA1xcle1/QxZO6aZpUmx11mZVEKYnf+++kdk3QwveqiwfeLQw7niOxmhpIH?= =?us-ascii?Q?XVrJArLx5P4qm0/bTPFi9dEX0j84KIclEcuKfbXHIhwQn469+jRFAHjUltbt?= =?us-ascii?Q?Ym6JLKPloxzcQzSYEgAvJDkYQq5cdi5ok8p3hVIXQZtKluGKjK/SyUNp7fic?= =?us-ascii?Q?dgjs7PmzZ0HrWXNJ5o3zXx4OYF8cdXsov7NTLnPx7jLB82oiDTyJ5i7D4OJp?= =?us-ascii?Q?M4iMYZkUdOHmuy21/2oYFqmXwQ7q7wIuzEGJSqwx+H5M5MjdEglHV/UEz7Ns?= =?us-ascii?Q?il7uw3h/S32PjkcH7J4NctfBOBctoSRLOomGzRQOWIGvZS459HPDKJvuwKme?= =?us-ascii?Q?Ru/iFQ=3D=3D?= X-OriginatorOrg: siemens.com X-MS-Exchange-CrossTenant-Network-Message-Id: a5610ae9-3e28-4216-7346-08daff8402dc X-MS-Exchange-CrossTenant-AuthSource: PA4PR10MB5780.EURPRD10.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Jan 2023 09:59:27.7613 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 38ae3bcd-9579-4fd4-adda-b42e1495d55a X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: LxJVPpqjqxKxLIojYRfXzZ6cMggOE2B5oISTpzCfYpkXh5h3TgPCyPhCG3vahMs8ETa996RbQAdLkwswQn7u3uqjj9DG4GBN5T8N/PAPELU= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU0PR10MB5606 X-TUID: lIj8HzFfXs1f Am Thu, 26 Jan 2023 09:21:12 +0100 schrieb "Schaffner, Tobias (T CED SES-DE)" : > On 25.01.23 22:38, Schild, Henning (T CED SES-DE) wrote: > > Am Wed, 25 Jan 2023 21:55:00 +0100 > > schrieb "Schaffner, Tobias (T CED SES-DE)" > > : > > > >> On 25.01.23 17:29, Schild, Henning (T CED SES-DE) wrote: > >>> Am Wed, 25 Jan 2023 14:44:40 +0100 > >>> schrieb Gylstorff Quirin : > >>> > >>>> On 1/25/23 14:29, Henning Schild wrote: > >>>>> Am Wed, 25 Jan 2023 10:01:51 +0100 > >>>>> schrieb "T. Schaffner" : > >>>>> > >>>>>> From: Tobias Schaffner > >>>>>> > >>>>>> This patch series will allow to specify a `pre` flag for the > >>>>>> USER_ and GROUP_ bitbake variables. If this flag is set to > >>>>>> `true` the given user or group will be created in the rootfs > >>>>>> configuration step instead of on rootfs postprocessing. This is > >>>>>> helpful when a specific id should be used which would otherwise > >>>>>> be picked by a user or group created by one of the installed > >>>>>> packages. > >>>>> > >>>>> While i do understand the reason i am not sure how relevant that > >>>>> is. Why would anything only function with a fixed ID? Whoever > >>>>> provided that thing should maybe fix it. > >>>> > >>>> Specific IDs are necessary for Updating an A/B rootfs system > >>>> with a persistent partition. In this case you do not want to > >>>> change any IDs as this can lead to wrong file permissions. > >>> > >>> I see, that is much more understandable. It also goes into the > >>> reproducible build direction. > >>> But if that is the case the solution does not seem to be good > >>> enough because it only considers users/groups created by isar. > >>> Not the ones created by installing debian packages. Where the > >>> order could be potentially random. Say you DEBIAN_DEPENDS or > >>> IMAGE_PREINSTALL "ftpd wwwd" which will craete users "ftp www" > >>> where the two deamons do not have any dep on each other and > >>> apt-get could install them in any order. That order might in > >>> reality not change too often but it could i.e. when you move from > >>> debian11 to debian12 or when you bring the third (or 10th) > >>> user-adding package into your new firmware. > >> > >> Thanks for the review! > >> > >> This series is not about reproducible builds. The IDs of the users > >> and groups that are created by debian packages are expected to > >> change between _image_ versions. So we expect these IDs to be > >> different after a swupdate. > > > > But your initial argument was that you have to create a user before > > any debian package comes, or did i misunderstand? Maybe we need to > > differentiate between upstream packages and isar-created ones? > > Lets make this clearer with an example: > A downstream layer creates one user X that writes to a separate > partition. This user gets the ID 1000 as there are no packages that > create any users. > > Now they want to create a image update that should be deployed. > The updated image includes a new debian package that creates a user Y. > The user Y of this package gets the ID 1000 as it is now the first > user that is created. Not sure a real debian package would create a non-system user and get a 1000 allocated in the first place. Are we talking about an isar-generated package creating a non-system user? > User X will now get 1001 and it is not possible to change this. The > data created on the separate partition belongs to user Y. > > The only resort at the moment is to revert the patch that moved the > user creation to the post processing. > > >> For reproducible builds it is important that the ordering of > >> installed packages and their dependencies stay the same but that > >> is a different story. I expect the ordering algorithm for a > >> specific set of packages including dependencies to be > >> deterministic but would have to look into that in detail. > > > > I expect the algorithm to be non-deterministic ... potentially as > > you progress using debian. I can just claim, you have to prove. > > From my point of view this problem derives from the fact that the > set of installed packages will change on image updates. If the user Y > is created in the first or in the last package does not matter. Its > just the fact that an additional user gets created. > > >> Still, if somebody had a requirement that a user or group of a > >> package (e.g. ftp or www) stays the same, one could use this > >> change to create the user beforehand and pin its id using this > >> change. > > > > True. But we might still want to keep the old database to run > > assertions so such things do not go unnoticed. > > > >>> So what you maybe really want is giving isar an /etc/passwd > >>> /etc/group pair. Every new firmware is build with the given layer > >>> code and that file-pair from the first release. Where you inject > >>> those files between bootstrap and install ... hoping that > >>> bootstrap will always be the same. Maybe one can inject before > >>> bootstrap ... or write a postproc function that will find all > >>> different ids and all files and fix up. Or at least start with an > >>> assertion in postproc that looks at the old database. > >> > >> Care that just adding /etc/passwd and /etc/group might not be > >> enough but you would have to handle the side effects of a > >> useradd/groupadd call properly (E.g. creating the home if set). > >> And I expect more things to come up if you have a detailed look. > > > > Yes. Not even want to think about LDAP or yp where the databases > > live in different files. > > > >> Take into account that the specific patch that introduces the pre > >> flag is small, easy to maintain and configure. > > > > It should still be motivated so that we later understand why we have > > it. And i would not call it easy to configure if one does not > > understand why ... people will "pre" randomly because they do not > > know what they are doing. We moved that stuff from pre to post > > once, and i can not help the feeling that people might want to want > > to mix pre and post one day ... at which point it might become > > really un-easy. > >>> Is the problem of uid/gid depend on install order known in the > >>> debian community and how do others solve it? Gentoo has moved from > >>> such dynamic allocation to static some years ago, probably for > >>> similar reasons. > >> > >> I am open to discuss this with the reproducible build guys but > >> again IMHO this discussion belongs into another thread. > > > > IMHO not, the repro guys want full repro ... which we can happily > > leave out when it comes to me. You want partial repro, which we > > should discuss here. > > I think you may have a valid point that a non deterministic ordering > on package install may be a problem for reproducable builds. Not only > when it comes to users but also e.g. every time two packages append > to the same file. > > > I do not want to hold this back, just understand it and see if there > > can be a better solution. Feel free to ignore me and merge if nobody > > else asks questions. > > I am happy to discuss this, I just think we are mixing things up. But > maybe I am missing something. Yes it is a mix. The repro guys are currently focussing on the very same code generating the very same output. Here we talk about the next gen of the code needing to repro bits that have to stay the same. We keep discussing a solution and abstracted away problems. Maybe it would be better to put the real problem at hand on the table. Then we can throw around ideas on how that affected layer could deal with it, and how isar could change to help in such cases. The move from pre to post we did some time ago, might indeed make that a problem we caused in all such layers that had a release at pre-times and now want the next at post-time. And touching this again might have the next such effect which we only start understanding once it is too late. And we should add tests. Looking at Isar today, we have the user "isar" added both in local.conf.sample and in example-raw. Maybe that should be two different users where one would even be non-system. Henning > Best! > > > Henning > > > >>> Henning > >>> > >>>>> > >>>>> So i am willing to say that this is super-niche! And it > >>>>> deserves a niche-solution in its layer, not a feature in Isar. > >>>>> > >>>>> You could hook in a task between bootstrap and image_install. Or > >>>>> you could rebuild a bootstrap package to have reserved ids. You > >>>>> could run "the thing" in namespaces ... > >>>>> > >>>>> So is that really relevant? Please go into detail. > >>>>> > >>>>> Whatever happens i think the python rewrite is cool. But the > >>>>> code may have been coming/inspired from OE ... in which case it > >>>>> would not be cool, because it would fork away further. > >>>> > >>>> > >>>> OE uses a complete different implementation than to original: > >>>> https://git.openembedded.org/openembedded-core/tree/meta/classes/useradd.bbclass > >>>> > >>>> see also: > >>>> > >>>> https://git.openembedded.org/openembedded-core/tree/meta-skeleton/recipes-skeleton/useradd/useradd-example.bb > >>>> > >>>> > >>>> > >>>> Quirin > >>>>> > >>>>> Henning > >>>>> > >>>>>> A rewrite of the image-account-extension in python was done on > >>>>>> the way. This allows us to drop a lot of encoding and parsing > >>>>>> code that was used to transition to shell and therefore made it > >>>>>> easier to read and maintain. > >>>>>> > >>>>>> Using python functions for more complex tasks allows us the > >>>>>> usage of unittests. A very basic infrastructure for > >>>>>> unittesting using the build in python unittest and the > >>>>>> bb.parse module was added. This was used to test the > >>>>>> re-implementation of the image-account-extension as a first > >>>>>> showcase. > >>>>>> > >>>>>> Tobias Schaffner (5): > >>>>>> simplify image-account-extension > >>>>>> allow creation of users/groups before rootfs creation > >>>>>> create a minimal python unittest infrastructure > >>>>>> add unittests for the image-account-extension > >>>>>> set minimal python version in user_manual to 3.5 > >>>>>> > >>>>>> doc/user_manual.md | 4 +- > >>>>>> meta/classes/image-account-extension.bbclass | 391 > >>>>>> +++++++----------- testsuite/unittests/README.md > >>>>>> | 28 ++ testsuite/unittests/bitbake.py | 37 ++ > >>>>>> testsuite/unittests/rootfs.py | 45 ++ > >>>>>> .../unittests/test_image_account_extension.py | 175 > >>>>>> ++++++++ 6 files changed, 434 insertions(+), 246 deletions(-) > >>>>>> create mode 100644 testsuite/unittests/README.md > >>>>>> create mode 100644 testsuite/unittests/bitbake.py > >>>>>> create mode 100644 testsuite/unittests/rootfs.py > >>>>>> create mode 100644 > >>>>>> testsuite/unittests/test_image_account_extension.py > >>>>>> > >>>>> > >>>> > >>>> > >>>> > >>>> > >>> > >