Re: BSD Installer as a replacement for sysinstall?

From: Brian Candler (B.Candler_at_pobox.com)
Date: 05/04/05

  • Next message: Brian Candler: "Re: boot banner project" 
    Date: Wed, 4 May 2005 09:53:41 +0100
To: Travis Poppe <tlpbsd@gmail.com>

    On Tue, May 03, 2005 at 06:32:42PM -0600, Travis Poppe wrote:
    > For quite some time I've been looking forward to seeing sysinstall go
    > and be replaced with a new system that's user interface agnostic. This
    > would allow developers to create a user interface of their choice
    > without having to muck around with the internals of the installer. It
    > seems that one of the major reasons this hasn't happened yet is simply
    > due to lack of development.
    >
    > Correct me of I'm wrong, but as far as I know, this is what BSD
    > Installer (the DragonFly team's installer) currently does.

    I'm very interested in seeing improvements to the installation and
    management utilities, but I think many of the current problems are
    architectural in the way the base system is packaged, which to me means we
    need to widen the discussion to more than just the 'installer' program.

    Jordan Hubbard wrote an article about these sorts of issues a long
    while back. It took me a while to find it, but here it is:
    http://people.freebsd.org/~jkh/package-and-install.txt
    Five years on, and it reads as if it were written yesterday.

    Also note here:
    http://docs.freebsd.org/cgi/getmsg.cgi?fetch=4914+0+archive/2001/freebsd-announce/20010916.freebsd-announce
    There are links to a binary updater project and a sysinstall replacement
    project. Both are dead as far as I can tell.

    And from about a year ago:
    http://lists.freebsd.org/pipermail/freebsd-libh/2004-May/000031.html

    I think this shows that:
    (1) we're going over old ground;
    (2) producing a solution which eliminates the weaknesses of the current
    installer is actually much more difficult than people generally think; and
    (3) this discussion probably belongs somewhere other than freebsd-current.

    The main problems that have affected me with sysinstall, mostly relating to
    binary upgrades, are listed below. Most of these would require a lot more
    radical overhaul to fix than just replacing sysinstall with something that
    has prettier buttons. That's not to say there's no value in just replacing
    sysinstall with a prettier UI, but it would leave a lot of things unsolved.
    I see little use in having an easy first-time install if upgrading to future
    versions is not equally easy. In that case, FreeBSD is likely to become
    labelled as "insecure" as it discourages people from keeping up to date.

    Now that I have tons of bandwidth on DSL and a fast CPU on my desktop I've
    moved to doing source upgrades, but there are plenty of people in the world
    who:
    (a) don't have the bandwidth or CPU
    (b) don't have the experience
    (c) conceptually prefer the idea of running the exact binaries that were
    released by the FreeBSD project [I fall into that group]
    (d) have hundreds of live servers which need to be upgraded, and don't see
    why they should have to compile the OS hundreds of times, degrading the
    service on those machines while it takes place, nor have to build the
    necessary infrastructure such as a local cvsup mirror.

    Personally, I think that addressing the needs of these groups of people is
    more important than making sysinstall prettier.

    Regards,

    Brian.

    -----------------------

    Fundamental issues with the current installation/upgrade process:

    1. You have a choice of distribution sets to install, but your choice is not
    recorded. Hence when you upgrade, you have to try to remember which
    distribution sets to upgrade. To be safe, whenever you do a binary upgrade
    to have to select "All" distribution sets.

    2. No record is made of which files were installed; when you upgrade, it
    just untars the new distribution(s) on top of the old. Any files which were
    in the original system but which should not be there on the new system, are
    left lying around. This problem especially affects source code; at the
    moment the only safe approach is to rm -rf /usr/src and reinstall it all
    from scratch (which loses your custom kernel configs unless you copy them
    first)

    3. There is no 'mergemaster' type functionality in a binary upgrade. You
    either get stuck with stale configs, or you manually compare the new configs
    to the old. Inexperienced admins are likely to be left with old and broken
    configs.

    4. Even with a source upgrade, 'mergemaster' is not clever enough to upgrade
    files which you have not touched automatically. This is especially true of
    the /etc/rc.d/* scripts. You'll see it when upgrading from 5.3 to 5-STABLE;
    you are presented with diffs for dozens of scripts, stuff in /etc/mtree and
    so on. The issue is that for each one, the user has to remember that she did
    not make any changes to that script herself, and hit 'i' to confirm the
    installation.

    I think the upgrade should be clever enough to say that if file X was not
    touched by the sysadmin, then it can be safely and automatically replaced by
    the new version of file X. To achieve this would mean keeping a database of
    checksums/hashes of files under /etc. The existing logic, which says do
    nothing if the RCS IDs are the same, should be kept as well of course.

    (Personally I don't consider /etc/rc.d/* scripts to be "configuration" data;
    I see them more like /etc/defaults/* files, which are part of the system and
    you're not supposed to touch. But a system which automatically replaces them
    only if you haven't touched them yourself would be fine for everyone. "rpm"
    has had this functionality for years)

    5. There should be a straightforward way to say 'upgrade all installed
    packages to the latest ones which are on the CD (or FTP)'. I know this is
    probably possible using portinstall with an appropriate set of options, but
    it's a basic sysadmin function which should be achievable through the
    interface.
    _______________________________________________
    freebsd-current@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-current
    To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"

  • Next message: Brian Candler: "Re: boot banner project"