Bug#931114: cluster-glue: ibmrsa-telnet not python3 ready

2019-06-26 Thread Pierre Dinh van
Package: cluster-glue
Version: 1.0.12-12
Severity: normal

Dear Maintainer,

I just upgraded my corosync cluster to buster, and the stonith external helper 
/usr/lib/stonith/plugins/external/ibmrsa-telnet wasn't starting anymore :

Jun 26 12:02:16 nfs4-c external/ibmrsa-telnet[22786]: [22848]: ERROR: Exception 
raised: cannot use a string pattern on a bytes-like object
Jun 26 12:02:17 nfs4-c stonith: [22764]: WARN: external_status: 'ibmrsa-telnet 
status' failed with rc 1
Jun 26 12:02:17 nfs4-c stonith: [22764]: ERROR: external/ibmrsa-telnet device 
not accessible.
Jun 26 12:02:17 nfs4-c pacemaker-fenced[2062]:  warning: stonith-nfs-a:22639 [ 
Performing: stonith -t external/ibmrsa-telnet -E -S ]

I changed the #!/usr/bin/python3 to #!/usr/bin/python2 and it works back.

Looks like it's not python3 ready.

Cheers

Pierre Dinh-van


-- System Information:
Debian Release: 10.0
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-5-amd64 (SMP w/24 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages cluster-glue depends on:
ii  adduser   3.118
ii  bzip2 1.0.6-9
ii  libbz2-1.01.0.6-9
ii  libc6 2.28-10
ii  libcurl4  7.64.0-4
ii  libdbus-1-3   1.12.16-1
ii  libdbus-glib-1-2  0.110-4
ii  libglib2.0-0  2.58.3-2
ii  liblrm2   1.0.12-12
ii  libltdl7  2.4.6-9
ii  libopenhpi3   3.8.0-2
ii  libopenipmi0  2.0.25-2.1
ii  libpils2  1.0.12-12
ii  libplumb2 1.0.12-12
ii  libplumbgpl2  1.0.12-12
ii  libsnmp30 5.7.3+dfsg-5
ii  libssl1.1 1.1.1c-1
ii  libstonith1   1.0.12-12
ii  libtimedate-perl  2.3000-2
ii  libuuid1  2.33.1-0.1
ii  libxml2   2.9.4+dfsg1-7+b3
ii  lsb-base  10.2019051400
ii  perl  5.28.1-6
ii  python3   3.7.3-1
ii  python3.7 3.7.3-2
ii  zlib1g1:1.2.11.dfsg-1

cluster-glue recommends no packages.

Versions of packages cluster-glue suggests:
ii  ipmitool  1.8.18-6

-- no debconf information



Bug#908494: Related to thunderbird-l10n-de

2018-09-17 Thread Pierre Dinh-van
On Mon, 17 Sep 2018 10:52:19 +0200 =?UTF-8?Q?Steffen_M=c3=bcller?=
 wrote:
> Hi,

Hello,

> the issue hit me again and I could nail it down to localization package
> thunderbird-l10n-de 1:60.0-3~deb9u1

I just checked with other localizations (thunderbird-l10n-eu and
thunderbird-l10n-fr) and it reacts exactly the same way. Lighting shows
up only in if locale is English or if it fallbacks to english.

I just deployed the workaround to remove thunderbird-l10n-de from all my
clients now...



Bug#909001: enigmail: Enigmail get uninstalled while upgrading thunderbird (60.0-3~deb9u1)

2018-09-17 Thread Pierre Dinh van
Package: enigmail
Version: 2:1.9.9-1~deb9u1
Severity: important

Dear Maintainer,


Today, all my users have trouble reading their encrypted emails, because
the last upgrade of thunderbird from security.debian.org on 16/09/2018 breaks 
enigmail (and a lot of other things). 

apt show thunderbird
[...]
Breaks: [...]  enigmail (<<2:2~), [...]
[...]

Automatic Upgrade of my systems removed enigmail everywhere. 

An upgrade would be usefull.

Cheers

Pierre


-- System Information:
Debian Release: 9.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-8-amd64 (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages enigmail depends on:
ii  gnupg  2.1.18-8~deb9u2
ii  gnupg-agent2.1.18-8~deb9u2
ii  gnupg2 2.1.18-8~deb9u2
ii  icedove1:60.0-3~deb9u1
ii  thunderbird [icedove]  1:60.0-3~deb9u1

Versions of packages enigmail recommends:
ii  pinentry-gnome3 [pinentry-x11]  1.0.0-2
ii  pinentry-gtk2 [pinentry-x11]1.0.0-2

enigmail suggests no packages.



Bug#880587: xrandr -o left/right crashes the X server if libvnc.so loaded

2017-11-02 Thread Pierre Dinh-van
Package: tigervnc-xorg-extension
Version: 1.7.0+dfsg-7
Severity: normal
Tags: upstream

Dear Maintainer,

I set up libvnc.so from tigervnc-xorg-extension for my stretch
workstations by adding a config file
/usr/share/X11/xorg.conf.d/99-vnc.conf with in it :


Section "Module"
Load  "vnc"
EndSection
Section "Screen"
Identifier "Screen0"
Device "Card0"
Monitor"Monitor0"
Option "SecurityTypes" "VncAuth"
Option "QueryConnect"
Option "QueryConnectTimeout" "30"
Option "IdleTimeout" "60"
Option "UserPasswdVerifier" "VncAuth"
Option "PasswordFile" "/etc/vncpasswd"
EndSection


I try to rotate locally my screen with 'xrandr -o left' or 'xrandr -o right'

it crashes the X session and goes back to lightdm.

If the resolution is not changed, for example with '-o inverted' then, the 
session runs further.

I tried with the upstream release 1.8.0 and it's affected by the same problem
I tried on computers with intel graphics, and in a VirtualBox VM. The result is 
the same on both.

removing the /usr/share/X11/xorg.conf.d/99-vnc.conf and restarting ligthdm 
removes the issue.


It's a problem for my users who might have the orientation of the display set 
up in the preferences of there XFCE4.

I cannot upgrade such users, or they will be first unable to login until they 
fix there xfce4 profile and they are then unable to use a vertical layout for 
their screen.



-- System Information:
Debian Release: 9.2
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8),
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages tigervnc-xorg-extension depends on:
ii  libaudit1  1:2.6.7-2
ii  libbsd00.8.3-1
ii  libc6  2.24-11+deb9u1
ii  libgcc11:6.3.0-18
ii  libgnutls303.5.8-5+deb9u3
ii  libjpeg62-turbo1:1.5.1-2
ii  libpam0g   1.1.8-3.6
ii  libstdc++6 6.3.0-18
ii  xserver-xorg-core  2:1.19.2-1+deb9u2
ii  zlib1g 1:1.2.8.dfsg-5

Versions of packages tigervnc-xorg-extension recommends:
ii  tigervnc-common  1.7.0+dfsg-7

tigervnc-xorg-extension suggests no packages.

-- no debconf information



Bug#855350: nomodeset parameter solved it for me

2017-10-27 Thread Pierre Dinh-van
Hi,

I just got the same problem on a lenovo computer after installing
stretch on it:

    Manufacturer: LENOVO
    Product Name: 3235H3G
    Version: ThinkCentre M92

It has this graphic card :

00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v2/3rd
Gen Core processor Graphics Controller (rev 09) (prog-if 00 [VGA
controller])
    Subsystem: Lenovo Xeon E3-1200 v2/3rd Gen Core processor Graphics
Controller
    Flags: bus master, fast devsel, latency 0, IRQ 11
    Memory at f780 (64-bit, non-prefetchable) [size=4M]
    Memory at e000 (64-bit, prefetchable) [size=256M]
    I/O ports at f000 [size=64]
    [virtual] Expansion ROM at 000c [disabled] [size=128K]
    Capabilities: [90] MSI: Enable- Count=1/1 Maskable- 64bit-
    Capabilities: [d0] Power Management version 2
    Capabilities: [a4] PCI Advanced Features
    Kernel modules: i915

The VNC Config file is in /usr/share/X11/xorg.conf.d/99-vnc.conf :

Section "Module"
    Load  "vnc"
EndSection
Section "Screen"
    Identifier "Screen0"
    Device "Card0"
    Monitor    "Monitor0"
    Option "QueryConnectTimeout" "30"
    Option "AcceptSetDesktopSize" "0"
    Option "IdleTimeout" "60"
    Option "SecurityTypes" "VncAuth"
    Option "QueryConnect"
    Option "UserPasswdVerifier" "VncAuth"
    Option "PasswordFile" "/etc/vncpasswd"
EndSection

The X session was just unusable on this computer, the mouse really slow,
and no process in top seemed to take resources. There was no EE messages
in Xorg.0.log

When I saw in the message #22 '(EE) modeset(0): failed to set mode:
Permission denied', I tried to reboot the computer with the kernel
parameter "nomodeset" and it solved the issue for me. I'm now going to
install the rest of my computers with nomodeset, since my users never
use the console.

Kernel version :

Linux enzio 4.9.0-4-amd64 #1 SMP Debian 4.9.51-1 (2017-09-28) x86_64
GNU/Linux


Cheers

Pierre



Bug#879866: Patch solving the issue

2017-10-26 Thread Pierre Dinh-van
Hi,

I tried to find out by myself where the bugs comes from.

I looked at the code upstream, and noticed that they moved the code
responsible for the reply "Unable to query the local user to accept the
connection." a few line up in unix/xserver/hw/vnc/XserverDesktop.cc

https://github.com/TigerVNC/tigervnc/blob/master/unix/xserver/hw/vnc/XserverDesktop.cc#L314

Looking at the code in rfb::VNCServerST::queryResult
XserverDesktop::queryConnection it's quite clear.
The 'queryConnectId' variable which triggers the Message "Another
connection is currently being queried." is set before the code related
to "Unable to query the local user to accept the connection.", which
doesn't reset the 'queryConnectId' variable.

So it makes sense to move the code before the initialisation of the
queryConnectId.

I build 1.7.0+dfsg-7 with the attached patch on top of the debian
patches, and it solves the issue.

I didn't look deeper to see if it as side effects, but since the
upstream developers did it too, I guess it could be nice to patch !

This bug is a kind of DoS since it needs the user to restart Xorg
completely to allow the service to be reached again.

Cheers

Pierre
--- tigervnc-1.7.0/unix/xserver/hw/vnc/XserverDesktop.cc	2016-09-08 12:31:18.0 +0200
+++ tigervnc-1.7.0.pierre/unix/xserver/hw/vnc/XserverDesktop.cc	2017-10-26 19:19:55.736805114 +0200
@@ -285,19 +285,18 @@
 return rfb::VNCServerST::REJECT;
   }
 
