Bug#855788: 855788 severity

[Thomas Liske]

Hi Paul,

could you please verify if there is a user named "needrestart-dbus"? The
package seems no creating the required user. Maybe this report is a
duplicate of #857077.


TIA,
Thomas


Paul Wise <p...@debian.org> writes:

> On Sun, 2017-03-05 at 23:24 +0100, Thomas Liske wrote:
>
>> the package's core functionally is the needrestart-session command - does
>> it working for you?
>
> When I run needrestart as a user, I get a lot of processes that need
> restarting but when I run needrestart-session, it says this:
>
> Nothing found...
> None of your processes need to be restarted.
>
>> Could you please also try to run the dbus registration manually?
>
> Looks like it is broken too, see below.
>
>> The command should not return. Please provide any syslog entries... if
>> it would work you should see something like:
>
> The command returns and I see this in the systemd journal:
>
> Mar 06 12:53:44 chianamo needrestart-dbus-session[20149]: 
> needrestart-dbus-session 2.11 launched
> Mar 06 12:53:45 chianamo needrestart-dbus-session[20149]: 
> org.freedesktop.DBus.Error.Spawn.FailedToSetup: Failed to setup environment 
> correctly
> Mar 06 12:53:45 chianamo needrestart-dbus-session[20149]: terminated
>
> -- 
> bye,
> pabs
>
> https://wiki.debian.org/PaulWise

-- 

::  WWW:https://fiasko-nw.net/~thomas/  ::
   :::  Jabber:   xmpp:tho...@jabber.fiasko-nw.net  :::
::  flickr: https://www.flickr.com/photos/laugufe/  ::

Bug#855788: 855788 severity

[Thomas Liske]

tags 855788 more-info upstream
thanks


Hi pabs,


Paul Wise  writes:

> On Thu, 2017-03-02 at 23:30 +0100, Yann Dirson wrote:
>
>> FWIW, no such problem here. Is that high severity really warranted ?
>
> The package is not working for me at all. I assumed that the reason

the package's core functionally is the needrestart-session command - does
it working for you?

Could you please also try to run the dbus registration manually?

/usr/lib/needrestart-session/needrestart-dbus-session

The command should not return. Please provide any syslog entries... if
it would work you should see something like:

Mar  5 23:20:14 clempner needrestart-dbus-session[31046]: 
needrestart-dbus-session 2.11 launched
Mar  5 23:20:14 clempner needrestart-dbus-session[31046]: entering event loop...


TIA,
Thomas


> no-one else reported the same issue was that no-one else was using the
> package and verifying that it works. In that case it is warranted.
> If the package is working for others but not me then it isn't.

> Could you describe and screenshot what happens when you upgrade or
> reinstall a GUI program that is running in your desktop?
> If you are willing to, please upload the screenshot here:
>
> https://screenshots.debian.net/package/needrestart-session
>
> -- 
> bye,
> pabs
>
> https://wiki.debian.org/PaulWise

-- 

::  WWW:https://fiasko-nw.net/~thomas/  ::
   :::  Jabber:   xmpp:tho...@jabber.fiasko-nw.net  :::
::  flickr: https://www.flickr.com/photos/laugufe/  ::

Bug#850948: needrestart: Hangs in apt hook with a zombie

[Thomas Liske]

Re,


Jonas Smedegaard  writes:

>> I think the severity of this bug should be lowered to important since 
>> there is no policy violation of needrestart at all.
>
> I think it is quite worrisome if simply installing (not actively using)
> needrestart inside a chroot spawns daemons - and that is not treated as 
> serious (no matter framed by some geleral Debian Policy wording).

Needrestart was never written nor designed to run within a chroot. This
use case does not make any sense at all. Just don't do it (should be
added to the README ;-) .


>> I (upstream) or Patrick (maintainer) could add a patch to needrestart 
>> to use invoke-rc.d instead of the service command. That would only be 
>> a Debian specific workaround.
>
> Please do.  That sounds like it would solve this issue.

ACK


>> Neighter do I. Another workaround could be to change needrestart to 
>> list only mode within piupart using some local config snippet as they 
>> do for policy-rc.d.
>
> If I understand you corretly, that you suggest to invent a mechanism 
> essentially doing the same as policy-rc.d, then I see no need for that: 
> Please respect the already existing policy-rc.d instead.
>
> I guess what you seek is a solution not specific to Debian - and find 
> that wuite sensible.  I suspect, however, that there is no XDG or 
> similar more generic standard for respecting deployment-specific hooks - 
> which is really what policy-rc.d is about (not only chroot support).

Yes, since I'm upstream it is required that needrestart focuses an
generic approach. A patch kept in Pattricks packaging VCS should keep
the balance.


HTH,
Thomas

-- 

::  WWW:https://fiasko-nw.net/~thomas/  ::
   :::  Jabber:   xmpp:tho...@jabber.fiasko-nw.net  :::
::  flickr: https://www.flickr.com/photos/laugufe/  ::

Bug#850948: needrestart: Hangs in apt hook with a zombie

[Thomas Liske]

Re,


I've replied to #850948 where I think you wan't to discuss the
piuparts-needrestart-* issue.


Jonas Smedegaard  writes:

>> Maybe it is just a debconf frontend issue? In cases needrestart does
>> seems to hang it trackes down to:
>> 
>> - daemons hangig while restarting them (init scripts)
>
> Agreed. This would imply that either piuparts fail to setup policy-rc.d 
> appropriately, or that needrestart ignores policy-rc.d.  The latter is a 
> Policy violation.

You are referencing Debian Policy's section 9.3.3 [1]? So this is *no*
policy violation since:
- invoke-rc.d *should* be used - but it is not required
- runing /etc/init.d/ initscripts *should* called by initscript
  subsystem - but it is not required
- needrestart is *no* maintainer script at all, so 9.3.3 even does not
  apply, doesn't it

[1] https://www.debian.org/doc/debian-policy/ch-opersys.html#s9.3.3

I think the severity of this bug should be lowered to important since
there is no policy violation of needrestart at all. needrestart uses
the service command of init-system-helpers to restart daemons. A quick
look into /usr/sbin/service shows that if there is no systemd the
service command calls the init script directly (look at
run_via_sysvinit). So you might consider to move the bug to
init-system-helpers.

