Bug 996671 - RFE: Support printing of CUPS back end discovery string
Summary: RFE: Support printing of CUPS back end discovery string
Alias: None
Product: Fedora
Classification: Fedora
Component: hplip   
(Show other bugs)
Version: 19
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Tim Waugh
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2013-08-13 16:27 UTC by David Woodhouse
Modified: 2013-08-14 12:11 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-08-14 12:11:15 UTC
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Launchpad 1212223 None None None Never

Description David Woodhouse 2013-08-13 16:27:30 UTC
We have a corporate printer database, and a simple script which will query it and "discover" the printers in the office where the user is based.

To generate the CUPS uri, we can use 'hp-makeuri -c'. This queries the printer by SNMP to obtain the IEEE1284 ident string, and creates a URI appropriately.

We then *want* the IEEE1284 ident string, since that needs to be in the output that CUPS sees too (and GNOME control-center fails if it isn't). So we would need to fetch it from each printer for a *second* time, since the information isn't available from hp-makeuri (or the backend python libraries that it calls).

This doubles the time it takes to query each printer. And time is a problem, since there is a timeout on discovery (cf. bug 996664).

It would be useful if hp-makeuri would give me the information I need in a single invocation.

As it is, I've ditched hp-makeuri completely and I'm doing it myself. But this is horrid. Don't make me do this :)

(And yes, it sucks that I have to give a dotted-quad IP address instead of the hostname, and I have no idea how it works with IPv6).

printers = db.printer_query(location)

for p in printers:
        ip = socket.gethostbyname(p['hostname'])

        # The hp-makeuri tool will query the IEEE1284 ident string to
        # generate the URI, but there's no way to get it to *tell* us
        # what the ident string was, and we need it too. So rather than
        # doubling the latency by fetching it again for ourselves, we
        # just do it once and generate the URI for ourselves. It isn't
        # particularly complex.
        var = netsnmp.Varbind('.')
        devid = netsnmp.snmpget(var, DestHost=ip, Version=1)[0]
        idmodel = None
        iddesc = None
        for idpart in devid.split(';'):
            if idpart.startswith('MDL:'):
                idmodel = idpart[4:]
            elif idpart.startswith('MODEL:'):
                idmodel = idpart[6:]
            elif idpart.startswith('DES:'):
                iddesc = idpart[4:]
            elif idpart.startswith('DESCRIPTION:'):
                iddesc = idpart[12:]

        if idmodel is None:

        # This check is never going to fail, since the SNMP query is HP-specific
        # in the first place. But just in case we fix that...
        if idmodel.startswith("HP") or idmodel.startswith("hp"):
            # This matches generalize_model() in hpmud.c
            uri='hp:/net/' + re.sub('_+$', '', re.sub('[/ ]+', '_', idmodel))+ '?ip=' + ip
            uri='socket://%s:9100' % p['hostname']
        if iddesc is None:
            iddesc = idmodel

        location = "%s %s-%s" % ( p['sitecity'], p['building'], p['floor'] )
        if p['pole'] != "n/a":
            location = location + " (" + p['pole'] + ")"
        devinfo = iddesc + " (" + location + ")"

        #    device-class device-uri "device-make-and-model" "device-info" "device-id" "device-location"
        print "%s %s \"%s\" \"%s\" \"%s\" \"%s\"" % (
            backend, uri, iddesc, devinfo, devid, location )

    except Exception, e:
        print str(e)

Comment 1 Tim Waugh 2013-08-14 12:11:15 UTC
Reported upstream.

Note You need to log in before you can comment on or make changes to this bug.