Bug#841372: Kerberos config update for CS.CMU.EDU

[Jeffrey Hutzelman]

On October 19, 2016 10:40:59 PM EDT, Sam Hartman  wrote:
>Your timing is dreadful.:-)

Yes.  Then again, I should have done this years ago.


>I just uploaded a new krb5-config and am not 100% sure I'll have time
>to
>get in another one for stretch before the freeze.
>I considered dropping the kdc lines and depending on SRV records for
>cs.cmu.edu, but decided that you were picky enough that you would have
>sent in an update request if you wanted one:-(

That would work, too.  The SRV records aren't going anywhere.


>I'll see what I can do.
>
>I need to wait for 2.5 to get into testing before uploading a 2.6
>because 2.5 is really needed.

Understood.  If it doesn't get done before the freeze, we'll live.  probably.  
:-)

-- Jeff

Bug#841372: Kerberos config update for CS.CMU.EDU

[Jeffrey Hutzelman]

Package: kerberos-configs
Version: 2.3
Severity: wishlist

The CS.CMU.EDU realm stanza included in krb5-config is a bit out of
date, and actually has been for some time.  We're trying to stamp out
client configuration that uses kerberos.cs.cmu.edu other than for admin
services, and it would help to get the following update applied:

OLD:
        CS.CMU.EDU = {
kdc = kerberos.cs.cmu.edu
kdc = kerberos-2.srv.cs.cmu.edu
admin_server = kerberos.cs.cmu.edu
}


NEW:
        CS.CMU.EDU = {
kdc = kerberos-1.srv.cs.cmu.edu
kdc = kerberos-2.srv.cs.cmu.edu
kdc = kerberos-3.srv.cs.cmu.edu
admin_server = kerberos.cs.cmu.edu
}

Thanks...

-- Jeff

Bug#757140: apr-util: please drop unneeded dependencies in libaprutil1-dev

[Jeffrey Hutzelman]

Package: apr-util
Version: 1.5.3-2

libaprutil1-dev contains dependencies on four other -dev packages which
do not appear to actually be needed when building against libaprutil:

libpcre3-dev
libsqlite3-dev
libpq-dev
libmysqlclient-dev