I (upstream) or Patrick (maintainer) could add a patch to needrestart to
use invoke-rc.d instead of the service command. That would only be a
Debian specific workaround.


>> - the debconf pipe gets weirrd (consolation)
>
> I suspect this to be irrelevant in scenarios involving policy-rc.d.

ACK


>> - needrestart and debconf thinks you call them interactive... but they
>>   are called non-interactive. As a result they wait forever for
>>   interaction.
>
> Agreed.
>
> From my brief conversations with the piuparts developers I am of the 
> impression that piuparts a) makes use of policy-rc.d and b) tells 
> debconf that interaction is non-interactive, c) has a quite big track 
> record to support a) and b), d) have rarely if ever tested needrestart 
> being pulled in as a dependency due to very few packages depending on it 
> at all.

Needrestart's use of debconf should be aware if piuparts already tells
debconf that it is called non-interactive. So it seems to hang due to
some init scripts problem as discussed above.


>> Feel free to open a new bug to needrestart to track down this issue.
>
> Thanks for the suggestion.  I am not familiar with piupart I will likely 
> not do so, but welcome others to pick up where I left.

Neighter do I. Another workaround could be to change needrestart to list
only mode within piupart using some local config snippet as they do for
policy-rc.d.


HTH,
Thomas


>
>  - Jonas
>
> -- 
>  * Jonas Smedegaard - idealist & Internet-arkitekt
>  * Tlf.: +45 40843136  Website: http://dr.jones.dk/
>
>  [x] quote me freely  [ ] ask before reusing  [ ] keep private

-- 

::  WWW:https://fiasko-nw.net/~thomas/  ::
   :::  Jabber:   xmpp:tho...@jabber.fiasko-nw.net  :::
::  flickr: https://www.flickr.com/photos/laugufe/  ::

Bug#826044: needrestart: Hangs in apt hook with a zombie

[Thomas Liske]

unblock 850948 with 826044
unmerge 826044
severity 826044 important
thanks

Hi,

Jonas Smedegaard  writes:

