I am building an installer for our product which works well. I've managed to build custom actions to install our services including a MySQL server.
The problem I have is executing a sql file to build the schema structures.
I have a custom action which uses mysql.exe and the command line arguments:
--port=### --user=### --password=### < "[INSTALLDIR]db\EmptyStruct.sql"
It tries to execute this ok but the cmd window which pops up, during the install, just runs through the mysql.exe command line options, which says to me that the command line it gets passed is not correct. However if I run the command manually after the install, it works perfectly.
Does anyone has any ideas please.
I'm making a few assumptions here:
You have a Windows Installer exe custom action that specifies mysql.exe and a command line as you showed
You are expecting the contents of [INSTALLDIR]db\EmptyStruct.sql to be redirected to mysql.exe's standard input
This will not happen. Behind the scenes, Windows Installer's exe custom action support uses the CreateProcess API and this API will interpret command lines literally. However the redirect < needs special handling to actually perform redirection.
To get that behavior, you must use a layer of indirection. For example, you could run cmd.exe as the exe, and give it a command line that will make it interpret and run the command line mysql.exe --port= ... < "[INSTALLDIR]...". However, if you didn't already have a command prompt showing, this would cause one to show up. If you want to avoid that, you could write a custom wrapper that performs the redirection for you, either as a C++ DLL or, say, InstallScript action.
Alternately, if there is a parameter that tells mysql.exe to run a script from a file, you could pass that instead of using redirection. I wasn't able to find evidence of such a parameter in a quick web search.
Thanks for your comments Michael and I used cmd.exe /k AddStruct.bat to accomplish the task!
Related
This question already has an answer here:
VS code terminal can't find AWS SAM even though windows terminal can
(1 answer)
Closed yesterday.
So I downloaded the MySQL installer from https://dev.mysql.com/downloads/installer/. I then went through the process of setting it up via the installer etc. After this was complete, I went to test the command in both Windows PowerShell and CMD, but neither worked.
I looked everywhere I could online to find out what the issue was, but nothing really worked. I found a post that said to add the MySQL path to the main system PATH and so I did. The command I used was:
SET PATH=%PATH%;C:\Program Files\MySQL\MySQL Server 8.0\bin
I also manually edited my environment variables and checked everything there. HOWEVER, a really weird thing is that when I run that command in cmd the mysql --version command WORKS! When I run the same command in Powershell it doesn't, and when I close Windows Terminal and re-open it, the command no longer works in cmd! I really have no idea whats going on. The error message I receive in PowerShell is:
PS C:\Users\User> mysql --version
mysql: The term 'mysql' is not recognized as a name of a cmdlet, function, script file, or executable program.
Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
And the error message I receive in CMD is:
C:\Users\User>mysql --version
'mysql' is not recognized as an internal or external command,
operable program or batch file.
If anyone could give me a hand, that'd be amazing, thanks.
Adding to the PATH the way you did is only temporary. It lasts as long as the terminal is open, and when the terminal is gone, so is the change to the path. Use setx instead of set to make it permanent, or make the change using the UI in Windows settings. To do the latter, open the Settings dialog and type Environment into the search box, and then choose the option to change the system environmental variables. When the System Properties dialog appears, click the Environmental variables button at the lower right.
I have created setup using installshield and everything is work file. Now I have one batch file and want to run with setup. I know we can create custom action and I have already created custom action for run powershell script and it is working fine.
Can anyone help/guide me for using which custom action I can execute the batch file?
Also I want to run MySQL script from installshield setup.
What I have tried:
I have tried to create different custom action but I don't know exactly which custom action is used for execute the batch file.
ASSUMING AN MSI INSTALLATION:
In your MSI Installation Designer pane, click on "Custom Actions and Sequences"; in the top part of the middle pane right click on "Custom Actions" and choose "New EXE -> Stored in Binary Table". Give it a name (and description, if you like). When it saves, right-click it and start the Custom Action Wizard.
The Action Type should be "Launch an executable" and the Location should be "Stored in the Directory Table".
For Action Parameters "Source", choose the directory you want to start in. For target enter a command to invoke your script, like cmd /c .\RunMyScript.bat arg1 arg2 ... (assuming the script is in the directory you started in.) If the script is in a different folder you can put one of your directory variables in brackets: cmd /c [INSTALLDIR]bin\script.bat. Typically the directory variable will already include a trailing backslash; using these variables with the bracket syntax helps make sure the action works even if the user chooses a different installation folder.
If the script is in a folder that is not a required part of the installation, you may need to make your command be something like cmd /c if exist .\script.bat .\script.bat - so that the custom action does not fail if the feature containing your script is not selected for install (or is removed when an installation is modified.)
I have typically wanted execution to be synchronous (install waits until script finishes before moving on); if your script does not return a reliable exit code, or if you don't want the installation to abort if the script fails, choose the one with "(Ignores error code)".
The custom action should typically be in the InstallExec sequence, after files are installed (but a script you run during an uninstall or repair could run earlier or in a different sequence.)
I'm new to servers and programming in general, and I have a question regarding remote acces to a server, and how much I can actually do on it.
The thin is I have a working program on a linux server, which I acces with my windows machine using mobaxterm. I can acces the server, I see folders and a cmd line, where I can compile a makefile. Everything runs well, however when I run the makefile it just compiles, and doesn't do anything. No error messages, but also no opening of a program. I don't understand anything. Is it a delimitation of the servers structure, that it can only store files on it?
When you compile under linux using a make, it produces an executable but does not run it. Make builds executable objects, but it does not run them. You should include your makefile in the question (reduced to a minimum if it is large). Inside it, you will see that it generates a executable file with a specific name. To run it, you need to invoke this from the command line.
To find out what it is building, a quick way is to type "make clean" (press enter of course) to clean up any built objects. Then type the "ls" command to see what is in your directory.
Next, build the program with the "make" command, then type "ls" to see what has been added. Ignore any new files that end in .o or .a or .so and look for any new files. These are the files built by make and at least one of them is the program you built.
Assuming you found a new file called "myprogram". To run it, type:
./myprogram
How can I get ejabberd to run an external auth script on windows?
So far- I've modified the file
C:\Program
Files\ejabberd-15.06\lib\ejabberd-15.06\priv\cfg\ejabberd.yml
to comment out the existing auth_method directive and instead added this:
auth_method: external
extauth_program: "D:\\DROPBOX\\Dropbox (Personal)\\EJABBERD\\auth\\ejabberd-auth.exe"
However, when I try to connect to the server- I see nothing in the logs indicating an attempt to run the script. I've even tried changing it to a non-existant file to see if that will log an error of some sort, but nothing.
All I get are "Accepted connection" type of logs.
In case it matters- upon start I do get several "unknown option" errors, including "ejabberd_config:validate_opts:752 unknown option 'auth_method' will be likely ignored" - however it seems this is a known, cosmetic-only error (see: https://github.com/processone/ejabberd/issues/630)
I do not use Windows, but, you should try playing with Erlang open_port command:
open_port({spawn, "YOURCOMMAND"}, [{packet, 2}]).
Note that open_port Erlang documentation says:
For external programs, the PATH is searched (or an equivalent method is used to find programs, depending on operating system). This is done by invoking the shell on certain platforms. The first space separated token of the command will be considered as the name of the executable (or driver). This (among other things) makes this option unsuitable for running programs having spaces in file or directory names.
I see your path has spaces. That alone should indeed make it impossible to call your command.
That said, external_auth command has never been tested on Windows. You may need to patch ejabberd command to make that authentication through external process work. I would be surprised if it works as is.
I am trying to build an msi that will upgrade an installation of mysql.
I can perform the basic upgrade of files and on a clean install everything works fine, the problem I have is, when performing an upgrade I need to perform a couple of actions around the uninstall of the previous version.
The only action I'm having trouble with is a change of one of the MySQL GLOBAL settings using the following command line
mysql.exe -u root --host=127.0.0.1 --port=5002 mysql --execute="SET GLOBAL innodb_fast_shutdown=0"
I do this as it is suggested that when upgrading a database innodb should perform a slow shutdown and this was the easiest way I could see of doing this.
Currently I use the following Wix to perform this action
<CustomAction Id="Innodb_slowshutdown" Property="OLDMYSQLEXE" Execute="immediate"
ExeCommand=""[MYSQLINSTALLBINPATH]mysql.exe" -u root --host=127.0.0.1 --port=5002 mysql --execute="SET GLOBAL innodb_fast_shutdown=0""
Return="check" Impersonate="yes"/>
...
<Custom Action="Innodb_slowshutdown" After="InstallInitialize">UPGRADEFOUND and NOT UPGRADINGPRODUCTCODE and NOT REINSTALL and MYSQLINSTALLBINPATH</Custom>
<RemoveExistingProducts After="Innodb_slowshutdown" />
However this always fails and I cannot understand why as when the fail occurs I copy the exact command line from the msiexec log and run it through a command line.
This works exactly as I would expect but I cannot figure out what the custom action is doing that is different.
During the install a console opens briefly and it would seem that the MySQL executable runs but something is wrong with the arguments and it causes a load of help info to come up, though I cant be sure this is exactly whats happening as it passes very quick.
Is there any way to pause the install at this point so I can see what is in the console?
Can anyone see any obvious problems with my Wix?
EDIT -
Also I'm not sure if this has anything to do with user rights, I run MSIEXEC from a command prompt opened "As Administrator" but if I did need to elevate rights how could I do this when I need to execute the action with the type immediate?
Please note I am aware that Immediate does not allow elevated rights but I cannot use deferred as it will not allow me to execute the command before RemoveExistingProducts.
I am not even sure it is anything to do with rights, I am merely pointing out that I have considered this as a possible reason but I cannot prove it.
Windows Installer doesn't support immediate custom actions that run with elevated rights. To execute a custom action with elevated rights, it must be marked Deferred="yes" and Impersonate="no".
Ok I found my mistake, this was due to not knowing how a Type 50 CaustomAction works.
All I had to do was to use a Property that contained the full path of the executable I wanted to execute and use ONLY command line arguments in the ExecuteCmd property
<CustomAction Id="Innodb_slowshutdown" Property="OLDMYSQLEXE" Execute="immediate"
ExeCommand="-u root --host=127.0.0.1 --port=5002 mysql --execute="SET GLOBAL innodb_fast_shutdown=0""
Return="check" Impersonate="yes"/>