These appear to stem from a need to have .la files provided by those
packages, which were previously referred to by the dependency_libs in
libaprutil1.la.  Now that the dependency_libs is empty (per Policy 10.2
and #619179), the corresponding -dev package dependencies are no longer
needed, and serve only to force the installation of unnecessary
development packages.  In particular, this dependency, combined with an
actual dependency in libpq-dev, means that it is impossible to have
libaprutil1-dev and heimdal-dev installed at the same time.


-- Jeffrey T. Hutzelman (N3NHS) jhu...@cmu.edu
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA


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

Bug#645382: unattended-upgrades: WARNING package 'NAME' upgradable but fails to be marked for upgrade

[Jeffrey Hutzelman]

On Thu, 2013-02-21 at 21:13 +0100, Michael Vogt wrote:
 On Wed, Feb 20, 2013 at 04:27:29PM -0500, Jeffrey Hutzelman wrote:
  (resending, so this actually shows up in the web log)
  
  sigh
  While 0.79 may address the new issue raised by ma...@debian.org in
  message #39, it does _not_ address the original issue, which relates to
  u-a refusing to upgrade a package if doing so would cause another
  package to be deleted, even when conflicts/provides/replaces are in
  play.
  
  Like the original requestor, I'd very much like to see a knob that
  changes this behavior, at least in cases where the deleted package is
  being replaced.
 
 Thanks for your mail! Attached is a bzr patch bundle that contains a
 first iteration of this feature. The bulk is the test data, the actual
 patch is relatively small.
 
 I only created a artifical testcase for it, it would be great if you
 could test it with unattended-upgrade --debug --dry-run for the real
 world case where it refuses to upgrade the package.

That seems to do the right thing, more or less.  It turns out that in
the real-world case, the replacing package uses Breaks, not Conflicts.
Given that the DPM seems to encourage the use of Breaks over Conflicts
in cases where it is not absolutely essential that the two packages not
be unpacked at the same time, I think the right thing is to treat either
relationship as meeting the requirement.  I've attached a patch that,
applied over yours, has that effect.  With both patches applied over
unattended-upgrades 0.76ubuntu1, my problem goes away.

-- Jeff
--- unattended-upgrade.x	2014-05-08 14:40:05.47902 -0400
+++ unattended-upgrade	2014-05-08 14:40:26.729118435 -0400
@@ -359,6 +359,12 @@
 if dep.name == needle_pkg.name:
 is_conflict = True
 break
+for or_dep in pkg.candidate.get_dependencies(Breaks):
+for dep in or_dep:
+print dep.name, needle_pkg.name
+if dep.name == needle_pkg.name:
+is_conflict = True
+break
 for or_dep in pkg.candidate.get_dependencies(Replaces):
 for dep in or_dep:
 if dep.name == needle_pkg.name:

Bug#729353:

[Jeffrey Hutzelman]

 This should have been fixed automatically via the upgrade.  I assume that
 part worked but your worry is someone changing it back afterwards?

That, or distributing configuration from a central source that needs to
work with multiple versions of the package.

 I suppose the init script could check for either, but now I wonder if that
 file shouldn't also have a comment saying that you were really looking for
 dpkg-reconfigure openafs-client and missed.

Um.  I suppose a comment suggesting using dpkg-reconfigure wouldn't be
out of place.  However, the notion that I'm doing it wrong if I edit the
file manually (or copy in one I got from a friend or my site admin) is
IMHO an unfriendly one.

-- Jeff


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

Bug#645382: unattended-upgrades: WARNING package 'NAME' upgradable but fails to be marked for upgrade

[Jeffrey Hutzelman]

(resending, so this actually shows up in the web log)

sigh
While 0.79 may address the new issue raised by ma...@debian.org in
message #39, it does _not_ address the original issue, which relates to
u-a refusing to upgrade a package if doing so would cause another
package to be deleted, even when conflicts/provides/replaces are in
play.

Like the original requestor, I'd very much like to see a knob that
changes this behavior, at least in cases where the deleted package is
being replaced.


-- Jeffrey T. Hutzelman (N3NHS) jhu...@cmu.edu
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA


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

Bug#337041: IUTF8 pseudo-terminal mode

[Jeffrey Hutzelman]

On Mon, 2013-02-04 at 16:02 +0100, Vincent Lefevre wrote:
 On 2005-12-31 16:05:59 +, Colin Watson wrote:
  Recent versions of the Linux kernel support an IUTF8 flag (see
  http://www.cl.cam.ac.uk/~mgk25/unicode.html#mod) which allows the
  character-erase function in cooked mode to handle UTF-8 characters
  correctly. I would like to allow this mode to be preserved by SSH, but
  there is no assignment for it at present.
  
  Could this line be added to the appropriate place in
  draft-ietf-secsh-connect and draft-ietf-secsh-assignednumbers to create
  this assignment? 42 seems like a reasonable place for it.
  
42IUTF8   Assume input characters are UTF-8 encoded.
  
  Thanks,
 
 The problem is still there in the Debian packages from openssh 6.0p1-3.

Yes, I'm sure it is.  The requested number was not added to the draft,
because it was too late to do so before publication.  A few days later,
Bill Sommerfeld, who was WG chair at the time, posted the following:

 So what needs to happen to get this standardized is for someone to write
 an internet-draft documenting this extension and advance it as either a
 working group item or as an individual submission.

That remains the case today.  The registration policy for that registry
is IETF Consensus, which means that getting a new number assigned
requires publishing an RFC.  For this sort of thing, that could happen
relatively quickly, once someone writes an internet-draft.

-- Jeff


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

Bug#46049: local services

[Jeffrey Hutzelman]

  /etc/service.d - wontfix ? Or is somebody still thinking about it ?
 I do not expect that this will happen, ever.

Any particular reason?

We did this a couple of months ago as an NSS module, which we're
planning on submitting upstream just as soon as we have some time.

Alternately, if there is still interest in merging in the contents
of /etc/services.local or similar, we've had a tool for that which we've
used on a variety of platforms since before this bug existed.
Unfortunately, it depends on perl, which would be an unacceptable
dependency for netbase.  However, if anyone is interested in using it
locally, they are welcome to do so; see

http://source.fac.cs.cmu.edu/cvsweb/dist/commonx/usr/adm/fac/bin/newservices

-- Jeffrey T. Hutzelman (N3NHS) jhu...@cmu.edu
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA





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

Bug#46049: [Fwd: Re: Bug#46049: local services]

[Jeffrey Hutzelman]

 Forwarded Message 
From: Jeffrey Hutzelman jh...@cmu.edu
To: Marco d'Itri m...@linux.it
Cc: jh...@cmu.edu
Subject: Re: Bug#46049: local services
Date: Tue, 11 Oct 2011 14:08:55 -0400

On Tue, 2011-10-11 at 19:41 +0200, Marco d'Itri wrote:
 On Oct 11, Jeffrey Hutzelman jh...@cmu.edu wrote:
 
/etc/service.d - wontfix ? Or is somebody still thinking about it ?
   I do not expect that this will happen, ever.
  Any particular reason?
 Low benefits, high cost and complexity.
 Configuration files are editable for a reason.

Sorry; I don't buy it.  The added complexity of examining a directory
full of files instead of a single file is not that high, and the
benefits are significant, which is why this approach has been deployed
throughout the system.  In particular, it eliminates two problems, which
taken together result in an intolerable situation:

1) Users wishing to add or update entries in /etc/services are forced
   to take manual action on every update, to merge local changes in
   with the new packaged database.  UCF would make this a little less
   painful, but as you correctly point out, it can't be used here
   unless/until it is promoted.  And, it doesn't really resolve the
   problem, because the user _still_ has to react to every update.

2) Maintainers needing to add or update entries in /etc/services are
   forced to submit a bug and wait for an updated netbase.  I haven't
   paid attention to how promptly this happens, so I'm not suggesting
   that this takes too long.  However, you're pretty much forced to
   choose between infrequent updates, which creates problems for new
   packages, or frequent updates, which exacerbates (1).  Additionally,
   this puts you in the critical path for every new network-based
   service, which creates both a bottleneck and unnecessary work for
   you.