> Hi,
>
> It seems I have another instance of this issue: piuparts hangs (as I 

piuparts does not use consolation, doesn't it? Please stop abusing this
issue focusing on needrestart vs. consolation for another issue.


> has more details - an interesting part is this extracted when piuparts 
> hangs:
>
> 30803 root   30  10  117M 63804  9816 T  0.0  0.2  0:11.84 │  │└─ 
> /usr/bin/python /srv/piuparts/sbin/piuparts --skip-logrotatefiles-test 
> --warn-on-others --no-eatmydata --scriptsdir /etc/piuparts/script
> 29515 root   30  10 84340 46992 32864 T  0.0  0.1  0:00.67 │  │   
> └─ apt-get -y install design-desktop=3.0.4
> 30238 root   30  10 84340 14128 0 T  0.0  0.0  0:00.00 │  │   
>└─ apt-get -y install design-desktop=3.0.4
> 30240 root   30  10  4288   752   676 T  0.0  0.0  0:00.00 │  │   
>   └─ sh -c test -x /usr/lib/needrestart/apt-pinvoke && 
> /usr/lib/needrestart/apt-pinvoke || true
> 30241 root   30  10 55276 1  4324 T  0.0  0.0  0:00.23 │  │   
>  └─ /usr/bin/perl -w /usr/share/debconf/frontend /usr/sbin/needrestart
> 30331 root   30  10 50124 17516  4148 T  0.0  0.1  0:00.40 │  │   
> └─ /usr/bin/perl /usr/sbin/needrestart
>  2846 root   30  10  4288   740   668 T  0.0  0.0  0:00.00 │  │   
>├─ sh -c resize 2>/dev/null
>  2847 root   30  10  4188   704   632 T  0.0  0.0  0:00.00 │  │   
>│  └─ resize
>  2838 root   30  10 0 0 0 Z  0.0  0.0  0:00.00 │  │   
>└─ 90-none

Maybe it is just a debconf frontend issue? In cases needrestart does
seems to hang it trackes down to:

- daemons hangig while restarting them (init scripts)
- the debconf pipe gets weirrd (consolation)
- needrestart and debconf thinks you call them interactive... but they
  are called non-interactive. As a result they wait forever for
  interaction.


Feel free to open a new bug to needrestart to track down this issue.


Thanks,
Thomas

-- 

::  WWW:https://fiasko-nw.net/~thomas/  ::
   :::  Jabber:   xmpp:tho...@jabber.fiasko-nw.net  :::
::  flickr: https://www.flickr.com/photos/laugufe/  ::

Bug#844283: needrestart: uses wrong quote function for regexps in default configuration file

[Thomas Liske]

severity 844283 normal
tags 844283 upstream fixed-upstream
thanks


Hi Paul,


thanks for the hint. Interestingly it seems that q() is somehow working
- at least if there is no EOL marker '$' in use (see also the
attachment). So the broken default config was there since the beginning
but it was not recorgnized since most of the regex did work, although
the quotation was broken. The default configuration has been fixed
upstream.

I do not think that this bug should have a severity of serious since it
is only a bug in the config file which breaks some of the
regex. Although this makes needrestart report some false positives it
does not break functionality nor security.


HTH,
Tho-facepalming-mas




Paul Wise  writes:

> Package: needrestart
> Version: 2.10-1
> Severity: serious
>
> needrestart uses the wrong Perl quote function for regexps in
> configuration file. It is using q but should be using qr
> (quote regexps). This means that all of the regexp options are
> potentially broken, but blacklist_mappings definitely is:
>
> http://perldoc.perl.org/perlop.html#Quote-and-Quote-like-Operators
> http://perldoc.perl.org/perlop.html#Regexp-Quote-Like-Operators
>
> # checkrestart -v
> Found 0 processes using old versions of upgraded files
> # needrestart -v
> [main] eval /etc/needrestart/needrestart.conf
> [main] running in root-mode
> [Core] Using UI 'NeedRestart::UI::stdio'...
> [main] detected systemd
> ...
> [main] #27891 uses deleted /run/user/1000/orcexec.OVkLUB
> [main] #27891 is not a child
> ...
> [main] #27891 exe => /usr/bin/pulseaudio
> [main] #27891 part of user session: uid=1000 sess=17
> ...
> User sessions running outdated binaries:
>  pabs @ session #17: pulseaudio[27891]
> ...
> # lsof -p 27891 | grep orc
> pulseaudi 27891 pabs  DEL   REG   0,43253423 
> /run/user/1000/orcexec.OVkLUB
> pulseaudi 27891 pabs  mem   REG  253,1   517176 26870717 
> /usr/lib/x86_64-linux-gnu/liborc-0.4.so.0.25.0
> # grep orc /proc/27891/maps
> 7fe19801-7fe19802 rw-s  00:2b 253423 
> /run/user/1000/orcexec.OVkLUB (deleted)
> 7fe19802-7fe19803 r-xs  00:2b 253423 
> /run/user/1000/orcexec.OVkLUB (deleted)
> 7fe19b5eb000-7fe19b664000 r-xp  fd:01 26870717   
> /usr/lib/x86_64-linux-gnu/liborc-0.4.so.0.25.0
> 7fe19b664000-7fe19b863000 ---p 00079000 fd:01 26870717   
> /usr/lib/x86_64-linux-gnu/liborc-0.4.so.0.25.0
> 7fe19b863000-7fe19b865000 r--p 00078000 fd:01 26870717   
> /usr/lib/x86_64-linux-gnu/liborc-0.4.so.0.25.0
> 7fe19b865000-7fe19b869000 rw-p 0007a000 fd:01 26870717   
> /usr/lib/x86_64-linux-gnu/liborc-0.4.so.0.25.0
> # grep -r orc /etc/needrestart/
> /etc/needrestart/needrestart.conf:q(/orcexec\.[\w\d]+( \(deleted\))?$),
> # grep -P '/orcexec\.[\w\d]+( \(deleted\))?$' /proc/27891/maps
> 7fe19801-7fe19802 rw-s  00:2b 253423 
> /run/user/1000/orcexec.OVkLUB (deleted)
> 7fe19802-7fe19803 r-xs  00:2b 253423 
> /run/user/1000/orcexec.OVkLUB (deleted)
> # cat test.pl 
> my %nrconf;
> my $pid = '27891';
> $nrconf{blacklist_mappings_q} = [q(/orcexec\.[\w\d]+( \(deleted\))?$),];
> $nrconf{blacklist_mappings_qr} = [qr(/orcexec\.[\w\d]+( \(deleted\))?$),];
> if(open(HMAP, '<', "/proc/$pid/maps")) {
>   while() {
>   chomp;
>   my ($maddr, $mperm, $moffset, $mdev, $minode, $path) = 
> split(/\s+/, $_, 6);
>   if ($path =~ /orc/){
>   print "Path: $path";
>   print " blacklisted_q" if(scalar grep { $path =~ $_; } 
> @{$nrconf{blacklist_mappings_q}});
>   print " blacklisted_qr" if(scalar grep { $path =~ $_; } 
> @{$nrconf{blacklist_mappings_qr}});
>   print "\n";
>   }
>   }
> }
> # perl test.pl
> Path: /run/user/1000/orcexec.OVkLUB (deleted) blacklisted_qr
> Path: /run/user/1000/orcexec.OVkLUB (deleted) blacklisted_qr
> Path: /usr/lib/x86_64-linux-gnu/liborc-0.4.so.0.25.0
> Path: /usr/lib/x86_64-linux-gnu/liborc-0.4.so.0.25.0
> Path: /usr/lib/x86_64-linux-gnu/liborc-0.4.so.0.25.0
> Path: /usr/lib/x86_64-linux-gnu/liborc-0.4.so.0.25.0
> # sed -n /orc/p /etc/needrestart/needrestart.conf
> q(/orcexec\.[\w\d]+( \(deleted\))?$),
> # sed -i '/orc/s/q/qr/' /etc/needrestart/needrestart.conf
> # sed -n /orc/p /etc/needrestart/needrestart.conf
> qr(/orcexec\.[\w\d]+( \(deleted\))?$),
> # needrestart -v
> [main] eval /etc/needrestart/needrestart.conf
> [main] running in root-mode
> [Core] Using UI 'NeedRestart::UI::stdio'...
> [main] detected systemd
> ...
> No user sessions are running outdated binaries.
>
> -- System Information:
> Debian Release: stretch/sid
>   APT prefers testing-debug
>   APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
> 'unstable-debug'), (800, 'unstable'), (790, 

Bug#811177: closed by Thomas Goirand <z...@debian.org> (Problem *not* in automysqlbackup)

[Thomas Liske]

fixed 811177 2.1-1
severity 811177 minor
tags 811177 upstream fixed-upstream
thanks


On Sat, Jan 16, 2016 at 09:49:27PM +0100, Alexander Schier wrote:
> Oh, maybe i even configured it. I disabled the kernelhints some time
> ago, i am not sure if i edited the config directly, but probably i did.
> 
> I guess it's still a bug, isn't it?

yes, but no "Severity: serious"  :-). As pointed out in #805755 it has
been fixed upstream long time ago, but is missing in jessie.


HTH,
Thomas

--

::  WWW:https://fiasko-nw.net/~thomas/  ::
   :::  Jabber:   xmpp:tho...@jabber.fiasko-nw.net  :::
::  flickr: https://www.flickr.com/photos/laugufe/  ::

Bug#799733: needrestart: fails when being invoked

[Thomas Liske]

tag 799733 fixed-upstream
thanks


Hi Christoph, Hi Sven,

On Mon, Sep 21, 2015 at 11:56:33PM +0200, Christoph Anton Mitterer wrote:
> # needrestart
> Can't locate File/Slurp.pm in @INC (you may need to install the File::Slurp 
> module) (@INC contains: /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.20.2 
> /usr/local/share/perl/5.20.2 /usr/lib/x86_64-linux-gnu/perl5/5.20 
> /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.20 /usr/share/perl/5.20 
> /usr/local/lib/site_perl .) at /usr/sbin/needrestart line 30.
> BEGIN failed--compilation aborted at /usr/sbin/needrestart line 30.

