6 Commits

Author SHA1 Message Date
Ian Wienand
7710e7fc27 Only use lsb_release for distro tags
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
2016-01-12 09:23:35 +11:00
Dean Troyer
dc97cb71e8 Mostly docs cleanups
Fix documentation build errors and RST formatting

Change-Id: Id93153400c5b069dd9d772381558c7085f64c207
2015-03-28 14:35:12 -05:00
Jim Rollenhagen
010959de40 Perform safety checks in create-stack-user.sh
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
2014-02-23 18:27:22 -08:00
Adam Spiers
cb961597cc Fix shocco errors and warnings
A few Markdown-oriented issues were causing Docutils errors to
leak into the end-user docs on http://devstack.org

Change-Id: I51fa9698afb1bfb48596478d83bd1fdcd84ac52e
2013-10-24 15:43:05 +01:00
Bob Ball
105c6e8718 Create-stack-user script should have execute permissions
Currently running stack.sh as root advises you about this script, which is not
executable

Change-Id: I674af044b8f3c31bcc86be5c6552e8086453d5cd
2013-10-18 15:33:26 +01:00
Dean Troyer
23f69d83e5 Split the creation of $STACK_USER account out of stack.sh
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
2013-10-04 16:36:00 -05:00