I can understand not wanting to introduce much additional complexity
into netbase which, after all, is both fairly simple and an important
package.  Personally, my preferred solution is the introduction of
libnss-dir:

Description: nss module to use directories (e.g /etc/hosts.d)
  This Name Service Switch (NSS) module works much like the 'files'
  service, but allows the local database to be constructed from an
  entire directory of files (e.g. /etc/hosts.d) instead of only a
  single file (/etc/hosts).
  .
  This module fully supports the ethers, hosts, networks, protocols,
  rpc, and services databases.  It also implements passwd, group, and
  shadow, but use of these is not recommended except under unusual
  circumstances, because it may not interact well with tools such as
  adduser(8).


However, I don't think the complexity of merging e.g. /etc/services.d is
too high.  Particularly, while inelegant, 'cat' is actually sufficient
as a merge tool for this case.

-- Jeff






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

Bug#143111: [OpenAFS-devel] Testing GNU findutils on AFS.... please!

[Jeffrey Hutzelman]

--On Monday, May 05, 2008 01:05:59 PM +0100 James Youngman [EMAIL PROTECTED] 
wrote:



On Tue, Apr 8, 2008 at 12:19 AM, Jeffrey Altman
[EMAIL PROTECTED] wrote:


 Are you willing to attempt to try to perform an AFS pioctl call
 to verify if the path is in AFS?


Speculatively for every directory on every system, no.


It shouldn't be necessary for every directory, only for the first directory 
and every time you cross into a new filesystem (i.e. st_dev changes).



It occurs to me to ask something else though.  Is possible for there
to be any kind of infinite cycle in an AFS directory hierarchy?


Yes.  Any number of mount points can refer to a volume, and it is possible 
to construct cycles this way.



With regular Unix filesystems we rely on the uniqueness of the
{st_dev,st_ino} combination; if we see the same value pair twice under
one startpoint, we conclude there is a loop.  Will this method work
for AFS?


Mostly.  Inode numbers in AFS encode the vnode number and volume ID; 
distinct vnodes in the same cell will have distinct inode numbers unless...


(a) You have 32-bit inode numbers and more than 2^16 volumes
(b) You are one of a handful of cells with funny volume ID's
(c) You have a volume with more than 2^15 directories or 2^15 non-dirs.

In any of those cases, you might get multiple vnodes with the same inode 
number.  In addition, vnodes in different cells may have different inode 
numbers, because the inode number does not encode the cell.


In practice, we've found this to be good enough for a wide variety of uses 
that depend on inode number uniqueness, for many years.  However, for 
correctness, if you think you've encountered a loop it is probably best to 
do an AFS pioctl to discover the actual FID cell, volume ID, and vnode 
number of the potentially-duplicate entry.  Of course, this requires that 
you have done so for the first occurrance, but IMHO the performance penalty 
of making this call for every directory known to be in AFS is acceptable.




 Now that I think about it, it would also be helpful to know what
 common Linux AFS clients put in struct dirent.d_type for AFS
 filesystem objects (files, directories, ...).  How about other Unix
 systems which support both AFS and d_type?  I also understand that AFS
 ACLs can sometimes allow readddir() to return a directory entry
 without it being possible to lstat(2) said directory item.  Is this
 the case?   What goes into d_type for such items?


 I will let someone else answer this.


Nobody has, though, yet...


I believe I did answer this.

