[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [SAGE] Unix training materials recommendations?




Long ago, when I was running my ISP, we did not have slip/ppp/pop
and we provided just unix services.

In order to get people able to use it, we ended up re-using an 
introductory unix booklet and reworking it for our environment.

It ended up being called File 901, and we distributed many many copies.
And we ran classes on it. 

We found that nothing that was out there really worked for us
becuase there were somethings that were important to us, and other
things we did not care about.

So the effort of putting together the booklet turned out to be 
a good project. It helped clarify many things.

There are some people who will never understand somethings about unix,
but who will be quite productive. And trying to teach them Unix from
a techy point of view is worthless. There are others who will 
gain great insight and power from learning some key unix ideas.

Editing with emacs/vi and regular expressions is one of the things
that some of the secretaries just went gah gah over. Others choked
on it though.

So given that you have different audiences, I would recommend different
booklets, with different work examples based on the audience.




Phil Pennock <phil.pennock@globnix.org> writes:

 % On 2004-05-07 at 06:50 -0700, John Sechrest wrote:
 % > Can you outline what you want to train them on?
 % 
 % Sure.  Should have included more info in the original mail rather than
 % maximum complexity stuff, sorry.  I'll veer the other way this time.
 % Please note that the divisions I have here are very _very_ rough and
 % subject to change following sage (*ducks*) advice.
 % 
 % There's several different levels.  Everyone is assumed to be comfortable
 % working with word-processors and email.  We're an ISP, so all our staff
 % tend to have some degree of basic clue (no matter how much I might
 % sometimes despair).  And people who need special training, such as
 % Sales, already get that sort of training.
 % 
 % This would be for tutorial sessions for staff who choose; volunteers
 % only.  Many of our staff feel, rightly in my opinion, that they could do
 % their jobs better if they had a deeper understanding of issues.  For
 % instance, Support might not need Unix skills and only enough Networking
 % for helping customers, but they'd certainly benefit from more Networking
 % theory.  That's not my dept -- I'm only a Junior at the network stuff.
 % 
 % Think of it as professional career development stuff on a semi-formal
 % or informal basis; tutorials and help.  Get the basic information out,
 % be available for more questions, etc etc.  We tend to like educating
 % internally and often recruiting internally, but even Marketing people
 % are wanting to know more about Unix generally.
 % 
 % One of my beliefs is that people work best when they understand not only
 % the layer they deal with, but at least one layer deeper too.
 % 
 % 
 % So, at the basic level there'd be "directories, what they are, how to
 % use them sensibly; this is how we browse around with a graphical viewer,
 % see this stuff.  See this shell, see how we do the same things.
 % Man-pages exist, here's one for ls(1).  The GUI is nice and easy, but
 % has to be programmed to allow you to do more; if you move beyond the GUI,
 % here's the shell; in some ways it's harder, but it lets you do harder
 % things, more easily.  You don't have check-boxes where it's obvious what
 % the options are, you need to use the man-pages.  You have a current
 % directory, here's how pathnames work.  If a command generates a lot of
 % output, do this (| less) and if you want to understand how that works,
 % tutorial 102 is on date X".  Slides to go with a talk, but a smallish
 % audience so much more interactive.  Notes and crib-sheets to go away with.
 % Hold it near the end of the work day and retire to cafe for beers/alcohol
 % and any further stuff (collecting the gripes about how bad my stuff is?)
 % 
 % There'd be information in advance describing what's covered, so people
 % could skip that one if they already know it.  Many of our staff can at
 % least do things like ls(1) on systems, even though they have to be taken
 % carefully through generating their SSH keys (F-Secure or PuTTY).  A lot
 % of staff have Unix logons but use a local "menu" program for all work.
 % 
 % A middle level would cover processes, pipelines at least enough to
 % explain the "| less" stuff (and "| lpr"), some redirection, etc.
 % Basic filesystem layout, where /home/ is, what /etc/ is for, stuff
 % with $PATH.  What the kernel is.  Anything else which seems appropriate.
 % It's been too many years since I read an introductory Unix text-book,
 % but I'd re-read some of those to get more hints about structuring how
 % things are introduced, if I need to work more from scratch.
 % 
 % Then there'd be a Security Basics tutorial explaining what public-key
 % crypto can do, using the ubiquitous SSH keys to explain public/private,
 % and cover PGP stuff too; The GnuPG Privacy Handbook is very decent and
 % would probably form most of the printed notes.  ;-)  Probably mention
 % HTTPS and webserver certificates as another example -- most people here
 % would understand that browser padlocks appear when the web-server has
 % a certificate.  Explain our SSH and CryptoCard usage, note why passwords
 % are bad, cover the cracking utilities, get the Abuse Dept to explain
 % how many headaches they have from customers allowing password-auth
 % mail-relay without knowing they do (MS Exchange) and how the spammers
 % run dictionary attacks.  That's the sort of example which shows that
 % this isn't theoretical stuff with no real-world relevance, but instead
 % that there are immediate monetary consequences.
 % 
 % There's been a vague "it would be good" thing for some time, but none of
 % the people supposed to organise stuff have done much.  A couple of weeks
 % ago, whilst ensuring that our Developers all had PGP keys and that I had
 % the correct ones and they knew why they had to be careful about signing
 % stuff, I found one who'd signed every key he was given, with Ultimate
 % trust.  I really don't want to find that again.  Since all our RIPE
 % database updates need to be PGP-signed, our Provisioning people would do
 % well to understand more about PGP, instead of just "run this
 % pre-packaged command".
 % 
 % Does this describe the sort of thing I'm thinking of?
 % 
 % As I said, the divisions and topics here are very rough, but are
 % guidelines rather than boundaries.
 % 
 % If I can get some structured teaching stuff to work from, that'd be great.
 % If not, then I'll start from scratch and make Rob very happy by releasing
 % them as SAGE member benefits (something like, not for public retrieval
 % but SAGE members can use it, and redistribute the printed notes in their
 % organisation) -- I already have my boss's approval for that.  I'd like
 % to be constructively lazy though.  (Sorry Rob.)
 % 
 % So, any pointers?
 % 
 % Ta muchly,
 % -Phil

-----
John Sechrest          .         Helping people use
                        .           computers and the Internet
                          .            more effectively
                             .                      
                                 .       Internet: sechrest@peak.org
                                      .   
                                              . http://www.peak.org/~sechrest