Failed to create config file/option alerts on Windows installer

[radinamatic]

"Failed to create config file/option" alerts

Branch: 0.16 installer (build # 81) on Windows 7 & 8

Current Behavior:

Two error alerts appear when KA Lite is started from the desktop shortcut:

Both errors alerts appear twice (1st, 2nd, 1st, 2nd), but after that KA Lite appears in the Taskbar notification area, and can start the server correctly.

[MCGallaspy]

@ruimalheiro perhaps you can give some insight? Not really sure what the config.h stuff is for.

[ruimalheiro]

Hey @radinamatic @MCGallaspy ,

The options to run at windows startup / autostart server are stored within the file "CONFIG.dat". The "config.h" contains all the logic to create and read the configuration file.

Perhaps that error is related with writing permissions issues by the user? If it fails to create the file, it will display that error.

[radinamatic]

So far these errors appear on Windows 7 & 8, but not on XP. Can that maybe shed some light?

[ruimalheiro]

That would make sense since that Windows Vista+ are more restrictive in respect to user permissions.

If the user does not have permissions to write to the directory where KA Lite is installed, it will not be able to create the configuration file and it will display that error.

Unfortunately we are not printing the errors to a log file or so. That would help a lot because we could easily check the error code under MSDN, that would provide us more detailed information.

Could you try to run KA Lite as admin (right click on exe, run as admin) and check if the same error is happening?

[radinamatic]

The user that is installing KA Lite and running has admin status, and those errors do not appear while running the KA Lite.exe (weather by double click, right click >Open or right click > Run as administrator).

However, if I want to activate Options > Run KA Lite when the user logs in, by right clicking KA Lite icon in the taskbar notification area, I get "Failed to create config file".

[MCGallaspy]

Yeah, it does indeed have to do with the owner of the CONFIG.dat file (which is found in KA Lite's installation directory). If it's created at install time, the admin privileges cause it to be owned by an admin. Subsequently a regular user doesn't have the perms to modify it, but if you run the gui app as admin it seems to work ok. (This is on Win 7, but I expect similar results for other versions.)

Not sure what the best course of actions is -- it might be possible to run KA Lite always as an admin (but that's a bit excessive), or to change the permissions of CONFIG.dat so that it's always writable.

[MCGallaspy]

The user also doesn't necessarily have permissions to create a CONFIG.dat file if one wasn't created during installation...

[MCGallaspy]

I wonder if it's possible to request the perms on newer version of Windows? I'll look into it.

[ruimalheiro]

Yep, that is right. Perhaps one possible course of action would be to actually create the configuration file under the user documents or similar? This would allow different config styles for each user on that machine and would avoid any I/O problems (regarding user permissions).

[MCGallaspy]

TL;DR

Old behavior is problematic since KA Lite could now be run by several users on the same machine. We should support multiple users (and also thereby avoid permissions problems), but this creates a lot of caveats for upgrading. I've proposed some changes, but they bear discussion because there are pros and cons. Read more below and share your opinion.

Recap

The installer is run with elevated permissions, so if a user chooses an option which creates a CONFIG.dat file, then it will be created with the elevated permissions, preventing subsequent access. However KA Lite.exe (the task-tray program) is generally not run with elevated permissions.

There are two distinct mechanisms by which the CONFIG.dat file could be created:

• At install time using the API exposed by IS. See here. No specific function for changing permissions, though could be possible using e.g. ShellExec
• After installation using the task-tray program. It is possible to set the desired access levels using CreateFile.

Furthermore, older installations of KA Lite may be suffering from this problem, in the sense that they might have created a CONFIG.dat at install time (as described above) but are not able to subsequently modify it, or they may receive notifications telling them that they can't open the CONFIG.dat file as @radinamatic experienced.

It's also now possible that if 2 users run KA Lite on the same system, that they will both be accessing the same CONFIG.dat file. That means the options will be modified for all users if one changes them, which is clearly not desirable.

Proposed changes regarding CONFIG.dat

Change	Pros	Cons
Remove the ability to create CONFIG.dat at install time	Prevents the ability to create a file which cannot be accessed without elevated privileges later. Easier to maintain code, as it's no longer duplicated.	Less convenient, perhaps will make it less obvious these options exist
Write CONFIG.dat to a location determined by the user running KA Lite.exe	Avoids sharing CONFIG.dat files across several users	Users may rely on old behavior. Configuration files may be lost and need to be set again.

Caveat

The behavior of "Run at system start..." doesn't play nice -- it currently runs KA Lite as the SYSTEM user (and will still in #322, except on XP). This is problematic because it means that several users may all control whether KA Lite is run by the SYSTEM user or not, but also because choosing to run KA Lite from the task-tray program actually runs KA Lite as the current user. Again, users may rely on old behavior here. In previous version of KA Lite there was no notion of running KA Lite as different users. Furthermore we don't wish to have users "lose" data because suddenly they are running KA Lite as a different user (which will create & access a different database file).

The latter issue is the most difficult problem here -- it is possibly annoying but trivial for the user to create a new CONFIG.dat file. But it could be more difficult to preserve user's data, depending on the version of KA Lite they use and how they typically start the server. How to preserve data when upgrading:

	KA Lite run as SYSTEM user (through scheduled task)	KA Lite run as current user (started manually from task-tray)
Shared database (0.13 and lower)	Migrate data from canonical location at upgrade time to installing user's ~/.kalite dir. Installer already does this.	Migrate data from canonical location at upgrade time to installing user's ~/.kalite dir. Installer already does this.
Single-user database (0.14 and higher)	Migrate data from location dependent on Windows version to installing user's ~/.kalite dir. The installer currently has no way to distinguish whether KA Lite is run this way or not. May need to prompt user. The alternative is to include a separate tool/script for migrating data, allowing users to self-identify if they need to use it after installation.	No action.

@radinamatic I'm particularly curious about the bottom-left entry -- in your opinion, what can we do that will make it as simple as possible for a user to upgrade in that scenario?

[MCGallaspy]

Additionally, I can't recall when we moved from a shared database to a single-user database on Windows -- from the release notes I think we started using a single-user database in 0.14.0. @radinamatic can you verify that 0.13.x uses a shared database (found in the KA Lite installation directory) and 0.14.x uses a single-user database (found in a user's .kalite directory)? This will inform how upgrades from various versions to 0.16.x should be handled.

[radinamatic]

Ok, I will do a 0.13 version installation to verify the shared database presence.

Regarding the CONFIG.dat conundrum, I'm just wondering how frequent is the use case where there are 2 different users (2 admins?) who need to run the server, which will lead to 2 sets of user data? I've always envisioned one and only one server installation, since it has the ability to manage multiple scenarios (schools, classes, groups...).

[radinamatic]

Thinking further...Learner users will probably never start the server themselves, but some Coach might (a part from Admins, obviously), so I do see the need for the server start by different users after all...

[radinamatic]

0.13.2 version has the data.sqlite file in folder:

C:\Program Files\KA Lite\ka-lite\kalite\database

[EdDixon]

@MCGallaspy knowing there is some crossover between a planned kalite deployment you are involved with and kolibri. This might be a good time to look at a start on a more sane user permission structure for our furture kolibri design? Depending on time tables of course which I know you understand much better than I? But my preference would be a roll based adminstration assigned model where the admin / assumed installer, can pick or choose from those internal account types which will be granted this capability and others on an as needed basis as I think @radinamatic is suggesting. I can imagine in many scenarios it could be best for the students themselves to be able to start it and my personal preference on my own machines has always been always on anyway LOL anyway, just food for thought?

[radinamatic]

0.14.2 version has the data.sqlite file in folder:

C:\Users\<username>\.kalite\database

[MCGallaspy]

Just a note -- on XP, even when a KA Lite scheduled task is run as the SYSTEM user, it seems to choose the location of the .kalite dir based on the current user's %USERPROFILE% value.

[radinamatic]

It does seems that only scheduled task are reserved for those with elevated permissions.

Regarding the above table about migrating data (bottom-left entry):

The installer currently has no way to distinguish whether KA Lite is run this way or not. May need to prompt user.

We are talking about upgrading on Win 7 & 8 for users who run KA Lite as SYSTEM user. Can't the installer check if there is a kalite.job scheduled task present?

The alternative is to include a separate tool/script for migrating data, allowing users to self-identify if they need to use it after installation.

That's also an option, but I would personally prefer if all can be correctly setup/migrated during the installation.

[MCGallaspy]

We are talking about upgrading on Win 7 & 8 for users who run KA Lite run as SYSTEM user. Can't the installer check if there is a kalite.job scheduled task present?

Yeah, I am trying to determine where the .kalite dir appears when run as the SYSTEM user -- then we can prompt them to save/migrate that data at install time. Sadly, it appears there's a bug in Windows affecting this very situation: https://support.microsoft.com/en-us/kb/2968540

[MCGallaspy]

A note to summarize the USERPROFILE situation on each version of Windows. I'll be updating this.

OS	Value of USERPROFILE at boot for SYSTEM user	Value of USERPROFILE after log in for SYSTEM user
XP	Apparently no value? Could be why it fails.	Takes the value for the currently logged-in user
Windows 7	C:\Windows\System32\config\systemprofile\	Same: C:\Windows\System32\config\systemprofile\
Windows 8	Probably also C:\Windows\SysWOW64\config\systemprofile\.kalite	Apparently in C:\Windows\SysWOW64\config\systemprofile\.kalite? Must look into SysWOW64 a bit.

[radinamatic]

Sadly, it appears there's a bug in Windows...

Oh, what a surprise... :unamused:

I am testing starting the server on non-admin (coach) Windows user with 0.14.2 that I installed today. It does not throw any errors from KA Lite options in taskbar notification, but it does require the system admin user password when python process is raised.

[radinamatic]

0.14.2 on Windows 7

Running the server by two different Windows users (one admin and other standard) creates two completely different KA Lite "setups" - different content folders, databases, (super)users...

Is this really the intended behavior? I could understand the need for, let's say, coach person to login with their Windows credentials on that machine and be able to start the server, but that would have to be the same KA Lite server "setup" as the one the admin user would run when they login on the machine with their own Windows credentials, and that's not what's happening.

[MCGallaspy]

Running the server by two different Windows users (one admin and other standard) creates two completely different KA Lite "setups" - different content folders, databases, (super)users...

Yes, if two different users run KA Lite then it will create two different .kalite directories, because it's based on the running user's %USERPROFILE% value. This can be changed by setting the KALITE_HOME environment variable. It's also why I find it problematic that the scheduled task runs as the SYSTEM user, but a user using the the task-tray program will start KA Lite as his/herself and not SYSTEM.

As for why this is the case, briefly it's because we want to ensure that any user that starts KA Lite has permission to write data, which is not the case in prior versions and resulted in errors. In this case:

I could understand the need for, let's say, coach person to login with their Windows credentials on that machine and be able to start the server, but that would have to be the same KA Lite server "setup" as the one the admin user would run when they login on the machine with their own Windows credentials, and that's not what's happening.

We'd like KA Lite to start as the admin user through a scheduled task, so the coach will never start it. The almost-equivalent thing we do on linux is create an initscript which runs kalite as a particular user every time. However I'm struggling to do this on Windows using schtasks.exe.

[EdDixon]

I have always felt this would be a nice feature in a multi-teacher classroom for example, where the room is scheduled for use by more than one teacher each day on the same hardware each having their own record store and coaching capabilities for the classes they are teaching without access to the others. I think it offers the greatest amount of flexibility in meeting different use cases but does come with its headaches on our end.

[MCGallaspy]

Okay, after much sleuthing I discovered that on Windows 8: the default value of KALITE_HOME is C:\Windows\System32\config\systemprofile\ still, but this gets translated to C:\Windows\SysWOW64\config\systemprofile\ somewhere along the way. See my table above.

[MCGallaspy]

TIL about running 32-bit windows programs in 64-bit windows: https://msdn.microsoft.com/en-us/library/aa384187(v=vs.85).aspx