My little Bag of Tricks: 'scli' -- SNMP Queries made very easy (Commandline Utility)

Some common daily problems you as an IT guy or gal are facing regularly....

• You are tasked to install a Linux driver for the brandnew Infotec printer your boss bought without consulting with you. Now you do not know, and he couldn't tell you: was the darn thing shipped with a PostScript module installed? Or does it understand PCL only?
• You are wondering, what the LCD display on the printer down the hall currently indicates, but you're too busy to get up and walk down?
• You are bothered by a user who phones "My big HP jammed; though I removed the paper, this red light keeps blinking all the time!"?

Use scli.

scli is the command to invoke the "SNMP Command Line Interface". A little known console utility, it is of great use to me on many occasions.

Executive summary:

scli connects to any SNMP-enabled network node and lets you interactively "browse" through the values stored in the device's SNMP database ("MIB", Management Information Base). My own personal usage is mainly for network printers (yeah, that's why I picked these examples), but scli can work with many more device types: bridges, routers, gateways, switches, computers and more. And it also has a scriptable, non-interactive mode...

Target users:

• users who want to learn what kind of (possibly sensitive) info the devices owned by them do reveal to their network neighbourhood
• users who are wielding a kind of "remote helpdesk" function (in their job, for their friends, or within their own family)
• users who are just curious about SNMP functions, and want to learn about that resource and about the network nodes in their proximity
• users who are somewhat familiar with "snmpwalk", but not familiar enough to run it without consulting the manpage every time again)

Links:

• scli project's homepage
• Screenshots
• Mailing List

Glorious details for the more curious readers:

scli does not only give you a more user friendly way than snmpwalk to run SNMP queries. It also formats the results it returns in a more user friendly way. You can run scli interactively. This gives you its own shell+prompt to run different commands. Or you can invoke it in a way that just executes one command, displays the result and returns to your standard shell (this mode is also good for scripting SNMP-related tasks you want to achieve in your network).

By default, scli returns plain ASCII text messages. You can also tell it to return XML-formatted messages by using the "–xml" parameter. XML may be very useful if you want the return to be processed by software, instead of being read by a human. Or if you want to pick it up and display the result in a fully-fledged GUI.... (you are a software developer who can do that, right? Actually, this may be a good exercise to get up to speed with Qt4 programming :-)     .)

Assuming the network node you are interested in poking at has the IP address 192.168.23.45. Start the tool by typing

  scli 192.168.23.45

SNMP-enabled devices by default use "public" as their "community name". So if scli does not see a community name on the commandline, it tries to silently use "public".

You wonder what that "community name" thingie means? It is a very weak way of authorization; in essence, a password common to all users, but with no separate user names. SNMP in version 1 will not even encrypt the community name on the wire! Yes, that's very bad security for most devices, but that's how the real life SNMP world around us currently is. (SNMP v2 and v4 are better, but not yet as common in devices used out there, though adoption is slowly gaining traction...).

If you have a node that is a bit less open, and you happen to know the used "community name", use it as an additional argument:

  scli 10.162.11.8 "community-name"

If it succeeds connecting, scli will present you its prompt:

  scli > 

(if you run scli verison 0.2.12)

  (10.162.11.8) scli > 

(if you run scli verison 0.3.1)

The utility is running in interactive mode now. Type "help" (without the quotes) to see the available commands. Type "show system info" to find out who the vendor of the device was, what the model name is, and more:

  (10.162.11.8) scli  > show system info
  Name:             Aficio 2027
  Agent:            snmp://public@10.162.11.8:161//
  Description:      RICOH Aficio 2027 1.01.5 / RICOH Network Printer C model /
                    RICOH Network Scanner C model / RICOH Network Facsimile C
                    model
  Contact:          Kurt Pfeifle
  Location:         Digital Product Development Office, Stuttgart, Infotec Europe B.V.
  Vendor:           unknown (enterprises.367)
  Services:         network transport application
  Current-Time:     2007-09-21 22:28:10 +01:00
  Agent-Boot-Time:  2007-09-03 18:43:42 +02:00
  System-Boot-Time: 2007-09-03 18:43:42 +02:00
  System-Boot-Dev:  RICOH Aficio 2027
  System-Boot-Args:
  Users:            3
  Processes:        5
  Memory:           192M
  Interfaces:       3

