Bug#1060082: collectd: OAuth fails for write_stackdriver because of small buffer size

[Stefanos Harhalakis]

Package: collectd
Version: 5.12.0-15+b1
Severity: important
Tags: upstream patch

collectd currently fails to write to stackdriver because OAuth fails
because it uses a buffer size of 256 bytes. This makes write_stackdriver
unusable.

It's practically this bug: https://github.com/collectd/collectd/issues/3897

It needs these changes: https://github.com/collectd/collectd/pull/3898/commits
(well, the first one)

Direct URLs:
- 
https://github.com/collectd/collectd/commit/24bb9e251969d5cf0e6eee14aad7a7e3bcc59dd8.patch
- 
https://github.com/collectd/collectd/commit/a4d3c1b5d3b43341ea003fe8353274dffbf45728.patch

-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'oldstable-security'), (500, 'unstable'), 
(500, 'stable'), (500, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.5.0-5-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages collectd depends on:
ii  collectd-core  5.12.0-15+b1
ii  libc6  2.37-12
ii  librrd81.7.2-4+b9

Versions of packages collectd recommends:
ii  default-jre-headless  2:1.17-75
ii  intel-cmt-cat 23.11-1
ii  libabsl20220623   20220623.1-3
ii  libatasmart4  0.19-5
ii  libbson-1.0-0 1.25.2-1
ii  libcurl3-gnutls   8.5.0-2
ii  libdbi1   0.9.0-6
ii  libesmtp6 1.1.0-3.1
ii  libgcc-s1 13.2.0-7
ii  libgcrypt20   1.10.3-2
ii  libglib2.0-0  2.78.3-1
ii  libgps30  3.25-2
ii  libgrpc++1.51 1.51.1-4
ii  libgrpc29 1.51.1-4
ii  libhiredis0.140.14.1-4
ii  libi2c0   4.3-4+b1
ii  libip4tc2 1.8.10-1
ii  libip6tc2 1.8.10-1
ii  libjansson4   2.14-2
ii  libldap-2.5-0 2.5.13+dfsg-5
ii  liblua5.3-0   5.3.6-2
ii  libmariadb3   1:10.11.6-1
ii  libmemcached111.1.4-1
ii  libmicrohttpd12   0.9.77-3
ii  libmnl0   1.0.5-2
ii  libmodbus53.1.10-1
ii  libmongoc-1.0-0   1.25.2-1
ii  libmosquitto1 2.0.18-1
ii  libnotify40.8.3-1
ii  libopenipmi0  2.0.33-1+b1
ii  liboping0 1.10.0-5+b1
ii  libpcap0.81.10.4-4
ii  libperl5.36   5.36.0-10
ii  libpq516.1-1
ii  libprotobuf-c11.4.1-1+b1
ii  libprotobuf32 3.21.12-8+b1
ii  libpython3.11 3.11.7-2
ii  libqpid-proton11  0.37.0-2+b2
ii  librabbitmq4  0.11.0-1+b1
ii  librdkafka1   2.3.0-1
ii  libriemann-client01.10.4-3
ii  librrd8   1.7.2-4+b9
ii  librte-eal24  23.11-1
ii  librte-ethdev24   23.11-1
ii  libsensors5   1:3.6.0-8
ii  libsnmp40 5.9.4+dfsg-1
ii  libssl3   3.1.4-2
ii  libstdc++613.2.0-7
ii  libudev1  255.2-2
ii  libupsclient6 2.8.1-1
ii  libvarnishapi37.1.1-1.1
ii  libvirt0  9.10.0-1
ii  libxenmisc4.174.17.2+76-ge1f9cb16e2-1
ii  libxml2   2.9.14+dfsg-1.3+b1
ii  libyajl2  2.1.0-5

collectd suggests no packages.

-- Configuration Files:
/etc/collectd/collectd.conf changed [not included]

-- no debconf information

Bug#947220: Root cause

[Stefanos Harhalakis]

I just tested it and the problem is that the dm_cache_smq module is missing
from initramfs. Adding it to "/etc/initramfs-tools/modules" and running
"update-initramfs -u" addresses the problem.

I guess that lvm2 should add dm_cache and dm_cache_smq to
/usr/share/initramfs-tools/hooks/lvm2, just like it has dm_mirror and
dm_raid.

Bug#947220: lvm2: System unbootable with cached root and latest kernel

[Stefanos Harhalakis]

Package: lvm2
Version: 2.03.02-3
Severity: critical
Justification: breaks the whole system

The system with the latest kernel from testing and the latest lvm2 is 
unbootable when the root filesystem is a cached lvm volume.

During boot, it says:
device-mapper: table: 253:3: cache: Error creating cache's policy
device-mapper: reload ioctl on (253:3) failed: Invalid argument
/sbin/modprobe failed: 1
/sbin/modprobe failed: 1

This repeats a couple of times and it drops to the initramfs shell. From there, 
it's possible to boot by removing the cache:

lvm lvchange --splitcache vg/root

Then boot and reattach:

lvconvert --type cache --cachepool root-cache vg/root

I've seen #862136 but I'm not sure if it's the same (haven't tested). I tested 
all three policies (smq, mq, cleaner) during the troubleshoting and none worked.

Another potential cause is this error that lvs throws after booting:

Unknown feature in status: 8 171/2048 128 1897/81920 235 840 562 2581 0 1897 0 
3 metadata2 writethrough no_discard_passdown 2 migration_threshold 2048 smq 0 
rw -
Unknown feature in status: 8 337/3072 128 7578/163840 23719 28981 8025 4909 0 
7578 0 3 metadata2 writethrough no_discard_passdown 2 migration_threshold 2048 
smq 0 rw -
Unknown feature in status: 8 341/3072 128 7018/163840 3369 32447 96 77 0 7018 0 
3 metadata2 writethrough no_discard_passdown 2 migration_threshold 2048 smq 0 
rw -
Unknown feature in status: 8 341/3072 128 7018/163840 3369 32447 96 77 0 7018 0 
3 metadata2 writethrough no_discard_passdown 2 migration_threshold 2048 smq 0 
rw -
Unknown feature in status: 8 337/3072 128 7578/163840 23719 28981 8025 4909 0 
7578 0 3 metadata2 writethrough no_discard_passdown 2 migration_threshold 2048 
smq 0 rw -
Unknown feature in status: 8 171/2048 128 1897/81920 235 840 562 2581 0 1897 0 
3 metadata2 writethrough no_discard_passdown 2 migration_threshold 2048 smq 0 
rw -

(I have 3 cached partitions, it's 2 lines per partition)

which sounds like there is something that lvm doesn't understand at boot (?)

Note: the system was bootable with a much earlier kernel (4.19.0-4), probably 
with an older version of lvm2. I haven't tested falling back to that.

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'oldoldstable'), (500, 'unstable'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.3.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages lvm2 depends on:
ii  dmeventd  2:1.02.155-3
ii  dmsetup   2:1.02.155-3
ii  libaio1   0.3.112-5
ii  libblkid1 2.34-0.1
ii  libc6 2.29-2
ii  libdevmapper-event1.02.1  2:1.02.155-3
ii  libdevmapper1.02.12:1.02.155-3
ii  libreadline5  5.2+dfsg-3+b13
ii  libselinux1   2.9-2+b2
ii  libsystemd0   242-7
ii  libudev1  242-7
ii  lsb-base  11.1.0

Versions of packages lvm2 recommends:
ii  thin-provisioning-tools  0.7.6-2.1

lvm2 suggests no packages.

-- Configuration Files:
/etc/lvm/lvm.conf changed [not included]

-- debconf-show failed

Bug#931794: fwupd doesn't work because of latest logitech firmware

[Stefanos Harhalakis]

Package: fwupd
Version: 1.2.6-1
Severity: important

This bug: https://github.com/hughsie/fwupd/issues/1139
prevents fwupd from working because the firmware has the unsupported
property. The bug exists in all debian versions and doesn't exist in the
latest upstream version.

The end result is that fwupd is rendered unusable

tl;dr the error is this:

# fwupdmgr get-updates
cannot handle firmware requirement 'not-child'

Bug#890622: vbackup: mbr backup fails on block devices with / in path

[Stefanos Harhalakis]

Good point. Fixed.


On Sun, Feb 18, 2018 at 12:16 PM, Dominik George <n...@ticdesk.teckids.org>
wrote:

> On Sun, Feb 18, 2018 at 12:03:09PM +, Stefanos Harhalakis wrote:
> > Ended up with a slightly different approach that converts / to _.
> > This should work:
> > https://github.com/sharhalakis/vbackup/commit/
> 52971d7b5e034f8bb939e2c1b23fbdc6c88b45d7
>
> OK. I wanted to keep the patch as small as possible for
> stetch-proposed-updates.
>
> That echo | sed also looks strange given that bash has built-in tools for
> that: foo=${foo//\//_}
>
> -nik
>
> --
> Dominik George (1. Vorstandsvorsitzender, pädagogische Leitung)
> Teckids e.V. - Erkunden, Entdecken, Erfinden.
> https://www.teckids.org/
>

Bug#890622: vbackup: mbr backup fails on block devices with / in path

[Stefanos Harhalakis]

Ended up with a slightly different approach that converts / to _.
This should work:
https://github.com/sharhalakis/vbackup/commit/52971d7b5e034f8bb939e2c1b23fbdc6c88b45d7


2018-02-16 20:56 GMT+00:00 Dominik George :

> > Find attached a patch with a simple fix.
>
> Sorry, the patch was broken. Here's the correct one.
>
> --
> Dominik George (1. Vorstandsvorsitzender, pädagogischer Leiter)
> Teckids e.V. - Erkunden, Entdecken, Erfinden.
> https://www.teckids.org/
>

Bug#789796: systemd[1]: Looping too fast. Throttling execution a little

[Stefanos Harhalakis]

Hi,

Can this be uploaded to jessie?

It would be of great help and, in a sense, having to run containers with 
full privileges is a security issue.


Thanks,
Stefanos

Bug#825394: systemd kill background processes after user logs out

[Stefanos Harhalakis]

Hi there,

As you know, one of the two reasons screen is used is to allow for
things to stay running if you get disconnected. In this spirit, I
personally run long-term things like backups and dist-upgrades under
screen (under X) in order to prevent interrupting them if (e.g.) X
crash. On the server side, I use screen in order to keep things
running even if I get disconnected.

My belief is that I am not the only and and I that a behavior change
like this should not enter testing lighthearted (I understand this is
only in unstable so far) even if it is the default behavior systemd
chooses to have.

Other than that, I'd be curious to see why this choice has been made
by systemd. I'm sure that there are good reasons, but I can't seem to
be able to find a reference to them. If you are aware of a link could
you please share it?

Thanks,
Stefanos

Bug#810255: approx: fdssf

[Stefanos Harhalakis]

FWIW, I had the exact same issue and it ended up being a problem on 
approx's cache


Running approx-gc fixed it.

Bug#814008: RFS: vbackup/1.0.1-1

[Stefanos Harhalakis]

On 28/02/16 12:17, Mattia Rizzolo wrote:

On Sun, Feb 28, 2016 at 01:58:14AM +, Stefanos Harhalakis wrote:

On 23/02/16 17:45, Mattia Rizzolo wrote:

On Sun, Feb 07, 2016 at 02:06:39PM +, Stefanos Harhalakis wrote:
* please meld the 2 changelog entries, the 1 minute, 14 seconds older
   one never hit the archive anyway.


Done


while on it maybe also bump the change date/time?


Bumped


* current standards-version is 3.9.7, check against it.


Done. No changes needed


no, you haven't.  you only modified the changelog entry, but not the
actual metadata.


Oops... Fixed


* in d/copyright, the years are 2006-2012, I'm confident you want to
   bump them.


Corrected


please document this in d/changelog.


Documented

The new source package is in mentors:

http://mentors.debian.net/package/vbackup

Thanks,
Stefanos

Bug#814008: RFS: vbackup/1.0.1-1

[Stefanos Harhalakis]

Hi Mattia,

Thanks for the review.

On 23/02/16 17:45, Mattia Rizzolo wrote:

On Sun, Feb 07, 2016 at 02:06:39PM +, Stefanos Harhalakis wrote:

Dear mentors,

I am looking for a sponsor for the 1.0.1-1 release of "vbackup".
This is normally handled by Vincent Bernat but he's currently away.


Hi!

stuff I don't like and would prefer to see changed:

* please meld the 2 changelog entries, the 1 minute, 14 seconds older
   one never hit the archive anyway.


Done


* current standards-version is 3.9.7, check against it.


Done. No changes needed


* what's "Set localstatedir to /var"? I can't see anything relevant in
   the packaging part.


That's because it is now calling "dh" which does this. The previous 
version was running the configure script directly and was not passing 
--localstatedir, thus defaulting to PREFIX/var



* what are those debian/.ci-name and debian/.ci-tgz files?


Leftovers from my personal CI setup. Removed.


* in d/rules, the following is useless if you use debhelper compat 9
   (you don't):
 # see EXAMPLES in dpkg-buildflags(1) and read /usr/share/dpkg/*
 DPKG_EXPORT_BUILDFLAGS = 1
 include /usr/share/dpkg/default.mk
   why did you add them?


Removed. I don't remember if it was from the initial debian/ dir 
creation or whether they were added later by me.



* you bumped the dependency on debhelper, but compat is still 5.
   clearly, read debhelper(7) if you bump it.


Done. I read the manpage for changes between 5 and 9 and didn't notice 
anything that applies to vbackup.



* is debian/dirs really really really needed?  if it is, you build
   system is broken and you may as well fix it.


It's not. Removed


* FYI, in d/rules I personally find the following comment useless
 # main packaging script based on dh7 syntax


Cleared


* you don't do hardening, can you consider enabling it? (see
   wiki.d.o/Hardening)


I had a look and didn't see anything that applies. vbackup is purely 
shell scripts. Am I missing something?



* in d/copyright, the years are 2006-2012, I'm confident you want to
   bump them.


Corrected

The new package is in mentors and is lintian clean:

http://mentors.debian.net/package/vbackup

Do you want to give it another shot?

Thanks,
Stefanos

Bug#814008: RFS: vbackup/1.0.1-1

[Stefanos Harhalakis]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for the 1.0.1-1 release of "vbackup".
This is normally handled by Vincent Bernat but he's currently away.

 * Package name: vbackup
   Version : 1.0.1-1
   Upstream Author : me
 * URL : https://github.com/sharhalakis/vbackup
   URL : https://www.v13.gr/proj.php/vbackup
   URL : http://vbackup.readthedocs.org/en/v1.0.1/
 * License : GPLv3
   Section : admin

The package is currently in mentors and is lintian clean:

 * http://mentors.debian.net/package/vbackup
 * dget -x 
http://mentors.debian.net/debian/pool/main/v/vbackup/vbackup_1.0.1-1.dsc

It builds one package:

vbackup- modular backup utility

This is quite a large release that touches most areas of the existing code 
and adds new features. Here's the debian changelog:

vbackup (1.0.1-1) unstable; urgency=medium

  * New upstream release that unbreaks vbackup

vbackup (1.0.0-1) unstable; urgency=medium

  * New upstream release
+ Bug and various other fixes
+ New methods: md5, gpg
+ New wizards: rm, md5, scp
+ mbr: Support disks named vdX
+ Improved output
+ Switch to linked config files
+ Standardize to strategy+level naming
+ Don't consider tar exit code 1 as a failure
+ New config format without per-level config
  * Set localstatedir to /var
  * Lose build-time dependencies
  * Lose Suggests
  * Use debhelper 9
  * Standards version to 3.9.6 (no changes)

Thanks,
Stefanos

Bug#809435: Please add 9p driver and preseed option using that

[Stefanos Harhalakis]

Hi again,

I noticed that you re-added the moreinfo tag. Is there any information
other that what I sent in my previous email that you are looking for?

Thanks,
Stefanos


On Sat, Jan 16, 2016 at 6:09 PM, Geert Stappers  wrote:
> Control: merge -1  811198
> Control: tag -1 -moreinfo
> Stop
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=811198

Bug#809435: Please add 9p driver and preseed option using that

[Stefanos Harhalakis]

I agree with avoiding floppy. So, perhaps a new source uri like:
9p://tag/path, where "tag" is the virtio device tag and "path" is the path
within it.

Regarding the modules:

$ find /lib/modules/$(uname -r)/ | grep 9p
/lib/modules/3.16.0-4-amd64/kernel/net/9p
/lib/modules/3.16.0-4-amd64/kernel/net/9p/9pnet_rdma.ko
/lib/modules/3.16.0-4-amd64/kernel/net/9p/9pnet.ko
/lib/modules/3.16.0-4-amd64/kernel/net/9p/9pnet_virtio.ko
/lib/modules/3.16.0-4-amd64/kernel/fs/9p
/lib/modules/3.16.0-4-amd64/kernel/fs/9p/9p.ko

I can't see why 9pnet_rdma would be needed, so it's 9p.ko, 9pnet.ko and
9ipnet_virtio.ko. 9p also needs virtio_ring and virtio but these are
already available.



On Wed, Dec 30, 2015 at 10:50 PM, Geert Stappers <stapp...@stappers.nl>
wrote:

> Control: tag -1 Moreinfo
> stop
>
> On Wed, Dec 30, 2015 at 05:13:25PM +, Stefanos Harhalakis wrote:
>
>
> > It would be great if d-i had that and the ability to mount a virtio 9p
> > filesystem to fetch the preseed file from.
>
> What is the kernel module name for "virtio 9p filesystem"?
> What are the kernel module names for "virtio 9p filesystem"?
>
>
> > I'm not sure if the floppy:// source supports that,
>
> What are the options to avoid "floppy"?
>
> My point: Use new name for new technology.
> (in other words: please leave obsolete technology
> like floppies out of the (current) game.)
>
>
> Groeten
> Geert Stappers
> --
> Leven en laten leven
>

Bug#809435: Please add 9p driver and preseed option using that

[Stefanos Harhalakis]

Package: debian-installer

The debian 8.2. netinst image is missing the 9p FS driver.

It would be great if d-i had that and the ability to mount a virtio 9p
filesystem to fetch the preseed file from. This would make VM preseeding
much easier, as all that an installer will have to do is to expose a
directory with the preseed file.

I'm not sure if the floppy:// source supports that, as I can't test it
without the 9p driver. If it does then all that's needed is to include the
9p driver.

Thanks,
Stefanos

Bug#794573: kwin-style-breeze: broken in testing

[Stefanos Harhalakis]

reopen 794573
thanks

I'm reopening this as it is now broken in testing. This combination:

ii  kwin-x114:5.3.2-3
ii  kwin-style-breeze   4:5.3.2-2

Doesn't work and the user cannot login to a KDE5 session. The only workaround 
is to move kwin-style-breeze's
/usr/lib/x86_64-linux-gnu/qt5/plugins/org.kde.kdecoration2/breezedecoration.so 
out of the way and then go to system settings and change the style to plastik.

FWIW, I see the exact same issue with kwin-decoration-oxygen, leaving plastik 
as the only decoration that works.

Bug#774446: libnet1: possible OVERFLOW in libnet-1.1.6+dfsg (try #2)

[Stefanos Harhalakis]

Hi,

Please correct if I'm missing something here:

Both dname and dname2 have the exact same size:

int8_t dname[100];
#ifndef HAVE_DEV_DLPI
int8_t dname2[100];
#endif

dname is set here:

if (*(l-device) == '/')
{
memset(dname, 0, sizeof(dname));
strncpy(dname, l-device, sizeof(dname) - 1);
dname[sizeof(dname) - 1] = '\0';
}
else
{
sprintf(dname, %s/%s, DLPI_DEV_PREFIX, l-device);
}


The first part ensures that it is a null terminated string while the second 
part does an sprintf() from l-device which to my understanding is indirectly 
limited to IF_NAMESIZE which is 16.

In any case, I don't see how dname2 can be overflowed without overflowing 
dname first.

Can you please elaborate a bit?

Thanks,
Stefanos


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

Bug#774446: libnet1: possible OVERFLOW in libnet-1.1.6+dfsg

[Stefanos Harhalakis]

Hi,

Please correct if I'm missing something here:

Both dname and dname2 have the exact same size:

int8_t dname[100];
#ifndef HAVE_DEV_DLPI
int8_t dname2[100];
#endif

dname is set here:

if (*(l-device) == '/')
{
memset(dname, 0, sizeof(dname));
strncpy(dname, l-device, sizeof(dname) - 1);
dname[sizeof(dname) - 1] = '\0';
}
else
{
sprintf(dname, %s/%s, DLPI_DEV_PREFIX, l-device);
}


The first part ensures that it's a null terminated string while the second 
part does an sprintf() from l-device which to my understanding is indirectly 
limited to IF_NAMESIZE which is 16.

In any case, I don't 


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

Bug#751291: libnet: [ftbfs] use dh-autoreconf in order to build on new architectures

[Stefanos Harhalakis]

Hi Fernando,

Thanks for the patch.

The new version should find its way to unstable in the near future.

Thanks,
Stefanos

On Wednesday 11 June 2014 16:09:52 Fernando Seiti Furusato wrote:
 Package: src:libnet
 Severity: normal
 Tags: patch
 User: debian-powe...@lists.debian.org
 Usertags: ppc64el
 User: debian-de...@lists.debian.org
 Usertags: autoreconf
 
 
 Dear Maintainer,
 
 Package libnet fails to build from source on ppc64el, due to 
configuration
 files being out of date.
 Running autoreconf will update them accordingly and the package will 
build
 successfully.
 The patch attached includes dh-autoreconf to the build.
 
 Thank you.
 Fernando
 
 
 -- System Information:
 Debian Release: jessie/sid
   APT prefers unstable
   APT policy: (500, 'unstable')
 Architecture: ppc64el (ppc64le)
 
 Kernel: Linux 3.13-1-powerpc64le (SMP w/4 CPU cores)
 Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
 Shell: /bin/sh linked to /bin/dash

Bug#746180: python-crypto: Bug in asn1 prevents decoding DerOctetString and DerObjectId

[Stefanos Harhalakis]

Package: python-crypto
Version: 2.6.1-4
Severity: normal
Tags: patch

Hi,

/usr/lib/python2.7/dist-packages/Crypto/Util/asn1.py has the following
bug twice:

this:
p = DerObject.decode(derEle, noLeftOvers)
should be:
p = DerObject.decode(self, derEle, noLeftOvers)

Right now you end up with the following every type one tries to use
DerObjectId or DerOctetString:

  File /usr/lib/python2.7/dist-packages/Crypto/Util/asn1.py, line 274,
  in decode
  p = DerObject.decode(derEle, noLeftOvers)
  TypeError: unbound method decode() must be called with DerObject
  instance as first argument (got str instance instead)

The attached patch should be fixing this problem

-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.14.0-v2-v (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages python-crypto depends on:
ii  libc6   2.18-4
ii  libgmp102:6.0.0+dfsg-2
ii  python  2.7.5-5
pn  python:any  none

python-crypto recommends no packages.

Versions of packages python-crypto suggests:
pn  python-crypto-dbg  none
pn  python-crypto-doc  none

-- debconf-show failed
diff -Nur python-crypto-2.6.1.orig/lib/Crypto/Util/asn1.py python-crypto-2.6.1/lib/Crypto/Util/asn1.py
--- python-crypto-2.6.1.orig/lib/Crypto/Util/asn1.py	2013-10-14 22:38:10.0 +0100
+++ python-crypto-2.6.1/lib/Crypto/Util/asn1.py	2014-04-27 19:27:11.602641108 +0100
@@ -257,7 +257,7 @@
 self.payload = value
 
 def decode(self, derEle, noLeftOvers=0):
-p = DerObject.decode(derEle, noLeftOvers)
+p = DerObject.decode(self, derEle, noLeftOvers)
 if not self.isType(OCTET STRING):
 raise ValueError(Not a valid OCTET STRING.)
 return p
@@ -271,7 +271,7 @@
 DerObject.__init__(self, 'OBJECT IDENTIFIER')
 
 def decode(self, derEle, noLeftOvers=0):
-p = DerObject.decode(derEle, noLeftOvers)
+p = DerObject.decode(self, derEle, noLeftOvers)
 if not self.isType(OBJECT IDENTIFIER):
 raise ValueError(Not a valid OBJECT IDENTIFIER.)
 return p

Bug#719335: lvm2: LVM fails to detect BCACHE-based physical volumes

[Stefanos Harhalakis]

Package: lvm2
Version: 2.02.95-7
Severity: important
Tags: patch

Hi,

I started using bcache and I've experienced two problems in two
different installations, both related to LVM:

Case 1: When using LVM for the root FS and the physical volume is a
bcache device the LVM fails to detect the PV. The reason is that bcache
works with udev rules which may need some time to be triggered. More
specifically, in this case I had an MD-raid-1 and an SSD device combined
as a bcache device which is then used as PV. During the boot process LVM
runs after mdadm but that time between them is not enough for the udev
rules (inside initramfs) to present the bcache device and thus LVM does
not detect it. Adding a timetout in the initramfs lvm script does the
trick

Case 2: That's more tricky: Using LVM on an SSD. Then using one of the
LVs as the cache device for bcache which is then used as PV for LVM.
IOW: LVM over BCACHE over LVM. Here the problem is that the init scripts
need another round of VG activation in order to detect the second layer
of LVM.

The attached patch fixes both of this cases. I'm not sure if there's a
more optimal way of achieving this.

Thanks,
Stefanos

-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.10.5-v2-v (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages lvm2 depends on:
ii  dmsetup   2:1.02.74-7
ii  initscripts   2.88dsf-41
ii  libc6 2.17-7
ii  libdevmapper-event1.02.1  2:1.02.74-7
ii  libdevmapper1.02.12:1.02.74-7
ii  libreadline5  5.2+dfsg-2
ii  libudev0  175-7.2
ii  lsb-base  4.1+Debian12

lvm2 recommends no packages.

lvm2 suggests no packages.

-- Configuration Files:
/etc/init.d/lvm2 changed [not included]
/etc/lvm/lvm.conf changed [not included]

-- debconf-show failed

-- debsums errors found:
debsums: changed file /usr/share/initramfs-tools/scripts/local-top/lvm2 (from 
lvm2 package)
diff --git a/debian/lvm2.init b/debian/lvm2.init
index df599c5..0232bdd 100644
--- a/debian/lvm2.init
+++ b/debian/lvm2.init
@@ -27,7 +27,7 @@ do_start()
 case $1 in
   start)
 	log_action_begin_msg Setting up LVM Volume Groups
-	do_start
+	do_start  sleep 2  do_start
 	case $? in
 		0|1) log_action_end_msg 0 ;;
 		2) log_action_end_msg 1 ;;
diff --git a/debian/tree/lvm2/usr/share/initramfs-tools/scripts/local-top/lvm2 b/debian/tree/lvm2/usr/share/initramfs-tools/scripts/local-top/lvm2
index 8fdd1f8..3b64f63 100755
--- a/debian/tree/lvm2/usr/share/initramfs-tools/scripts/local-top/lvm2
+++ b/debian/tree/lvm2/usr/share/initramfs-tools/scripts/local-top/lvm2
@@ -24,6 +24,9 @@ activate_vg()
 		return 1
 	fi
 
+	# Wait for udev rules to present more devices
+	sleep 2
+
 	# Take care of lilo boot arg, risky activating of all vg
 	case $dev in
 	fe[0-9]*)

