RE: HOWTOs for the new newbies [was: procmail and kmail]

["Paul Sims" <nospam [at] lombard.co.uk>]

I've just written a mini mail-howto aimed at the newbie. comments please:


My aim is to to get this onto the Sheflug site if acceptable. It also seems 
a very useful subject to cover at the next ShefLUG meet - I don't mind 
demonstrating if it's felt to be useful : )

Suggestions for other topics are always welcome - saves staring at the wall 
or playing ksokoban all day !
-----Original Message-----
From:	Stephen J. Turnbull [SMTP:turnbull [at] sk.tsukuba.ac.jp]
Sent:	Monday, February 21, 2000 4:35 AM
To:	sheflug@vuw.ac.nz
Subject:	HOWTOs for the new newbies [was: procmail and kmail]

Despite my disagreements with Martin, I think he's formulated the
issue and described the need very well.

>>>>> "Martin" == Martin P Holland <m.holland [at] noether.freeserve.co.uk> 
writes:

    Martin> On Fri, 18 Feb 2000, Stephen J. Turnbull wrote:

    >> My advice is to ditch the K environment,

    Martin> What on earth are you ranting about Stephen?  ;-) What has
    Martin> a desktop enviroment got to do with setting up
    Martin> sendmail/fetchmail properly? Nothing.

Oh, I'm confused.  So all those k* utilities really have nothing to do
with their Internet access and mail systems?

That's what I thought, but people seem to keep expecting them to set
up their PPP and mail systems for them.  :-)

    Martin> BTW, I wrote some simple (I think) notes at
    Martin> http://www.noether.freeserve.co.uk on setting up fetchmail
    Martin> and sendmail for my ISP that might help people who are
    Martin> struggling. (If the emails I get are any guide it has
    Martin> helped quite few people.)

This is exactly what I meant to suggest by "get rid of the X
environment".  I meant get rid of the Fisher-Price busy-box config
tools.  Even MSFT doesn't do them very well, and Heaven knows they
spend enough money on them.

The problem is that understanding both the syntax of the config files
and the limitations of the config tools is not easy, and not worth it
IMHO.  If the tools work, good.  Use them and forget about it---Linux
will do the rest.  But if the tools don't work, you are best advised
to start from the beginning.

    Martin> Def: A Home User has a linux box at home (possibly not
    Martin> even on a LAN) which is periodically connected by dial-up
    Martin> to the internet and is being used as a desktop workstation
    Martin> as a drop-in replacement for win98/98.

I have to quarrel with the "drop-in" description.  Nobody in their
right mind would use Linux as a "drop-in" replacement for Win98.  What
Win98 does acceptably well, it does far better than Linux can.  The
only advantage Linux has in competing with Win98 on its home ground is
that the applications, where available at all, are often far cheaper.

I don't think that adding /usr/doc/HAND-HOLDING/ to the doc tree would
keep these users in the Linux fold, no matter how well they were
written.  So home users really have to be something else.

Sure, they expect Linux networking to be as easy to configure as
Windows networking.  But if that's all, it ought to be possible to do
it in a script (maybe with a Fisher-Price interface).  What Windows
does for configuration is not very complex.

What we really need here is a list of common functionality that users
(have a right to) expect that Linux will provide a "dumb Windows
compatibility configuration" for.  PPP.  Somewhat more powerful mail
service shouldn't be hard.  ISDN.  XFree86 still comes out of the box
with 8bpp (256 colors) standard, so you have to configure TrueColor
specifically.  (Dunno about Britain, but in the US and Japan all home
users have true color.)  XF86_SVGA makes extremely conservative
assumptions about what is needed to run at TrueColor depth.  Printing.
(This is a crime AFAIK; I'm always using multiple "decapitated-edge"
versions of Ghostscript and typically a witch's-brew of TrueType
libraries and funky filters, so I haven't let anything like
"magicfilter" near my printer in over 5 years.  But what I hear is
distressing.)  WWW browser preloaded with Linux links.  (Netscape will
do, Mozilla ain't up to it yet.  But none of them is great in a
non-Latin-1 environment yet.)  Desktop themes (window manager-
independent!  Debian is working on this but I haven't tried it yet, I
think the Gnome people are collaborating with them?).

But the DWCC ought to be flexibly extensible, and not break when you
add bells and whistles that Windows couldn't handle (filtering and
caching WWW proxies, servers, procmail, etc.).

And then there is the "apps" problem.  Menu-driven WYSIWYG word
processor (AbiWord looks good, though), spreadsheet (Gnumeric is
getting good reviews but is clearly still not ready for prime time),
presentation software (MagicPoint is very cool but not WYSIWYG, and
some of the best effects like swallowing other X apps and generating
dynamic graphics inside the presentation are still buggy; I dunno
about the K thingy).  Too many media players (xv, imagemagick, rsound,
esound, nas, Real*, xmms, etc, etc).

