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.

Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

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.

Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>

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

Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>

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.

Signed-off-by: Peter Bergin <peter@berginkonsult.se>
Signed-off-by: Ross Burton <ross.burton@intel.com>

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.

Signed-off-by: David Vincent <freesilicon@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

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.

Signed-off-by: David Vincent <freesilicon@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>

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\)

Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>

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.

Signed-off-by: Mikko Ylinen <mikko.ylinen@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>

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.

Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

This addresses (among others) the following problem:
- USERADD_ERROR_DYNAMIC=error causes a recipe to get skipped
  because a static ID entry is missing
- the entry gets added to the file
- using the recipe still fails with the same error as before
  because the recipe gets loaded from the cache instead
  of re-parsing it with the new table content

Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>