error with mysql and storebackup

I was messing around with learning how to run mysql a few weeks ago, but
have been very busy with work and haven’t had a chance to go back to it,
so I don’t really remember what I did.

In any case, I use storebackup (from the repositories), and I have it
running a daily backup. I had not really been checking, but I noticed
today that it had not been performing the backup, and had been giving me
an error. There was mail in my inbox that said the following:


running daily cronjob scripts

SCRIPT: output (stdout && stderr) follows

error: skipping "/var/log/mysql/mysqld.log" because parent directory has
insecure permissions (It's world writable or writable by group which is
not "root") Set "su" directive in config file to tell logrotate which
user/group should be used for rotation.
SCRIPT: logrotate
------- END OF OUTPUT


SCRIPT: storebackup exited with RETURNCODE = 1.
SCRIPT: output (stdout && stderr) follows

Error running backup for "/etc/storebackup.d/stbu.conf"
SCRIPT: storebackup
------- END OF OUTPUT

So, I looked up the permissions of this file, and here is what I found:


# ls -l /var/log/mysql/
total 24
-rw-r----- 1 mysql mysql 15900 Oct  2 13:15 mysqld.log
-rw-r----- 1 mysql mysql  1843 Oct  2 13:15 mysqld-upgrade.log
-rw-r----- 1 mysql mysql  2404 Oct  2 13:15 mysqld-upgrade-run.log

somehow when I started trying to learn mysql, these files were created
with the user ‘mysql’.

And then, here is what the storebackup log said:


BEGIN     2013.10.02 14:00:04 16638 backing up directory <> to
</mnt/backcron/default>
VERSION   2013.10.02 14:00:04 16638 storeBackup.pl, 3.2, build 361
INFO      2013.10.02 14:00:04 16638 setting ARG_MAX to 63488 (Linux)
ERROR     2013.10.02 14:00:04 16638 source directory <> does not exist
ERROR     2013.10.02 14:00:04 16638 caught signal 1, terminating

So you can see I am not making backups at the moment (my last backup is
over a month old).

I looked in the /etc/storebackup.d/stbu.conf file to find the “su”
directive, but I can’t figure out where I could or should do that.

So what is the best solution? I see 3 options:
1 - figure out how to tell storebackup to backup this file, but without
changing the owner and user of the mysql files (I don’t even know if
that is possible)
2 - change the owner and user of the mysql files (is that possible?)
3 - tell storebackup to skip those files (I can’t find how to do that,
but doesn’t that defeat the purpose of backing up everything?)

If there are other options, I would definitely appreciate the help.

G.O.
Box #1: 12.3 | KDE 4.10 | AMD Phenom IIX4 | 64 | 16GB
Box #2: 12.2 | KDE 4.9.2 | AMD Athlon X3 | 64 | 4GB
Laptop: 12.3 | KDE 4.10 | Core i7-2620M | 64 | 8GB

grglsn wrote:
> I was messing around with learning how to run mysql a few weeks ago, but
> have been very busy with work and haven’t had a chance to go back to it,
> so I don’t really remember what I did.
>
> In any case, I use storebackup (from the repositories), and I have it
> running a daily backup. I had not really been checking, but I noticed
> today that it had not been performing the backup, and had been giving me
> an error. There was mail in my inbox that said the following:

You seem to have multiple separate problems. I don’t know anything about
storebackup so I may not be able to help much there.

>


> running daily cronjob scripts
>
> SCRIPT: output (stdout && stderr) follows
>
> error: skipping "/var/log/mysql/mysqld.log" because parent directory has
> insecure permissions (It's world writable or writable by group which is
> not "root") Set "su" directive in config file to tell logrotate which
> user/group should be used for rotation.
> SCRIPT: logrotate
> ------- END OF OUTPUT

OK, so logrotate is objecting to the permissions of /var/log/mysql (the
parent of /var/log/mysql/mysqld.log) but see below

> SCRIPT: storebackup exited with RETURNCODE = 1.
> SCRIPT: output (stdout && stderr) follows
>
> Error running backup for "/etc/storebackup.d/stbu.conf"
> SCRIPT: storebackup
> ------- END OF OUTPUT
> 

So, I looked up the permissions of this file, and here is what I found:


> # ls -l /var/log/mysql/
> total 24
> -rw-r----- 1 mysql mysql 15900 Oct  2 13:15 mysqld.log
> -rw-r----- 1 mysql mysql  1843 Oct  2 13:15 mysqld-upgrade.log
> -rw-r----- 1 mysql mysql  2404 Oct  2 13:15 mysqld-upgrade-run.log
> 