D'Oh! A method of the File::Slurp module was used during development
of needrestart 2.3. But in the final release of needrestart 2.3 no
function of File::Slurp was used any more. So this is a orphan
dependency.

Patrick has already uloaded needrestart 2.3-2 adding the dependency
(quick'n'dirty workaround). In needrestart 2.4 the dependency will be
dropped from the needrestart command and the package.


HTH,
Thomas

--

::  WWW:https://fiasko-nw.net/~thomas/  ::
   :::  Jabber:   xmpp:tho...@jabber.fiasko-nw.net  :::
::  flickr: https://www.flickr.com/photos/laugufe/  ::

Bug#771348: needrestart: starts not running services

[Thomas Liske]

severity 771348 normal
tags 771348 - security
thanks

On 11/28/2014 07:06 PM, Christoph Anton Mitterer wrote:

Since this may start services which are only to be run under specific
situations, e.g. when only in a secure network, or when VPN is running
because they may grant system access e.g. without authentication...
(take ssh which can be configured to allow password less access to root)
I'm marking this severity=critical and tags=security.


needrestart does not automaticly restart any services by default. I 
don't see any security issues if the user selects to restart a service 
(although the service was not running before). Sorry, but your example 
sounds hypothetical to me.


You could add a entry to override_rc to prevent ssh to be restarted 
accidentally.



HTH,
Thomas


Maybe the whole things applies to non-SSH as well, since a while I'm always
seeing two entries for GDM, one gdm3.service and gdm3 alone.



-- Package-specific info:
needrestart output:
Running kernel seems to be up-to-date.
Services to be restarted:
service dbus restart



-- System Information:
Debian Release: jessie/sid
   APT prefers unstable
   APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_DE.utf8, LC_CTYPE=en_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages needrestart depends on:
ii  dpkg   1.17.22
ii  libmodule-find-perl0.12-1
ii  libmodule-scandeps-perl1.16-1
ii  libproc-processtable-perl  0.51-1
ii  libsort-naturally-perl 1.03-1
ii  libterm-readkey-perl   2.32-1+b1
ii  perl   5.20.1-3

needrestart recommends no packages.

needrestart suggests no packages.

