|
|
| Applications |
| Mailing Lists |
| Miscellaneous |
| Operating Systems |
| Programming |
Re: linux-ipsec: Notes from _trying_ to install & configure Linux FreeS/WAN...
Date: Wed Nov 25 1998 - 18:07:48 EST
> So your seeing my lab notes taken in real time, somewhat raw...
No sweat. Better unnecessary information than not enough.
> JD gripes that there is no README (or INSTALL) in the download
Yeah, the site could stand some re-organizing; it's on my list.
> He was about to get 2.0.35 (after downloading 26) as thats what the
Is 36 actually officially out yet? (I've been waiting for you to say so, Hugh -- I lack time to keep polling for it or to wade through yet more mailing lists.) The docs now mention 36, but I'm reluctant to endorse it fully until I'm actually running it on at least one test system.
> Humm... JD was trying to compile on a fast machine with the right
Groan. This is not an easy problem, especially since the Linux kernel does not appear to be set up for this. doc/impl.notes now discusses the issue, but only very briefly, to say "not supported". I've made a note to myself to investigate the matter -- I *think* you could do it by just deferring the "make install"s -- but it's not simple and I'm not giving it high priority.
> His "make -n install" errored out when it got to /etc files. Bug?
Impossible to say, without more information. It works for me.
> He is trying to figure out what files are put where by install,
Please clarify this, I don't know what it's saying.
> Now he tells me that it's a SUSE system he has been building on and
"I'm sorry, sir, but your warranty is void." :-)
> He says that some of 'our' sub make files are missing 'clean'
Not true. I just looked. It's barely possible that lib/Makefile acquired it recently, although I don't think so -- I'd have to dig to be sure -- but gmp/Makefile is stock GNU software and hasn't changed in a long time.
> He tryed to to a make in freeswan while the kernel (2.0.36) was
See above comment about warranty being void. As mentioned in step 4 of INSTALL, you are supposed to compile, or at least configure, the kernel before doing *anything* else. Note that step 4 is not just a suggestion, it is phrased as a requirement. That's partly for the indicated reason (some of our stuff needs, or used to need, the results), but also partly to try to make sure that we don't get blamed for inability to build a kernel when it's not our fault.
> On the make insert the 'patch' command was not found on this
> system.
There's no graceful way around this, I'm afraid.
> This new kernel is not seeing his second ether card, whee.
As per step 5 of INSTALL, this should have been sorted out before anything was done with IPSEC. (I've now changed step 5 to be a requirement, not just a suggestion.)
> JD says this was a much easyer compile then the last time he tryed,
Unfortunately difficult -- too many dependencies -- and probably little time saving, given that compiles seem to be largely CPU-bound on systems with adequate memory.
> While looking at the comments in the sysconfig/ipsec file the word
There is no single entirely satisfactory word, alas. This really needs to be dealt with in separate documentation.
> He is getting a module load error on klips, humm...
ipsec_setup_start tries to do a module load regardless, to cover that case. Possibly it should try to be smart and figure out whether that's needed.
> He wanders into modes.html, oh goodie... He wants an intoduction to
The first thing such an introduction should probably say is "unless you have unusual requirements, you shouldn't be reading this". ipsec_manual knows how to do almost everything in that file (extruded subnets are the only exception), and since there is no theory or background in it, only recipes, it's now largely redundant.
INSTALL now points firmly to ipsec_manual and ipsec_auto, and only to them.
> The INSTALL file gives him the idea that the standard link is done
Not quite correct, but not actually a ridiculous idea (especially with older versions where Pluto still had major rough edges). I've reversed the order of steps 17 and 18 to put automatic keying first.
> He does not know what a left and a right is, and wants at least an
> intro to what they are all about. There are no comments saying what
> doc to read in the example ipsec-* files so he is lost again.
Fixed, there is now a pointer to the manual page.
> He is not using RCS to keep backups of ipsec-manual etc.
The eventual docs should presumably include a reference to something like the Nemeth book on how to be a sysadmin.
> He thinks of man pages as reference and not as things to read at
I don't know what we can do for someone who doesn't think of reading the docs that the INSTALL file specifically points him to. (It was fixed about a week ago to do that.)
> JD and I really want ***EVERY*** man page to have have an example of
> all major modes of the command, function or whatever.
That will double or triple the size of some of them, unfortunately... They could use some examples, but one of everything may be going too far.
> JD finds the paragraph describing left and right, but I note that
> that paragraph does not say that this allows for sharing of that file
> (or segments) between machines via hand cp, rdist, srdist, ssh etc.
> JD figured that out, but it was not explained well.
It's there, but yes, not explained well. Now improved some.
> He did not get the description of PFS. It needs a rewrite by the
> doc person the project hires.
It's a tricky concept to grasp if you haven't run into it before. The eventual docs need a gentle introduction to concepts like this; there really isn't room for it in a manpage.
> He goes off to edit the ipsec-auto file. He gives left the secure
> net address of his SG. Opps.
Manpage explicitly says "public-network interface".
> Once again he has set leftnexthop to my SG machine. Opps.
The phrasing of the description of the nexthop variables could probably be improved, but it's hard.
> I note that the default lifetime is in un-mentric'ed units still.
Tsk tsk, not good, fixed.
> ...Third how would one do a one way encrypted
IKE-negotiated connections are inherently bidirectional, as I recall. A facility for unidirectional connections would be feasible in ipsec_manual... but note that it would still require action on both ends. Both receiver and transmitter need to know about it; this is fundamental.
> He says that he wishes that things were very different from step
Good idea (although he's ignored step 5 of INSTALL -- which recommends getting communications going without IPSEC first -- already).
> Is it possible for ipsec_auto set up both a tunnel and a transport
> for the SG's automaticly?
Might be feasible, although it adds complications at a time when they are, perhaps, least desired.
Henry Spencer
henry@spsystems.net
(henry@zoo.toronto.edu)
Received on Wed Nov 25 18:45:20 1998This archive was generated by hypermail 2.1.8 : Wed Aug 23 2006 - 12:59:08 EDT
|
Contact Us Legal Notices Order Services Online Pantek Home Privacy Policy IT news Site Map Pantek Library |