Bug#775277: should we split krb5-kpropd into a separate package?

[Michael Weiser]

Hi Sam,

On Fri, Oct 16, 2015 at 01:24:05PM +, Sam Hartman wrote:

> I'm sorry.
> I thought I had responded long ago on this, but apparently not.
> I think the package split makes sense.

I finally got a chance to give this kpropd package split a whirl.
Attached is my first take on a patch.

What's your take on the upgrade path: Do we need to make sure that
someone who's using kpropd now doesn't get it uninstalled upon upgrade
of krb5-kdc? Should we have a preinst script that detects a running
kpropd and print a warning that he'll need to install krb5-kpropd?

Thanks,
-- 
Michael Weiserscience + computing ag
Senior Solutions ArchitectGeschaeftsstelle Duesseldorf
  Faehrstrasse 1
phone: +49 211 302 708 32 D-40221 Duesseldorf
fax:   +49 211 302 708 50 www.science-computing.de
-- 
Vorstand/Board of Management:
Dr. Bernd Finkbeiner, Dr. Arno Steitz, Yvonne Veyhelmann
Vorsitzender des Aufsichtsrats/
Chairman of the Supervisory Board:
Philippe Miltin
Aufsichtsrat/Supervisory Board:
Katrin James, Winfried Holz
Sitz/Registered Office: Tuebingen
Registergericht/Registration Court: Stuttgart
Registernummer/Commercial Register No.: HRB 382196
>From 1a8ddc544abe303e2929edb6a9e4645e062b4caa Mon Sep 17 00:00:00 2001
From: Mark Proehl 
Date: Tue, 13 Jan 2015 14:34:50 +0100
Subject: [PATCH] Move kpropd into separate package

This allows for more fine-granular deployment of services and allows easy
integration of init script and systemd unit for kpropd (in addition to existing
inetd example). Fixes #775277.
---
 debian/control  |  21 +++-
 debian/krb5-kdc.install |   2 -
 debian/krb5-kdc.postinst|  12 -
 debian/krb5-kdc.prerm   |   6 ---
 debian/krb5-kpropd.init | 127 
 debian/krb5-kpropd.install  |   2 +
 debian/krb5-kpropd.postinst |  19 +++
 debian/krb5-kpropd.prerm|  13 +
 debian/krb5-kpropd.service  |  14 +
 debian/rules|   1 +
 10 files changed, 196 insertions(+), 21 deletions(-)
 create mode 100755 debian/krb5-kpropd.init
 create mode 100644 debian/krb5-kpropd.install
 create mode 100644 debian/krb5-kpropd.postinst
 create mode 100644 debian/krb5-kpropd.prerm
 create mode 100644 debian/krb5-kpropd.service

diff --git a/debian/control b/debian/control
index e81e946..71c24d9 100644
--- a/debian/control
+++ b/debian/control
@@ -39,7 +39,7 @@ Depends: ${misc:Depends}, ${shlibs:Depends}, libkrb5-3 (= 
${binary:Version}),
  libkadm5srv-mit9,
  krb5-config, krb5-user, lsb-base (>= 3.0-6), libverto-libev1 | 
libverto-libevent1,
  libkdb5-8 (>= 1.13.1+dfsg-1)
-Suggests: openbsd-inetd | inet-superserver, krb5-admin-server,
+Suggests: krb5-kpropd, krb5-admin-server,
  krb5-kdc-ldap (= ${binary:Version})
 Description: MIT Kerberos key server (KDC)
  Kerberos is a system for authenticating users and services on a network.
@@ -92,6 +92,25 @@ Description: MIT Kerberos master server (kadmind)
  slave KDCs.  This package is generally only used on the master KDC for a
  Kerberos realm.
 
+Package: krb5-kpropd
+Architecture: any
+Priority: optional
+Depends: ${misc:Depends}, ${shlibs:Depends},
+ krb5-kdc (= ${binary:Version})
+Suggests: openbsd-inetd | inet-superserver
+Description: MIT Kerberos key server (KDC)
+ Kerberos is a system for authenticating users and services on a network.
+ Kerberos is a trusted third-party service.  That means that there is a
+ third party (the Kerberos server) that is trusted by all the entities on
+ the network (users and services, usually called "principals").
+ .
+ This is the MIT reference implementation of Kerberos V5.
+ .
+ This package contains the Kerberos slave KDC update server (kpropd). The
+ kpropd command runs on the slave KDC server. It listens for update requests
+ made by the kprop program, and periodically requests incremental updates from
+ the master KDC. This package should be installed on slave KDCs.
+
 Package: krb5-multidev
 Section: libdevel
 Architecture: any