-  queryConnectAddress.replaceBuf(sock->getPeerAddress());
-  if (!userName)
-userName = "(anonymous)";
-  queryConnectUsername.replaceBuf(strDup(userName));
-  queryConnectId = (uint32_t)(intptr_t)sock;
-  queryConnectSocket = sock;
-
   count = vncNotifyQueryConnect();
   if (count == 0) {
 *reason = strDup("Unable to query the local user to accept the connection.");
 return rfb::VNCServerST::REJECT;
   }
 
+  queryConnectAddress.replaceBuf(sock->getPeerAddress());
+  if (!userName)
+userName = "(anonymous)";
+  queryConnectUsername.replaceBuf(strDup(userName));
+  queryConnectId = (uint32_t)(intptr_t)sock;
+  queryConnectSocket = sock;
   return rfb::VNCServerST::PENDING;
 }
 


Bug#879866: tigervnc-xorg-extension: QueryConnect connection w/o running vncconfig never timeouts

2017-10-26 Thread Pierre Dinh-van
Package: tigervnc-xorg-extension
Version: 1.7.0+dfsg-7
Severity: normal

Dear Maintainer,

   * What led up to the situation?

I set up libvnc.so from tigervnc-xorg-extension for my stretch
workstations by adding a config file
/usr/share/X11/xorg.conf.d/99-vnc.conf with in it :


