How to install MySQL unattended with custom settings? - mysql

This is the command-line used install MySQL silently,
/quiet
But how to run the MySQL installer unattended with custom settings in the installer?

UPDATE: A newer and somewhat related answer here.
UPDATE: Several stages of answers here. I will leave them all in. The proposed technical solution / workaround moved to the top.
Instance Configuration
The actual configuration of instances seems to have been moved from MySQLInstanceConfig.exe to the installer itself: Where is the MySql 5.6 equivalent of `MySQLInstanceConfig.exe` to edit configuration files? Please try the MySQLInstallerConsole.exe (note: that links to version 8.0, not 5.7) application, sample:
Silent Installation: It seems this console appliation can run the installation silently in
various flavors, making the procedure below optional.
MSI Packages
I did a test run of what I believe was the mysql-5.7.22-winx64.msi file (there are many MSI files embedded in the main one, please see below). My best tip: get on the phone with the vendor to determine if they have actively tried to prevent silent installation. They just might have, and then you might be fighting windmills over time. They should improve this design if you ask me - though it is not the worst I have seen.
By launching the original, large MSI and enabling automatic logging (see section in that link: "Globally for all setups on a machine"), then running through its built-in, custom GUI and kicking off the actual install and then checking the "CommandLine" entry in the actual log file generated in the temp folder - it looks like it sets the following properties: REBOOT, ADDLOCAL, INSTALLDIR, INSTALLLOCATION, ARPINSTALLLOCATION, INSTALL_ROOT, DATADIR. Actual log entry below:
******* Product: C:\ProgramData\MySQL\MySQL Installer for Windows\Product Cache\mysql-5.7.22-winx64.msi
******* Action:
******* CommandLine: REBOOT=ReallySuppress ADDLOCAL=RegKeys,ALWAYSINSTALL,Readme,MISC,Server_Scripts,ProgramMenu,MYSQLSERVER,Client,DEVEL,SharedLibraries,UserEditableDataFiles INSTALLDIR="C:\Program Files\MySQL\MySQL Server 5.7" INSTALLLOCATION="C:\Program Files\MySQL\MySQL Server 5.7" ARPINSTALLLOCATION="C:\Program Files\MySQL\MySQL Server 5.7" INSTALL_ROOT="C:\Program Files\MySQL\MySQL Server 5.7" DATADIR="C:\ProgramData\MySQL\MySQL Server 5.7" ALLUSERS=1
These are in other words the properties set by the custom setup GUI that normally runs the installation process. You should be able to use this procedure for all the embedded MSI files you need to install. Then you simply extract these MSI files that you need from the large MSI and run them in sequence in some fashion, with the command lines you have found. You can also apply transforms if need be.
To state the obvious: this might take you some time to get right as you struggle with pre-requisites and your corporate use case. I'd go for piloting. Find a dynamic team and get your stuff on their test PCs quickly and tell them to give it a trashing asap :-). Chances are you already do, just mentioning it. I for one can never get these things right without some unfortunate, time-consuming iterations.
Summary of procedure:
Enable automatic logging (MSI expert Stefan Kruger's info)
Install via custom setup-GUI with options set as appropriate
Find properties to set in the log file in the %temp% folder.
Log file will have random name, sort by data and open most recently changed log file.
Get hold of the embedded MSI files from the wrapper setup:
Get hold of an MSI tool for viewing / editing MSI files (list towards bottom)
Delete launch conditions from wrapper setup (LaunchCondition table)
Extract content like this: msiexec.exe /a mysql-installer-community-5.7.22.1.msi TARGETDIR=C:\YourFolder
Tha above command kick off an administrative installation - essentially a glorified file extract, but a very good feature of MSI used by application packagers every day
Try to install on a test machine with an msiexec.exe command line based on the properties you found set
Sample:
msiexec.exe /i mysql-5.7.22-winx64.msi REBOOT=ReallySuppress ADDLOCAL="RegKeys,ALWAYSINSTALL,Readme,MISC,Server_Scripts,ProgramMenu,MYSQLSERVER,Client,DEVEL,SharedLibraries,UserEditableDataFiles" INSTALLDIR="C:\Program Files\MySQL\MySQL Server 5.7" INSTALLLOCATION="C:\Program Files\MySQL\MySQL Server 5.7" ARPINSTALLLOCATION="C:\Program Files\MySQL\MySQL Server 5.7" INSTALL_ROOT="C:\Program Files\MySQL\MySQL Server 5.7" DATADIR="C:\ProgramData\MySQL\MySQL Server 5.7" ALLUSERS=1 /QN
And some parameter info:
ADDLOCAL="..." - list of features to install locally
REBOOT=ReallySuppress - prevent spontaneous reboot
ALLUSERS=1 - install per machine
/QN - crucial addition to the command line found in the log file. this makes the install run in silent mode
Unusual MSI Design: I know this is an unusual MSI, but generally you call the vendor or search their website to obtain documentation for deployment such as this and follow the procedure I outline below (let me add the link here too: How to make better use of MSI files) using PUBLIC properties or transforms to modify the installation.
However, I wrote the section below before I did a quick check of this MSI. A quick look revealed a myriad of embedded MSI packages. Not at all good. The MSI also has no GUI, and its administrative installation (file extraction) is blocked with a launch condition. Quite terrible design in fact. You can make an administrative installation by deleting the launch conditions using Orca or an equivalent tool and going:
msiexec.exe /a mysql-installer-community-5.7.22.1.msi TARGETDIR=C:\YourFolder
It seems the idea is that this is a wrapper MSI which will launch a proprietary GUI (.NET based?) that you can then use to install the bits and pieces you need of the MySQL tool suite. It would have been much better if this launcher was a setup.exe built with WiX Burn, Installshield, Advanced Installer or an equivalent tool.
Recommended Procedure: The honest answer is that I don't know. I would call the vendor if possible, check their user forums and do some further googling in general. Most of the embedded MSI files should be possible to install in silent mode, I would hope.
The real-world approach would probably be to extract all the MSI files using the above administrative installation trick, although there must be a reason why they block administative installations - which I am unaware of. Most likely they do not want to support silent installation with options? (give them a call?). Then you take the individual MSI files you need, and see if they will install in silent mode using the approach described here with PUBLIC properties and / or transforms. There are many features in these setups, and you can use ADDLOCAL at the command line to define which ones to install and not. See the linked answer below. However, as I state below as well; feature control is a very complex topic (recommended skim).
Beware of pre-requisite runtime requirements. There may be several, such as the .NET framework and various runtimes. I see several of these being installed by the custom setup GUI.
My original, generic answer below:
MSI: It looks like this installer is in Windows Installer format, in other words an MSI file. You are in luck in the sense that MSI files are very flexible with regards to silent installation and the configration of custom paramenters. It is, however, dependpent on the package being well-designed, which is not always the case.
PUBLIC PROPERTIES and Transforms: I have an ancient answer here on the topic of customizing MSI installations: How to make better use of MSI files (just the first parts, the ending flies a bit off the handle with other topics). As you will see in the linked answer, you essentially set available PUBLIC properties at the command line, or create a transform to customize anything you want in the installer. The latter is what most corporations do for deployment.
Configuration: What properties can be set at the command line (that has any effect), varies between different setups. The setup creator must have made these properties - and built functionality around them in the setup - for them to be configurable. Typical parameterized values would include license keys, URLs to license servers and user and company names and emails and similar. For more substantial changes (such as changing shortcuts or similar), people usually resort to using a transform. You also use the ADDLOCAL property to define which features to install (all other features will not be installed if you specify a value for ADDLOCAL). Feature control is a built-in property of MSI, and you can control feature selection in detail from the command line or via a transform. However, feature control is a very complex topic (recommended skim).
Concrete Sample: As mentioned above you need to set properties and values as appropriate for the setup in question. This means you have to hit the documenation for the setup in question to determine what is "settable" or not.
Some Links:
https://downloads.mysql.com/docs/refman-5.7-en.pdf
https://dev.mysql.com/doc/mysql-installation-excerpt/5.5/en/windows-using-installer.html

Related

Octave gets stuck on Busy... inside TeXmacs in Windows OS

I have TeXmacs and Octave installed, both working properly otherwise. I have also added the path to octave executable (i.e. C:\Octave\Octave-5.1.0.0\mingw64\bin) to the Windows environment variables and octave runs in cmd/PowerShell terminals and Jupyter with no hassle. However, when running Octave inside TeXmacs through Toolbar > insert > session > octave it gets stuck on Busy..., the same reaction for any other commands as well:
Octave gets stuk on Busy... inside TeXmacs.
This is my environment:
TeXmacs 1.99.9
Octave 5.1.0 (installed through Chocolatey)
Windows 10 version 1809
I would appreciate if you could help me know what is the problem and how I can solve it.
P.S. I have reported this issue in the TeXmacs repo.
#Foad. I wrote an updated Octave plugin for Texmacs. I tried it on Windows, OSX and Linux, works on the systems I have access to. If you are interested to test it, you can download the zipped archive from here https://lists.gnu.org/archive/html/texmacs-dev/2019-12/msg00005.html.
To install it, unzip the archive and copy the octaveX directory in the application plugins folder, alongside all the plugins that come with the standard Texmacs installation. Won’t work if installed in ~/.Texmacs/plugins. If everything goes fine, you should find a new Insert/Session/OctaveX menu (note: I changed the session name). If not, try to refresh the plugin system with the menu Tools/Update/Plugins. If you try it, please let me know, especially if you find troubles. In case I will do my best to fix them.
A fundamental prerequisite is a working octave-cli command in a operating system shell. Should be standard on Linux, may require some additional setup on Windows (environmental variables) or OSX (.bash_profile). You can find some help and more details under the menu Help/Plug-ins/OctaveX.
Concerning the error you found, as far I understand there are some issues with the standard distributed plugin: first, a .octaverc file is missing, so several variables are not initialized, in addition the Windows version calls a not existent file. Moreover the plotting functions are quite old and are not compatibile with Octave newer than version 2 (or maybe 3, anyway a quite old version).
You could try to run the command in
%TEXMACS_PATH%/plugins/octave/bin/tm_octave.bat
from the terminal to see what happens. There is a problem with this plugin and it does not work also on Mac but I do not know enough Octave to fix it. Somehow it does not manage to find the files which are in
%TEXMACS_PATH%/plugins/octave/octave
Please try to modify tm-start.m to look like
d=getenv("TEXMACS_PATH");
if (length(d) > 0)
addpath("tm:polynomial:plot")
tmrepl
endif
In windows, octave should be run using the scripts octave.bat (in the mingw64\bin directory of the octave install) or octave.vbs (in the install directory) for the GUI
You should not run octave.exe directly.

Setting mem configure option in TCL build script

I need to build Activestate TCL for Ubuntu 18.04 with memory option enabled, "--enable-symbols=mem flag to the configure script" but there is no configure script in my download, only these, which don't have a "configure" line in them.
license-at8.6-thread.
update_check
komodo_download
payload
README-8.6-thread.txt
pdemos
install_welcome.txt
install.tcl
install.sh
install_lib.tcl
install_images
MANIFEST_at8.6.txt
install_data.tcl
Can someone describe how to add the switch described above for Ubuntu?
.
In order to set the mem option, you'll need to compile Tcl from source. To do that you'll need to get a C build chain (especially a C compiler such as gcc or clang, and make to act as a build orchestrator) and the Tcl (and Tk) source code for the version you want to build. The official location for releases of Tcl sources is on SourceForge:
https://sourceforge.net/projects/tcl/files/Tcl/
Pick the version you need and the download package you prefer (ZIP or compressed Tar archive).
Once you've downloaded and unpacked the Tcl code, change into the appropriate directory within the distribution (e.g., unix for Linux builds) and run the configure script inside; it's that script that you pass the --enable-symbols=mem option to.
ActiveTcl is essentially built the same way (except without symbols at all; it's a production distribution after all). It's main distinguishing feature is that it is set up with access to lots of extra packages to go with it. The same goes for most Linux distributions' own tcl packages. They're all production distributions and aren't configured for memory debugging precisely because that adds a lot of overhead to the code (both time and space).

Compile MySQL 5.6.30 on CentOS 6.7 - "Manually-specified variables were not used"

I have downloaded the mysql-5.6.30.tar.gz source file, extracted and I'm using the following CMAKE command:
cmake /mysql-5.6.30 -DCMAKE_INSTALL_PREFIX=/usr/local/mysql -DWITH_CHARSET=CP1251=1
-DENABLE_THREAD_SAFE_CLIENT=1 -DMAX_INDEXES=250 -DDOWNLOAD_BOOST=1
-DWITH_BOOST=%HOME/mysqlboost -DENABLE_DOWNLOADS=1
Most of that is normal, apart from the MAX_INDEXES value of 250. The client has very specific requirements for this, and is the reason I am trying to compile this from source (there doesn't appear to be a way to change this value once MySQL is installed, must be done at compile).
CMake runs through the compilation (after i fixed various dependencies being missing and such), but at the end states:
-- Generating done
CMake Warning:
Manually-specified variables were not used by the project:
CMAKE_CC_COMPILER
DOWNLOAD_BOOST
ENABLE_THREAD_SAFE_CLIENT
MAX_INDEXES
WITH_BOOST
WITH_CHARSET
-- Build files have been written to: /mysql-5.6.30
This is a bit of an issue, as I specifically needed MAX_INDEXES to be written to the build files so I can install MySQL with it. Can anyone tell me A) Why is it ignoring every single variable I passed to it? and/or B) Is there any other way to enforce MAX_INDEXES (to at least 200) in a MySQL Installation. If it helps, it can be 5.6 or 5.7.
Thanks.
You can solve the MAX_INDEXES and ENABLE_THREAD_SAFE_CLIENT problem with this from the MySQL source directory (tested):
MY_FLAGS="DMAX_INDEXES=256 -DENABLE_THREAD_SAFE_CLIENT"
cmake -DCMAKE_C_FLAGS="$MY_FLAGS" -DCMAKE_CXX_FLAGS="$MY_FLAGS" .
The reason it ignored your variables was because they were not Cmake variables, but rather macros referenced by the source of MySQL (some).
The variables understood by Cmake are documented at https://dev.mysql.com/doc/refman/5.6/en/source-configuration-options.html
For the internal macros you have to search in the MySQL source.
According to mysql documentation on source configuration options, the configuration options you listed are eithes supported from a certain mysql v5.7 version or are not even listed on that page, meaning they are not mysql specific.
Compile a mysql v5.7.1 or higher from source to be able to set max_indexes config option.

MySQL++ Application error at launch

I compiled MySQL++ with no issues. When I launched some of the executables (resetdb.exe and simple1.exe) they suggest to run to test if the installation has been successful, the first error I got was that libmysql.dll was missing.
Adding its path to the PATH environment variable did not fix the problem, even after launching a new command prompt; I had to copy the DLL in the directory where MySQL++ executables are.
Now the DLL is found, but I get this error:
simple1.exe - Application error
The application was unable to start correctly (0xc000007b).
Click OK to close the application.
even launching from the command line, I get no more information than these.
Thank you for any help!
MySQL 5.5 -
MySQL++ 3.0.9 -
Windows 7 64 bits -
MINGW32 -
GCC 4.4.0
0xC000007B is a Windows error that means the executable is corrupted. It could refer either to simple1.exe or to one of the DLLs it's linking against.
Some reasons this could happen:
You're mixing toolchains in an incompatible way. In your case, you may have built simple1.exe using pieces built by MinGW GCC and pieces built by Visual C++. MinGW should be compatible with any pure C DLL built by Visual C++, including the MySQL C API DLL. However, you may have other pieces interfering. MinGW isn't compatible with VC++ at the C++ level, but then, it shouldn't have linked at all if this were your problem.
You didn't follow the MySQL C API import library build steps in README-MinGW.txt. You either missed a step, or skipped it entirely and are trying to use the import library that shipped with MySQL.
In your previous gyrations, you ended up with a corrupt object file, which got linked in. Try saying make clean all at the top level of MySQL++ to force a complete rebuild.
You're mixing versions of MySQL or MySQL++. If you have more than one version of each on the system, make sure you're consistent in their use. That is, build the C API import library from the same DLL you run the programs against, use exrun.bat to run the examples to ensure you're using the just-built version of the MySQL++ DLL instead of another you have in your PATH, etc.
Additionally, I note that you're using an older version of MySQL++. If you were on Linux, I could understand that as some distributions still ship with 3.0.9. But since you have to build MySQL++ from source with MinGW, I don't see why you're not using 3.1.0. Did you get a binary build from somewhere?
As for your PATH problem, did you restart the MinGW shell after doing this? PATH updates don't affect running programs; they keep the value they saw when they started.

Installing files to x64 "Program Files" from x86 msi

I'm creating installer using InstallShield 2010 (basic MSI) that is having two features.
First feature consists of:
main .NET application compiled as x86,
some native x86 third party dlls which are used by main application (x64 versions are unavailable).
Second feature contains single component which is an extension for MS Reporting Services compiled as AnyCPU.
During UI sequence I'm using InstallScript custom action to enumerate all available Reporting Services instances from both x86 and x64 registry trees.
The user is prompted to select on which instance he wants to deploy our extension.
Based on selected instance I'm quering registry for actual location of Reporting Services in file system which is usually something like "C:\Program Files\Microsoft SQL Server\MSSQL.2\Reporting Services" and storing this value in a MSI Property.
Then by using Set Directory action I'm setting destination directory of a component (our extension) to the value of that MSI Property.
Everything is installing perfectly fine unless you've trying to install it for x64 Reporting Services in that case extension files are installed to wrong location. Even thou MSI Property is set to correct path "C:\Program Files\MicroSoft..." (I've checked msi log) it looks like system is automatically redirecting to "Program Files (x86)".
Is there any possible solution to overcome this issue?
If you need to install to the 64-bit ProgramFiles folder, use a 64-bit MSI.
Finally solved this issue myself without creating 64bit MSI by using InstallScript custom actions.
First custom action to install:
Manually copy required files to desired location (InstallScript can access x64 Program Files)
Save this location in registry as a key component for this feature to use during uninstall
Second custom action to uninstall:
Read installed location from registry (do not use System Search to get this value due to it'll be auto translated by WindowsInstaller to "ProgramFiles (x86)")
Delete files
You can change the INSTALLDIR property to ProgramFile64 rather then ProgramFiles, this will help you to install on desired path, since you application is 32-bit so the path will be C:\ProgramFiles(x86)\Your Company Name\Your Product Name along with this have you made your components as 64-bit compatible?