Bug#1065926: Moving python-docker 5.0.3-1 to Python 3.12 will result in breaking changes

[A. Karl Kornel]

Hello!

I came across this bug as I was writing up Ubuntu bug 2061929.  
Unfortunately, python-docker 5.0.3-1 will break if Python3 moves to 
3.12.  There are at least two different issues:


• python-docker 5.0.3 relies on code from distutils, at runtime.  The 
workaround for this is to rewrite the code, or to instead rely on 
python3-setuptools.


• python-docker uses the requests & urllib3 modules in ways that break 
in newer versions.  The breakage is in how the docker module talks to 
local Docker daemons through a UNIX socket.  The only way to resolve 
this is a code change.


There may be other breakages with python-docker 5.x and Python 3.12; I 
cannot say for certain.


I came across this with Ubuntu 24.04, because they moved python3 to 
3.12.  More details, along with possible patches, can be found in 
https://bugs.launchpad.net/ubuntu/+source/python-docker/+bug/2061929


--
~ Karl Kornel

Bug#907536: Update fstab template & docs to mention systemctl daemon-reload

[Karl Kornel]

Package: mount
Version: 2.25.2-6
Severity: wishlist
Tags: d-i


Hello!

I have a kindof-weird request, related to systemd and the documentation around 
/etc/fstab.  I'd like to request that the stock /etc/fstab file include a note 
to run `systemctl daemon-reload` if you make changes to the file, but do not 
reboot afterwards.

As has been mentioned in https://github.com/systemd/systemd/issues/7291 (among 
other places), when systemd is started during system boot—and when the daemon 
is reloaded with `systemctl daemon-reload`—generators (including, but not 
limited to, systemd-fstab-generator(8)) read /etc/fstab and generate unit files 
appropriately.  If the sysadmin modifies /etc/fstab, but does not reboot, 
things may not work as expected.  systemd-fstab-generator(8) makes an reference 
to systemd.swap(5), but our group has also experienced weirdnesses with NFS 
mounts, particularly when we're using NFSv4 and the krb5 security types, which 
require various rpc services be started before the mount can take place.

Since people (including, most of the time, me!) forget about the link between 
system and /etc/fstab, I would like to request that a short note be placed in 
various places related to the fstab file, saying that, if the system isn't 
going to be rebooted, asking that at least `systemctl daemon-reload` after 
making any changes.

I can think of three places in Debian where it would be worth mentioning this:

• The /etc/fstab file generated during installation (that's why I added the 
`d-i` tag).
• The fstab(5) man page.
• The examples in the /usr/share/doc/mount/examples directory.

I did some searching around outside of Debian, and I found that RHEL made a 
similar change, except they modified their administrator guides.  The change 
was made earlier this year, in 
https://bugzilla.redhat.com/show_bug.cgi?id=1566088

If you have any questions about my request, please don't hesitate to reach out! 

-- 
~ A. Karl Kornel
Stanford Research Computing Center
University IT, Stanford University

Bug#886806: intel-microcode: New version 20180108 published

[Karl Kornel]

Package: intel-microcode
Version: 3.20171215.1
Severity: grave
Tags: security

Hello!

In the ancient past (last week…), Mr. Holschuh mentioned, “I expect an official 
release from Intel soon, hopefully with updates for everything.”.

Well, it looks like there has been a release!  The data file version is 
20180108.

The microcode download page is 
https://downloadcenter.intel.com/download/27431/Linux-Processor-Microcode-Data-File

--
A. Karl Kornel | System Administrator
Research Computing | Stanford University

Bug#851103: slurm account's UID conflicts with a user -- Allow setting a different ID at install time

[Karl Kornel]

Source: slurm-llnl
Version: 16.05.8-1
Severity: wishlist
Tags: patch

Hello!

We are in the process of setting up a new cluster, which will be available to 
many Stanford people.  As part of setting it up, I discovered that UID 64030 
(which is normally used for SLURM) is already in use by a previous student!  
The student has graduated, so the UID is no longer active, but if the student 
ever comes back, then he will get that UID again, which will cause problems.

(By the way, I say that because the cluster uses central LDAP for account 
information, so giving him a new UID would be difficult.)

The easiest thing to do would be to make a local modification to the existing 
preinst script, replacing “64030” with a different UID (I already have one 
allocated).  But, I think the better way to do it is to make the preinst script 
prompt the user for an ID, and then use that!  This also means that I can offer 
the script for you to take upstream, which is what I’m doing now!

Here’s how things work:

1) If an account called “slurm” already exists, and a group called “slurm” 
already exists, then the package install takes place.  This is actually a break 
from previous behavior.
2) Ask the user to provide an ID.  If no ID is provided (because the user 
cleared the field, because a noninteractive install is happening, etc.), then 
default to ID 64030.
3) Check for non-numeric characters in the response.  If any are found, notify 
the user and mark an error.
4) Check if the ID is already in use, either for a user or a group.  If the ID 
is in use, notify the user and mark an error.
5) If no errors were found, go to the next step.  If there have been three 
failed attempts, then error out the install/upgrade.  Otherwise, increase the 
priority of the query, and go back to Step 2.
6) Add the user/group, as a system account, and without a home directory.

As I mentioned, the biggest change between the original script, and my 
proposal, is that two previous checks have been removed:

* There was a check to see if the slurm account had a home directory; if it 
did, then (under certain conditions) the home directory is changed to 
“/nonexistent”.
* There was a check to see if the existing slurm account had UID and GID 64030.

Both of those checks were removed under the idea that, if an account already 
exists, it should not be messed with.

