UNIX admin wrote:
Now, if only zones were configurable through the
jumpstart mechanism. And, if only WANboot worked
with the jumpstart filesystem layout, instead of
everything having to be in a single flat directory.
Then it would be really nice, and I wouldn't have my
engineering team scrambling to try and figure out
how to do truly remote builds and writing extra
tools to do zone configuration.
I'm not sure what you mean by "if only WANboot worked with the JumpStart filesystem
layout". JumpStart does work with WANboot.
But why do you even need WANboot? This is more indicative of an architectural
problem than a technical problem. Why didn't your engineering team write a
spec for a Solaris IPSec crypto router/firewall? Then you wouldn't need
WANboot because everything would be going over the VPN.
I was part of the team that designed the WAN Boot solution (just the
advice on the crypto/security parts and how to use OpenSSL to do that).
WAN Boot was designed for a very specific customer use case that IPsec
can not solve in that customers environment. It was designed for the
case of doing the install over the untrustwrothy internet. IPsec just
wasn't an option in this case which is why WAN Boot does SSL.
My original suggestion, and that of several other security people, for
doing a cryptographically protected installation was to use NFSv3 with
RPCSEC_GSS. It need not be Kerberos we were willing at that time to
implement LIPKEY/SPKM to do this (we aren't now because we know they are
unsound and DTLS is a better solution).
It was the WAN Install project that brought us other goodness though:
pkgadd over https being one of them.
I have to say that WAN Boot to most people looks like it is missing
things but it does do what it was originally designed to do,
unfortunately that makes it not quite suitable for everyone.
--
Darren J Moffat
_______________________________________________
opensolaris-discuss mailing list
[email protected]
