I've no idea how to debug PHP. CodeIgniter uses (to me) a fairly spaghettified layout. The business part of BMB is in /usr/clearos/apps/bmbackup/libraries/Bmbackup.php but I don't know how to output variables and I've no idea what development environment allows you to insert breakpoints. I wonder if it appears on a different bus than one named "usb"

Unfortunately there is not a maintainer for the BMB app, but if you'd like to help, great. The source code is maintained at GitLab. I believe the recommended thing to do is fork the repo, make you changes then make a merge request.

It looks like my Microserver has USB3 slots but the only USB3 device I have is a phone.

Have you seen the development stuff under the Resources menu?
I wonder if BMB will exhibit the same problem with a USB2 device plugged into a USB3 port?

Sussed it!!

Here's the fix (haven't yet picked up the GitLab code, but this works).

The problem is in _get_devices. The existing code scans the usb bus - but it assumes that the bus only contains a bus-set in single-figures - ie 1-9. In the case of (eg) the ASUS M5A99X this runs into double figures .. 2 USB3.0/2.0 mid board, 2 USB 3.0/2.0 back panel, and 14 USB 2.0/1.1 (6 mid board, 8 back panel) ... and it just so happens (at least in my setup), the back panel USB 3 that I'm using is sitting on 11-1.

The fix is to modify the REGEX definitions to look for 1 or more leading digits instead of just 1. So (eg.) 10-1 as well as 1-1

Replace (basically the regular expressions):

        

        // Find USB devices that match: %d-%d

        $entries = $this->_scan_directory(self::PATH_USB_DEVICES, '/^\d-\d$/');



        if (!empty($entries)) {

            $devices_set_1 = $this->_get_devices_helper($entries);

            foreach($devices_set_1 as $dev)

                $devices[] = $dev;

        }



        // Some USB devices are detected in a slightly different way:

        // Find USB devices that match: %d-%d.%d

        $entries2 = $this->_scan_directory(self::PATH_USB_DEVICES, '/^\d-\d\.\d$/');

        if (!empty($entries2)) {

            $devices_set_2 = $this->_get_devices_helper($entries2);

            foreach($devices_set_2 as $dev)

                $devices[] = $dev;

        }

with

        // Find USB devices that match: %d-%d

        $entries1 = $this->_scan_directory(self::PATH_USB_DEVICES, '/^\d+-\d$/');

        if (!empty($entries1)) {

            $devices_set_1 = $this->_get_devices_helper($entries1);

            foreach($devices_set_1 as $dev)

                $devices[] = $dev;

        }



        // Some USB devices are detected in a slightly different way:

        // Find USB devices that match: %d-%d.%d

        $entries2 = $this->_scan_directory(self::PATH_USB_DEVICES, '/^\d+-\d\.\d$/');

        if (!empty($entries2)) {

            $devices_set_2 = $this->_get_devices_helper($entries2);

            foreach($devices_set_2 as $dev)

                $devices[] = $dev;

        }

This is more self-consistent as it uses consistently named variable-sets.

Strange. /etc/clearos/bmbackup.d/email.conf is set up as a configuration file in the spec file, so if it has been changed when in use, upgrading the app should not overwrite it, and should create a new /etc/clearos/bmbackup.d/email.conf.rpmnew file. This is a feature of the rpm system. The file is a zero length file by default.

Can you check your syslog for the message "base - removing commands from sudoers file" and/or "app-bmbackup - uninstalling" to see if deploy/uninstall got triggered during the uninstall?

I am really not happy with deploy/uninstall removing things from the CC parameter in the sudoers file and will speak to Dave about it. There is no way BMB can know if another app needs those privileges.

Hi Richard,
Thanks for looking at it
That look like a regex. If so, your fix will fail for devices numbered 0-9. In a normal regex you'd use a + for one or more occurrences and \d means a digit. Instead of:

'/^\d\d-\d\.\d$/'

can you try:

'/^\d+-\d\.\d$/'

If "+" does not work, try escaping it, so "\+". If that does not work try a "*" instead. A * means any number of occurrences whereas a + means one or more. Note this is regex knowledge and not PHP knowledge (of which I have just about none). Another option is

'/^\d\d?-\d\.\d$/'

where a ? makes the preceding entry (the second digit) optional.

Obviously apply a similar fix to the other section.

If this works, I can push a fix to the app as I have repo commit rights.

There are definitely two different ways of detecting USB devices or two different ways the USB devices declare themselves so code was changed, perhaps last year

On the face of it, your post and my correction crossed in posting .. my fix is actually [\d]+ or \d+ .. I realised immediately after I hit 'reply'! .. the brackets are optional, but can make the definition clearer.

I've looked a bit closer; the USB devices (hubs) get listed as (eg) 11-1:1.0 (the 3.0 hub on my system)

I'd started the fork, but given we know the fix, you may as well do it.

Committed .. I think! - first time I've used Git - I've used a number of other config control systems (and been an administrator for one), but have never used Github/Gitlab

Looks like I was teaching you to suck eggs about regex's. Apologies.

I don't see any code commit in the repo. Did you fork the repo then commit to your new forked repo? If so I **think** you then need to do a merge request. I've no idea how to do that as I can commit directly.

Do you want to try a merge request or shall I patch directly? I have filed Issue #2 on your behalf.

Don't worry about it

(my backgound is military GPS (embedded), air traffic control, threat assessment/weapon assignment and the occasional Windows application for test purposes. Linux is however, relatively new ...

I forked and then did a commit - I couldn't see how to do the merge.
I suggest you make the change yourself; it's easy enough and spelt out.

I've patched it with:

[\d]+

Commit. It is now syncing to the repos which could take up to two hours. Once in the mirrors, you can test it with:

yum update app-bmbackup --enablerepo=clearos-updates-testing

Please give feedback. If it works, we may well be able to release it on Tuesday.

Odd .. it's now 05.26 and it doesn't appear to be in the 'testing' mirror ...

My bad. I forgot it was a contributor package so:

yum update app-bmbackup --enablerepo=clearos-contribs-testing

So far so good - the drive shows up.

My own version also created a backup overnight, so if this version does too (not reason to believe it won't), it should be good to go.

There may be another issue - I had an email notification in place that didn't survive the update, so there may need to be a further investigation if this disappears again when the update makes it through to the repository-proper. It's possible though, that I won't see it as I assume the version will be the same, so it may be worth putting a public post out for anyone that uses the app to warn them and report it if they see it. (I may pick it up as I have another box with the same setup, but that doesn't have as many buses). In the meantime, I'll see if I can figure out where it's stored and see if the update mechanism overwrites it.

Could have been me; I've just updated the other server and the notifications section remained unchanged. Ignore me!

I am so unhappy with the change to sudoers in the uninstall, I am pushing another build with it removed. Even the rest of the uninstall looks dodgy. The last line will remove the second to last anyway. Arguably both are under control of the rpm system and should be removed anyway, except the email.conf is a config file and will end up as an rpmsave file. I'll leave those lines for the moment as they won't harm anything.

The package should be available some time in the next two hours.

These fixes were release to the Community last night - both the USB enumeration fix and the removal of the dangerous bit of the uninstall code. I've left in the remaining bits of the uninstall code as they won't cause any damage.