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"/>
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'm using apparmor as hardening layer for libvirt-qemu , everything is OK , but there is one thing that I can't solve systematically, let me explain :
When create a new qemu instance , profile is generated from /etc/apparmor.d/libvirt/TEMPLATE.qemu to a file with path /etc/apparmor.d/libvirt/libvirt-81303229-df4c-4b18-b33b-277bcda81b0f for example .
When instance is shut-off profile is unloaded from kernel by apparmor and it is OK as expected. But if i remove the instance definitively, i would expect that profile is removed also from filesystem, but it is not and still present in filesystem. After some time I have very big mess in libvirt instance profile files
Yes .. I can write a cron job what will be delete unnecessary libvirt profile files ... but ..is there some more clear solution , maybe builtin function of apparmor ?
Thanks
Are you using libvirt undefine to delete the stopped guest? It appears that virt-aa-helper should delete an undefined domain but I think it is a bug and you should file a ticket.
You can use the virt-aa-helper command directly to remove the files which is probably the safest as it should deal with the dependencies for you.
An example command is:
$ sudo /usr/lib/libvirt/virt-aa-helper -D -u libvirt-3c3d5aa2-f581-457d-b5ab-efbf9fdd4a6e
But it may be some edge case that they need to account for, where you can undefine a running instance to convert it to ephemeral. You would need to take care of that edge case.
Note: Because virt-aa-helper is intended to be run by libvirt you will have to use sudo with the command. If you do not it will silently fail and not remove the profile.
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!
I've successfully installed MySQL 5.6 on my F19. Although the installation was successful, I'm unable to start the mysql service.
When I ran
service mysql start
It returns the following error:
Starting MySQL..The server quit without updating PID file (/var/lib/mysql/sandboxlabs.pid).
I disabled SELinux (permissive mode), and the service started smoothly. But I did some research about disabling SELinux, and found that disabling SELinux is a bad idea. So, is there any way to add custom MySQL policy? Or should I leave the SELinux to permissive mode?
The full answer depends on your server configuration and how you're using MySQL. However, it's completely feasible to modify your SELinux policy to allow MySQL to run. In most cases, this sort of operation can be performed with a small number of shell commands.
Start by looking at /var/log/audit/audit.log. You can use audit2allow to generate a permission-granting policy around the log messages themselves. On Fedora 19, this utility is in the policycoreutils yum package.
The command
# grep mysql /var/log/audit/audit.log | audit2allow
...will output the policy code that would need to be compiled in order to allow the mysql operations that were prevented and logged in audit.log. You can review this output to determine whether you'd like to incorporate such permissions into your system's policy. It can be a bit esoteric but you can usually make out a few file permissions that mysql would need in order to run.
To enable these changes, you need to create the policy module as a compiled module:
# grep mysql /var/log/audit/audit.log | audit2allow -M mysql
...will output the saved plaintext code to mysql.te and the compiled policy code to mysql.pp. You can then use the semodule tool to import this into your system's policy.
# semodule -i mysql.pp
Once you've done this, try starting mysqld again. You might need to repeat this process a few times since mysqld might still falter on some new access permission that wasn't logged in previous runs. This is because the server daemon encounters these permission checks sequentially and if it gets tripped on one, it won't encounter the others until you allow access to the initial ones. Have patience -- sometimes you will need to create mysql1.pp mysql2.pp mysql3.pp ... and so on.
If you're really interested in combining these into a unified policy, you can take the .te files and "glue" these together to create a unified .te file. Compiling this file is only slightly more work -- you need the Makefile from /usr/share/selinux/devel/Makefile in order to convert this into a .pp file.
For more information:
If you're a more graphical type, there's also a great article by RedHat magazine on compiling policy here. There's also a great blog article which takes you through the creation of a policy here. Note the emphasis on using /usr/share/selinux/devel/Makefile to compile your own .te, .fc, and .if files (selinux source written in M4).
I followed this tutorial to the very end, then found out it didn't work right. I think I have everything installed but when I type
mysql -uroot
I only get
-bash: mysql: command not found
Note: I did not skip the "Setting the Path" step. Upon running this command for the first time:
mate ~/.bash_login
This brought up an empty file. So I added this line:
export PATH="/usr/local/bin:/usr/local/sbin:/usr/local/mysql/bin:$PATH"
I saved the file, closed TextMate, executed the following command:
. ~/.bash_login
...and continued with the tutorial. Based on your suggestions, I thought maybe the file didn't actually get saved. So I ran the following command to bring up the file again:
mate ~/.bash_login
...yet the contents of the file were as they should be.
Any suggestions?
You probably don't have the mysql binaries in your path.
The link you posted has a section on setting the path, titled "Setting the Path Do not skip this step! Most everything else will fail if you do."
EDIT: As debugging steps, try:
First launching a new terminal window. Does it run now?
Typing "echo $PATH" at the prompt. Does the path show up correctly as you've typed it in bash_profile?
Running it the long way: /usr/local/mysql/bin/mysql -u root
Does the application run?
Did you follow the step that says
Setting the Path
Do not skip this step! Most everything
else will fail if you do.
Did you close your terminal window and re-open it afterwards?
Update:
What does "which mysql" say? Does "ls /usr/local/mysql/bin" say?
Two things:
Try editing ~/.profile (rather than ~/.bash_profile or ~/.bash_login).
You may find it easier to use the native Mac style .dmg installer directly from Sun.
One nice thing about the dmg installer is that it automagically sets up symlinks to /usr/local/mysql (which means less - or no - fiddling with your $PATH).
Another option would be to use MAMP.
It has Apache, PHP and MySQL packaged with no further setup necessary.
MySQL is usually put in /usr/local/mysql/bin/
You need to add this to your PATH, you can do this by adding the follwoing lines to your .bash_profile
PATH=$PATH:/usr/local/mysql/bin/
export PATH
The .bash_profile file is located in the root of your username directory.
Make sure you restart your Terminal for the setting to take affect.
And if you're not a command-line person, I highly recommend you also install the MySQL Preference Pane to start/stop the server and install Sequel Pro to create databases and run queries.
ftp://ftp.mysql.com/pub/mysql/download/gui-tools/MySQL.prefPane-leopardfix.zip
http://www.sequelpro.com/