enablefileprotect bug and how to report it?

[LinuxStandard]

I've found a few bugs here and there in cPanel over the last few months, but I haven't had the time to find where to report these. I suspect others have reported some as some of the bugs eventually get fixed.

Is there an official bug reporting procedure page I can find somewhere?

Bug #1:

FreeBSD: /scripts/enablefileprotect with filesystems acls enabled gives:

Undefined subroutine &main::setuids called at /scripts/enablefileprotect line 56.

adding:

sub setuids {
my($user) = $_[0];
my($uid,$gid);
(undef,undef,$uid,$gid) = getpwnam($user);
if ( ! ($( = int($gid)) ) {
print "error setting gid\n";
exit;
}
}

to the file fixes this issue.

Bug #2:

cpbackup on FreeBSD cannot copy daily backups to weekly/monthly backups. There is sufficient disk space and file permissions should not be that unusual.

Background:

rsync version 2.6.9 protocol version 29

/backup/ is 68GB in size. The total account disk usage of all accounts is 10GB.

Compression is enabled and mounting options are disabled.

I've never been able to pin this down and it has been a problem for a very long time.

[cPanelDavidG]

You can submit official bug reports by going to http://bugzilla.cpanel.net

There's also a convenient link to it in the "cPanel Links" menu in this forum (scroll up) .

[LinuxStandard]

You can submit official bug reports by going to http://bugzilla.cpanel.net

There's also a convenient link to it in the "cPanel Links" menu in this forum (scroll up) .

I'm aware of the bugzilla system, but is there an official format or is it treated the same as other bugzilla systems implemented by Mozilla and others?

[cpanelkenneth]

Please report a single issue per bug report. Hence for what you posted above, there should be two reports. Also, please don't open a bug report that consists merely of a link to a forum thread.

Ideally what we want is enough information in order re-create the bug. Details are important, especially if reporting an issue on a highly modified system. Full cPanel version number is also very relevant. Screenshots can be useful.

For the first issue, simply copying and pasting what you posted here will suffice as I've already examined the script in question and noted the error.

For the second issue, some extra info is useful. For example, is /backup on a separate slice/drive? Are quotas or ACLs enabled on /backup ? Any output in any log (system or cPanel) regarding failure to copy the backups to weekly/monthly ?

[LinuxStandard]

Please report a single issue per bug report. Hence for what you posted above, there should be two reports. Also, please don't open a bug report that consists merely of a link to a forum thread.

Ideally what we want is enough information in order re-create the bug. Details are important, especially if reporting an issue on a highly modified system. Full cPanel version number is also very relevant. Screenshots can be useful.

For the first issue, simply copying and pasting what you posted here will suffice as I've already examined the script in question and noted the error.

For the second issue, some extra info is useful. For example, is /backup on a separate slice/drive? Are quotas or ACLs enabled on /backup ? Any output in any log (system or cPanel) regarding failure to copy the backups to weekly/monthly ?

No quotas, no acls, and nothing highly unusual.

The options for the mount are:

rw,noexec,nosuid,nodev

and could be the source of some issue for it, but it seems rsync would not be executed from /backup/ itself. I have no logs, no error messages, and nothing to go on. I have never been able to track this bug down and it has been in place through cPanel 10 - 11 and FreeBSD 5.4 - 6.3 (on the same system).

[cpanelkenneth]

No quotas, no acls, and nothing highly unusual.

The options for the mount are:

rw,noexec,nosuid,nodev

and could be the source of some issue for it, but it seems rsync would not be executed from /backup/ itself. I have no logs, no error messages, and nothing to go on. I have never been able to track this bug down and it has been in place through cPanel 10 - 11 and FreeBSD 5.4 - 6.3 (on the same system).

I've informed the developers of the first issue. As for the second issue, I'm having difficulty reproducing it. Could you provide an example ACL for an account?

[LinuxStandard]

I've informed the developers of the first issue. As for the second issue, I'm having difficulty reproducing it. Could you provide an example ACL for an account?

It has no trouble backing up the actual account data. It is able to complete a full daily backup bearing in mind that PostgreSQL is disabled (bug 6361). The problem is with the ability for it to copy the daily backup folder to the weekly backup folder:

The normal shell operation would be:

cp -Rf /backup/cpbackup/daily/* /backup/cpbackup/weekly/

Do you have any information on the rsync command that performs this action for the cpbackup script?

Edit: I have been away for a few days so I have not had a chance to respond. Thank you for following up on these issues.

[cpanelkenneth]

It has no trouble backing up the actual account data. It is able to complete a full daily backup bearing in mind that PostgreSQL is disabled (bug 6361). The problem is with the ability for it to copy the daily backup folder to the weekly backup folder:

The normal shell operation would be:

cp -Rf /backup/cpbackup/daily/* /backup/cpbackup/weekly/

Do you have any information on the rsync command that performs this action for the cpbackup script?

Edit: I have been away for a few days so I have not had a chance to respond. Thank you for following up on these issues.

The rsync command, flags and arguments are documented within /scripts/cpbackup. By default, the flags used are -rlptD. Checking rsync version 2.6.9 protocol version 29 on FreeBSD 6.3 shows those flags are valid.

Which version of FreeBSD are you using?

[LinuxStandard]

The system is running FreeBSD 6.3 so bugger me if I know what the problem is.

I've looked through the cpbackup file, but I haven't had the time to reconstruct the exact command it will issue to the system to copy the daily to weekly. That might be the information needed to find out why this is not working properly.

[cpanelkenneth]

The command is this:

cpusystem( "rsync", $rsyncopts, "--delete", "${basedir}/daily/", "${basedir}/weekly" );

Which is interpolated to this:

cpusystem( "rsync", '-rlptD, "--delete", "/backup/cpbackup/daily/", "/backup/cpbackup/weekly" );

or whatever is specified in your backup config for the backup directory.

The problem might be in cpusystem on your system. That function takes the arguments given and passes them to:

• cpuwatch
• or logwatch
• or executes directly if the prior two are not found

The first two binaries are in /usr/local/cpanel/bin

At this time I'm unable to replicate either this bug, or the PosgtgreSQL bug you filed. Would you mind opening a complimentary support ticket at https://tickets.cpanel.net/submit/ ? Please mark it: ATTN QA: FreeBSD backup bug

There is obviously something amiss, something different between your system(s) and our test systems.

[LinuxStandard]

Hi,

Thank you for following up.

The cpbackup script runs into the PostgreSQL error when attempting to run:

sh -c echo "1442 LISTUSERS 0 0" | /usr/local/cpanel/bin/postgresadmin

More about the system:

perl version/build:

This is perl, v5.8.8 built for i386-freebsd-64int
(with 1 registered patch, see perl -V for more detail)

PostgreSQL version:

postgres (PostgreSQL) 8.2.6

FreeBSD version/kernel version:

FreeBSD 6.3-RELEASE-p1 #5:

The actual output of the script itself is:

Grabbing PostgreSQL databases............
could not change directory to "/usr/local/etc/"
Password for user postgres: .........
.........
.........
.........

/usr/local/etc will be replaced with the directory the shell session was in when the cpbackup run was manually started.

The ............. will continue without end until it is interrupted and will then go into an infinite loop requesting the password.

The backup error is indeed very unusual. I have been working on tracking it down for quite some time and it has proved to be quite difficult.

/usr/local/cpanel/bin/ contains cpuwatch, but no copy of logwatch. A find search run on all files under /usr/local/cpanel failed to return any results for logwatch and logwatch also isn't in the PATH on the system.

I've also checked the rsync command with the options you provided.

I've checked for the cpusystem run in the /scripts/cpbackup file and it seems if there were problems running cpusystem then it would also prevent daily backups from executing correctly. Daily backups have (nearly) always worked while copying between those directories has not.

I checked the rsync command and it does seem to work correctly. cpusystem exists and I see no problems with ldd (checking for missing libraries or similar). The rsync command may not be able to handle the cpuwatch throttling or there may be other problems that I am not seeing.

Can you provide the command that the cpbackup script might pass to cpuwatch? I am looking into that myself now.

[LinuxStandard]

I am not sure if this has been reported, but I ran into the same bug when installing mongrel and it was a pain to debug:

http://www.hawkhost.com/blog/2008/02...cpanel-part-2/

Edit: I also updated the bug in bugzilla about the PostgreSQL problem so it contains the same information we have here in the thread.

[LinuxStandard]

I haven't seen any change in the PostgreSQL backup problem. The backup issue seems to be resolved by increasing the loadthreshold value will allow the backups to complete, but this also disables the throttling control.

I've found another issue with newly created accounts and the acls.

user1...user2...user3...user4...user5...user6...user7...user8...user9...user10...user11...user12...user13...user14...user15...setfacl: acl_set_file() failed for /usr/home/user15: Invalid argument
...Done

The user15 account was just created and the enablefileprotect script is unable to set the acl properly.

A patch such as:

- system('setfacl','-kb','-m','group:nobody:x','-m','group:mail:x','-m','group:ftp:x',
+ system('setfacl','-m','group:nobody:x','-m','group:mail:x','-m','group:ftp:x',

will allow it to complete successfully.

I believe the problem is due to a problem with the wwwacct script setting them up incorrectly on account creation.

I am unable to submit tickets about servers with proper password access without customer permission and so far they have not allowed me to do that.

[cpanelkenneth]

I've tracked down the backup issue with syncing daily -> weekly/monthly

It was actually very simple. rsync is installed in /usr/local/bin. When PATH is not defined in the crontab, it uses a default path of:

/usr/bin:/bin

which of course causes the call to rsync to fail. An easy fix is to add this:

PATH=$PATH:/usr/local/bin

at the top of the crontab.


Still attempting to duplicate the PostgreSQL issue.

[LinuxStandard]

Have you been able to recreate the PostgreSQL issue and is the acl issue patched on FreeBSD?