If we move the superuser account creation to the end, it's practical to
Ctrl+C it in case you already have a superuser in the data that got
imported.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
If the database dump is older than the application, there may be
migrations to run, so we need to run them after importing and not
beforehand.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
It's best practice for security reasons to use shell=False and pass
command line arguments as a list; it also avoids some pain with
escaping, so let's use it everywhere we can (in fact we're only left
with one place in layerindex/tasks.py where we now pass shell=True).
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Change minimum required version of Django to 1.11.11.
Signed-off-by: Amber Elliot <amber.n.elliot@intel.com>
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
The original TableSorter is unmaintained, move to the latest version of
the active fork:
https://mottie.github.io/tablesorter/docs/
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Indentation, spacing, and wrapping of a long import line.
Signed-off-by: Amber Elliot <amber.n.elliot@intel.com>
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Add user security questions upon registration as extra authentication
for password reset. Three unique security questions must be chosen and
answered. Answers are then stored in the database with the same hashing
algorithm as the users's password.
On password reset, users get two chances to get two out of three
security questions answered correctly. After a second failure their
account is locked and email is sent to the admin. The same template is
shown for the axes lockout. Super user cannot reset their password until
they set security questions.
Users can update their security questions or add them if they weren't
originally set (in the case of super user) in Edit Profile.
Signed-off-by: Amber Elliot <amber.n.elliot@intel.com>
This involves changing how registration templates are referenced
and how the activation email is sent on user's email address change.
Signed-off-by: Amber Elliot <amber.n.elliot@intel.com>
This allows users to see the site ID in the admin page.
Signed-off-by: Amber Elliot <amber.n.elliot@intel.com>
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Database dumps are simply SQL (i.e. plain text) so they tend to be
both large and easy to compress, so having them gzipped is something
worth supporting.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Make the app should use a database account that has only the privileges
it needs rather than the root account for improved security.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
You really need to specify these both together since during updates we
will very likely fetch over both HTTP and HTTPS.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
* We can't use # because it can result in part of the password being
trimmed off when it gets put in a configuration file.
* Similarly, our parsing splits on = so it is unwise to allow as a valid
character.
* Add uppercase characters for a little more randomisation.
Make it easier to do updates and also reinstall from scratch; if the
application is already installed, we force the user be explicit about
which one they want to do so that there is less chance of data loss.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Refactor out HTTPS configuration code to a new function to give the code
a bit more structure.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Add settings for user/password for the RabbitMQ server and make
dockersetup.py set it up. (The rabbitmq container intrinsically
understands RABBITMQ_DEFAULT_*, and for the sake of consistency I've
reused those variables for the other containers.)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
The default wait_timeout we are getting from the official MariaDB
container (as inherited from Debian) is 600s, which is too short if you
walk away while the setup script is running and it stops on the
"manage.py createsuperuser" step for longer than 10 minutes. We don't
really need this timeout, so just use the upstream default of 28800 (8h)
instead.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
The application is most likely to be used in an internal setting,
however should someone want to make it accessible externally, add
support for Let's Encrypt certificates for serving via HTTPS.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Apply some branding, improve user friendliness and give the user a
chance to break out if they actually don't want to run the installation.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
If we want a minimum level of security we should enable HTTPS. However,
the only practical way we can do that without the user having to do further
infrastructure setup and/or pay a certification authority is to use a
self-signed certificate. Do this by default, and also provide an option
to specify a previously obtained certificate/key pair.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
* Use default macro in command line help text to avoid duplication
* Make config editing slightly more robust
* Display a message at the end telling the user how to access the
application based upon the port mapping
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Adding setup script for docker containers. The script will edit all
necessary configuration files, build and launch all containers, and
do the initial database setup - including populating the database
with data supplied by the user.
Changed docker/README to reflect new setup instructions.
Signed-off-by: Amber Elliot <amber.n.elliot@intel.com>
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
This makes deployment (and updates) much easier. You still need to
follow some setup instructions in the docker/README file, but the number
of steps is reduced and most commands simplified.
Thanks to Konrad Scherer <Konrad.Scherer@windriver.com> for suggesting
this (although the docker-compose.yml here was written from scratch).
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
This should have been added in 2c8f979f9c
to make it possible to delete an account that is the administrator for a
maintenance plan without removing the maintenance plan.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Move the Export Recipe List button, change it to match the Export CSV
button on the layer detail page and put the Tools menu back (useful for
accessing the Admin site if not just for consistency). The Submit Layer
button remains hidden.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
If you had more than one layer on a maintenance plan, only the recipes
from the last layer were shown because we were using a recipe list
variable from the last iteration. The fix just turned out to be to
indent the code that read from that list so it runs every iteration
instead of at the end.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
For security reasons it's best practice to use parameters to pass values
into SQL statements and not substitute them in as strings (with Django's
database API the distinction is subtle, but we pass in the parameters in
a second list parameter instead of using % to substitute them before
passing the query in).
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Patches often need to be applied in a specific order. For OE recipes we
were always storing the Patch objects correct order as they are
refreshed every time the recipe itself is refreshed, however for other
distro comparisons, import_otherdistro.py attempts to preserve existing
records, adds new ones and then deletes whatever is left over, which may
result in the order getting messed up over time. To avoid this issue,
record the order next to the patch and set the model meta-info to use
this to sort Patch queries by default.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
The recipe upstream history can't be reconstructed, so we need to be
able to export it out of an old database an import it into the new one.
There's also a "remove-duplicates" function; whilst not strictly
necessary it did help us to remove duplicate records resulting from
running the import twice (due to a bug) and may be useful in future
under similar circumstances.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
