Date: Thu, 12 Jul 2001 18:04:22 +0200 From: "Karsten W. Rohrbach" <karsten@rohrbach.de> To: Paul Robinson <paul@akita.co.uk> Cc: Terry Lambert <tlambert2@mindspring.com>, Bill Moran <wmoran@iowna.com>, freebsd-hackers@FreeBSD.ORG Subject: Re: getting rid of sysinstall - Was: FreeBSD Mall now BSDCentral Message-ID: <20010712180421.F91396@mail.webmonster.de> In-Reply-To: <20010712154432.N53408@jake.akitanet.co.uk>; from paul@akita.co.uk on Thu, Jul 12, 2001 at 03:44:32PM %2B0100 References: <20010706144935.A61843@xor.obsecurity.org> <3B4650D0.97F10B83@bellatlantic.net> <20010707002340.B16071@widomaker.com> <20010707004731V.jkh@osd.bsdi.com> <3B49F8D5.2C9BFA73@mindspring.com> <3B4A0124.26025FB5@iowna.com> <3B4A1423.E8E365E@mindspring.com> <20010711190247.D52923@mail.webmonster.de> <20010712154432.N53408@jake.akitanet.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
--eNMatiwYGLtwo1cJ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Paul Robinson(paul@akita.co.uk)@2001.07.12 15:44:32 +0000: > On Jul 11, "Karsten W. Rohrbach" <karsten@rohrbach.de> wrote: > =20 > > some rough and spontaneuos ideas: > > - stripped down python interpreter runs as init >=20 > Wow. If you think about it, that's quite a big departure from where FBSD = is > at the moment (or I'm missing the point). You might find a lot more people > would prefer Perl if you're going to move to this kind of model (however > it's been so long since I looked at this stuff, you might already be using > this model, and I don't know about it), but I say ignore them. ;-) perl might be superior in features at first glance but it has=20 serious deficiencies in the resulting code style, due to it's nature it not simply enables programmers to do bad things[tm] but almost enforces them to do so. > > - every class has properties which can be preloaded (=3Dunattended inst= all > > functionality from 'recorded' install session or manually generated > > setup) >=20 > Potentially a hazardous thing to offer. I can see where you're coming fro= m, > but there are basic questions that would need to be resolved before we get > into the other issues - e.g. where exactly is the install session going to > be recorded to? You can't put it on the CD you're pulling from, floppies = are > a pain in the backside, and the early (more confusing parts) are not going > to have a network available to them. Probably. Is their an existing > installer that does this, and if so how does it record sessions? what i was already thinking about was getting some minimal file access layer -- or rather object access layer -- in place. this would give us some options where to fetch stuff from and where to write it to. there's one idea which might not be as obvious to you all which i had some months ago for storing configuration data of systems after installation in a safe place (for system restoration and so on). we could multiplex the config writing to the install partitions on the disk and, simultaneously, over the network onto a configuration storage server. due to the object access abstraction it does not really matter what kind of server this is -- it could be a filesystem hierarchy, ldap, corba, you name it. i do not see a problem with giving properties to instances in an installer, storing them somewhere, and re-use them for subsequent installs on similar pieces of hardware. > > so on, perhaps stuff configuration metadata into xml and re-write it > > to the appropriate (maybe new/different) format -- oops, i said the > > x-word :-> >=20 > That's quite a big project. Just getting decent XML parsers in place at > early stages of install would be problematic IMHO. as you might have read between the lines of my comment, this would be an option, and i just mentioned it to keep the folks happy that think they could solve nearly every single one of their business problems with xml. > > - remote install dialog ui using ethernet as transport (yay!) would be > > a nice idea >=20 > No, no, no, NO! Please don't do this. Although it seems like a nice idea, > securing this would be a nightmare, because the only way this could > realistically be done is if the box decided to do a pure network boot, > brought over an install image, and then you managed to ssh in or something > at the right moment. It's too open to abuse. Again, it's a nice idea, but= I > think on a practical level it might be too complicated. we are talking about installer runtime, when booted from a cd or over the net or with a boot floppy. i would not enable this functionality withing the installer of a running system, sure. > > - making the base system consist of packages would raise the need for > > package db flagging of non-removable/mandatory pkgs >=20 > Yeah, really decent top-notch package management is something sorely miss= ing > in FBSD. I have several times sat down and thought about writing something > decent or even lift something from somewhere else, but never got around to > it. One idea I had was to trojan install so that it could track dependanc= ies > on standard 'make install' builds. Maybe even put some stuff in 'make' > itself, or 'configure'. When you think about it, it's not that bad an > idea. But then, if it was a good idea, somebody else would have done it, > except they haven't, probably for reasons I haven't thought about. yes, getting the pkg-plist as a result of the actual install invokation would make sense. >=20 > > - with that step we also could package sendmail and bind out of the base > > system ;-) hint-hint >=20 > sendmail sucks. I think this comes back to the issue of taste. First thin= g I > do after an install once I've secured it down, etc. is get sendmail off t= he > box and exim in place instead. If that was an option at install time > (sendmail was never even on the box in the first place) I would jump up a= nd > down and smile. And stuff. >=20 > > - package signature verification would also be a nice thing to have, > > especially with signature fetching over the net >=20 > Still open to abuse. To really secure that you would need to put in measu= res > to prevent man-in-the-middle attacks, etc. Good idea though. i simply do not get your point. you could do that with a http/ssl enabled fetch client that knows the server certificate -- if that one is compromised you're hosed, i know, but it improves package integrity checking and security related stuff. compared to the current mechanism this would be a lightyear leap. > <snip big ascii diagram that seems to make sense and disclaimer> it was written very spontaneously, don't expect it to cover all aspects... > Yeah, all seems to make sense. I think python might be a choice that will > raise some eyebrows, but on the whole it seems pretty cool. the choice of python for such a thing originates from a few key features: - you can strip down the interpreter to a bare minimum, keeping it small - python2 with batteries-included libs/bindings make it runtime extendable - you can distribute bytecode for all the modules which also cuts down overall size - it encourages average programmers to stick to a way good style which keeps the code readable and open to engineering - in-code documentation - debugging is much easier than with perl/tcl/... - it is not just an OO extension of a known language, thus it has no legacy stuff inside - it is fast - it is easily extendable - you can pickle() any instantiated object (serialize and put to a file) /k --=20 > Motto of the Electrical Engineer: > Working computer hardware is a lot like an erect penis: it > stays up as long as you don't fuck with it. KR433/KR11-RIPE -- WebMonster Community Founder -- nGENn GmbH Senior Techie http://www.webmonster.de/ -- ftp://ftp.webmonster.de/ -- http://www.ngenn.n= et/ karsten&rohrbach.de -- alpha&ngenn.net -- alpha&scene.org -- catch@spam.de GnuPG 0x2964BF46 2001-03-15 42F9 9FFF 50D4 2F38 DBEE DF22 3340 4F4E 2964 B= F46 Please do not remove my address from To: and Cc: fields in mailing lists. 1= 0x --eNMatiwYGLtwo1cJ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE7TcqFM0BPTilkv0YRAhmhAJ42PRjIOnNmK0YpUNv0GdbsJPrVegCfQGbT MCpSZX+VtRg46eJkFs+7ysE= =h0cy -----END PGP SIGNATURE----- --eNMatiwYGLtwo1cJ-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010712180421.F91396>