On Mon, Oct 19, 2009 at 11:29:49AM +0300, Henrik Ingo wrote:

On Sat, Oct 17, 2009 at 12:18 AM, Sergey Petrunya <psergey@askmonty.org> wrote:

...

Hi!

Thanks everyone for input on the input so far! I believe I've collected it all and put into the WL entry: http://askmonty.org/worklog/Server-RawIdeaBin/?tid=55

* If there is something missing there, please bring that argument up again.

* Final call for objections/comments on Step#1. Please voice them now,  otherwise what is described in step #1 may end up implemented.

Can't think of anything.

Last point: When uninstalling, the data directory should be left untouched. This is safer and seem to be common even with applications that don't store as important data as a database does.

There is a problem with this: in step#1, installer doesn't handle upgrades, so it will not be possible to install and uninstall repeatedly. The first uninstall will leave the datadir in place, and then the second installation will refuse to install there. One will have to go to the install location and manually remove the datadir. This might scare away non-technically-savy users - in Windows XP the windows explorer app won't even show the contents of C:\Program Files\, instead it will show a message telling you that this is a folder with system files that you shouldn't mess with. One might wonder if we could have the installer to still install into that path. This presents two challenges: 1. What if the user really wants to start from scratch (e.g. they've set up SQL permissions that locked themselves out or something like that). 2A.We'll need to adapt the configuration to the files that are in the datadir, e.g. I know that the server won't start if ib_logfile's size on disk doesn't match the value in the server configuration. There might be other things like this. We could settle for doing "null" upgrades only: - if we're creating the datadir, put a file named this-is-mariadb-5.1.38.dat - have the installer allow to re-use the datadir if this file is present. 2B.As an alternative, We could have the uninstaller dump the entire database to somewhere and then rely on the user to import it back. BR Sergey -- Sergey Petrunia, Software Developer Monty Program AB, http://askmonty.org Blog: http://s.petrunia.net/blog

@Vlad .. we have discussed that already - but the main reason is another: With UAC ('user account control') ON on Vista and higher even an admin user cannot write to 'program files' unless progeam is started with explicit admin privilege. If server is isntalle to \program files and a user starts the server from command line *as a user*(NOTE: an admin user does not neccesarily have admin privileges with UAC on) all writes will to to user's \virtualstore folder - what means that database files will be duplicated: one copy for 'system' and one for 'user. . Please try to understand the differences between WIndows 2000/XP/2003 on one side and Vista/2008/win7 on the other. I am referring to UAC. If you never used any Windows version higher than XP .. well then .. accept the limitation of your experience. . There will need an option for user to specify bot 'basedir' and 'datadir' independently. default 'basedir' should be 'program files' - default datadir should be 'AppData'. . This is the (mine) bug report where this discussion started in MySQL context: http://bugs.mysql.com/bug.php?id=34593 . Peter . On Mon, Oct 19, 2009 at 18:40, Vladislav Vaintroub <wlad@sun.com> wrote:

...

-----Original Message----- From: maria-developers-bounces+wlad=sun.com@lists.launchpad.net [mailto:maria-developers-bounces+wlad <maria-developers-bounces%2Bwlad>= sun.com@lists.launchpad.net] On Behalf Of Sergey Petrunya Sent: Monday, October 19, 2009 6:24 PM To: Henrik Ingo Cc: maria-developers@lists.launchpad.net Subject: Re: [Maria-developers] Windows installer, part 2 This might scare away non-technically-savy users - in Windows XP the windows explorer app won't even show the contents of C:\Program Files\, instead it will show a message telling you that this is a folder with system files that you shouldn't mess with.

I hope you do not want to store data files in Program Files. This location is first, restricted for use by the (elevated) Administrators only and second, it is there to store executables and shared libraries and maybe even readonly data from the installation.

Program data like databases are to be stored somewhere else, "echo %ProgramData%" might give a hint to the correct folder:)

_______________________________________________ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp

