Allow specification of config values (device name, superuser, etc) via web interface if skipped during setup

[jamalex]

In some cases (e.g. when we create Ubuntu USB installation images) we'll be pre-installing KA Lite into a reusable installation image, so we can't pre-specify device name, superuser info, etc.

The idea here is to have a way to have KA Lite pre-installed/setup, with some of the data entry steps skipped, then have these missing pieces of information detected and requested when the web interface is first loaded, before anything else can be done.

Plan:

1. Add a --skip-input step to the setup management command. Will take a look at the existing options to avoid duplication.
2. Add middleware to detect these missing settings (specifically, lack of admin user, or empty device name), and redirect to a form (see 3).
3. Display a very simple form with boxes to fill in and save these values.

Optional:

• Have basic facility info be requested in this form as well, so the server is then ready to go. This should be optional, since it might be for use in a pre-existing facility that just hasn't been synced yet. So, we should probably direct the user to register and sync after filling out the form.

Advantages

• Can be done remotely, e.g. over wifi on a Pi.
• Has easy access to all the i18n machinery.

[bcipolli]

The current code-base allows us to:

• Specify a hard-coded admin/password in the local_settings.py file
• Use the computer name as the device ID

For the RCT 1, is there anything blocking us from using these existing features?

[jamalex]

Specify a hard-coded admin/password in the local_settings.py file

Should work fine, especially since we want things to be predictable for Nalanda, so we can administer remotely.

Use the computer name as the device ID

Right, we had talked about this. It shifts the burden to documentation (since they need to be sure to put in a meaningful name during OS installation. But that can work.

Do these things happen during setup, or kaserve? If the prior, then perhaps I should focus instead on #1653?

[bcipolli]

These happen in setup, which is called by kaserve if needed. #1653 is to re-enable that kaserve auto-installation pathway. So yes, I recommend focusing there!

[bcipolli]

Moving to post-RCT.

[jamalex]

Thanks. Updated the original description to reflect the longer-range focus.

[jamalex]

@aronasorman @rtibbles @benjaoming Just realized that this may be a blocker for 0.13, depending on how all the installers handle the configuration steps.

[jamalex]

Put as high-priority for now, until we figure that out

[benjaoming]

In general, Django recommends against manipulating settings runtime. So ideally, these variables should exist somewhere else.

The reasoning is that by convention, settings should be loaded and interpreted before anything else and then not change. The section in the docs is pretty brief:

https://docs.djangoproject.com/en/1.7/topics/settings/#altering-settings-at-runtime

[jamalex]

This specific issue isn't for local_settings.py, though we've discussed having those be web-configurable as well. This one is about creating an admin user, initializing the Device, etc -- database stuff.

[benjaoming]

Okay, my bad, it came across as a settings thing, just keep it in mind that it puts constraint on what can be configured directly from a web interface without writing to files and reloading applications.

[benjaoming]

Parts implemented in #3668 (superuser creation vi modal dialogue)

Regarding the empty device name: I don't know if it makes sense to ask users about this, maybe using hostname is sufficient?

[jamalex]

Regarding the empty device name: I don't know if it makes sense to ask users about this, maybe using hostname is sufficient?

Defaulting to hostname is good, but many deployments need to uniquely identify their devices.

[benjaoming]

Self-assigning this, not to fix it for 0.15, but to add some of the recent development of ideas and to reflect that parts of the description has already been solved through unattended "kalite start".

[benjaoming]

Although the device name is missing from auto-generated setups, it's still linked to the device's hostname. Given that someone is doing mass deployment, that should be fine.

Since no one has been pitching this, I'm kind of assuming that the priority is so low that this may never end up being solved anyways. And it's quite harmless to most users.

[benjaoming]

**) Most of all this was mitigated with the superuser creation dialogue btw.