OK, but the problem is with the directory itself, so what are ITS
permissions?

i.e. use ls -la /var/log/mysql/

somehow when I started trying to learn mysql, these files were created
with the user ‘mysql’.

As indeed they should be. That is precisely how it should be.

And then, here is what the storebackup log said:


> BEGIN     2013.10.02 14:00:04 16638 backing up directory <> to
> </mnt/backcron/default>
> VERSION   2013.10.02 14:00:04 16638 storeBackup.pl, 3.2, build 361
> INFO      2013.10.02 14:00:04 16638 setting ARG_MAX to 63488 (Linux)
> ERROR     2013.10.02 14:00:04 16638 source directory <> does not exist
> ERROR     2013.10.02 14:00:04 16638 caught signal 1, terminating
> 

So storebackup seems to be picking up an empty directory name,
presumably from its configuration file.

> So you can see I am not making backups at the moment (my last backup is
> over a month old).
>
> I looked in the /etc/storebackup.d/stbu.conf file to find the “su”
> directive, but I can’t figure out where I could or should do that.

I don’t see the relevance of an ‘su’ command?

> So what is the best solution? I see 3 options:
> 1 - figure out how to tell storebackup to backup this file, but without
> changing the owner and user of the mysql files (I don’t even know if
> that is possible)
> 2 - change the owner and user of the mysql files (is that possible?)
> 3 - tell storebackup to skip those files (I can’t find how to do that,
> but doesn’t that defeat the purpose of backing up everything?)

You seem to think that the logrotate problem is connected to the
storebackup problem. I don’t so I think all your proposals are
irrelevant or positively dangerous.

> If there are other options, I would definitely appreciate the help.

So for the logrotate problem, please use the ls -la command and post the
output.

For the storebackup problem, I guess the next step is to post your
config file, but maybe somebody else has a better idea.

On 10/02/2013 07:11 PM, Dave Howorth wrote:
>
> You seem to have multiple separate problems. I don’t know anything about
> storebackup so I may not be able to help much there.
>
>>


>> running daily cronjob scripts
>>
>> SCRIPT: output (stdout && stderr) follows
>>
>> error: skipping "/var/log/mysql/mysqld.log" because parent directory has
>> insecure permissions (It's world writable or writable by group which is
>> not "root") Set "su" directive in config file to tell logrotate which
>> user/group should be used for rotation.
>> SCRIPT: logrotate
>> ------- END OF OUTPUT
>
> OK, so logrotate is objecting to the permissions of /var/log/mysql (the
> parent of /var/log/mysql/mysqld.log) but see below
>
>> SCRIPT: storebackup exited with RETURNCODE = 1.
>> SCRIPT: output (stdout && stderr) follows
>>
>> Error running backup for "/etc/storebackup.d/stbu.conf"
>> SCRIPT: storebackup
>> ------- END OF OUTPUT
>> 

So, I looked up the permissions of this file, and here is what I found:


>> # ls -l /var/log/mysql/
>> total 24
>> -rw-r----- 1 mysql mysql 15900 Oct  2 13:15 mysqld.log
>> -rw-r----- 1 mysql mysql  1843 Oct  2 13:15 mysqld-upgrade.log
>> -rw-r----- 1 mysql mysql  2404 Oct  2 13:15 mysqld-upgrade-run.log
>> 

OK, but the problem is with the directory itself, so what are ITS
permissions?

i.e. use ls -la /var/log/mysql/

So for the logrotate problem, please use the ls -la command and post the
output.

Ok, here it is:


# ls -la /var/log/mysql/
total 32
drwxrwx---  2 mysql mysql  4096 Aug 24 16:16 .
drwxr-xr-x 13 root  root   4096 Oct  2 19:07 ..
-rw-r-----  1 mysql mysql 15900 Oct  2 13:15 mysqld.log
-rw-r-----  1 mysql mysql  1843 Oct  2 13:15 mysqld-upgrade.log
-rw-r-----  1 mysql mysql  2404 Oct  2 13:15 mysqld-upgrade-run.log

so the permissions are writeable by user and group, which happen to be
the same, and are not root.

Thanks for the help.


G.O.
Box #1: 12.3 | KDE 4.10 | AMD Phenom IIX4 | 64 | 16GB
Box #2: 12.2 | KDE 4.9.2 | AMD Athlon X3 | 64 | 4GB
Laptop: 12.3 | KDE 4.10 | Core i7-2620M | 64 | 8GB