-- Configuration Files:
/etc/needrestart/needrestart.conf changed:
$nrconf{defno} = 1;
$nrconf{blacklist} = [
 # ignore sudo (not a daemon)
 q(^/usr/bin/sudo(\.dpkg-new)?$),
 # ignore DHCP clients
 q(^/sbin/(dhclient|dhcpcd5|pump|udhcpc)(\.dpkg-new)?$),
];
$nrconf{override_rc} = {
 # DBus
 q(^dbus) = 0,
 # display managers
 q(^gdm) = 0,
 q(^kdm) = 0,
 q(^nodm) = 0,
 q(^wdm) = 0,
 q(^xdm) = 0,
 q(^lightdm) = 0,
 # networking stuff
 q(^network-manager) = 0,
 q(^NetworkManager) = 0,
 q(^openvpn) = 0,
 q(^quagga) = 0,
 q(^tinc) = 0,
 # gettys
 q(^getty@.+\.service) = 0,
 # misc
 q(^zfs-fuse) = 0,
 q(^mythtv-backend) = 0,
};
if(-d q(/etc/needrestart/conf.d)) {
   foreach my $fn (sort /etc/needrestart/conf.d/*.conf) {
  print STDERR $LOGPREF eval $fn\n if($nrconf{verbose});
  eval do { local(@ARGV, $/) = $fn; };
  die Error parsing $fn: $@ if($@);
   }
}


-- no debconf information




--

::  WWW: http://fiasko-nw.net/~thomas/  ::
   :::  Jabber:   xmpp:tho...@jabber.fiasko-nw.net  :::
::  flickr:  http://www.flickr.com/photos/laugufe/  ::


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

Bug#770937: needrestart: Kills wdm session on system running systemd g (maybe via dbus restart)

[Thomas Liske]

Hi Axel,


restarting dbus kills any graphical user session.

On 11/25/2014 11:58 AM, Axel Beckert wrote:

recently, it happened twice that needrestart killed my X session which
was started by wdm and is running the awesome window manager via
~/.Xsession.


sorry :-(



I don't think it's the new upload but rather the recent dbus updates. I
can't exactly remember if the second-last case was at the time when dbus
was updated (and if so, needrestart would have been at version 1.2-4),
but the case today definitely had a dbus update included.

According to the logs it also restarted systemd itself.


This happens if needrestart detects systemd using outdated libs. 
needrestart suggests to run `systemctl daemon-reexec` if it detects that 
pid 1 uses outdated binaries (if systemd was detected).




in the (used) default config, systemd restarted dbus:


Are you able to kill your X session by calling `systemctl daemon-reexec` 
manually?





Nov 25 11:18:57 c-cactus systemd[1]: Reexecuting.
Nov 25 11:18:57 c-cactus systemd[1]: systemd 215 running in system mode. (+PAM 
+AUDIT +SELINUX +IMA +SYSVINIT +LIBCRYPTSETUP +GCRYPT +ACL +XZ -SECCOMP 
-APPARMOR)
Nov 25 11:18:57 c-cactus systemd[1]: Detected architecture 'x86-64'.
Nov 25 11:18:57 c-cactus systemd[1]: Started ACPI event daemon.
Nov 25 11:18:57 c-cactus systemd[1]: Mounted /var.
Nov 25 11:18:57 c-cactus systemd[1]: Mounted /home.
Nov 25 11:18:57 c-cactus systemd[1]: Mounted /boot.
Nov 25 11:18:57 c-cactus systemd[1]: Mounted /.
Nov 25 11:18:57 c-cactus systemd[1]: Started File System Check on 
/dev/disk/by-uuid/….
[…]
Nov 25 11:18:57 c-cactus systemd[1]: Activated swap /dev/…/swap.


At this point `systemctl reexec` should have been finished.



Nov 25 11:18:57 c-cactus systemd[1]: Stopping Accounts Service...
Nov 25 11:18:57 c-cactus systemd[1]: Stopping Avahi mDNS/DNS-SD Stack...
Nov 25 11:18:57 c-cactus systemd[1]: Stopping Bluetooth service...
Nov 25 11:18:57 c-cactus systemd[1]: Stopping Regular background program 
processing daemon...
Nov 25 11:18:57 c-cactus systemd[1]: Starting Regular background program 
processing daemon...
Nov 25 11:18:57 c-cactus systemd[1]: Started Regular background program 
processing daemon.
Nov 25 11:18:57 c-cactus systemd[1]: Stopping D-Bus System Message Bus...
Nov 25 11:18:57 c-cactus systemd[1]: Starting Accounts Service...
Nov 25 11:18:57 c-cactus systemd[1]: Starting Bluetooth service...
Nov 25 11:18:57 c-cactus systemd[1]: Stopping OpenBSD Secure Shell server...
Nov 25 11:18:57 c-cactus systemd[1]: Stopping Journal Service...
Nov 25 11:18:57 c-cactus systemd[1641]: Stopping Default.
Nov 25 11:18:57 c-cactus systemd[1641]: Stopped target Default.
Nov 25 11:18:57 c-cactus systemd[1641]: Stopping Basic System.
Nov 25 11:18:57 c-cactus systemd[1641]: Stopped target Basic System.
Nov 25 11:18:57 c-cactus systemd[1641]: Stopping Paths.
Nov 25 11:18:57 c-cactus systemd[1641]: Stopped target Paths.
Nov 25 11:18:57 c-cactus systemd[1641]: Stopping Timers.
Nov 25 11:18:57 c-cactus systemd[1641]: Stopped target Timers.
Nov 25 11:18:57 c-cactus systemd[1641]: Stopping Sockets.
Nov 25 11:18:57 c-cactus systemd[1641]: Stopped target Sockets.
Nov 25 11:18:57 c-cactus systemd[1641]: Starting Shutdown.
Nov 25 11:18:57 c-cactus systemd[1641]: Reached target Shutdown.
Nov 25 11:18:57 c-cactus systemd[1641]: Starting Exit the Session...
Nov 25 11:18:57 c-cactus systemd[1]: Starting OpenBSD Secure Shell server...
Nov 25 11:18:57 c-cactus systemd[1]: Started OpenBSD Secure Shell server.
Nov 25 11:18:57 c-cactus systemd[1641]: Received SIGRTMIN+24 from PID 12082 
(kill).
Nov 25 11:18:57 c-cactus systemd[1]: Started Trigger Flushing of Journal to 
Persistent Storage.
Nov 25 11:18:57 c-cactus systemd[1]: Starting Daemon for power management...
Nov 25 11:18:57 c-cactus systemd[1]: Starting LSB: Starts and stops Wicd...
Nov 25 11:18:57 c-cactus systemd[1]: Starting D-Bus System Message Bus...
Nov 25 11:18:57 c-cactus systemd[1]: Started D-Bus System Message Bus.
Nov 25 11:18:57 c-cactus systemd[1]: Started Bluetooth service.
Nov 25 11:18:57 c-cactus systemd[1]: Starting Hostname Service...
Nov 25 11:18:57 c-cactus systemd[1]: Started Accounts Service.
Nov 25 11:18:57 c-cactus systemd[1]: Started Daemon for power management.
Nov 25 11:18:57 c-cactus systemd[1]: Starting User Manager for UID 1000...
Nov 25 11:18:57 c-cactus systemd[1]: Starting Login Service...
Nov 25 11:18:57 c-cactus systemd[1]: Started Hostname Service.
Nov 25 11:18:57 c-cactus systemd[1]: Started Login Service.
Nov 25 11:18:57 c-cactus systemd[1]: Started User Manager for UID 1000.
Nov 25 11:18:58 c-cactus systemd[1]: Starting Session c1 of user abe.
Nov 25 11:18:58 c-cactus systemd[1]: Started Session c1 of user abe.
Nov 25 11:18:59 c-cactus systemd[1]: Starting LSB: start or stop the WINGs 
display manager...
Nov 25 11:18:59 c-cactus systemd[1]: Started LSB: start or stop the WINGs 
display manager.
Nov 25 11:18:59 c-cactus systemd[1]: Starting X11 Display Manager.
Nov 25 

Bug#770937: needrestart: Kills wdm session on system running systemd g (maybe via dbus restart)

[Thomas Liske]

Re,

On 11/25/2014 08:53 PM, Axel Beckert wrote:

Hi Thomas,

Thomas Liske wrote:

restarting dbus kills any graphical user session.


I wouldn't say that. But it's probably true for most modern desktop
environments and systemd -- unfortunately.


I'm afraid so!



in the (used) default config, systemd restarted dbus:


Are you able to kill your X session by calling `systemctl
daemon-reexec` manually?


Nope, can still work in that session. :-)


Phew!



Nov 25 11:18:57 c-cactus systemd[1]: Activated swap /dev/…/swap.


At this point `systemctl reexec` should have been finished.


That's also where the log ended after the manual systemctl
daemon-reexec.


OK


It might be an dependency issue... X11 Display Manager depends on
something that needrestart did suggest to restart.


Compared to modern login managers, wdm's dependencies are rather lightweight:

Depends: libc6 (= 2.11), libpam0g (= 0.99.7.1), libselinux1 (=
1.32), libwings2 (= 0.95.0), libwraster3 (= 0.95.0), libwutil2 (=
0.95.0), libx11-6, libxau6, libxdmcp6, libxinerama1, libxmu6, debconf
(= 1.5.20) | debconf-2.0, libpam-runtime (= 0.76-13.1),
libpam-modules, psmisc, x11-apps, x11-common, x11-xserver-utils,
x11-utils


I meant the systemd services dependencies. I did just take a short look 
on my local systemd+kdm+kde environment... but I've no idea how it works 
at all :-(




Are you able to remember which service were selected?


Not at all, because I had set $nrconf{restart} = 'a' and systemd
doesn't care to tell me what it does -- compared to needrestart on a
system with good old sysvinit. Meh.


If you did not run needrestart in the meanwhile you might find your
selection still in debconf:

$ grep -A 8 'needrestart/ui-query_pkgs$' /var/cache/debconf/config.dat


This looks very suspicious:




Value: dbus.service, lxc
Variables:
  PKGS = dbus.service, lxc, wdm.service



Value: dbus.service, lxc
  PKGS = dbus.service, lxc, wdm.service



So why the heck are there wdm and dbus listed?


The Value field it the important one, the PKGS variable is just used 
to build the list. If dbus was restarted this was the cause of killing 
your session :-(




with only one exception:

→ cat /etc/needrestart/conf.d/abe.conf
#$nrconf{restart} = 'a';
$nrconf{ui} = 'NeedRestart::UI::stdio';


Maybe the problem is within the code path of the auto restart mode. This 
might not be tested as extensive as the list mode... I'll need to dig 
into it...



Thx  HTH,
Thomas

--

::  WWW: http://fiasko-nw.net/~thomas/  ::
   :::  Jabber:   xmpp:tho...@jabber.fiasko-nw.net  :::
::  flickr:  http://www.flickr.com/photos/laugufe/  ::


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

Bug#770937: needrestart: Kills wdm session on system running systemd g (maybe via dbus restart)

[Thomas Liske]

tags 770937 upstream fixed-upstream
thanks


Re,


On 11/25/2014 09:17 PM, Thomas Liske wrote:

Are you able to remember which service were selected?


Not at all, because I had set $nrconf{restart} = 'a' and systemd
doesn't care to tell me what it does -- compared to needrestart on a
system with good old sysvinit. Meh.


If you did not run needrestart in the meanwhile you might find your
selection still in debconf:

$ grep -A 8 'needrestart/ui-query_pkgs$' /var/cache/debconf/config.dat


This looks very suspicious:


sorry, I was a little bit confused... the debconf template 
needrestart/ui-query_pkgs is not used in auto mode but only in 
interactive mode.



Maybe the problem is within the code path of the auto restart mode. This
might not be tested as extensive as the list mode... I'll need to dig

  
  auto


into it...


...and I've found the bug - the override_rc option was never evaluated 
in auto mode. Upstream have been patched to respect the defno and 
override_rc settings in auto mode, too.


https://github.com/liske/needrestart/commit/62d07dc271a89cf1584cc3ee2a13b4fae47dc6bc

Sorry for the trouble caused by killing your sessions.


HTH,
Thomas

--

::  WWW: http://fiasko-nw.net/~thomas/  ::
   :::  Jabber:   xmpp:tho...@jabber.fiasko-nw.net  :::
::  flickr:  http://www.flickr.com/photos/laugufe/  ::


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

Bug#767584: segfaults when segfaults when a dot is used in the config as part of the hostname

[Thomas Liske]

tag 767584 upstream, fixed-upstream
thanks


Hi Simon,

On 11/20/2014 02:14 PM, Simon Kainz wrote:

Please see the attached patch. This essentially replaces g_error() by
g_printerr(), now preventing a SIGTERM after g_error() is called.
According to [0] this is intended behavior, because g_error() should
be used for things like assertion failures, not for expected errors.


thanks for pointing this out. I've applied your patch upstream.


Thanks,
Thomas


--
supp...@ibh.de  Tel. +49 351 477 77 30
www.ibh.de  Fax  +49 351 477 77 39

---
Dipl.-Ing. Thomas Liske
Netzwerk- und System-Design


IBH IT-Service GmbH Amtsgericht Dresden
Gostritzer Str. 67a HRB 13626
D-01217 Dresden GF: Prof. Dr. Thomas Horn
Germany VAT DE182302907
---
Ihr Partner für: LAN, WAN IP-Quality, Security, VoIP, SAN, Backup, USV
---
   professioneller IT-Service - kompetent und zuverlässig
---


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

Bug#769544: needrestart: prompts user without following Debian Configuration Management Specification - accesses /dev/tty

[Thomas Liske]

Re,

On 11/15/2014 03:49 PM, Andreas Beckmann wrote:

On 2014-11-14 19:48, Thomas Liske wrote:

On 11/14/2014 01:07 PM, Andreas Beckmann wrote:

during a test with piuparts I noticed your package prompts the user
badly.  Prompting in maintainer scripts must be done by communicating
through a program such as debconf which conforms to the Debian
Configuration Management Specification, version 2 or higher.


the Debian Policy does not apply - the observed bug is within the
upstream perl core.


The Policy applies to upstream bugs too, as long as they are found in Debian. 
:-)


You are quoting a section applying to debian maintainer scripts - the 
maintainer script in needrestart does not use debconf nor is it buggy at 
all. needrestart is launched by apt outside of dpkg - it's just apt 
which hangs due to the buggy DPkg::Post-Invoke command.


So the package can be installed/upgraded/removed without problems... 
it's just the dpkg frontend which hangs due to the bug ;-P



But that's just academic - the bug is silly and needs to be fixed 	for 
jessie without any doubt.




I think this is triggered by a division by zero in the same code path as
in #767370. This could be triggered if no kernel images were found or no


I could verify that the bug disappears if I use
   --extra-old-packages linux-image-amd64
so merging the two reports.


Thanks for confirming  merging!



process being a restart candidates. Both conditions occure rarely in the
wild. Therefore the severity of this issue should be not higher than
normal.


No kernel installed is not uncommon in virtualized environments - this
is where the bug was found initially.
I would agree on a lower severity if piuparts was the only way to
trigger the bug.


Paravirtualized using libvirt AFAIK - there are many other 
virtualization environments requiring a kernel image inside the 
container. But the bug should keep a severity of serious[1] if it 
violates the debian policy.


[1] https://www.debian.org/Bugs/Developer#severities



The current upload you want to get into jessie was only uploaded with
priority=low. If the upstream fix for this bug here gets backported
and uploaded with priority=medium it would be eligible for migration
at the same time. I think you should do that, especially since I do
not see an unblock request for the current version in sid.


The patch for #767370 and #769544 has not been uploaded by Patrick, yet.


HTH,
Thomas

--

::  WWW: http://fiasko-nw.net/~thomas/  ::
   :::  Jabber:   xmpp:tho...@jabber.fiasko-nw.net  :::
::  flickr:  http://www.flickr.com/photos/laugufe/  ::


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

Bug#769544: needrestart: prompts user without following Debian Configuration Management Specification - accesses /dev/tty

[Thomas Liske]

tag 769544 severity normal
thanks

Hi Andreas,

On 11/14/2014 01:07 PM, Andreas Beckmann wrote:

during a test with piuparts I noticed your package prompts the user
badly.  Prompting in maintainer scripts must be done by communicating
through a program such as debconf which conforms to the Debian
Configuration Management Specification, version 2 or higher.


the Debian Policy does not apply - the observed bug is within the 
upstream perl core.




A new installation works fine, updates are problematic.
The piuparts test is killed after exceeding its runtime.
Right now I accidently noticed this in a window where piuparts-slave is
running:

12:42:06 Testing package testing2sid/main/needrestart 1.2-4
Scanning processes...
Scanning candidates...
SET needrestart/ui-query_pkgs sysv init


I think this is triggered by a division by zero in the same code path as 
in #767370. This could be triggered if no kernel images were found or no 
process being a restart candidates. Both conditions occure rarely in the 
wild. Therefore the severity of this issue should be not higher than normal.




You may not access /dev/tty for prompting (or whatever) ...
use debconf *properly*.


/dev/tty is not used for prompting while using needrestart's debconf 
frontend - but the bug broke the debconf pipe.


needrestart does intentionally not use debconf's progressbar widget 
since it disrupts the tty's scrollback buffer (see also #748758).



HTH,
Thomas

--

::  WWW: http://fiasko-nw.net/~thomas/  ::
   :::  Jabber:   xmpp:tho...@jabber.fiasko-nw.net  :::
::  flickr:  http://www.flickr.com/photos/laugufe/  ::


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

Bug#735027: needrestart: blacklist lightdm

[Thomas Liske]

Hi Michael,

On 01/12/2014 12:23 AM, Cyril Brulebois wrote:
 Michael Gilbert mgilb...@debian.org (2014-01-11):
 package: needrestart
 severity: grave
 version: 0.5-1
 tags: patch

 needrestart currently blacklists other desktop managers, but not

I've added your patch upstream - thanks for contributing!


 lightdm.  There is the potential to lose data when needrestart
 suggests restarting lightdm.
 
 That is not data loss.

This is no data loss (in sense of corrupting on disk data). The user is
asked before restarting any service and can change the configuration to
ignore lightdm. The severity of this bug should be changed to minor IMHO.


HTH,
Thomas

-- 

::  WWW: http://fiasko-nw.net/~thomas/  ::
   :::  Jabber:   xmpp:tho...@jabber.fiasko-nw.net  :::
::  flickr:  http://www.flickr.com/photos/laugufe/  ::


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

Bug#732461: needrestart: fails to install, remove, and install again

[Thomas Liske]

Hi Andreas,

On 12/18/2013 10:49 AM, Andreas Beckmann wrote:
 Package: needrestart
 Version: 0.4-1
 Severity: serious
 User: debian...@lists.debian.org
 Usertags: piuparts
 
 Hi,
 
 during a test with piuparts I noticed your package failed to install,
 remove (but not purge), and install again.
 Before the second installation the package is in config-files-remaining
 state. The configuration is remaining from the last version that was
 successfully configured - which is the same version that is going to be
 installed again.
 
 Like a plain failure on initial install this makes the package too buggy
 for a release, thus the severity.

it is even more worse. After removing the package it breaks dpkg to
install/upgrade/uninstall any packages. As a workaround you have to
manually disable/remove the old config file
/etc/dpkg/dpkg.cfg.d/needrestart.

I've improved the upstream config template to handle this issue
gracefully:
https://github.com/liske/needrestart/commit/327830f4bf2f573704d5135e8beb1204a3543126


HTH,
Thomas


From the attached log (scroll to the bottom...):
 
 0m22.3s DEBUG: Starting command: ['chroot', '/tmp/piupartss/tmpwc6DQn', 
 'apt-get', '-y', 'install', 'needrestart=0.4-1']
 0m22.8s DUMP: 
   Reading package lists...
   Building dependency tree...
   Reading state information...
   The following NEW packages will be installed:
 needrestart
   debconf: delaying package configuration, since apt-utils is not installed
   0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
   Need to get 0 B/10.9 kB of archives.
   After this operation, 124 kB of additional disk space will be used.
   /bin/bash: /usr/lib/needrestart/dpkg-status: No such file or directory
   Selecting previously unselected package needrestart.
   (Reading database ... 8301 files and directories currently installed.)
   Preparing to unpack .../needrestart_0.4-1_all.deb ...
   E: Sub-process /usr/bin/dpkg exited unexpectedly
 0m22.8s ERROR: Command failed (status=100): ['chroot', 
 '/tmp/piupartss/tmpwc6DQn', 'apt-get', '-y', 'install', 'needrestart=0.4-1']
 
 
 cheers,
 
 Andreas
 


-- 

::  WWW: http://fiasko-nw.net/~thomas/  ::
   :::  Jabber:   xmpp:tho...@jabber.fiasko-nw.net  :::
::  flickr:  http://www.flickr.com/photos/laugufe/  ::


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

Bug#611088: apt-dater-host silently ignores ABI-incompatible

[Thomas Liske]

Hi,

On 01/29/2011 06:26 PM, Patrick Matthäi wrote:

Am 29.01.2011 18:07, schrieb Stefan Bühler:

Hi,

shouldn't the do_upgrade method use dist-upgrade too then?

I guess it would be at least nice to have the option to run dist-upgrade
instead of (safe-)upgrade in the frontend.


I already thought about that, but I think (with assumeyes) that it may
break systems, especially if someone is using testing.



dist-upgrade should not be used without some additional tweaks (it might 
not be safe under all circumstances). I'm still tweaking it for 
apt-dater 0.8.5 - using dist-upgrade for do_status was the simplest way 
to prevent 0.8.4 from hiding ABI upgrades.



Regards,
Thomas

--
   :::  GnuPG: 0x49D0C2C3  mailto:tho...@fiasko-nw.net  :::
   :::xmpp:tho...@jabber.fiasko-nw.net  :::




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

Bug#560186: The bug is still there...

[Thomas Liske]

Hi Micha,

Micha vor dem Berge schrieb:

Hi all,

I followed the discussion about this bug, updated apt-dater and
apt-dater-host to version 0.8.1+svn450-1 (available in sid) and still
get the hosts placed in unknown no matter which status they should
have (updates pending or up to date or whatever).

If you look at the project bug tracker, you'll see that somebody else
obviously noticed this bug...

http://sourceforge.net/tracker/?func=detailaid=2933741group_id=233727atid=1091021


I'd just fixed this bug on SF - it was triggered when a (Debian) host 
didn't have a stock Debian kernel installed. SVN HEAD contains a 
apt-dater-host script which fixes this issue.


If your problemes still exists by the most recent SVN HEAD version, I 
would prefer if you open a new bug report. This one seems to touch more 
than one bug; most of them fixed upstream in the meantime.


The packages in sid are missing some bugfixes and we are going to do a 
bugfix release 0.8.2 very soon.



Cheers,
Thomas



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

Bug#560186: apt-dater: suddenly fails to see updates and reports hosts as unknown

[Thomas Liske]

Hi,

Patrick Matthäi wrote:

On Wed, Dec 09, 2009 at 03:50:02PM +0100, Patrick Matthäi wrote:


could you send me the files of one host from
~/.cache/apt-dater/stats/hostname* please.

I'll send you two. osama:22.stat is from a box running unstable,
which shows up as up to date wrongly, while dungheap:22.stat is
from a machine running lenny which shows up as unknown.



Your osama problem might be a bit more difficult. I will test it later.
But for dungheap you do not have the right apt-dater-host version or
better said, noone that is known by me:
STATUS: apt-dater-host|0.8.0-3coretec1|x


there is something curious. I'd feeded your stats files into apt-dater 
(SVN Head build) on my Lenny host and the hosts showed up as Updates 
pending. The Debian package is still in sync w/ SVN HEAD IMHO - 
Patrick, might it be a packaging problem ;) ?



Regards,
Thomas


What happens, if you use the apt-dater-host packages from
{etch,lenny}-backports? Yeah apt-dater is in both backports :)


What happens if you enter the host about apt-dater with the 'c' key?

I get an ssh session, as expected.


Also for the unknown one?








--
supp...@ibh.de  Tel. +49 351 477 77 30
www.ibh.de  Fax  +49 351 477 77 39

---
Dipl.-Ing. Thomas Liske
Netzwerk- und System-Design


IBH IT-Service GmbH Amtsgericht Dresden
Gostritzer Str. 61-63   HRB 13626
D-01217 Dresden GF: Prof. Dr. Thomas Horn
Germany VAT DE182302907
---
Ihr Partner für: LAN, WAN IP-Quality, Security, VoIP, SAN, Backup, USV
---
   professioneller IT-Service - kompetent und zuverlässig
---



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

Bug#560186: apt-dater: suddenly fails to see updates and reports hosts as unknown

[Thomas Liske]

Re,

On Wed, 9 Dec 2009, Patrick Matthäi wrote:


Am 09.12.2009 17:11, schrieb Thomas Liske:

Hi,

Patrick Matthäi wrote:

On Wed, Dec 09, 2009 at 03:50:02PM +0100, Patrick Matthäi wrote:


could you send me the files of one host from
~/.cache/apt-dater/stats/hostname* please.

I'll send you two. osama:22.stat is from a box running unstable,
which shows up as up to date wrongly, while dungheap:22.stat is
from a machine running lenny which shows up as unknown.

 

Your osama problem might be a bit more difficult. I will test it later.
But for dungheap you do not have the right apt-dater-host version or
better said, noone that is known by me:
STATUS: apt-dater-host|0.8.0-3coretec1|x


there is something curious. I'd feeded your stats files into apt-dater
(SVN Head build) on my Lenny host and the hosts showed up as Updates
pending. The Debian package is still in sync w/ SVN HEAD IMHO -
Patrick, might it be a packaging problem ;) ?


Hm fuck.

I have backported installed the testing version on our update server and I 
have got the same symptoms, also if the apt-dater-host package is in sync 
with the apt-dater version.


One host should have got updates and the other ones should be up to date.

Now 4 hosts are in up to date (also the one with updates) and all the other 
ones are going into unknown.


Also curious:
if I close now apt-dater and reopen it, _every_ host is again in unknown


OK I think I've tracked it down. There was a damn spare ! on an if 
condition which brakes the hole parcing stuff. There was a changed on the 
error handling between ADPROTO 0.3 and 0.5 - the old version is handled as 
UNKNOWN, the recent version is handled as UPTODATE.


Upstream has been fixed w/ r432, please try out.


Cheers,
Thomas

Bug#470298: rssh allows remote command execution

[Thomas Liske]

Package: rssh
Version: 2.3.2-2
Severity: grave
Tags: security
Justification: user security hole

rssh allows remote command execution using shell backticks:

$ ssh [EMAIL PROTECTED] rsync `cat /etc/issue`

will run 'cat /etc/issue' on the remote host:

Mar 10 15:29:55 ijon rssh[11414]: setting log facility to LOG_USER
Mar 10 15:29:55 ijon rssh[11414]: setting umask to 022
Mar 10 15:29:55 ijon rssh[11414]: user liske attempted to execute forbidden 
commands
Mar 10 15:29:55 ijon rssh[11414]: command: rsync Debian GNU/Linux 4.0 \n \l


Cheers,
Thomas Liske

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

Versions of packages rssh depends on:
ii  debconf [debconf-2.0]  1.5.11etch1   Debian configuration management sy
ii  libc6  2.3.6.ds1-13etch5 GNU C Library: Shared libraries
ii  openssh-server 1:4.3p2-9 Secure shell server, an rshd repla

rssh recommends no packages.

-- debconf information excluded



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