[37505] in Kerberos

home help back first fref pref prev next nref lref last post

Re: Building your own vs. deploying OS packaged version of MIT

daemon@ATHENA.MIT.EDU (Robbie Harwood)
Fri May 13 11:51:54 2016

From: Robbie Harwood <rharwood@redhat.com>
To: Tareq Alrashid <tareq@qerat.com>
In-Reply-To: <64F47B0A-6B01-43EF-89D0-3AA99DECDF15@qerat.com>
Date: Fri, 13 May 2016 11:51:32 -0400
Message-ID: <jlgziruhs6z.fsf@thriss.redhat.com>
MIME-Version: 1.0
Cc: kerberos@mit.edu
Content-Type: multipart/mixed; boundary="===============1994510097964700985=="
Errors-To: kerberos-bounces@mit.edu

--===============1994510097964700985==
Content-Type: multipart/signed; boundary="=-=-=";
	micalg=pgp-sha1; protocol="application/pgp-signature"

--=-=-=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Tareq Alrashid <tareq@qerat.com> writes:

> The new world order seem to demand some adjustments to how we do
> things nowadays with on premise and cloud service deployment.  We know
> how many OS=E2=80=99es come with prebuilt versions Kerberos RHEL/OS X=E2=
=80=A6etc.,
> and I am starting to ponder if efficiency could be optimized if we no
> longer built our own Kerberos binaries from downloaded MIT source, but
> rather just configure OS=E2=80=99s e.g. RHEL 7 version of krb5-1.13?  Red=
Hat
> does release security patches with OS patches and that can save us
> some manual labor.

With my RHEL maintainer hat on, I would recommend starting from the krb5
packaging for the distro you're using.  For our krb5 specifically, we
patch in compatibility with distro-specific features that aren't
generally useful (selinux and debuginfo support come immediately to
mind for us, or HURD support for Debian).  For faster distros, the
version of krb5 present is usually "latest release + a couple patches";
for slower distros, it'll be "older release + a few more patches", if
that makes sense.

Now, whether that's building those packages from source or just
installing the binaries is up to you.  Building from source allows you
to be ready to patch if needed, as well as verifying build integrity
(most distros consider non-reproducible builds a bug these days).  On
the other hand, just installing the binary packages is less time
consuming and gets you basically the same thing.

What it comes down to really is who you want support from.  If you want
just upstream support, then build from MIT source; if you want distro
provider support (and the potential for upstream support sometimes,
you'd of course want to use the distro packages.

Hope that helps,
=2D-Robbie

--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJXNfgGAAoJECUy+RdqlaRCo1YP/jUUFzvqLkTklPLVl+6pgxaq
cWvzRr/aRbhVJWYB90Y9lZw+GLAdn85cE/bMep8koruDSCMziEFZRifRL6q4k5fn
gsUv3t3i94N5YAuufzxTwMZp0w3Cbp9Cfas9CnuznB6ow2IX2KUTgVUqddCL/7cD
sJmjipTy6184FihILYAb7i09tAqGMXK+bTX4WYAxeEOKUWXKg0S7Ika8BNoFvOYS
J2HxPVVIRMUzoUV18t7oNTT8JMJ0xYbJv/3HuwAY0KYtwBHYOcHCwOiEUMw7/FEA
BBFIEYyNM6q+mxgpNUU/HGSBmIbFor7XWriYX1vzc4LoRGSlVni76k7EJNpgIL8A
A2cZkP4YUkfXKG27bbJJFHXEAvaLMSKZW1F5qmvLKk2QSvZztQ5qcn4ZrJfNEjvn
F9BrLgBzMfezWvPfVfe9n6UUR8YpLyCOf6oqcqVolrqQSqWHDphUHojZWOr1BuQ+
CT7UIew2ujbYCQCgK7Hz4eTEFrOYVINBBTChbbJdTXn2fVtGEMS1D+hCdPy4Zyxx
UW3ka5KyssrbmI3AcZ34GTYZVat5WhP3q9WITNZIuwu2jxjCD3DXK1jSgurgjjEl
Kin8gr2ydMn/q7ZmTNUy/VtR3HpEyVptYbQDGsjrzjU/N+1oZhRzHx5GhwpeQzfO
MgYXpd/XwIPnSsnxlSUb
=SSX1
-----END PGP SIGNATURE-----
--=-=-=--

--===============1994510097964700985==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

________________________________________________
Kerberos mailing list           Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

--===============1994510097964700985==--

home help back first fref pref prev next nref lref last post