That's a bit out of bounds, the relation to configuration that I see
is that those FAQs are often closely related to (ie, same poster) the
config FAQs, and second, maybe rather than writing HOWTOs for the "new
newbie", one might make more contribution by working on docs for the
apps.

    Martin> In fact I would guess that the majority of linux users are
    Martin> Home Users in this sense. (This is all presumption on my
    Martin> part of course, any one know any hard information?)

How would you get it?  But I think you are on safe ground in assuming
this is a substantial demand.

    Martin> There is a distincy lack in the HOWTOs of concise
    Martin> infromation _targeted_ at these particular users.

Of course.  That concise information is all in k* scripts already,
where it belongs.  :-)

But back to your point.  Who's going to write those HOWTOs?  You don't
want newbies writing HOWTOs ... where do you find authors with
expertise who sympathize with newbies who don't want to be experts?

I, for example, am working on a couple of HOWTOs related to
internationalization.  But surely you don't expect me to hose my book
royalties by targeting my HOWTO at people I don't know, will never
meet as peers, and who will never contribute anything except revenue
to any projects I care deeply about?

Sure, I'm an arrogant arse; that was pointed out by my 10th-grade
English teacher.  But I'm also willing to answer questions on Sheflug,
and a couple of other LUGs, because I know the people here, because
some of you have answered my questions, and because I like the company
anyway, even if I can't smell the curry from over here.  What I'm not
willing to do is take those specific answers and turn them into a FAQ,
let alone a HOWTO, for people I don't know and whose main concerns
often leave me completely cold.  I'm mostly concerned about admin
types, and working on free stuff for them doesn't leave me a lot of
free time.

I don't think I'm untypical of HOWTO authors in those aspects.

    Martin> The info is all there of course, but you have to read
    Martin> carefully, interpret, have some experience (certainly an
    Martin> unreasonable expectation for new users).

(1) I didn't find it so when I was a newbie.

(2) It's not clear that having high expectations of "newbies" when
they are using an industrial strength OS is unreasonable, any more
than having higher expectations for lorry drivers than for bicyclists
is unreasonable.

Be that as it may, the "new newbie" does not have the background, as
you say, and there is a demand to be addressed here.

    Martin> Since (I claim) Home Users are in the majority this means
    Martin> that there is a gap.

Which I suggest is probably best bridged with pounds (sterling).

Certainly, there will be a few dedicated people like yourself writing
HOWTOs for the new newbie.  But are you sure that your effort wouldn't
be better put into putting that knowledge into a script that only Perl
would ever read?  The Home Users, as you describe them, don't _want_
to read HOWTOs.  They want things to "just work".

So they should buy commercial distributions with hand-holding support
contracts.

    Martin> I think that there is need for a dial-up-user-HOWTO that
    Martin> addresses issues like sendmail, fetchmail, named, ipchains
    Martin> concisely based on the needs in this particuar case (or
    Martin> perhaps a sequence of mini-HOWTOs).

But how do you do this "concisely"?  The parts that can be addressed
concisely are already in the main addressed concisely:  in Perl and
Python.  The fact that the new newbie can't read those doesn't matter
if they work, and it probably wouldn't matter if they didn't.

This is not a jab at you; I haven't read your page yet.  This is a
statement of personal experience.  I've participated in writing a
whole book on installing a Japanese environment on Linux at this
level.  I'm not proud of it, but I don't see how we could have done
better.  My coauthors are proud of the fact that the bugs in other
books' procedures don't arise on their systems using ours, and we do
provide a lot of technical background that other books do not.  We
make some attempt to bridge the gap between the cookbook aspect and
the structural concepts.  But (IMO) it doesn't work very well.  There
are plenty of potential bugs in our procedures, and we don't (can't,
AFAICT, I've been worrying about this from Day One) provide the means
to debug them to the level of user we're targeting.

    Martin> I would welcome any suggestions to make things more
    Martin> distro-independent.

Well, we went to the trouble of installing various base distributions
(Red Hat, Debian, and Turbolinux are the popular ones in Japan---this
was one reason for the coauthor organization, it meant we could get
more coverage and better depth by having people run the system as
their day-to-day system), and then added several "Japanization"
distributions on top of them.  We also installed 2 native Japanese
distributions (based on Red Hat and Debian respectively).

I wouldn't ask anybody to do that kind of scutwork if they weren't
getting paid for it.  Not having done it once myself.  But I think
that's the way to do it....