Section "Module"
Load  "vnc"
EndSection
Section "Screen"
Identifier "Screen0"
Device "Card0"
Monitor"Monitor0"

Option "SecurityTypes" "VncAuth"
Option "QueryConnect"
Option "QueryConnectTimeout" "30"
Option "IdleTimeout" "60"
Option "UserPasswdVerifier" "VncAuth"
Option "PasswordFile" "/etc/vncpasswd"
EndSection

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

So the VNC server is launched when Xorg is started by my lightdm. I also
have a vncconfig -nowin which get started for the user directly after
login. So if our helpdesk is connecting to the client, the user should
first allow the remote VNC connection. The problem happens if a vnc
connection is tried while vncconfig is not running (for example, when
only lightdm is running on the display, because the user didn't logged in).

   * What was the outcome of this action?

In this case, the client reports after authentication :
"Unable to query the local user to accept the connection."

Fine, cause vncconfig is not started at this point.

All the further tries of connecting to the vnc sessions ends with :
"Another connection is currently being queried"

It doesn't seems to timeout at any time, until the X server is restarted.
If the user logs in, vncconfig is started but the client stills get the
previous message.

   * What outcome did you expect instead?

If no vncconfig is running, the server shouldn't go in the state of
"another connection is currently being queried".

In our case, it means that if a workstation gets by error an incoming
vnc connection before the user logs in, if the users needs our remote
help later on, it will not be possible for us to connect.

I tried it with the following clients from stretch, and they all give
the same symptoms :

- vinagre
- tigervnc-client
- gvncviewer
- xtightvncviewer


I tried to update tigervnc-xorg-extension to sid, but it seems to be the
same version as on stretch.

-- System Information:
Debian Release: 9.2
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8),
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages tigervnc-xorg-extension depends on:
ii  libaudit1  1:2.6.7-2
ii  libbsd00.8.3-1
ii  libc6  2.24-11+deb9u1
ii  libgcc11:6.3.0-18
ii  libgnutls303.5.8-5+deb9u3
ii  libjpeg62-turbo1:1.5.1-2
ii  libpam0g   1.1.8-3.6
ii  libstdc++6 6.3.0-18
ii  xserver-xorg-core  2:1.19.2-1+deb9u2
ii  zlib1g 1:1.2.8.dfsg-5

Versions of packages tigervnc-xorg-extension recommends:
ii  tigervnc-common  1.7.0+dfsg-7

