Re: Upcoming changes to Debian Linux kernel packages

[Sam Hartman]

> "Bastian" == Bastian Blank  writes:

Bastian> The same as now: nowhere, because those packages have been
Bastian> removed from the archive already.

Bastian> And sadly you did not answer the question why a second
Bastian> degree error must not be worse then a worked around first
Bastian> degree error?

I'll admit that I find that phrasing difficult enough that I had to read
it a couple of times and I'm still not sure I've got it.

Let me see if I understand what you are saying.

1)  kernel headers will be removed from the archive.  So people complain
if they have an old kernel and wish to get kernel headers for it, but
those headers have been removed.

2) If the kernel header version changes but the kernel header package
name does not change  (version changed but not uname -r in the new
scheme?), you can have what you think is the right kernel headers but
they do not work with the binaries you have installed.

3) you can run into trouble between testing and backports.

I think that's what you mean by the first-level error.
If not, I'm still confused.

In the second level error case you are talking about is:

1) there is a regression in the kernel

2) someone needs kernel headers for an old kernel they want to downgrade
to.

I don't actually see how this is a second level error.
It appears to be a different first-level error (a regression), and  the
downgrade appears to follow naturally from that.

You point out that someone may not be able to get kernel headers for the
downgraded kernel.

a) They might.  In the window between a new kernel being introduced into
unstable and the same kernel being introduced into testing  there is an
old kernel available with kernel headers.
Similarly if someone needs to downgrade as far as stable, there is a
kernel with headers available in stable.

B) They might already have headers installed.  Imagine someone who
installs headers at the same time they install the kernel.
Unless they managed to upgrade the same version of their kernel without
also upgrading their headers, they will still have headers.
They can still build modules against that kernel, either because they
installed a new dkms package, or because one of their dkms packages
upgraded.

I think what you are saying is that

1) the current system is fragile: sometimes you want a kernel headers
that is not available and sometimes you have version skew between the
kernel headers and kernel even though you have both installed.

2) In your system, fewer things are possible, but the combination that
is possible is more likely to work.

And I think people's response is that
they care enough about some of the things you are breaking that they are
willing to accept the fragility.


Bastian> -- Each kiss is as the first.  -- Miramanee, Kirk's wife,
Bastian> "The Paradise Syndrome", stardate 4842.6

Re: Upcoming changes to Debian Linux kernel packages

[Sam Hartman]

> "Bastian" == Bastian Blank  writes:

Bastian> On Mon, Sep 25, 2023 at 04:35:08AM +0200, Andreas Beckmann wrote:
>> On 25/09/2023 00.50, Bastian Blank wrote:
>> > Already built modules remain until someone deletes it.  So you
>> can also > switch back to the still installed older kernel
>> version and it will have > the still working module available.
>> Assume I have Linux 6.6 and a third-party gpu driver module
>> installed (so there are dkms and the Linux 6.6 headers as well)
>> and everything is working fine.  Then I upgrade the system, which
>> brings Linux 6.7 (along linux-image-6.6 which is kept installed)
>> and a new version of the gpu driver (which adds support for
>> 6.7). So the old gpu module for 6.6 gets removed and a new one is
>> built for 6.7 only (since there are only 6.7 headers now).

Bastian> Ah, here lays the missconception.  No, the 6.6 ones are not
Bastian> removed.  Why should they be?  The system knows it can't
Bastian> rebuild them.

Bastian> If the current implementation would remove them, it is a
Bastian> problem there, not in the concept.

I still think it would help if you would work more on articulating what
problem you are trying to solve with the linux-headers versioning
change.  I have read multiple versions of this proposal, and your
follow-ups, and I still do not understand what is prompting the
linux-headers change.

My intuition mirrors others in the conversation that it is problematic
to support multiple kernel versions without also supporting multiple
header versions.

Bug#1035908: Bullseye regression: NFS4 referals appear not to work

[Sam Hartman]

package: nfs-utils
severity: important
justification: regression from bullseye with silent failure
version: 1:2.6.2-4

Hi.
I've noticed that since upgrading to  bookworm the refer option in
/etc/exports appears to be entirely ignored.

Looking through the sources to exportd and support/export/cache.c, it
looks like perhaps referals support in exports is keyed on
--enable-junctions.  I'm not entirely sure of that, but
it looks like write_fsloc is only called in dump_to_cache  if
HAVE_JUNCTION_SUPPORT is enabled.

I *think* write_fsloc is what writes out the referal location as well as
any junction location.
So, I *think* that as part of adding the junction support upstream has
broken referals unless you enable junction support.

