It's a breeze to provision Vagrant to echo "hello world". Heck, even I can handle that!
But when it comes to doing things a user would actually like to do when provisioning a box, such as installing mysql, creating a database, and creating a mysql user, well... those things just don't seem to work. ARRG.
I'm working with a virtual CentOS server and installing MySQL goes off without a hitch, but that's about where I meet the proverbial brick wall. Bear in mind, I can do all these things easily by SSH'ing into the box (but of course that defeats the purpose of provisioning):
echo "hello world"; <-- good
sudo yum install mysql-server -y; <-- good
sudo /sbin/service mysqld start; <-- good
sudo mysql create user 'mycooluser'#'%' identified by 'mypassword'; <-- BAD
I've been Googling all over the place and the closest I've come is this article, but since it is based on Ubuntu rather than CentOS, I got stuck right away since apparently yum doesn't know what debconf-utils is, while apt does.
Can anyone shed some light on this for me? I don't think mine is an outrageous use-case, all I want to do is have the shell provisioner
install mysql
create database
create user and grant him all privileges
run db_setup.sql to add table structure and data to new database
Please don't tell me to "use chef or puppet". I've already tried and they had their own sets of issues and honestly feel like overkill for these simple requirements. Surely these items can be accomplished with a shell provisioner?
Thanks a lot for any insight. You may be able to tell I'm at my wit's end.
Here is my Vagrantfile:
# -*- mode: ruby -*-
# vi: set ft=ruby :
VAGRANTFILE_API_VERSION = "2"
$script = <<SCRIPT
set -x
echo I am provisioning...
date > /etc/vagrant_provisioned_at
echo "hello world"
yum install mysql-server -y
/sbin/service mysqld start
mysql -e "create user 'mycooluser'#'%' identified by 'mypassword'"
SCRIPT
Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|
config.vm.box = "chef/centos-6.5"
config.vm.provision :shell, :inline => $script
end
vagrant up should get you a centos-6.5 OS with mysql and the user 'mycooluser'.
To verify:
vagrant ssh to the box after it has finished provisioning and perform the following within the centos guest OS.
mysql -uroot
mysql> SELECT User FROM mysql.user;
+------------+
| User |
+------------+
| mycooluser |
| root |
| |
| root |
| |
| root |
+------------+
6 rows in set (0.00 sec)
Note: You will probably want to grant privileges for 'mycooluser' in order to login using the mysql shell etc.
More details can be found here.
Related
I am trying to setup MariaDB in a Docker container for CI/CD testing.
However, the way I do it the DB does not exist when I log into the container.
Here's parts of my Dockerfile
FROM debian:stable-slim
RUN apt -y install mariadb-server mariadb-client
EXPOSE 3306
ADD ./DBShema.sql /db/DBShema.sql
RUN mysqld_safe \
mysqladmin --silent --wait=30 ping \
mysql < /db/DBShema.sql
Does not show my DB / tables.
MariaDB [(none)]> show databases;
+--------------------+
| Database |
+--------------------+
| information_schema |
| mysql |
| performance_schema |
+--------------------+
3 rows in set (0.001 sec)
How should that go properly to make the piped DB info persistent?
I think you are overcomplicating things. I do not see the point of starting from a plain Debian installation that requires you to install the RDBMS manually.
There are MariaDB images already made that you can use as a starting point for your CI images. Take the following Dockerfile as an example:
FROM mariadb:10.6.4-focal
COPY schema.sql /docker-entrypoint-initdb.d
This effectively copies over an sql script into the directory that is used to initialize the database on the first container start. This is mentioned in this portion of the documentation.
Once this is done the spun off container will contain all the changes included in the related sql file. I hope this is what you want.
I can't create a database after logging in mysql under my root account. Do I have to make an admin account to do so? Also, for some reason, my StartUp file didn't install (there was an error). I'm not sure if that will affect anything else since mySQL DOES start up when I type "mysql" into my terminal.
Also when I type in
mysql> SELECT Host, User FROM mysql.user;
+---------------------+------+
| Host | User |
+---------------------+------+
| 127.0.0.1 | root |
| ::1 | root |
| myname-mac.att.net | |
| myname-mac.att.net | root |
| localhost | |
| localhost | root |
+---------------------+------+
Which I don't get. I seem to have multiple root users and I don't know what ::1 means.
EDIT: My databases currently look like this.
mysql> SHOW DATABASES;
+--------------------+
| Database |
+--------------------+
| information_schema |
+--------------------+
1 row in set (0.02 sec)
And it doesn't matter what I type in as my database name. I even tried calling it 'apple'.
It might be problem with space.
Follow this
Check .err logs at /var/lib/mysql
if the log says something like
"[ERROR] Can't start server: can't create PID file: No space left on device"
Check /var size by df -hk /var
if used is 100% , then u have to find the files which is geting filled.
find large file in /var by
find /var/ -type f -size +100000k -exec ls -lh {} \; | awk '{ print $9 ": " $5 }'
see which file you can delete and then restart the mysql process by
/etc/init.d/mysql restart
let me know if that worked :)
If you're on macosx and if you've system preference pane installed, that should show a message like
the following directory is not owned by _mysql user - "/usr/local/msyql/data"
Once you know that path you can do the following:
sudo chown -R mysql:mysql /usr/local/mysql/data
sudo chown -R mysql:mysql <path>
You have one root user for several domains. Meaning you can connect and run queries on that database FROM the specified domains.
If you want to only show one, give it '%' for the domain and remove all others, although that is not advised. Save the root user for run rights only from localhost, and create limited users for running queries from outside.
As for test database error, it happens on fresh installs. Just reboot the mysql server(stop/start process) or the computer.
Also, make sure you have full rights by doing
GRANT ALL PRIVILEGES ON *.* TO 'root'#'thedomainyourunfrom/localhost/%' WITH GRANT OPTION;
this will give your root user full rights across all databases in the server
osx manual http://dev.mysql.com/doc/mysql-macosx-excerpt/5.0/en/macosx-installation.html
As an additional resource, you can try two other things:
Find out the data folder for your MySQL and 'chown' it so that mysql can write properly to it. For example, if your MySQL's data folder is /usr/local/mysql/data/, you can 'chown' it by typing up the command chown -R mysql:mysql /usr/local/mysql/data/
If you have just installed your MySQL server, try restarting your computer. Sometimes the installer fails on giving proper file access to the program
I hope that helps!
I can't create a database after logging in mysql under my root account. Do I have to make an admin account to do so? Also, for some reason, my StartUp file didn't install (there was an error). I'm not sure if that will affect anything else since mySQL DOES start up when I type "mysql" into my terminal.
Also when I type in
mysql> SELECT Host, User FROM mysql.user;
+---------------------+------+
| Host | User |
+---------------------+------+
| 127.0.0.1 | root |
| ::1 | root |
| myname-mac.att.net | |
| myname-mac.att.net | root |
| localhost | |
| localhost | root |
+---------------------+------+
Which I don't get. I seem to have multiple root users and I don't know what ::1 means.
EDIT: My databases currently look like this.
mysql> SHOW DATABASES;
+--------------------+
| Database |
+--------------------+
| information_schema |
+--------------------+
1 row in set (0.02 sec)
And it doesn't matter what I type in as my database name. I even tried calling it 'apple'.
It might be problem with space.
Follow this
Check .err logs at /var/lib/mysql
if the log says something like
"[ERROR] Can't start server: can't create PID file: No space left on device"
Check /var size by df -hk /var
if used is 100% , then u have to find the files which is geting filled.
find large file in /var by
find /var/ -type f -size +100000k -exec ls -lh {} \; | awk '{ print $9 ": " $5 }'
see which file you can delete and then restart the mysql process by
/etc/init.d/mysql restart
let me know if that worked :)
If you're on macosx and if you've system preference pane installed, that should show a message like
the following directory is not owned by _mysql user - "/usr/local/msyql/data"
Once you know that path you can do the following:
sudo chown -R mysql:mysql /usr/local/mysql/data
sudo chown -R mysql:mysql <path>
You have one root user for several domains. Meaning you can connect and run queries on that database FROM the specified domains.
If you want to only show one, give it '%' for the domain and remove all others, although that is not advised. Save the root user for run rights only from localhost, and create limited users for running queries from outside.
As for test database error, it happens on fresh installs. Just reboot the mysql server(stop/start process) or the computer.
Also, make sure you have full rights by doing
GRANT ALL PRIVILEGES ON *.* TO 'root'#'thedomainyourunfrom/localhost/%' WITH GRANT OPTION;
this will give your root user full rights across all databases in the server
osx manual http://dev.mysql.com/doc/mysql-macosx-excerpt/5.0/en/macosx-installation.html
As an additional resource, you can try two other things:
Find out the data folder for your MySQL and 'chown' it so that mysql can write properly to it. For example, if your MySQL's data folder is /usr/local/mysql/data/, you can 'chown' it by typing up the command chown -R mysql:mysql /usr/local/mysql/data/
If you have just installed your MySQL server, try restarting your computer. Sometimes the installer fails on giving proper file access to the program
I hope that helps!
I'm trying to understand the reason why I keep experiencing problems while using INTO OUTFILE command.
I always get this erroro:
ERROR 1 (HY000): Can't create/write to file '/var/www/p1.txt' (Errcode: 13)
SELECT password FROM mysql.user WHERE user='root' INTO OUTFILE '/var/www/p1.txt';
Useful details:
web application : DVWA (localhost) (for study purposes)
Server: Apache/2.2.14 (Ubuntu) - PHP/5.3.2
MySQL version 5.1.63
Operating system Linux Backtrack 5r3.
I'm running the command as root. Also, I can freely create folders or files in /var/www/
Errcode 13 I know it means permission denied, but what should I do in order to fix the problem?
Any help will be highly appreciated.
Even if you're logged in as root into MySQL, the file write will be performed as the user running the actual MySQL daemon.
In other words, you should check which user runs mysqld, and give write permission to the directory for that user.
you must alter the permissions for user mysqld. start by running the following command sudo aa-status to check your user status and authorized directories. if you want to change permissions, edit /etc/apparmor.d/usr.sbin.mysqld and insert the directories you want.
you must then restart apparmor sudo /etc/init.d/apparmor restart
chown /var/www to the user trying to write the file, or chmod 777 /var/www
this is probably not a secure way of doing it, you might like to consider putting the file elsewhere
Although this post is quite old, in 2018 this problem is still there. I spent a couple of hours banging my head in this maze.
Server version: 5.7.24 MySQL Community Server (GPL) running on Ubuntu 14.04
To allow MySql to SELECT INTO OUTFILE requires to set MySQL's secure-file-priv option in your configuration.
Append the following 2 lines to /etc/mysql/mysql.conf:
[mysqld]
# allow INTO OUTFILE file and LOAD DATA INFILE to this directory
secure_file_priv=/usr/share/mysql-files
/usr/share/mysql-files is the directory where my files will be stored. I created it doing:
sudo su
cd /usr/share
mkdir mysql-files
chown mysql:mysql mysql-files
chmod a+rw mysql-files
Change /usr/share/mysql-files for whatever you prefer, but avoid to use the /tmp directory!
Why?
Because, at next time you'll be rebooting, the /tmp directory is happily erased including your precious mysql-files sub-directory. The mysql service then chokes and it won't start, leading to wierd errors with cryptics messages.
restart mysql and check:
sudo su
service mysql restart
mysql
mysql> SHOW VARIABLES LIKE "%secure%";
+--------------------------+-------------------------+
| Variable_name | Value |
+--------------------------+-------------------------+
| require_secure_transport | OFF |
| secure_auth | ON |
| secure_file_priv | /usr/share/mysql-files/ |
+--------------------------+-------------------------+
3 rows in set (0.07 sec)
mysql> quit
Bye
You are not done, yet!
There is a troll by the name of apparmor who will ruines your project.
Edit the file /etc/apparmor/local/usr/sbin/mysqld and append the
following 2 lines -- don't forget the ending commas:
/usr/share/mysql-files rw,
/usr/share/mysql-files/** rw,
save it, and reparse:
sudo apparmor_parser -r /etc/apparmor.d/usr.sbin.mysqld
That should make it.
On centos the selinux thing is playing not-nice.
$ getenforce
Enforcing
$ setenforce 0
Permissive
Now this is crude, but worked for me (until reboot, then it switches back on).
If this temporary measure works, you need to google for how to configure selinux properly.
Check the user of mysqld with,
ps -aef | grep mysql
mysql 9355 9102 0 Aug24 ? 21:53:25 /usr/libexec/mysqld
Check wiich group mysql belong to with,
groups mysql
mysql : mysql www
Then write the file under path which belong to mysql or have write permission for group www and mysql. For example, test under has write permission to group www.
ll /data/
drwxrwxr-x 2 www www 4096 Dec 9 19:31 test
Then execute mysql mysql -u root -p -e 'use sc_test; select file_path from sc_files INTO OUTFILE "/data/test/paths.txt";'
I was fighting with this enigmatic error for hours, too, tried everything I could find, to no avail, and finally remembered I already had this same problem years before without being able to find a solution back then no matter how long I searched for and tried all these smart counsels.
secure_file_priv was new to me but I didn't try this because I didn't want to rebuild my docker container just to make this work.
Solution
Looking at my docker-compose file I found the solution to this problem: I didn't have a mapping to the target directory, so for the mysql container this directory wasn't existent.
Workaround
Back then I developed a workaround for my cron jobs:
first dump to tmp (to which my container has a mapping)
mv to where it should be in the first place
Well, it works fine, so why bother.
I have searched and found this post (http://stackoverflow.com/questions/1814297/cant-load-file-data-in-the-mysql-directory) but it is not working for me.
i am un Ubuntu 12.04 and MySQL version is 5.5.22-0ubuntu1
I have logged into MySQL as root and so grants should all be okay:
mysql> show grants;
+---------------------------------------------------------------------+
| Grants for root#localhost |
+---------------------------------------------------------------------+
| GRANT ALL PRIVILEGES ON *.* TO 'root'#'localhost' WITH GRANT OPTION |
| GRANT PROXY ON ''#'' TO 'root'#'localhost' WITH GRANT OPTION |
+---------------------------------------------------------------------+
I am trying to insert some data from a text file into a MySQL database and the LOAD_FILE function doesn't seem to work properly
I created a test file, permissions of 777 and copied to root of the install (I tried changing owner/group to root:root and mysql:mysql and still no good):
mysql> select load_file('/test.txt');
+------------------------+
| load_file('/test.txt') |
+------------------------+
| NULL |
+------------------------+
1 row in set (0.00 sec)
But if I try this:
mysql> select load_file('/etc/hosts');
It works fine. If I copy the test file into /etc it still fails.
has anyone seen this before or can perhaps point me to another way to load into the database?
To use load_file, the following conditions must be met (from the documentation):
The file must be located on the server host
You must specify the full path name to the file, and you must have the FILE privilege.
The file must be readable by all and its size less than max_allowed_packet bytes.
If the secure_file_priv system variable is set to a nonempty directory name, the file to be loaded must be located in that directory.
If the file contains SQL statements that you want to execute, an easier approach might be to pipe it in:
mysql -u foo -p dbname < filename.sql
Im not an expert on MySQL, but ive observed that MySQL version 5.5 has a problem with UBUNTU OS.
Even after following the documentation in mysql docs LOAD_FILE() didnt work.
There is a service called apparmour, preventing the function LOAD_FILE() from executing, i tried stopping that service but still it persisted.....
I know this doesnt solve your problem, but at least it'll help u find where the problem is......
Consider this one-liner (note, I'm on Ubuntu):
printf "$(cat update_xml.sql)" "$(cat my.xml | sed s/"'"/"\\\'"/g)" | mysql -h myRemoteHost -u me -p***
In update_xml.sql there is:
UPDATE
myTable
SET
myXmlColumn = '%s'
WHERE
...
Adding this for future reference. Probably won't help the OP.
As noted before, AppArmor is to blame. You need to whitelist the paths needed for load_file into the provided profile which can be found here: /etc/apparmor.d/usr.sbin.mysqld. The apparmor.d documentation can be found here. This is the recommended way as AppArmor has its reasons to be there.
Alternatives:
This is the unrecommended method. Disable the usr.sbin.mysqld profile so you won't expose all the services. Simply link the profile to /etc/apparmor.d/disable with ln -s /etc/apparmor.d/usr.sbin.mysqld /etc/apparmor.d/disable/usr.sbin.mysqld. Reload the profiles with /etc/init.d/apparmor restart. It probably makes sense for a development machine.
This is the highly unrecommended method, if you don't actually need AppArmor. The profiles can be unloaded with /etc/init.d/apparmor teardown. Disable the init script with update-rc.d -f apparmor remove.
All the above stuff requires root privileges, but I skipped the ever repetitive sudo in front of all the commands.