@Vlad .. I did not think that you suggested storing data in program files. I understood very well that you advised that it should not be done like that. But I pointed out that in my opinion the main reason is not that Windows (from XP at least) will try to hide the content in program files from user - in my opinion the main problem (with UAC set ON) occurs if the server is sometimes started as a service and sometimes as a user program - because the server will then write database content to different file positions in the two cases (and that was also the reason why MySQL changed their installer). If server is always started as a service this problem will not occur. Also if server is installed elsewhere than program files (like c:\mysql) it will not happen. I am only trying to get attention to what may happen if 3 conditions are met: 1) UAC is ON 2) server is installed to program files 3) server is sometimes started as a service and sometimes as a user program . I am still awaiting comments to my outline of how work on an installer could be started earlier in this thread. I think we may be able to wrap up something in a few days based on NSIS. Actually almost everything I outlned is rather trivial (we can copy most from our SQLyog/MONyog installers) with the sole problem that we will need to 'replace into a file'. I do not think we did before, but with scintilla/scilexer I also think we can handle this too without too much difficulty. But I will have to discuss details about this with Khusbbo and Manoj (our tech lead) 2row as today was holiday in India. But if nobody likes the outlined workflow then it would be waste of time of course! . . Peter . On Mon, Oct 19, 2009 at 22:04, Vladislav Vaintroub <wlad@sun.com> wrote:

From: Peter Laursen [mailto:peter_laursen@webyog.com] Sent: Monday, October 19, 2009 7:00 PM To: Vladislav Vaintroub Cc: Sergey Petrunya; Henrik Ingo; maria-developers@lists.launchpad.net Subject: Re: [Maria-developers] Windows installer, part 2

...

@Vlad .. we have discussed that already - but the main reason is another: With UAC ('user account control') ON on Vista and higher even an admin user cannot write to 'program files' unless progeam is started with explicit admin >privilege. If server is isntalle to \program files and a user starts the server from command line *as a user*(NOTE: an admin user does not neccesarily have admin privileges with UAC on) all writes will to to user's \virtualstore >folder - what means that database files will be duplicated: one copy for 'system' and one for 'user. . Please try to understand the differences between WIndows 2000/XP/2003 on one side and Vista/2008/win7 on the other. I am referring to UAC. If you never used any Windows version higher than XP .. well then .. accept the limitation of >your experience.

I'm wondering how did you derive that:) I used to run Longhorn/Vista betas since 2006, Win7/2008R2 betas since January this year, so I do know pretty well the stuff you're talking about :)

...

There will need an option for user to specify bot 'basedir' and 'datadir' independently. default 'basedir' should be 'program files' - default datadir should be 'AppData'.

...

This is the (mine) bug report where this discussion started in MySQL context: http://bugs.mysql.com/bug.php?id=34593

I wonder how can you read from my post that I suggested storing data in ProgramFiles? In contrary, my position on that was always that - it is bad to store data or config files in Program Files - it is bad to run MySQL service under administrative account and it is even worse to run it under SYSTEM.

The core of the UAC is dumbing down members of Administrators group to be a normal users by default. So now, if service would not run as high-privileged administrative account (it does not need any admin privileges), and installation would save config files in a place where they are editable, then users would not have to care or know anything about UAC. Also note, using least possible privileges is a prerequisite for passing formal MS certifications, since at least Windows2003 times. And please refer to my previous post about security - I described how improving security creates on the other hand user friendly UAC-popup-free experience.

"and additionally to run the program in user session you need elevation." No. I can start MySQL (installed with a recent MySQL installer like 5.1.39 - or just a zip/no-install distribution) as a user with the command '<path to>\basedir\bin\mysqld --defaults-file <path to>my.ini. But if UAC is ON and the cmd.exe session was not started with explicit 'run as administrator' option the server will write to user's \virtualstore folder and *NOT *to the 'datadir' defined in server configuration. That is the problem in my understanding. It results in two different copies of the database files. . Actually I agree with your 'preaching' (at least as an option for live servers running on a Windows server platform). But I do not think such change between MySQL and MariaDB should be implemented in current stage. I am in favor building a rather simple 'skeleton' doing what is required for Windows - uninstaller, PCA compability, start menu items, registering service correctly etc. - (but not all what is required for MySQL/MariaDB in the first place) that can be detailed. . Peter . On Mon, Oct 19, 2009 at 23:52, Vladislav Vaintroub <wlad@sun.com> wrote:

