Does MariaDB have a default my.cnf in their sources that contains all params and their default values? I found only debian/additions/my.cnf but it does not reflect all params and seems to be updated occasionally.
For example, PHP has default php.ini in their sources, so when they change a default value or add a new option they update this file. While upgrading PHP I compare hash sums of original configs and see if something has been changed. I wonder whether MariaDB has a similar file.
No, MariaDB does not have a configuration file which would list all available options and their default values. Different MariaDB packages might provide some configuration files, but those are different, they only contain a small subset of options, and the values are different from default ones.
MariaDB default configuration can be obtained by running
mysqld --no-defaults --verbose --help
or, on a running 10.1+ server, by executing
SELECT variable_name, default_value FROM information_schema.system_variables ORDER BY variable_name
but naturally, neither of these would help to find out that variable values have changed by a hash sum. Luckily, default values of core server variables change very rarely in stable releases.
Related
After having set the path for the default working directory as well as my first (and only) project within RStudio options I wonder why RStudio keeps creating an empty folder named "R" within my "/home" directory every time it is started.
Is there any file I could delete/edit (eventually create) to stop this annoying behaviour and if so, where is it located ?
System: Linux Mint v. 19.3
Software: RStudio v. 1.3.959 / R version 3.4.4
Thanks in advance for any hints.
Yes, you can prevent the creation of the R directory — R is configurable via a set of environment variables.
However, setting these correctly isn’t trivial. The first issue is that many R packages are sensitive to the R version they’re installed with. If you upgrade R and try to load the existing package, it may break. Therefore, the R package library path should be specific to the R version.
On clusters, an additional issue is that the same library path might be read by various cluster nodes that run on different architectures; this is rare, but it happens. In such cases, compiled R packages might need to be different depending on the architecture.
Consequently, in general the R library path needs to be specific both to the R version and the system architecture.
Next, even if you configure an alternative path R will silently ignore it if it doesn’t exist. So be sure to manually create the directory that you’ve configured.
Lastly, where to put this configuration? One option would be to put it into the user environment file, the path of which can be specified with the environment variable R_ENVIRON_USER — it defaults to $HOME/.Renviron. This isn’t ideal though, because it means the user can’t temporarily override this setting when calling R: variables in this file override the calling environment.
Instead, I recommend setting this in the user profile (e.g. $HOME/.profile). However, when you use a desktop launcher to launch your RStudio, this file won’t be read, so be sure to edit your *.desktop file accordingly.1
So in sum, add the following to your $HOME/.profile:
export R_LIBS_USER=${XDG_DATA_HOME:-$HOME/.local/share}/R/%p-library/%v
And make sure this directory exists: re-source ~/.profile (launching a new shell inside the current one is not enough), and execute
mkdir -p "$(Rscript -e 'cat(Sys.getenv("R_LIBS_USER"))')"
The above is using the XDG base dir specification, which is the de-facto standard on Linux systems.2 The path is using the placeholders %p and %v. R will fill these in with the system platform and the R version (in the form major.minor), respectively.
If you want to use a custom R configuration file (“user profile”) and/or R environment file, I suggest setting their location in the same way, by configuring R_PROFILE_USER and R_ENVIRON_USER (since their default location, once again, is in the user home directory):
export R_PROFILE_USER=${XDG_CONFIG_HOME:-$HOME/.config}/R/rprofile
export R_ENVIRON_USER=${XDG_CONFIG_HOME:-$HOME/.config}/R/renviron
1 I don’t have a Linux desktop system but I believe that editing the Env entry to the following should do it:
Exec=env R_LIBS_USER=${XDG_DATA_HOME:-$HOME/.local/share}/R/%p-library/%v /path/to/rstudio
2 Other systems require different handling. On macOS, the canonical setting for the library location would be $HOME/Library/Application Support/R/library/%v. However, setting environment variables on macOS for GUI applications is frustratingly complicated.
On Windows, the canonical location is %LOCALAPPDATA%/R/library/%v. To set this variable, use [Environment]::SetEnvironmentVariable in PowerShell or, when using cmd.exe, use setx.
Is there any proper documentation available for flyway for step by step process. For instance how to set the licence-key to pro version from the community version?How to set the environment variable to assign the value FLYWAY_EDITION TO PRO
I haven't seen the configuration file setting for edition. I've been using the commandline switch "-pro" or "-enterprise".
I've been referencing the Key with this variable in the conf files..."flyway.licenseKey=FL01<512 bit key>"
If you have the variable you have to use the commandline switch, and if you use the commandline switch, you have to have the variable, either in the .conf or passed on the commandline.
In Windows: either use the environment variables dialog to create a FLYWAY_EDITION variable and set its value, or use Powershell:
set-item -path env:FLYWAY_EDITION -value 'pro'
In Linux:
export FLYWAY_EDITION=pro
Note that the valid values are community, pro and enterprise and are case-sensitive. Setting any of the command-line flags will override the environment.
I am trying to start a project using Symfony on a Mac Sierra.
I installed Symfony successfully, but I get this warning:
We selected the timezone 'UTC' for now, but please set date.timezone
to select your timezone. in
phar:///usr/local/bin/symfony/src/Symfony/Installer/NewCommand.php on
line 283 ✕ Symfony 3.2.1 was successfully installed but your system
doesn't meet its
technical requirements! Fix the following issues before executing
your Symfony application: * date.timezone setting must be set
> Set the "date.timezone" setting in php.ini* (like Europe/Paris).
I tried to change php.ini with brackets editor on the created project on folders:
project/vendor/doctrine/cache/test/travis/php.ini
project/vendor/doctrine/doctrine-cache-bundle/test/travis/php.ini
Didn't help.
As I read Symfony has built-in Apache Server.
Those php.ini files are totally unrelated to what you have to do.
Open up the Terminal and type php -i | grep "php.ini". That should reveal the location of the php.ini which is used by PHP in console mode.
XAMPP is known for using different php.ini file for the server. In order to find the the one used by the XAMPP, run a sample php file with phpinfo() from browser.
Also, note that Symonfy itself does not have the built-in server. In merely used the one PHP provided from version 5.4 and on.
Hope this helps...
I am Mac user, so , in Finder you need to go to /private/etc, find php.ini.default,
Yo need to copy that file to the desktop. To edit you need to unlock the document. Just click Unlock if asked. Rename to php.ini, set the date.timezone=Europe/YourCountry and do not forget to erase the semicolon before.And finally save it and put it back to etc.
Watch: https://www.youtube.com/watch?v=Wb6Fh-B3W-o
i recently moved from mysql to maria db , i want to enable page compression feature offered by mariadb , but i have no success with enabling it.
https://mariadb.com/kb/en/mariadb/compression/
what i did
i installed lz4 algo as mentioned in above doc
i also run few commands which were OK.
SET GLOBAL innodb_file_per_table=1;
SET GLOBAL innodb_file_format=Barracuda;
but when i run
set global innodb_compression_algorithm=lz4;
i get error
Unknown system variable 'innodb_compression_algorithm'
so any idea how to fix it , basically i have 100mb database and i want to compress it
The main point here is that not all available compression formats are compiled in by default. As you can read here https://mariadb.com/kb/en/mariadb/compression/
Because all of these compression methods are not available by default
on all distributions and MariaDB server does not bundle them, you may
need to download the desired compression method package from the above
links, install the package and finally recompile MariaDB server from
the source distribution with:
So to use lz4 you will need to recompile mariadb from source.
What's the MariaDB version that your are trying? Page compression was introduced in MariaDB 10.1. more info here
Try setting in my.cnf file
[mysqld]
innodb_compression_algorithm = lz4
I have developed a cookbook for my application which depends on Nginx cookbook. I have downloaded the Nginx cookbook from the following location
https://github.com/miketheman/nginx
and tried including the default recipe in my cookbook and overriding version attribute specified in the default attribute file. But irrespective of what i do, Nginx version 1.0.x is installed. I could not track from where it is fetching the version information. Can anyone help resolving this issue?
Thanks
If you specify the nginx cookbook as a dependency in your own wrapper cookbook, you have to deal with the strict load order of attribute files. Since Chef 11, all dependency cookbooks are loaded first, before the cookbook which requires them. As the dependency cookbooks (including nginx) are loaded, the attribute files are loaded and evaluated in this order:
attributes/default.rb of nginx
all other attributes files of nginx in alphabetical order
attributes/default.rb of your cookbook
all other attributes files of your cookbook in alphabetical order
As you can see, all the attributes of the nginx cookbook are initialized before your own attribute files are loaded. Thus, any dependent attributes (i.e. ones which are initializes using values of other existing attributes) use the values defined in the nginx cookbook, not your own.
Now, as you can see node['nginx']['source']['version'] is initialized with node['nginx']['version'] and thus uses the default value. This value is not changed if you just change node['nginx']['version'] later in your cookbook.
But fear not, there is a remedy :) You can reload specific attribute files in order to re-set their attributes. Here, this is rather convenient if you want to overwrite the nginx version. This is what I do in the attributes/default.rb in my nginx wrapper cookbook:
override['nginx']['version'] = '1.6.0'
override['nginx']['source']['checksum'] = '943ad757a1c3e8b3df2d5c4ddacc508861922e36fa10ea6f8e3a348fc9abfc1a'
# Reload nginx::source attributes with our updated version
node.from_file(run_context.resolve_attribute('nginx', 'source'))
from attributes/default.rb the default version is set to '1.4.4'
The simplest way to find out what version you've set it to is look for the following attribute on the chef-server UI:
['nginx']['version']
hopefully this should be set to whatever you've set it to!
I think that the real issue here is that the ['nginx']['version'] does not behave as you might expect it to.
According to the README file ...
If you use the nginx::default or nginx::repo recipes, you will load the latest binary package from either your platform's repository, or from the "stable" repo that is provided by the Nginx maintainers. The version attribute is effectively ignored!!.
The version attribute is only honoured if you use the nginx::source recipe, where it determines the URL of the source archive that is fetched and built.
If you use the nginx::ohai recipe, it updates the version attribute according to the version of Nginx that is currently installed.
Clear yet? If not then:
nginx::default gives you a (typically) old version of Nginx
nginx::repo gives you a (typically) more recent stable version of Nginx
nginx::source is the only recipe that allows you to specify the version of Nginx that you want.
If that doesn't seem to explain what you are seeing ... you need to dive into the recipe source code. The recipe behaviour (e.g. selection of installation repositories) varies across the different platforms / families.