--
University of Tsukuba                Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences       Tel/fax: +81 (298) 53-5091
_________________  _________________  _________________  _________________
What are those straight lines for?  "XEmacs rules."
---------------------------------------------------------------------
Sheffield Linux User's Group - http://www.sheflug.co.uk
To unsubscribe from this list send mail to
- <sheflug-request [at] vuw.ac.nz> - with the word
 "unsubscribe" in the body of the message.

  GNU the choice of a complete generation.

"WorldSecure Server <lombard.co.uk>" made the following
 annotations on 02/21/00 09:46:15
------------------------------------------------------------------------------
The opinions expressed within this email represent those of the 
individual and not necessarily those of Lombard. 

The contents of this Email may be privileged and are confidential. It may not be disclosed to or used by anyone other than the addressee(s), nor copied in any way. If received in error, please advise the sender, then delete from your system.

Should you wish to use Email as a mode of communication, Lombard are unable to guarantee the security of Email content outside of our own computer systems.  



 

==============================================================================
I have seen a few discussions recently on getting email working with Linux. 
In actual fact, this is remarkably easy once you realise the linux mail concept
breaks mail handling into discreet pacakges - 
(a) the client end, a mail reader such as pine, mutt, kmail, xfmail 
(b) mail transfer agent, such as sendmail,which sends your mail via smtp to your isp.
(c) mail delivery agent, such as fetchmail, which collects and downloads
mail via pop3, imap, ldap etc, to your local machine.

Here it gets interesting - once on your machine, mail can be sorted
into individual mailboxes using procmail for example, or sendmail can
be used to drop the mail into a local mailbox. 

Step 1:	Get internet connection sorted - use wvdial, run wvdialconfig and plug
your details into /etc/wvdial.conf.

Step 2:	Make sure fetchmail & sendmail are installed, then configure
fetchmail. In an xterm type "fetchmailconf" . Choose Novice configuration.
First, specify the name of your isp's mail server (eg, mail.someisp.co.uk, 
pop.someisp.co.uk). When you hit ENTER this will appear in the box below - 
highlight the entry & hit the EDIT button. Add your user name, highlight
and again press EDIT. Add your password. You can now add some local names
or aliases for the user, so you can collect mail for all the users on your
system. Save the changes & exit - we'll test the config in a moment.

Step 3: Test fetchmail - go online and type "fetchmail -v" which will report
each step of the mail collection process. If all goes well, proceed to set
up sendmail, otherwise, check your user name, password & server details in your 
$HOME/.fetchmailrc file. (example below)

poll mail.myisp.co.uk with proto POP3
       user "username" there with password "mypassword" is linuxusername here
options keep fetchall

The "options" section can be deleted once fetchmail performs as you want
as it simply downloads all the old mail as well as new, and keeps the existing
mail on the server, so if all does not go well you still have your mail left
undamaged.

Step 4 : Setup sendmail. Happy news - in most cases, home users with  dialup
internet access should find sendmail runs "out of the box" except for setting 
SmartHost to your isp's smtp server. Change this in /etc/sendmail.cf or in 
your distribution's admin utility. To check, start up pine and compose a 
mail then send it. If sendmail is running, this mail is queued 
(locations vary depending on which linux you are running) until there
is an internet connection. With your internet connection up, type "sendmail
-q" and check /var/log/mail - it should say that the mail was sent ok.
There is very little tweaking needed in sendmail, perhaps the only one of
value is masqerading - you can tell sendmail to make all mail appear to come
from one user. Usually sendmail will put in the "from" line
<username> [at] <hostname>. You can change this to, say,
"user@mydomain.co.uk".  Just make sure the details here are not rejected by
yopur isp's mail server as an invalid relay - for example, Freenetname will
reject any domain name except freenetname.co.uk or a domain obtained through
them.  

That's it. Just make sure the system starts sendmail on boot, so there is an
active smtp process - this can be set up in YaST in SuSE or Setup in RH.

Now for your mail reader. Pine is my favourite - menu driven, fast, easy to
live with. Again, with most distributions it should work with no configuration
at all, since it uses sane defaults.

kmail and xfmail are also good, although you have to supply all the details.
If using sendmail locally, set the smtp server as localhost, unless you want to
connect direct to your isp.

In use, since sendmail is normally started as daemon, simply write your mail &
send. When you connect to the internet, type "fetchmail" to download your mail 
from your isp Type "sendmail -q" and your queued mail is sent to your isp for 
forwarding plus the downloaded mail is made ready to collect from your local
mailbox. Read with the client of your choosing.

For more automation, especially if you spend a long time online, set up 
fetchmail to download every 30 mins (option in fetchmailconf) and sendmail
to send every 30 mins (sendmail -q30m) in your ip-up script or evem a manually 
executed script.

Happy mailing!

The Wulfster.