That's kind of unfortunate for us because junction support comes with
dependencies like libxml2 which are kind of a lot to swallow in
nfs-utils.

I'd appreciate help confirming my conclusions.

* Are referals actually broken

* Is there an easy way to get them back without junction support

* how willing to turn on junction support are we in bookworm?  In a
  bookworm backport?
  


signature.asc
Description: PGP signature

Bug#1028451: 2nd DisplayPort doesn't get video

[Sam Hartman]

> "Moritz" == Moritz Mühlenhoff  writes:
Moritz> Not moving to 6.1.x (which is most likely the next Linux
Moritz> kernel LTS) is by far a worse regression since it applies to
Moritz> every single Debian system.

Moritz> As a community distro without paid, full time kernel
Moritz> maintainers we can't just randomly stick to an older kernel
Moritz> tree and decide to assess/backport hundreds of patches sent
Moritz> to stable@ every week.

I think we're all agreed on that point.
What we can do is delay the release if we have a serious enough bug that
is not fixed yet.
I think what people are saying on this bug is that this issue is serious
enough it should be considered as a release blocker---something that
could actually delay the release.

From where I sit, thinking about what I've deployed in the last five
years, I agree with that analysis: this *might* be serious enough to
delay the release until there is a fix.
Given that  we can't stick on 6.0, I think we should try to get this
into testing as soon as possible so we can see how big of an impact it
is in practice.
I don't like to see testing broken, but I like to see stable broken in
serious ways even less.
And so I'd recommend we see  how badly this is going to hurt us.


signature.asc
Description: PGP signature

Re: Which package is responsible for setting rlimits?

[Sam Hartman]

>>>>> "Simon" == Simon McVittie  writes:

Simon> On Mon, 01 Feb 2021 at 11:49:25 -0500, Sam Hartman wrote:
>> >>>>> "Simon" == Simon McVittie  writes: I'm
>> assuming that the proposal is to change this for bookworm.

Simon> I'm sorry, I don't have a concrete proposal, and I don't
Simon> understand which package is meant to be responsible for this
Simon> well enough to write one.

It sounded like you were proposing that pam detect if systemd was pid1
and if so, then do what it does today otherwise inherit limits by
default.

Assuming the PAM maintainer wants to support alternative init systems in
a context bigger than development, that sounds like a fine option.
Detecting whether pid1 is systemd might be tricky for pam; I haven't
thought about what that does for (build) dependencies, but we could
figure something out.

However, this change seems too late for bullseye given where we are in
the freeze.

Re: Which package is responsible for setting rlimits?

[Sam Hartman]

> "Simon" == Simon McVittie  writes:

I'm assuming that the proposal is to change this for bookworm.
It seems like it's too late in the process to change something like this
for bullseye without more explicit and significant harm documented  than
you have given so far.

Simon> Rationale: on sysvinit or runit systems, pid 1 is very simple
Simon> and is unlikely to need to elevate any limits, but sysadmins
Simon> are expected to restart system services in an unpredictable
Simon> execution environment (certainly true for systemd, I'm not so
Simon> sure for runit). On systemd systems, pid 1 is more complex,
Simon> but part of the value we get for that complexity is that even
Simon> when sysadmins restart system services, the service receives
Simon> a known and predictable execution environment, so it does not
Simon> need to be robust against inheriting a wrong rlimit or other
Simon> parameters.

At a project level, I mostly don't buy this rationale in the context of
the GR we passed last year.

My reading of that GR is that running alternative init systems for end
users is not a project-level goal.
It may be a goal of individual package maintainers.
Supporting development of alternative init systems is a project level
goal, or at least was at the time we voted on the GR.

So, in terms of how the project thinks about this, I think the question
should be how much  would  the behavior of accepting defaults from init
systems negatively impact the work of someone trying to develop a new
init system.

At one level, they could certainly configure PAM if the particular
situation was unusual.
At another level, if the limits that pam is likely to inherit are going
to be sufficiently broken to hender normal work, that's probably not
good.

I actually think that in most cases inheriting limits would be
acceptable for development, even if it did add some uncertainty for
production use.
I also think that a credible replacement to systemd is going to need to
provide a way to configure resource limits and to allow administrators
to restart services from pid 1 rather than from a random context.

So,I think that by the time development of an alternate init system
progresses to a point where it is being considered by the project as a
credible replacement for systemd, inheriting limits is likely to work
for that system.