I would really appreciate it if people could try out this change.  I have tried 
this many times on the new cluster (which runs Ubuntu Xenial), but this patch 
adds a lot of complexity, so I think other people should try it before it gets 
applied (assuming you are willing to take the patch).

NOTE: This patch requires that you have already applied the patches from bug 
850891.  I definitely think bug 850891 should be resolved before this one, 
because that bug moves the same code from three preinst scripts into one.

Finally, it is possible for the text to be translated!  If anyone is interested 
in making translations, information is available here: 
http://www.fifi.org/doc/debconf-doc/tutorial.html#AEN34 (see the section called 
“Localizing the templates file”).

I look forward to any comments that you have.  Thank you very much!

--
A. Karl Kornel | System Administrator
Research Computing | Stanford University
+1 (650) 736-9327
 



0001-Allow-custom-ID-for-slurm-user.patch
Description: 0001-Allow-custom-ID-for-slurm-user.patch

Bug#850891: Additional patch, to cover slurmdbd's duplicate code

[Karl Kornel]

Hi Rémi, (I hope the é comes through the email properly!)

If I would play devil’s advocate, then I would say this: “An action like this 
seems inappropriate to place into a package that does not clearly indicate why 
it is needed.  Instead, you should create a slurm-common package, and have the 
user creation happen there.”

I would be OK with that: I am fine putting together a patch to create a 
“slurm-common” package that does the user creation.  Some common documentation 
could also be moved to that package.  But, I did not know if that was 
appropriate, so I submitted the simpler change first!

~ Karl

On 1/11/17, 1:21 AM, "Rémi Palancher"  wrote:

FWIW, we took the same approach in our EDF-specific packages:

https://github.com/edf-hpc/slurm-llnl

It works fine for us so far!

I just don't remember why we didn't propose the patch back into Debian 
official packages though :(

Best,
Rémi

Bug#850891: Additional patch, to cover slurmdbd's duplicate code

[Karl Kornel]

Hello!

I have a second patch, to make another similar change to my first patch.

I noticed that slurmdbd’s preinst script is doing the same user-creation.  
Although slurmdbd does not directly relate to slurm-client, both slurm-client 
and slurmdbd depend directly on the slurm-wlm-basic-plugins package.  So, my 
second patch does two things:

1) Move the preinst script from the slurm-client package to the 
slurm-wlm-basic-plugins package.
2) Remove the duplicate user-creation code from slurmdbd.

Again, please let me know if I am missing anything!

--
A. Karl Kornel | System Administrator
Research Computing | Stanford University
+1 (650) 736-9327



0002-Remove-duplicate-slurmdbd-user-creation-preinst.patch
Description: 0002-Remove-duplicate-slurmdbd-user-creation-preinst.patch

Bug#850891: slurmctld depends on slurm-client; both have the same preinst user-creation code

[Karl Kornel]

Source: slurm-llnl
Version: 16.05.8-1
Severity: wishlist
Tags: patch

Hello!

I was looking around in the preinst scripts for SLURM, and I noticed that the 
slurm user-creation code exists in the slurmctld.preinst script, and also the 
slurm-client.preinst script.  Since the slurmctld package depends on the 
slurm-client package, I am wondering if one is a duplicate of the other?

I have attached a patch, which removes the user-creation code from slurmctld’s 
preinst script.  Would you mind having a look at it, and let me know if I am 
missing something?

Thank you very much for the consideration!

--
A. Karl Kornel | System Administrator
Research Computing | Stanford University
+1 (650) 736-9327


0001-Remove-duplicate-slurmctld-user-creation-preinst.patch
Description: 0001-Remove-duplicate-slurmctld-user-creation-preinst.patch

Bug#828549: SLURM OpenSSL 1.1 issue - Patch to disable OpenSSL support until upstream fixes

[Karl Kornel]

Hi Mehdi,

That’s awesome!  Changing the code is definitely preferable, as long as the 
code works with older versions of MySQL.

To check this, I tried building SLURM in a Jessie COWbuilder installation.  In 
order to test, one dependency had to be changed in the control file: Change 
“default-libmysqlclient-dev” to “libmysqlclient-dev”.  The test took place with 
OpenSSL 1.0.1 (specifically, OpenSSL source package version 1.0.1t-1+deb8u3).

I also tried building for Ubuntu Xenial (again using COWbuilder), which has 
OpenSSL package version 1.0.2g-1ubuntu4.5.  This also required changing the 
control file, as with Jessie.

I did not test in Wheezy, because there are other dependency issues (like a 
minimum debhelper version) that would need to be changed.  I also did not test 
on Ubuntu Trusty.

Both builds were able to complete.  You can download the results here:

Debian Jessie (16.05.6-2~sbp81+1, for jessie-backports): 
https://stanford.box.com/s/tehux7vh57w75k9sfjjpt0s0sjiugor1
Ubuntu Xenial (16.05.6-2~sbp16.04+1, for xenial-backports: 
https://stanford.box.com/s/opnjc8ab5dqzrwwp3qi2rutvfa1mu51l

(I’ll keep each links working until the bug is fixed upstream)

“sbp” stands for “Stanford Backport”, since this isn’t an official backport.  
Each .tar.gz has all of the stuff you would need to upload to a repository of 
your own, so you can either install the .deb files manually, or you could use 
the .changes file to upload to a repository of your own.  The versions are 
numbered so that when Gennaro releases 16.05.6-2 (or something later), that 
will take precedence over the ones I built.

Unfortunately, I don’t think your patch would be able to work directly, because 
the quilt build process requires that the original code be untouched; all of 
the changes to source have to be Quilt patches.  So, I’ve taken your patch and 
converted it into a quilt patch!  I’m attaching to this email a Git commit 
patch that creates the quilt patch, and updates the patch series list.

So, here are the next steps that I would suggest:

* Mehdi, you should go to https://bugs.schedmd.com, create an account, open bug 
3226, and attach your patch (the original one you sent me).  I’m asking you to 
do it because you are the author, so you should get the credit for it.
* Anyone who wants to test on Jessie or Xenial can use one of the builds that I 
made.
* In the meantime, if Gennaro decides to go forward with your code, he could 
use the quilt patch I’ve attached here. 

Thanks much for the patch!

~ Karl 



0001-Add-support-for-OpenSSL-1.1.patch
Description: 0001-Add-support-for-OpenSSL-1.1.patch

Bug#828549: SLURM OpenSSL 1.1 issue - Patch to disable OpenSSL support until upstream fixes

[Karl Kornel]

forwarded 828549 https://bugs.schedmd.com/show_bug.cgi?id=3226
tags 828549 + patch
thanks

Hello!

It looks like even the latest SLURM Debian package, 16.05.6-1, still has this 
issue. I tested with OpenSSL package version 1.1.0b-2, building on a sid 
COWbuilder.

The issue is being tracked upstream at this URL:

https://bugs.schedmd.com/show_bug.cgi?id=3226

The bug was filed on Oct. 31, and acknowledged on Nov. 1.

SLURM only uses OpenSSL in one place: To create “job step credentials”.  
However, this is not the default: the default is to have MUNGE create those 
credentials.

Since OpenSSL is only used in one place, and that’s not even as the default, I 
have created a Quilt patch which removes OpenSSL from the build entirely.  
Unfortunately, it’s not enough to change how we run ./configure; if the 
configure script sees an OpenSSL installation, it will use it, so I have to 
completely remove the test for OpenSSL, as well as the Makefile.am file that 
would trigger the compilation of OpenSSL-using code.

The same Quilt patch also updates the configuration builder HTML, to remove the 
OpenSSL option.

Finally, I update the the control file, README files, and the init scripts 
(removing the OpenSSL-related checks).

All of these changes are in a series of two Git patch files, which are attached.

--
A. Karl Kornel | System Administrator
Research Computing | Stanford University
+1 (650) 736-9327



0002-Update-Debian-files-for-OpenSSL-removal.patch
Description: 0002-Update-Debian-files-for-OpenSSL-removal.patch


0001-Add-quilt-patch-to-disable-OpenSSL.patch
Description: 0001-Add-quilt-patch-to-disable-OpenSSL.patch

Bug#783779: Moving bug to ifupdown

[Karl Kornel]

reassign 783779 ifupdown
retitle 783779 Fresh system interface gets allow-hotplug; doesn't wait 
for full ifup

reopen 783779
found 783779 0.7.53.1
tags 783779 jessie d-i
noowner 783779
thankyou

Since this apparently isn't an issue with systemd, I'm moving this to 
ifupdown.  I hope that's the right place for it!


Tagging as jessie because I didn't see this problem in wheezy, and also 
tagging as d-i because the problem occurred on a freshly-installed system.


I thought this was related to bug 766943, but that's already been closed 
in an earlier version.  Maybe this is related to bug 752919 or 550014? 
Unfortunately, I don't know enough to say either way.


~ Karl


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

Bug#784568: Maybe in the nouveau package?

[Karl Kornel]

reassign 784568 xserver-xorg-video-nouveau
thankyou

Hello!

I'm updating this bug to confirm that the issue is still happening, but 
once I switched to the binary nVidia drivers (via the nvidia-driver 
package), the problem stopped.  So, this definitely seems like something 
related to nouveau.  As a result, I'm moving the bug.


I checked out bug #698296, and this might be related, but that bug's log 
doesn't show any nouveau_exa_upload_to_screen:380 or 
nouveau_exa_download_from_screen:295 messages.


--
~ A. Karl Kornel, (650) 736-9327
Authentication  Collaboration Solutions
University IT, Stanford University


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

Bug#783779: systemd: system-ifup.slice start completes before interface is up

[Karl Kornel]

On 4/29/2015 5:43 PM, Michael Biebl wrote:

snip

Once /etc/init.d/networking has completed, the network is considered up.


Ah, OK.  Sorry about that!  I thought systemd had taken over that 
functionality.



snip

Can you attach the output of
systemctl status networking.service
systemctl status ifup@eth0.service


Attached as networking.service-status.txt and 
i...@eth0.service-status.txt.



(you need to run that as root).
Does it help, if you switch allow-hotplug eth0 to auto eth0 in
/etc/network/interfaces?


Yes it does!  If I switch to auto eth0, then everything will correctly 
wait for the network connection to come up before continuing to boot.


I have attached post-interface-change-networking.service-status.txt to 
show the output of `systemctl status networking.service` after I changed 
from allow-hotplug eth0 to auto eth0.


~ Karl
â—� ifup@eth0.service - ifup for eth0
   Loaded: loaded (/lib/systemd/system/ifup@.service; static)
   Active: active (exited) since Thu 2015-04-30 10:52:04 PDT; 2min 28s ago
  Process: 710 ExecStart=/sbin/ifup --allow=hotplug %I (code=exited, 
status=0/SUCCESS)
 Main PID: 710 (code=exited, status=0/SUCCESS)

Apr 30 10:52:04 blargh.stanford.edu systemd[1]: Started ifup for eth0.
Apr 30 10:52:04 blargh.stanford.edu dhclient[721]: Internet Systems Consortium 
DHCP Client 4.3.1
Apr 30 10:52:04 blargh.stanford.edu dhclient[721]: Copyright 2004-2014 Internet 
Systems Consortium.
Apr 30 10:52:04 blargh.stanford.edu dhclient[721]: All rights reserved.
Apr 30 10:52:04 blargh.stanford.edu dhclient[721]: For info, please visit 
https://www.isc.org/software/dhcp/
Apr 30 10:52:04 blargh.stanford.edu dhclient[721]: 
Apr 30 10:52:04 blargh.stanford.edu ifup[710]: Internet Systems Consortium DHCP 
Client 4.3.1
Apr 30 10:52:04 blargh.stanford.edu ifup[710]: Copyright 2004-2014 Internet 
Systems Consortium.
Apr 30 10:52:04 blargh.stanford.edu ifup[710]: All rights reserved.
Apr 30 10:52:04 blargh.stanford.edu ifup[710]: For info, please visit 
https://www.isc.org/software/dhcp/
Apr 30 10:52:04 blargh.stanford.edu dhclient[721]: Listening on 
LPF/eth0/14:cc:20:00:20:36
Apr 30 10:52:04 blargh.stanford.edu dhclient[721]: Sending on   
LPF/eth0/14:cc:20:00:20:36
Apr 30 10:52:04 blargh.stanford.edu dhclient[721]: Sending on   Socket/fallback
Apr 30 10:52:04 blargh.stanford.edu dhclient[721]: DHCPDISCOVER on eth0 to 
255.255.255.255 port 67 interval 5
Apr 30 10:52:04 blargh.stanford.edu ifup[710]: Listening on 
LPF/eth0/14:cc:20:00:20:36
Apr 30 10:52:04 blargh.stanford.edu ifup[710]: Sending on   
LPF/eth0/14:cc:20:00:20:36
Apr 30 10:52:04 blargh.stanford.edu ifup[710]: Sending on   Socket/fallback
Apr 30 10:52:04 blargh.stanford.edu ifup[710]: DHCPDISCOVER on eth0 to 
255.255.255.255 port 67 interval 5
Apr 30 10:52:09 blargh.stanford.edu dhclient[721]: DHCPDISCOVER on eth0 to 
255.255.255.255 port 67 interval 9
Apr 30 10:52:09 blargh.stanford.edu ifup[710]: DHCPDISCOVER on eth0 to 
255.255.255.255 port 67 interval 9
Apr 30 10:52:09 blargh.stanford.edu dhclient[721]: DHCPREQUEST on eth0 to 
255.255.255.255 port 67
Apr 30 10:52:09 blargh.stanford.edu dhclient[721]: DHCPOFFER from 171.64.18.1
Apr 30 10:52:09 blargh.stanford.edu ifup[710]: DHCPREQUEST on eth0 to 
255.255.255.255 port 67
Apr 30 10:52:09 blargh.stanford.edu ifup[710]: DHCPOFFER from 171.64.18.1
Apr 30 10:52:09 blargh.stanford.edu dhclient[721]: DHCPACK from 171.64.18.1
Apr 30 10:52:09 blargh.stanford.edu ifup[710]: DHCPACK from 171.64.18.1
Apr 30 10:52:09 blargh.stanford.edu dhclient[721]: bound to 171.64.19.50 -- 
renewal in 81898 seconds.
Apr 30 10:52:09 blargh.stanford.edu ifup[710]: bound to 171.64.19.50 -- renewal 
in 81898 seconds.
â—� networking.service - LSB: Raise network interfaces.
   Loaded: loaded (/etc/init.d/networking)
  Drop-In: /run/systemd/generator/networking.service.d
   └─50-insserv.conf-$network.conf
/lib/systemd/system/networking.service.d
   └─network-pre.conf
   Active: active (exited) since Thu 2015-04-30 10:52:04 PDT; 38s ago
  Process: 627 ExecStart=/etc/init.d/networking start (code=exited, 
status=0/SUCCESS)

Apr 30 10:52:03 blargh.stanford.edu ntpdate[690]: Can't find host 
time-a.stanford.edu: Name or service not known (-2)
Apr 30 10:52:04 blargh.stanford.edu networking[627]: Configuring network 
interfaces...done.
Apr 30 10:52:04 blargh.stanford.edu systemd[1]: Started LSB: Raise network 
interfaces..
● networking.service - LSB: Raise network interfaces.
   Loaded: loaded (/etc/init.d/networking)
  Drop-In: /run/systemd/generator/networking.service.d
   └─50-insserv.conf-$network.conf
/lib/systemd/system/networking.service.d
   └─network-pre.conf
   Active: active (running) since Thu 2015-04-30 10:56:38 PDT; 1min 4s ago
  Process: 1261 ExecStop=/etc/init.d/networking stop (code=exited, 
status=0/SUCCESS)
  Process: 1355 ExecStart=/etc/init.d/networking start (code=exited, 
status=0/SUCCESS)
   CGroup: /system.slice/networking.service
   

Bug#783837: nvidia-driver: Driver incompatible with UEFI? Can we conflict with grub-efi-amd64?

[Karl Kornel]

Package: nvidia-driver
Version: 340.65-2
Severity: important
Tags: upstream

Hello!

I have a newly-build (built from scratch) amd64 jessie system, built on UEFI, 
but it looks like the nVidia driver is not currently compatible with UFEI 
systems.

In my case, the issue manifested as not being able to switch to any virtual 
consoles after X started.  Before X starts, I am able to see boot messages 
etc..  Once X starts, it works fine, but if I try to switch to any virtual 
consoles, I hear a beep and the display goes to sleep.

Some searching around lead me to the following forum post:

https://devtalk.nvidia.com/default/topic/827139/linux/uefi-nvidia-vga-console-complaints-/

I get the same error (Your system is not currently configured to drive a VGA 
console) that is described in the forum, so I am thinking that reinstalling 
onto a BIOS system will fix the problem for me.

Would it be possible to make the nvidia-driver package conflict with the 
grub-efi-amd64 and grub-efi-ia32 packages, until the nVidia releases a 
UEFI-compatible driver?

Please let me know if I can provide any additional information.  Thanks very 
much!

-- Package-specific info:
uname -a:
Linux blargh.stanford.edu 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt9-3~deb8u1 
(2015-04-24) x86_64 GNU/Linux

/proc/version:
Linux version 3.16.0-4-amd64 (debian-ker...@lists.debian.org) (gcc version 
4.8.4 (Debian 4.8.4-1) ) #1 SMP Debian 3.16.7-ckt9-3~deb8u1 (2015-04-24)

/proc/driver/nvidia/version:
NVRM version: NVIDIA UNIX x86_64 Kernel Module  340.65  Tue Dec  2 09:50:34 PST 
2014
GCC version:  gcc version 4.8.4 (Debian 4.8.4-1) 

lspci 'VGA compatible controller [0300]':
00:02.0 VGA compatible controller [0300]: Intel Corporation Xeon E3-1200 v3 
Processor Integrated Graphics Controller [8086:041a] (rev 06) (prog-if 00 [VGA 
controller])
Subsystem: Dell Device [1028:05a6]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- TAbort- 
MAbort- SERR- PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 47
Region 0: Memory at f740 (64-bit, non-prefetchable) [size=4M]
Region 2: Memory at d000 (64-bit, prefetchable) [size=256M]
Region 4: I/O ports at f000 [size=64]
Capabilities: access denied
Kernel driver in use: i915

01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GF119 [NVS 310] 
[10de:107d] (rev a1) (prog-if 00 [VGA controller])
Subsystem: NVIDIA Corporation Device [10de:094e]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- 
MAbort- SERR- PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 51
Region 0: Memory at f600 (32-bit, non-prefetchable) [size=16M]
Region 1: Memory at e000 (64-bit, prefetchable) [size=128M]
Region 3: Memory at e800 (64-bit, prefetchable) [size=32M]
Region 5: I/O ports at e000 [size=128]
[virtual] Expansion ROM at f700 [disabled] [size=512K]
Capabilities: access denied
Kernel driver in use: nvidia

dmesg:
[0.00] AGP: No AGP bridge found
[0.00] AGP: Checking aperture...
[0.00] AGP: No AGP bridge found
[0.307659] vgaarb: device added: 
PCI::00:02.0,decodes=io+mem,owns=mem,locks=none
[0.307662] vgaarb: setting as boot device: PCI::01:00.0
[0.307663] vgaarb: device added: 
PCI::01:00.0,decodes=io+mem,owns=io+mem,locks=none
[0.307664] vgaarb: loaded
[0.307665] vgaarb: bridge control possible :01:00.0
[0.307665] vgaarb: no bridge control possible :00:02.0
[0.584556] Linux agpgart interface v0.103
[   42.412702] [drm] Replacing VGA console driver
[   42.436212] vgaarb: device changed decodes: 
PCI::00:02.0,olddecodes=io+mem,decodes=none:owns=none
[   42.988317] snd_hda_intel :01:00.1: Handle VGA-switcheroo audio client
[   43.579231] nvidia: module license 'NVIDIA' taints kernel.
[   43.583945] vgaarb: device changed decodes: 
PCI::01:00.0,olddecodes=io+mem,decodes=none:owns=none
[   43.584140] [drm] Initialized nvidia-drm 0.0.0 20130102 for :01:00.0 on 
minor 1
[   43.584144] NVRM: loading NVIDIA UNIX x86_64 Kernel Module  340.65  Tue Dec  
2 09:50:34 PST 2014
[   43.700298] input: HDA NVidia HDMI/DP,pcm=3 as 
/devices/pci:00/:00:01.0/:01:00.1/sound/card2/input15
[   43.700370] input: HDA NVidia HDMI/DP,pcm=7 as 
/devices/pci:00/:00:01.0/:01:00.1/sound/card2/input16
[   56.333741] nvidia :01:00.0: irq 51 for MSI/MSI-X
[   56.871733] NVRM: Your system is not currently configured to drive a VGA 
console
[   56.871735] NVRM: on the primary VGA device. The NVIDIA Linux graphics driver
[   56.871736] NVRM: requires the use of a text-mode VGA console. Use of other 
console
[  

Bug#779368: Bug exists in upstream (bug #655074) -- Workaround is to enable SSL

[Karl Kornel]

Hello!

I did some searching upstream, and it looks like this is upstream bug
#655074.  I found that this issue still exists in the latest version of
upstream (version 38.0a2), and I also found that turning on SSL solves
the problem.  At least, I think it solves the problem, because debug
messages show Icedove moving on to executing a search.  The search
doesn't work, but I think that's because of something else.

So, the workaround for this issue (including in Icedove) is to use SSL
for the LDAP connection at the same time that you are using GSSAPI.  Of
course, this probably won't work for everyone.

Anyway, all my notes have been added to the upstream bug!

~ Karl


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

Bug#779364: pan: Crash when opening article with layered attachments

[Karl Kornel]

 On Mar 1, 2015, at 12:37 AM, Dominique Dumont d...@debian.org wrote:
 
 snip
 
 Could you please follow up on this bug to answer any question upstream may 
 have ? 

Hi Dominique,

Certainly!  I have CCed myself on the bug, and will watch for any questions.

~ Karl


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

Bug#779368: icedove: LDAP and GSSAPI silently failing with protocol violation

[Alfred Karl Kornel]

Package: icedove
Version: 31.4.0-1~deb7u1
Severity: normal

Hello!

I am having an issue with icedove and LDAP/GSSAPI.

I am trying to connect Icedove to our organization's LDAP server.  In order to 
get access to non-public information (like phone numbers and email addresses), 
I need to use GSSAPI for authentication (simple binding is not supported).

I am able to do GSSAPI authentication with the `ldapsearch` command, so I know 
that my Kerberos credentials are OK.

I am attaching a packet capture, showing the attempted bind, and the failure.  
Wireshark reports that the bind is failing with the following error:

generic failure: protocol violation: client requested invalid layer

Please let me know if you need any more info!


-- System Information:
Debian Release: 7.8
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/bash

Versions of packages icedove depends on:
ii  debianutils   4.3.2
ii  fontconfig2.9.0-7.1
ii  libasound21.0.25-4
ii  libatk1.0-0   2.4.0-2
ii  libc6 2.13-38+deb7u8
ii  libcairo2 1.12.2-3
ii  libdbus-1-3   1.6.8-1+deb7u6
ii  libdbus-glib-1-2  0.100.2-1
ii  libevent-2.0-52.0.19-stable-3+deb7u1
ii  libffi5   3.0.10-3
ii  libfontconfig12.9.0-7.1
ii  libfreetype6  2.4.9-1.1
ii  libgcc1   1:4.7.2-5
ii  libgdk-pixbuf2.0-02.26.1-1
ii  libglib2.0-0  2.33.12+really2.32.4-5
ii  libgtk2.0-0   2.24.10-2
ii  libhunspell-1.3-0 1.3.2-4
ii  libpango1.0-0 1.30.0-1
ii  libpixman-1-0 0.26.0-4+deb7u1
ii  libsqlite3-0  3.7.13-1+deb7u1
ii  libstartup-notification0  0.12-1
ii  libstdc++64.7.2-5
ii  libx11-6  2:1.5.0-1+deb7u1
ii  libxext6  2:1.3.1-2+deb7u1
ii  libxrender1   1:0.9.7-1+deb7u1
ii  libxt61:1.1.3-1+deb7u1
ii  psmisc22.19-1+deb7u1
ii  zlib1g1:1.2.7.dfsg-13

Versions of packages icedove recommends:
ii  myspell-en-us [myspell-dictionary]  1:3.3.0-4

Versions of packages icedove suggests:
ii  fonts-lyx 2.0.3-3
ii  libglib2.0-0  2.33.12+really2.32.4-5
ii  libgssapi-krb5-2  1.10.1+dfsg-5+deb7u3

-- no debconf information


icedove_packets.pcap
Description: application/vnd.tcpdump.pcap

Bug#777549: Issue also appears in 6.7p1-3 on sid

[Karl Kornel]

found 777549 openssh/1:6.7p1-3
thank you


Hello!

It looks to me like this issue also exists in the latest version, on sid.

I checked this by grabbing openssh_6.7p1.orig.tar.gz and 
openssh_6.7p1-3.debian.tar.xz off of packages.debian.org, and then 
applying gssapi.patch to the source.


I see that the GSSAPI key-exchange algorithms are added to the head of 
the proposal in sshconnect2.c lines 170-188.  Then, on lines 222-223, 
the client checks to see if any key-exchange algorithms were specified 
as options; if they were, the existing contents of the proposal get 
blown away.


I was wondering if the block of code from lines 170-188 could be merged 
into the #ifdef GSSAPI block that exists at lines 227-236.  Those 
lines appear after the key-exchange algorithms proposal gets potentially 
blown away, so I think it would be safe to change at that point.


I'm sorry that I'm unable to build and test right now, but I don't have 
any hardware (physical or virtual) that I can test on.  If that changes, 
I'll let you know!


~ Karl


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

Bug#777549: openssh-client: Setting KexAlgorithms disables GSSAPIKeyExchange

[Alfred Karl Kornel]

Package: openssh-client
Version: 1:6.0p1-4+deb7u2
Severity: normal

Good morning!

I am reporting an issue that I have discovered in Debian's OpenSSH package: 
It appears that setting GSSAPIKeyExchange overrides the KexAlgorithms setting.

The group I am in (Authentication  Collaboration Solutions, part of Stanford
IT) relies heavily on Kerberos: It is our policy to not allow our group 
members to enter passwords in remote sites, with few exceptions.

As a new employee in our group, I have been updating our internal 
documentation that documents how we use SSH.  Part of that includes making a 
standard OpenSSH client configuration for other new employees to use.  One of 
the items in this configuration is to enable GSSAPI key exchange, and also to 
disable certain key-exchange algorithms.

The problem I found is, if I explicitly set KexAlgorithms, that essentially 
turns off GSSAPIKeyExchange.  Looking at debug logs, OpenSSH does not even try 
to use GSSAPI key exchange, which makes me think that setting KexAlgorithms 
somehow overrides whatever changes GSSAPIKeyExchange is trying to make.

I'm going to try reproducing this problem in openssh 6.7p1-3, just to make 
sure the problem still exists there; I'll report back when I'm able to 
reproduce.


-- System Information:
Debian Release: 7.8
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-4-amd64 (SMP w/1 CPU core)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/bash

Versions of packages openssh-client depends on:
ii  adduser3.113+nmu3
ii  debconf [debconf-2.0]  1.5.49
ii  dpkg   1.16.15
ii  libc6  2.13-38+deb7u7
ii  libedit2   2.11-20080614-5
ii  libgssapi-krb5-2   1.10.1+dfsg-5+deb7u2
ii  libselinux12.1.9-5
ii  libssl1.0.01.0.1e-2+deb7u14
ii  passwd 1:4.1.5.1-1
ii  zlib1g 1:1.2.7.dfsg-13

Versions of packages openssh-client recommends:
ii  openssh-blacklist0.4.1+nmu1
ii  openssh-blacklist-extra  0.4.1+nmu1
ii  xauth1:1.0.7-1

Versions of packages openssh-client suggests:
pn  keychain  none
pn  libpam-sshnone
pn  monkeysphere  none
pn  ssh-askpass   none

-- Configuration Files:
/etc/ssh/ssh_config changed [not included]

-- no debconf information


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

Bug#777549: openssh-client: Setting KexAlgorithms disables GSSAPIKeyExchange

[Karl Kornel]

Hello!

Since three replies came in at once (from my perspective), I'm doing one 
email.


On 2/9/2015 6:53 PM, Russ Allbery wrote:

Alfred Karl Kornel akkor...@stanford.edu writes:


I am reporting an issue that I have discovered in Debian's OpenSSH
package:  It appears that setting GSSAPIKeyExchange overrides the
KexAlgorithms setting.


Yeah, I would expect this, since GSS-API key exchange *is* a key exchange
mechanism.  If you do GSS-API key exchange, that completely replaces the
normal ssh public key negotiation, since it instead uses Kerberos to
negotiate the encrypted channel with the server.


That's what I thought, but as I understood the patch, it seems that 
turning on GSSAPIKeyExchange is just working out what GSSAPI 
key-exchange methods are supported, and then prepending those to the 
default list of key-exchange algorithms (and then adding null at the 
end).  That way, if the server doesn't support GSSAPI key exchange, the 
client is able to fall back to one of the more traditional methods.



Is the problem that you want to be able to control the key exchange
algorithms that the server falls back on if GSS-API key exchange fails
(if, for example, the client doesn't support it)?


Yup, that's correct!


If you're happy to require all clients to do GSS-API key exchange, you can
just delete all public keys for the server.  They're not used at all with
GSS-API, and that will prevent the server from negotiating any public key
exchange mechanism as a fallback.


The problem with that is, if I do that I'm putting all of my faith that 
GSSAPI will be working on both ends.  I don't want to trust in GSSAPI 
not working if something goes wrong on my client.  For example, if 
Kerberos is messed up on my workstation, I could still securely log in 
to the server, I'd just have a coworker log in and get the host key 
fingerprint for me.



On 2/9/2015 7:09 PM, Christoph Anton Mitterer wrote: On Mon, 2015-02-09 
at 18:53 -0800, Russ Allbery wrote:

snip

 Guess the main problem here is, that GSSAPI Kex should have become
 configurable via KexAlgorithms and not via a separate option.
 OTOH, The GSSAPI Kex is really quite special (IIRC the client
 authentication phase also happens during the kex then).

Well, I'm find with just having GSSAPIKeyExchange prepend all of the 
GSSAPI methods to the start of my chosen KexAlgorithms list.  You could 
easily get very complicated here, such as by having SSH recognize things 
like gssapi-group1 or gssapi-group-exchange, and then replace with 
the appropriate expansions (after working out the OIDs).


snip

 Anyway,... best chances are if Alfred would report this to upstream
 (which is here not OpenSSH, but the maintainers of the patchset).

I was wondering if this would need to go upstream, but from what I 
understood, bug reporters are supposed to report bugs directly to Debian.


Could you please tell me where upstream is in this case?  I did some 
quick searching, but the one place I found hadn't been updated in a few 
years.


Once I know where to send the bug report, I'm happy to file it upstream!


On 2/9/2015 7:18 PM, Russ Allbery wrote:
snip

 That's also true, particularly since it sounded from the second message
 like he has a proposed fix.  However, it's worth noting that any fix for
 this wouldn't make it into jessie at this point, so you'll want to be
 thinking about workarounds or planning on backporting a later version.

Yeah, it's really depressing, but I guess that's what's gonna happen. 
Could it possibly make it into jessie-backports, or is that also too 
much to hope for?


Either way, thanks very much for the quick reply to my bug report!

~ Karl


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

Bug#339841: Additional Information for Bug#339841

[A. Karl Kornel]

Hello.  I have some additional information to add to this bug.

	First, I tried to check out a new working copy into a different  
directory (the repository and working copy are still on the same  
system here).  Making the changes to the newly-checked-out copy can  
not be committed (the crash still takes place, and a cleanup/recover  
still needs to be done).


	In addition to the local working copy, I also have access to two  
working copies on remote systems.  Both remote working copies use svn 
+ssh to connect to the repository.  One remote system has version  
1.2.1 (r15230), and another has version 1.1.4 (r13838).  For each  
remote working copy, I updated it to the latest revision (with no  
problems), made a change, and tried to commit.  Each one failed in  
the same place with the following:



svn: Commit failed (details follow):
svn: Malformed network data


Each one required a cleanup/recover.

	In the end I dumped the entire repository, created a repository on a  
different machine, restored the repository onto the different  
machine, switched the URLs of all checked out working copies, and  
the problem was gone.  The different machine is running Darwin  
8.3.0 running Subversion 1.1.4 (r13838).



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

Bug#339841: svn commit crashes when commiting approx. 300 files to a local BDB repository

[A. Karl Kornel]

Package: svn
Version: subversion
Severity: important

   I am using Subversion 1.1.4 (r13838) that was already on the system. 
I did not install it, and I assume it came as part of the Debian
installation.

   I have a repository containing many files (at least 1000) and several 
branches (directories), about 7 of which are in use and 6 of which are 
no longer in use (deleted), this in addition to the main trunk.  I have 
about 300 files spread out in the 6 branches + trunk which I needed to 
commit.  I first ran `svn update`, which showed no updates, and then ran 
`svn commit`.  I entered one line of text in the commit log.  All files 
were sent without problems.  During the Transmitting file data part, 
subversion aborted.

   After this, I did a `svn update` and was told that the directory was
locked.  I ran `svn cleanup` and did not receive any output.  I then ran
`svn update` again and was told the repository needed to be recovered. 
I did so (nothing was lost), and tried the update/commit again.  This
time, the abort still took place but I was able to get a core dump.

   I then redid the cleanup/recover, and tried to commit smaller batches 
of files (one commit per branch + head).  This does not work either.  It 
seems that I can no longer commit anything from my working copy without 
an abort.

   Here is information that I was able to obtain from the core dump.  

* First, the information generated by gdb when loading:

This GDB was configured as i686-pc-linux-gnu...(no debugging symbols 
found)
Using host libthread_db library /lib/libthread_db.so.1.

Core was generated by `svn commit'.
Program terminated with signal 6, Aborted.
Reading symbols from /usr/lib/libsvn_client-1.so.0...(no debugging 
symbols found)...done.
Loaded symbols for /usr/lib/libsvn_client-1.so.0
Reading symbols from /usr/lib/libsvn_wc-1.so.0...(no debugging symbols 
found)...done.
Loaded symbols for /usr/lib/libsvn_wc-1.so.0
Reading symbols from /usr/lib/libsvn_ra-1.so.0...
(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libsvn_ra-1.so.0
Reading symbols from /usr/lib/libsvn_delta-1.so.0...(no debugging 
symbols found)...done.
Loaded symbols for /usr/lib/libsvn_delta-1.so.0
Reading symbols from /usr/lib/libsvn_subr-1.so.0...
(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libsvn_subr-1.so.0
Reading symbols from /usr/lib/libaprutil-0.so.0...(no debugging symbols 
found)...done.
Loaded symbols for /usr/lib/libaprutil-0.so.0
Reading symbols from /usr/lib/libldap.so.2...
(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libldap.so.2
Reading symbols from /usr/lib/liblber.so.2...(no debugging symbols 
found)...done.
Loaded symbols for /usr/lib/liblber.so.2
Reading symbols from /usr/lib/libdb-4.2.so...
(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libdb-4.2.so
Reading symbols from /usr/lib/libexpat.so.1...(no debugging symbols 
found)...done.
Loaded symbols for /usr/lib/libexpat.so.1
Reading symbols from /usr/lib/libapr-0.so.0...
(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libapr-0.so.0
Reading symbols from /lib/librt.so.1...(no debugging symbols 
found)...done.
Loaded symbols for /lib/librt.so.1
Reading symbols from /lib/libnsl.so.1...
(no debugging symbols found)...done.
Loaded symbols for /lib/libnsl.so.1
Reading symbols from /usr/lib/libneon.so.24...(no debugging symbols 
found)...done.
Loaded symbols for /usr/lib/libneon.so.24
Reading symbols from /usr/lib/i686/cmov/libssl.so.0.9.7...
(no debugging symbols found)...done.
Loaded symbols for /usr/lib/i686/cmov/libssl.so.0.9.7
Reading symbols from /usr/lib/i686/cmov/libcrypto.so.0.9.7...(no 
debugging symbols found)...done.
Loaded symbols for /usr/lib/i686/cmov/libcrypto.so.0.9.7
Reading symbols from /lib/libdl.so.2...
(no debugging symbols found)...done.
Loaded symbols for /lib/libdl.so.2
Reading symbols from /usr/lib/libxml2.so.2...(no debugging symbols 
found)...done.
Loaded symbols for /usr/lib/libxml2.so.2
Reading symbols from /usr/lib/libz.so.1...
(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libz.so.1
Reading symbols from /lib/libpthread.so.0...(no debugging symbols 
found)...done.
Loaded symbols for /lib/libpthread.so.0
Reading symbols from /lib/libm.so.6...
(no debugging symbols found)...done.
Loaded symbols for /lib/libm.so.6
Reading symbols from /lib/libc.so.6...(no debugging symbols 
found)...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /usr/lib/libsvn_diff-1.so.0...
(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libsvn_diff-1.so.0
Reading symbols from /usr/lib/libsvn_ra_local-1.so.0...(no debugging 
symbols found)...done.
Loaded symbols for /usr/lib/libsvn_ra_local-1.so.0
Reading symbols from /usr/lib/libsvn_repos-1.so.0...
(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libsvn_repos-1.so.0
Reading symbols from /usr/lib/libsvn_fs-1.so.0...(no debugging symbols 
found)...done.
Loaded symbols for