[00:00] <arooni> you're referring to /var/log/mysql/ error log?
[00:00] <blackflow> arooni: I guess so
[00:00] <arooni> because i dont see any entry there
[00:01] <blackflow> arooni: is any logging configured in my.cnf? and anyway, how exactly did you change the data dir?
[00:04] <arooni> was folllowing https://www.digitalocean.com/community/tutorials/how-to-move-a-mysql-data-directory-to-a-new-location-on-ubuntu-16-04
[00:08] <blackflow> arooni: so first things first, put the apparmor profile in complain mode, see if that fixes it.
[00:10] <arooni> im googlign that
[00:11] <arooni> i'm not sure how to use sudo aa-complain /path/to/bin/  that would be my path to mysql?
[00:11] <blackflow> arooni: aa-complain usr.sbin.mysqld
[00:13] <arooni> ok thats done
[00:13] <arooni> where is the output of apparmor complaints its not in my mysql error log
[00:14] <blackflow> arooni: journal, syslog.  grep for "audit"
[00:14] <blackflow> anyway, if it's in complain mode, then it won't block. if that fixes mysqld starting up, then it means you have to adjust the profile properly.
[00:15] <blackflow> looking at that DO article, I think the problem is that it didn't reload the modified profile. I'm not sure just "restarting" AppArmor will do that.
[00:15] <blackflow> I use apparmor_parser -r   directly
[00:16] <arooni> https://gist.github.com/d5a532fb94c3ff118d2056091e8936db doesnt it mean its allowing stuff?
[00:16] <arooni> today is the first ive ever heard of apparmor
[00:16] <arooni> im a bit of a linux noob; excuse the noobness
[00:19] <blackflow> yeah in complain mode it won't actually block, but will continue auditing. so, did that fix mysql service?
[00:20] <arooni> sadly no
[00:20] <arooni> ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)
[00:20] <arooni> gawd this is annoying and frustrating
[00:20] <arooni> it shouldnt be so damn hard just to move data directory
[00:22] <blackflow> arooni: so you rsynced the original data dir to another location, changed 'datadir' directive of mysqld.conf and restarted the service?
[00:23] <blackflow> arooni: check the new dir first. that rsync command looks wrong, no trailing slash on the source directory, it'd copy the directory over to the destination
[00:23] <arooni> i did arsync the original data
[00:23] <arooni> i changed datadir
[00:23] <arooni> in the config
[00:23] <blackflow> check the destination dir you supposedly moved the files to, if it's correct
[00:23] <arooni> this was my rsync command  sudo rsync -av /var/lib/mysql data/
[00:24] <blackflow> arooni: right, and now you have .../data/mysql/...     right?
[00:24] <arooni> theres 3.6 gig there
[00:24] <arooni> so it looks to be all there
[00:24] <arooni> blackflow: its in /home/arooni/.mysql/data/mysql
[00:25] <blackflow> and that exact path is what you put into "datadir" directive of mysqld.conf?
[00:25] <blackflow> not  /home/arooni/.mysql/data/  ?
[00:26] <arooni> that was my thought too
[00:26] <arooni> 90% of the time its a typo
[00:26] <arooni> mysql starts up just fine when its in the default directory
[00:26] <blackflow> right, missing trailing slash on the src dir
[00:26] <arooni> you mean i screwed up my rsync?
[00:26] <blackflow> arooni: oh another thing... check that all path elements are accessible to the mysqld user
[00:26] <arooni> or my path in my.cnf
[00:27] <arooni> https://gist.github.com/c63b27eaa35edd92c099238ebcdd4bbb
[00:27] <blackflow> let me put it this way.....   rsync  /path/a /path/b/    will create   /path/b/a/...       and    rsync /path/a/ /path/b/       will copy files under a/ to b/
[00:28] <arooni> blackflow: so maybe i should redo the rsync
[00:28] <arooni> with full paths
[00:29] <blackflow> doesn't matter, if this works for you. the question is only fi you want   /home/david/.mysql/data/<files here>    or   /home/david/.mysql/data/mysql/<files here>
[00:29] <arooni> i dont honestly care
[00:30] <arooni> i think the files are all there; im just not sure why mysql cant find them
[00:30] <blackflow> also check that /home, /home/david and /home/david/.mysql   are accessible to the mysql user. those dirs are probably owned by david, so they ALL must have read and exec rights for "others"
[00:30] <arooni> i also need to eat dinner; but i get stubborn
[00:30] <arooni> ahhh
[00:30] <arooni> thats a good point
[00:30] <arooni> so lets ask this question
[00:30] <arooni> whats a better directory
[00:30] <blackflow> why did you even move it?
[00:30] <arooni> maybe /home/mysql
[00:30] <arooni> blackflow: was trying to free up space on root partition
[00:30] <arooni> never again
[00:31] <blackflow> if I had to do that, I'd create /home/mysql-data   just for those files
[00:31] <blackflow> and make it owned by "mysql:mysql"
[00:31] <arooni> see thats what a smart person would do
[00:31] <arooni> i always though that acls worked on linux like ; as long as the group/owner was there it didnt matter where it was
[00:31] <arooni> but i think the problem here is
[00:32] <arooni> the mysql user doesnt have access to /home/david let alone the sub dir its in
[00:32] <blackflow> no no, i tmatters, ALL path elements must be accessible
[00:32] <arooni> ahhhhhhhhhhhhh ha
[00:32] <arooni> so that was the basic lack of knowledge i had
[00:32] <arooni> lets see if moving it to /home/msyql works better
[00:32] <blackflow> yeah the kernel is checking them top-down, one by one
[00:33] <arooni> blackflow: is there anyway to test to see if the mysql user could access manually
[00:33] <arooni> i guess running su mysql
[00:33] <arooni> and then seeing if i could navigate there?
[00:33] <blackflow> yeah that's one way
[00:34] <arooni> is there a better way
[00:35] <blackflow> I wouldn't know
[00:35] <arooni> well
[00:35] <arooni> that fixed it
[00:35] <arooni> thanks for the hand holding :)
[00:35] <arooni> how do i turn off that apparmor complaining thing
[00:35] <blackflow> don't forget to adjust the apparmor profile
[00:35] <arooni> i did :)
[00:35] <blackflow> aa-enforce usr.sbin.mysqld
[00:35] <arooni> can you explain it like i'm 5 what the point of apparmor is
[00:36] <blackflow> AA is mandatory access control (MAC). unlike traditional unix (discreet access control) with users, groups and rwx, in a MAC every SUBJECT (process) is checked for access (read, write, execute, create, ......) for any OBJECT (process, file, socket, ...) it wants to interact with.
[00:37] <blackflow> so you write policies that say:   proces X can READ path Y.  or process X can execute binary Y at path Z, ...
[00:37] <blackflow> it's a bit more complex, there's more than just filesystem paths involved, but that's the gist of it
[00:37] <arooni> makes sense;  does all linux use that
[00:37] <arooni> or is it just ubuntu
[00:38] <arooni> *all linux distros
[00:38] <blackflow> ubuntu takes extensive advantage of it. CentOS, Fedora, RHEL  use another MAC system called SELinux
[00:38] <blackflow> that's pretty much it, I don't know if any other distro makes the effort to enable and provide some default profiles for a MAC like AA or SELinux
[00:39] <blackflow> at any rate, AppArmor is good. being MAC, your MySQL could get compromised and elevated to root, but root couldn't do anything that's not allowed by the profile.
[00:40] <blackflow> that's the whole point of it. without it, if your mysqld became root, then it could access anything, because it's root, right?   MAC doesn't care about users or groups, only about explicit access declared in the profiles.
[00:40] <blackflow> or in other words, with a MAC profile, you render root unprivileged.
[00:44] <arooni> so they all have their apparmor equivalent
[00:44] <arooni> when you use MAC ; what is the abbreviation youre using
[00:44] <blackflow> Mandatory Access Control
[00:47] <arooni> that makes sense
[00:47] <arooni> as i learn more about linux; seems its pretty well thought out; and secure
[00:48] <blackflow> well, it has tools and means to make your computing environment reasonably secure, but it's never absolute.