I'm sure you will find more interesting queries of your own quickly.

scli has a good commandline auto-completion (using the [TAB] key) built in. Type "show system [TAB] [TAB]" to get a list of subcommands other than the "info" we used. You'll see possible completions "devices info mounts processes storage". That means "show system storage" is another valid scli sub-command. Try it.

Of course, you can even try "show system" on its own [without any of the available sub commands]. That makes scli execute all of the possible subcommands, and it will return all results at once; to not overwhelm you, any too long output will automatically go piped through a pager.

The same is true for "show [TAB] [TAB]" or "show" all on its own. Run it and see all SNMP info about the device you are currently accessing.

Remember these (very few) tips to help you get up to speed with scli:

1. Your most important command to remember with scli is "show scli command [TAB] [TAB]".
2. Your most frequently used initial command with scli will probably be "show scli command tree".
3. scli ships with a very good man page; make sure to look at it at least one time.
4. scli can return its query results XML-formated, if called with the "–xml" parameter.

scli is available in Debian (stable, testing and unstable all have 0.2.12-2, while experimental has 0.3.1-0.1). If you happen to use 0.3.1, don't miss to try a scan for SNMP enabled devices in your neighbourhood. At the interactive scli command prompt (scli > -- but make sure you aren't currently connected to a specific SNMP node), type "run scli scan <a-network-IP-address-in-your-reach>". Or run scli in command mode from the shell, and type: "scli -c 'run scli scan <a-network-IP-address-in-your-reach>'" (that network address may be something like 192.168.0.0/24 or 10.162.4.0/22 or whatever your network environment dictates). This scan command is one of the new ones in 0.3; it will present you a list of all SNMP-enabled nodes that respond to the (unsafe) community name "public" (which we didn't explicitely need to type here). You may want to fix that hole…

scli was created by Prof. Jürgen Schönwälder, who also is one of the people who created the SNMP standard and wrote the RFCs describing it.

---

P.S.: Oh, you *really* wanted to know the answers to these initial questions? Ok, here we go:

Is my new Laserjet PostScript-enabled?

  kurt:~> scli 10.162.11.8 -c "show printer interpreters" | grep Description
  Description:   Automatic Language Switching
  Description:   Customized PJL
  Description:   RPCS
  Description:   PostScript
  Description:   PCL 5e Emulation
  Description:   PCL XL Emulation
  Description:   Adobe PostScript 3

So, whatever "RPCS" is — PostScript is supported as well. It will be easy to print to it from CUPS…
 

What's on the LCD display on that remote printer right now?

  kurt:~> scli 192.168.23.45 -c "show printer display"
  PRINTER LINE   TEXT
        1    1   No Paper: Tray 4

Uuhh, and you wondered why that thing didn't give any noise since 2 hours…
 

Why doesn't that red light stop flashing on that printer?

  kurt:~> scli 192.168.23.48 -c "show printer covers"
  Printer:      1
  Cover:        1
  Description:  Rear Door
  Status:       coverOpen
  
  Printer:      1
  Cover:        2
  Description:  Top Door
  Status:       coverClosed

So, that's easy. Tell your user: "Please shut that darn Rear Door again and the flashing red light will go away."

Upcoming KDE4's print capability no longer in limbo -- developer pledges "happyness will happen soon :)"

In recent weeks, some long, interesting threads on the kde-core-devel mailing list caused a far reaching discovery: the venerable KDEPrint framework (part of kdelibs) will no longer work well with KDE4, whereas it served so brilliantly since more than 6 years (it was designed and created for KDE 2.2 in 2001). KDEPrint was simply ported to Qt4 already many months ago... while it had not had any active maintenance and volunteer developer love since quite a few years already (due to lack of time on the part of the original andthe new maintainer and new commitments in their non-KDE real life). So it slowly got out of sync with the ongoing development of CUPS 1.1.x, the recent CUPS 1.2 and also the newest CUPS 1.3.

Lots of mails on the problem occurred on the list, and a few volunteers stepped forward to organize an IRC meeting, to investigate more closely and to care for new code to be written.

A core KOffice developer who was hired by Trolltech and started his new job only a few days ago could convince his new employer to get involved in the new KDE printing tasks during work-time which led to a definite plan: to transfer and embed most of what KDEPrint in KDE3 did, over into a dramatically improved and in big parts re-written QtPrinter4 (this specific name may not be technically correct) which in turn will be used by KDE4 (maybe only KDE 4.1, not yet 4.0).

Here is the basic consideration that justifies this move:

"INTRODUCTION
KDEPrint is build around a basic assumption that QPrinter generates postscript. You can see this by the fact that ghostscript is used heavily. For example to convert to pdf, but also to do 'filters'.

With the introduction of Qt4 this situation changed considerably; QPrinter is now capable of generating not only postscript, but also PDF natively. And since we want printing to work on Windows as well that adds the 'feature' that QPrinter directly talks to the printer driver and the output of that tends to be some sort of binary printer specific format.

PROBLEM
Due to the change of input most of the kdeprint will no longer be sufficient for all cases where the application doesn't generate postscript. Which is KOffice and all apps on Windows. Things like print-preview can not work anymore in those cases either and all filters stop working due to being postscript based."

After the IRC meeting discussed the specifics, a few summary emails reported about the findings.

As usual, some sceptic voice did raise its doubts, but this was quickly appeased:

"I've said it before, and I'll say it again, this stuff has my and TTs attention. Consider that I'm one of the largest backers of a printing system that will "just work". I mean, I have just spent 2 years off on my own time writing a word processor. Which is useless without proper printing. :-) Consider my motivation here.

We have a roadmap, and the manpower to keep to it, which is better then you will have seen in years in kdeprint."

So all is well?

Not quite yet. But there is hope.

However, you better prepare to suffer through some temporary regressions once/if you'll start to use KDE 4.0 for printing from early next year (then your distro will have their first KDE4 packages available). And keep the confidence that KDE 4.1 will be re-imbursing you for showing the patience with any KDE 4.0 regressions.

Keep in mind this last paragraph by one of the summary mails:

"One last thing: before people start complaining about loss of functionality, we have, so far, two coders who know next to nothing about printing, one or two more with limited time and little knowledge of the kde print codebase, a printing guru with little knowledge of the kde print codebase and maintainer who has very little time to spare on this. And a deadline in three weeks."

OpenPrinting/LinuxFoundation: "Hiring for Implementing PDF Printing Workflow"

Here is a recent announcement from the OpenPrinting workgroup, hosted by the The Linux Foundation. It didn't receive any widespread publication, AFAICS. But it deserves to:

OpenPrinting/LinuxFoundation: "We are Hiring Students/Interns for Implementing the PDF Printing Workflow"

Posted by: Till Kamppeter

Date: August 29, 2007 09:08AM

One of the decisions which was made on the OSDL Printing Summit in Atlanta last year and widely accepted by all participants was to switch the standard print job transfer format from PostScript to PDF. This format has many important advantages, especially

• PDF is the common platform-independent web format for printable documents
• Portable
• Easy post-processing (N-up, booklets, scaling, ...)
• Easy Color management support
• Easy High color depth support (> 8bit/channel)
• Easy Transparency support
• Smaller files
• Linux workflow gets closer to Mac OS X

To turn this into reality work is needed in many components of the printing infrastructure. The japanese team of the OpenPrinting work group has already the needed CUPS filters in their Subversion repositories.

What is still missing is to make the universal print filter foomatic-rip (most printer drivers are integrated into the printing system with this filter) handling PDF input and to make the built-in printer drivers of Ghostscript also working with other renderers than Ghostscript, like XPDF/Poppler for example.

These two projects are now open for students or interns. If you like to take one of these challenges, go to the detailed project description and/or contact Till Kamppeter (till.kamppeter at gmail.com).

Till

OpenPrinting Manager
OpenPrinting (linuxprinting.org) Forum and web site administrator

You can also look at a more detailed project description.

Printing Secrets revealed: Grok some Basics about 'PPDs'... and quickly snatch them from a remote CUPS Server

PostScript printers traditionally have all their model specific job options represented in an ASCII file, the "PostScript Printer Description" (PPD). Each printjob option includes three things:

• how the specific option is named internally
• how this option is "translated" so a human computer user can make sense of it
• which option matching code to be injected (in PostScript, PJL or other format) into the printfile to make the printer use this print feature

Adobe developed, specified and published the exact format of PPD files, starting more than 20 years ago. Ever since, PPD files have been used on Apple Macs and Windows PCs (and a few other platforms) to describe and drive PostScript printers.

CUPS extended the concept of PPD files to non-PostScript printers as well (because CUPS uses a computer-based PostScript interpreter, and it can direct each job through a conversion filter to create a jobfile with a format feasible for the target printer).

A CUPS printer named foobaz has its own model-specific print options represented in the file foobaz.ppd that lives in /etc/cups/ppd/. You can of course look at it in an editor.

You may know already, that there is a web page listing of all installed printers on a CUPS server: http://localhost:631/printers/. Every printer on a CUPS server even has its own individual web page. For printer "foobaz", it is at http://localhost:631/printers/foobaz. If you use CUPS, you probably have seen it fairly often already. (Or maybe not... if you are a Mac user: Go try it.)

Once you successfully share a printer (and hence turn your computer a print server for other workstations), this web page is accessible from other computers in your neighbourhood (maybe even over the Internet, if you are not careful!). Just replace the 'localhost' part of above URL with the IP address or the hostname of your CUPS computer.

Now here is the first little secret of today: use the same URL as above, but add the extension string '.ppd' to the printers's web page URL. Make it http://localhost:631/printers/foobaz.ppd. Point your browser to it. Sishshsh!, opens up the PPD in its full ASCII glory for you to look at.

If a printer is shared, its PPD is shared as well. You can look at it from a remote computer, with any browser: http://remote.cups.server:631/printers/foobaz.ppd. This sharing of the PPD is the secret sauce behind CUPS' amazing capability where it allows each remote CUPS client to access and use every single one of a printdriver's job options without ever needing to install that driver locally, on each client!

Windows admins may be familiar with 'Point and Print' installations of shared printers. These are a fairly comfortable way to get a print client install a printer and its driver to use what they call a 'network printer' in the Microsoft empire (that is, a printer with its printqueue hooked to a Windows print server). But still, there is a need to initially 'Point and Print' on each client, for each printer, before that network printer can be used.

CUPS trumps that convenience: no need for 'Point and Print'. Just share a printer from the print server. Provided your Linux (and Unix, and *BSD and Mac OS X...) print clients are correctly set up for this function, they don't need to do anything else: their GUI printing dialogs (like kprinter, xpp, gtklp, ...) will just display all printers as they are shared.

And more, these dialogs will display all available job options, including the printer specific ones, without ever needing to install a local queue, a local driver, or going through the 'Point and Print' procedure. Install a new shared printer on the central CUPS server, wait a few seconds ... and Bang!, all clients will 'see' and be able to use that printer with all its capabilities!

Now assume you know a CUPS server somewhere on the net (local, or on the other side of the globe), that shares its printer named infotec_isc_2525 with you. Then you can put our second little secret of today to some use: snatch that printer's PPD for you. This command:

  wget http://cupsserver.remote:631/printers/infotec_isc_2525.ppd

will fetch the PPD file for you.

Assume, your boss told you to migrate the existing CUPS 1.1.23 server to a 1.3.0 system, and place it on a new, more powerfull hardware. You can't simply copy the old configuration files over, because of some format changes. And how do you get all the PPDs from "there" to "here"? Here are a few initial tips. First, get a list of all existing queues (with their current status) from the remote server:

  lpstat -h cupsserver.remote -p \
          | tee remote.queuenames.full.list

Next, get the info about each queue's method to connect to its actual print device:

  lpstat -h cupsserver.remote -v \
          | tee remote.backends.list \
          | awk '{print $3}' \
          | sed 's#:$##' \
          | tee queuenames.list

Last, fetch each of the available PPDs and store them in a local repository:

  for i in $(cat queuenames.list); do
      wget http://cupsserver.remote:631/printers/${i}.ppd
  done

You now only need to figure how to use this information harvest (and the PPD files) to re-install all the queues locally. And if your old CUPS server hosted 100 queues or more, you really don't want to re-install them all manually. How to automate this, by creating a little script is left as an exercise to the readers....

Printing Secrets Revealed: How to set Custom Page Sizes with CUPS Printjobs

So you have one of those sophisticated office printer models with adjustable guides that allow you to use any weird media size (with some sensible min/max value for width and height)? And you don't know how to tell CUPS to use that size when printing? (Ah... you don't have such a printer, and you are about to skip this article? Wait. The content may still be useful to you. See the last paragraph.)

