Bug 238552 - sysutils/bacula9-server: chio-bacula greps too specifically and misses output
Summary: sysutils/bacula9-server: chio-bacula greps too specifically and misses output
Status: New
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Dan Langille
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-06-13 21:56 UTC by Adam Hammer
Modified: 2019-06-13 21:56 UTC (History)
0 users

See Also:
bugzilla: maintainer-feedback? (dvl)

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Adam Hammer 2019-06-13 21:56:34 UTC 
I've installed FreeBSD 12.0-RELEASE amd64 and bacula9 packages using `pkg install ...` (i.e. not compiled from source).  I'm beginning to work on the bacula-sd configuration file.

I think our autochanger is returning output that chio-bacula does not expect and I'm worried it will cause a problem later.  In particular, our changer says:

    $ chio -f /dev/ch0 status -S | grep drive
    drive 0: <ACCESS,FULL> source: <slot 15>

However, the chio-bacula script, in the "loaded" command, searches for:

    grep "^drive ${DRIVE}: <FULL> .*slot"

The extra "ACCESS," in our output causes the script to drop to a section that lists all empty slots (apparently under the assumption that there can be only one).  I've hacked the script to match our output.  I don't know how common this case is.

    $ chio-bacula.orig /dev/ch0 loaded 0 /dev/nsa0 0
    1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 20 25 26 27 28 29
    $ chio-bacula.hacked /dev/ch0 loaded 0 /dev/nsa0 0
    16

Also, I expected the default permissions on /dev/ch0 to match /dev/nsa0 (i.e. group read/write by operator), but I suppose that's a different report for a different time and place.