It may well be that the PAM maintainer wishes to support sysvinit or
other alternate init systems in contexts broader than the development of
an init system.
I don't know; that seems like a decision for the PAM maintainer rather
than debian-devel.

If that is true, then your proposed solution seems reasonable.
If not, then perhaps we should just drop our patch.

Re: Producing verifiable initramfs images

[Sam Hartman]

This is not a disagreement with anything you write.

I've noticed that there is a lot more configuration that gets encoded in
the initramfs than I thought.
The most surprising for me is that if you want to control the names of
network devices or anything else set by the .link file,
that ends up needing to go on the initramfs, because udevd will set up
network devices even if they are not needed to find the root.
Unfortunately, that means that initramfs udev configuration (including
/etc/systemd/network/*.link) tends to need to be on the initramfs.

I realize you only gave crypttab as an example, but the set of initramfs
configuration is larger than I at least expected.

--Sam

Re: Merge request friendly handling of debian/changelog

[Sam Hartman]

I agree that better handling of things like debian/changelog is
something we should focus effort on.

I think we can either  do something gbp dch like, possibly allowing
commits to annotate whether and to what extent they should be included
in changelog.

Or  some code that knows how to merge changelogs

Or some file based approach like you discuss.

I think exploring options like these and getting experience would be
great for Debian.

Re: Bits from the Release Team: ride like the wind, Bullseye!

[Sam Hartman]

> "Ben" == Ben Hutchings  writes:

Ben> On Sun, 2019-07-07 at 02:47 +0100, Jonathan Wiltshire wrote:
Ben> [...]
>> No binary maintainer uploads for bullseye
>> =
>> 
>> The release of buster also means the bullseye release cycle is
>> about to begin.  From now on, we will no longer allow binaries
>> uploaded by maintainers to migrate to testing. This means that
>> you will need to do source-only uploads if you want them to reach
>> bullseye.

Ben> I support this move in principle, but:


Ben> This is not going to fly for src:linux.  We can't stage ABI
Ben> bumps in experimental as we typically have a different upstream
Ben> versions in unstable and experimental.  We even need to do ABI
Ben> bumps in stable from time to time.

Ben> I think that the requirement to upload binary packages for
Ben> binary-NEW (but not source-NEW) needs to go.

I agree with Ben.  There are a lot of good reasons to stage (possibly
even most) binary new packages through experimental.
Ben has talked about cases where experimental can't work.
I'd like to talk about cases where it is the wrong answer.

However, we've gotten a lot of feedback from our maintainers over the
years that anything that adds an extra round trip to their workflow is
significantly demotivating.
If I need to wait for something to go through new, and then after it
goes through new do an extra thing to accomplish my goal, that increases
the cost of what I'm doing significantly.

If it's a simple soname bump because of a new symbol, that doesn't
always require experimental.  Thinking back to my own experience with
krb5, I have a good handle on when ABI bumps need to go through
experimental and when things are going to be fine through unstable.  I
haven't made a lot of mistakes in that front--uploading things to
unstable that ended up being broken enough we wished they had gone
through experimental.

I know I'm not alone.

I think that for this to fly, binaries for binary new need to go.

I understand that balancing the trade offs here requires a bit of a mind
meld between the ftp team and the release team, and I understand that
cross team decision making is more complex here.
I'd be happy to facilitate any discussion around the trade offs if that
would be useful.

--Sam

Bug#929557: Some Thoughts

[Sam Hartman]

The linux Kernel introduced an upstream commit designed to remove an
interface that was being misused.

That does not meet the kind of requirements for changes that we (Debian)
make in stable releases.
If I filed an unblock for krb5 to remove an interface at this point in
the release process it would be outright refused.

Even if krb5 had multiple levels of visibility and even if I filed an
unblock to change interface visibility it would be refused.

Even if I filed an unblock to change interface visibility to prevent
other people from violating the krb5 license it would be refused.

We are more permissive in what changes we accept from the kernel team.
There are a lot of reasons for that.  But I think it's more that we're
changing the default for changes from the kernel team, than that we
necessarily want the kernel team to be more able to break other software
in stable than other packages.

That is, if we had the resources to review the changes adequately and do
adequate testing, I actually suspect we would hold the kernel to the
same standards we hold other packages to.

I do not think this particular change would meet those standards for
buster.
I think this change clearly meets those standards for unstable.
And yet, as I said above, we do hold the kernel to different standards
for stable releases for a variety of reasons.
However, even if the default is that we are more permissive with the
kernel, we can review the complex cases on a case by case basis.  And we
should review that based on what is best for Debian, not what is best
for the kernel team.

I'm not saying the kernel team should revert the commit.
I'm saying that the issue is far more complex than has been outlined in
this bug so far.

I think that the kernel team and the ZOL maintainers should work with
the stable release team for buster to figure out which changes are
permissible.
Ultimately I'd expect that the stable release team will get to decide
which changes they want in buster and I hope that the kernel team and
the ZOL maintainers will work with that.

Re: ZFS in Buster

[Sam Hartman]

Hi.

Thanks for bringing up this issue originally.
I think it has started some good discussion with the Debian zfs
maintainers.

However, I think this particular subthread about zfs has served its
purpose.

I cannot find anything in your message that is on topic for the
debian-devel mailing list.

Rehashing github discussions  between two non-debian parties doesn't
really seem of central import to the Debian developer community.

Discussing what the open zfs and kernel community should do and how they
should work together is certainly off-topic for debian-devel.

There are certain zfs discussions that might be on-topic for
debian-devel, but this particular subthread does not appear to be one of
them.
Thanks,

--Sam

Re: Fixing Linux getrandom() in stable

[Sam Hartman]

> "Thorsten" == Thorsten Glaser  writes:

Thorsten> Adrian Bunk dixit:
>> As an example, what happens if I debootstrap and deploy the
>> resulting filesytem to a large number of identical embedded
>> systems without entropy sources?

Thorsten> Just get into a habit of not doing so, for example by
Thorsten> modifying the image during each writing process.

I'm sorry, but modifying the image before each write is simply not
realistic.

My company has found that it's easy to get suppliers to deploy a static
image to the storage of appliances we're constructing during the
manufacturing process.
They do not have tools for modifying the image.  We do detect first boot
and do things like change filesystem UUIDs.
Mixing in any entropy we can obtain during the first boot is relatively
easy.  However, very quickly, we're going to need to do things like
generate ssh keys for management and generate a few other public keys.

Similar situations show up in cloud environments.  There you can use
virtio-rng or similar.

However, the fact is that when we design systems, we are constrained by
constraints placed by other parts of the process out of our control.
Delivering an image that is static and that will be deployed onto
multiple systems is something that does happen and it happens because
it's the best design tradeoff available.
It does have security implications, and in fact may decrease security of
random numbers overall.  On the other hand, it can increase security of
code integrity and tends to be associated with design methodologies that
create reproducible environments.

So, you can try and sweep static images under the rug, but all you're
doing is dsmissing people with real problems they need to solve.
It would be much more constructive to acknowledge that people will use
static images, discuss the security implications, solve the problems we
can solve, and document the residual security implications so our users
and the broader community are aware of our limitations.

--Sam

Bug#808293: freeradius stopped working after kernel upgrade

[Sam Hartman]

control: -1 severity important

I'm not sure what the best way to avoid freeradius being pulled out of
jessie is besides dropping the severity.
If tagging it wheezy and bringing the severity back up would work feel
free to do that.
Is anyone seeing this with jessie or is this a wheezy-only issue?

Bug#622146: This is broken for me.

[Sam Hartman]

 Rob == Rob Naccarato r...@naccy.org writes:

Rob This doesn't appear to be fixed to me. I get the same
Rob problems. I have even installed backported kernel
Rob (2.6.39-bpo.2-amd64) and nfs-utils (1:1.2.4-1~bpo60+1) and I
Rob still get these:

This requires fixes in krb5 and nfs-utils.
krb5 has been fixed, but nothing gets better until the nfs-utils fix.



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/tslobx7iq3f@mit.edu

Bug#622146: nfs-common: compatibility between squeeze and sid broken

[Sam Hartman]

It should be fixed in unstable by actually supporting the new enctypes.
While ncice, that rather misses the point.



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/tsl62k3tahb@mit.edu

Bug#622146: nfs-common: compatibility between squeeze and sid broken

[Sam Hartman]

 Adam == Adam D Barratt a...@adam-barratt.org.uk writes:


Adam The krb5 package was uploaded and I've (somewhat belatedly)
Adam marked it for acceptance at the next dinstall.  What's the
Adam status of the nfs-utils upload?

My guess is they were waiting for krb5.
Remember they have to increase build-depends for the krb5 you just
accepted.



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/tslvct7gcoa@mit.edu

Bug#622146: nfs-common: compatibility between squeeze and sid broken

[Sam Hartman]

I expect to get to the krb5 package in a day or so. I expect nfs-utils
will want to up its build-depends on krb5 to 1.8.3+dfsg-4squeeze2



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/tsld3gfpht8@mit.edu

Bug#622146: nfs-common: compatibility between squeeze and sid broken

[Sam Hartman]

 Philipp == Philipp Kern pk...@debian.org writes:

Philipp On Mon, Aug 01, 2011 at 01:34:34AM -0700, Steve Langasek wrote:
 On Tue, Jul 19, 2011 at 05:42:34PM -0400, Sam Hartman wrote:
  I don't have checkouts handy, but my strong suspicion is that if
 someone  is now passing in GSS_C_NT_HOSTBASED_SERVICE into
 gssd_acquire_cred and  there isn't an argument slot, you can
 leave it off.   gss_c_nt_hostbased_service has always been the
 default for gssd.
 
 Ok, thanks.  I've built packages of nfs-utils and krb5 using the
 referenced backported patches, and can confirm that I'm now able
 to connect successfully from an nfs-utils 1.2.4 client without
 having to set permitted_enctypes on the server.

Philipp Why is the nfs-utils patch needed again?  To be able to run
Philipp nfs-utils in squeeze with a newer kernel?

No.  The issue is that sid clients will ask a squeeze server to do
something the squeeze kernel can't handle.  However, rather than asking
the kernel you ask the nfs-utils userspace.  The squeeze krb5 can handle
the new encryption type and so it negotiates something, tries to stuff
it into the kernel, and doesn't even know how to do that.

The krb5 patch revises an existing API which allows userspace to tell
krb5 about the kernel capabilities to apply to the server as well as the
client.

the nfs-utils patch tells the server userspace code to call that
existing API which is only called on the client in squeeze.

The failure mode is that without both patches, squeeze servers fail to
work with sid clients running sid kernels.

--Sam



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/tslty9yup4w@mit.edu

Bug#622146: nfs-common: compatibility between squeeze and sid broken

[Sam Hartman]

If I get an ack from SRM i'll do the krb5 upload.



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/tsllivd472o@mit.edu

Bug#622146: nfs-common: compatibility between squeeze and sid broken

[Sam Hartman]

 Steve == Steve Langasek vor...@debian.org writes:

Steve Hi Sam, I've also run into this bug, in the context of
Steve preparing to update nfs-utils in Ubuntu for IPv6 support.  My
Steve NFS server is running squeeze, and updating causes the client
Steve and server to fail to negotiate as described.

Your nfs server is squeeze and your client was squeeze but is now more
than squeeze?

(substitute ubuntu releases with pre-ipv6 nfs-utils as appropriate for
squeeze?)

R24603 in MIT upstream subversion.

See attached.

I'm happy to interact with SRM for the krb5 side of it.  However, the
bug as reported didn't seem to be this one because the server involved
was older than squeeze.

so I didn't actually have any users rrequesting a solution to a problem
I knew how to solve.  If you have a problem that this krb5 patch and the
mentioned nfs-utils patch solve then we definitely should propose a
backport to SRM.  I'll be happy to prepare krb5 packages.


From 82affd78ac2c2b13bacf8e004f13f2d0dba5acea Mon Sep 17 00:00:00 2001
From: ghudson ghudson@dc483132-0cff-0310-8789-dd5450dbe970
Date: Tue, 25 Jan 2011 00:23:48 +
Subject: [PATCH] ticket: 6852
 subject: Make gss_krb5_set_allowable_enctypes work for the acceptor
 target_version: 1.9.1
 tags: pullup

With the addition of enctype negotiation in 1.7, a gss-krb5 acceptor
can choose an enctype for the acceptor subkey other than the one in
the keytab.  If the resulting security context will be exported and
re-imported by another gss-krb5 implementation (such as one in the
kernel), the acceptor needs a way to restrict the set of negotiated
enctypes to those supported by the other implementation.  We had that
functionality for the initiator already in the form of
gss_krb5_set_allowable_enctypes; this change makes it work for the
acceptor as well.


git-svn-id: svn://anonsvn.mit.edu/svn/krb5/trunk@24603 dc483132-0cff-0310-8789-dd5450dbe970
---
 src/lib/gssapi/krb5/accept_sec_context.c |9 +
 1 files changed, 9 insertions(+), 0 deletions(-)

diff --git a/src/lib/gssapi/krb5/accept_sec_context.c b/src/lib/gssapi/krb5/accept_sec_context.c
index 9d40f68..c3cb2f1 100644
--- a/src/lib/gssapi/krb5/accept_sec_context.c
+++ b/src/lib/gssapi/krb5/accept_sec_context.c
@@ -623,6 +623,15 @@ kg_accept_krb5(minor_status, context_handle,
 goto fail;
 }
 
+/* Limit the encryption types negotiated (if requested). */
+if (cred-req_enctypes) {
+if ((code = krb5_set_default_tgs_enctypes(context,
+  cred-req_enctypes))) {
+major_status = GSS_S_FAILURE;
+goto fail;
+}
+}
+
 if ((code = krb5_rd_req(context, auth_context, ap_req,
 cred-default_identity ? NULL : cred-name-princ,
 cred-keytab,
-- 
1.7.4.1

Bug#622146: nfs-common: compatibility between squeeze and sid broken

[Sam Hartman]

I don't have checkouts handy, but my strong suspicion is that if someone
is now passing in GSS_C_NT_HOSTBASED_SERVICE into gssd_acquire_cred and
there isn't an argument slot, you can leave it off.
gss_c_nt_hostbased_service has always been the default for gssd.



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/tslpql67xrp@mit.edu

Bug#622146: nfs-common: compatibility between squeeze and sid broken

[Sam Hartman]

OK, I have no clue nor really any interest in debugging DES.

There is a real bug here introduced in krb5 1.7 which added enctype
negotiation . I'd expect that to create some problems for sid clients
talking to squeeze servers.  There's a solution to that which involves
backporting the nfs-utils patch mentioned earlier in this bug to squeeze
and backporting a krb5 patch that depends on to squeeze.  I'm certainly
happy to backport the krb5 patch if the stable release managers approve.

However, that won't help you. I don't understand how you're seeing that
issue because the code that causes the problem is introduced into krb5
1.7 and lenny has krb5 1.6. If the server doesn't support the
negotiation feature, it is not used.



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/tsld3inywxb@mit.edu

Bug#622146: nfs-common: compatibility between squeeze and sid broken

[Sam Hartman]

Hi.
I was missing some context here.

My suspicion is that things will work
if you add
permitted_enctypes = des-cbc-crc
default_tgs_enctypes = des-cbc-crc
to the configuration of the nfs server

And make sure that the nfs principal on the NFS server has nothing but a
des-cbc-crc key in the KDC database.
That is
kadmin.local: getprinc nfs/machine_name
should only list DES keys.

If you satisfy all of these conditions then I *think* that a sid client
can connect to a squeeze server.

It may also work to make the following config changes on the client:

default_tgs_enctypes = des-cbc-crc

and no config changes on the server.


Clearly, this is all non-ideal.
Once we confirm what's going on, we can look into backporting some fixes
to this issue introduced into MIT Kerberos and nfs-utils.


--Sam



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/tslfwnk2nzb@mit.edu

Bug#622146: nfs-common: compatibility between squeeze and sid broken

[Sam Hartman]

 Luk == Luk Claes l...@debian.org writes:

Luk On 06/06/2011 05:37 PM, Alberto Gonzalez Iniesta wrote:
 Adding the following line in the [libdefaults] section of
 /etc/krb5.conf fixed the problem for me (tm), probably not the
 best solution, but works: permitted_enctypes = des-cbc-md5

Luk It's probably better to set enable_weak_crypto=yes, does that
Luk work?

Hi.
I think I gave Luk the wrong setting.
It's allow_weak_crypto = yes not enable_weak_crypto = yes.

You should not have to set permitted_enctypes.
Enabling weak_crypto and only setting the des-cbc-crc key with ktadd in
kadmin is supposed to be sufficient.

--Sam



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/tslsjrl6000@mit.edu

Re: openafs in etchnhalf

[Sam Hartman]

 Russ == Russ Allbery [EMAIL PROTECTED] writes:

Russ Rainer Dorsch [EMAIL PROTECTED] writes:
 is anybody taking care of the openafs modules which do not
 compile any more with the etchnhalf kernel?
 
 The openafs modules in backports.org do compile though with the
 etchnhalf kernel.

Russ I'm quite happy to upload new packages for etchnhalf, but
Russ I'm afraid they'd have to be just that -- packages of a
Russ newer upstream.  The upstream changes to support newer
Russ kernels are far too comprehensive for me to be able to
Russ isolate them and apply them separately, and the result would
Russ be poorly-tested and less stable than going to the current
Russ packages from Debian testing.
What about uploading an openafs-kernel source package that only produced 
openafs-modules-source?


That would at least isolate the change to the kernel module.


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