Easy. Try one of these commands then:

 lp -d printername -o PageSize=Custom.4x6in \
             -o fitplot /path/to/PDF ;      # inches

lp -d printername -o PageSize=Custom.4x8cm \
              -o fitplot /path/to/PDF ;      # cm

lp -d printername -o PageSize=Custom.440x310 \
              -o fitplot /path/to/PDF ;      # points (1/72 of an inch)

These assume a few things:

• you indeed have a printer named "printername" (how weird is this?!)
  
• you want to print a PDF file
  
• you want to make the printout fit onto the medium ("fitplot")
  

The "fit onto the medium" will happen automatically. CUPS will scale the page image up or down to the size that makes you PDF fit onto the sheet. It will also automatically rotate a page, if that makes it fit better into the available space.

This works also if you print other file types. And it even allows you to use fractions of an inch or cm units:

 lp -d printername -o PageSize=Custom.5.5x6.9in \
               /path/to/ASCII.txt ;

lp -d printername -o PageSize=Custom.5x8.2cm \
              -o fitplot /path/to/Photo.jpg ;

lp -d printername -o PageSize=Custom.440x310 \
              -o fitplot /path/to/Scanned.tif ;

Supported image formats for CUPS printing are all of the commonly know, plus some more obscure ones: JPEG, TIFF (but not multipage TIFF!), PNG, GIF, PNM, PPM, SUN Raster, .... When the CUPS scheduler receives a printfile, it applies its "auto-typing" mechanism against it to find out its file format ("MIME type").