Bug#716922: libqt4-core: qt 4.8.5 breaks akonadi 4.10 with postgres backend

[Stefanos Harhalakis]

Package: libqt4-core
Version: 4:4.8.5+dfsg-2
Severity: important

Hello,

qt 4.8.5 is affected but this bug:

https://bugreports.qt-project.org/browse/QTBUG-30076

which causes akonadi from unstable to break when using the postgresql
backend. The only workaround is to downgrade to 4.8.4, so please don't
push this to testing.

This is the akonad error:
Error during executing query SELECT id, name FROM FlagTable WHERE (
name = ( :0 ) ) :  ERROR:  invalid input syntax for type bytea
LINE 1: EXECUTE qpsqlpstmt_54 ('\SEEN')

which AFAICT makes akonadi unable to store/alter flags.

Thanks,
Stefanos

-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.9.9-v2-v (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages libqt4-core depends on:
ii  libqt4-dbus 4:4.8.5+dfsg-2
ii  libqt4-network  4:4.8.5+dfsg-2
iu  libqt4-script   4:4.8.4+dfsg-4
ii  libqt4-test 4:4.8.5+dfsg-2
ii  libqt4-xml  4:4.8.5+dfsg-2
iu  libqtcore4  4:4.8.4+dfsg-4

libqt4-core recommends no packages.

libqt4-core suggests no packages.

-- debconf-show failed


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

Bug#682590: hmm

[Stefanos Harhalakis]

So I had another look at this and something doesn't add up.

I believe that the CVE is for CNs with / in them while the code checks the 
textual representation of the whole subject.

For example, when you have C=UK CN=test.v13.gr you end up having a textual 
representation of /C=UK/CN=test.v13.gr which fails the check because of the 
/ in it but does not seem to fall within CVE's description.

I believe the problem lies in lib/puppet/ssl/certificate.rb which uses as name 
the full name instead of just CN.

Puppet's internal CA doesn't have this problem because it only adds CN to the 
subject. The patch is supposed to strip everything before and after the CN=xxx 
part.

Please consider the attached patch which I believe changes the representation 
of the certificate name to be just the CN field. There's a bug in it in case 
another field contains the string CN= in it, which will result in a failure to 
match the certificate name but I believe this is minor, hard to work around 
and not a security risk.

If you have a close look you'll see that puppet was already stripping the CN= 
part but was failing miserably when there were other parts in the subject or 
the issuer.

p.s. I don't claim to have any knowledge of puppet's code. This is just a 
quick hack so standard disclaimers apply.

Thanks,
Stefanos
diff -Nur puppet-2.7.18.orig/lib/puppet/ssl/certificate.rb puppet-2.7.18/lib/puppet/ssl/certificate.rb
--- puppet-2.7.18.orig/lib/puppet/ssl/certificate.rb	2012-07-09 23:08:16.0 +0100
+++ puppet-2.7.18/lib/puppet/ssl/certificate.rb	2013-04-16 01:48:08.763992157 +0100
@@ -15,7 +15,7 @@
   # Convert a string into an instance.
   def self.from_s(string)
 instance = wrapped_class.new(string)
-name = instance.subject.to_s.sub(/\/CN=/i, '').downcase
+name = instance.subject.to_s.sub(/.*\/CN=([^\/]*)($|\/.*)/i, '\n').downcase
 result = new(name)
 result.content = instance
 result

Bug#682590: correct patch

[Stefanos Harhalakis]

Please ignore the previous patch and consider this one.

There's a typo in the previous one.

diff -Nur puppet-2.7.18.orig/lib/puppet/ssl/certificate.rb puppet-2.7.18/lib/puppet/ssl/certificate.rb
--- puppet-2.7.18.orig/lib/puppet/ssl/certificate.rb	2012-07-09 23:08:16.0 +0100
+++ puppet-2.7.18/lib/puppet/ssl/certificate.rb	2013-04-16 02:12:59.369573970 +0100
@@ -15,7 +15,7 @@
   # Convert a string into an instance.
   def self.from_s(string)
 instance = wrapped_class.new(string)
-name = instance.subject.to_s.sub(/\/CN=/i, '').downcase
+name = instance.subject.to_s.sub(/.*\/CN=([^\/]*)($|\/.*)/i, '\1').downcase
 result = new(name)
 result.content = instance
 result

Bug#682590: Any update

[Stefanos Harhalakis]

Hi,

I'm changing the severity of this bug since I believe that it is a huge issue 
(with a tiny fix).

AFAIK it makes puppet unusable when one uses his own CA since it looks that 
puppet server or agents will reject any certificates that include a / in the 
textual representation of the subject or the issuer, which in turn are 
practically all certificates.


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

Bug#682590: patch

[Stefanos Harhalakis]

And in case it helps more, here's the full patch.
diff -Nur puppet-2.7.18.orig/lib/puppet/ssl/base.rb puppet-2.7.18/lib/puppet/ssl/base.rb
--- puppet-2.7.18.orig/lib/puppet/ssl/base.rb	2012-07-10 00:36:29.0 +0100
+++ puppet-2.7.18/lib/puppet/ssl/base.rb	2013-04-13 23:01:44.245916200 +0100
@@ -6,7 +6,7 @@
   SEPARATOR = \n---\n
 
   # Only allow printing ascii characters, excluding /
-  VALID_CERTNAME = /\A[ -.0-~]+\Z/
+  VALID_CERTNAME = /\A[ -.0-~\/]+\Z/
 
   def self.from_multiple_s(text)
 text.split(SEPARATOR).collect { |inst| from_s(inst) }

Bug#682590: patch

[Stefanos Harhalakis]

Gr. It's never easy...
I'll try to find a solution but I don't promise anything.


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

On Sat, 2013-04-13 at 23:03 +0100, Stefanos Harhalakis wrote:
 And in case it helps more, here's the full patch.

The upstream bug to which this bug is marked as forwarded indicates
that
simply updating the expression to include / (as per your suggested
patch) would reintroduce CVE-2012-3867, which doesn't seem like an
ideal
solution.

See http://projects.puppetlabs.com/issues/15561#note-13 for reference.

Regards,

Adam


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

Bug#702534: libnet: FTBFS on x32: Needs libtool update

[Stefanos Harhalakis]

On Thursday 07 March 2013, Daniel Schepler wrote:
 The fix is to update libtool using the current sid package (=
 2.4.2-1.2).  The attached debdiff does this at build time using
 dh-autoreconf.

Thanks for the patch.

I'll upload a new package soon.

Cheers,
Stefanos


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

Bug#682590: puppetmaster: puppet stopped working for existing certificates that contain / in their subject

[Stefanos Harhalakis]

Package: puppetmaster
Version: 2.7.18-1
Severity: important
Tags: upstream

Dear Maintainer,

Since the latest upgrade I've been bitten by puppet bug #15561

http://projects.puppetlabs.com/issues/15561

The following used to work just fine:

# puppet kick 
Triggering 
Host  failed: Certname
... subject ... must not contain unprintable or non-ASCII characters
 finished with exit code 2
Failed: 

I am using a custom (not managed by puppet) CA. The problem seems to be
triggered by the fact that CN includes a / in it. As mentioned in the
puppet bug report this is a very common thing.

The issue is that it makes puppet unusable for existing installations
and since this is going to be in Wheezy it may end up braking for a lot
of people's installations that will upgrade.

The bug is accepted upstream and it seems that it will be fixed in the
2.7 series.

Please consider this an RC bug.

Thanks,
Stefanos

-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.4.3-v2-v (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages puppetmaster depends on:
ii  puppetmaster-common  2.7.18-1
ii  ruby1.8  1.8.7.358-4

puppetmaster recommends no packages.

puppetmaster suggests no packages.

-- 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#682590: fix

[Stefanos Harhalakis]

FWIW, the fix is to change /usr/lib/ruby/vendor_ruby/puppet/ssl/base.rb:

-  VALID_CERTNAME = /\A[ -.0-~]+\Z/
+  VALID_CERTNAME = /\A[ -.0-~\/]+\Z/

(i.e. add / to permitted characters).


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

Bug#628796: fsprotect: /bin/touch missing in initrd

[Stefanos Harhalakis]

Hi,

On Sat, Mar 3, 2012 at 16:44, Cyril Brulebois k...@debian.org wrote:
 Julien Cristau jcris...@debian.org (01/01/2012):
 On Fri, Jun  3, 2011 at 10:55:08 +0300, V13 wrote:
  Thanks for the report. I'll fix it in the next release.
 any ETA for this fix?

 ping again?

This is now in mentors, but needs some cleanups before going for sponsorship.



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

Bug#607870: cgroup-bin: Perhaps use tmpfs for /sys/fs/cgroup to avoid problems

[Stefanos Harhalakis]

Package: cgroup-bin
Version: 0.37-1
Severity: important


Hello,

The default installation seems to use (in /etc/cgconfig.con):

cpu = /sys/fs/cgroup
cpuacct = /sys/fs/cgroup/cpuacct
etc...

Is will be cleaner to use a small tmfs mount for /sys/fs/cgroup and then change
the above to:

cpu = /sys/fs/cgroup/cpu
cpuacct = /sys/fs/cgroup/cpuacct
etc...

The above also causes problems when restarting cgconfig. Using strace it seems
that cgconfigparser attempts to rmdir /sys/fs/cgroup (because it is listed in
the 'cpu' line) which is not permitted and it fails.

Just changing 'cpu' entry (without using a tmpfs mount point) does not fix
the problem because it is not possible to create dirs under /sys/fs/cgroup.

The problems makes reloading of /etc/cgconfig.conf impossible since
/etc/init.d/cgconfig restart fails.

Using a small tmpfs seems to solve this. It also solves a minor problem with
/etc/init.d/cgred which fails if none of the mounted cgroup partitions
is mounted as 'cgroup'. For example, using:

mount -t cgroup -o cpu none /sys/fs/cgroup

will make /etc/init.d/cgred restart fail because of line 80:

if ! grep ^cgroup /proc/mounts /dev/null; then

which expects a mount like this one:

mount -t cgroup -o cpu cgroup /sys/fs/cgroup

Thus, the tmpfs should be mounted with:

mount -t tmpfs -o size=1M,mode=755 cgroup /sys/fs/cgroup

and it will make the rest of cgroup mountings immune to the init.d/cgred
problem.

Testing the tmpfs existance is also easy since a touch under it will fail
if it is not mounted:

if ! touch /sys/fs/cgroup/.test 21 ; then
mount -t tmpfs -o size=1M,mode=755 cgroup /sys/fs/cgroup
else
rm -f /sys/fs/cgroup/.test
fi

-- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 
'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.36-v2-v (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages cgroup-bin depends on:
ii  libc6 2.11.2-7   Embedded GNU C Library: Shared lib
ii  libcgroup10.37-1 A library to control and monitor c

cgroup-bin recommends no packages.

cgroup-bin suggests no packages.

-- Configuration Files:
/etc/cgconfig.conf changed [not included]
/etc/cgrules.conf changed [not included]
/etc/default/cgred 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#601207: clarification

[Stefanos Harhalakis]

Michal,

FWIW, Cyril seems to refer to your version 
(7.9.0+git20100903.a5fd0396-0ubuntu0sarvatt)
while you refer to the mesa version (7.9). Perhaps you should fill a bug 
report against a valid debian version (e.g. 7.8.2-2), where the wish actually 
applies.

He is right because you filled this bug against a package version (see the top 
of: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=601207) that doesn't 
exist in debian.



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

Bug#524403: ITP: iguanair -- IguanaWorks Infrared Tranceiver support tools

[Stefanos Harhalakis]

Hello Max,

(Yes, two months for a reply is a long time :-)

On Saturday 31 of July 2010, Max Vozeler wrote:
 I recently got a iguanaIR USB and would like to have it
 supported without the need to rebuild lirc.
 
 Stefanos, are you still interested? Let me know if you
 need review and/or sponsorship. I'm happy to help but lack
 the time to maintain it properly myself.

After your mail I tried to package iguanaIR but I failed. While everything 
else seems OK, I can't package the python bindings. Is there any documentation 
on how python bindings are supposed to be packaged? I've looked some other 
packages and they seem to do some hocus pocus for this.

I understand that there should be one package (with the bindings) per python 
version but I don't know which python versions I'm supposed to package for and 
how to incorporate this to CDBS (iguanaIR isn't using distutils).

While I'm not as inderested as before and I somehow lack the time, I'm willing 
to complete the packaging and maintain the package. I've found the creators of 
iguanaIR to be helpfull and they look forward for a debian package so any bugs 
etc will most probably be handled by them. Since the releases of iguanaIR 
software are not frequent this will not be very time consiming.

So, if you can help me with the python bindings packaging we can upload this 
soon. I'm currently using CDBS for the packaging.



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

Bug#418975: #418975 affects stable

[Stefanos Harhalakis]

Hello,

On Wednesday 19 of May 2010, Faidon Liambotis wrote:
 Ping?

Does the attached patch work?

If not I'd like to have a test case (either a sample program or step-by-step 
instructions) in order to reproduce the bug. Just installing heartbeat isn't 
enough since IPv6Addr gives:

# ./IPv6addr 2000::1 start
IPv6addr[16323]: ERROR:  Generic error
ERROR:  Generic error

(even with 1.1.4-2)
diff -ur libnet-1.1.2.1.orig//src/libnet_build_ip.c libnet-1.1.2.1/src/libnet_build_ip.c
--- libnet-1.1.2.1.orig//src/libnet_build_ip.c	2004-03-16 20:40:59.0 +0200
+++ libnet-1.1.2.1/src/libnet_build_ip.c	2010-05-24 21:54:09.374852597 +0300
@@ -520,8 +520,12 @@
 }
 
 /* no checksum for IPv6 */
-return (ptag ? ptag : libnet_pblock_update(l, p, LIBNET_IPV6_H,
-LIBNET_PBLOCK_IPV6_H));
+ptag = ptag ? ptag : libnet_pblock_update(l, p, LIBNET_IPV6_H,
+	LIBNET_PBLOCK_IPV6_H);
+
+libnet_pblock_record_ip_offset(l, p);
+
+return(ptag);
 bad:
 libnet_pblock_delete(l, p);
 return (-1);

Bug#576942: #576942: /boot/vmlinuz-2.6.32-3-amd64: kernel fix for wrong mtrr mask from MS-7252 bios may be wrong and cause problems with fglrx-driver

[Stefanos Harhalakis]

While watching this conversation, I've some comments:

a) The kernel only prints a backtrace. It is not an OOPS or a BUG(). It is 
just a backtrace because the message mtrr: your BIOS has set up an incorrect 
mask, fixing it up. is printed using the WARN_ONCE() macro. Thus, I don't see 
how it can be classified as a kernel bug. At worst, the bug will have to do 
with using WARN_ONCE.