diff --git a/debian/krb5-kdc.install b/debian/krb5-kdc.install
index 93aecc4..15b0e83 100644
--- a/debian/krb5-kdc.install
+++ b/debian/krb5-kdc.install
@@ -2,8 +2,6 @@ usr/sbin/kproplog
 usr/share/man/man8/kproplog.8
 usr/sbin/kdb5_util
 usr/share/man/man8/kdb5_util.8
-usr/sbin/kpropd
-usr/share/man/man8/kpropd.8
 usr/sbin/krb5kdc
 usr/share/man/man8/krb5kdc.8
 usr/share/man/man5/kdc.conf.5
diff --git a/debian/krb5-kdc.postinst b/debian/krb5-kdc.postinst
index e90e301..6e5a8be 100644
--- a/debian/krb5-kdc.postinst
+++ b/debian/krb5-kdc.postinst
@@ -46,18 +46,6 @@ EOF
 db_stop
 fi
 
-# Only try to add the inetd line on an initial installation.  Add it
-# commented out in a way that will not be automatically enabled, since the
-# Kerberos administrator should do that manually when ready.
-#
-# If update-inetd isn't available, don't bother, since it's just an example.
-if [ "configure" = "$1" ] && which update-inetd 

Bug#775277: should we split krb5-kpropd into a separate package?

[Sam Hartman]

I'm sorry.
I thought I had responded long ago on this, but apparently not.
I think the package split makes sense.

Bug#775277: should we split krb5-kpropd into a separate package?

[Benjamin Kaduk]

On Tue, 13 Oct 2015, Michael Weiser wrote:

> Hi Ben,
>
> > Looking at the patch, it feels awkward to manually install the unit file
> > and sysv script to the staging directory.  If we created a new
> > krb5-kpropd package to be installed only on slave KDCs, then we could
> > benefit from the debian/packagename.init magic and also have the script
> > be active by default, since it would only be installed on machines which
> > should use it.
>
> Uh, somehow this slipped past me. I like the idea.
>
> What's the status here: Do all agree, a separate package is the way to
> go? Is someone even working on it?

I think we still need to hear from Sam.

-Ben

> I'd be happy to give it a go, separating kpropd with it's init scripts
> out into a separate package.

Bug#775277: should we split krb5-kpropd into a separate package?

[Michael Weiser]

Hi Ben,

> Looking at the patch, it feels awkward to manually install the unit file
> and sysv script to the staging directory.  If we created a new
> krb5-kpropd package to be installed only on slave KDCs, then we could
> benefit from the debian/packagename.init magic and also have the script
> be active by default, since it would only be installed on machines which
> should use it.

Uh, somehow this slipped past me. I like the idea.

What's the status here: Do all agree, a separate package is the way to
go? Is someone even working on it?

I'd be happy to give it a go, separating kpropd with it's init scripts
out into a separate package.

Thanks,
-- 
Michael Weiserscience + computing ag
Senior Solutions ArchitectGeschaeftsstelle Duesseldorf
  Faehrstrasse 1
phone: +49 211 302 708 32 D-40221 Duesseldorf
fax:   +49 211 302 708 50 www.science-computing.de
-- 
Vorstandsvorsitzender/Chairman of the board of management:
Gerd-Lothar Leonhart
Vorstand/Board of Management:
Dr. Bernd Finkbeiner, Dr. Arno Steitz
Vorsitzender des Aufsichtsrats/
Chairman of the Supervisory Board:
Philippe Miltin
Sitz/Registered Office: Tuebingen
Registergericht/Registration Court: Stuttgart
Registernummer/Commercial Register No.: HRB 382196

Bug#775277: should we split krb5-kpropd into a separate package?

[Benjamin Kaduk]

Looking at the patch, it feels awkward to manually install the unit file
and sysv script to the staging directory.  If we created a new krb5-kpropd
package to be installed only on slave KDCs, then we could benefit from the
debian/packagename.init magic and also have the script be active by
default, since it would only be installed on machines which should use it.

Also, there's a chunk of the patch which is whitespace-only changes that
should probably not be included when we take this feature, since it's just
churn.

-Ben


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org