The received job format is then converted by an appropriate filter into a different one to make it better suited for further processing. (Overall, there may not only be one filter, but a whole chain of different ones which form a pipeline until the job is in a format that can be consumed by the target printer.)

With image and graphic formats, the first filter in the chain typically is "imagetops" or "imagetoraster". Both these filters understand the "fitplot" parameter that you gave on the above commandline, and act accordingly while converting their input into PS (PostScript) or CUPS Raster format.

You did notice that the "fitplot" parameter was skipped in the printing of the text, yes? Well, it does not make much sense here. Instead, to customize the size of your printed text you can specify "cpi" (characters per inch) and "lpi", as well as top, bottom, left and/or right margins:

 lp -d printername \
-o PageSize=Custom.10x12cm /path/to/ASCII.txt \
-o page-top=33 \
-o page-bottom=44 \
-o page-left=60 \
-o page-right=80 \
-o lpi=5.53 \
-o cpi=11.3 \
/var/log/cups/page_log 

So you think this "custom page size" tip isn't of much use for you? Hold on. You can use it to "print to file" and generate PostScript pages that do have appropriate BoundingBoxes for leaflets /brochures you are going to hand to a commercial printshop for transfer onto paper. Or you can further process said PostScript into a polished PDF presentation that fits exactly on the wide screen of your shiny new notebook. (You don't know how to "print to file"? You don't know how to convert a PostScript to PDF? I'll deal with questions like these in one of the next blog entries. So come back, if you are interested.) Tell me your own use case for the CUPS custom page size print option...

Okidoki, First Post Now For Testing...

....which may later be deleted again.

This blog will collect whatever I encounter in my day to day work. Problems, their solutions, open questions, tips and tricks I want to share. Mainly about printing, but not strictly so. If I feel like relieving myself by uttering a solid rant about world politics or privatelife, I'll do so too.