[Novalug] Posting stories (explainations of things)

Peter Larsen peter@peterlarsen.org
Sat Dec 3 20:41:05 EST 2016

On 12/03/2016 05:47 PM, Gary Knott via Novalug wrote:
> So I went to novalug.com.  I saw a "link" to "knowledge";  I guess
> that's where such a story would go.  It would be a good idea to construct
> and offer good essays on various subjects.  (I'd like to
> read the story of UEFI, GPT, GRUB2, dual-booting these days, etc., for
> example.)  And a clear, careful networking story
> would be of interest too as indicated by the current
> conversation.

We've had calls for volunteers quite a few times for novalug.com - this
is definitely something that could be done, for instance to tag and
organize presentations done at our meetings, or perhaps post parts/full
emails from the mailing list in an organized manner.

> I looked at the citation
> https://access.redhat.com/documentation/en-US/Red_Hat_
> Enterprise_Linux/7/html/Networking_Guid
> <https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Networking_Guide>
> to see what Network Teaming was, and was
> completely unenlightened.

Hmmmmm - it's actually pretty lengthy, and I used it to move from "bond"
to team.  I'm curious here, are we talking about lack of conceptual
definitions or about lacking implementation information?  The reason I
ask, is that chapter 5 where this is explains is quite extensive,
starting out "simple" and ending up with some pretty advanced examples.

Btw. just to be sure, this is the section that describes what teaming is:

> - So some more complete stories would be welcome.

To be concrete, what is missing? What would make it more complete?  To
be sure, Red Hat's RHEL based manuals aren't there to teach computer
science. They work very bad for that and I don't think I would suggest
someone just using the man pages if they're attempting to learn how
networking works for instance.  The idea of bonding/teaming is HUGE and
you could get a whole class/certification just in that topic with
Cisco!  While the principles are easily explained, there are so many
different ways of designing teams/bonds that you actually have to start
looking at some very nasty details before some of the differences make
sense. And that I will grant you - the different protocols are not laid
out in a way that would make you understand those "nasty details". The
targeted reader would be someone who wants to know how to do X in RHEL,
and the manual would cover all of that.

But that said - if you just wanted to learn what teaming is and get an
idea of how to use it, the guide certainly does that job very well. 
That said, I took the word "libteam" from the introduction in the guide,
and quickly found http://libteam.org/ which has some GREAT getting
started guide (without NetworkManager). But I would point out, that
teaming/bonding isn't exactly a beginner networking topic.

> Actually, one of the main problems with man pages is the
> lack of definitions and contexts of things, and the lack of examples; both
> would greatly expand the size of a man page, but so what?
> Such material could come at the end, or even in a separate "page".

Hmmm - in my opinion that's pretty much all the guides do? They define
keywords and describes their usage. Now, if you don't know what
something is called that's where the man pages aren't going to be very
helpful. For instance, to see everything that defines/talks about
different aspects of networking do a keyword search in man:

$ apropos network
(or man -k network)

It's a rather LOOONG list.
> A challenge:  Assume you don't know much, but you're using
> a Ubuntu Linux system with a network printer that someone else setup.

Actually, this was pretty much a family member's situation the other
week. They called me saying their printer wasn't working anymore. After
arriving, I simply turned the printer on and PRESTO I had 50 pages
printed out - lots of duplicates as they had tried multiple times with
the same document. I then went on to explain how to check the printer
queue and "lecture" on turning the printer on of course :)

> You give the command: lp filea, but you forgot to turn the printer on.
> (Or if it was on, the paper jammed.)

See - this is where I think the argument fails. If you have no clue
about printing and queues, you wouldn't know "lp" or "lpr.cups".  None
outside of me in my immediate family are "computer literate" and unless
there's a "print button" or a menu with "print" in it, they wouldn't
know what to do. They don't know (or want to know) what happens when you
enter the print dialog and the printer begins. To them, it's very
advanced to change the property from portrait to landscape.

For this kind of user, I would expect them to use the GUI help. In
fedora I would hit "meta" and type "help". In the help window, I would
type "print" and lo and behold, the first option is named " Cancel,
pause or release a print job" - I kid you not :)  But it's all based on
the GUI (GNome). It doesn't cover the details of cups. And it shouldn't.

> How do you lookup (ON the sytem, not via google,) how to
> reprint this file without doing another lp command?

If you're a command line guy you should know man. "man -k -s 1 printing"
gives you cups:
cups (1)             - a standards-based, open source printing system

So you type "man cups" and you can then see lp and all the other
utilities. But really, command line is far from beginner/easy stuff for

> (maybe you recall lpq - but that doesn't solve the reprint problem  -
> and maybe you don't know about lpq)

It's all listed in the cups man page.
       cancel(1),  client.conf(7),  cupsctl(8),  cupsd(8),  lp(1), 
lpadmin(8), lpinfo(8), lpoptions(1), lpr(1), lprm(1), lpq(1), lpstat(1),
CUPS Online Help
       (http://localhost:631/help), CUPS Web Site (http://www.CUPS.org),
PWG Internet Printing Protocol Workgroup (http://www.pwg.org/ipp)

  Peter Larsen

More information about the Novalug mailing list