Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by krbdev.mit.edu (Postfix) with ESMTP id 87A1C3DEDA for ; Thu, 24 May 2012 13:17:24 -0400 (EDT) Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q4OHHN9N020386 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 24 May 2012 13:17:23 -0400 Received: from blade.bos.redhat.com (blade.bos.redhat.com [10.16.184.36]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q4OHHMlv008351 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 24 May 2012 13:17:23 -0400 Received: from blade.bos.redhat.com (localhost.localdomain [127.0.0.1]) by blade.bos.redhat.com (8.14.5/8.14.5) with ESMTP id q4OHHMPT016338 for ; Thu, 24 May 2012 13:17:22 -0400 Received: (from nalin@localhost) by blade.bos.redhat.com (8.14.5/8.14.5/Submit) id q4OHHL7v016337 for rt@krbdev.mit.edu; Thu, 24 May 2012 13:17:21 -0400 Date: Thu, 24 May 2012 13:17:21 -0400 From: Nalin Dahyabhai To: rt@krbdev.mit.edu Subject: Re: [krbdev.mit.edu #6742] would like to be able to specify listening address for krb5kdc and kadmind Message-ID: <20120524171721.GA2268@redhat.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: Red Hat, Inc. X-Disclaimer: I am not a spokesmodel. Views expressed are my own. X-Key-ID: 78688BF5 X-Key-Fingerprint: 60BC AD87 AF51 3A00 8C99 0388 379B CE57 7868 8BF5 User-Agent: Mutt/1.5.21 (2010-09-15) X-Scanned-BY: MIMEDefang 2.67 on 10.5.11.11 RT-Send-Cc: X-RT-Original-Encoding: us-ascii Content-Length: 851 On Thu, May 24, 2012 at 12:04:30PM -0400, Greg Hudson via RT wrote: > We have someone interested in solving this issue. Do you think it would > be sufficient to add an inetd option to krb5kdc? > > Because we serve over UDP and TCP, and because correctly implementing a > UDP server in the Unix socket interface is more difficult than it should > be, our server network loop is very complicated. Deferring this issue to > inetd would have a small UI footprint and would add a small amount of > additional complexity. Adding specific address configuration would have a > larger UI footprint and a larger increase in complexity, I expect. But > it's something we could still consider. It sounds like it could. Would such a setup end up firing up a different KDC (or kadmind) process for each listening address that received traffic? Nalin