b) Perhaps you could try using nopat as kernel argument. I believe that 
since PAT is used by fglrx, mtrr should have no effect (no? - I'm no expert), 
but who knows. Also, play with fglrx's argument for pat.

c) Perhaps try adding: Option NoMTRR to the screen section of xorg.conf for 
testing.

If (b) works then this may be a kernel bug, irrelevant with the backtrace.

if (c) works then this *may* be an Xorg bug.



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

Bug#418975: #418975 affects stable

[Stefanos Harhalakis]

Hello,

Does the patch of message #77 fix your problem?



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

Bug#566161: fsprotect: uninstallable in sid, depends on kernel component

[Stefanos Harhalakis]

Hello,

On Thursday 21 of January 2010, Julien Cristau wrote:
 fsprotect depends on aufs-modules which is not in sid (and soon not in
 testing).  Besides, to quote one of the kernel maintainers, User-space
 packages should never depend on kernel components, because the kernel
 might be provided from outside the system (e.g. for a chroot'd
 environment).  Please remove this dependency (fsprotect is being
 removed from testing temporarily because of this, to let the 2.6.32
 kernel into squeeze).

So you suggest that fsprotect should perform run-time detection of aufs 
instead?




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

Bug#564138: fsprotect: It also runs with NFS Root.

[Stefanos Harhalakis]

Thanks for the tip. I never considered fsprotect for NFS. I'll include that in 
the next version.





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

Bug#558597: proftpd ssl problem

[Stefanos Harhalakis]

Hello,

I also have this problem.

Looking at the source code, proftpd assumes that ssl renegotiation only needs 
to be enabled with openssl =0.8.9l (Testing/Unstable have 0.8.9k where it is 
enabled). However, upload of 0.8.9k-6 for debian disabled that:

openssl (0.9.8k-6) unstable; urgency=low

  * Disable SSL/TLS renegotiation (CVE-2009-3555) (Closes: #555829)

 -- Kurt Roeckx k...@roeckx.be  Thu, 12 Nov 2009 18:10:31 +

Proftpd needs to be changed to enable renegotiations even with the current 
debian version of openssl. 

This may also need to be accompanied by a modification in the Depends  for 
proper openssl version.



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

Bug#561640: root directory has mode rwxrwxrwt

[Stefanos Harhalakis]

On Tuesday 22 of December 2009, Phil Vandry wrote:
 On Tue, 22 Dec 2009 16:04:24 +0200, Harhalakis Stefanos wrote:
   $ ls -ld /
   drwxrwxrwt 7 root root 160 2009-12-18 21:40 .
 
  This does not seem easy to exploit because of the sticky bit. No?
 
 You're right. The problem is less serious because of the sticky bit.
 
 One way that you could still exploit it though would be to create
 trojan directories in the tmpfs branch directly, like /fsprotect/tmp/usr .

I tried that already and it seems that aufs doesn't see the new directory at 
once. For example, I created /fsprotect/tmp/sbin/getty in order to get init 
execute my own getty but /sbin/getty was still the getty from the original 
filesystem.

 Thanks for creating this tool, by the way. I'm glad someone spent the
 time to figure out the gymnastics of bind-mounting and moving directories
 around to get it working correctly and cleanly inside the initramfs.

You're welcome!




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

Bug#555636: Fix pending

[Stefanos Harhalakis]

Hello,

This bug will be closed by the next fsprotect version which is currently in 
mentors. I've contacted my sponsor so it is a matter of time to be uploaded.



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

Bug#545991: Installation error

[Stefanos Harhalakis]

Hello,

Since you asked, this is the error of a munin-node installation without
python:

dias:/# apt-get install munin-node
Reading package lists... Done
Building dependency tree   
Reading state information... Done
The following extra packages will be installed:
  gawk libio-multiplex-perl libnet-cidr-perl libnet-server-perl libnet-snmp-perl
Suggested packages:
  libio-socket-ssl-perl libcrypt-des-perl libdigest-hmac-perl 
libdigest-sha1-perl libio-socket-inet6-perl munin
  munin-plugins-extra libwww-perl liblwp-useragent-determined-perl 
libnet-irc-perl smartmontools acpi lm-sensors python
  ethtool libdbd-pg-perl
The following NEW packages will be installed:
  gawk libio-multiplex-perl libnet-cidr-perl libnet-server-perl 
libnet-snmp-perl munin-node
0 upgraded, 6 newly installed, 0 to remove and 0 not upgraded.
Need to get 1673kB of archives.
After this operation, 4442kB of additional disk space will be used.
Do you want to continue [Y/n]? 
Get:1 http://ftp.ntua.gr lenny/main gawk 1:3.1.5.dfsg-4.1 [721kB]
Get:2 http://ftp.ntua.gr lenny/main libio-multiplex-perl 1.09-2 [21.9kB]
Get:3 http://ftp.ntua.gr lenny/main libnet-cidr-perl 0.11-3 [14.8kB]
Get:4 http://ftp.ntua.gr lenny/main libnet-server-perl 0.97-1 [141kB]
Get:5 http://ftp.ntua.gr lenny/main libnet-snmp-perl 5.2.0-1 [112kB]
Get:6 http://ftp.ntua.gr lenny/main munin-node 1.2.6-10~lenny1 [662kB]
Fetched 1673kB in 0s (2071kB/s)
Selecting previously deselected package gawk.
(Reading database ... 16528 files and directories currently installed.)
Unpacking gawk (from .../gawk_1%3a3.1.5.dfsg-4.1_amd64.deb) ...
Selecting previously deselected package libio-multiplex-perl.
Unpacking libio-multiplex-perl (from .../libio-multiplex-perl_1.09-2_all.deb) 
...
Selecting previously deselected package libnet-cidr-perl.
Unpacking libnet-cidr-perl (from .../libnet-cidr-perl_0.11-3_all.deb) ...
Selecting previously deselected package libnet-server-perl.
Unpacking libnet-server-perl (from .../libnet-server-perl_0.97-1_all.deb) ...
Selecting previously deselected package libnet-snmp-perl.
Unpacking libnet-snmp-perl (from .../libnet-snmp-perl_5.2.0-1_all.deb) ...
Selecting previously deselected package munin-node.
Unpacking munin-node (from .../munin-node_1.2.6-10~lenny1_all.deb) ...
Processing triggers for man-db ...
Setting up gawk (1:3.1.5.dfsg-4.1) ...
Setting up libio-multiplex-perl (1.09-2) ...
Setting up libnet-cidr-perl (0.11-3) ...
Setting up libnet-server-perl (0.97-1) ...
Setting up libnet-snmp-perl (5.2.0-1) ...
Setting up munin-node (1.2.6-10~lenny1) ...
Adding system user `munin' (UID 106) ...
Adding new group `munin' (GID 108) ...
Adding new user `munin' (UID 106) with group `munin' ...
Not creating home directory `/var/lib/munin'.
Initializing plugins..# There were some errors:
# Got junk from smart_: /usr/bin/env: python: No such file or directory
failed.
done.
Starting Munin-Node: done.



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

Bug#429394: linux-image-2.6.18-4-686-bigmem: STIME of ps output for a process is not constant

[Stefanos Harhalakis]

Hello and sorry for the long-delay. Kmail removed the 'to-do' flag of this 
mail after a crash and i forgotten it.

On Friday 14 August 2009, Moritz Muehlenhoff wrote:
 On Tue, Dec 16, 2008 at 02:04:45AM +0200, Stefanos Harhalakis wrote:
  On Monday 15 December 2008, Moritz Muehlenhoff wrote:
   Does this error still occur with more recent kernel versions?
  
   If you're running Etch, could you try to reproduce this bug
   with the 2.6.24 based kernel added in 4.0r4?
   http://packages.qa.debian.org/l/linux-2.6.24.html
 
  I'm sorry but I don't know of a way to reproduce this on-demand, even on
  the same machine with the same kernel. I know that this is an ugly bug
  report but I can only report further similar problems or perhaps try to
  automate this in a way.
 
  To make this harder, ps shows the date instead of the time a process
  started when there are more than 24h passed and thus I cannot test it
  with other processes. This is a server machine that I cannot reboot for
  testing.
 
 Has this error re-occured in the mean time?

I cannot reproduce it (I never could) and I haven't noticed it again. Since 
AFAIK there are a lot of changes in kernel timming code since 2.6.18, I 
suggest you close this bug and I'll re-report it if I see it again.

Thanks!



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

Bug#546933: [Pkg-fglrx-devel] Bug#546933: fglrx-source: module fails to load on vanilla 2.6.31 kernel

[Stefanos Harhalakis]

Hello,

On Wednesday 16 September 2009, Giacomo Mulas wrote:
 Package: fglrx-source
 Version: 1:9-9-1
 Severity: normal
 
 I just rebooted my laptop with the latest 2.6.31 (vanilla) kernel, built
 with make-kpkg, and found out that the fglrx module cannot be loaded
 because:
 
 [ 1759.237455] fglrx: Unknown symbol find_task_by_vpid
 
 I will now try to understand whether this is a regression introduced in
 version 9-9-1 of fglrx or it depends on changes in the kernel upon going
 2.6.31 - 2.6.31.

I've also tried fglrx with 2.6.31 and indeed this problem exists. It is 
introduced by 2.6.31 but it is easy to fix. However, the fglrx driver is 
unstable and causes freezes. For me (ati 4870) it freezes instantly with an 
oops when I run glxgears or fgl_glxgears. Others get freezes without even 
trying. There is an unofficial 'ubuntu' preview-version of fglrx 9.10 which is 
said to be working with 2.6.31.

The freeze only affects the screen. The system is operational and can be 
rebooted via network.

I suggest downgrading to 2.6.30 until 9.10 is released (that's what I did).



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

Bug#538814: invalid map handle

[Stefanos Harhalakis]

Hello,

I'm using ATI's fglrx 9.6 driver (not debian's) with some custom patching and 
it works for me even with Invalid map handle errors. This probably means 
that this message is not fatal and it is not the one that causes the 
segmentation fault.

FWIW: The invalid map handle seems to be something that accumulates over time 
and degrades graphics performance. It is highly produced when using KDE's 
openGL based effects.

I use xserver-xorg 7.4+3 on amd64.




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

Bug#536202: libnet: TCP header fields not correct on 64 bit machines

[Stefanos Harhalakis]

Hello,

On Wednesday 08 July 2009, Fabrice Coutadeur wrote:
 Applicable packages:
 dsniff 2.4b1+debian-18
 libnet1 1.1.2.1-4
 libc6 2.9-4ubuntu6

 Recommended course of action:
 libnet-headers.h specifies fields in TCP structures as u_char, u_short and
 u_long, which are interpreted as 8-bit, 16-bit and 64-bit numbers
 respectively
 on a 64-bit machine. These should be changed to uint8_t, uint16_t and
 uint32_t
 respectively for compatibility with 64-bit machines.

First of all, the debian stable version is 1.1.2.1-2 and the debian testing 
version is 1.1.4-2. There is no current 1.1.2.1-4 version:

http://packages.debian.org/search?keywords=libnet1

Apart from that, I could not find the problem you're reporting. There is no 
u_short or u_char in libnet-headers.h in current stable (1.1.2.1-2) and 
testing (1.1.4-2) versions.

Perhaps you've a stale libnet-headers.h or a copyied file? Are you examining 
/usr/include/libnet/libnet-headers.h ? If so, you can check the md5sums with:

debsums libnet1-dev




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

Bug#534437: arping segfault with multiple interface and not -i switch in command line options

[Stefanos Harhalakis]

Hello,

On Friday 26 June 2009, Giuseppe Iuculano wrote:
 reassign 534437 libnet 1.1.4-1
 retitle 534437 multiple libnet_init() causes libnet 1.1.4-1 to SEGV

I believe I've found the bug. The following patch seems to fix it. I've made a 
new version (1.1.4-2) of libnet so test that one when it will be available.

If you're in hurry you can get the not-yet-uploaded sources:

dget -u http://mentors.debian.net/debian/pool/main/l/libnet/libnet_1.1.4-2.dsc

and build it yourself.

Here's the patch:

--- libnet-1.1.4.orig/src/libnet_if_addr.c  2009-06-27 14:48:56.084093427 
+0300
+++ libnet-1.1.4/src/libnet_if_addr.c   2009-06-27 14:49:30.081249393 +0300
@@ -240,6 +240,7 @@
 {
 /* fix memory leak */
 free(al-device);
+   al-device = NULL;
 }
 if ((al-device = strdup(device)) == NULL)
 {
@@ -406,6 +407,7 @@
 for (i = 0; i  c; i++)
 {
 free(al[i].device);
+   al[i].device = NULL;
 }
 return (1);
 
@@ -413,6 +415,7 @@
 for (i = 0; i  c; i++)
 {
 free(al[i].device);
+   al[i].device = NULL;
 }
 return (-1);
 }




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

Bug#530241: Fwd: Re: Bug#530241: does not parse errors=remount-ro option

[Stefanos Harhalakis]

Hello,

On Monday 25 May 2009, martin f krafft wrote:
 also sprach Stefanos Harhalakis v...@v13.gr [2009.05.23.1432 +0200]:
  mount -n -o move ... done.
 
  If it is shown before, it will be helpfull to tell me after which
  line. There will be a pause of 3 seconds after the 'done.' message
  but I suggest you also press ctrl-S at that point.

 The problem happens later:

 Fast boot enabled, so skipping file system check. (warning).
 [   81.434677] aufs au_opts_parse:1042:mount[1697]: unknown option
 errors=remount-ro [   81.441904] aufs au_opts_parse:1042:mount[1698]:
 unknown option errors=remount-ro mount: / not mounted already, or bad
 option

 This is due to /etc/rcS.d/S10checkroot.sh, which remounts the root
 filesystem.

That was what I thought. I reproduced it and unfortunately I don't see a 
standard way for avoiding this. I believe that the lines that case the problem 
in checkroot.sh are the following:

if ! mount -n -o remount,$rootopts,$rootmode $fstabroot / 2/dev/null
then
mount -n -o remount,$rootopts,$rootmode /
fi

The only fixes that I can think of are:
a) Ask initscripts' authors to add a check for already r/w root filesystem and 
leave the root filesystem r/w.
b) On-the-fly change fstab to remove extra options.

I find (b) to be the easiest approach but I'm not sure that it won't cause 
problems. Any thoughts on that?

 PS: why do you --bind mount /fsprotect/aufs to /root instead of
 using --move?

Good point. I changed that.

p.s. I'm CC'ing this to the bug report address to keep track of the 
conversation. It may be usefull for future reference.




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

Bug#530241: Fwd: Re: Bug#530241: does not parse errors=remount-ro option

[Stefanos Harhalakis]

On Monday 25 May 2009, martin f krafft wrote:
  The only fixes that I can think of are:
  a) Ask initscripts' authors to add a check for already r/w root
  filesystem and leave the root filesystem r/w.
  b) On-the-fly change fstab to remove extra options.
 
  I find (b) to be the easiest approach but I'm not sure that it won't
  cause problems. Any thoughts on that?

 No, definitely do not touch (b).

Remeber that the change will happen inside the protected filesystem and will 
be lost at the next boot.

 I think (c) would be best:

 (c) fix aufs to support errors=remount-ro, and even if it justs
 ignores the option. After all, I am unsure what errors mean in
 a tmpfs context.

It's only related to aufs. tmpfs never gets those options. After the 
fsprotect's initramfs script runs, the new root filesystem is an aufs 
filesystem. When the checkroot attempts to remount it read-write it passes the 
existing options to mount, which are not recognized by aufs. This happens with 
other options too. I tested it with reiserfs' notail option.

I don't believe that making aufs ignore all unrecognized options is the 
correct way to solve it. It will introduce problems to all people using it 
when they pass wrong options. AFAIK XFS did a similar change recently, 
ignoring all unknown options on remount (a quickdirty test just verified 
this), but I'm not sure about this either.

  p.s. I'm CC'ing this to the bug report address to keep track of the
  conversation. It may be usefull for future reference.

 If you set your Mail-Followup-To header correctly, then I would have
 replied too. ;)

Changing M-F-T for each mail with kmail is practically impossible. Mutt is 
more flexible with this.




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

Bug#530245: udev: Fix of bug #462655 should be ported to lenny

[Stefanos Harhalakis]

Package: udev
Version: 0.141-1
Severity: critical
Tags: security
Justification: root security hole


Bug #462655 also affects lenny.

I believe that it should be ported to lenny too since:
a) It is security related
b) Most aacraid-related controllers are on servers which tend to use stable

-- Package-specific info:
-- /etc/udev/rules.d/:
/etc/udev/rules.d/:
total 220
lrwxrwxrwx 1 root root23 2008-09-17 17:34 010-no-legacy-ptys.rules - 
../no-legacy-ptys.rules
lrwxrwxrwx 1 root root20 2008-09-17 16:45 025_libchipcard.rules - 
../libchipcard.rules
lrwxrwxrwx 1 root root19 2008-09-17 16:45 025_libgphoto2.rules - 
../libgphoto2.rules
lrwxrwxrwx 1 root root15 2008-09-17 16:45 025_lomoco.rules - 
../lomoco.rules
lrwxrwxrwx 1 root root16 2008-09-17 16:45 030_ifplugd.rules - 
../ifplugd.rules
lrwxrwxrwx 1 root root13 2008-09-17 17:31 035_kino.rules - ../kino.rules
-rw-r--r-- 1 root root  1137 2008-10-01 17:33 65_dmsetup.rules
-rw-r--r-- 1 root root   991 2008-09-17 16:45 65_mdadm.vol_id.rules
-rw-r--r-- 1 root root  3436 2009-03-06 07:51 70-persistent-cd.rules
-rw-r--r-- 1 root root  1652 2009-05-02 00:08 70-persistent-net.rules
-rw-r--r-- 1 root root   283 2009-03-25 23:52 85_dmraid.rules
lrwxrwxrwx 1 root root16 2008-09-17 16:45 libmtp7.rules - ../libmtp7.rules
lrwxrwxrwx 1 root root15 2008-09-17 16:45 libnjb.rules - ../libnjb.rules
-rw-r--r-- 1 root root   550 2008-09-18 16:21 xpp.rules
-rw-r--r-- 1 root root   505 2008-09-17 16:45 xpp.rules.dpkg-old
lrwxrwxrwx 1 root root17 2008-09-17 16:45 z33_v.rules - ../v-custom.rules
lrwxrwxrwx 1 root root30 2008-09-17 17:31 z55_alsa-firmware-loaders.rules 
- ../alsa-firmware-loaders.rules
lrwxrwxrwx 1 root root19 2008-09-17 16:45 z60_alsa-utils.rules - 
../alsa-utils.rules
-rw-r--r-- 1 root root  2079 2009-04-08 18:20 z60_gpsd.rules
lrwxrwxrwx 1 root root15 2008-09-17 16:45 z60_hdparm.rules - 
../hdparm.rules
-rw-r--r-- 1 root root  5354 2009-03-17 12:09 z60_hplip.rules
-rw-r--r-- 1 root root   590 2009-05-17 19:13 z60_iguanair.rules
-rw-r--r-- 1 root root  1240 2009-04-06 21:06 z60_kpartx.rules
-rw-r--r-- 1 root root  2589 2008-09-17 16:45 z60_libpisock9.rules
-rw-r--r-- 1 root root  1152 2009-05-06 15:26 z60_libsane-extras.rules
-rw-r--r-- 1 root root 72908 2009-03-04 12:03 z60_libsane.rules
-rw-r--r-- 1 root root 72908 2008-09-17 16:45 z60_libsane.rules.dpkg-old
-rw-r--r-- 1 root root  7117 2009-04-12 00:32 z60_xserver-xorg-input-wacom.rules
-rw-r--r-- 1 root root  6661 2008-09-17 16:45 
z60_xserver-xorg-input-wacom.rules.dpkg-old
-rw-r--r-- 1 root root   217 2008-09-17 16:45 zaptel.perms

-- /sys/:
/sys/block/dm-0/dev
/sys/block/dm-1/dev
/sys/block/dm-2/dev
/sys/block/dm-3/dev
/sys/block/dm-4/dev
/sys/block/fd0/dev
/sys/block/md10/dev
/sys/block/md11/dev
/sys/block/md12/dev
/sys/block/md13/dev
/sys/block/md1/dev
/sys/block/md5/dev
/sys/block/md6/dev
/sys/block/md7/dev
/sys/block/md8/dev
/sys/block/md9/dev
/sys/block/nbd0/dev
/sys/block/nbd10/dev
/sys/block/nbd11/dev
/sys/block/nbd12/dev
/sys/block/nbd13/dev
/sys/block/nbd14/dev
/sys/block/nbd15/dev
/sys/block/nbd1/dev
/sys/block/nbd2/dev
/sys/block/nbd3/dev
/sys/block/nbd4/dev
/sys/block/nbd5/dev
/sys/block/nbd6/dev
/sys/block/nbd7/dev
/sys/block/nbd8/dev
/sys/block/nbd9/dev
/sys/block/ram0/dev
/sys/block/ram10/dev
/sys/block/ram11/dev
/sys/block/ram12/dev
/sys/block/ram13/dev
/sys/block/ram14/dev
/sys/block/ram15/dev
/sys/block/ram1/dev
/sys/block/ram2/dev
/sys/block/ram3/dev
/sys/block/ram4/dev
/sys/block/ram5/dev
/sys/block/ram6/dev
/sys/block/ram7/dev
/sys/block/ram8/dev
/sys/block/ram9/dev
/sys/block/sda/dev
/sys/block/sda/sda10/dev
/sys/block/sda/sda11/dev
/sys/block/sda/sda12/dev
/sys/block/sda/sda13/dev
/sys/block/sda/sda1/dev
/sys/block/sda/sda2/dev
/sys/block/sda/sda3/dev
/sys/block/sda/sda5/dev
/sys/block/sda/sda6/dev
/sys/block/sda/sda7/dev
/sys/block/sda/sda8/dev
/sys/block/sda/sda9/dev
/sys/block/sdb/dev
/sys/block/sdb/sdb10/dev
/sys/block/sdb/sdb11/dev
/sys/block/sdb/sdb12/dev
/sys/block/sdb/sdb13/dev
/sys/block/sdb/sdb1/dev
/sys/block/sdb/sdb2/dev
/sys/block/sdb/sdb3/dev
/sys/block/sdb/sdb5/dev
/sys/block/sdb/sdb6/dev
/sys/block/sdb/sdb7/dev
/sys/block/sdb/sdb8/dev
/sys/block/sdb/sdb9/dev
/sys/block/sdc/dev
/sys/block/sdc/sdc10/dev
/sys/block/sdc/sdc11/dev
/sys/block/sdc/sdc12/dev
/sys/block/sdc/sdc13/dev
/sys/block/sdc/sdc1/dev
/sys/block/sdc/sdc2/dev
/sys/block/sdc/sdc3/dev
/sys/block/sdc/sdc5/dev
/sys/block/sdc/sdc6/dev
/sys/block/sdc/sdc7/dev
/sys/block/sdc/sdc8/dev
/sys/block/sdc/sdc9/dev
/sys/block/sdd/dev
/sys/block/sdd/sdd10/dev
/sys/block/sdd/sdd11/dev
/sys/block/sdd/sdd12/dev
/sys/block/sdd/sdd13/dev
/sys/block/sdd/sdd1/dev
/sys/block/sdd/sdd2/dev
/sys/block/sdd/sdd3/dev
/sys/block/sdd/sdd5/dev
/sys/block/sdd/sdd6/dev
/sys/block/sdd/sdd7/dev
/sys/block/sdd/sdd8/dev
/sys/block/sdd/sdd9/dev
/sys/block/sde/dev
/sys/block/sde/sde1/dev
/sys/block/sdf/dev
/sys/block/sdf/sdf1/dev
/sys/block/sdf/sdf2/dev
/sys/block/sdf/sdf3/dev

Bug#530242: disabled fsprotect is not really worth a warning

[Stefanos Harhalakis]

This will be fixed in the next upload.

Thanks!





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

Bug#530243: properly document fsprotect parameter's argument

[Stefanos Harhalakis]

On Saturday 23 May 2009, martin f krafft wrote:
 Package: fsprotect
 Version: 1.0.2
 Severity: minor

 Maybe you could add something like the following to the
 documentation:

Thanks a lot. You'll see it in the documentation (README.Debian and the pdf) 
of the next upload.




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

Bug#530241: does not parse errors=remount-ro option

[Stefanos Harhalakis]

On Saturday 23 May 2009, martin f krafft wrote:
 When I boot with fsprotect protecting my root filesystem, I see the
 following message:

Can you please try the following?:

* edit /usr/share/initramfs-tools/scripts/local-bottom/fsprotect and change 
DEBUG=no to DEBUG=yes.

* Run: update-initramfs -u

* Reboot

* See if the message is shown before or after the 'done.' line. You'll see 
something like this:

mount -n -o move ...
done.

If it is shown before, it will be helpfull to tell me after which line. There 
will be a pause of 3 seconds after the 'done.' message but I suggest you also 
press ctrl-S at that point.

I'd like to know if this message is caused by the commands that are run by 
fsprotect or because of their effects. Also, what is the version of aufs-
source you're using?

(I currently can't reproduce it here because i don't have a system with ext3 
/)




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

Bug#529955: ITP: iguanair -- IguanaWorks Infrared Tranceiver support tools

[Stefanos Harhalakis]

Package: wnpp
Severity: wishlist
Owner: Stefanos Harhalakis v...@v13.gr


* Package name: iguanair
  Version : 0.99
  Upstream Author : IguanaWorks Inc.
* URL : http://iguanaworks.net/
* License : GPLv2 and LGPLv2
  Programming Lang: C and Python
  Description : IguanaWorks Infrared Tranceiver support tools

This is a package for iguanaworks support tools and development files.
It adds the required tools to manage IgianaWorks IR transceivers and
the appropriate development files (library and headers) for adding
iguaunaIR support to lirc (see bug #524403)



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

Bug#524421: ITP: katimon -- KDE ATI Graphics Card Monitor

[Stefanos Harhalakis]

Package: wnpp
Severity: wishlist
Owner: Stefanos Harhalakis v...@v13.gr


* Package name: katimon
  Version : 1.0.2
  Upstream Author : Stefanos Harhalakis v...@v13.gr
* URL : http://www.v13.gr/proj/katimon/
* License : GPLv2
  Programming Lang: Python
  Description : KDE ATI Graphics Card Monitor

A KDE program for monitoring ATI graphics cards.
This program can:
* Display graphics card temperature
* Display and modify graphics card fans
* Automatically adjust fan speed
* Display GPU usage
* Display core GPU speed and memory speed
* Overclock the graphics card

It is written in Python and uses the aticonfig tool.



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

Bug#516222: RFS: libnet - orphaning libnet

[Stefanos Harhalakis]

Hello,

On Friday 27 March 2009, David Paleino wrote:
 retitle 516222 O: libnet -- library for the construction and handling of
 network packets thanks

 Hello,
 libnet has been in RFA (Request for Adoption) for more than a month now,
 and I'm hereby orphaning it.

 Someone please pick it up, as it's an important piece of software in
 Debian.

 Sam Roberts (CCed) is taking over upstream development, please contact him
 when adopting libnet.

I'm willing to maintain it.

I'm not familiar with libnet source code but I'm with its subject and I can 
package it whenever a new version becomes available or when a new package is 
needed.

From what you say, I guess that the homepage[1] will change in the near 
future. Is there another one ? 

I see that you use git. Is it madantory to use git? (I'm not familiar with 
it).

Also, I'm somehow new in this maintaining thing, so if there is someone else 
interested, please do it...

... but if not, I'd appreciate any information I can have.

[1] http://www.packetfactory.net/libnet/



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

Bug#516222: RFS: libnet - orphaning libnet

[Stefanos Harhalakis]

Hello,

On Friday 27 March 2009, Jan Christoph Nordholz wrote:
 Hi Stefanos,

 if you need help, I could lend a hand now and then. I don't have the
 time to maintain the package on my own, but I have a faible for old
 and/or undocumented C code and some experience in delving through
 networking code in particular, so I could e.g. help hunting bugs.

Thank you for your offer. I'm also quite familiar with C and networking code 
and I hope that there will be no problems. If there are any I'll annoy 
you :-)



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

Bug#516222: RFS: libnet - orphaning libnet

[Stefanos Harhalakis]

On Friday 27 March 2009, David Paleino wrote:
 F/up set, please respect it
 (I forgot setting it in my first mail, sorry.)

Being a user of kmail I don't really know if it is possible to easily handle 
it. Also, I'm not suer I completely understand what you mean. You want to 
only send replies to the debian-devel list? (If yes, excuse this reply :-)

  I see that you use git. Is it madantory to use git? (I'm not familiar
  with it).

 No. You (or whoever is going to maintain it) may use whichever $VCS you
 want. There's some old-ish SVN repository for libnet (I migrated it to git
 recently, so the history there is not that old -- if you meant to use SVN,
 that is)

 http://svn.debian.org/viewsvn/collab-maint/deb-maint/libnet

 But please note that the SVN repo is quite broken [0] -- you may want to
 remove it and start it all over again (maybe re-importing it from git?)

I have to have this stored in an VCS? For some other packages i packaged (only 
1 in debian), i used a local copy (at least to begin with).

If yes: Do I have to have the whole package in the VCS or just the debian/ 
directory? From what I've read I assumed that I only need to have local 
copies (or a versioning system) of debian/.


signature.asc
Description: This is a digitally signed message part.

Bug#520765: ITP: fsprotect -- Make filesystems immutable

[Stefanos Harhalakis]

Package: wnpp
Severity: wishlist
Owner: Stefanos Harhalakis v...@v13.gr


* Package name: fsprotect
  Version : 1.0.0
  Upstream Author : Stefanos Harhalakis v...@v13.gr
* URL : http://www.v13.gr/ (not available yet)
* License : GPL
  Programming Lang: Shell
  Description : Make filesystems immutable

fsprotect ease the pain of protecting a system. By using an init script and
a initramfs script it can make the root and other filesystems immutable.
It uses aufs and tmpfs.

A typical admin only has to install fsprotect and add the 'fsprotect'
parameter to kernel to make the / immutable. She can also add a list of
filesystems to be protected in /etc/default/fsprotect.

This is a 'must' for all public computers like those in labs, libraries, etc.

-- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 
'experimental')
Architecture: amd64 (x86_64)



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

Bug#513813: python-kde4-dev: Generated file needs an extra line for UTF-8 encoding

[Stefanos Harhalakis]

Package: python-kde4-dev
Version: 4:4.2.0-1
Severity: important
Tags: patch


Using the pykdeuic4 the generated python script doesn't contain a coding
header. When someone uses unicode characters 127 at the qt-designer the
generated python code contains them as-is. This makes it an invalid python
script. This is easily fixed by adding a one-line header at the python code.

The attached patch fixes this simple bug.

As a bonus it also fixes another problem: The generated file starts with an
empty line. This isn't proper for scripts starting with #!. The patch
also removes this extra line.

-- System Information:
Debian Release: 5.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 
'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.28-v2-v (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages python-kde4-dev depends on:
ii  python2.5.2-3An interactive high-level object-o
ii  python-qt44.4.4-3Python bindings for Qt4

Versions of packages python-kde4-dev recommends:
ii  python-kde4   4:4.2.0-1  Python bindings for the KDE 4 libr

python-kde4-dev suggests no packages.

-- debconf-show failed
diff -Nur kdebindings-4.2.0.orig/python/pykde4/tools/pykdeuic4/pykdeuic4.py kdebindings-4.2.0/python/pykde4/tools/pykdeuic4/pykdeuic4.py
--- kdebindings-4.2.0.orig/python/pykde4/tools/pykdeuic4/pykdeuic4.py	2008-01-05 01:52:57.0 +0200
+++ kdebindings-4.2.0/python/pykde4/tools/pykdeuic4/pykdeuic4.py	2009-02-01 15:48:56.32873 +0200
@@ -24,8 +24,9 @@
 from PyQt4.uic.Compiler import indenter, compiler
 from PyQt4.uic.Compiler import qtproxies
 
-header = 
-#!/usr/bin/env python
+header = #!/usr/bin/env python
+# coding=UTF-8
+#
 # Generated by pykdeuic4 from %s on %s
 #
 # WARNING! All changes to this file will be lost.

Bug#510275: krypt

[Stefanos Harhalakis]

On Friday 02 January 2009, Ana Guerrero wrote:
  Anyway, without beeing a DD, as a debian user, I'd like to have this
  program available as a package.
 
  So, to conclude, just take a moment to reply with at least a simple go-on
  or don't-go-on. I won't argue any more.

 You are free to package it and ask people to sponsor it. Nobody can forbid
 you of uploading a proper package to Debian if you find a sponsor, but
 think in the work that this will carry to the distro for maybe little gain.
 Your package will be some time in unstable, yeah, but its final target
 won't be being in a debian release given that squeeze (next release after
 lenny) will have KDE 4.

I believe that I cannot take such a decision myself. From my POV (as a debian 
user) I want this program to be in debian and that's why i packaged it (as 
expected, I'm also using it). Fotis offered to sponsor it but I don't want to 
introduce problems to debian, so I'll follow your advice.

As for KDE4, krypt will be usable for squeeze too and when the author ports it 
to KDE4 it will be ported for debian too. Having this in debian may increase 
the interrest of other/new users for it and they may offer to do the porting 
themeselves. As I see it, its main/only problem is that it will be replaced 
by built-in support in KDE4 sometime in the future (perhaps in KDE 4.3) but 
until then (1 year from now?) it is an essential tool for all 
encrypted-USB-stick, encrypted-USB-disk and 
laptop-with-encrypted-data-partition KDE3/4 users.

p.s. Should I stop CCing you?



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

Bug#510275: ITP: krypt -- KDE GUI for managing volumes encrypted with LUKS

[Stefanos Harhalakis]

Hello Scott,

On Wednesday 31 December 2008, Scott Kitterman wrote:
 Since it's too late for Lenny and Squeeze will be a KDE4 release, I think
 there is no point in packaging this until it's ported for KDE4.

Krypt only depends on kdelibs. Everything else is HAL and DBUS related, so it 
should be working with kde4 too. If I understand it correctly, lenny will 
have kdelibs4 (that's kde3 libs) so it will be usable there too.

In fact, krypt only needs libkdeui and libkdecore from the kde libraries 
(that's what ldd shows).



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

Bug#510275: krypt

[Stefanos Harhalakis]

Thanks for the answer,

On Wednesday 31 December 2008, Ana Guerrero wrote:
 Hi,

 On Wed, Dec 31, 2008 at 09:54:32PM +0200, Stefanos Harhalakis wrote:
  Hello there,
 
  I've prepared a debian package for krypt [1] (KDE GUI for managing
  volumes encrypted with LUKS) and while looking for a sponsor, Faidon
  Liambotis suggested that I should contact you (pkg-kde) too. Is there any
  special procedure for creating a debian package for a kde program? Krypt
  only depends on kdelibs4 so it should be able to be used with kde4 too
  (right?).
 
  Is it OK to go-on and look for a sponsor?
 
  [1] http://krypt.berlios.de/

 I have seen the ITP and marked to answer to the bug number, doing it now
 (bug Cc'ed).
 As you might know already, after Lenny, we are replacing KDE 3 with KDE 4,
 this transition will be quick but replacing all kde 3 apps for kde 4 apps,
 will take sime (surely too much time). So in the meantime we'll need to
 keep kdelibs (and part of kdebase), but the ultimate goal is getting ride
 of that too (and Qt3 too!)
 Even if you app only needs kdelibs, it is an app that is *integrated* with
 kde 3.5... I really think it is best wait until it is ported to KDE 4 then
 package it.

I believe that there are some arguments for including it in debian too:

a) It is not integrated. It just integrates with the desktop environment. It 
is a single executable binary that interracts with hal and dbus. After 
opening a luks device, the device is handled by KDE as a normal mapper 
device. It should work for gnome and KDE4 too

b) From what I've seen, up to KDE 4.2, there is no good support for crypted 
volumes (correct me me if I'm wrong). This little program fills the gap.

c) It's the only way (?) to have easily accessible encrypted removable 
devices.

d) As you said, sime. Why not have this available for that time?

e) It is a program that exists today and solves a today's problem. Isn't it 
better to have this available for the next year (or more), until it is ported 
to KDE4 or KDE4 gets support for encrypted devices?

f) Are there any drawbaks for including this in debian?

g) Isn't this what happens with all other packages? AFAIK, the KDE3-KDE4 
transition of programs is not a debian's issue but the program's developers. 
Why not distribute this with debian too?

Anyway, without beeing a DD, as a debian user, I'd like to have this program 
available as a package. 

So, to conclude, just take a moment to reply with at least a simple go-on or 
don't-go-on. I won't argue any more.

Thanks in advance and have a happy new year.

p.s. Please CC me.



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

Bug#510275: ITP: krypt -- KDE GUI for managing volumes encrypted with LUKS

[Stefanos Harhalakis]

Package: wnpp
Severity: wishlist
Owner: Stefanos Harhalakis v...@it.teithe.gr


* Package name: krypt
  Version : 0.2
  Upstream Author : Jakub Schmidtke sja...@users.berlios.de
* URL : http://krypt.berlios.de/
* License : GPL
  Programming Lang: C++
  Description : KDE GUI for managing volumes encrypted with LUKS

I'm willing to maintain this package for debian. It is also requested with
RFP #507655. To my knowledge (and to wnpp lists) noone else is working on it.
It seems an easy to package program that should not be hard to maintain.

Krypt is a nice gui, very nicely integraded in KDE 3.5, for easy mounting of
LUKS encrypted volumes (like USB sticks).

-- System Information:
Debian Release: 5.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 
'experimental')
Architecture: amd64 (x86_64)



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

Bug#510121: kernel-package: make-kpkg needs to take care of /lib/firmware for multiple installed kernel versions

[Stefanos Harhalakis]

Package: kernel-package
Version: 11.015
Severity: important


Building a kernel package with make-kpkg for kernels =2.6.27 results in
including some files in the package that are put in /lib/firmware. For example:

(2.6.28 .deb contents)

drwxr-xr-x root/root 0 2008-10-12 15:45 ./lib/firmware/
drwxr-xr-x root/root 0 2008-10-12 15:45 ./lib/firmware/yamaha/
-rw-r--r-- root/root 12288 2008-10-12 15:45 
./lib/firmware/yamaha/ds1_ctrl.fw
-rw-r--r-- root/root   128 2008-10-12 15:45 ./lib/firmware/yamaha/ds1_dsp.fw
-rw-r--r-- root/root 12288 2008-10-12 15:45 
./lib/firmware/yamaha/ds1e_ctrl.fw

The next kernel (2.6.29) package will also have those files in it. So there
will be two .deb files with the same files in /lib/firmware. This makes it
impossible to install a new kernel and keep the old one installed in the
system. This actually happened with kernels 2.6.27 and 2.6.28.

Perhaps /lib/firmware files should be a different package
(linux-kernel-firmware-2.6.28) etc. Most probably there isn't any problem
having kernel 2.6.27 with firmware from 2.6.28 (etc... etc...). Also, the
kernel-firmware may be a non-free package (per debian policy ?).

I see that this bug is also mentioned as ubuntu bug #256983
(https://bugs.launchpad.net/ubuntu/+source/kernel-package/+bug/256983)

which includes a on-liner patch for installing the firmware in 
/lib/firmware/version

-- System Information:
Debian Release: 5.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 
'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.28-v2-v (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages kernel-package depends on:
ii  binutils2.18.1~cvs20080103-7 The GNU assembler, linker and bina
ii  debianutils 2.30 Miscellaneous utilities specific t
ii  dpkg1.14.23  Debian package management system
ii  dpkg-dev1.14.23  Debian package development tools
ii  file4.26-1   Determines file type using magic
ii  gcc [c-compiler]4:4.3.2-2The GNU C compiler
ii  gcc-4.1 [c-compiler 4.1.2-23 The GNU C compiler
ii  gcc-4.2 [c-compiler 4.2.4-4  The GNU C compiler
ii  gcc-4.3 [c-compiler 4.3.2-1  The GNU C compiler
ii  gettext 0.17-4   GNU Internationalization utilities
ii  make3.81-5   The GNU version of the make util
ii  module-init-tools   3.4-1tools for managing Linux kernel mo
ii  perl5.10.0-18Larry Wall's Practical Extraction 
ii  po-debconf  1.0.15   manage translated Debconf template
ii  util-linux  2.13.1.1-1   Miscellaneous system utilities

Versions of packages kernel-package recommends:
ii  bzip2 1.0.5-1high-quality block-sorting file co
ii  libc6-dev [libc-dev]  2.7-16 GNU C Library: Development Librari

Versions of packages kernel-package suggests:
pn  docbook-utils none (no description available)
ii  e2fsprogs 1.41.3-1   ext2/ext3/ext4 file system utiliti
pn  libdb3-devnone (no description available)
pn  libncurses-devnone (no description available)
pn  linux-initramfs-tool  none (no description available)
pn  linux-source | kernel-source  none (no description available)
pn  xmlto none (no description available)

-- debconf-show failed



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

Bug#429394: linux-image-2.6.18-4-686-bigmem: STIME of ps output for a process is not constant

[Stefanos Harhalakis]

On Monday 15 December 2008, Moritz Muehlenhoff wrote:
 Does this error still occur with more recent kernel versions?

 If you're running Etch, could you try to reproduce this bug
 with the 2.6.24 based kernel added in 4.0r4?
 http://packages.qa.debian.org/l/linux-2.6.24.html

I'm sorry but I don't know of a way to reproduce this on-demand, even on the 
same machine with the same kernel. I know that this is an ugly bug report but 
I can only report further similar problems or perhaps try to automate this in 
a way.

To make this harder, ps shows the date instead of the time a process started 
when there are more than 24h passed and thus I cannot test it with other 
processes. This is a server machine that I cannot reboot for testing.



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

Bug#503463: faubackup conflicts with vbackup

[Stefanos Harhalakis]

Package: faubackup
Severity: normal

*** Please type your report below this line ***

Hello there,

I'm the author of a backup program named 'vbackup' which was just uploaded to
unstable. I see that faubackup was originally named 'vbackup' but it was
renamed and that it conflicts with 'vbackup' and it also provides it. Since
the original vbackup package is not longer in any version of debian I'm
asking you to remove the conflicts and provides for obvious reasons.

I'm not sure if what I'm proposing here is correct behavior for a debian
package so perhaps we should ask debian mentors for guidance.

-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), 
(1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.27-v2-v (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash



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

Bug#423923: dhcbd: names with - character

[Stefanos Harhalakis]

It seems that dhcbd uses the interface name as part of the dbus request path. 

Dbus only accepts the following characters (copy-paste from dbus source code):

#define VALID_NAME_CHARACTER(c) \
  ( ((c) = '0'  (c) = '9') ||   \
((c) = 'A'  (c) = 'Z') ||   \
((c) = 'a'  (c) = 'z') ||   \
((c) == '_') )

Most probably this should be considered a bug of dhcdbd.

So, using any character not in the above set will return an error when trying 
to get address with dhcp.



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

Bug#499689: libc6: Now that lenny is frozen, glibc should (?) have a newer version in MIN_KERNEL_SUPPORTED

[Stefanos Harhalakis]

Package: libc6
Version: 2.7-13
Severity: normal


Hello there,

Now that lenny is frozen shouldn't glibc depend to a newer (2.6.26) kernel
version? Currently, MIN_KERNEL_SUPPORTED is set to 2.6.9 and (as you know)
leaves out some newer features.

Apologies if this is nonsense.

-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'stable'), (150, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.26-v2-v (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages libc6 depends on:
ii  libgcc1   1:4.3.1-9  GCC support library

libc6 recommends no packages.

Versions of packages libc6 suggests:
ii  glibc-doc 2.7-13 GNU C Library: Documentation
ii  locales   2.7-13 GNU C Library: National Language (

-- debconf-show failed



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

Bug#468735: usplash: workaround

[Stefanos Harhalakis]

Eric,

Try adding this instead:

[ -e /sbin/usplash ]  /sbin/usplash -c -v
[ -e /sbin/usplash_write ]  /sbin/usplash_write PULSATE
[ -e /sbin/usplash_write ]  /sbin/usplash_write VERBOSE true

(notice the -c)

it worked for me in two different configurations. You can find out what 
exactly usplash does at:
/usr/share/initramfs-tools/scripts/init-top/usplash

p.s. Don't forget update-initramfs -u



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

Bug#489957: Why not move /etc/apache2/envvars to /etc/default/apache2 ?

[Stefanos Harhalakis]

Package: apache2
Version: 2.2.9-2
Severity: minor


/etc/apache2/envvars contains the lines:

export APACHE_RUN_USER=www-data
export APACHE_RUN_GROUP=www-data
export APACHE_PID_FILE=/var/run/apache2.pid

Correct me if I'm wrong but don't these belong to /etc/default/apache2 ?

Excuse me if this is already discussed. I didn't find anything related
in the BTS and Google.

-- Package-specific info:
List of enabled modules from 'apache2 -M':
  alias auth_basic authn_file authz_default authz_groupfile
  authz_host authz_user autoindex cgi dav_fs dav dir env mime
  negotiation php5 python setenvif ssl status userdir

-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'stable'), (150, 'unstable'), (1, 
'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.25-v2-v (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages apache2 depends on:
ii  apache2-mpm-prefork   2.2.9-2Apache HTTP Server - traditional n

apache2 recommends no packages.

-- no debconf information



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

Bug#481347: logcheck: Logcheck leaves world-readable dead.letter

[Stefanos Harhalakis]

On Friday 20 June 2008, Robert Luberda wrote:
   The problem that it is world readable lies in the used tool mail,
  coming from the mailx package. The information exposure problem is not
  limited to logcheck here, it in fact is a more general problem residing
  in mailx that it doesn't tighten the file permission of the dead.letter
  file it creates.

 No, mailx correctly sets umask to 077 before creating a dead.letter
 file. The problem might be in sendmail binary which is spawned by mailx.
 I use postifx and can't reproduce the bug with it.

 Stefanos, could you please check if you get the dead.letter after the
 following commands:
 umask 000
 yes | dd  count=102400 | /usr/sbin/sendmail -t `id -u`

You are correct:

-rw-r--r-- 1 v13 x9697 52429153 2008-06-20 11:35 dead.letter

Also tested this without changing the umask (loged-out/in and removed the old 
dead.letter) and it had the same results:

$ ls -l dead.letter 
-rw-r--r-- 1 v13 x9697 52429153 2008-06-20 11:39 dead.letter

$ umask
0077

Installed sendmail version is 8.13.8-3:

ii  sendmail  8.13.8-3
ii  sendmail-base 8.13.8-3
ii  sendmail-bin  8.13.8-3
ii  sendmail-cf   8.13.8-3
ii  sendmail-doc  8.13.8-3



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

Bug#481347: logcheck: Logcheck leaves world-readable dead.letter

[Stefanos Harhalakis]

Package: logcheck
Version: 1.2.54
Severity: grave
Tags: security
Justification: user security hole

Logcheck can leave a world readable dead.letter that contains parsed
logs.

Steps to reproduce:
* Create a lot of logs that will not be filtered by logcheck. (very
  easy). 10MBytes should be enough. You have an hour to do so.
* When logcheck runs it will produce a file of size X MBytes to be
  mailed to root
* Most MTAs have a limit for the maximum message size. If it is exceeded
  and you're using sendmail, the mail will be saved in a file named dead.letter
* For logcheck this is placed in: /var/lib/logcheck/dead.letter
* Go read this file and get some logs that you should not see

Example file:
-rw-r--r-- 1 logcheck logcheck 17001006 2008-05-15 15:02 
/var/lib/logcheck/dead.letter

Proposed solution:
Change permissions of /var/lib/logcheck dir to 770


-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (990, 'stable')
Architecture: amd64 (x86_64)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-6-amd64
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)

Versions of packages logcheck depends on:
ii  adduser  3.102   Add and remove users and groups
ii  cron 3.0pl1-100  management of regular background p
ii  debconf  1.5.11etch1 Debian configuration management sy
ii  grep 2.5.1.ds2-6 GNU grep, egrep and fgrep
ii  lockfile-progs   0.1.10  Programs for locking and unlocking
ii  logtail  1.2.54  Print log file lines that have not
ii  mailx1:8.1.2-0.20050715cvs-1 A simple mail user agent
ii  sendmail-bin [ma 8.13.8-3powerful, efficient, and scalable 
ii  sysklogd [system 1.4.1-18System Logging Daemon

Versions of packages logcheck recommends:
ii  logcheck-database 1.2.54 database of system log rules for t

-- no debconf information



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

Bug#462243: more info

[Stefanos Harhalakis]

Do you happen to have a wacom device? If so, try unplugging it and restarting 
the X server.

I had the same problem and it was solved when i unplugged the wacom volito usb 
device. Alternatively you may remove the wacom-related configuration options 
from xorg.conf.



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

Bug#462655: udev: Udev creates aacraid devices with group floppy (reopen #404927)

[Stefanos Harhalakis]

Package: udev
Version: 0.105-4
Severity: critical
Tags: security
Justification: root security hole

This is a follow-up to closed bug report #404927.

The group problem is not yet fixed. The rule:

SUBSYSTEM==block, ATTRS{removable}==1, \
DRIVERS!=aacraid, GROUP=floppy

in permissions.rules still results in group 'floppy'. I'm not sure why.
I don't know if this is a udev bug or a permission.rules bug but I 
suggest changing the rules to either:

# the aacraid driver is broken and reports that disks removable (see #404927)
SUBSYSTEM==block, DRIVERS==aacraid, GROUP:=disk
SUBSYSTEM==block, ATTRS{removable}==1, GROUP=floppy

or:

# the aacraid driver is broken and reports that disks removable (see #404927)
SUBSYSTEM==block, ATTRS{removable}==1, GROUP=floppy
SUBSYSTEM==block, DRIVERS==aacraid, GROUP=disk

Perhaps the second should be preferred to allow further modifications.

If the ATTRS{removable} check is not removed, the rule will not apply to 
partitions of the disk (I've checked it).

Either way, since in many systems there is at least one user that belongs to 
group 'floppy' by default, this is a security issue that concerns stable 
release too. A user that belongs to group floppy can easily become root by 
(for example) editing /dev/sda and modifying the shadow file. Since
we're talking about aacraid devices, the affected machines most probably
will by servers.

-- Package-specific info:
-- /etc/udev/rules.d/:
/etc/udev/rules.d/:
total 8
lrwxrwxrwx 1 root root  20 2007-09-07 19:33 020_permissions.rules - 
../permissions.rules
lrwxrwxrwx 1 root root  13 2007-09-07 19:33 udev.rules - ../udev.rules
lrwxrwxrwx 1 root root  25 2007-09-07 19:33 z20_persistent-input.rules - 
../persistent-input.rules
lrwxrwxrwx 1 root root  19 2007-09-07 19:33 z20_persistent.rules - 
../persistent.rules
-rw-r--r-- 1 root root 610 2007-09-07 20:03 z25_persistent-cd.rules
-rw-r--r-- 1 root root 498 2007-09-07 19:33 z25_persistent-net.rules
lrwxrwxrwx 1 root root  33 2007-09-07 19:33 z45_persistent-net-generator.rules 
- ../persistent-net-generator.rules
lrwxrwxrwx 1 root root  12 2007-09-07 19:33 z50_run.rules - ../run.rules
lrwxrwxrwx 1 root root  16 2007-09-07 19:33 z55_hotplug.rules - 
../hotplug.rules
lrwxrwxrwx 1 root root  29 2007-09-07 19:33 z75_cd-aliases-generator.rules - 
../cd-aliases-generator.rules

-- /sys/:
/sys/block/loop0/dev
/sys/block/loop1/dev
/sys/block/loop2/dev
/sys/block/loop3/dev
/sys/block/loop4/dev
/sys/block/loop5/dev
/sys/block/loop6/dev
/sys/block/loop7/dev
/sys/block/ram0/dev
/sys/block/ram10/dev
/sys/block/ram11/dev
/sys/block/ram12/dev
/sys/block/ram13/dev
/sys/block/ram14/dev
/sys/block/ram15/dev
/sys/block/ram1/dev
/sys/block/ram2/dev
/sys/block/ram3/dev
/sys/block/ram4/dev
/sys/block/ram5/dev
/sys/block/ram6/dev
/sys/block/ram7/dev
/sys/block/ram8/dev
/sys/block/ram9/dev
/sys/block/sda/dev
/sys/block/sda/sda1/dev
/sys/block/sda/sda2/dev
/sys/block/sda/sda5/dev
/sys/block/sda/sda6/dev
/sys/block/sda/sda7/dev
/sys/block/sdb/dev
/sys/block/sdb/sdb1/dev
/sys/block/sdb/sdb5/dev
/sys/block/sdb/sdb6/dev
/sys/block/sdb/sdb7/dev
/sys/block/sdb/sdb8/dev
/sys/block/sr0/dev
/sys/class/input/input0/event0/dev
/sys/class/input/input1/event1/dev
/sys/class/input/input1/mouse0/dev
/sys/class/input/input1/ts0/dev
/sys/class/input/input2/event2/dev
/sys/class/input/mice/dev
/sys/class/misc/device-mapper/dev
/sys/class/misc/hpet/dev
/sys/class/misc/mcelog/dev
/sys/class/misc/psaux/dev
/sys/class/misc/rtc/dev
/sys/class/misc/snapshot/dev
/sys/class/scsi_generic/sg0/dev
/sys/class/scsi_generic/sg1/dev
/sys/class/scsi_generic/sg2/dev
/sys/class/usb_device/usbdev1.1/dev
/sys/class/usb_device/usbdev2.1/dev
/sys/class/usb_device/usbdev2.2/dev
/sys/class/usb_device/usbdev3.1/dev
/sys/class/usb_device/usbdev4.1/dev
/sys/class/usb_device/usbdev5.1/dev
/sys/devices/pci:00/:00:1d.0/usb2/2-0:1.0/usbdev2.1_ep81/dev
/sys/devices/pci:00/:00:1d.0/usb2/2-1/2-1:1.0/usbdev2.2_ep81/dev
/sys/devices/pci:00/:00:1d.0/usb2/2-1/2-1:1.1/usbdev2.2_ep82/dev
/sys/devices/pci:00/:00:1d.0/usb2/2-1/usbdev2.2_ep00/dev
/sys/devices/pci:00/:00:1d.0/usb2/usbdev2.1_ep00/dev
/sys/devices/pci:00/:00:1d.1/usb3/3-0:1.0/usbdev3.1_ep81/dev
/sys/devices/pci:00/:00:1d.1/usb3/usbdev3.1_ep00/dev
/sys/devices/pci:00/:00:1d.2/usb4/4-0:1.0/usbdev4.1_ep81/dev
/sys/devices/pci:00/:00:1d.2/usb4/usbdev4.1_ep00/dev
/sys/devices/pci:00/:00:1d.3/usb5/5-0:1.0/usbdev5.1_ep81/dev
/sys/devices/pci:00/:00:1d.3/usb5/usbdev5.1_ep00/dev
/sys/devices/pci:00/:00:1d.7/usb1/1-0:1.0/usbdev1.1_ep81/dev
/sys/devices/pci:00/:00:1d.7/usb1/usbdev1.1_ep00/dev

-- Kernel configuration:
 isapnp_init not present.


-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'testing')
Architecture: amd64 (x86_64)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-5-amd64
Locale: LANG=en_US.UTF-8, 

Bug#462655: udev: Udev creates aacraid devices with group floppy (reopen #404927)

[Stefanos Harhalakis]

On Saturday 26 January 2008, Marco d'Itri wrote:
 tag 462655 unreproducible moreinfo
 thanks

 On Jan 26, Stefanos Harhalakis [EMAIL PROTECTED] wrote:
  The group problem is not yet fixed. The rule:
 
  SUBSYSTEM==block, ATTRS{removable}==1, \
  DRIVERS!=aacraid, GROUP=floppy
 
  in permissions.rules still results in group 'floppy'. I'm not sure why.
  I don't know if this is a udev bug or a permission.rules bug but I
  suggest changing the rules to either:
 
  # the aacraid driver is broken and reports that disks removable (see
  #404927) SUBSYSTEM==block, DRIVERS==aacraid, GROUP:=disk
  SUBSYSTEM==block, ATTRS{removable}==1, GROUP=floppy

 I can't see why this would make any difference.
 Please forgive me if I do not believe that the workaround added one year
 ago actually never worked and you are the first one to notice it.

Since I'm the bug reporter of bug #404927 too, I can assure you that this 
was never fixed. I've this issue on 3 different machines using aacraid. 
Has anyone confirmed that this bug was fixed? The fix provided in bug #404927
is the one I'm also suggesting and it was never merged. The fixed that was 
applied to udev rules was a different and it doesn't fix the problem.

More information follow separated by === lines. Please be more specific 
if you want even more.

===

Look at a live reproduction:

# ln -sf /etc/udev/permissions.rules.orig /etc/udev/permissions.rules
# udevtest /block/sda/sda1
parse_file: reading '/etc/udev/rules.d/020_permissions.rules' as rules file
parse_file: reading '/etc/udev/rules.d/udev.rules' as rules file
parse_file: reading '/etc/udev/rules.d/z20_persistent-input.rules' as rules file
parse_file: reading '/etc/udev/rules.d/z20_persistent.rules' as rules file
parse_file: reading '/etc/udev/rules.d/z25_persistent-cd.rules' as rules file
parse_file: reading '/etc/udev/rules.d/z25_persistent-net.rules' as rules file
parse_file: reading '/etc/udev/rules.d/z45_persistent-net-generator.rules' as 
rules file
parse_file: reading '/etc/udev/rules.d/z50_run.rules' as rules file
parse_file: reading '/etc/udev/rules.d/z55_hotplug.rules' as rules file
parse_file: reading '/etc/udev/rules.d/z75_cd-aliases-generator.rules' as rules 
file
This program is for debugging only, it does not create any node,
or run any program specified by a RUN key. It may show incorrect results,
if rules match against subsystem specfic kernel event variables.

main: looking at device '/block/sda/sda1' from subsystem 'block'
udev_rules_get_name: add symlink 
'disk/by-path/pci-:04:00.0-scsi-0:0:0:0-part1'
run_program: 'vol_id --export /dev/.tmp-8-1'
run_program: '/lib/udev/vol_id' (stdout) 'ID_FS_USAGE=filesystem'
run_program: '/lib/udev/vol_id' (stdout) 'ID_FS_TYPE=ext3'
run_program: '/lib/udev/vol_id' (stdout) 'ID_FS_VERSION=1.0'
run_program: '/lib/udev/vol_id' (stdout) 
'ID_FS_UUID=4098a158-9ea0-45d7-aa7f-8ff6f18556f8'
run_program: '/lib/udev/vol_id' (stdout) 'ID_FS_LABEL='
run_program: '/lib/udev/vol_id' (stdout) 'ID_FS_LABEL_SAFE='
run_program: '/lib/udev/vol_id' returned with status 0
udev_rules_get_name: add symlink 
'disk/by-uuid/4098a158-9ea0-45d7-aa7f-8ff6f18556f8'
udev_rules_get_name: no node name set, will use kernel name 'sda1'
udev_device_event: device '/block/sda/sda1' already in database, validate 
currently present symlinks
udev_node_add: creating device node '/dev/sda1', major = '8', minor = '1', mode 
= '0660', uid = '0', gid = '25'
udev_node_add: creating symlink 
'/dev/disk/by-path/pci-:04:00.0-scsi-0:0:0:0-part1' to '../../sda1'
udev_node_add: creating symlink 
'/dev/disk/by-uuid/4098a158-9ea0-45d7-aa7f-8ff6f18556f8' to '../../sda1'
main: run: 'socket:/org/kernel/udev/monitor'


# ln -sf /etc/udev/permissions.rules.v13 /etc/udev/permissions.rules
# udevtest /block/sda/sda1
parse_file: reading '/etc/udev/rules.d/020_permissions.rules' as rules file
parse_file: reading '/etc/udev/rules.d/udev.rules' as rules file
parse_file: reading '/etc/udev/rules.d/z20_persistent-input.rules' as rules file
parse_file: reading '/etc/udev/rules.d/z20_persistent.rules' as rules file
parse_file: reading '/etc/udev/rules.d/z25_persistent-cd.rules' as rules file
parse_file: reading '/etc/udev/rules.d/z25_persistent-net.rules' as rules file
parse_file: reading '/etc/udev/rules.d/z45_persistent-net-generator.rules' as 
rules file
parse_file: reading '/etc/udev/rules.d/z50_run.rules' as rules file
parse_file: reading '/etc/udev/rules.d/z55_hotplug.rules' as rules file
parse_file: reading '/etc/udev/rules.d/z75_cd-aliases-generator.rules' as rules 
file
This program is for debugging only, it does not create any node,
or run any program specified by a RUN key. It may show incorrect results,
if rules match against subsystem specfic kernel event variables.

main: looking at device '/block/sda/sda1' from subsystem 'block'
udev_rules_get_name: add symlink 
'disk/by-path/pci-:04:00.0-scsi-0:0:0:0-part1'
run_program: 'vol_id --export

Bug#457957: Xserver eats too much memory

[Stefanos Harhalakis]

More info using xrestop:

USER   PID %CPU %MEMVSZ   RSS TTY  STAT START   TIME COMMAND
root  6213  5.2 41.9 876260 871360 tty7RLs+ 02:52   0:56 /usr/bin/X -br 
-nolisten tcp :0 vt7 -auth /var/run/xauth/A:0-rOJXrs

while xrestop gives:
xrestop - Display: :0.0
  Monitoring 27 clients. XErrors: 94
  Pixmaps:8511K total, Other: 226K total, All:8737K total

res-base Wins  GCs Fnts Pxms Misc   Pxm mem  Other   Total   PID Identifier
1a066   931  150  228 5944K 10K   5954K  6388 KDE Desktop
1c0   193   411  187  372 1038K 15K   1053K  6390 kicker
2e0   535  1261  418  797  611K 35K646K  6434  - KMail


$ cat /proc/6213/status
Name:   Xorg
VmPeak:   990772 kB
VmSize:   876260 kB
VmLck:   168 kB
VmHWM:956588 kB
VmRSS:871360 kB
VmData:   854744 kB
VmStk:84 kB
VmExe:  1592 kB
VmLib: 17224 kB
VmPTE:   900 kB
Threads:1

This looks like 100% memory leak. It happened after using iceweasel for 
10 minutes to view some google maps.



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

Bug#458340: ITP: vbackup -- A modular backup program

[Stefanos Harhalakis]

Package: wnpp
Severity: wishlist
Owner: Stefanos Harhalakis [EMAIL PROTECTED]


* Package name: vbackup
  Version : 0.1.4
  Upstream Author : Stefanos Harhalakis [EMAIL PROTECTED]
* URL : http://www.it.teithe.gr/~v13/vbackup/
* License : GPLv2, may be changed to GPLv3
  Programming Lang: Shell
  Description : A modular backup program

  vbackup is a modular backup program. It is a set of scripts that can
  perform full or incremental system backups. Currently it supports:
  * Filesystem backups using tar
  * XFS backups using xfsdump
  * PostgreSQL backups
  * MySQL backups
  * dpkg package list backups

-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'stable'), (150, 'unstable'), (1, 
'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.23.11-v2-v (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash



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

Bug#457957: xserver-xorg: X server eats too much memory

[Stefanos Harhalakis]

On Friday 28 December 2007, Julien Cristau wrote:
 On Thu, Dec 27, 2007 at 16:47:33 +0200, Stefanos Harhalakis wrote:
  X server eats a *lot* of memory. Currently it has a VMsize of 3GB with
  RSS 1.5GB. ps output:
 
  USER   PID %CPU %MEMVSZ   RSS TTY  STAT START   TIME COMMAND
  root  6421  2.6 58.2 3083584 1210180 tty7  SLs+ 11:41   7:49
  /usr/bin/X -br -nolisten tcp :0 vt7 -auth /var/run/xauth/A:0-NfXjOZ
 
  I believe that this is reproducable by openning firefox (or konqueror)
  and visiting google maps for some time.

 If that memory gets freed when you kill the firefox process, then it's
 not an X server bug.

  Firefox was not running (it died). When X server had 1.5GB of memory, 
firefox/iceweasel was not running. Perhaps you should ignore this report 
until it happens again and I have more details using xrestop.

  Apart from that, I believe that 1.5GB for X server a serious problem when 
caused by firefox when visiting google maps. Just go to google maps and watch 
the X server memory increasing by each move you do. It takes just a few 
minutes to exhaust system memory. Should I fill this bug report against 
firefox/iceweasel instead ?



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

Bug#457957: More info

[Stefanos Harhalakis]

After a X server restart the memory is a lot less:

USER   PID %CPU %MEMVSZ   RSS TTY  STAT START   TIME COMMAND
root 27493  5.8  0.9  30336 20488 tty7 SLs+ 16:53   
0:05 /usr/bin/X -br -nolisten tcp :0 vt7 -auth /var/run/xauth/A:0-NfXjOZ

Only 204K RSS and 303 VM



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

Bug#457957: xserver-xorg: X server eats too much memory

[Stefanos Harhalakis]

Package: xserver-xorg
Version: 1:7.3+8
Severity: important


X server eats a *lot* of memory. Currently it has a VMsize of 3GB with
RSS 1.5GB. ps output:

USER   PID %CPU %MEMVSZ   RSS TTY  STAT START   TIME COMMAND
root  6421  2.6 58.2 3083584 1210180 tty7  SLs+ 11:41   7:49
/usr/bin/X -br -nolisten tcp :0 vt7 -auth /var/run/xauth/A:0-NfXjOZ

I believe that this is reproducable by openning firefox (or konqueror)
and visiting google maps for some time.

The correspoding /proc/XXX/status file:
Name:   Xorg
.. mpla mpla mpla...
VmPeak:  3134804 kB
VmSize:  3083584 kB
VmLck:   168 kB
VmHWM:   1537284 kB
VmRSS:   1407900 kB
VmData:  3062884 kB
VmStk:84 kB
VmExe:  1592 kB
VmLib: 16420 kB
VmPTE:  3056 kB

System has 2GB of memory, it is currently using swap:
# free
 total   used   free sharedbuffers cached
Mem:   20759922023532  52460  0104 433200
-/+ buffers/cache:1590228 485764
Swap: 1171113618838489827288

System uptime is 5hours but this happened in about half an hour, so it
is a fast memory leak (or whatever).

-- Package-specific info:
Contents of /var/lib/x11/X.roster:
xserver-xorg

/var/lib/x11/X.md5sum does not exist.

X server symlink status:
lrwxrwxrwx 1 root root 13 2007-02-02 21:21 /etc/X11/X - /usr/bin/Xorg
-rwxr-xr-x 1 root root 1672764 2007-12-22 02:43 /usr/bin/Xorg

Contents of /var/lib/x11/xorg.conf.roster:
xserver-xorg

VGA-compatible devices on PCI bus:
05:00.0 VGA compatible controller: nVidia Corporation NV43 [GeForce 6600] (rev 
a2)

/etc/X11/xorg.conf does not match checksum in /var/lib/x11/xorg.conf.md5sum.

Xorg X server configuration file status:
-rw-r--r-- 1 root root 6261 2007-12-07 18:00 /etc/X11/xorg.conf

Contents of /etc/X11/xorg.conf:
# nvidia-xconfig: X configuration file generated by nvidia-xconfig
# nvidia-xconfig:  version 1.0  ([EMAIL PROTECTED])  Tue Aug  1 21:11:12 PDT 
2006

# /etc/X11/xorg.conf (xorg X Window System server configuration file)
#
# This file was generated by dexconf, the Debian X Configuration tool, using
# values from the debconf database.
#
# Edit this file with caution, and see the /etc/X11/xorg.conf manual page.
# (Type man /etc/X11/xorg.conf at the shell prompt.)
#
# This file is automatically updated on xserver-xorg package upgrades *only*
# if it has not been modified since the last upgrade of the xserver-xorg
# package.
#
# If you have edited this file but would like it to be automatically updated
# again, run the following command:
#   sudo dpkg-reconfigure -phigh xserver-xorg
Section InputDevice
Identifier stylus
Driver wacom
Option Protocol ImPS/2
Option Device /dev/input/wacom
Option  Type  stylus
Option  Threshold 10
Option  Mode  Relative
Option  USB   On
EndSection
Section InputDevice
Identifier eraser
Driver wacom
Option Protocol ImPS/2
Option Device /dev/input/wacom
Option  Type  eraser
Option  USB   On
EndSection
Section InputDevice
Identifier cursor
Driver wacom
Option Protocol ImPS/2
Option Device /dev/input/wacom
Option  Type  cursor
Option  USB   On
#   Option  Button2   BUTTON 3
#Option Button3   BUTTON 2
EndSection

Section ServerLayout

InputDevice stylusSendCoreEvents
InputDevice eraserSendCoreEvents
InputDevice cursorSendCoreEvents
Identifier Default Layout
Screen Default Screen 0 0
InputDeviceGeneric Keyboard
#InputDeviceConfigured Mouse
InputDeviceMS Mouse SendCoreEvents
InputDeviceTrackball SendCoreEvents
Option  AIGLX on
EndSection

Section Files

# path to defoma fonts
FontPath/usr/share/fonts/X11/misc
FontPath/usr/X11R6/lib/X11/fonts/misc
FontPath/usr/share/fonts/X11/cyrillic
FontPath/usr/X11R6/lib/X11/fonts/cyrillic
FontPath/usr/share/fonts/X11/100dpi/:unscaled
FontPath/usr/X11R6/lib/X11/fonts/100dpi/:unscaled
FontPath/usr/share/fonts/X11/75dpi/:unscaled
FontPath/usr/X11R6/lib/X11/fonts/75dpi/:unscaled
FontPath/usr/share/fonts/X11/Type1
FontPath/usr/X11R6/lib/X11/fonts/Type1
FontPath/usr/share/fonts/X11/100dpi
FontPath/usr/X11R6/lib/X11/fonts/100dpi
FontPath/usr/share/fonts/X11/75dpi
FontPath/usr/X11R6/lib/X11/fonts/75dpi
FontPath/var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType
EndSection

Section Module
#Load   i2c
#Load   bitmap
#Load   ddc
Load   extmod
Load   xtrap
Load   freetype
Load   glx
Load   

Bug#376865: Another solution

[Stefanos Harhalakis]

  I'd suggest that osirismd/configs directory should be owned by root, group 
osirismd and permissions 1770. This way, default configurations cannot be 
changed by the osirismd (This is not a security issue. Just to dissallow 
accidental overwrites.) but it will be able to store everything else in 
there. 

  Apart from that, it is a slight security issue to allow users to browse and 
view the stored configurations.



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

Bug#424621: solved

[Stefanos Harhalakis]

  I had the same (or similar) problem. It seems that the problem occurs 
because of different versions of beagle and libbeagle0. When I 'synchronized' 
those two versions (both testing or unstable) the problem was solved.

  I believe that this is a no-bug. Perhaps the beagle package from unstable 
should depend on a newer version of libbeagle0.



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

Bug#273269: sysklogd: Resolving may lock the system

[Stefanos Harhalakis]

Package: sysklogd
Version: 1.4.1-20
Followup-For: Bug #273269


Please consider changing the severity of this bugreport.
There is a remote bug that can freeze the system when using -r:

To reproduce it:
* Set as nameserver 127.0.0.1
* Start syslogd with -r
* Have a remote system log messages (1 per 2-3 seconds is enough)
* Start a local named (this will freeze)
* Try to login

This will freeze the system because syslogd uses gethostbyname() to do
the lookups which blocks it. Bind has already binded at port 53 but is
not able to perform lookups yet since it waits for some messages to be
logged to the syslog. syslog keeps trying to resolve the remote hostname
and still gets messages from it. Sending spoofed syslog packets amy keep
the system from actually booting.

There is no need to use a local named for it. When using a remote
nameserver that is not responding, syslog will be blocked. A blocked
syslogd results in blocking all processes that try to log something. su,
login, etc, all try to log something and thus you're not able to login
to the system until about 30 seconds have passed.

At least add a note to the /etc/default/sysklogd script to warn users
that when using -r they should have the appropriate entries in
/etc/hosts.

-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'stable'), (150, 'unstable'), (1, 
'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.22-v2-v (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages sysklogd depends on:
ii  klogd [linux-kernel-log-daemo 1.4.1-20   Kernel Logging Daemon
ii  libc6 2.5-9+b1   GNU C Library: Shared libraries

sysklogd recommends no packages.

-- no debconf information


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

Bug#266480: removal of gentleblue make machines unable to boot

[Stefanos Harhalakis]

  I'm using gentleblue splashimage on many of my machines since it is a very 
nice one. I've used it on some servers too. Those servers will not boot after 
the last upgrade because grub will determine that /boot/grub/splash.xpm.gz 
does not exist and it will wait for a keypress. Worst, the upgrade process 
will not even warn about this. Please add it back or fix it using the 
postinst script.

  BTW it was a very nice splashimage...


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

Bug#405201: more info

[Stefanos Harhalakis]

Hi there,

  I had the same problem today (again). This was not a debian or an xserver 
problem (for me ?). My X server was crashing when using kde and running any 
opengl app or xawtv. When starting a new X server with no wm:

X :0   (sleep 5s ; DISPLAY=:0 xterm)

and running the same app in the xterm there was no problem.

  It seems that this is caused by new X packages that override the nvidia glx 
libraries. To solve the problem just reinstall the nvidia driver.

  When reinstalling the nvidia driver, an error message is displayed that 
proves (?) this:

ERROR: File '/usr/lib/xorg/modules/extensions/libglx.so' is not a symbolic 
link.

Hope this helps...

V13


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

Bug#404927: udev believes hardware raid devices are removable and sets the permissions to group floppy

[Stefanos Harhalakis]

Package: udev
Version: 0.103-1
Severity: critical
Tags: security
Justification: root security hole


Hi there,

  Just noticed that udev sets the group of the hard disks to 'floppy'
  making them r/w to this group (actually, tiger noticed it):

brw-rw  1 root floppy 8,  0 Dec 29 11:25 /dev/sda
brw-rw  1 root floppy 8,  1 Dec 29 11:25 /dev/sda1
brw-rw  1 root floppy 8,  2 Dec 29 11:25 /dev/sda2
brw-rw  1 root floppy 8,  5 Dec 29 11:25 /dev/sda5
brw-rw  1 root floppy 8,  6 Dec 29 11:25 /dev/sda6
brw-rw  1 root floppy 8, 16 Dec 29 11:25 /dev/sdb
brw-rw  1 root floppy 8, 17 Dec 29 11:25 /dev/sdb1
brw-rw  1 root floppy 8, 32 Dec 29 11:25 /dev/sdc
brw-rw  1 root floppy 8, 33 Dec 29 11:25 /dev/sdc1
brw-rw  1 root floppy 8, 48 Dec 29 11:25 /dev/sdd
brw-rw  1 root floppy 8, 49 Dec 29 11:25 /dev/sdd1
brw-rw  1 root floppy 8, 50 Dec 29 11:25 /dev/sdd2

  The machine has a hardware raid controller:

:02:01.0 RAID bus controller: Adaptec AAC-RAID (rev 01)

  udevinfo gives this:

  looking at device '/block/sda':
KERNEL==sda
SUBSYSTEM==block
DRIVER==
ATTR{stat}==3560  800   19725227816 2406 463956368 
  392728031056   420544
ATTR{size}==20971776
ATTR{removable}==1
ATTR{range}==16
ATTR{dev}==8:0

  looking at parent device 
'/devices/pci:00/:00:1c.0/:02:01.0/host0/target0:0:0/0:0:0:0':
KERNELS==0:0:0:0
SUBSYSTEMS==scsi
DRIVERS==sd
ATTRS{ioerr_cnt}==0x0
ATTRS{iodone_cnt}==0x1771
ATTRS{iorequest_cnt}==0x1771
ATTRS{iocounterbits}==32
ATTRS{timeout}==30
ATTRS{state}==running
ATTRS{rev}==V1.0
ATTRS{model}==linux   
ATTRS{vendor}==Adaptec 
ATTRS{scsi_level}==3
ATTRS{type}==0
ATTRS{queue_type}==ordered
ATTRS{queue_depth}==256
ATTRS{device_blocked}==0

  looking at parent device 
'/devices/pci:00/:00:1c.0/:02:01.0/host0/target0:0:0':
KERNELS==target0:0:0
SUBSYSTEMS==
DRIVERS==

  looking at parent device 
'/devices/pci:00/:00:1c.0/:02:01.0/host0':
KERNELS==host0
SUBSYSTEMS==
DRIVERS==
  looking at parent device '/devices/pci:00/:00:1c.0/:02:01.0':
KERNELS==:02:01.0
SUBSYSTEMS==pci
DRIVERS==aacraid
ATTRS{broken_parity_status}==0
ATTRS{enable}==1
ATTRS{modalias}==pci:v9005d0285sv9005sd0290bc01sc04i00
ATTRS{local_cpus}==ff
ATTRS{irq}==169
ATTRS{class}==0x010400
ATTRS{subsystem_device}==0x0290
ATTRS{subsystem_vendor}==0x9005
ATTRS{device}==0x0285
ATTRS{vendor}==0x9005

  looking at parent device '/devices/pci:00/:00:1c.0':
KERNELS==:00:1c.0
SUBSYSTEMS==pci
DRIVERS==
ATTRS{broken_parity_status}==0
ATTRS{enable}==1
ATTRS{modalias}==pci:v8086d25AEsvsdbc06sc04i00
ATTRS{local_cpus}==ff
ATTRS{irq}==0
ATTRS{class}==0x060400
ATTRS{subsystem_device}==0x
ATTRS{subsystem_vendor}==0x
ATTRS{device}==0x25ae
ATTRS{vendor}==0x8086

  looking at parent device '/devices/pci:00':
KERNELS==pci:00
SUBSYSTEMS==
DRIVERS==

  Notice the 'aacraid' and 'adaptec' values that identify the hardware
  raid controller and the 'removable flag. I believe that this is not
  a misconfiguration of me and I don't have access to another machine
  with a hardware raid controller to test it there.

  I've classified this as a serious security hole, since the first user
  that is created when installing debian is in group 'floopy' and thus
  he may get superuser privileges in many ways and cause total data
  loss.

  Thanks in advance...

-- Package-specific info:
-- /etc/udev/rules.d/:
/etc/udev/rules.d/:
total 4
lrwxrwxrwx  1 root root  20 2006-02-03 14:43 020_permissions.rules - 
../permissions.rules
lrwxrwxrwx  1 root root  13 2006-02-03 14:43 udev.rules - ../udev.rules
lrwxrwxrwx  1 root root  25 2006-04-16 12:47 z20_persistent-input.rules - 
../persistent-input.rules
lrwxrwxrwx  1 root root  19 2006-02-03 14:43 z20_persistent.rules - 
../persistent.rules
-rw-r--r--  1 root root 605 2006-09-20 20:36 z25_persistent-net.rules
lrwxrwxrwx  1 root root  33 2006-05-28 15:54 z45_persistent-net-generator.rules 
- ../persistent-net-generator.rules
lrwxrwxrwx  1 root root  12 2006-02-03 14:43 z50_run.rules - ../run.rules
lrwxrwxrwx  1 root root  16 2006-02-03 14:43 z55_hotplug.rules - 
../hotplug.rules
lrwxrwxrwx  1 root root  29 2006-09-20 20:36 z75_cd-aliases-generator.rules - 
../cd-aliases-generator.rules

-- /sys/:
/sys/block/ram0/dev
/sys/block/ram10/dev
/sys/block/ram11/dev
/sys/block/ram12/dev
/sys/block/ram13/dev
/sys/block/ram14/dev
/sys/block/ram15/dev
/sys/block/ram1/dev
/sys/block/ram2/dev
/sys/block/ram3/dev
/sys/block/ram4/dev
/sys/block/ram5/dev
/sys/block/ram6/dev
/sys/block/ram7/dev
/sys/block/ram8/dev
/sys/block/ram9/dev
/sys/block/sda/dev
/sys/block/sda/sda1/dev
/sys/block/sda/sda2/dev
/sys/block/sda/sda5/dev

Bug#404927: additional information

[Stefanos Harhalakis]

  It seems that this problem occurred between 27/12/2006 and 29/12/2006. The
only thing that changed was the kernel from 2.6.16-2-686-smp to 2.6.18-3-686.

  If I remember correctly, tiger was not updated lately, so it would have
noticed this change:

  Here are the last tiger reports:

-rw---  1 root root  50 2006-12-19 05:00 check_perms.out.10
-rw---  1 root root  50 2006-12-20 05:00 check_perms.out.9
-rw---  1 root root  50 2006-12-21 05:00 check_perms.out.8
-rw---  1 root root  50 2006-12-22 05:00 check_perms.out.7
-rw---  1 root root  50 2006-12-23 05:00 check_perms.out.6
-rw---  1 root root  50 2006-12-24 05:00 check_perms.out.5
-rw---  1 root root  50 2006-12-25 05:00 check_perms.out.4
-rw---  1 root root  50 2006-12-26 05:00 check_perms.out.3
-rw---  1 root root  50 2006-12-27 05:00 check_perms.out.2
-rw---  1 root root 382 2006-12-29 05:00 check_perms.out.1

(at 28 Dec, the machine was powered-off because of maintenance and there is
no tiger report)

nas:/var/log/tiger# cat check_perms.out.2 

# Performing check of system file permissions...
nas:/var/log/tiger# cat check_perms.out.1

# Performing check of system file permissions...
--WARN-- [perm021w] Disk device /dev/sda1 has read/write access for group 
floppy. 
--WARN-- [perm021w] Disk device /dev/sda6 has read/write access for group 
floppy. 
--WARN-- [perm021w] Disk device /dev/sdd1 has read/write access for group 
floppy. 
--WARN-- [perm021w] Disk device /dev/sdd2 has read/write access for group 
floppy. 

Hope this helps...

V13


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

Bug#288016: Please consider adding a shutdown script that releases loop devices

[Stefanos Harhalakis]

I'm also having this problem because I use loopback devices. On each 
shutdown/reboot a partition stays mounted because of:

/mnt/cdtemp/debian-testing-1.iso on /mnt/deb1 type iso9660 
(ro,noexec,nosuid,nodev,loop=/dev/loop/0)

I'm having this dvd image on disk and I'm using it as an apt source. I'm sure 
there are other uses of loopback devices out there too...

Please consider reopening this bug...

As a fix you could also iterate through /etc/mtab using reverse order. This 
way you could umount all filesystems without needing to care about their 
nature.


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

Bug#392325: /etc/default/ntpdate should only contain configuration options

[Stefanos Harhalakis]

Package: ntpdate
Version: 1:4.2.2+dfsg.2-3
Severity: wishlist


/etc/default/ntpdate tries to read /etc/ntp.conf. I believe that this
should be done from the startup script insted of /etc/default/ntpdate.
The current approach requires most users to update their
/etc/default/ntpdate after some upgrades.

I suggest that /etc/default/ntpdate contains the NTPSERVERS and
NTPOPTIONS options only and leave the /etc/init.d/ntpdate to decided whether
the /etc/ntp.conf should be read and how.

IOW, I suggest moving the 'if' blocks to /etc/init.d/ntpdate, even the
default ones, and check for an empty 'NTPSERVERS' in /etc/init.d/ntpdate
and act as needed. This will leave /etc/default/ntpdate with user
configuration options only.

-- System Information:
Debian Release: testing/unstable
  APT prefers testing
  APT policy: (990, 'testing'), (100, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.17-2-686
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)

Versions of packages ntpdate depends on:
ii  libc62.3.6.ds1-4 GNU C Library: Shared libraries
ii  libcap1  1:1.10-14   support for getting/setting POSIX.
ii  libssl0.9.8  0.9.8c-3SSL shared libraries
ii  lsb-base 3.1-15  Linux Standard Base 3.1 init scrip
ii  netbase  4.25Basic TCP/IP networking system

ntpdate recommends no packages.

-- debconf-show failed


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

Bug#354118: k3b fails to burn cds on sata writer using cdrecord because it prefers dev=X, Y, Z instead of dev=/dev/scd0

[Stefanos Harhalakis]

Package: k3b
Version: 0.12.10-2
Severity: important


When trying to write a cd using a sata drive, k3b fails. A log is
included in the message.

The failed command is:
/usr/bin/cdrecord.mmap -v gracetime=2 dev=1,0,0 speed=4 -dao 
driveropts=burnfree -eject -data just.an.iso

This problem has the following sideeffects:

1) It requires that module 'sg' is loaded for /dev/sgX to be present
2) It requires that all /dev/sgX devices are readable from cdrecord. In
my case, /dev/sg0 is for /dev/sda and /dev/sg1 is for /dev/scd0:

crw-rw  1 root root  21, 0 Feb 23 15:06 /dev/sg0
crw-rw  1 root cdrom 21, 1 Feb 23 15:06 /dev/sg1
brw-rw  1 root disk 8, 0 Feb 23 14:20 /dev/sda
brw-rw  1 root cdrom 11, 0 Feb 23 14:21 /dev/scd0

Of course, there should be no need for cdrecord to be able to read
/dev/sg0. This is probably a bug of cdrecord.
3) It doesn't allow me to write anyt cdrom.

Now, if i use the following command from command line:
/usr/bin/cdrecord.mmap -v gracetime=2 dev=/dev/scd0 speed=4 -dao 
driveropts=burnfree -eject -data just.an.iso

it simply works. The only difference is that dev=1,0,0 is replaced by
/dev/scd0. If I remember correctly k3b uses the device name instead of
the device id for atapi drivers. I believe that this should happen for
for sata drives too.

This also solves the /dev/sgX problem because cdrecord will not look it
up.

Tested using k3b from stable and testing/unstable/experimental (same
version) too.

The failed log:

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

System
---
K3b Version: 0.12.10

KDE Version: 3.5.1
QT Version:  3.3.5
Kernel:  2.6.15-1-686-smp
Devices
---
HL-DT-ST DVDRAM GSA-4163B A103 (/dev/scd0, /dev/sg1) at  [CD-R; CD-RW; CD-ROM; 
DVD-ROM; DVD-RAM; DVD-R; DVD-RW; DVD+R; DVD+RW; DVD+R DL] [DVD-ROM; DVD-R 
Sequential; DVD-RAM; DVD-RW Restricted Overwrite; DVD-RW Sequential; DVD+RW; 
DVD+R; DVD+R Double Layer; CD-ROM; CD-R; CD-RW] [SAO; TAO; RAW; SAO/R96P; 
SAO/R96R; RAW/R16; RAW/R96P; RAW/R96R; Restricted Overwrite]

Used versions
---
cdrecord: 2.1.1a03

cdrecord
---
/usr/bin/cdrecord: Warning: Running on Linux-2.6.15-1-686-smp
/usr/bin/cdrecord: There are unsettled issues with Linux-2.5 and newer.
/usr/bin/cdrecord: If you have unexpected problems, please try Linux-2.4 or 
Solaris.
scsidev: '1,0,0'
scsibus: 1 target: 0 lun: 0
Linux sg driver version: 3.5.33
SCSI buffer size: 64512
/usr/bin/cdrecord: This version of cdrecord does not include DVD-R/DVD-RW 
support code.
/usr/bin/cdrecord: See /usr/share/doc/cdrecord/README.DVD.Debian for details on 
DVD support.
Cdrecord-Clone 2.01.01a01 (i686-pc-linux-gnu) Copyright (C) 1995-2004 J?rg 
Schilling
NOTE: this version of cdrecord is an inofficial (modified) release of cdrecord
  and thus may have bugs that are not present in the original version.
  Please send bug reports and support requests to [EMAIL PROTECTED].
  The original author should not be bothered with problems of this version.
TOC Type: 1 = CD-ROM
Using libscg version 'schily-0.8'.
Driveropts: 'burnfree'
atapi: 1
Device type: Removable CD-ROM
Version: 5
Response Format: 2
Capabilities   : 
Vendor_info: 'HL-DT-ST'
Identifikation : 'DVDRAM GSA-4163B'
Revision   : 'A103'
Device seems to be: Generic mmc2 DVD-R/DVD-RW.
Current: 0x000A
Profile: 0x0012 
Profile: 0x0011 
Profile: 0x0014 
Profile: 0x0013 
Profile: 0x001A 
Profile: 0x001B 
Profile: 0x002B 
Profile: 0x0010 
Profile: 0x0009 
Profile: 0x000A (current)
Profile: 0x0008 
Profile: 0x0002 
Using generic SCSI-3/mmc   CD-R/CD-RW driver (mmc_cdr).
Driver flags   : MMC-3 SWABAUDIO BURNFREE 
Supported modes: TAO PACKET SAO SAO/R96P SAO/R96R RAW/R16 RAW/R96P RAW/R96R
Drive buf size : 1053696 = 1029 KB
Drive DMA Speed: 13843 kB/s 78x CD 9x DVD
FIFO size  : 4194304 = 4096 KB
Track 01: data   496 MB
Total size:  570 MB (56:29.81) = 254236 sectors
Lout start:  570 MB (56:31/61) = 254236 sectors
Current Secsize: 2048
ATIP info from disk:
  Indicated writing power: 6
  Reference speed: 2
  Is not unrestricted
  Is erasable
  ATIP start of lead in:  -11680 (97:26/20)
  ATIP start of lead out: 337348 (74:59/73)
  1T speed low:  0 (reserved val  0) 1T speed high:  4
  2T speed low:  0 (reserved val  5) 2T speed high:  0 (reserved val 12)
  power mult factor: 4 5
  recommended erase/write power: 3
  A1 values: 02 4A B0
  A2 values: 5C D8 26
Disk type:Phase change
Manuf. index: 23
Manufacturer: SKC Co., Ltd.
Blocks total: 337348 Blocks current: 337348 Blocks remaining: 83112
Starting to write CD/DVD at speed 4 in real SAO mode for single session.
Last chance to quit, starting real write in 2 seconds.
   1 seconds.
   0 seconds. Operation starts.
Waiting for reader process to fill input buffer ... input buffer ready.
BURN-Free is OFF.
Turning BURN-Free on
Performing OPC...
Sending CUE sheet...
/usr/bin/cdrecord: WARNING: Drive returns wrong 

Bug#308585: tiger: Filesystem nfsd is not recognised as a local filesystem

[Stefanos Harhalakis]

Package: tiger
Version: 1:3.2.1-24
Severity: normal


Tiger reports this message:

--CONFIG-- [con010c] Filesystem nfsd used by none is not recognised as a
local filesystem

The fstab entry is:
none/nfsnfsddefaults0   0

mount says:
none on /nfs type nfsd (rw)

This filesystem is similar to the proc, devfs, sysfs, rpc_pipefs, usbfs, devpts 
filesystems.

-- System Information:
Debian Release: 3.1
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.10-1-686-smp
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)

Versions of packages tiger depends on:
ii  binutils2.15-5   The GNU assembler, linker and bina
ii  coreutils [fileutils]   5.2.1-2  The GNU core utilities
ii  debconf 1.4.30.13Debian configuration management sy
ii  diff2.8.1-11 File comparison utilities
ii  libc6   2.3.2.ds1-21 GNU C Library: Shared libraries an
ii  net-tools   1.60-10  The NET-3 networking toolkit

-- debconf information:
* tiger/mail_rcpt: root
  tiger/remove_mess: true
* tiger/policy_adapt:


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

Bug#290803: login: /var/log/btmp is created with insecure permissions

[Stefanos Harhalakis]

Package: login
Version: 1:4.0.3-30.7
Severity: critical
Tags: security
Justification: root security hole


It seems that /var/log/btmp is created as a world readable file.
This is insecure (and it is reported by 'tiger') because this file
contains failed logins , including unknown usernames. It is possible
for a user to see the root password (and others too) by running /usr/bin/lastb.

Tiger reports this as an error:

# Checking for existence of log files...
--FAIL-- [logf005f] Log file /var/log/btmp permission should be 660 

-- System Information:
Debian Release: 3.1
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.10-1-686-smp
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Versions of packages login depends on:
ii  libc6   2.3.2.ds1-20 GNU C Library: Shared libraries an
ii  libpam-modules  0.76-22  Pluggable Authentication Modules f
ii  libpam-runtime  0.76-22  Runtime support for the PAM librar
ii  libpam0g0.76-22  Pluggable Authentication Modules l

-- no debconf information


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

Bug#290803: login: /var/log/btmp is created with insecure permissions

[Stefanos Harhalakis]

On Sunday 16 January 2005 22:24, Justin Pryzby wrote:
 On Sun, Jan 16, 2005 at 09:51:44PM +0200, Stefanos Harhalakis wrote:
  Package: login
  Version: 1:4.0.3-30.7
  Severity: critical
  Tags: security
  Justification: root security hole
 
 
  It seems that /var/log/btmp is created as a world readable file.
  This is insecure (and it is reported by 'tiger') because this file
  contains failed logins , including unknown usernames.

 Aren't the usernames alwyas visible in /etc/password?

  It is possible for a user to see the root password (and others too)
  by running /usr/bin/lastb.

 lastb isn't show me any passwords; just valid usernames as seen in
 passwd and dates.

It also contains unknown usernames. This includes any logins that you've 
entered the password (or something else) as the username. If you enter 
test123 as the username then the btmp will contain the word 'test123' which 
can be your root or user password.

 Justin
V13


pgpaxC1R6FywB.pgp
Description: PGP signature