tigervnc-xorg-extension suggests no packages.

-- no debconf information



Bug#792456: debian-installer: partman fails encrypting swap

2015-07-14 Thread Pierre Dinh-van
Package: debian-installer
Version: installer from debian-8.1.0-amd64-netinst.iso
Severity: important
Tags: d-i


While creating an encrypted swap partition in partman, it fails with the kernel
message "Unable to find swap-space signature". Which blocks going further in
the install process.

It seams that after initialisation of the underlaying luks device, partman
forgets to run mkswap on the openened device.

After the error occurs : 

# swapon /dev/mapper/md1_crypt
swapon: /dev/mapper/md1_crypt: Invalid argument
# mkswap /dev/mapper/md1_crypt
# swapon /dev/mapper/md1_crypt
#


Workaround is to remove swap partition and activate it when installation is 
done.


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



Bug#792450: debian-installer: partman cannot create new RAID on disk if RAID pre-exists

2015-07-14 Thread Pierre Dinh-van
Package: debian-installer
Version: installer from debian-8.1.0-amd64-netinst.iso
Severity: normal
Tags: d-i


while installing debian to a hard drive where it was before a RAID subsystem on
it, it's not possible to "create a new empty partition table on this device"
while using partman.

Partman will warn that "the selected device contains partitions used for
software RAID devices." and asks for confirmation "Remove existing software
RAID partitions?"

selecting yes just does nothing. 

stoping the MD devices in a shell with mdadm --stop makes it possible to
initiate a new empty partition on the device, but drops the warning about
underlaying RAID partitions.

Deleting the old raid partitions from the disk and creating new ones doesn't
work either. It replaces the partitions from the disk, without stopping the
existing/autodetected RAID. It ends with an "Error informing the kernel about
modifications to partition..."

Stoping the arrays manually allows the process to continue.

Otherwise, a reboot is needed in the middle of the install process.

I guess it could be fix by stopping the autodetected arrays before starting any
work on the partitions.


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



Bug#792435: debian-installer: Keyboard layouts sorted with English name when locale is set to something else.

2015-07-14 Thread Pierre Dinh-van
Package: debian-installer
Version: installer from debian-8.1.0-amd64-netinst.iso
Severity: wishlist
Tags: l10n


In the first steps of the installer, when we choose a language which is not
english (tested with German, Spanish, French), the keyboard layouts are showing
up ordered as in the english version (just as short example when selecting
French as language, and looking for the german keyboard layout) :

Français
Géorgien
Allemand
Grec

"Allemand" is sorted as it would be "German".

It's kind of confusing cause we start with a looks-like-a-sorted list, but the
things are not at the expected place.

This doesn't happen when looking for the country list.

Should be nice to fix before the next release.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150714181505.24614.40695.reportbug@px



Bug#400301: Using dspam with libhash_drv.so in daemon mode can lead to DoS.

2009-07-24 Thread Pierre Dinh-van
dspam:
  Installed: 3.6.8-9
  Candidate: 3.6.8-9

I configured my server to use dspam as daemon under Lenny with libhash_drv.so 
as driver for 2 month, and it
suddently crashed with segfault in libhash_drv.so for 2 days.

See kernel messages :

[4209827.385345] dspam[22322]: segfault at 7f9bcc4a5cc0 ip 7f9bcc5e415f sp 
448ffec0 error 4 in libhash_drv.so.7.0.0[7f9bcc5e2000+5000]
[4212838.514323] dspam[22529]: segfault at 7fb096aa4478 ip 7fb096a5d15f sp 
4149eec0 error 4 in libhash_drv.so.7.0.0[7fb096a5b000+5000]
[4213116.665649] dspam[22613]: segfault at 7f07cfcc4000 ip 7f07cfcb515f sp 
41441ec0 error 4 in libhash_drv.so.7.0.0[7f07cfcb3000+5000]
[4213263.530802] dspam[23796]: segfault at 7f3f16f1be50 ip 7f3f16e9e15f sp 
4199eec0 error 4 in libhash_drv.so.7.0.0[7f3f16e9c000+5000]
[4213504.544104] dspam[24424]: segfault at 7f313d61c2e8 ip 7f313d5a415f sp 
41813ec0 error 4 in libhash_drv.so.7.0.0[7f313d5a2000+5000]
[4213708.967832] dspam[24481]: segfault at 7fec5f339a50 ip 7fec5f28e15f sp 
4129eec0 error 4 in libhash_drv.so.7.0.0[7fec5f28c000+5000]
[4275800.005645] dspam_clean[13507]: segfault at 7f32aa94a478 ip 7f32aa92715f 
sp 7fffb4b18650 error 4 in libhash_drv.so.7.0.0[7f32aa925000+5000]
[4306980.330052] dspam_clean[4236]: segfault at 7f465ce7a478 ip 7f465ce5715f sp 
7fff67049600 error 4 in libhash_drv.so.7.0.0[7f465ce55000+5000]
[4307032.334237] dspam_clean[4239]: segfault at 7fd1d7d67478 ip 7fd1d7d4415f sp 
7fffe1f374e0 error 4 in libhash_drv.so.7.0.0[7fd1d7d42000+5000]
[4309279.258966] dspam_clean[8637]: segfault at 7f7f85063478 ip 7f7f8504015f sp 
7fff8f232800 error 4 in libhash_drv.so.7.0.0[7f7f8503e000+5000]
[4310046.873552] dspam_clean[8808]: segfault at 7f7fba759478 ip 7f7fba73615f sp 
7fffc4926f00 error 4 in libhash_drv.so.7.0.0[7f7fba734000+5000]
[4310105.077497] dspam_clean[8829]: segfault at 7f3011877478 ip 7f301185415f sp 
7fff1ba47010 error 4 in libhash_drv.so.7.0.0[7f3011852000+5000]
[4310683.110547] dspam_clean[10009]: segfault at 7f4e1ecec478 ip 7f4e1ecc915f 
sp 7fff28eba430 error 4 in libhash_drv.so.7.0.0[7f4e1ecc7000+5000]
[4314041.519282] dspam_2sql[12029]: segfault at 7f99a7dc6478 ip 7f99a7da315f sp 
7fffb1f965d0 error 4 in libhash_drv.so.7.0.0[7f99a7da1000+5000]
[4314224.640323] dspam_2sql[12039]: segfault at 7fc0c2c15478 ip 7fc0c2bf215f sp 
7fffccde3420 error 4 in libhash_drv.so.7.0.0[7fc0c2bf+5000]

