[37510] 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 (Tareq Alrashid)
Wed Jun 1 10:57:59 2016

Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Tareq Alrashid <tareq@qerat.com>
In-Reply-To: <jlgziruhs6z.fsf@thriss.redhat.com>
Date: Wed, 1 Jun 2016 10:57:38 -0400
Message-Id: <AF9E4F0F-4221-4D71-823B-A76EB81229BF@qerat.com>
To: kerberos@mit.edu
Cc: Tareq Alrashid <tareq@qerat.com>
Content-Type: text/plain; charset="utf-8"
Errors-To: kerberos-bounces@mit.edu
Content-Transfer-Encoding: 8bit

Thank you one and all for the provided feedback! Greatly helpful and very much appreciated.  Tareq

> On May 13, 2016, at 11:51 AM, Robbie Harwood <rharwood@redhat.com> wrote:
> 
> 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’es come with prebuilt versions Kerberos RHEL/OS X…etc.,
>> 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’s e.g. RHEL 7 version of krb5-1.13?  RedHat
>> 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,
> --Robbie


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


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