linux/poky.git/meta/classes/useradd-staticids.bbclass, branch pyro

useradd-staticids: don't create username-group if gid is specified

2017-11-05T22:39:48+00:00

Adding distcc to an image, and having staticids enabled, doesn't work as it causes a a superfluous 'distcc' group being added using a conflicting GID, thus failing the build: | ERROR: distcc-3.2-r0 do_prepare_recipe_sysroot: distcc: groupadd command did not succeed. Compared to other recipes, the distcc recipe only specifies --gid for the primary group, and doesn't specify --no-user-group, but when --gid is given, it doesn't make sense to create a matching username-group in addition, even if --no-user-group was not specified, and 'useradd' actually complains if --gid and --user-group are given both. If only --gid is given, the current code in here effectively behaves as if --user-group was specified, taking the group-id of the username-group from the --gid parameter. This causes the error above, as we try to add a new group (distcc) with an existing group-id (nogroup). This is contrary to the comment in this file just above, contrary to what useradd can do, contrary to behaviour without the useradd-staticids bbclass, and non-intuitive. Change the code such that a username-group is only created - if a primary group using --gid was not specified, or - if --no-user-group was not specified To be in line with useradd, if gid is not given, and --no-user-group is given, we add the user to the group 'users', which mimics useradd's behaviour. (From OE-Core rev: b1843e60ebe534243b49f3685540fa5ea49d5f35) Signed-off-by: André Draszik Signed-off-by: Richard Purdie (cherry picked from commit fc3a86ae68919cec72c1a8ae0f9ba1f98ae13f0d) Signed-off-by: André Draszik Signed-off-by: Armin Kuster Signed-off-by: Richard Purdie

useradd-statids.bbclass: Add support for -P / --clear-password option

2017-04-29T10:17:22+00:00

The commit 31dee7946340bf0f1e94e4e714191d3d6ca3bf6a added a new useradd and groupadd option to specify a clear text password. The parsing logic in the useradd-staticid class did not understand this new option. If the meta-skeleton examples were run with the class enabled an error would be generated, as an example uses the -P option. Note, the code has a check that we do not attempt to set both a crypt and clear text password. It is not allowed that these two options are set at the same time, so we prefer the crypt option if they happen to be. (From OE-Core rev: a1715970d5c454dd24d04972ffb9cf735b5d1338) Signed-off-by: Mark Hatle Signed-off-by: Richard Purdie

useradd-staticids.bbclass: Always fail/warn for missing IDs

2017-03-22T11:35:20+00:00

Previously, with USERADD_ERROR_DYNAMIC set to error/warn, if a static UID/GID was specified in the recipe, then no error/warning would be issued even if no ID was specified in the passwd/groups files. (From OE-Core rev: 8e4b4e28a7c3a9dbd6b9298bea5d2c1328b3f24a) Signed-off-by: Peter Kjellerstedt Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

useradd-staticids.bbclass: Support recipes specifying static IDs

2017-03-22T11:35:20+00:00

If this bbclass is used and a recipe specifies a static ID for a user/group as part of the USERADD_PARAM_${PN} or GROUPADD_PARAM_${PN}, the build would fail with and error like this if there was no corresponding ID in the passwd/group files specified via USERADD_UID_TABLES/USERADD_GID_TABLES: ERROR: meta-oe/recipes-support/postgresql/postgresql_9.4.11.bb: meta-oe/recipes-support/postgresql/postgresql_9.4.11.bb inherits useradd but doesn't set USERADD_PARAM, GROUPADD_PARAM or GROUPMEMS_PARAM for package postgresql (From OE-Core rev: e744fac05fc5cc19cabc59c1e79ff4c1b3ee396d) Signed-off-by: Peter Kjellerstedt Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

useradd-staticids: fix typo for '--expiredate'

2017-02-23T20:49:48+00:00

There is a typo in the useradd-staticids.bbclass that causes error during do_install. If build was configured to use usedadd-staticids and the recipe included (for example): USERADD_PARAM_${PN} = "--expiredate '' testUser" Due to the typo this added the wrong option '--expiredata ' that caused an error. (From OE-Core rev: 9d26a2f9f52ae9df6aa5e0ee20683ada35c32af1) Signed-off-by: Peter Bergin Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

useradd-staticids: Fix groupadd

2017-01-26T10:44:27+00:00

When a group name is duplicated between USERADD_PARAM and GROUPADD_PARAM, this class tries to add it twice which results in failure of the groupadd command. (From OE-Core rev: 5b84cc895500c28674d2a7b7c2dd618cf8fb30e9) Signed-off-by: David Vincent Signed-off-by: Richard Purdie

extrausers: Use static ids when available

2017-01-19T22:47:20+00:00

When creating users at the image level using extrausers class, the current behavior is to ignore the status of USERADDEXTENSION. This could lead to undefined behavior when static ids are expected but the system falls back to dynamic ones. (From OE-Core rev: 331140e892f84b70bced44a0b5d14f32ec95042e) Signed-off-by: David Vincent Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

meta: remove True option to getVar calls

2016-12-16T10:23:23+00:00

getVar() now defaults to expanding by default, thus remove the True option from getVar() calls with a regex search and replace. Search made with the following regex: getVar ?$( ?[^,()]*), True$ (From OE-Core rev: 7c552996597faaee2fbee185b250c0ee30ea3b5f) Signed-off-by: Joshua Lock Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

useradd-staticids.bbclass: catch missing uid/gid exceptions

2016-10-28T15:15:20+00:00

The change to get rid of FuncFailed exceptions changed the behavior of how missing uid/gid error are be handled. Instead of catching the exception and handling that via bb.parse.SkipPackage(), a fatal error was called. This won't work with recipes that are unused and therefore do not have UID/GIDs defined. The problem triggers when parsing all recipes (e.g., oe-selftest runs bitbake -p). The right way to handle this is to raise bb.parse.SkipPackage(). This will error correctly once the recipe is needed. (From OE-Core rev: 55384cfc743a12a78bef736ee08ed453b6a6a21e) Signed-off-by: Mikko Ylinen Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

useradd-staticids.bbclass: Use bb.fatal() instead of raising FuncFailed

2016-10-04T15:29:04+00:00

This sets a good example and avoids unnecessarily contributing to perceived complexity and cargo culting. Motivating quote below: < kergoth> the *original* intent was for the function/task to error via whatever appropriate means, bb.fatal, whatever, and funcfailed was what you'd catch if you were calling exec_func/exec_task. that is, it's what those functions raise, not what metadata functions should be raising < kergoth> it didn't end up being used that way < kergoth> but there's really never a reason to raise it yourself FuncFailed.__init__ takes a 'name' argument rather than a 'msg' argument, which also shows that the original purpose got lost. (From OE-Core rev: e507cb978fd52164beb28324933cb3d5e368c3ab) Signed-off-by: Ulf Magnusson Signed-off-by: Richard Purdie