All commands which tried to access the database were affected by this segfault.

/var/spool/dspam was something like 380MB big.

In my situation, it causes a DoS of my mail server, with every mail received by 
the MTA rejected to the sender because dspam wasn't replying.

I migrated it to libmysql_drv for now, but it could be really good to have a 
warning when starting dspam as daemon with libhash_drv as
storage.





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



Bug#513596: Upstream seems to be fixed

2009-02-03 Thread Pierre Dinh-van
It seems, that this issuee was corrected in the trunk of the upstream 
subversion since revision 41.

http://code.google.com/p/cryptsetup/source/diff?spec=svn47&r=41&format=side&path=/trunk/lib/setup.c&old_path=/trunk/lib/setup.c&old=38

Maybe a better patch could be build from it.

This bug also reported for ubuntu 8.04 :

https://bugs.launchpad.net/cryptsetup/+bug/324871


signature.asc
Description: Digital signature


Bug#513596: Exists also in Etch

2009-01-30 Thread Pierre Dinh-van
Tags: patch
Version: 2:1.0.4+svn26-1

The version provided in Etch also has the same limitation.

Patch for etch attached.

diff -ru cryptsetup-1.0.4+svn26.orig/lib/setup.c cryptsetup-1.0.4+svn26/lib/setup.c
--- cryptsetup-1.0.4+svn26.orig/lib/setup.c	2009-01-30 17:47:37.0 +0100
+++ cryptsetup-1.0.4+svn26/lib/setup.c	2009-01-30 17:46:29.0 +0100
@@ -756,7 +756,7 @@
 			r = -EINVAL; goto out;
 		}
 		openedIndex = LUKS_open_any_key(device, password, passwordLen, &hdr, &mk, backend);
