Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 11 Sep 2002 15:33:11 +0200
From:      Roman Neuhauser <neuhauser@bellavista.cz>
To:        richard childers <fscked@pacbell.net>
Cc:        freebsd-questions@freebsd.org
Subject:   Re: Answers (& Questions) Re: OpenSSH 3.4p1 Upgrade
Message-ID:  <20020911133311.GX83171@freepuppy.bellavista.cz>
In-Reply-To: <3D7EB40F.331798E0@pacbell.net>
References:  <3D7EB40F.331798E0@pacbell.net>

next in thread | previous in thread | raw e-mail | index | archive | help
# fscked@pacbell.net / 2002-09-10 20:10:07 -0700:

    ...

> Next we upgrade OpenSSL. The current version is 0.9.6g and is available
> from both ftp.freebsd.org (../branches/-current/ports/security/openssl/)
> and from the source, at www.openbsd.org.
> 
> FreeBSD purists will insist that one uses the port. I would have said
> the same until I tried it and found that while it compiled and installed
> flawlessly, I (again) wanted the new installation to overlay the old
> installation, neatly, and it was insistent on installing the new OpenSSL
> installation in /usr/local; leaving me with the task of (manually!!)
> hunting down and eliminating the bits and pieces of the old OpenSSL
> installation, in /usr.

    you could have just done
    make install clean -DOPENSSL_OVERWRITE_BASE
    but there's this prob with --openssldir; see below.
 
> I found that make(1), invoked with '-n', was useful for determining
> where things would go *before* they were installed; and so I used this
> to study the less documented aspects of the OpenSSL port's building
> process. Using this, I determined that it was possible to accomplish a
> very close fit to the original OpenSSL installation, with the following
> set of commands:
> 
> # cd /usr/ports/security/openssl
> # find . -type f -exec rm -f {} \; -print
> # ftp ftp.freebsd.org
> 
> - log in as ftp
> 
> ftp> cd /pub/FreeBSD/branches/-current/ports/security/openssl
> ftp> bin
> ftp> bel
> ftp> prompt
> ftp> hash
> ftp> mget *
> ftp> quit
> 
> # vi Makefile
> 
> - find line where it says '#/usr/local#' and change it to '#/usr#'

    did you actually read the line? it said: replace all occurrences of
    "/usr/local" with the value of ${PREFIX} *in pkg-message*. what you
    did was thus completly benign, but also completely useless, as it
    has nothing to do with where stuff gets installed. net result was
    that instead of the message

    "Copy /usr/local/openssl/openssl.cnf.sample to
    /usr/local/openssl/openssl.cnf and edit it to fit your needs."

    you saw

    "Copy /usr/local/openssl/openssl.cnf.sample to
    /usr/local/openssl/openssl.cnf and edit it to fit your needs."

    what's the difference? there's none. you rewrote "/usr" with "/usr".
 
> # make PREFIX=/usr LOCALBASE=/usr
> # make PREFIX=/usr LOCALBASE=/usr install

    almost right (the specified LOCALBASE didn't bite you just
    because openssl has no dependancies [other than those in the base],
    and wasn't used)
 
> This creates a pretty close installation to that received with FreeBSD
> 4.6 but it still creates a /usr/local/openssl directory and puts some
> libraries in there, if I recall correctly.

    actually, it'd create /usr/openssl, and this is a real bug imo.
    OPENSSL_OVERWRITE_BASE should set --openssldir=/etc/ssl.

    but even with openssldir set to /usr/openssl this should just work
    with the openssh port, but it doesn't look like it's actually the
    case.

    if you build openssh with -DUSE_OPENSSL_BASE, it expects you to have
    /etc/ssl, which will break if you installed the openssl port with
    -DOPENSSL_OVERWRITE_BASE.

    if you build openssh without the switch, it basically assumes you
    have /usr/local/openssl. bummer. :|

> Now for two questions:

    [(1) snipped, i have no idea about that stuff]

> (2) Why do FreeBSD ports put everything in /usr/local ?

    because that's the default for ${PREFIX}

> I would think that critical things that are so important that they are
> included in the operating system release (OpenSSL, OpenSSH) would be
> important enough elements of a security infrastructure, that upgrading
> them via the ports mechanism would result in a neatly overlaid new
> installation over the old one - not a mixture of new and old
> libraries, executables, and configuration files.

    this *should* be the case with the openssl port and the
    -DOPENSSL_OVERWRITE_BASE switch, but openssh obviously can't be
    installed in /usr without hacking the port Makefile, although it
    doesn't look like it'd be too hard.
 
> In closing, I will note that I found the same problems with Linux RPMs,
> then, that I find, now, with FreeBSD ports - the author of the RPM would
> create RPMs that did not conform to the pattern used by the original
> release of Linux, requiring much additional work recreating RPMs - and
> note that it is a little disconcerting to encounter the same sort of
> weaknesses in FreeBSD's ports.
> 
> Perhaps it would be worth while to consider two ports - one
> FreeBSD-centric, and the other, /usr/local-centric, as it were -
> analogous to sunfreeware's model, where open source is compiled and
> packaged for two audiences - those whom prefer their executables in /opt
> .. and those whose tastes are somewhat more baroque.  (-:

    two ports shouldn't be needed, a switch would suffice. if it was
    implemented.

    n.b.: richard, thanks for the detailed description, but note that
    emails this long are generally too long for people to bother reading
    them. the longer the description of your problem, the less replies.
    this is a pity especially as the description usually gets longer
    with increasing complexity of the described problem. however, try
    to squeeze it into fewer lines next time: for your own good. :)

-- 
begin 666 nonexistent.vbs
FreeBSD 4.6-STABLE
10:41AM up 21 days, 16:34, 12 users, load averages: 0.04, 0.11, 0.08
end

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020911133311.GX83171>