From: Peter Laursen [mailto:peter_laursen@webyog.com] Sent: Monday, October 19, 2009 10:35 PM To: Vladislav Vaintroub Cc: Sergey Petrunya; Henrik Ingo; maria-developers@lists.launchpad.net Subject: Re: [Maria-developers] Windows installer, part 2

...

I am only trying to get attention to what may happen if 3 conditions are met: 1) UAC is ON 2) server is installed to program files 3) server is sometimes started as a service and sometimes as a user program

In normal mysql it looks like this: the datadir directory that is created as part of installation has following ACLs: CreatorOwner (SYSTEM),Administrators = Full Control Users = Read Only.

With ACLs set like this it is impossible to run the program without admin account, and additionally to run the program in user session you need elevation. There is no UAC/elevation for services, so services run but again only under administrative account.

One way to resolve this is user to create user mysqluser, group mysql, add the user who installs MySQL to the group and set the ACLs on the datadir so that group has full control. This is what I'm preaching all the time, I have tested this scenario and it works fine and there is no need for elevation. It is probably another way to get this running and escape the need of elevation, but I'm not aware about it (I'm pretty sure no one wants to give every user read/write on this directory, as was suggested here http://bugs.mysql.com/bug.php?id=38373 )

The above would of course apply to MariaDB as well.

...

I am still awaiting comments to my outline of how work on an installer could be started earlier in this thread.

I would perhaps be a bit more careful the about the early choice of NSIS as the installer tool. I admit being quite uninformed about NSIS and I never used it myself, but my impression after reading about NSIS was that it is great for copying files and everything that goes beyond copying is not trivial (maybe with the exception of starting an exe) . Everything else is done with crude Win32 API scripting, or with one of the numerous non-standard plugins. Again, it was just an impression after reading about it and not the fact of life. Please correct me if I'm wrong here. Also, is that it is a custom exe installer and it is not the standard recommended by OS vendor (MSI is standard). Have you thought about using WiX?

Sergey is the captain of the ship here, so let him propose a roadmap. Things are getting too polemical now. But if an installer for MariaDB should be completed in weeks some compromises/trade-offs would be required for a start and a (or more) 'mockup'(s) would be required very soon. . On Tue, Oct 20, 2009 at 00:51, Vladislav Vaintroub <wlad@sun.com> wrote:

From: Peter Laursen [mailto:peter_laursen@webyog.com] Sent: Tuesday, October 20, 2009 12:12 AM To: Vladislav Vaintroub Cc: Sergey Petrunya; Henrik Ingo; maria-developers@lists.launchpad.net Subject: Re: [Maria-developers] Windows installer, part 2

...

will write to user's \virtualstore folder and NOT to the 'datadir' defined in server configuration. That is the problem in my understanding. It results in two different copies of the database files.

File Virtualization does not apply to 64 bit. This problem hit you on 32 bit, but what I see for 64 bit processes, is that server cannot open file for writing when running under non-elevated (even if administrative) account.

...

Actually I agree with your 'preaching' (at least as an option for live servers running on a Windows server platform). I thought about it as a "must", and not option:) User will still be able to change the service to run as SYSTEM.

...

But I do not think such change between MySQL and MariaDB should be implemented in current stage. I am in favor building a rather simple 'skeleton' doing what is required for Windows - uninstaller, PCA compability, start menu items, registering service correctly etc. - (but not all what is required for MySQL/MariaDB in the first place) that can be detailed.

I understand that completely. My point was however, I believe it is very unlikely you'll be able to solve usability problems as outlined in the discussion (like ability to start server in user session) without fixing security. I'm not aware of any tricks, except extremely radical measures, like making all files world-writable. Of course Maria v.1 can live with the same usability and security limitations as MySQL, but after reading your "Does MySQL care about Windows users", I thought you'd prefer an improvement.