When we know the type, we fill it in.  Directories and mount points get
DT_DIR; files get DT_REG.  Currently symlinks always get DT_UNKNOWN, which
I consider a bug, and so do objects whose type is genuinely not known.

MacOS X uses the same logic as Linux, described above.
It doesn't look like OpenAFS supports d_type on other platforms.

Yes.  It's possible to get an entry that corresponds to a directory on
which you have no permissions, or a mount point pointing at a volume that
doesn't exist, or for a FetchData call to return an error in response to
some problem on the fileserver.

-- Jeff



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#143111: [OpenAFS-devel] Testing GNU findutils on AFS.... please!

[Jeffrey Hutzelman]

On Thu, 20 Mar 2008, James Youngman wrote:

 This property is normally honoured by Unix (file-) systems because
 filesystems can only be mounted on subdirectories in any case.  Here's
 an example:

Right, so the link count of the parent counts the mounted-on directory,
not what's mounted there.

 That's not generally true for the reason illustrated above, but I'll
 assume your statement was about AFS specifically.

Correct.

  You can't tell in advance which kind you'll see, so a heuristic
   like checking to see if the rule applies to the first directory you
   examine, which probably works fairly well for other filesystems, won't work
   with AFS.

 So is it the case that I can mount an AFS filesystem at
 /afs/mumble/foo/bar without there previously existing a directory
 /afs/mumble/foo?

Correct, in a way, but your phrasing suggests a conceptual disconnect.
One doesn't generally think of an AFS filesystem, but of _the_ AFS
filesystem -- there is conceptually a single, global filesystem, which is
normally mounted at /afs.

An AFS mount point isn't a dynamic, client-side thing like a normal UNIX
filesystem mount; it is an object _in_ the filesystem which refers to
another volume.  This is presented mostly-transparently to userland as
just another directory.  Part of the mostly is the link count currently
under discussion,  The rest is a set of AFS-specific interfaces for
examining and manipulating mount points explicitly (*).

Note that David Howells has an alternate AFS client implementation one
version of which is distributed with the Linux kernel.  He handles mount
points by presenting them to userland as empty directories, allowing any
AFS volume to be mounted on any directory, and providing automounter-like
functionality to trigger mounts as mount points are traversed.  However, I
have no idea whether he adjusts the link counts of the containing
directories to reflect mount points.  I would suspect not, since that
would mean that satisfying stat(2) on a directory would require fetching
metadata for all of its contents from the fileserver.


 At the moment, find (oldfind in 4.2.x and 4.3.x) relies on examining
 the results of stat(2) to figure out if it should turn off the leaf
 optimisation.  It makes this determination for every directory it
 searches.   Supposing find knows that AFS may be in use somewhere on
 the system, what is the highest performance way of determining if the
 link-count assumption will hold immediately within that directory?

I can't think of an efficient way.  It may be helpful to know that inode
numbers in AFS are always odd for true directories, and even for
everything else, including mount points (this began as an artifact of the
server implementation, but too much depends on it for it to change now).
Note that while a volume root is a directory, it is presented with the
inode number of the mount point.

Unfortunately, I'm not sure how that helps you.


 Is it feasible for example to assume that directories not
 (canonically) beginning with /afs/ (or matching the regex ///+afs/)
 simply cannot be on an AFS filesystem?

On a system running OpenAFS, it is generally safe to assume that AFS is
mounted in only one place, because we generally can't do anything else.
There was code for a while to allow multiple mounts on MacOS X, but it
used an approach that ISTR was unsafe to begin with and impossible in
later OS releases, so I don't believe it exists any longer.

On a system running OpenAFS, it is also safe to assume that all files in
AFS will have the same value for st_dev.

Unfortunately, these assumptions don't always hold on other clients.

On many platforms, you can expect the reported filesystem type to be
something meaningful.  I don't know whether this is the case for all
platforms or not.

 Now that I think about it, it would also be helpful to know what
 common Linux AFS clients put in struct dirent.d_type for AFS
 filesystem objects (files, directories, ...).

When we know the type, we fill it in.  Directories and mount points get
DT_DIR; files get DT_REG.  Currently symlinks always get DT_UNKNOWN, which
I consider a bug, and so do objects whose type is genuinely not known.


 How about other Unix
 systems which support both AFS and d_type?

MacOS X uses the same logic as Linux, described above.
It doesn't look like OpenAFS supports d_type on other platforms.

 I also understand that AFS
 ACLs can sometimes allow readddir() to return a directory entry
 without it being possible to lstat(2) said directory item.  Is this
 the case?

Yes.  It's possible to get an entry that corresponds to a directory on
which you have no permissions, or a mount point pointing at a volume that
doesn't exist, or for a FetchData call to return an error in response to
some problem on the fileserver.

 What goes into d_type for such items?

The same as in any other case - if we know the type, it gets filled in;
otherwise it get set to DT_UNKNOWN.  Note that the type of a filesystem
object is 

Bug#143111: [OpenAFS-devel] Testing GNU findutils on AFS.... please!

[Jeffrey Hutzelman]

--On Saturday, March 15, 2008 08:36:45 PM + James Youngman 
[EMAIL PROTECTED] wrote:



First of all, please forgive me for posting to your mailing list
without first subscribing to it.   Secondly, please CC me on your
replies since I am not subscribed :)