-		if(openedIndex < 0 || keyIndex == openedIndex) {
+		if(openedIndex < 0) {
 			printf("No remaining key available with this passphrase.\n");
 			r = -EPERM; goto out;
 		}


signature.asc
Description: Digital signature


Bug#513596: cryptsetup: A patch for this issue

2009-01-30 Thread Pierre Dinh-van
Package: cryptsetup
Version: 2:1.0.6-7
Followup-For: Bug #513596


I just looked in the source, and the problem comes from lib/setup.c where
it's explicitly denied to remove a key with itselfs (keyIndex == openedIndex).

The attached patch removes this extra check. I rebuild the package and installed
it, and it seems to work fine, I'm able to have an unusable luks partition :

r...@pierre:/tmp# cryptsetup luksDump /dev/mapper/pierre-testluks
LUKS header information for /dev/mapper/pierre-testluks

Version:1
Cipher name:aes
Cipher mode:cbc-essiv:sha256
Hash spec:  sha1
Payload offset: 2056
MK bits:256
MK digest:  2b ba 0b 5a f9 cb 49 57 f6 db 7e cd 94 a6 21 fb 48 83 e3 02 
MK salt:58 89 47 04 76 85 e3 77 75 09 2e eb 41 e2 f7 18 
8e 9f 27 03 38 a0 94 87 5e 95 1d fa 98 80 e3 9d 
MK iterations:  10
UUID:   1defedc2-a202-46fe-81ca-5ddbf997a891

Key Slot 0: DISABLED
Key Slot 1: DISABLED
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED

I didn't noticed any side effect for now...


-- System Information:
Debian Release: 5.0
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.18-6-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 cryptsetup depends on:
ii  dmsetup  2:1.02.27-4 The Linux Kernel Device Mapper use
ii  libc62.7-18  GNU C Library: Shared libraries
ii  libdevmapper1.02.1   2:1.02.27-4 The Linux Kernel Device Mapper use
ii  libpopt0 1.14-4  lib for parsing cmdline parameters
ii  libuuid1 1.41.3-1universally unique id library

cryptsetup recommends no packages.

Versions of packages cryptsetup suggests:
ii  dosfstools3.0.1-1utilities for making and checking 
ii  initramfs-tools [linux-initra 0.92o  tools for generating an initramfs
ii  udev  0.125-7/dev/ and hotplug management daemo

-- no debconf information
diff -ru cryptsetup-1.0.6.orig/lib/setup.c cryptsetup-1.0.6/lib/setup.c
--- cryptsetup-1.0.6.orig/lib/setup.c	2009-01-30 17:06:59.0 +0100
+++ cryptsetup-1.0.6/lib/setup.c	2009-01-30 17:07:59.0 +0100
@@ -659,7 +659,7 @@
 LUKS_dealloc_masterkey(mk);
 mk = NULL;
 }
-		if(openedIndex < 0 || keyIndex == openedIndex) {
+		if(openedIndex < 0) {
 options->icb->log(CRYPT_LOG_ERROR,"No remaining key available with this passphrase.\n");
 			r = -EPERM; goto out;
 		} else


Bug#513596: cryptsetup: Cannot delete a Keyslot from itselfs

2009-01-30 Thread Pierre Dinh-van
Package: cryptsetup
Version: 2:1.0.6-7
Severity: normal


I noticed that it is impossible to remove a keyslot with the key of this slot.
Problem occurs either with passphrase and with key-file.

I guess it's not a feature, since it should be possible to delete all key-slots 
to make
access to the data quite-impossible. There is also a warning message while 
trying to do it,
so I'm sure it should be possible (and in the case we have to delete the last 
keyslot, the 
only possibility is to use the same key).

Example :

r...@pierre:/tmp# ls -sh keyslot*
4.0K keyslot0.rand  4.0K keyslot1.rand
r...@pierre:/tmp# cryptsetup luksFormat -s256 /dev/mapper/pierre-testluks 
/tmp/keyslot0.rand

WARNING!

This will overwrite data on /dev/mapper/pierre-testluks irrevocably.

Are you sure? (Type uppercase yes): YES
Command successful.
r...@pierre:/tmp# cryptsetup luksAddKey --key-file /tmp/keyslot0.rand 
/dev/mapper/pierre-testluks /tmp/keyslot1.rand
key slot 0 unlocked.
Command successful.
r...@pierre:/tmp# cryptsetup luksDump /dev/mapper/pierre-testluks
LUKS header information for /dev/mapper/pierre-testluks

Version:1
Cipher name:aes
Cipher mode:cbc-essiv:sha256
Hash spec:  sha1
Payload offset: 2056
MK bits:256
MK digest:  84 b0 9a 7e 56 98 ed c0 01 56 cd a8 ab 6a be 25 e6 22 e4 4b 
MK salt:a5 4f 46 09 9e 1d 9e 3b 08 d9 5b 35 8b ea 99 41 
fb ae 4c 17 f1 03 32 4a af b0 76 c5 06 ed e1 e5 
MK iterations:  10
UUID:   b6bf43f9-6de5-4290-945f-65faaa8a188d

Key Slot 0: ENABLED
Iterations: 128887
Salt:   e3 70 ff b6 d2 94 c0 a7 89 aa 97 33 6a 20 b2 c7 
32 9f 65 6d 95 78 48 6b f2 52 3e c0 f8 04 27 34 
Key material offset:8
AF stripes: 4000
Key Slot 1: ENABLED
Iterations: 236321
Salt:   ba 18 91 42 b7 de 3f d0 db 96 0a 09 9e 9e 1c fb 
06 e7 17 73 e6 8b e5 f7 9a c4 4d a7 3c e1 40 d4 
Key material offset:264
AF stripes: 4000
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED
r...@pierre:/tmp# cryptsetup luksKillSlot --key-file /tmp/keyslot1.rand 
/dev/mapper/pierre-testluks 1
No remaining key available with this passphrase.
Command failed.
r...@pierre:/tmp# cryptsetup luksKillSlot --key-file /tmp/keyslot0.rand 
/dev/mapper/pierre-testluks 0
No remaining key available with this passphrase.
Command failed.
r...@pierre:/tmp# cryptsetup luksKillSlot --key-file /tmp/keyslot0.rand 
/dev/mapper/pierre-testluks 1
key slot 1 verified.
Command successful.
r...@pierre:/tmp# cryptsetup luksKillSlot --key-file /tmp/keyslot0.rand 
/dev/mapper/pierre-testluks 0

WARNING!

This is the last keyslot. Device will become unusable after purging this key.

Are you sure? (Type uppercase yes): YES
No remaining key available with this passphrase.
Command failed.
r...@pierre:/tmp# 



-- System Information:
Debian Release: 5.0
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.18-6-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 cryptsetup depends on:
ii  dmsetup  2:1.02.27-4 The Linux Kernel Device Mapper use
ii  libc62.7-18  GNU C Library: Shared libraries
ii  libdevmapper1.02.1   2:1.02.27-4 The Linux Kernel Device Mapper use
ii  libpopt0 1.14-4  lib for parsing cmdline parameters
ii  libuuid1 1.41.3-1universally unique id library

cryptsetup recommends no packages.

Versions of packages cryptsetup suggests:
ii  dosfstools3.0.1-1utilities for making and checking 
ii  initramfs-tools [linux-initra 0.92o  tools for generating an initramfs
ii  udev  0.125-7/dev/ and hotplug management daemo

-- 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#465694: Occurs quite often on Macbook (first generation)

2009-01-28 Thread Pierre Dinh-van
xserver-xorg-video-intel : 2:2.3.2-2+lenny6

The crash of Xorg occurs quite often (2 or 3 times/day), with no other 
possibility as a reboot to restart X.

rmmod drm i915 && modprobe drm i915

doesn't help, and it occurs with all kernels I have :
- 2.6.18-6-686 (from debian etch)
- 2.6.23.12 + mactel patches (manually compiled)
- 2.6.26 (from lenny)
- 2.6.28.2 (manually compiled)

I noticed that it happens a little bit more often when I'm using the external 
monitor in 1600x1200 than with the standart LCD panel (1280x800).

I didn't found any message in the log files, except in Xorg.0.log (attached)


X.Org X Server 1.4.2
Release Date: 11 June 2008
X Protocol Version 11, Revision 0
Build Operating System: Linux Debian (xorg-server 2:1.4.2-10)
Current Operating System: Linux macbook 2.6.28.2 #1 SMP Sun Jan 25 15:59:24 CET 
2009 i686
Build Date: 09 January 2009  02:57:16AM
 
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
Module Loader present
Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/Xorg.0.log", Time: Wed Jan 28 23:56:52 2009
(==) Using config file: "/etc/X11/xorg.conf"
(**) Option "defaultserverlayout" "MonitorLayout Layout"
(**) ServerLayout "MonitorLayout Layout"
(**) |-->Screen "MonitorLayout Screen" (0)
(**) |   |-->Monitor "Eizo"
(**) |   |-->Device "MonitorLayout Device"
(**) |-->Input Device "Generic Keyboard"
(**) |-->Input Device "Configured Mouse"
(==) Automatically adding devices
(==) Automatically enabling devices
(WW) The directory "/usr/share/X11/fonts/misc" does not exist.
Entry deleted from font path.
(WW) The directory "/usr/share/X11/fonts/cyrillic" does not exist.
Entry deleted from font path.
(WW) The directory "/usr/share/X11/fonts/100dpi/" does not exist.
Entry deleted from font path.
(WW) The directory "/usr/share/X11/fonts/75dpi/" does not exist.
Entry deleted from font path.
(WW) The directory "/usr/share/X11/fonts/Type1" does not exist.
Entry deleted from font path.
(WW) The directory "/usr/share/X11/fonts/100dpi" does not exist.
Entry deleted from font path.
(WW) The directory "/usr/share/X11/fonts/75dpi" does not exist.
Entry deleted from font path.
(==) Including the default font path 
/usr/share/fonts/X11/misc,/usr/share/fonts/X11/cyrillic,/usr/share/fonts/X11/100dpi/:unscaled,/usr/share/fonts/X11/75dpi/:unscaled,/usr/share/fonts/X11/Type1,/usr/share/fonts/X11/100dpi,/usr/share/fonts/X11/75dpi,/var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType.
(**) FontPath set to:
/var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType,
/usr/share/fonts/X11/misc,
/usr/share/fonts/X11/cyrillic,
/usr/share/fonts/X11/100dpi/:unscaled,
/usr/share/fonts/X11/75dpi/:unscaled,
/usr/share/fonts/X11/Type1,
/usr/share/fonts/X11/100dpi,
/usr/share/fonts/X11/75dpi,
/var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType
(==) RgbPath set to "/etc/X11/rgb"
(==) ModulePath set to "/usr/lib/xorg/modules"
(==) |-->Input Device "Generic Keyboard"
(==) The core keyboard device wasn't specified explicitly in the layout.
Using the first keyboard device.
(II) Open ACPI successful (/var/run/acpid.socket)
(II) Loader magic: 0x81e38c0
(II) Module ABI versions:
X.Org ANSI C Emulation: 0.3
X.Org Video Driver: 2.0
X.Org XInput driver : 2.0
X.Org Server Extension : 0.3
X.Org Font Renderer : 0.5
(II) Loader running on linux
(II) LoadModule: "pcidata"
(II) Loading /usr/lib/xorg/modules//libpcidata.so
(II) Module pcidata: vendor="X.Org Foundation"
compiled for 1.4.2, module version = 1.0.0
ABI class: X.Org Video Driver, version 2.0
(++) using VT number 7

(II) PCI: PCI scan (all values are in hex)
(II) PCI: 00:00:0: chip 8086,27a0 card 8086,7270 rev 03 class 06,00,00 hdr 00
(II) PCI: 00:02:0: chip 8086,27a2 card 8086,7270 rev 03 class 03,00,00 hdr 80
(II) PCI: 00:02:1: chip 8086,27a6 card 8086,7270 rev 03 class 03,80,00 hdr 80
(II) PCI: 00:07:0: chip 8086,27a3 card , rev 03 class 11,01,00 hdr 00
(II) PCI: 00:1b:0: chip 8086,27d8 card 8384,7680 rev 02 class 04,03,00 hdr 00
(II) PCI: 00:1c:0: chip 8086,27d0 card , rev 02 class 06,04,00 hdr 81
(II) PCI: 00:1c:1: chip 8086,27d2 card , rev 02 class 06,04,00 hdr 81
(II) PCI: 00:1d:0: chip 8086,27c8 card 8086,7270 rev 02 class 0c,03,00 hdr 80
(II) PCI: 00:1d:1: chip 8086,27c9 card 8086,7270 rev 02 class 0c,03,00 hdr 00
(II) PCI: 00:1d:2: chip 8086,27ca card 8086,7270 rev 02 class 0c,03,00 hdr 00
(II) PCI: 00:1d:3: chip 8086,27cb card 8086,7270 rev 02 class 0c,03,00 hdr 00
(II) PCI: 00:1d:7: chip 8086,27cc card 8086,7270 rev 02 class 0c,03,20 hdr 00
(II) PCI: 00:1e:0: chip 8086,2448 card , rev e2 class 06,04,01 hdr 01
(II) PCI: 00

Bug#495236: nagios3-common: init script fails to remove command file

2008-08-15 Thread Pierre Dinh-van
Package: nagios3-common
Version: 3.0.1-1~bpo40+1
Severity: normal
Tags: patch


I noticed that my nagios3 installation didn't manage to startup automatically 
at boot process.
After checking a little bit, I noticed that the command file 
/var/lib/nagios3/rw/nagios.cmd still 
exists after a reboot, but is not a pipe anymore, but a standart file.

[EMAIL PROTECTED]:~$ sudo ls -l /var/lib/nagios3/rw/nagios.cmd
-rw-r--r-- 1 root root 115 2008-08-15 17:10 /var/lib/nagios3/rw/nagios.cmd


I tried to use the init script of nagios 3.0.3 (from etch-backports), but it 
doesn't fix this issue.

I fixed it with the following workaround, but why the command file changing its 
type stays a mystery for me.


--- nagios3.303 2008-08-15 17:35:19.0 +0200
+++ nagios3 2008-08-15 17:35:51.0 +0200
@@ -103,9 +103,11 @@
 check_named_pipe () {
   nagiospipe="$(get_config command_file)"
   if [ -p "$nagiospipe" ]; then
-return 1   # a named pipe exists
+  return 1   # a named pipe exists
+  elif [ -e "$nagiospipe" ];then
+  return 1
   else
-return 0   # no named pipe exists
+  return 0   # no named pipe exists
   fi
 }



-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (x86_64)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-6-xen-amd64
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)

Versions of packages nagios3-common depends on:
ii  adduser  3.102   Add and remove users and groups
ii  apache2-utils2.2.3-4+etch5   utility programs for webservers
ii  coreutils5.97-5.3The GNU core utilities
ii  debconf [debconf 1.5.11etch2 Debian configuration management sy
ii  lsb-base 3.1-23.2etch1   Linux Standard Base 3.1 init scrip
ii  mailx1:8.1.2-0.20050715cvs-1 A simple mail user agent
ii  nagios-plugins-b 1.4.5-1etch1Plugins for the nagios network mon
ii  nagios3-doc  3.0.1-1~bpo40+1 documentation for nagios3
ii  ucf  2.0020  Update Configuration File: preserv

Versions of packages nagios3-common recommends:
ii  apache22.2.3-4+etch5 Next generation, scalable, extenda
ii  apache2-mpm-worker [httpd] 2.2.3-4+etch5 High speed threaded model for Apac
pn  nagios-images  (no description available)
pn  nagios-plugins (no description available)

-- debconf information:
  nagios3/nagios1-in-apacheconf: false
  nagios3/adminpassword-mismatch:
  nagios3/httpd: apache2



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