grglsn wrote:
> On 10/02/2013 07:11 PM, Dave Howorth wrote:
>> You seem to have multiple separate problems. I don’t know anything about
>> storebackup so I may not be able to help much there.
>>
>>>


>>> running daily cronjob scripts
>>>
>>> SCRIPT: output (stdout && stderr) follows
>>>
>>> error: skipping "/var/log/mysql/mysqld.log" because parent directory has
>>> insecure permissions (It's world writable or writable by group which is
>>> not "root") Set "su" directive in config file to tell logrotate which
>>> user/group should be used for rotation.
>>> SCRIPT: logrotate
>>> ------- END OF OUTPUT
>> OK, so logrotate is objecting to the permissions of /var/log/mysql (the
>> parent of /var/log/mysql/mysqld.log) but see below
>>
>>> SCRIPT: storebackup exited with RETURNCODE = 1.
>>> SCRIPT: output (stdout && stderr) follows
>>>
>>> Error running backup for "/etc/storebackup.d/stbu.conf"
>>> SCRIPT: storebackup
>>> ------- END OF OUTPUT
>>> 

So, I looked up the permissions of this file, and here is what I found:


>>> # ls -l /var/log/mysql/
>>> total 24
>>> -rw-r----- 1 mysql mysql 15900 Oct  2 13:15 mysqld.log
>>> -rw-r----- 1 mysql mysql  1843 Oct  2 13:15 mysqld-upgrade.log
>>> -rw-r----- 1 mysql mysql  2404 Oct  2 13:15 mysqld-upgrade-run.log
>>> 

OK, but the problem is with the directory itself, so what are ITS
permissions?

i.e. use ls -la /var/log/mysql/

So for the logrotate problem, please use the ls -la command and post the
output.

Ok, here it is:


> # ls -la /var/log/mysql/
> total 32
> drwxrwx---  2 mysql mysql  4096 Aug 24 16:16 .
> drwxr-xr-x 13 root  root   4096 Oct  2 19:07 ..
> -rw-r-----  1 mysql mysql 15900 Oct  2 13:15 mysqld.log
> -rw-r-----  1 mysql mysql  1843 Oct  2 13:15 mysqld-upgrade.log
> -rw-r-----  1 mysql mysql  2404 Oct  2 13:15 mysqld-upgrade-run.log
> 

>
> so the permissions are writeable by user and group, which happen to be
> the same, and are not root.
>
> Thanks for the help.

Here’s a bug report that tells you how to fix the problem:

http://www.novell.com/support/kb/doc.php?id=7005219

What I’m not sure about is why it occurred in the first place.
Presumably the underlying issue has been fixed by now.

On 10/02/2013 09:18 PM, Dave Howorth wrote:
>> Thanks for the help.
>
> Here’s a bug report that tells you how to fix the problem:
>
> http://www.novell.com/support/kb/doc.php?id=7005219
>
> What I’m not sure about is why it occurred in the first place.
> Presumably the underlying issue has been fixed by now.
>
Excellent, thanks a ton. It is late here in Asia, so I will have to fix
it in the morning.


G.O.
Box #1: 12.3 | KDE 4.10 | AMD Phenom IIX4 | 64 | 16GB
Box #2: 12.2 | KDE 4.9.2 | AMD Athlon X3 | 64 | 4GB
Laptop: 12.3 | KDE 4.10 | Core i7-2620M | 64 | 8GB

On 10/02/2013 10:06 PM, grglsn wrote:
> On 10/02/2013 09:18 PM, Dave Howorth wrote:
>>> Thanks for the help.
>>
>> Here’s a bug report that tells you how to fix the problem:
>>
>> http://www.novell.com/support/kb/doc.php?id=7005219
>>
>> What I’m not sure about is why it occurred in the first place.
>> Presumably the underlying issue has been fixed by now.
>>
> Excellent, thanks a ton. It is late here in Asia, so I will have to fix
> it in the morning.
>

Thanks for the link, I have modified the su config file for logrotate
according to the instructions. So I will wait and see, hopefully that
will fix the problem.

I also figured out what was wrong with storebackup - I had set the wrong
directory in the storebackup configuration file.


G.O.
Box #1: 12.3 | KDE 4.10 | AMD Phenom IIX4 | 64 | 16GB
Box #2: 12.2 | KDE 4.9.2 | AMD Athlon X3 | 64 | 4GB
Laptop: 12.3 | KDE 4.10 | Core i7-2620M | 64 | 8GB