eh; that's what moderators are for (says the person who is supposed to be 
moderating, but mostly shirks that duty and leaves it to others).



My question, is, if you build GNU findutils on your system, do the
-xdev option and the -fstype test work on AFS


I'm sure someone will give this a try and let you know.  Also, I bet if we 
tried really hard, we could get you access to someplace where you can test 
for yourself.



If you are in a mood to test things though, is oldfind's -noleaf
option needed to correctly search AFS filesystems?  (without it, find
assumes that directories with a link count of 2 have no
subdirectories).


Without testing, yes, it is needed at least some of the time.  That 
assumption is not valid in AFS, and neither is the assumption that when you 
run out of link count you've run out of subdirectories.  The problem here 
is that AFS files can be one of four kinds - files, directories, symlinks, 
and mount points.  A mount point is a reference to the root of another 
volume by name or volume ID.  Mount points look to clients like 
directories, but are not counted in the containing directory's link count, 
since they do not in fact contain a link to that directory.


So, to a program like find, there are effectively two kinds of 
subdirectories -- those that are included in the link count and those that 
are not.  You can't tell in advance which kind you'll see, so a heuristic 
like checking to see if the rule applies to the first directory you 
examine, which probably works fairly well for other filesystems, won't work 
with AFS.


-- Jeff



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#337041: IUTF8 pseudo-terminal mode

[Jeffrey Hutzelman]

On Monday, January 02, 2006 04:43:58 PM -0600 Nicolas Williams 
[EMAIL PROTECTED] wrote:



On Mon, Jan 02, 2006 at 05:29:40PM -0500, Bill Sommerfeld wrote:

In response to later messages:
 While setting LANG et al is indeed useful, it's not enough to make the
 kernel's terminal driver do the right thing when erasing characters in
 cooked mode. That's why the termios flag was invented.

I think Nicolas was implying that a request from the client to use a
UTF8 locale would cause the server to set up the pseudoterminal it
creates/allocates/... appropriately for the requested locale.  But
that's perhaps at odds with the existing strategy within the protocol of
making termios-level details visible on the wire.


I think I was a bit more explicit about this, but, yes, this would be a
hack, and very POSIX-specific (and I was explicit about that too).  But
such a hack would also probably make most users happy :^/ at the expense
of elegance and code complexity for SSHv2 servers running on POSIXy
platforms.

SSHv2's pty negotiation could certainly improve in this regard, I don't
deny it!

But I suspect saying UTF-8 is not enough here.  What options are
there?  Should the pty driver reject non-UTF-8 sequences?  Should it
normalize?  Pass input through raw?  I suspect most users wouldn't want
much of a pty UTF-8 input mechanism as their clients, presumably, have a
decent UTF-8 input method already -- but then, maybe they don't.

I definitely think this should be a WG work item, if nothing else to
ensure it gets more eyeballs because I18N requires care.


The original request wasn't really about standardizing handling of UTF-8 in 
SSH data streams.  That's really outside the scope of the protocol -- 
unlike telnet, SSH doesn't provide a virtual terminal; it connects the 
shell running on the server to the user's real terminal, and experience has 
shown this is basically the right thing to do.


The request here was to enable SSH to pass a platform-specific TTY mode bit 
which it doesn't currently handle.  The bit in question causes the tty 
driver on Linux systems to behave in a particular way; specifically, it 
tells the driver that the user is typing in UTF-8, and that when the user 
types the ERASE character, the driver should remove a complete character 
(possibly a multi-byte UTF-8 sequence) from the input buffer.


One could argue that an SSH server running on such a system should look at 
the configured locale and configure the PTY appropriately, and that's 
probably even a good idea.  However, a user using 'stty' to change terminal 
modes at the remote end of an ssh connection has an expectation that the 
change will propagate to the local terminal as much as possible, and the 
point of defining a bit for IUTF8 is to help make that possible.


-- Jeff


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]