RHEL based distros set homedir permissions to 700,
and Ubuntu 21.04+ to 750[1], i.e missing executable
permission for group or others, this results into failures
as defined in the below bug.
Since in doc we add useradd command, it's good to
add instructions to fix the permissions there itself
instead of getting failures during installation and then
fixing it.
Also update user create script to fix permissions
by adding executable bit to DEST directory if missing.
[1] https://discourse.ubuntu.com/t/private-home-directories-for-ubuntu-21-04-onwards/19533
Closes-Bug: #1966858
Change-Id: Id2787886433281238eb95ee11a75eddeef514293
If the sudo-ldap package is providing the sudo command instead of the plain
sudo package, accept that instead of breaking the system and requiring direct
root login intervention to fix things.
Change-Id: I45d7e4617bd59e72b4f0bf2e91750a6830e2a010
The existing GetOSVersion has a lot of unused code which is wrong in
several ways
- the only path tested in upstream CI is with lsb_release, because
it's pre-installed on all nodes
- the /etc/redhat-release checking probably still works, but is
unnecessary
- If using lsb_release, os_UPDATE has never actually been set.
- the /etc/SuSE-release branch checking is broken if the lsb package
is actually installed. lsb checking does not set os_UPDATE but yet
the SuSE DISTRO setting relies on this to set a patch level (and so
does some of the rpm tags). SuSE 11 is up to update 3, but the rpm
matching is stuck hard-coded to update 2. I'm guessing
installation is actually broken there.
- the debian checking branch is broken. The VERSION tags have been
removed and were not supposed to be relied on anyway (see notes in
[1])
This simplifies things:
- remove OSX checking (moved here after discussions in
I31d0fdd30928ecc8d959a95838b1d3affd28ac6f)
- only use the output of lsb_release.
- A small best-effort check to pre-install lsb packages if not
detected (that avoids chicken-egg-problem of package-install
wrappers relying on os_* flags).
- The unset os_UPDATE is removed. It's only previous use was for
setting separate suse versions in the DISTRO element for matching
during package installs (since removed)
- DISTRO setting is modified to use the parts of os_RELEASE it wants.
Per-above, this is the correct place to parse out specifics.
- Call out the is_* functions, which are a better way to detect
platforms
- Export the variables as read-only, since they shouldn't be reset
[1] http://sources.debian.net/src/base-files/7.5/debian/changelog/
Change-Id: I46a2c36d95327087085df07cb797eb91249a893c
This adds some safety checks to the stack user creation script.
This includes:
- Using set -o errexit to exit early on errors
- Make sure STACK_USER is set before doing anything with it
Change-Id: If027daddd03e32c5ba3c2ebb05ad5b27d2868b0a
A few Markdown-oriented issues were causing Docutils errors to
leak into the end-user docs on http://devstack.org
Change-Id: I51fa9698afb1bfb48596478d83bd1fdcd84ac52e
Automatically creating a new user account is not always the right course
of action when stack.sh is running as root. Plus, the re-exec did not
work correctly in some cases.
* Create tools/create-stack-user.sh to set up a suitable user
for running DevStack
* Abort stack.sh and unstack.sh if running as root and suggest creating a
suitable user account.
Change-Id: I5d967c00c89f32e861449234ea8fe19261cd9ae3
