Bug#1035904: dpkg currently warning about merged-usr systems (revisited)

[Roger Lynn]

On 15/05/2023 19:00, Simon McVittie wrote:
> On Sun, 14 May 2023 at 23:37:34 +0200, Josh Triplett wrote:
>> People build things on Debian that are not Debian packages. People
>> compile binaries on Debian, and expect them to work on any system that
>> has sufficiently new libraries.
> 
> *raises hand*
> 
> Hello, I represent an example of those people. With my $work hat on,
> I'm involved in maintaining a family of Debian derivatives (the Steam
> Runtime) that is used to run Steam games on arbitrary distributions,
> including but not limited to Debian. Some of these binaries are built
> on a Debian derivative, but run on an arbitrary other distribution,
> using a RPATH[1] to find their non-glibc dependencies.

As another much smaller example, which I hope is still relevant, I have
taken binaries from Debian stable or oldstable armel and run them for
diagnostic purposes on embedded boards which only have Busybox installed and
for which I don't have a convenient build environment.

Regards,
Roger

PS Apologies if I've followed up incorrectly - I read debian-devel through
an NNTP gateway.

Bug#947771: unbound: cannot restart daemon under sysvinit-core when apparmor is enforced

[Roger Lynn]

Followup-For: Bug #947771
Package: unbound
Version: 1.13.1-1

On Fri, 03 Jul 2020 19:27:17 +0900 Stephane Lapie 
 wrote:

I worked around this issue by adding --remove-pidfile to the "start-stop-daemon 
--stop" commands.


On Thu, 28 Jan 2021 02:19:05 +0800 Gedalya  wrote:

-    if start-stop-daemon --stop --quiet --oknodo --pidfile $PIDFILE --name 
$NAME --retry 5; then
+    if start-stop-daemon --stop --quiet --oknodo --remove-pidfile 
--pidfile $PIDFILE --name $NAME --retry 5; then


Thank you, this fixed it for me.

This bug would appear to be related to that described at
https://github.com/NLnetLabs/unbound/issues/303
but that was apparently fixed in 1.13.0.

Regards,

Roger

Bug#992886: r8169: no dedicated PHY driver found for PHY ID 0xc1071002

[Roger Lynn]

On 05/09/2021 09:07, Salvatore Bonaccorso wrote:

On Wed, Sep 01, 2021 at 10:59:19PM +0100, Roger Lynn wrote:

On Wed, 25 Aug 2021 08:07:48 +0200 Heiner Kallweit 
wrote:
> A number of Gigabyte boards from ~2009 have broken BIOS support, resulting in 
the PHY
> reporting an invalid PHY ID. Realtek / Gigabyte don't release errata 
information,
> therefore there's not much that can be done. In bugzilla.kernel.org you can 
find
> workarounds that helped for some users, else use the r8168 driver.

In https://bugzilla.kernel.org/show_bug.cgi?id=207203 it was suggested to
enable the boot ROM in the BIOS and/or reinsert the r8169 kernel module.
Neither of these worked for me. Fortunately the r8168-dkms package does
work. Thank you for the suggestion, as I was not aware of this driver.


According to the discussion, there is not something to patch on the
kernel side and rather likely a BIOS bug. So closing the bug.


The r8168-dkms package asks for bugs to be filed when it works but the 
in-kernel driver doesn't. I guess this bug already counts for that.

Bug#992378: /etc/apparmor.d/usr.sbin.cupsd: Prevents Let's Encrypt certificates from being used

[Roger Lynn]

On 06/09/2021 11:05, Didier 'OdyX' Raboud wrote:

CUPS appears to already have access to everything in /etc/ssl/ on all
systems, which is where I used to keep my CAcert certificates. This doesn't
feel any different.


You're absolutely right; that's convincing to me!

Reopening, and will fix in the next upload.


Excellent! Thank you.

Bug#993819: release-notes: Please document the removal of wicd

[Roger Lynn]

Package: release-notes
Severity: important

Hi,

Please document the removal of wicd in Bullseye. This seems particularly
dangerous if the upgrade is being done over a network connection being managed
by wicd as it seems likely that the connection will be lost when wicd is
removed (due to dependency problems). It would also be helpful if alternatives
could be suggested.

Thanks,

Roger

Bug#992886: r8169: no dedicated PHY driver found for PHY ID 0xc1071002

[Roger Lynn]

On Wed, 25 Aug 2021 08:07:48 +0200 Heiner Kallweit  
wrote:

A number of Gigabyte boards from ~2009 have broken BIOS support, resulting in 
the PHY
reporting an invalid PHY ID. Realtek / Gigabyte don't release errata 
information,
therefore there's not much that can be done. In bugzilla.kernel.org you can find
workarounds that helped for some users, else use the r8168 driver.


In https://bugzilla.kernel.org/show_bug.cgi?id=207203 it was suggested to 
enable the boot ROM in the BIOS and/or reinsert the r8169 kernel module. 
Neither of these worked for me. Fortunately the r8168-dkms package does 
work. Thank you for the suggestion, as I was not aware of this driver.


Roger

Bug#992378: /etc/apparmor.d/usr.sbin.cupsd: Prevents Let's Encrypt certificates from being used

[Roger Lynn]

On 27/08/2021 14:33, Didier 'OdyX' Raboud wrote:> Control: tags -1 +wontfix

Using Let's Encrypt is fine, allowed, and (apparently) working with CUPS,
but as that's clearly not a default way of working for CUPS, I'd be
_very_ reluctant to allow CUPS to access "all the Let's Encrypt
certificates" on all systems it gets installed to. Furthermore, 
/etc/apparmor.d/usr.sbin.cupsd is a configuration file, freely

modifiable by the local system administrator. In other words, imposing
that a local system administrator needs to update that file to enable a
specific type of certificates is reasonable.


CUPS appears to already have access to everything in /etc/ssl/ on all 
systems, which is where I used to keep my CAcert certificates. This doesn't 
feel any different.


On 29/08/2021 08:31, Didier 'OdyX' Raboud wrote:

Le vendredi, 27 août 2021, 18.31:17 h CEST Roger Lynn a écrit :

The documentation is definitely lacking - I've been trying to work out
why my configuration broke since upgrading to Buster 3 months ago! Even
with the loglevel set to "debug", the logs were utterly unhelpful.
Let's Encrypt is the most popular source of signed certificates and the
upstream documentation at https://www.cups.org/doc/encryption.html
explicitly says:

"CUPS also supports certificates created and managed by the popular
Let's Encrypt certificate service, which are stored in the
/etc/letsencrypt/live directory."


Right. Where do you suggest this needed apparmor edition should be
documented?
README.Debian or cups-files.conf(5) seem appropriate. A mention in 
NEWS.Debian would have been useful, but it's probably a bit late for that now.


Thanks,

Roger

Bug#992378: /etc/apparmor.d/usr.sbin.cupsd: Prevents Let's Encrypt certificates from being used

[Roger Lynn]

The documentation is definitely lacking - I've been trying to work out why
my configuration broke since upgrading to Buster 3 months ago! Even with the
loglevel set to "debug", the logs were utterly unhelpful. Let's Encrypt is
the most popular source of signed certificates and the upstream
documentation at https://www.cups.org/doc/encryption.html explicitly says:

"CUPS also supports certificates created and managed by the popular Let's
Encrypt certificate service, which are stored in the /etc/letsencrypt/live
directory."

Bug#992886: r8169: no dedicated PHY driver found for PHY ID 0xc1071002

[Roger Lynn]

Package: src:linux
Version: 5.10.46-4
Severity: normal
File: /lib/modules/5.10.0-8-amd64/kernel/drivers/net/ethernet/realtek/r8169.ko

I've just upgraded this machine to Bullseye and it seems unable to load the
ethernet driver:

[6.548031] r8169 :02:00.0: can't disable ASPM; OS doesn't have ASPM 
control
[6.566607] libphy: r8169: probed
[6.566613] r8169 :02:00.0: no dedicated PHY driver found for PHY ID 
0xc1071002, maybe realtek.ko needs to be added to initramfs?
[6.590372] r8169: probe of :02:00.0 failed with error -49
[6.590412] r8169 :03:00.0: can't disable ASPM; OS doesn't have ASPM 
control
[6.592984] libphy: r8169: probed
[6.592987] r8169 :03:00.0: no dedicated PHY driver found for PHY ID 
0xc1071002, maybe realtek.ko needs to be added to initramfs?
[6.626342] r8169: probe of :03:00.0 failed with error -49

This is long after the filesystem has been mounted, so the initramfs should be
irrelevant, but I tried adding the realtek and r8169 modules to the initramfs
and the only difference was that the error was earlier in the boot sequence.

The machine is 12 years old and has worked with every stable Debian release in
that time. The old Buster kernel, 4.19.0-17-amd64, running with Bullseye
reports:

[   10.604259] r8169 :02:00.0: can't disable ASPM; OS doesn't have ASPM 
control
[   10.616071] libphy: r8169: probed
[   10.616222] r8169 :02:00.0 eth0: RTL8168d/8111d, 00:24:1d:1e:99:33, XID 
281000c0, IRQ 25
[   10.616223] r8169 :02:00.0 eth0: jumbo features [frames: 9200 bytes, tx 
checksumming: ko]
[   10.616921] r8169 :03:00.0: can't disable ASPM; OS doesn't have ASPM 
control
[   10.619251] libphy: r8169: probed
[   10.619384] r8169 :03:00.0 eth1: RTL8168d/8111d, 00:24:1d:1e:99:31, XID 
281000c0, IRQ 26
[   10.619385] r8169 :03:00.0 eth1: jumbo features [frames: 9200 bytes, tx 
checksumming: ko]
...
[   17.134036] r8169 :02:00.0: firmware: direct-loading firmware 
rtl_nic/rtl8168d-1.fw
[   17.134559] Generic PHY r8169-200:00: attached PHY driver [Generic PHY] 
(mii_bus:phy_addr=r8169-200:00, irq=IGNORE)
[   17.285430] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[   17.286173] Generic PHY r8169-300:00: attached PHY driver [Generic PHY] 
(mii_bus:phy_addr=r8169-300:00, irq=IGNORE)
[   17.437417] IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready
[   20.009162] r8169 :02:00.0 eth0: Link is Up - 100Mbps/Full - flow 
control rx/tx
[   20.009180] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

Thanks,

Roger

-- Package-specific info:
** Version:
Linux version 5.10.0-8-amd64 (debian-ker...@lists.debian.org) (gcc-10 (Debian 
10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP 
Debian 5.10.46-4 (2021-08-03)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-5.10.0-8-amd64 
root=UUID=cc5ea548-3370-40b7-b244-7fb88e5b310e ro radeon.dpm=1 quiet

** Not tainted

** Kernel log:
Unable to read kernel log; any relevant messages should be attached

** Model information
sys_vendor: Gigabyte Technology Co., Ltd.
product_name: GA-MA790FXT-UD5P
product_version: 
chassis_vendor: Gigabyte Technology Co., Ltd.
chassis_version: 
bios_vendor: Award Software International, Inc.
bios_version: F8n
board_vendor: Gigabyte Technology Co., Ltd.
board_name: GA-MA790FXT-UD5P
board_version: 

** Loaded modules:
udp_diag
tcp_diag
inet_diag
cpufreq_userspace
cpufreq_powersave
cpufreq_conservative
cpufreq_ondemand
uinput
it87
hwmon_vid
loop
msr
i2c_dev
snd_hda_codec_realtek
snd_hda_codec_generic
ledtrig_audio
ax88179_178a
usbnet
snd_hda_codec_hdmi
mii
snd_hda_intel
snd_intel_dspcfg
soundwire_intel
soundwire_generic_allocation
snd_soc_core
edac_mce_amd
snd_compress
soundwire_cadence
kvm_amd
snd_hda_codec
ccp
r8169
rng_core
snd_hda_core
kvm
firewire_ohci
firewire_core
snd_hwdep
wmi_bmof
realtek
soundwire_bus
mdio_devres
libphy
sr_mod
crc_itu_t
irqbypass
snd_pcm
snd_timer
cdrom
pcspkr
ohci_pci
ohci_hcd
ata_generic
snd
sg
ehci_pci
ehci_hcd
sp5100_tco
watchdog
pata_atiixp
usbcore
acpi_cpufreq
soundcore
button
usb_common
wmi
i2c_piix4
k10temp
ext4
crc16
mbcache
jbd2
crc32c_generic
sd_mod
t10_pi
crc_t10dif
crct10dif_generic
crct10dif_common
radeon
i2c_algo_bit
drm_kms_helper
cec
ahci
ttm
libahci
libata
drm
evdev
psmouse
scsi_mod
serio_raw

** Network interface configuration:
*** /etc/network/interfaces:

auto lo
iface lo inet loopback

allow-hotplug eth0
iface eth0 inet static
address 192.168.0.3
netmask 255.255.255.0
network 192.168.0.0
broadcast 192.168.0.255
gateway 192.168.0.2
allow-hotplug eth1
iface eth1 inet static
address 192.168.2.1
netmask 255.255.255.0

** Network status:
*** IP interfaces and addresses:
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
   valid_lft forever preferred_lft forever
inet6 ::1/128 scope host 
   valid_lft 

Bug#959949: sensord: not available in stable o testing

[Roger Lynn]

Package: sensord
Version: 1:3.4.0-3+b1
Followup-For: Bug #959949

Hi,

The last version of sensord still seems to work perfectly for logging
temperatures. Is there any other package that will do this instead?

Thanks,

Roger

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

Kernel: Linux 4.9.0-16-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/dash
Init: sysvinit (via /sbin/init)

Versions of packages sensord depends on:
ii  libc62.24-11+deb9u4
ii  librrd8  1.6.0-1+b2
ii  libsensors4  1:3.4.0-4
ii  lm-sensors   1:3.4.0-4
ii  lsb-base 9.20161125

sensord recommends no packages.

Versions of packages sensord suggests:
pn  rrdtool  

-- no debconf information

Bug#992378: /etc/apparmor.d/usr.sbin.cupsd: Prevents Let's Encrypt certificates from being used

[Roger Lynn]

Package: cups-daemon
Version: 2.3.3op2-3+deb11u1
Severity: normal
File: /etc/apparmor.d/usr.sbin.cupsd

Adding
  /etc/letsencrypt/archive/** r,
seems to fix this.

I only discovered what was causing the problem when I stumbled across
https://askubuntu.com/questions/1079957

Thanks,

Roger

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

Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages cups-daemon depends on:
ii  adduser3.118
ii  bc 1.07.1-2+b2
ii  init-system-helpers1.60
ii  libavahi-client3   0.8-5
ii  libavahi-common3   0.8-5
ii  libc6  2.31-13
ii  libcups2   2.3.3op2-3+deb11u1
ii  libdbus-1-31.12.20-2
ii  libelogind0 [libsystemd0]  246.9.1-1+debian1
ii  libgssapi-krb5-2   1.18.3-6
ii  libpam0g   1.4.0-9
ii  libpaper1  1.1.28+b1
ii  lsb-base   11.1.0
ii  procps 2:3.3.17-5
ii  ssl-cert   1.1.0+nmu1

Versions of packages cups-daemon recommends:
pn  avahi-daemon  
pn  colord
pn  cups-browsed  
pn  ipp-usb   

Versions of packages cups-daemon suggests:
ii  cups   2.3.3op2-3+deb11u1
ii  cups-bsd   2.3.3op2-3+deb11u1
ii  cups-client2.3.3op2-3+deb11u1
ii  cups-common2.3.3op2-3+deb11u1
ii  cups-filters   1.28.7-1
pn  cups-pdf   
ii  cups-ppdc  2.3.3op2-3+deb11u1
ii  cups-server-common 2.3.3op2-3+deb11u1
ii  foomatic-db-compressed-ppds [foomatic-db]  20200820-1
ii  ghostscript9.53.3~dfsg-7
ii  poppler-utils  20.09.0-3.1
pn  smbclient  
ii  udev   247.3-6

-- Configuration Files:
/etc/cups/cups-files.conf changed:
CreateSelfSignedCerts no
SystemGroup lpadmin
LogFileGroup adm
AccessLog /var/log/cups/access_log
ErrorLog /var/log/cups/error_log
PageLog /var/log/cups/page_log


-- no debconf information

Bug#987316: Fwd: Re: Bug#987316: initscripts: tmpfs has wrong size

[Roger Lynn]

Sorry, I failed to send this to the bug. Resending...

 Forwarded Message 
Subject: Re: Bug#987316: initscripts: tmpfs has wrong size
Date: Wed, 21 Apr 2021 22:11:12 +0100
From: Roger Lynn 
To: Thorsten Glaser 

On 21/04/2021 18:38, Thorsten Glaser wrote:

• add “set -x” as first and “set +x” as last line to
   /lib/init/tmpfs.sh
• perhaps also add “grep Total /proc/meminfo” in there
   for extra debugging
• reboot with serial console, so we can actually capture
   all the debug messages

I suspect one of the operations involved fails for you,
or swap is initialised later. Hrm.


Swap is apparently initialised later. There are three calls to that script 
recorded by bootlogd and on all of them SwapTotal is 0 kB. It then prints 
the lines for "Mounting local filesystems", "Activating swapfile swap, if 
any" and "Cleaning up temporary files". Do you still need the full debug output?


Regards,

Roger

Bug#987316: initscripts: tmpfs has wrong size

[Roger Lynn]

On 21/04/2021 16:56, Thorsten Glaser wrote:

To “provide no value” you have to actually do…

TMPFS_SIZE=

… in /etc/defaults/tmpfs because the commented-out value is default.

Perhaps rewording tmpfs(5) to say “If this is explicitly set to the
empty string, the kernel default…” is in order?


Thanks for the clarification. I think that reduces this bug to "Why is my 
tmpfs set to 20% of physical RAM rather than 20% of total virtual memory?" 
(And the rewording of the manual page would be nice too.)


I've now tried uncommenting the default TMPFS_SIZE line, and that makes no 
difference. An empty value does give 50% of physical RAM, as expected based 
on Thorsten's explanation.


Regards,

Roger

Bug#232584: /usr/bin/svnserve: Need an init.d script?

[Roger Lynn]

On 06/04/2021 22:34, Roger Lynn wrote:

I've written a new version of the script for Bullseye, based on Yubao Liu's
version and the template in init-d-script(5). Attached should be the
/etc/init.d/svnserve script and /etc/defaults/svnserve file. I am not an
expert on scripting, but it seems to work. It still needs Yubao Liu's
logrotate file.


And... that version didn't handle restarts properly. Here is a another 
attempt...


Regards,

Roger
#!/usr/bin/env /lib/init/init-d-script
### BEGIN INIT INFO
# Provides:  svnserve
# Required-Start:$syslog $remote_fs $local_fs $network
# Required-Stop: $syslog $remote_fs $local_fs $network
# Default-Start: 2 3 4 5
# Default-Stop:  0 1 6
# Short-Description: SVN server daemon service
# Description:   Debian init script to start the daemon
#serving Subversion repositories.
### END INIT INFO


DAEMON=/usr/bin/svnserve
LOG_FILE=/var/log/svnserve.log

START_ARGS="-c svn:svn"


do_start_prepare()
{
DAEMON_ARGS="-d -T -r $REPOS_DIR --config-file=$CONFIG_FILE 
--log-file=$LOG_FILE $SVNSERVE_OPTIONS"

if [ ! -f "$LOG_FILE" ]; then
touch $LOG_FILE
chown svn:adm $LOG_FILE
chmod 640 $LOG_FILE
fi
}


do_restart_prepare()
{
do_start_prepare
}

Bug#987316: initscripts: tmpfs has wrong size

[Roger Lynn]

Package: initscripts
Version: 2.96-6
Severity: normal
X-Debbugs-Cc: ro...@rilynn.me.uk

Hi,

I think this bug is not the same as #688412 because /etc/fstab is NOT involved
here.

As shown in the configuration files below, I have configured RAMTMP with the
default size settings.

tmpfs(5) says:
   TMPFS_SIZE
  Maximum  size  for  all tmpfs filesystems if no specific size is
  provided.  The default is 20%VM (20% of virtual memory,  includ‐
  ing  swap  space).  If no value is provided here, the kernel de‐
  fault (50% RAM) will be used.

I find this confusing, because the default in /etc/defaults/tmpfs is:
#TMPFS_SIZE=20%VM

Which is commented out, so presumably the default is for the kernel default to
be used, which should give me 50 % or 2 GB of my 4 GB of RAM:
$ free
   totalusedfree  shared  buff/cache   available
Mem: 396  264432  6665121524 3033500 3435280
Swap:8388604   19784 8368820

However my tmpfs is only 775 MB:
$ df
Filesystem 1K-blocks  Used Available Use% Mounted on
...
tmpfs 792880 0792880   0% /dev/shm
...
tmpfs 792880   856792024   1% /tmp

Which appears to be only 20 % of my physical RAM.

Have I misunderstood something or is there a bug here? This is a recent
Bullseye installation.

Thanks,

Roger


-- System Information:
Debian Release: bullseye/sid
  APT prefers testing-security
  APT policy: (500, 'testing-security'), (500, 'stable-updates'), (500, 
'testing'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-5-amd64 (SMP w/4 CPU threads)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages initscripts depends on:
ii  lsb-base  11.1.0
ii  sysv-rc   2.96-6

Versions of packages initscripts recommends:
ii  e2fsprogs  1.46.2-1
ii  psmisc 23.4-2

initscripts suggests no packages.

-- Configuration Files:
/etc/default/tmpfs changed:
RAMTMP=yes


-- no debconf information

Bug#986493: /etc/init.d/ufw: init script does not depend on nftables

[Roger Lynn]

Package: ufw
Version: 0.36-7.1
Severity: important
File: /etc/init.d/ufw
Justification: renders package unusable
X-Debbugs-Cc: ro...@rilynn.me.uk

Hi,

ufw apparently depends on nftables but the init script does not declare it.
This results in errors from ip-tables-restore when ufw starts:

Starting firewall: ufw...
iptables-restore v1.8.7 (nf_tables):
line 42: CHAIN_USER_ADD failed (No such file or directory): chain 
ufw-before-logging-input
line 42: CHAIN_USER_ADD failed (No such file or directory): chain 
ufw-before-logging-output
line 42: CHAIN_USER_ADD failed (No such file or directory): chain 
ufw-before-logging-forward
line 42: CHAIN_USER_ADD failed (No such file or directory): chain 
ufw-before-input
line 42: CHAIN_USER_ADD failed (No such file or directory): chain 
ufw-before-output
line 42: CHAIN_USER_ADD failed (No such file or directory): chain 
ufw-before-forward
line 42: CHAIN_USER_ADD failed (No such file or directory): chain 
ufw-after-input
line 42: CHAIN_USER_ADD failed (No such file or directory): chain 
ufw-after-output
line 42: CHAIN_USER_ADD failed (No such file or directory): chain 
ufw-after-forward
line 42: CHAIN_USER_ADD failed (No such file or directory): chain 
ufw-after-logging-input
line 42: CHAIN_USER_ADD failed (No such file or directory): chain 
ufw-after-logging-output
line 42: RULE_APPEND faied (No such file or directory): rule in
iptables-restore: line 3 failed
iptables-restore: line 3 failed
iptables-restore: line 4 failed
failed.
startpar: service(s) returned failre:ufw ... failed!


Adding "nftables" to the Required-Start: and Required-Stop: lines in 
/etc/init.d/ufw resolves the problem:

# Required-Start:$local_fs nftables
# Required-Stop: $local_fs nftables


Thanks,

Roger




-- System Information:
Debian Release: bullseye/sid
  APT prefers testing-security
  APT policy: (500, 'testing-security'), (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-5-amd64 (SMP w/4 CPU threads)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages ufw depends on:
ii  debconf [debconf-2.0]  1.5.75
ii  iptables   1.8.7-1
ii  lsb-base   11.1.0
ii  python33.9.2-2
ii  ucf3.0043

ufw recommends no packages.

Versions of packages ufw suggests:
ii  rsyslog  8.2102.0-2

-- Configuration Files:
/etc/default/ufw changed:
IPV6=yes
DEFAULT_INPUT_POLICY="REJECT"
DEFAULT_OUTPUT_POLICY="ACCEPT"
DEFAULT_FORWARD_POLICY="REJECT"
DEFAULT_APPLICATION_POLICY="SKIP"
MANAGE_BUILTINS=no
IPT_SYSCTL=
IPT_MODULES=""

/etc/init.d/ufw changed:
set -e
PATH="/sbin:/bin"
[ -d /lib/ufw ] || exit 0
. /lib/lsb/init-functions
for s in "/lib/ufw/ufw-init-functions" "/etc/ufw/ufw.conf" "/etc/default/ufw" ; 
do
if [ -s "$s" ]; then
. "$s"
else
log_failure_msg "Could not find $s (aborting)"
exit 1
fi
done
error=0
case "$1" in
start)
if [ "$ENABLED" = "yes" ] || [ "$ENABLED" = "YES" ]; then
log_action_begin_msg "Starting firewall:" "ufw"
output=`ufw_start` || error="$?"
if [ "$error" = "0" ]; then
log_action_cont_msg "Setting kernel variables ($IPT_SYSCTL)"
fi
if [ ! -z "$output" ]; then
echo "$output" | while read line ; do
log_action_cont_msg "$line"
done
fi
else
log_action_begin_msg "Skip starting firewall:" "ufw (not enabled)"
fi
log_action_end_msg $error
exit $error
;;
stop)
if [ "$ENABLED" = "yes" ] || [ "$ENABLED" = "YES" ]; then
log_action_begin_msg "Stopping firewall:" "ufw"
output=`ufw_stop` || error="$?"
if [ ! -z "$output" ]; then
log_action_cont_msg "$output"
fi
else
log_action_begin_msg "Skip stopping firewall:" "ufw (not enabled)"
fi
log_action_end_msg $error
exit $error
;;
restart|force-reload)
log_action_begin_msg "Reloading firewall:" "ufw"
output=`ufw_reload` || error="$?"
if [ ! -z "$output" ]; then
log_action_cont_msg "$output"
fi
log_action_end_msg $error
exit $error
;;
status)
output=`ufw_status` || error="$?"
if [ ! -z "$output" ]; then
log_action_cont_msg "$output"
fi
log_action_end_msg $error
exit $error
;;
*)
echo "Usage: /etc/init.d/ufw {start|stop|restart|force-reload|status}"
exit 1
;;
esac
exit 0


-- debconf information:
* ufw/enable: true
* ufw/allow_known_ports: SSH
  ufw/allow_custom_ports:
* ufw/existing_configuration:

Bug#232584: /usr/bin/svnserve: Need an init.d script?

[Roger Lynn]

Package: subversion
Version: 1.14.1-3
Followup-For: Bug #232584
X-Debbugs-Cc: ro...@rilynn.me.uk

I've written a new version of the script for Bullseye, based on Yubao Liu's 
version and the template in init-d-script(5). Attached should be the 
/etc/init.d/svnserve script and /etc/defaults/svnserve file. I am not an 
expert on scripting, but it seems to work. It still needs Yubao Liu's 
logrotate file.


-- System Information:
Debian Release: bullseye/sid
  APT prefers testing-security
  APT policy: (500, 'testing-security'), (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-5-amd64 (SMP w/4 CPU threads)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages subversion depends on:
ii  libapr1  1.7.0-6
ii  libaprutil1  1.6.1-5
ii  libc62.31-11
ii  libsvn1  1.14.1-3

subversion recommends no packages.

Versions of packages subversion suggests:
ii  db5.3-util  5.3.28+dfsg1-0.8
pn  libapache2-mod-svn  
ii  patch   2.7.6-7
ii  subversion-tools1.14.1-3

-- no debconf information
#!/usr/bin/env /lib/init/init-d-script
### BEGIN INIT INFO
# Provides:  svnserve
# Required-Start:$syslog $remote_fs $local_fs $network
# Required-Stop: $syslog $remote_fs $local_fs $network
# Default-Start: 2 3 4 5
# Default-Stop:  0 1 6
# Short-Description: SVN server daemon service
# Description:   Debian init script to start the daemon
#serving Subversion repositories.
### END INIT INFO

DAEMON=/usr/bin/svnserve
LOG_FILE=/var/log/svnserve.log

START_ARGS="-c svn:svn"

do_start_prepare()
{
DAEMON_ARGS="-d -T -r $REPOS_DIR --config-file=$CONFIG_FILE 
--log-file=$LOG_FILE $SVNSERVE_OPTIONS"

if [ ! -f "$LOG_FILE" ]; then
touch $LOG_FILE
chown svn:adm $LOG_FILE
chmod 640 $LOG_FILE
fi
}
REPOS_DIR=/srv/svn/repositories
CONFIG_FILE=/srv/svn/svnserve.conf

SVNSERVE_OPTIONS=""

Bug#986482: /usr/bin/svnserve: Need an init.d script?

[Roger Lynn]

Package: subversion
Version: 1.14.1-3
Followup-For: Bug #232584

I've written a new version of the script for Bullseye, based on Yubao Liu's
version and the template in init-d-script(5). Attached should be the init
script and defaults file. I am not an expert on scripting, but it seems to
work.

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing-security
  APT policy: (500, 'testing-security'), (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-5-amd64 (SMP w/4 CPU threads)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages subversion depends on:
ii  libapr1  1.7.0-6
ii  libaprutil1  1.6.1-5
ii  libc62.31-11
ii  libsvn1  1.14.1-3

subversion recommends no packages.

Versions of packages subversion suggests:
ii  db5.3-util  5.3.28+dfsg1-0.8
pn  libapache2-mod-svn  
ii  patch   2.7.6-7
ii  subversion-tools1.14.1-3

-- no debconf information
#!/usr/bin/env /lib/init/init-d-script
### BEGIN INIT INFO
# Provides:  svnserve
# Required-Start:$syslog $remote_fs $local_fs $network
# Required-Stop: $syslog $remote_fs $local_fs $network
# Default-Start: 2 3 4 5
# Default-Stop:  0 1 6
# Short-Description: SVN server daemon service
# Description:   Debian init script to start the daemon
#serving Subversion repositories.
### END INIT INFO

DAEMON=/usr/bin/svnserve
LOG_FILE=/var/log/svnserve.log

START_ARGS="-c svn:svn"

do_start_prepare()
{
DAEMON_ARGS="-d -T -r $REPOS_DIR --config-file=$CONFIG_FILE 
--log-file=$LOG_FILE $SVNSERVE_OPTIONS"

if [ ! -f "$LOG_FILE" ]; then
touch $LOG_FILE
chown svn:adm $LOG_FILE
chmod 640 $LOG_FILE
fi
}
REPOS_DIR=/srv/svn/repositories
CONFIG_FILE=/srv/svn/svnserve.conf

SVNSERVE_OPTIONS=""

Bug#691407: closed by Christian Göttsche (Re: logrotate(8) does not mention all reasons for ignoring included files)

[Roger Lynn]

On 10/09/2019 17:05, Christian Göttsche wrote:

To better document this in the man page, I created
https://github.com/logrotate/logrotate/pull/265


Thank you. Also must not be group writeable. This is what caught me out 
(making the file group writeable in the first place was an accident).


Roger

Bug#691407: closed by Christian Göttsche (Re: logrotate(8) does not mention all reasons for ignoring included files)

[Roger Lynn]

On 08/09/19 16:48, Debian Bug Tracking System wrote:

This is an automatic notification regarding your Bug report
which was filed against the logrotate package:

#691407: logrotate(8) does not mention all reasons for ignoring included files

It has been closed by Christian Göttsche .

Their explanation is attached below along with your original report.
If this explanation is unsatisfactory and you have not received a
better one in a separate message then please contact Christian Göttsche 
 by
replying to this email.


Subject:
Re: logrotate(8) does not mention all reasons for ignoring included files
From:
Christian Göttsche 
Date:
08/09/19 17:45 +0200
To:
691407-d...@bugs.debian.org

To:
691407-d...@bugs.debian.org


Closing due to no response.


No response due to not being copied on the email in question!


In the BTS, I see that on Wed, 22 Aug 2018 22:54:02 +0200, Christian 
Göttsche  apparently wrote:

Control: tags -1 moreinfo unreproducible

Hi,
by


some unspecified "bad" file modes, which include being group writeable.


do you mean configuration files or log files?
In my tests logrotate does rotate logs which are group writeable and
errors out when a configuration file has insecure permissions.


I don't remember filing this bug seven years ago, but the section of the man 
page quoted in the original report was clearly referring to configuration 
files. You have reproduced the error, which was a result of a requirement 
which I could not find in the the man page. If this bug is unreproducible, 
does that mean you were able to find where in the man page this is documented?


Having left cron to run overnight with an erroneous logrotate.d file I see 
that an error is now reported without needing to resort to adding "-v" to 
various scripts:
"error: Ignoring vsftpd because of bad file mode - must be 0644 or 0444." 
and it now states what the file mode requirements are, which it did not 
before. As a result it would probably be reasonable to downgrade this bug to 
minor severity.


Previously no error was reported when the script was run by cron, when "-v" 
was added to logrotate the error message given did not state what was wrong 
with the file mode and this requirement is not mentioned in the man page. 
This made it difficult to work out why logrotate was not working.


Regards,

Roger

Bug#918824: distributed-net: logorate scipt attempts to call unimplemented "reload" target in /etc/init.d/distributed-net

[Roger Lynn]

Package: distributed-net
Version: 2.9112.521-1
Severity: normal

Hi,

Every week, distributed-net causes the following email to be sent:

/etc/cron.daily/logrotate:
/etc/init.d/distributed-net: 165: /etc/init.d/distributed-net: 3: Bad file 
descriptor
invoke-rc.d: initscript distributed-net, action "reload" failed.
error: error running non-shared postrotate script for 
/var/log/distributed-net.log of '/var/log/distributed-net.log '
run-parts: /etc/cron.daily/logrotate exited with return code 1


There are a couple of reasons for this.

The first is that /etc/logrotate.d/distributed-net contains the line 
"invoke-rc.d distributed-net reload >/dev/null", but "reload" is not 
implemented in /etc/init.d/distributed-net, despite that script's usage 
message claiming that it is.

The other reason is that when called with an unrecognised parameter, 
/etc/logrotate.d/distributed-net attempts to run line 165:
"echo "Usage: $SCRIPTNAME 
{start|stop|status|restart|reload|force-reload|fetch|flush|update}" >&3",
but file descriptor 3 does not exist. I presume that it's trying to redirect 
to stderr and that the >&3 should be >&2. Also the string claims that "reload" 
is a valid parameter, which it isn't.

Thanks,

Roger


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

Kernel: Linux 4.9.0-8-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages distributed-net depends on:
ii  bind9-host [host]  1:9.10.3.dfsg.P4-12.3+deb9u4
ii  debconf [debconf-2.0]  1.5.61
ii  libc6  2.24-11+deb9u3

Versions of packages distributed-net recommends:
ii  logrotate  3.11.0-0.1

Versions of packages distributed-net suggests:
ii  acpid  1:2.0.28-1+b1
pn  apmd   

-- debconf information:
* distributed-net/fullconfig: false

Bug#712564: spamassassin: Add feature to run spamassassin as debian-spamd user

[Roger Lynn]

On 14/12/2018 12:35, Christian Weiske wrote:

When spamassassin is running in daemon mode (spamd) as root,
the default behaviour is to setuid to the user running spamc. This
lets spamd to load and examine the per-user configuration files as
the user. So by default, the effective UID is sent to spamd from
spamc.


This is only necessary when you have a 1:1 mapping between email
recipients and users on the system, and not at all useful when there is
a virtual user setup via database or MySQL.

Even if you are in a non-virtual setup, the question is if users really
use their own configuration files for spamassassin, or if they rather
rely on the admin to configure SA correctly.


This. exim connects to spamd at SMTP time, when there might be several local 
recipients, so there is no single local user to run spamd as. And I don't 
expect each of my users to set up their own spamassassin configuration.



If the main usage scenario of spamassassin on debian installations is
virtual user databases, then the default could be changed to let spamd
run the children as debian-spamd.



I adjusted /etc/default/spamassassin and ajusted OPTIONS:

OPTIONS="--username=debian-spamd --group debian-spamd ..."


I have always added "-u debian-spamd" to all my spamassassin installations, 
and now I'm wondering if I need to add --group too, but it appears to be 
unnecessary.


Regards,

Roger

Bug#880047: postgrey: Regression - Postgrey doesn't start after installing new stable proposed-update

[Roger Lynn]

On 08/11/18 19:34, Adrian Bunk wrote:

Tanks a lot for trying stretch-proposed-updates and reproting bugs you find!

This is a regression that is also in 1.36-5 in unstable.

The proposed 1.36-3+deb9u1 update has now been dropped from the upcoming
stretch point release.


Thank you for your work on this package. I think the reason my system was 
badly affected by the new release is because I had used the example unix 
socket location given in /usr/share/doc/postgrey/README.exim, which 
conflicted with the new directory created in the init script (although to be 
fair, the README does warn that the socket location might need to be changed).


Regards,

Roger

Bug#880047: postgrey: Regression - Postgrey doesn't start after installing new stable proposed-update

[Roger Lynn]

Package: postgrey
Version: 1.36-3+deb9u1
Followup-For: Bug #880047

On a Stable system installed about a year ago, Postgrey 1.36-3 has always run
fine. When installing 1.36-3+deb9u1 I get:

Setting up postgrey (1.36-3+deb9u1) ...
Installing new version of config file /etc/init.d/postgrey ...
[] Starting postfix greylisting daemon: postgreymkdir: cannot create 
directory ‘/var/run/postgrey/’: File exists
invoke-rc.d: initscript postgrey, action "start" failed.

# /etc/init.d/postgrey stop
[] Stopping postfix greylisting daemon: postgreystart-stop-daemon: unable 
to open pidfile /var/run/postgrey/postgrey.pid (Not a directory)

# /etc/init.d/postgrey start
[] Starting postfix greylisting daemon: postgreymkdir: cannot create 
directory ‘/var/run/postgrey/’: File exists

$ ls -al /var/run/postgrey 
srw-rw-rw- 1 postgrey postgrey 0 Oct 27 23:14 /var/run/postgrey

After deleting /var/run/postgrey Postgrey will start, although subsequent
restarts give:

# /etc/init.d/postgrey start
[] Starting postfix greylisting daemon: postgreyPid_file 
"/var/run/postgrey/postgrey.pid" already exists.  Overwriting!
. ok 

Thanks,

Roger

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

Kernel: Linux 4.9.0-8-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages postgrey depends on:
ii  adduser3.115
ii  debconf [debconf-2.0]  1.5.61
ii  libberkeleydb-perl 0.55-1+b2
ii  libnet-dns-perl1.07-1
ii  libnet-server-perl 2.008-3
ii  libnetaddr-ip-perl 4.079+dfsg-1+b1
ii  perl   5.24.1-3+deb9u4
ii  ucf3.0036

Versions of packages postgrey recommends:
ii  exim4  4.89-2+deb9u3
ii  libnet-rblclient-perl  0.5-3
ii  libparse-syslog-perl   1.10-2

postgrey suggests no packages.

-- debconf information:
  postgrey/1.32-3_changeport:

Bug#848690: related

[Roger Lynn]

On 20/04/18 18:46, Herman van Rink wrote:
> This seems to be hitting more users...
> 
> https://github.com/monitoring-plugins/monitoring-plugins/issues/1142
> 
> https://github.com/nagios-plugins/nagios-plugins/issues/329
> 
> https://bugs.launchpad.net/ubuntu/+source/nagios-plugins/+bug/1367791
> 
> 
> The addition of 'discard minimum 1' to ntp.conf ad Stuart suggests
> resolves this.

If the original report is accurate, the bug is in the Nagios plugin, so this
bug is against the wrong package.

Roger

Bug#892788: e2guardian: Please enable MITM Filtering HTTPS

[Roger Lynn]

Package: e2guardian
Version: 3.4.0.3-2
Severity: wishlist

Hi,

Please configure and compile e2guardian with the --enable-sslmitm=yes flag set.
Without this a content filter is not very useful on the modern internet.

Thanks,

Roger

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

Kernel: Linux 4.9.0-5-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages e2guardian depends on:
ii  adduser 3.115
ii  clamav  0.99.4+dfsg-1+deb9u1
ii  libc6   2.24-11+deb9u3
ii  libgcc1 1:6.3.0-18+deb9u1
ii  libpcre32:8.39-3
ii  libstdc++6  6.3.0-18+deb9u1
ii  perl5.24.1-3+deb9u2
ii  zlib1g  1:1.2.8.dfsg-5

e2guardian recommends no packages.

Versions of packages e2guardian suggests:
ii  clamav-freshclam  0.99.4+dfsg-1+deb9u1
ii  squid 3.5.23-5+deb9u1

-- Configuration Files:
/etc/e2guardian/e2guardian.conf changed:
languagedir = '/usr/share/e2guardian/languages'
language = 'ukenglish'
loglevel = 2
logexceptionhits = 2
logfileformat = 1
dstatlocation = '/var/log/e2guardian/dstats.log'
filterip = 192.168.0.2
filterports = 8080
proxyip = 127.0.0.1
proxyport = 3128
proxytimeout = 20
proxyexchange = 20
pcontimeout = 55
usecustombannedimage = on
custombannedimagefile = '/usr/share/e2guardian/transparent1x1.gif'
usecustombannedflash = on
custombannedflashfile = '/usr/share/e2guardian/blockedflash.swf'
filtergroups = 1
filtergroupslist = '/etc/e2guardian/lists/filtergroupslist'
bannediplist = '/etc/e2guardian/lists/bannediplist'
exceptioniplist = '/etc/e2guardian/lists/exceptioniplist'
showweightedfound = on
urlcachenumber = 1000
urlcacheage = 900
scancleancache = on
phrasefiltermode = 2
preservecase = 0
hexdecodecontent = off
forcequicksearch = off
reverseaddresslookups = on
reverseclientiplookups = on
logclienthostnames = on
prefercachedlists = off
maxcontentfiltersize = 1024
maxcontentramcachescansize = 16384
maxcontentfilecachescansize = 65536
filecachedir = '/tmp'
deletedownloadedtempfiles = on
initialtrickledelay = 20
trickledelay = 10
downloadmanager = '/etc/e2guardian/downloadmanagers/fancy.conf'
downloadmanager = '/etc/e2guardian/downloadmanagers/default.conf'
contentscanner = '/etc/e2guardian/contentscanners/clamdscan.conf'
contentscannertimeout = 60
contentscanexceptions = off
recheckreplacedurls = off
forwardedfor = off
usexforwardedfor = off
logconnectionhandlingerrors = on
logsslerrors = off
logchildprocesshandling = off
maxchildren = 180
minchildren = 20
minsparechildren = 16
preforkchildren = 10
maxsparechildren = 32
maxagechildren = 500
maxips = 0
ipcfilename = '/tmp/.e2guardianipc'
urlipcfilename = '/tmp/.e2guardianurlipc'
ipipcfilename = '/tmp/.e2guardianipipc'
nodaemon = off
nologger = off
logadblocks = off
loguseragent = off
softrestart = off
mailer = '/usr/sbin/sendmail -t'
cacertificatepath = '/etc/e2guardian/ssl/my_rootCA.crt'
caprivatekeypath = '/etc/e2guardian/ssl/private_root.pem'
certprivatekeypath = '/etc/e2guardian/ssl/private_cert.pem'
generatedcertpath = '/var/log/e2guardian/generatedcerts/'

/etc/e2guardian/e2guardianf1.conf changed:
groupmode = 1
groupname = ''
bannedphraselist = '/etc/e2guardian/lists/bannedphraselist'
weightedphraselist = '/etc/e2guardian/lists/weightedphraselist'
exceptionphraselist = '/etc/e2guardian/lists/exceptionphraselist'
bannedsitelist = '/etc/e2guardian/lists/bannedsitelist'
greysitelist = '/etc/e2guardian/lists/greysitelist'
bannedsslsitelist = '/etc/e2guardian/lists/bannedsslsitelist'
greysslsitelist = '/etc/e2guardian/lists/greysslsitelist'
exceptionsitelist = '/etc/e2guardian/lists/exceptionsitelist'
bannedurllist = '/etc/e2guardian/lists/bannedurllist'
greyurllist = '/etc/e2guardian/lists/greyurllist'
exceptionurllist = '/etc/e2guardian/lists/exceptionurllist'
exceptionregexpurllist = '/etc/e2guardian/lists/exceptionregexpurllist'
bannedregexpurllist = '/etc/e2guardian/lists/bannedregexpurllist'
picsfile = '/etc/e2guardian/lists/pics'
contentregexplist = '/etc/e2guardian/lists/contentregexplist'
urlregexplist = '/etc/e2guardian/lists/urlregexplist'
refererexceptionsitelist = '/etc/e2guardian/lists/refererexceptionsitelist'
refererexceptionurllist = '/etc/e2guardian/lists/refererexceptionurllist'
embededreferersitelist = '/etc/e2guardian/lists/embededreferersitelist'
embededrefererurllist = '/etc/e2guardian/lists/embededrefererurllist'
urlredirectregexplist = '/etc/e2guardian/lists/urlredirectregexplist'
!! Not compiled !! authexceptionsitelist = 
'/etc/e2guardian/lists/authexceptionsitelist'
!! Not compiled !! authexceptionurllist = 
'/etc/e2guardian/lists/authexceptionurllist'
blockdownloads = off
exceptionextensionlist = '/etc/e2guardian/lists/exceptionextensionlist'
exceptionmimetypelist = 

Bug#889487: linux-image-4.14.0-2-amd64: please enable CONFIG_X86_MCELOG_LEGACY

[Roger Lynn]

On 04/02/18 02:00, Jon DeVree wrote:
> On Sun, Feb 04, 2018 at 01:03:59 +0100, Ben Hutchings wrote:
>> This was unintentional, but I think it's correct.  The Kconfig says to
>> use rasdaemon which is already packaged and in stable.
> 
> rasdaemon has a hard dependency on systemd, it isn't installable on
> machines still running sysvinit.

Yes it is installable. It depends on systemd, not systemd-sysv. systemd is
co-installable with sysvinit-core. I have it installed on a Stretch sysvinit
system (it then complains that it can't find a debugfs).

> Not sure if thats a hard dep or if it only just means rasdaemon is
> missing a sysvinit script.

Roger

Bug#879462: plasma-desktop: xterm bell opens KDE Accessibility Tool confirmation dialog

[Roger Lynn]

Package: plasma-desktop
Version: 4:5.8.6-1
Severity: normal

Hi,

Since upgrading from Jessie to Stretch, a bell in an xterm (commonly generated 
by tab completion or pressing ^G) always opens "Warning - KDE Accessibility 
Tool", which asks 'Do you really want to activate "Sticky keys" and "Mouse 
Keys"?'

Selecting "Deactivate All AccessX Features & Gestures" and choosing "No" does
not stop the dialog appearing again.

In "Accessibility - System Settings", "Activation Gestures" tab, "Use gestures
for activating sticky keys and slow keys" is turned off.

This is also mentioned at 
https://unix.stackexchange.com/questions/246305/tab-in-xterm-under-kde-always-brings-up-accessibility-tool-dialog

Thanks,

Roger


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

Kernel: Linux 4.9.0-4-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/dash
Init: sysvinit (via /sbin/init)

Versions of packages plasma-desktop depends on:
ii  breeze   4:5.8.5-2
ii  kactivitymanagerd5.8.4-1
ii  kde-cli-tools4:5.8.4-2
ii  kded55.28.0-1
ii  kio  5.28.0-2
ii  libc62.24-11+deb9u1
ii  libcanberra0 0.30-3
ii  libfontconfig1   2.11.0-6.7+b1
ii  libgcc1  1:6.3.0-18
ii  libkf5activities55.28.0-1
ii  libkf5activitiesstats1   5.28.0-1
ii  libkf5archive5   5.28.0-2
ii  libkf5auth5  5.28.0-2
ii  libkf5baloo5 5.28.0-2
ii  libkf5bookmarks5 5.28.0-1
ii  libkf5codecs55.28.0-1+b2
ii  libkf5completion55.28.0-1
ii  libkf5configcore55.28.0-2
ii  libkf5configgui5 5.28.0-2
ii  libkf5configwidgets5 5.28.0-2
ii  libkf5coreaddons55.28.0-2
ii  libkf5dbusaddons55.28.0-1
ii  libkf5emoticons-bin  5.28.0-1
ii  libkf5emoticons5 5.28.0-1
ii  libkf5globalaccel5   5.28.0-1
ii  libkf5guiaddons5 5.28.0-1
ii  libkf5i18n5  5.28.0-2
ii  libkf5iconthemes55.28.0-2
ii  libkf5itemmodels55.28.0-2
ii  libkf5itemviews5 5.28.0-1
ii  libkf5jobwidgets55.28.0-2
ii  libkf5kcmutils5  5.28.0-2
ii  libkf5kdelibs4support5   5.28.0-1
ii  libkf5kiocore5   5.28.0-2
ii  libkf5kiofilewidgets55.28.0-2
ii  libkf5kiowidgets55.28.0-2
ii  libkf5newstuff5  5.28.0-1
ii  libkf5notifications5 5.28.0-1
ii  libkf5notifyconfig5  5.28.0-1
ii  libkf5parts5 5.28.0-1
ii  libkf5people55.28.0-1
ii  libkf5peoplewidgets5 5.28.0-1
ii  libkf5plasma55.28.0-2
ii  libkf5plasmaquick5   5.28.0-2
ii  libkf5quickaddons5   5.28.0-1
ii  libkf5runner55.28.0-1
ii  libkf5service-bin5.28.0-1
ii  libkf5service5   5.28.0-1
ii  libkf5solid5 5.28.0-3
ii  libkf5sonnetui5  5.28.0-2
ii  libkf5wallet-bin 5.28.0-3
ii  libkf5wallet55.28.0-3
ii  libkf5widgetsaddons5 5.28.0-3
ii  libkf5windowsystem5  5.28.0-2
ii  libkf5xmlgui55.28.0-1
ii  libkfontinst54:5.8.6-1
ii  libkfontinstui5  4:5.8.6-1
ii  libkworkspace5-5 4:5.8.6-2.1
ii  libpackagekitqt5-0   0.9.6-1
ii  libphonon4qt5-4  4:4.9.0-4
ii  libpulse-mainloop-glib0  10.0-1+deb9u1
ii  libpulse010.0-1+deb9u1
ii  libqt5concurrent55.7.1+dfsg-3+b1
ii  libqt5core5a 5.7.1+dfsg-3+b1
ii  libqt5dbus5  5.7.1+dfsg-3+b1
ii  libqt5gui5   5.7.1+dfsg-3+b1
ii  libqt5network5   5.7.1+dfsg-3+b1
ii  libqt5printsupport5  5.7.1+dfsg-3+b1
ii  libqt5qml5   5.7.1-2+b2
ii  libqt5quick5  

Bug#878569: spamassassin: Can't set TxRep directory for site wide use

[Roger Lynn]

On 18/10/17 21:02, Roger Lynn wrote:
> I've found https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7383 which
> contains a very small patch which apparently fixes the bug. Without this the
> TxRep plugin is unusable.

Applying the attached patch appears to have fixed this issue. I have now run
into https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7164 which means I
get two perl warnings for every message I receive.

Roger
--- spamassassin-3.4.1.orig/lib/Mail/SpamAssassin/Plugin/TxRep.pm
+++ spamassassin-3.4.1/lib/Mail/SpamAssassin/Plugin/TxRep.pm
@@ -932,7 +932,7 @@ across all users.
 my ($self, $key, $value, $line) = @_;
 unless (defined $value && $value !~ /^$/) {return 
$Mail::SpamAssassin::Conf::MISSING_REQUIRED_VALUE;}
 if (-d $value){return 
$Mail::SpamAssassin::Conf::INVALID_VALUE; }
-$self->{txrep_path} = $value;
+$self->{auto_whitelist_path} = $value;
 }
   });

Bug#878569: spamassassin: Can't set TxRep directory for site wide use

[Roger Lynn]

I've found https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7383 which
contains a very small patch which apparently fixes the bug. Without this the
TxRep plugin is unusable.

Thanks,

Roger

Bug#851096: [pkg-ntp-maintainers] Bug#851096: update-leap tries to fetch https:// using a module without HTTPS support

[Roger Lynn]

On 01/04/17 00:11, Kurt Roeckx wrote:
> You should probably use the file from tzdata instead:
> /usr/share/zoneinfo/leap-seconds.list

Thank you for pointing this out. Is there any reason why the NTP package
shouldn't use it by default?

Roger

Bug#760415: cups: Need to "reset" the printer between 2 jobs (very similar to STR #3964)"

[Roger Lynn]

Package: cups
Version: 2.2.1-8
Followup-For: Bug #760415

Hi,

Unfortunately I still encounter this bug with a fresh installation of Stretch: 
if I don't power cycle my Lexmark E232 between jobs I get hundreds of pages of 
raw PCL when I try to print a second document.

Regards,

Roger

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

Kernel: Linux 4.9.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages cups depends on:
ii  cups-client2.2.1-8
ii  cups-common2.2.1-8
ii  cups-core-drivers  2.2.1-8
ii  cups-daemon2.2.1-8
ii  cups-filters   1.11.6-3
ii  cups-ppdc  2.2.1-8
ii  cups-server-common 2.2.1-8
ii  debconf [debconf-2.0]  1.5.61
ii  ghostscript9.20~dfsg-3.2+deb9u1
ii  libavahi-client3   0.6.32-2
ii  libavahi-common3   0.6.32-2
ii  libc-bin   2.24-11+deb9u1
ii  libc6  2.24-11+deb9u1
ii  libcups2   2.2.1-8
ii  libcupscgi12.2.1-8
ii  libcupsimage2  2.2.1-8
ii  libcupsmime1   2.2.1-8
ii  libcupsppdc1   2.2.1-8
ii  libgcc11:6.3.0-18
ii  libstdc++6 6.3.0-18
ii  libusb-1.0-0   2:1.0.21-1
ii  poppler-utils  0.48.0-2
ii  procps 2:3.3.12-3

Versions of packages cups recommends:
pn  avahi-daemon 
pn  colord   
ii  cups-filters [ghostscript-cups]  1.11.6-3
ii  printer-driver-gutenprint5.2.11-1+b2

Versions of packages cups suggests:
pn  cups-bsd   
pn  cups-pdf   
ii  foomatic-db-compressed-ppds [foomatic-db]  20161201-1
pn  hplip  
pn  printer-driver-hpcups  
pn  smbclient  
ii  udev   232-25+deb9u1

-- debconf information:
* cupsys/raw-print: false
* cupsys/backend: usb

Bug#878569: spamassassin: Can't set TxRep directory for site wide use

[Roger Lynn]

Package: spamassassin
Version: 3.4.1-6
Severity: normal

Hi,

I have a site wide installation of Spamassassin, running as user debian-spamd.
Pyzor and Razor correctly use debian-spamd's home directory, but Bayes and 
TxRep do not. Fortunately Bayes respects the "bayes_path" option.

According to http://truxoft.com/resources/txrep.htm (linked from 
https://wiki.apache.org/spamassassin/TxRep ) the "auto_whitelist_path" option 
should set the TxRep directory. However, having set it to 
"/var/lib/spamassassin/.spamassassin/tx-reputation", which is what the 
documentaion says the default should be, spamd logs:

rules: failed to run TXREP test, skipping:
(locker: [...] safe_lock: cannot create lockfile 
/nonexistent/.spamassassin/tx-reputation.mutex: No such file or directory )

"/nonexistent/" is also the directory Bayes uses by default.

I guessed that perhaps the option should be "txrep_path", but that just 
resulted in:

config: failed to parse line, skipping, in "/etc/spamassassin/local.cf": 
txrep_path /var/lib/spamassassin/.spamassassin/tx-reputation

The "auto_whitelist_path" option did work correctly with the Auto-WhiteList 
function in Jessie.

Thanks,

Roger


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

Kernel: Linux 4.9.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages spamassassin depends on:
ii  adduser  3.115
ii  curl 7.52.1-5+deb9u1
ii  init-system-helpers  1.48
ii  libhtml-parser-perl  3.72-3
ii  libhttp-date-perl6.02-1
ii  libmail-dkim-perl0.40-1
ii  libnet-dns-perl  1.07-1
ii  libnetaddr-ip-perl   4.079+dfsg-1+b1
ii  libsocket6-perl  0.27-1+b1
ii  libsys-hostname-long-perl1.5-1
ii  lsb-base 9.20161125
ii  perl 5.24.1-3+deb9u2
ii  perl-modules-5.24 [libarchive-tar-perl]  5.24.1-3+deb9u2

Versions of packages spamassassin recommends:
ii  gnupg 2.1.18-8~deb9u1
ii  libio-socket-inet6-perl   2.72-2
ii  libmail-spf-perl  2.9.0-4
ii  libperl5.24 [libsys-syslog-perl]  5.24.1-3+deb9u2
ii  sa-compile3.4.1-6
ii  spamc 3.4.1-6+b1

Versions of packages spamassassin suggests:
ii  libdbi-perl  1.636-1+b1
ii  libencode-detect-perl1.01-4+b3
ii  libgeo-ip-perl   1.50-1+b1
ii  libio-socket-ssl-perl2.044-1
ii  libnet-patricia-perl 1.22-1+b3
ii  libperl5.24 [libcompress-zlib-perl]  5.24.1-3+deb9u2
ii  pyzor1:1.0.0-2
ii  razor1:2.85-4.2+b2

-- Configuration Files:
/etc/default/spamassassin changed:
ENABLED=1
OPTIONS="-u debian-spamd --allow-tell"
PIDFILE="/var/run/spamd.pid"
CRON=1

/etc/spamassassin/local.cf changed:
time_limit 50
use_txrep 1
auto_whitelist_path /var/lib/spamassassin/.spamassassin/tx-reputation
ok_locales en
ok_languages en
score GTUBE 4.0
score BAYES_00  0  0 (-0.5) (-0.5)
score BAYES_05  0  0 (-0.5) (-0.5)
score BAYES_80  0  0  (0.5)  (0.5)
score BAYES_95  0  0  (0.5)  (1.0)
score BAYES_99  0  0  (1.5)  (2.0)
score BAYES_999 0  0  (0.2)  (0.2)
score MICROSOFT_EXECUTABLE(1.0)
score MIME_SUSPECT_NAME   (0.5)
clear_report_template
report Host "_HOSTNAME_", requires _REQD_ points.
report _SUMMARY_
trusted_networks192.168/16
trusted_networks90.155.73.34
trusted_networks81.187.30.29
internal_networks 192.168/16 90.155.73.34
 lock_method flock
required_score 0.0
bayes_ignore_header X-Spam-Score
bayes_ignore_header X-Spam-Report
bayes_path /var/lib/spamassassin/.spamassassin/bayes
bayes_auto_learn_threshold_nonspam 0.0
bayes_auto_learn_threshold_spam 6.0
 normalize_charset 1
ifplugin Mail::SpamAssassin::Plugin::Shortcircuit
endif # Mail::SpamAssassin::Plugin::Shortcircuit

/etc/spamassassin/v310.pre changed:
loadplugin Mail::SpamAssassin::Plugin::Pyzor
loadplugin Mail::SpamAssassin::Plugin::Razor2
loadplugin Mail::SpamAssassin::Plugin::SpamCop
loadplugin Mail::SpamAssassin::Plugin::AntiVirus
loadplugin Mail::SpamAssassin::Plugin::AutoLearnThreshold
loadplugin Mail::SpamAssassin::Plugin::TextCat
loadplugin Mail::SpamAssassin::Plugin::WhiteListSubject
loadplugin Mail::SpamAssassin::Plugin::MIMEHeader
loadplugin Mail::SpamAssassin::Plugin::ReplaceTags

/etc/spamassassin/v320.pre changed:
loadplugin Mail::SpamAssassin::Plugin::Check
loadplugin Mail::SpamAssassin::Plugin::HTTPSMismatch
loadplugin 

Bug#873064: dovecot-imapd: Can't connect from older MacOSX and iOS devices to imap 993

[Roger Lynn]

On 24/08/2017 08:26, Peter Chubb wrote:
> After upgrading dovecot, MacOSX El Capitan and IOS versions below 8 can 
> no longer connect.  The error in the log is:
>  SSL_accept() failed: error:1417D18C:SSL 
> routines:tls_process_client_hello:version too low, session=...

This is due to a bug introduced in OpenSSL 1.1.0f-4, which you presumably
updated at the same time. As I am not a Debian Developer I will leave it to
someone else to reassign this bug.

> How can I reenable TLSv1 ?  The obvious
> ssl_protocols = TLSv1, TLSv1.1, TLSv1.2, !SSLv2, !SSLv4
> doesn't work for me.

I would assume that downgrading openssl and libssl1.1 to version 1.1.0f-3
(available from snapshot.debian.org) should work...

Roger

Bug#760415: cups: Need to "reset" the printer between 2 jobs (very similar to STR #3964)"

[Roger Lynn]

Package: cups
Version: 1.7.5-11+deb8u2
Followup-For: Bug #760415

I also have this problem with a Lexmark E232 with both Jessie and Wheezy. I
can't remember if it occurred in Squeeze and I haven't tried Stretch yet.
I'll try to remember to report back when I upgrade to Stretch.

Thanks,

Roger

-- System Information:
Debian Release: 8.9
  APT prefers oldstable-updates
  APT policy: (500, 'oldstable-updates'), (500, 'oldstable-proposed-updates'), 
(500, 'oldstable')
Architecture: i386 (i686)

Kernel: Linux 3.16.0-4-686-pae (SMP w/1 CPU core)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages cups depends on:
ii  cups-client1.7.5-11+deb8u2
ii  cups-common1.7.5-11+deb8u2
ii  cups-core-drivers  1.7.5-11+deb8u2
ii  cups-daemon1.7.5-11+deb8u2
ii  cups-filters   1.0.61-5+deb8u3
ii  cups-ppdc  1.7.5-11+deb8u2
ii  cups-server-common 1.7.5-11+deb8u2
ii  debconf [debconf-2.0]  1.5.56+deb8u1
ii  ghostscript9.06~dfsg-2+deb8u5
ii  libavahi-client3   0.6.31-5
ii  libavahi-common3   0.6.31-5
ii  libc-bin   2.19-18+deb8u10
ii  libc6  2.19-18+deb8u10
ii  libcups2   1.7.5-11+deb8u2
ii  libcupscgi11.7.5-11+deb8u2
ii  libcupsimage2  1.7.5-11+deb8u2
ii  libcupsmime1   1.7.5-11+deb8u2
ii  libcupsppdc1   1.7.5-11+deb8u2
ii  libgcc11:4.9.2-10
ii  libstdc++6 4.9.2-10
ii  libusb-1.0-0   2:1.0.19-1
ii  lsb-base   4.1+Debian13+nmu1
ii  poppler-utils  0.26.5-2+deb8u1
ii  procps 2:3.3.9-9

Versions of packages cups recommends:
pn  avahi-daemon 
pn  colord   
ii  cups-filters [ghostscript-cups]  1.0.61-5+deb8u3
ii  printer-driver-gutenprint5.2.10-3

Versions of packages cups suggests:
pn  cups-bsd   
pn  cups-pdf   
ii  foomatic-db-compressed-ppds [foomatic-db]  20150411-1
pn  hplip  
pn  printer-driver-hpcups  
pn  smbclient  
ii  udev   215-17+deb8u7

-- Configuration Files:
/etc/cups/cupsd.conf.default 9ffef7ab095f3f35dcd108ba52de6295 [Errno 2] No such 
file or directory: u'/etc/cups/cupsd.conf.default 
9ffef7ab095f3f35dcd108ba52de6295'
/etc/default/cups 2b436fbb1a32b82b6aba45a76a1d7e40 [Errno 2] No such file or 
directory: u'/etc/default/cups 2b436fbb1a32b82b6aba45a76a1d7e40'

-- debconf information:
* cupsys/backend: lpd, socket, usb, snmp, dnssd
* cupsys/raw-print: true

Bug#865042: sensord: Sensord package is missing in Debian Stretch

[Roger Lynn]

Package: sensord
Version: 1:3.3.5-2
Followup-For: Bug #865042

Hi,

Removing the whole package because one particular use-case has some problems
seems like a bit of an over-reaction, especially when that usage isn't even
mentioned in the package description and the required dependency is only a
suggests. Unfortunately I assume it's unlikely to be reintroduced into
Stretch and we will have to wait for Buster. :-(

Thanks,

Roger

-- System Information:
Debian Release: 8.8
  APT prefers oldstable-updates
  APT policy: (500, 'oldstable-updates'), (500, 'oldstable-proposed-updates'), 
(500, 'oldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages sensord depends on:
ii  libc62.19-18+deb8u10
ii  librrd4  1.4.8-1.2
ii  libsensors4  1:3.3.5-2
ii  lm-sensors   1:3.3.5-2
ii  lsb-base 4.1+Debian13+nmu1

sensord recommends no packages.

Versions of packages sensord suggests:
pn  rrdtool  

-- Configuration Files:
/etc/logcheck/ignore.d.workstation/sensord [Errno 13] Permission denied: 
u'/etc/logcheck/ignore.d.workstation/sensord'

-- no debconf information

Bug#851620: partman-md: doesn't warn about not being able to embed in the end

[Roger Lynn]

On 16/01/17 22:00, Samuel Thibault wrote:
> partman-md doesn't warn when disks to be used for RAID are partitioned
> with GPT without a bios boot partition for embedding (and I haven't seen
> documentation about the issue in the installer manual).

Is this the same problem that was reported in installation-report bug
#768624 "grub core.img won't fit in the embedding area which is required for
LVM"?

Roger

Bug#820983: /usr/share/doc/samba/NEWS.Debian.gz: "smb signing" is an "unknown parameter"

[Roger Lynn]

Package: samba
Version: 2:4.2.10+dfsg-0+deb8u1
Severity: normal
File: /usr/share/doc/samba/NEWS.Debian.gz

Hi,

The NEWS file states:

Finally, two important configuration options should be considered,
that we were unable to silently change defaults for:
- smb signing = required
- ntlm auth = no

However smb signing is not a recognised parameter:

.../lib/param/loadparm.c:743(lpcfg_map_parameter)
  Unknown parameter encountered: "smb signing"

Searching through SMB.CONF(5), it appears the intended parameter is:

client signing = mandatory

Is this correct? According to the NEWS file this option has security
implications, so should be considered important.

Thanks,

Roger


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

Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages samba depends on:
ii  adduser  3.113+nmu3
ii  dpkg 1.17.26
ii  libacl1  2.2.52-2
ii  libattr1 1:2.4.47-2
ii  libbsd0  0.7.0-2
ii  libc62.19-18+deb8u4
ii  libcups2 1.7.5-11+deb8u1
ii  libhdb9-heimdal [heimdal-hdb-api-8]  1.6~rc2+dfsg-9
ii  libldap-2.4-22.4.40+dfsg-1+deb8u2
ii  libldb1  2:1.1.20-0+deb8u1
ii  libpam-modules   1.1.8-3.1+deb8u1+b1
ii  libpam-runtime   1.1.8-3.1+deb8u1
ii  libpopt0 1.16-10
ii  libpython2.7 2.7.9-2
ii  libtalloc2   2.1.2-0+deb8u1
ii  libtdb1  1.3.6-0+deb8u1
ii  libtevent0   0.9.25-0+deb8u1
ii  libwbclient0 2:4.2.10+dfsg-0+deb8u1
ii  lsb-base 4.1+Debian13+nmu1
ii  multiarch-support2.19-18+deb8u4
ii  procps   2:3.3.9-9
ii  python   2.7.9-1
ii  python-dnspython 1.12.0-1
ii  python-ntdb  1.0-5
ii  python-samba 2:4.2.10+dfsg-0+deb8u1
pn  python2.7:any
ii  samba-common 2:4.2.10+dfsg-0+deb8u1
ii  samba-common-bin 2:4.2.10+dfsg-0+deb8u1
ii  samba-dsdb-modules   2:4.2.10+dfsg-0+deb8u1
ii  samba-libs   2:4.2.10+dfsg-0+deb8u1
ii  tdb-tools1.3.6-0+deb8u1
ii  update-inetd 4.43

Versions of packages samba recommends:
ii  attr   1:2.4.47-2
ii  logrotate  3.8.7-1+b1
ii  samba-vfs-modules  2:4.2.10+dfsg-0+deb8u1

Versions of packages samba suggests:
pn  bind9  
pn  bind9utils 
pn  ctdb   
pn  ldb-tools  
ii  ntp1:4.2.6.p5+dfsg-7+deb8u1
pn  smbldap-tools  
pn  winbind

-- debconf information:
* samba/run_mode: daemons
  samba-common/title:

Bug#232584: new svnserve init.d script

[Roger Lynn]

On Sun, 25 Mar 2012 05:33:14 +0800 Liu Yubao  wrote:
> Share my svnserve init.d script.
> 
> First, I use user "svn" and group "svn" for svnserve:
> 
> [ "`getent group svn`" ] || addgroup --system svn
> 
> [ "`getent passwd svn`" ] || adduser --system --home /srv/svn \
> --shell /bin/false --ingroup svn --disabled-password \
> --disabled-login --gecos "svnserver server account" svn
> 
> Some file paths embedded in /etc/init.d/svnserve and can be adjusted in
> /etc/default/svnserve:
> repository root: /srv/svn
> pid file:  /var/run/svnserve.pid
> log file: /var/log/svnserve.log
> config file: /srv/svn/svnserve.conf  (I used --config-file option
> because I wouldn't like to manage */conf/svnserve.conf)
> 
> Files attached, hope that's useful for somebody:-)
> /etc/init.d/svnserve
> /etc/default/svnserve
> /etc/logrotate.d/svnserve
> 
> The  /etc/init.d/svnserve is modified from /etc/init.d/skeleton.

Thank you for the script, which I have been successfully using for several
years.

I've just upgraded to Jessie and svnserve now appears to require write
access to the directory containing the PID file. Also PID files have moved
to /run. I have therefore modified the script to create /run/svnserve with
owner svn:svn and moved the PID file to /run/svnserve/svnserve.pid

Roger
#! /bin/sh
### BEGIN INIT INFO
# Provides:  svnserve
# Required-Start:$local_fs $remote_fs $network $syslog
# Required-Stop: $local_fs $remote_fs $network $syslog
# Default-Start: 2 3 4 5
# Default-Stop:  0 1 6
# Short-Description: svnserver daemon service
# Description:   Starts, stops or restarts the svnserve daemon. The
#daemon serves requests from subversion clients.
### END INIT INFO

# Author: Yubao Liu 
#

# Do NOT "set -e"

# PATH should only include /usr/* if it runs after the mountnfs.sh script
PATH=/sbin:/usr/sbin:/bin:/usr/bin
DESC="svnserver daemon service"
NAME=svnserve
PIDDIR=/run/$NAME
PIDFILE=$PIDDIR/$NAME.pid
LOGFILE=/var/log/svnserve.log
DAEMON=/usr/bin/$NAME
DAEMON_ARGS="-d -T -r /srv/svn --config-file=/srv/svn/svnserve.conf 
--pid-file=$PIDFILE --log-file=$LOGFILE"
SCRIPTNAME=/etc/init.d/$NAME

# Exit if the package is not installed
[ -x "$DAEMON" ] || exit 0

# Read configuration variable file if it is present
[ -r /etc/default/$NAME ] && . /etc/default/$NAME

# Load the VERBOSE setting and other rcS variables
. /lib/init/vars.sh

# Define LSB log_* functions.
# Depend on lsb-base (>= 3.2-14) to ensure that this file is present
# and status_of_proc is working.
. /lib/lsb/init-functions

#
# Function that starts the daemon/service
#
do_start()
{
# Return
#   0 if daemon has been started
#   1 if daemon was already running
#   2 if daemon could not be started
if [ "$STARTUP" != "yes" ]; then
echo -n " [STARTUP isn't \"yes\" in /etc/default/svnserve]"
return 2
fi

start-stop-daemon --start --quiet --pidfile $PIDFILE --exec $DAEMON 
--test > /dev/null \
|| return 1
mkdir -p $PIDDIR
chown svn:svn $PIDDIR
touch $PIDFILE $LOGFILE
chown svn:svn $PIDFILE $LOGFILE
chmod 640 $LOGFILE
start-stop-daemon --start --quiet --pidfile $PIDFILE --exec $DAEMON -c 
svn:svn -- \
$DAEMON_ARGS \
|| return 2
# Add code here, if necessary, that waits for the process to be ready
# to handle requests from services started subsequently which depend
# on this one.  As a last resort, sleep for some time.
}

#
# Function that stops the daemon/service
#
do_stop()
{
# Return
#   0 if daemon has been stopped
#   1 if daemon was already stopped
#   2 if daemon could not be stopped
#   other if a failure occurred
start-stop-daemon --stop --quiet --retry=TERM/30/KILL/5 --pidfile 
$PIDFILE --name $NAME
RETVAL="$?"
[ "$RETVAL" = 2 ] && return 2
# Wait for children to finish too if this is a daemon that forks
# and if the daemon is only ever run from this initscript.
# If the above conditions are not satisfied then add some other code
# that waits for the process to drop all resources that could be
# needed by services started subsequently.  A last resort is to
# sleep for some time.
start-stop-daemon --stop --quiet --oknodo --retry=0/30/KILL/5 --exec 
$DAEMON
[ "$?" = 2 ] && return 2
# Many daemons don't delete their pidfiles when they exit.
rm -f $PIDFILE
return "$RETVAL"
}

#
# Function that sends a SIGHUP to the daemon/service
#
do_reload() {
#
# If the daemon can reload its configuration without
# restarting (for example, when it is sent a SIGHUP),
# then implement that here.
#
start-stop-daemon --stop --signal 1 --quiet --pidfile $PIDFILE --name 
$NAME
 

Bug#789862: Error: Message creation failed, not sending

[Roger Lynn]

Package: reportbug
Version: 6.6.3
Severity: normal

Hi,

I've just upgraded to Jessie and after editing a bug report for vsftpd 3.0.2-17 
I got the following output:

Report will be sent to Debian Bug Tracking System sub...@bugs.debian.org
Attachments:
 conf-file attached
 log-file attached
Submit this report on vsftpd (e to edit) [Y|n|a|c|e|i|l|m|p|q|d|t|s|?]? 
Warning: opening 'conf-file attached' failed: No such file or directory.
Warning: opening 'log-file attached' failed: No such file or directory.
Error: Message creation failed, not sending
Traceback (most recent call last):
  File /usr/bin/reportbug, line 2211, in module
main()
  File /usr/bin/reportbug, line 1081, in main
return iface.user_interface()
  File /usr/bin/reportbug, line 2203, in user_interface
self.options.envelopefrom)
  File /usr/lib/python2.7/dist-packages/reportbug/submit.py, line 316, in 
send_report
msgname = os.path.expanduser(outfile) or ('/var/tmp/%s.bug' % package)
  File /usr/lib/python2.7/posixpath.py, line 261, in expanduser
if not path.startswith('~'):
AttributeError: 'NoneType' object has no attribute 'startswith'

My bug report appears to have been deleted from /tmp. My reportbug
configuration has not changed since Wheezy.

Thank you,

Roger

-- Package-specific info:
** Environment settings:
INTERFACE=text

** /home/roger/.reportbugrc:
reportbug_version 4.12.6
mode advanced
ui text

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

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages reportbug depends on:
ii  apt   1.0.9.8.1
ii  python2.7.9-1
ii  python-reportbug  6.6.3
pn  python:anynone

reportbug recommends no packages.

Versions of packages reportbug suggests:
pn  claws-mail none
pn  debconf-utils  none
pn  debsumsnone
pn  dlocatenone
pn  emacs23-bin-common | emacs24-bin-commonnone
ii  exim4  4.84-8
ii  exim4-daemon-light [mail-transport-agent]  4.84-8
ii  file   1:5.22+15-2
ii  gnupg  1.4.18-7
pn  python-gtk2none
pn  python-gtkspellnone
pn  python-urwid   none
pn  python-vte none
ii  xdg-utils  1.1.0~rc1+git20111210-7.4

Versions of packages python-reportbug depends on:
ii  apt   1.0.9.8.1
ii  python-debian 0.1.27
ii  python-debianbts  1.12
pn  python:anynone

python-reportbug 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#787404: ntp_intres.request: permission denied

[Roger Lynn]

On 01/06/2015 09:16, Klaus Ethgen wrote:
 This is a successor of bug #571469. All is said there. NTP needs running
 DNS when it starts. Please add $named to Required-Start in init script.

What if a $named is not installed? Shouldn't it be Should-Start?

Roger
(Not an NTP maintainer or a Debian Developer)


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

Bug#785193: mailman depends on cron instead of cron-daemon

[Roger Lynn]

On 14/05/2015 14:41, Joost van Baal-Ilić wrote:
 Using the cron-daemon virtual package is clearly where we want to end up,
 wrote Russ Allbery in Message-id 87r3y5dwm3@hope.eyrie.org.
 
 So that would be a Depends: cron-daemon|cron for mailman afaik.
 
 See https://lists.debian.org/30446027.mNS7mfypdK@antec for some background
 information.  It would be nice to be able to ship a fixed mailman in 
 stretch.
 No hurry for now though, I'd guess.

Shouldn't the real package be listed before the virtual package in the
dependency field? It would be similar to the dependencies mailman already
has on apache2 | httpd and exim4 | mail-transport-agent, to give cron |
cron-daemon.

Roger


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

Bug#782450: ppp: Buffer overflow in radius plugin

[Roger Lynn]

On 14/04/2015 07:48, Emanuele Rocca wrote:
 NMU diff attached.


 ppp_2.4.6-3.1-nmu.diff

 diff -Nru ppp-2.4.6/debian/patches/rc_mksid-no-buffer-overflow 
 ppp-2.4.6/debian/patches/rc_mksid-no-buffer-overflow
 --- ppp-2.4.6/debian/patches/rc_mksid-no-buffer-overflow  1970-01-01 
 01:00:00.0 +0100
 +++ ppp-2.4.6/debian/patches/rc_mksid-no-buffer-overflow  2015-04-14 
 08:27:53.0 +0200
 @@ -0,0 +1,23 @@
 +Description: Fix buffer overflow in rc_mksid()
 + rc_mksid converts the PID of pppd to hex to generate a pseudo-unique string.
 + .
 + If the process id is bigger than 65535 (), its hex representation will 
 be
 + longer than 4 characters, resulting in a buffer overflow.
 + .
 + The bug can be exploited to cause a remote DoS.
 + .
 +Author: Emanuele Rocca e...@debian.org
 +Bug-Debian: https://bugs.debian.org/782450
 +Last-Update: 2015-04-14
 +
 +--- ppp-2.4.6.orig/pppd/plugins/radius/util.c
  ppp-2.4.6/pppd/plugins/radius/util.c
 +@@ -77,7 +77,7 @@ rc_mksid (void)
 +   static unsigned short int cnt = 0;
 +   sprintf (buf, %08lX%04X%02hX,
 +(unsigned long int) time (NULL),
 +-   (unsigned int) getpid (),
 ++   (unsigned int) getpid () % 65535,

Shouldn't this be 65536? If you're trying to limit to 0x then 65535  too
small. getpid ()  0x might be clearer than using the modulus operator
and should have exactly the same effect.

 +cnt  0xFF);
 +   cnt++;
 +   return buf;


Roger


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

Bug#782450: ppp: Buffer overflow in radius plugin

[Roger Lynn]

On 14/04/2015 07:48, Emanuele Rocca wrote:
 NMU diff attached.


 ppp_2.4.6-3.1-nmu.diff

 diff -Nru ppp-2.4.6/debian/patches/rc_mksid-no-buffer-overflow 
 ppp-2.4.6/debian/patches/rc_mksid-no-buffer-overflow
 --- ppp-2.4.6/debian/patches/rc_mksid-no-buffer-overflow  1970-01-01 
 01:00:00.0 +0100
 +++ ppp-2.4.6/debian/patches/rc_mksid-no-buffer-overflow  2015-04-14 
 08:27:53.0 +0200
 @@ -0,0 +1,23 @@
 +Description: Fix buffer overflow in rc_mksid()
 + rc_mksid converts the PID of pppd to hex to generate a pseudo-unique string.
 + .
 + If the process id is bigger than 65535 (), its hex representation will 
 be
 + longer than 4 characters, resulting in a buffer overflow.
 + .
 + The bug can be exploited to cause a remote DoS.
 + .
 +Author: Emanuele Rocca e...@debian.org
 +Bug-Debian: https://bugs.debian.org/782450
 +Last-Update: 2015-04-14
 +
 +--- ppp-2.4.6.orig/pppd/plugins/radius/util.c
  ppp-2.4.6/pppd/plugins/radius/util.c
 +@@ -77,7 +77,7 @@ rc_mksid (void)
 +   static unsigned short int cnt = 0;
 +   sprintf (buf, %08lX%04X%02hX,
 +(unsigned long int) time (NULL),
 +-   (unsigned int) getpid (),
 ++   (unsigned int) getpid () % 65535,

Shouldn't this be 65536? If you're trying to limit to 0x then 65535  too
small. getpid ()  0x might be clearer than using the modulus operator
and should have exactly the same effect.

 +cnt  0xFF);
 +   cnt++;
 +   return buf;


Roger


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

Bug#755722: systemd must sync systemclock to RTC on shutdown

[Roger Lynn]

On 13/02/2015 06:54, Martin Pitt wrote:
 Control: severity -1 normal
 
 I still disagree with critical:
 
  - If the hardware clock is so broken that at the next boot it has an
earlier time than on the previous boot/ntpdate, then writing it
once more at shutdown isn't going to entirely fix this problem, as
it will again go sufficiently wrong if you don't reboot immediately
but after some time.

A good hardware clock can easily lose many minutes over a year. A not
particularly bad one could lose an hour over a year and several minutes over
a month. That is not at all broken and will cause time to go backwards on
every reboot. Every machine with a hardware clock that does not run fast
will eventually run into this problem every time they reboot if the hardware
clock has not been written since installation, especially if they boot quickly.

The user can not easily monitor the status of the hardware clock and will
see that the time on the computer appears to be accurate. There is no reason
to assume that the hardware clock is more accurate when the user can only
monitor the system clock.

Roger


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

Bug#770069: Bug#769672: hdapsd: Doesn't start at boot

[Roger Lynn]

On 02/12/2014 13:47, Evgeni Golov wrote:

Hi,

On 11/26/2014 08:28 AM, Evgeni Golov wrote:

Thanks. Could you please test the following patched version:
 https://people.debian.org/~evgeni/tmp/hdapsd_20141024-3~test1_amd64.deb

What I do not really understand: read() should be interrupted on
SIGTERM/SIGUSR1, so we already should jump out of the loop!?


As far as I remember from when I looked at the code, a signal will interrupt 
the read() to call the signal handler. The signal handler sets a global 
variable and returns, which means the read() continues to wait. When the 
read() eventually returns the global variable is checked at the end of the 
main while loop which means that the program can finish.



Could any one of you confirm the package as working (properly stoping)
now, compared to the -2 version currently found in Debian?
I'd like to get it into Jessie, but can't test properly w/o the hardware.


Sorry, I missed your previous email. I'll try to test it in the next day or two.

Roger


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

Bug#770069: Bug#769672: hdapsd: Doesn't start at boot

[Roger Lynn]

On 02/12/14 14:01, Roger Lynn wrote:
 On 02/12/2014 13:47, Evgeni Golov wrote:
 On 11/26/2014 08:28 AM, Evgeni Golov wrote:
 Thanks. Could you please test the following patched version:
  https://people.debian.org/~evgeni/tmp/hdapsd_20141024-3~test1_amd64.deb

 What I do not really understand: read() should be interrupted on
 SIGTERM/SIGUSR1, so we already should jump out of the loop!?
 
 As far as I remember from when I looked at the code, a signal will interrupt 
 the read() to call the signal handler. The signal handler sets a global 
 variable and returns, which means the read() continues to wait. When the 
 read() eventually returns the global variable is checked at the end of the 
 main while loop which means that the program can finish.
 
 Could any one of you confirm the package as working (properly stoping)
 now, compared to the -2 version currently found in Debian?
 I'd like to get it into Jessie, but can't test properly w/o the hardware.
 
 Sorry, I missed your previous email. I'll try to test it in the next day or 
 two.

It stops immediately now, although the ordering of the logs is a little
strange. Here are the syslogs after starting and stopping it. Note the last
line and timings:

Dec  2 23:00:50 brahms hdapsd[15249]: Selected interface: FREEFALL
Dec  2 23:00:50 brahms hdapsd[15249]: Uses hardware logic from /dev/freefall

Dec  2 23:01:09 brahms hdapsd[15249]: Terminating hdapsd
Dec  2 23:01:09 brahms systemd[1]: hdapsd.service: main process exited,
code=exited, status=255/n/a
Dec  2 23:01:09 brahms systemd[1]: Unit hdapsd.service entered failed state.
Dec  2 23:01:09 brahms hdapsd[15249]: Tue Dec  2 23:00:50 2014: Starting hdapsd

Thanks,

Roger


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

Bug#769672: hdapsd: Doesn't start at boot

[Roger Lynn]

On 17/11/2014 11:12, Whoopie wrote:

I can reproduce the issue:
$ sudo /etc/init.d/hdapsd start
  * Starting IBM Hard Disk Active Protection System (HDAPS) daemon hdapsd   
[ OK ]

real0m2.059s
user0m0.050s
sys 0m0.023s

$ time sudo /etc/init.d/hdapsd stop
  * Stopping IBM Hard Disk Active Protection System (HDAPS) daemon hdapsd   
[ OK ]

real0m30.079s
user0m0.083s
sys 0m0.285s


It looks like hdapsd doesn't terminate in time, it get's KILLed after 30 
seconds, see the do_stop() function in /etc/init.d/hdapsd:
start-stop-daemon --stop --quiet --retry=TERM/30/KILL/5 --pidfile $PIDFILE 
--name $NAME

strace shows:
17912 --- SIGTERM {si_signo=SIGTERM, si_code=SI_USER, si_pid=18045, si_uid=0} 
---
17912 rt_sigaction(SIGTERM, {0x402cb0, [TERM], SA_RESTORER|SA_RESTART, 
0x7f779b2aec30}, {0x402cb0, [TERM], SA_RESTORER|SA_RESTART, 0x7f779b2aec30}, 8) 
= 0
17912 rt_sigreturn()= 0
17912 read(3,  unfinished ...
17912 +++ killed by SIGKILL +++


Adding some debugging output, the SIGTERM handler is called, but the while loop is not 
stopped, as the new running value doesn't find its way into the main process. 
But here, my coding skills stop, sorry.


I started looking at this yesterday, but ran out of time. I assume the code 
is getting stuck in a loop or function call, which means it never returns to 
the main while loop in main(). This is slightly worrying: if the main loop 
is not running does that meant the hard disc protection is not working?


Any signal apart from SIGTERM and SIGUSR1 is not caught and causes an 
immediate exit without shutting down nicely.


Should the instructions at:
https://www.debian.org/doc/manuals/debian-reference/ch12.en.html#_debugging_the_debian_package
build me a package with debugging enabled?

Roger


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

Bug#769672: hdapsd: Doesn't start at boot

[Roger Lynn]

On 16/11/14 17:09, Evgeni Golov wrote:

On 11/16/2014 06:00 PM, Evgeni Golov wrote:

Right, how about this:


The correct patch would be:
diff --git a/debian/README.Debian b/debian/README.Debian
index 97ea7cf..f914834 100644
--- a/debian/README.Debian
+++ b/debian/README.Debian
@@ -1,6 +1,16 @@
 hdapsd for Debian
 -

+disable hdapsd
+==
+
+hdapsd can be disabled on boot, if you want to start it manually.
+
+To disable hdapsd under systemd, use “systemctl disable hdapsd.service”.
+For inits using the init.d scripts, adjust /etc/default/hdapsd to have
+  START=no
+in it.
+
 hdapsd with kernels = 2.6.27
 =

diff --git a/debian/rules b/debian/rules
index fdbeae1..a7c6726 100755
--- a/debian/rules
+++ b/debian/rules
@@ -14,10 +14,3 @@ override_dh_auto_install:
 override_dh_auto_clean:
dh_auto_clean
rm -f $(CURDIR)/misc/*.service
-
-override_dh_systemd_enable:
-   # Do not enable the file by default on purpose.
-   # The user should enable it only after making sure the
configuration is
-   # appropriate for his/her computer.
-   # This corresponds to START=no in /etc/default/hdapsd
-   dh_systemd_enable --no-enable

That would also enable hdapsd after installation on systemd, which is
what you actually want.


That looks reasonable. I had found the START=yes line, which didn't help me
on systemd. I can't think of any reason why you would install the package
and want it to not run. The default configuration looks as if it should work
for the majority of cases and I assume it's not going to do any harm if it's
incorrectly configured or if the hardware doesn't exist. It's not as if it
is opening network ports with security implications.


I've never
used systemd before and I'm not enjoying it. I'm not convinced the Debian
packaging is ready yet for a stable release.


systemd packaging or hdapsd packaging?


systemd. I am surprised at how much sysvinit configuration is apparently not 
implemented in systemd. And I'm struggling with the lack of configuration 
files with only a binary interface through systemctl.


Roger


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

Bug#769672: hdapsd: Doesn't start at boot

[Roger Lynn]

On 17/11/14 17:00, Evgeni Golov wrote:
 On 11/17/2014 04:24 PM, Roger Lynn wrote:
 On 17/11/2014 11:12, Whoopie wrote:
 It looks like hdapsd doesn't terminate in time, it get's KILLed after
 30 seconds, see the do_stop() function in /etc/init.d/hdapsd:
 start-stop-daemon --stop --quiet --retry=TERM/30/KILL/5 --pidfile
 $PIDFILE --name $NAME

 strace shows:
 17912 --- SIGTERM {si_signo=SIGTERM, si_code=SI_USER, si_pid=18045,
 si_uid=0} ---
 17912 rt_sigaction(SIGTERM, {0x402cb0, [TERM], SA_RESTORER|SA_RESTART,
 0x7f779b2aec30}, {0x402cb0, [TERM], SA_RESTORER|SA_RESTART,
 0x7f779b2aec30}, 8) = 0
 17912 rt_sigreturn()= 0
 17912 read(3,  unfinished ...
 17912 +++ killed by SIGKILL +++
 
 This is
  ret = read(freefall_fd, count, sizeof(count));
 line 1249 from hdapsd.c
 
 Adding some debugging output, the SIGTERM handler is called, but the
 while loop is not stopped, as the new running value doesn't find its
 way into the main process. But here, my coding skills stop, sorry.
 
 read() blocks until there is something to read from /dev/freefall.
 
 I started looking at this yesterday, but ran out of time. I assume the
 code is getting stuck in a loop or function call, which means it never
 returns to the main while loop in main(). This is slightly worrying: if
 the main loop is not running does that meant the hard disc protection is
 not working?
 
 No, it should be working, because in the case the hardware logic detects
 a fall, the read will unblock.

I can confirm that shaking the laptop while waiting for hdapsd to to
terminate does make it unblock.

Thanks,

Roger


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

Bug#769672: hdapsd: Doesn't start at boot

[Roger Lynn]

On 16/11/14 13:53, Evgeni Golov wrote:
 Hi Roger,
 
 [ CCing Whoopie because he has more experience with the freefall code ]
 
 On 11/15/2014 03:07 PM, Roger Lynn wrote:
 
 After adding hdapsd to a newly installed Jessie laptop, it is not being
 started at bootup, with nothing being logged.
 
 hdapsd is installed disabled, you need to call systemctl enable
 hdapsd if you want to use it, I might have not documented that part
 properly, sorry.

I couldn't find anything in either README file or the man page. I've never
used systemd before and I'm not enjoying it. I'm not convinced the Debian
packaging is ready yet for a stable release.

 Running /etc/init.d/hdapsd start  starts it as expected:
 Nov 15 14:01:36 brahms hdapsd[10763]: Selected interface: FREEFALL
 Nov 15 14:01:36 brahms hdapsd[10763]: Uses hardware logic from /dev/freefall
 
 Cool, which HW is this?

Dell Latitude E6540. The drive is a ST500LM000-1EJ162. Do you want any more
details?

 However stopping hdapsd fails. Both shutting the laptop down or running
 /etc/init.d/hdapsd stop results in a 90 second timeout after which the
 process is killed:
 Nov 15 14:06:48 brahms systemd[1]: hdapsd.service stop-sigterm timed out. 
 Killing.
 Nov 15 14:06:48 brahms systemd[1]: hdapsd.service: main process exited, 
 code=killed, status=9/KILL
 Nov 15 14:06:48 brahms systemd[1]: Unit hdapsd.service entered failed state.
 
 Interesting. I do not have any freefall-capable HW here, so I never
 tried the code myself. I guess there is something fishy in the lets end
 now code when running on freefall, but I have no direct clue.
 
 Does this happen with sysvinit too?

I've not tried. It's a new installation which defaulted to systemd. I'm
debating whether to attempt to replace systemd with sysvinit.

Thanks,

Roger


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

Bug#769672: hdapsd: Doesn't start at boot

[Roger Lynn]

Package: hdapsd
Version: 1:20141024-1
Severity: important

Hi,

After adding hdapsd to a newly installed Jessie laptop, it is not being
started at bootup, with nothing being logged.
Running /etc/init.d/hdapsd start  starts it as expected:
Nov 15 14:01:36 brahms hdapsd[10763]: Selected interface: FREEFALL
Nov 15 14:01:36 brahms hdapsd[10763]: Uses hardware logic from /dev/freefall

However stopping hdapsd fails. Both shutting the laptop down or running
/etc/init.d/hdapsd stop results in a 90 second timeout after which the
process is killed:
Nov 15 14:06:48 brahms systemd[1]: hdapsd.service stop-sigterm timed out. 
Killing.
Nov 15 14:06:48 brahms systemd[1]: hdapsd.service: main process exited, 
code=killed, status=9/KILL
Nov 15 14:06:48 brahms systemd[1]: Unit hdapsd.service entered failed state.

Regards,

Roger

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

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

Versions of packages hdapsd depends on:
ii  init-system-helpers  1.21
ii  libc62.19-13
ii  libconfig9   1.4.9-2

Versions of packages hdapsd recommends:
pn  tp-smapi-dkms | tp-smapi-source  none

hdapsd suggests no packages.

-- Configuration Files:
/etc/hdapsd.conf changed:
  device=sda;
  adaptive=true;
  syslog=true;


-- 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#767331: get-iplayer: useless after BBC API changes

[Roger Lynn]

Hi,

Is there any chance of getting this fixed in Jessie please? I would have 
expected that a freeze exception would be granted for this bug and I believe 
uploads fixing 'important' bugs are still allowed.


Thanks,

Roger


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

Bug#766838: ntpdate runs before network is up

[Roger Lynn]

On 26/10/14 08:53, Torquil Macdonald Sørensen wrote:
4264 Oct 26 08:36:48 lenovo ntpdate[371]: Can't find host ntp.uio.no: Name 
 or service not known (-2)

I recently noticed a similar problem caused by ntpdate being run before my
DNS server (maradns at the moment) is started. I've worked around it by
telling ntpdate not to use the ntpd configuration and giving it some IP
addresses instead. Looking at your logs it's not clear to me whether your
problem is a lack of connectivity or just no DNS, but I'm no expert.

Roger


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

Bug#737921: [TLS1.2] gnutls only likes SHA1 and SHA256 certificates

[Roger Lynn]

On 23/10/2014 04:46, Desai, Jason wrote:

I ran into this bug too - not fun.  I was not able to find a work around until 
I started investigating how to disable SSLv3 to protect against POODLE.  Since 
it seems that the issue is with TLS 1.2 and SHA512, I think you can disable the 
TLS 1.2 protocol altogether as a work around until this gets fixed properly.  
Don't forget to disable SSLv3 while you're at it.


Thanks for the tip. I have only recently discovered that CACert have been 
offering SHA256 certificates for several months, but the option is only 
shown when you add a new server. This provides an alternative work around 
for those trying to use CACert certificates.  For details see:

http://blog.cacert.org/2014/06/selection-of-hash-algorithm-during-certificate-creation/

Roger


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

Bug#761580: RFP: iceape -- The Iceape Internet Suite

[Roger Lynn]

Package: wnpp
Severity: wishlist

* Package name: iceape
  Version : 2.29
* URL : http://www.seamonkey-project.org/
* License : MPL/GPL/LGPL
  Programming Lang: C++/XUL
  Description : The Iceape Internet Suite

The Iceape Internet Suite is an unbranded Seamonkey Internet Suite 
suitable for free distribution.

The SeaMonkey project is a community effort to develop the SeaMonkey 
all-in-one internet application suite (see below). Such a software suite 
was previously made popular by Netscape and Mozilla, and the SeaMonkey 
project continues to develop and deliver high-quality updates to this 
concept. Containing an Internet browser, email  newsgroup client with 
an included web feed reader, HTML editor, IRC chat and web development 
tools, SeaMonkey is sure to appeal to advanced users, web developers and 
corporate users.

Under the hood, SeaMonkey uses much of the same Mozilla source code 
which powers such successful siblings as Firefox and Thunderbird. Legal 
backing is provided by the Mozilla Foundation.


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

Bug#740160: gnutls unusable with cacert SHA2-512 sigs

[Roger Lynn]

Package: libgnutls26
Version: 2.12.20-8+deb7u1
Followup-For: Bug #740160

Hi,

I've just renewed the CAcert certificate on my production server and found
this bug. At this point my options would appear to be to move to a different
GNU/Linux distribution or move to a new certificate provider. Is that correct?

Thanks,

Roger

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

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

Versions of packages libgnutls26 depends on:
ii  libc6  2.13-38+deb7u1
ii  libgcrypt111.5.0-5+deb7u1
ii  libp11-kit00.12-3
ii  libtasn1-3 2.13-2
ii  multiarch-support  2.13-38+deb7u1
ii  zlib1g 1:1.2.7.dfsg-13

libgnutls26 recommends no packages.

libgnutls26 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#741675: clamav-base: Missing quoting and bogus generated config file

[Roger Lynn]

Package: clamav
Version: 0.98.1+dfsg-1+deb7u2
Followup-For: Bug #741675

This update also trashes the clamd.conf file, see below for its contents.
I've had to manually insert it as it also seems to upset reportbug:

Gathering additional data, this may take a while...
ERROR: Incorrect argument format for option LogRotate
ERROR: Missing argument for option at line 10
Spawning sensible-editor...

These are the messages I got from aptitude:

Preparing to replace libclamav6 0.98.1+dfsg-1+deb7u1 (using 
.../libclamav6_0.98.1+dfsg-1+deb7u2_i386.deb) ...
Unpacking replacement libclamav6 ...
Preparing to replace clamav-daemon 0.98.1+dfsg-1+deb7u1 (using 
.../clamav-daemon_0.98.1+dfsg-1+deb7u2_i386.deb) ...
[ ok ] Stopping ClamAV daemon: clamd Waiting .  . .
Unpacking replacement clamav-daemon ...
Preparing to replace clamav-base 0.98.1+dfsg-1+deb7u1 (using 
.../clamav-base_0.98.1+dfsg-1+deb7u2_all.deb) ...
Unpacking replacement clamav-base ...
Preparing to replace clamav-freshclam 0.98.1+dfsg-1+deb7u1 (using 
.../clamav-freshclam_0.98.1+dfsg-1+deb7u2_i386.deb) ...
[ ok ] Stopping ClamAV virus database updater: freshclam.
Unpacking replacement clamav-freshclam ...
Preparing to replace clamav 0.98.1+dfsg-1+deb7u1 (using 
.../clamav_0.98.1+dfsg-1+deb7u2_i386.deb) ...
Unpacking replacement clamav ...
Processing triggers for man-db ...
Setting up libclamav6 (0.98.1+dfsg-1+deb7u2) ...
Setting up clamav-base (0.98.1+dfsg-1+deb7u2) ...
/var/lib/dpkg/info/clamav-base.postinst: 403: [: 10: unexpected operator
Replacing config file /etc/clamav/clamd.conf with new version
Setting up clamav-freshclam (0.98.1+dfsg-1+deb7u2) ...
/var/lib/dpkg/info/clamav-freshclam.postinst: 353: [: 10: unexpected operator
Disabling old logrotate script for clamav-freshclam
Replacing config file /etc/clamav/freshclam.conf with new version
[] Starting ClamAV virus database updater: freshclamERROR: Missing argument 
for option at line 10
ERROR: Can't open/parse the config file /etc/clamav/freshclam.conf
 failed!
Setting up clamav-daemon (0.98.1+dfsg-1+deb7u2) ...
[] Starting ClamAV daemon: clamd ERROR: Incorrect argument format for 
option LogRotate
ERROR: Can't open/parse the config file /etc/clamav/clamd.conf
 failed!
Setting up clamav (0.98.1+dfsg-1+deb7u2) ...

Restoring my old clamd.conf and freshclam.conf files from backups appears to
allow clamav to work.

Thanks,

Roger

-- Package-specific info:
--- configuration ---
Checking configuration files in /etc/clamav

Config file: clamd.conf
---
#Automatically Generated by clamav-base postinst
#To reconfigure clamd run #dpkg-reconfigure clamav-base
#Please read /usr/share/doc/clamav-base/README.Debian.gz for details
LocalSocket /var/run/clamav/clamd.ctl
FixStaleSocket true
LocalSocketGroup clamav
LocalSocketMode 666
# TemporaryDirectory is not set to its default /tmp here to make overriding
# the default with environment variables TMPDIR/TMP/TEMP possible
User clamav
AllowSupplementaryGroups true
ScanMail true
ScanArchive true
ArchiveBlockEncrypted false
MaxDirectoryRecursion 30
FollowDirectorySymlinks false
FollowFileSymlinks false
ReadTimeout 180
MaxThreads 4
MaxConnectionQueueLength 8
LogSyslog false
LogRotate 10 clamav-base/LogRotate doesn't exist
LogFacility LOG_LOCAL6
LogClean false
LogVerbose false
PidFile /var/run/clamav/clamd.pid
DatabaseDirectory /var/lib/clamav
SelfCheck 3600
Foreground false
Debug false
ScanPE true
MaxEmbeddedPE 10 clamav-base/MaxEmbeddedPE doesn't exist
ScanOLE2 true
ScanHTML true
MaxHTMLNormalize 10 clamav-base/MaxHTMLNormalize doesn't exist
MaxHTMLNoTags 10 clamav-base/MaxHTMLNoTags doesn't exist
MaxScriptNormalize 10 clamav-base/MaxScriptNormalize doesn't exist
MaxZipTypeRcg 10 clamav-base/MaxZipTypeRcg doesn't exist
ScanSWF 10 clamav-base/ScanSWF doesn't exist
DetectBrokenExecutables false
ExitOnOOM false
LeaveTemporaryFiles false
AlgorithmicDetection true
ScanELF true
IdleTimeout 30
PhishingSignatures true
PhishingScanURLs true
PhishingAlwaysBlockSSLMismatch false
PhishingAlwaysBlockCloak false
DetectPUA false
ScanPartialMessages false
HeuristicScanPrecedence false
StructuredDataDetection false
CommandReadTimeout 5
SendBufTimeout 200
MaxQueue 100
ExtendedDetectionInfo true
OLE2BlockMacros false
ScanOnAccess 10 clamav-base/ScanOnAccess doesn't exist
OnAccessIncludePath 
OnAccessExcludePath 
OnAccessMaxFileSize 
OnAccessExcludeUID 
AllowAllMatchScan 10 clamav-base/AllowAllMatchScan doesn't exist
ForceToDisk 10 clamav-base/ForceToDisk doesn't exist
DisableCertCheck 10 clamav-base/DisableCertCheck doesn't exist
StreamMaxLength 50M
LogFile /var/log/clamav/clamav.log
LogTime true
LogFileUnlock false
LogFileMaxSize 0
Bytecode true
BytecodeSecurity TrustSigned
BytecodeTimeout 6
OfficialDatabaseOnly false
CrossFilesystems true

Config file: freshclam.conf
---
# Automatically created by the clamav-freshclam postinst
# Comments will get lost when you reconfigure the clamav-freshclam package

DatabaseOwner clamav

Bug#708852: how helping?

[Roger Lynn]

On 24/01/2014 10:30, Stéphane Grégoire wrote:
 How can I help to package latest version?
 
 Iceape is very important because I think it's better than iceweasel +
 icemonkey.

Agreed.

The Linux/x86_64 version from
http://www.seamonkey-project.org/releases/#contrib seems to work for me on
AMD64 Wheezy running out of my home directory, but I've no idea if the built
in updater will work[0] or what the dependencies are. I'm surprised that
Mozilla apparently can't produce a 64 bit build themselves when most Linuxes
have been 64 bit for many years.

Roger

[0] At least I should be able to just delete the old version and download a
new one if necessary as it doesn't try to install files all over the system.


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

Bug#695472: samba: cups smb:// printers broken after upgrading server to wheezy

[Roger Lynn]

Package: samba
Version: 2:3.6.6-6
Followup-For: Bug #695472

Hi,

After upgrading from Squeezy to Wheezy printing from 32b WinXP and 64b Win7
Pro inexplicably stopped working, the Windows queue list simply saying
Error and not giving any further details. With the default logging levels
nothing to explain the problem was being logged by Samba or Cups. I have no
idea what the problem was, but adding use client driver = yes to smb.conf
seems to have fixed it, which I was only able to find thanks to this bug. I
am using the Windows drivers for the printer.

Thanks,

Roger

PS Having just finished browsing to the end of the bug list, this would
appear to be the same as bug 709613. I will attempt to merge them.

-- System Information:
Debian Release: 7.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 
'stable')
Architecture: i386 (i686)

Kernel: Linux 3.2.0-4-686-pae (SMP w/1 CPU core)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages samba depends on:
ii  adduser3.113+nmu3
ii  debconf [debconf-2.0]  1.5.49
ii  dpkg   1.16.10
ii  libacl12.2.51-8
ii  libattr1   1:2.4.46-8
ii  libc6  2.13-38
ii  libcap21:2.22-1.2
ii  libcomerr2 1.42.5-1.1
ii  libcups2   1.5.3-5
ii  libgssapi-krb5-2   1.10.1+dfsg-5+deb7u1
ii  libk5crypto3   1.10.1+dfsg-5+deb7u1
ii  libkrb5-3  1.10.1+dfsg-5+deb7u1
ii  libldap-2.4-2  2.4.31-1+nmu2
ii  libpam-modules 1.1.3-7.1
ii  libpam-runtime 1.1.3-7.1
ii  libpam0g   1.1.3-7.1
ii  libpopt0   1.16-7
ii  libtalloc2 2.0.7+git20120207-1
ii  libtdb11.2.10-2
ii  libwbclient0   2:3.6.6-6
ii  lsb-base   4.1+Debian8+deb7u1
ii  procps 1:3.3.3-3
ii  samba-common   2:3.6.6-6
ii  update-inetd   4.43
ii  zlib1g 1:1.2.7.dfsg-13

Versions of packages samba recommends:
ii  logrotate  3.8.1-4
ii  tdb-tools  1.2.10-2

Versions of packages samba suggests:
pn  ctdb  none
pn  ldb-tools none
ii  openbsd-inetd [inet-superserver]  0.20091229-2
pn  smbldap-tools none

-- debconf information:
* samba/run_mode: daemons
* samba/generate_smbpasswd: false
  samba-common/title:


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

Bug#708174: gnutls26: with priority SECURE128 fails to negotiate a cipher suite with itself

[Roger Lynn]

On 13/05/13 18:28, Roger Lynn wrote:
 Running
 gnutls-serv -d 255 -p 1234 --x509certfile /etc/ssl/certs/rilynn.pem 
 --x509keyfile /etc/ssl/private/rilynn.key
 and
 gnutls-cli -d 255 -p 1234 --priority SECURE128 rilynn.me.uk
 on the same box fails to negotiate a cipher suite. A priority string of
 NORMAL appears to work.

Interestingly, SECURE256 also seems to work.

Roger


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

Bug#708174: gnutls26: with priority SECURE128 fails to negotiate a cipher suite with itself

[Roger Lynn]

Package: gnutls-bin
Version: 3.0.22-3+really2.12.20-7
Followup-For: Bug #708174

Hi,

I am testing on two machines, an old Pentium 3 system from which I originally
reported this bug and a new Xeon system from which I am sending this, both
running up to date Wheezy. I get the same results on both.

On 14/05/13 02:21, Daniel Kahn Gillmor wrote:
 On 05/13/2013 01:28 PM, Roger Lynn wrote:
 Source: gnutls26
 Version: 2.12.20-6
 Severity: normal
 
 Running
 gnutls-serv -d 255 -p 1234 --x509certfile /etc/ssl/certs/rilynn.pem 
 --x509keyfile /etc/ssl/private/rilynn.key
 and
 gnutls-cli -d 255 -p 1234 --priority SECURE128 rilynn.me.uk
 on the same box fails to negotiate a cipher suite. A priority string of
 NORMAL appears to work.
 
 Hm, i'm not able to replicate this, using gnutls-bin
 3.0.22-3+really2.12.20-6 (the version currently in wheezy/jessie/sid,
 which i think is the same version as the source package version
 mentioned above.

Sorry for the confusion, this message includes the details of the gnutls-bin
that I'm using.

 is it possible that your test is not connecting to the system you're
 testing?

I don't think so.

 here's how i ran my test:
 
  certtool -p  x.key
  echo 'cn=127.0.0.1'  template.cfg
  certtool -s --load-privkey x.key  x.cert --template template.cfg
  gnutls-serv -d 255 -p 1234 --x509certfile x.cert --x509keyfile x.key
 
 and then in another terminal:
 
  gnutls-cli -d 255 -p 1234 --x509cafile x.cert --priority SECURE128
 127.0.0.1
 
 And the connection succeeded, selecting the following parameters:
 
 - Version: TLS1.2
 - Key Exchange: DHE-RSA
 - Cipher: AES-128-CBC
 - MAC: SHA256
 - Compression: NULL

That works for me, which suggests (to me at least) that this might have
something to do with the keys or certificates. I have tested with two, both
created with OpenSSL and signed by CAcert. The newer one was created on 11 Oct
2012 on up to date Wheezy with the script at
http://svn.cacert.org/CAcert/Software/CSRGenerator/csr

 Using a priority string of SECURE128 for outgoing SMTP connections in Debian
 exim also fails between two Wheezy boxes, which is how I noticed the problem
 in the first place.
 
 hmm, this seems particularly worrisome!  I will try to set this up and
 test it.  what sort of failure are you seeing specifically? can you
 share (the relevant parts of) your configurations that show this error?

On the sending end I get the universal gnutls error message:
TLS error on connection to mail.fundamentalsltd.co.uk [217.169.26.194] 
(gnutls_handshake): A TLS packet with unexpected length was received.

/etc/exim4/conf.d/transport/30_exim4-config_remote_smtp has had the following
added:
tls_require_ciphers = SECURE128

On the receiving end I get:
TLS error on connection from rilynn.me.uk [90.155.73.34] (gnutls_handshake): 
Could not negotiate a supported cipher suite.

/etc/exim4/conf.d/main/00_local_options contains:
MAIN_TLS_ENABLE = defined
MAIN_TLS_CERTIFICATE = /etc/ssl/certs/mail_server.pem
MAIN_TLS_PRIVATEKEY = /etc/exim4/mail_privatekey.pem

 Also, gnutls appears to prefer to use the weakest available cipher instead of
 the strongest, which seems a bit odd.
 
 This also sounds worrisome, but it might be due to a misinterpretation
 of how the priority string is supposed to work.  --priority SECURE128 in
 gnutls26 appears to mean *only* the ciphersuites with 128-bit ciphers,
 not those ciphers and above.

This seems counter-intuitive, as the expected action would be to select a
minimum cipher length, which is what is suggested at 
http://www.gnutls.org/manual/html_node/Priority-Strings.html
However that presumably applies to a newer version of the software.
What is the correct way to exclude weaker ciphers?

 i note that there is no gnutls-doc/*really2.12.20-6 package in wheezy
 to compare with :/  That seems like it might make debugging or writing
 code that targets gnutls26 a serious challenge.

Is gnutls26-doc is what you are looking for?

Thanks for looking into this,

Roger

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

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

Versions of packages gnutls-bin depends on:
ii  libc6 2.13-38
ii  libgcrypt11   1.5.0-5
ii  libgnutls26   2.12.20-7
ii  libp11-kit0   0.12-3
ii  libreadline6  6.2+dfsg-0.1
ii  libtasn1-32.13-2
ii  zlib1g1:1.2.7.dfsg-13

gnutls-bin recommends no packages.

gnutls-bin 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#709236: /usr/bin/apt-cdrom: Replaces tabs with spaces in /etc/apt/sources.list

[Roger Lynn]

Package: apt
Version: 0.8.10.3+squeeze1
Severity: minor
File: /usr/bin/apt-cdrom

Hi,

apt-cdrom has replaced all the tabs with spaces in my nicely formatted
sources.list, messing up the appearance. It should not modify lines which
it is not specifically editing the contents of.

Thanks,

Roger

-- Package-specific info:

-- apt-config dump --

APT ;
APT::Architecture amd64;
APT::Build-Essential ;
APT::Build-Essential:: build-essential;
APT::Install-Recommends 1;
APT::Install-Suggests 0;
APT::Acquire ;
APT::Acquire::Translation environment;
APT::Authentication ;
APT::Authentication::TrustCDROM true;
APT::NeverAutoRemove ;
APT::NeverAutoRemove:: ^firmware-linux.*;
APT::NeverAutoRemove:: ^linux-firmware$;
APT::NeverAutoRemove:: ^linux-image.*;
APT::NeverAutoRemove:: ^kfreebsd-image.*;
APT::NeverAutoRemove:: ^linux-restricted-modules.*;
APT::NeverAutoRemove:: ^linux-ubuntu-modules-.*;
APT::Never-MarkAuto-Sections ;
APT::Never-MarkAuto-Sections:: metapackages;
APT::Never-MarkAuto-Sections:: restricted/metapackages;
APT::Never-MarkAuto-Sections:: universe/metapackages;
APT::Never-MarkAuto-Sections:: multiverse/metapackages;
APT::Never-MarkAuto-Sections:: oldlibs;
APT::Never-MarkAuto-Sections:: restricted/oldlibs;
APT::Never-MarkAuto-Sections:: universe/oldlibs;
APT::Never-MarkAuto-Sections:: multiverse/oldlibs;
Dir /;
Dir::State var/lib/apt/;
Dir::State::lists lists/;
Dir::State::cdroms cdroms.list;
Dir::State::mirrors mirrors/;
Dir::State::extended_states extended_states;
Dir::State::status /var/lib/dpkg/status;
Dir::Cache var/cache/apt/;
Dir::Cache::archives archives/;
Dir::Cache::srcpkgcache srcpkgcache.bin;
Dir::Cache::pkgcache pkgcache.bin;
Dir::Etc etc/apt/;
Dir::Etc::sourcelist sources.list;
Dir::Etc::sourceparts sources.list.d;
Dir::Etc::vendorlist vendors.list;
Dir::Etc::vendorparts vendors.list.d;
Dir::Etc::main apt.conf;
Dir::Etc::netrc auth.conf;
Dir::Etc::parts apt.conf.d;
Dir::Etc::preferences preferences;
Dir::Etc::preferencesparts preferences.d;
Dir::Etc::trusted trusted.gpg;
Dir::Etc::trustedparts trusted.gpg.d;
Dir::Bin ;
Dir::Bin::methods /usr/lib/apt/methods;
Dir::Bin::dpkg /usr/bin/dpkg;
Dir::Media ;
Dir::Media::MountPath /media/apt;
Dir::Log var/log/apt;
Dir::Log::Terminal term.log;
Dir::Log::History history.log;
Dir::Ignore-Files-Silently ;
Dir::Ignore-Files-Silently:: ~$;
Dir::Ignore-Files-Silently:: \.disabled$;
Dir::Ignore-Files-Silently:: \.bak$;
Dir::Ignore-Files-Silently:: \.dpkg-[a-z]+$;
DPkg ;
DPkg::Pre-Install-Pkgs ;
DPkg::Pre-Install-Pkgs:: /usr/bin/apt-listchanges --apt || test $? -ne 10;
DPkg::Pre-Install-Pkgs:: /usr/sbin/dpkg-preconfigure --apt || true;
DPkg::Tools ;
DPkg::Tools::Options ;
DPkg::Tools::Options::/usr/bin/apt-listchanges ;
DPkg::Tools::Options::/usr/bin/apt-listchanges::Version 2;
CommandLine ;
CommandLine::AsString apt-config dump;

-- /etc/apt/preferences --

Package: *
Pin: release a=lenny-backports
Pin-Priority: 200

-- /etc/apt/sources.list --

#deb cdrom:[Debian GNU/Linux squeeze-di-beta2 _Squeeze_ - Official Beta amd64 
DVD Binary-1 20101203-17:44]/ squeeze contrib main
#deb cdrom:[Debian GNU/Linux 5.0.1 _Lenny_ - Official amd64 CD Binary-1 
20090413-02:50]/ lenny main

deb cdrom:[Debian GNU/Linux 7.0.0 _Wheezy_ - Official amd64 CD Binary-1 
20130504-14:44]/ wheezy main
deb http://ftp.uk.debian.org/debian squeeze 
main contrib non-free
deb http://ftp.uk.debian.org/debian squeeze-updates 
 main contrib non-free
deb http://ftp.uk.debian.org/debian squeeze-proposed-updates
   main contrib non-free

#deb http://ftp.uk.debian.org/debian-volatile   squeeze/volatile
main contrib non-free
#deb http://ftp.uk.debian.org/debian-volatile   squeeze/volatile-sloppy 
main contrib non-free

##deb http://ftp.uk.debian.org/backports.org lenny-backports
main contrib non-free
#deb http://ftp.uk.debian.org/debian-backports   lenny-backports
main contrib non-free

deb http://security.debian.org   squeeze/updates
   main contrib non-free
##deb http://security.eu.debian.org lenny/updates   
main contrib non-free


deb-src http://ftp.uk.debian.org/debian squeeze 
main contrib non-free
deb-src http://ftp.uk.debian.org/debian squeeze-updates 
 main contrib non-free
deb-src http://ftp.uk.debian.org/debian 
squeeze-proposed-updates   main contrib non-free

deb-src http://security.debian.org  squeeze/updates 
 main contrib non-free

##deb http://volatile.debian.org/debian-volatile lenny/volatile main contrib 
non-free
##deb-src http://volatile.debian.org/debian-volatile lenny/volatile main 
contrib non-free


-- System Information:
Debian Release: 

Bug#708174: gnutls26: with priority SECURE128 fails to negotiate a cipher suite with itself

[Roger Lynn]

Source: gnutls26
Version: 2.12.20-6
Severity: normal

Running
gnutls-serv -d 255 -p 1234 --x509certfile /etc/ssl/certs/rilynn.pem 
--x509keyfile /etc/ssl/private/rilynn.key
and
gnutls-cli -d 255 -p 1234 --priority SECURE128 rilynn.me.uk
on the same box fails to negotiate a cipher suite. A priority string of
NORMAL appears to work.

The server reports:

Set static Diffie-Hellman parameters, consider --dhparams.
Echo Server listening on IPv4 0.0.0.0 port 1234...done
Echo Server listening on IPv6 :: port 1234...bind() failed: Address already in 
use
|4| REC[0x9224138]: Allocating epoch #0

* Accepted connection from IPv4 192.168.0.1 port 50714 on Mon May 13 18:07:09 
2013
|2| ASSERT: gnutls_constate.c:695
|4| REC[0x9224138]: Allocating epoch #1
|7| READ: Got 5 bytes from 0x5
|7| READ: read 5 bytes from 0x5
|7| RB: Have 0 bytes into buffer. Adding 5 bytes.
|7| RB: Requested 5 bytes
|4| REC[0x9224138]: Expected Packet[0] Handshake(22) with length: 1
|4| REC[0x9224138]: Received Packet[0] Handshake(22) with length: 113
|7| READ: Got 113 bytes from 0x5
|7| READ: read 113 bytes from 0x5
|7| RB: Have 5 bytes into buffer. Adding 113 bytes.
|7| RB: Requested 118 bytes
|4| REC[0x9224138]: Decrypted Packet[0] Handshake(22) with length: 113
|6| BUF[HSK]: Inserted 113 bytes of Data(22)
|6| BUF[REC][HD]: Read 1 bytes of Data(22)
|6| BUF[REC][HD]: Read 3 bytes of Data(22)
|3| HSK[0x9224138]: CLIENT HELLO was received [113 bytes]
|6| BUF[REC][HD]: Read 109 bytes of Data(22)
|6| BUF[HSK]: Inserted 4 bytes of Data
|6| BUF[HSK]: Inserted 109 bytes of Data
|3| HSK[0x9224138]: Client's version: 3.3
|2| ASSERT: gnutls_db.c:326
|2| ASSERT: gnutls_db.c:246
|2| EXT[0x9224138]: Parsing extension 'SERVER NAME/0' (17 bytes)
|2| EXT[0x9224138]: Parsing extension 'SAFE RENEGOTIATION/65281' (1 bytes)
|2| EXT[0x9224138]: Parsing extension 'SESSION TICKET/35' (0 bytes)
|2| EXT[0x9224138]: Parsing extension 'SIGNATURE ALGORITHMS/13' (6 bytes)
|2| EXT[SIGA]: rcvd signature algo (4.1) RSA-SHA256
|2| EXT[SIGA]: rcvd signature algo (2.2) DSA-SHA1
|2| ASSERT: gnutls_handshake.c:3348
|1| Could not find an appropriate certificate: Insufficient credentials for 
that request.
|3| HSK[0x9224138]: Removing ciphersuite: DHE_DSS_ARCFOUR_SHA1
|3| HSK[0x9224138]: Removing ciphersuite: DHE_DSS_3DES_EDE_CBC_SHA1
|3| HSK[0x9224138]: Removing ciphersuite: DHE_DSS_AES_128_CBC_SHA1
|3| HSK[0x9224138]: Removing ciphersuite: DHE_DSS_AES_256_CBC_SHA1
|3| HSK[0x9224138]: Removing ciphersuite: DHE_DSS_CAMELLIA_128_CBC_SHA1
|3| HSK[0x9224138]: Removing ciphersuite: DHE_DSS_CAMELLIA_256_CBC_SHA1
|3| HSK[0x9224138]: Removing ciphersuite: DHE_DSS_AES_128_CBC_SHA256
|3| HSK[0x9224138]: Removing ciphersuite: DHE_DSS_AES_256_CBC_SHA256
|3| HSK[0x9224138]: Removing ciphersuite: DHE_RSA_3DES_EDE_CBC_SHA1
|3| HSK[0x9224138]: Removing ciphersuite: DHE_RSA_AES_128_CBC_SHA1
|3| HSK[0x9224138]: Removing ciphersuite: DHE_RSA_AES_256_CBC_SHA1
|3| HSK[0x9224138]: Removing ciphersuite: DHE_RSA_CAMELLIA_128_CBC_SHA1
|3| HSK[0x9224138]: Removing ciphersuite: DHE_RSA_CAMELLIA_256_CBC_SHA1
|3| HSK[0x9224138]: Removing ciphersuite: DHE_RSA_AES_128_CBC_SHA256
|3| HSK[0x9224138]: Removing ciphersuite: DHE_RSA_AES_256_CBC_SHA256
|3| HSK[0x9224138]: Removing ciphersuite: RSA_ARCFOUR_SHA1
|3| HSK[0x9224138]: Removing ciphersuite: RSA_ARCFOUR_MD5
|3| HSK[0x9224138]: Removing ciphersuite: RSA_3DES_EDE_CBC_SHA1
|3| HSK[0x9224138]: Removing ciphersuite: RSA_AES_128_CBC_SHA1
|3| HSK[0x9224138]: Removing ciphersuite: RSA_AES_256_CBC_SHA1
|3| HSK[0x9224138]: Removing ciphersuite: RSA_CAMELLIA_128_CBC_SHA1
|3| HSK[0x9224138]: Removing ciphersuite: RSA_CAMELLIA_256_CBC_SHA1
|3| HSK[0x9224138]: Removing ciphersuite: RSA_AES_128_CBC_SHA256
|3| HSK[0x9224138]: Removing ciphersuite: RSA_AES_256_CBC_SHA256
|2| ASSERT: gnutls_handshake.c:921
|2| ASSERT: gnutls_handshake.c:586
|2| ASSERT: gnutls_handshake.c:2358
|2| ASSERT: gnutls_handshake.c:2991
|6| BUF[HSK]: Cleared Data from buffer
Error in handshake
Error: Could not negotiate a supported cipher suite.
|4| REC: Sending Alert[2|40] - Handshake failed
|4| REC[0x9224138]: Sending Packet[0] Alert(21) with length: 2
|7| WRITE: enqueued 7 bytes for 0x5. Total 7 bytes.
|7| WRITE FLUSH: 7 bytes in buffer.
|7| WRITE: wrote 7 bytes, 0 bytes left.
|4| REC[0x9224138]: Sent Packet[1] Alert(21) with length: 7
|2| ASSERT: gnutls_record.c:276
|6| BUF[HSK]: Cleared Data from buffer
|4| REC[0x9224138]: Epoch #0 freed
|4| REC[0x9224138]: Epoch #1 freed


The client reports :

Resolving 'rilynn.me.uk'...
Connecting to '192.168.0.1:1234'...
|4| REC[0x89c9238]: Allocating epoch #0
|2| ASSERT: gnutls_constate.c:695
|4| REC[0x89c9238]: Allocating epoch #1
|3| HSK[0x89c9238]: Keeping ciphersuite: DHE_RSA_AES_128_CBC_SHA256
|3| HSK[0x89c9238]: Keeping ciphersuite: DHE_RSA_AES_128_CBC_SHA1
|3| HSK[0x89c9238]: Keeping ciphersuite: DHE_RSA_CAMELLIA_128_CBC_SHA1
|3| HSK[0x89c9238]: Keeping ciphersuite: DHE_RSA_3DES_EDE_CBC_SHA1
|3| HSK[0x89c9238]: Keeping ciphersuite: 

Bug#684164: ppp: Please package upstream snaphots (was: rp-pppoe 3.11 allows 1500B MTU on PPPoE (RFC4638))

[Roger Lynn]

Hi,

Once wheezy was released I was going to request for upstream snapshots to be
packaged, as upstream appears to be stable, slow moving and releasing very
infrequently. I have been successfully running the latest upstream using the
Debian packaging for a PPPoE connection for the last six months without any
apparent problems on a moderately busy office server. Quite a few of the
Debian patches are included in the current upstream, so the packaging is
actually cleaner.

Thanks,

Roger


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

Bug#701508: nginx: Please provide httpd-cgi virtual package

[Roger Lynn]

On 23/02/2013 22:47, Roger Lynn wrote:
 Many packages which should work with nginx cannot be installed with it because
 they depend on httpd-cgi. Nginx can run CGI applications, yet the only way to
 do this seems to be to install another webserver and then disable it.

I had forgotten that fcgiwrap is also required in order to use CGI with
nginx, so I am not sure which package should provide httpd-cgi - but
probably nginx, which should at least suggest fcgiwrap.

Thanks,

Roger


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

Bug#699641: unbound: Returns SERVFAIL for every query if there was no internet access when started

[Roger Lynn]

On 02/02/13 20:07, Robert Edmonds wrote:
 Robert Edmonds wrote:
 Roger Lynn wrote:
  Every query returns SERVFAIL even after internet access appears and even 
  for
  queries which are forwarded to a local server. Unbound has to be restarted
  after internet access appears before it will work.
  
  This is a significant problem as if there is no internet access when 
  unbound
  is started then there is no DNS at all for the local network until internet
  access can be restored.
 
 i agree, that's definitely an issue.  it looks like there might have
 been some relevant fixes in unbound 1.4.19, do you think you could
 install unbound 1.4.19-1 from unstable and see if it behaves any better?
 i believe the dependencies are all the same, so you ought to be able to
 just pin the unbound packages from unstable.
 
 by the way, i believe you can set the domain-insecure option on your
 local domains in order to prevent DNSSEC failures from impacting the
 resolution of those domains.

I've tested this again this after adding 'domain-insecure: mydomain.co.uk'
to the configuration and upgrading to 1.4.17-3 from Testing.

I still get the following lines logged after a starting with no internet access:
Feb 22 18:25:34 alphonse unbound-anchor: /var/lib/unbound/root.key has content
Feb 22 18:25:34 alphonse unbound-anchor: fail: the anchor is NOT ok and
could not be fixed
Feb 22 18:25:35 alphonse unbound: [3910:0] notice: init module 0: validator
Feb 22 18:25:35 alphonse unbound: [3910:0] notice: init module 1: iterator
Feb 22 18:25:35 alphonse unbound: [3910:0] info: start of service (unbound
1.4.17).

But I no longer get the lines about failed to prime trust anchor -- could
not fetch DNSKEY rrset . DNSKEY IN. Resolution of local domains now works,
presumably because of the addition of the domain-insecure option.

When an internet connection is established then all DNS requests work as
normal, without having to restart unbound, so this problem seems to have
gone away. I don't understand why, as the changelog suggests an unrelated
minor update.

As I am no longer able to reproduce the original problem I am happy for this
bug to be closed, unless you think there is a need for further investigation.

Thank you for your time,

Roger


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

Bug#701508: nginx: Please provide httpd-cgi virtual package

[Roger Lynn]

Package: nginx
Version: 1.2.1-2.2
Severity: important

Hi,

Many packages which should work with nginx cannot be installed with it because
they depend on httpd-cgi. Nginx can run CGI applications, yet the only way to
do this seems to be to install another webserver and then disable it.

Thanks,

Roger

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

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

Versions of packages nginx depends on:
ii  nginx-full  1.2.1-2.2

nginx recommends no packages.

nginx 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#700729: swat: Password management has stopped working

[Roger Lynn]

On 18/02/2013 00:00, Andrew Bartlett wrote:
 On Sat, 2013-02-16 at 18:24 +, Roger Lynn wrote:
 At some point in the last month server password management using Swat has
 stopped working. Swat can be logged into and the old and new server passwords
 entered, but choosing Change Password appears to just reload the page
 without changing anything. Entering the wrong old password or mismatching
 new passwords does the same thing.
 
 The only relevant logging I can find is in /var/log/samba/log. which has
 recently started getting lots of lines like this when Swat is used:
 
 [2013/02/16 15:02:30.297508,  0] passdb/secrets.c:76(secrets_init)
   Failed to open /var/lib/samba/secrets.tdb
 
 As my only use of Swat is to allow users to change their passwords, this has
 had a major affect on the usability of the package.
 
 Please report upstream.  We may somehow be able to obtain the CSRF token
 and store it in memory before we become the non-privileged user. 
 
 Just to be sure, are you running SWAT as root, from xinetd?

SWAT is being run by stunnel, which is running in daemon mode. I couldn't
get it to work from inetd. The relevant part of my stunnel configuration
looks like this:

[swat]
accept  = 192.168.10.1:901
exec= /usr/sbin/swat
execargs = swat -P

According to ps SWAT is running as user root. It used to work and I don't
think anything has changed here so I presume SWAT has the necessary privileges.

I will attempt to report this upstream. I'd be grateful if any fixes could
be backported to Debian Wheezy, release policy permitting, as this appears
to be a regression caused by a security update.

Thanks,

Roger


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

Bug#700729: swat: Password management has stopped working

[Roger Lynn]

Package: swat
Version: 2:3.6.6-5
Severity: important

Hi,

At some point in the last month server password management using Swat has
stopped working. Swat can be logged into and the old and new server passwords
entered, but choosing Change Password appears to just reload the page
without changing anything. Entering the wrong old password or mismatching
new passwords does the same thing.

The only relevant logging I can find is in /var/log/samba/log. which has
recently started getting lots of lines like this when Swat is used:

[2013/02/16 15:02:30.297508,  0] passdb/secrets.c:76(secrets_init)
  Failed to open /var/lib/samba/secrets.tdb

# ls -l /var/lib/samba/secrets.tdb 
-rw--- 1 root root 430080 Aug 24 23:30 /var/lib/samba/secrets.tdb

24 August is the date I first installed Samba.

Swat is running through stunnel, which has always occasionally logged SSL
errors, but there don't appear to have been any recent changes to stunnel or
its dependancies.

While I don't know the Samba code, it looks at least possible to me that the
problem was introduced by the patch for CVE-2013-0214.

My smb.conf file looks like this:

[global]
workgroup = FUNDAMENTALS
server string = %h server
interfaces = 127.0.0.0/8, bond0
bind interfaces only = Yes
obey pam restrictions = Yes
pam password change = Yes
unix password sync = Yes
syslog = 0
log file = /var/log/samba/log.%m
max log size = 1000
load printers = No
os level = 65
preferred master = Yes
domain master = Yes
dns proxy = No
wins support = Yes
panic action = /usr/share/samba/panic-action %d
idmap config * : backend = tdb
invalid users = root
[Service]
comment = Service files
path = /srv/smb/service
read only = No
create mask = 0775
force create mode = 0664
directory mask = 0770
force directory mode = 0770
oplocks = No
level2 oplocks = No

There are several other similar share definitions.

Apart from the security update, the only other recent changes I can think of
are adding the level2 oplocks = No parameter, but I can't imagine that
affecting Swat, and I briefly tried max protocol = SMB2 but reverted that
when it appeared to negatively impact reliability in Windows.

As my only use of Swat is to allow users to change their passwords, this has
had a major affect on the usability of the package.

Thank you for your assistance,

Roger

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

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

Versions of packages swat depends on:
ii  dpkg  1.16.9
ii  libc6 2.13-37
ii  libcap2   1:2.22-1.2
ii  libcomerr21.42.5-1
ii  libcups2  1.5.3-2.14
ii  libgssapi-krb5-2  1.10.1+dfsg-3
ii  libk5crypto3  1.10.1+dfsg-3
ii  libkrb5-3 1.10.1+dfsg-3
ii  libldap-2.4-2 2.4.31-1
ii  libpam0g  1.1.3-7.1
ii  libpopt0  1.16-7
ii  libtalloc22.0.7+git20120207-1
ii  libtdb1   1.2.10-2
ii  libwbclient0  2:3.6.6-5
ii  openbsd-inetd [inet-superserver]  0.20091229-2
ii  samba 2:3.6.6-5
ii  zlib1g1:1.2.7.dfsg-13

Versions of packages swat recommends:
ii  samba-doc  2:3.6.6-5

swat 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#700350: dovecot-core: fails to upgrade from squeeze to bpo: Can't locate feature.pm in @INC

[Roger Lynn]

On 12/02/2013 17:20, gregor herrmann wrote:
 On Mon, 11 Feb 2013 23:40:38 +0100, Andreas Beckmann wrote:
 during a test with piuparts I noticed your package fails to upgrade from
 'squeeze'.
 It installed fine in 'squeeze', then the upgrade to 'squeeze-backports' 
 fails.
 
   Can't locate feature.pm in @INC (@INC contains: /etc/perl 
 /usr/local/lib/perl/5.10.1 /usr/local/share/perl/5.10.1 /usr/lib/perl5 
 /usr/share/perl5 /usr/lib/perl/5.10 /usr/share/perl/5.10 
 /usr/local/lib/site_perl .).
 
 Interesting.
 feature is in perl-modules (5.10.1) or perl-base (5.14 and 5.16):
 
 perl-base: /usr/share/perl/5.14.2/feature.pm
 perl-base: /usr/share/perl/5.16.2/feature.pm
 perl-modules: /usr/share/perl/5.10.1/feature.pm
 
 (And the /usr/share/perl/5.10 in your @INC output is a symlink to
 /usr/share/perl/5.10.1 where the file is.)
 
 Is this some timing issue, like the old perl-modules half uninstalled
 or something?

perl-modules probably isn't installed at all as dovecot-core in backports
doesn't appear to have a dependency on it and I can see no sign of it in the
piuparts log. perl-base in squeeze is 5.10.1 and presumably doesn't contain
the required file.

Roger

(Just a Dovecote user)


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

Bug#699641: unbound: Returns SERVFAIL for every query if there was no internet access when started

[Roger Lynn]

Package: unbound
Version: 1.4.17-2
Severity: normal

If there is no internet access when unbound is started (which there isn't on
my server immediately after a reboot), then unbound logs:
Feb  1 18:19:23 alphonse unbound-anchor: /var/lib/unbound/root.key has content
Feb  1 18:19:23 alphonse unbound-anchor: fail: the anchor is NOT ok and could 
not be fixed
Feb  1 18:19:23 alphonse unbound: [8860:0] notice: init module 0: validator
Feb  1 18:19:23 alphonse unbound: [8860:0] notice: init module 1: iterator
Feb  1 18:19:23 alphonse unbound: [8860:0] info: start of service (unbound 
1.4.17).
Feb  1 18:19:25 alphonse unbound: [8860:0] info: failed to prime trust anchor 
-- could not fetch DNSKEY rrset . DNSKEY IN
Feb  1 18:19:25 alphonse unbound: [8860:0] info: failed to prime trust anchor 
-- could not fetch DNSKEY rrset . DNSKEY IN
Feb  1 18:19:25 alphonse unbound: [8860:0] info: failed to prime trust anchor 
-- could not fetch DNSKEY rrset . DNSKEY IN
Feb  1 18:19:25 alphonse unbound: [8860:0] info: failed to prime trust anchor 
-- could not fetch DNSKEY rrset . DNSKEY IN
Feb  1 18:19:25 alphonse unbound: [8860:0] info: failed to prime trust anchor 
-- could not fetch DNSKEY rrset . DNSKEY IN
Feb  1 18:19:25 alphonse unbound: [8860:0] info: failed to prime trust anchor 
-- could not fetch DNSKEY rrset . DNSKEY IN

Every query returns SERVFAIL even after internet access appears and even for
queries which are forwarded to a local server. Unbound has to be restarted
after internet access appears before it will work.

This is a significant problem as if there is no internet access when unbound
is started then there is no DNS at all for the local network until internet
access can be restored.

Thanks,

Roger

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

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

Versions of packages unbound depends on:
ii  adduser 3.113+nmu3
ii  libc6   2.13-37
ii  libevent-2.0-5  2.0.19-stable-3
ii  libgcc1 1:4.7.2-5
ii  libldns11.6.13-1
ii  libpython2.72.7.3-6
ii  libssl1.0.0 1.0.1c-4
ii  openssl 1.0.1c-4
ii  unbound-anchor  1.4.17-2

unbound recommends no packages.

unbound suggests no packages.

-- Configuration Files:
/etc/unbound/unbound.conf changed:
server:
# The following line will configure unbound to perform cryptographic
# DNSSEC validation using the root trust anchor.
auto-trust-anchor-file: /var/lib/unbound/root.key
# verbosity number, 0 is least verbose. 1 is default.
verbosity: 1
# print statistics to the log (for every thread) every N seconds.
# Set to  or 0 to disable. Default is disabled.
statistics-interval: 86400
# print one line with time, IP, name, type, class for every query.
# log-queries: yes
# specify the interfaces to answer queries from by ip-address.
# The default is to listen to localhost (127.0.0.1 and ::1).
# specify 0.0.0.0 and ::0 to bind to all available interfaces.
# specify every interface[@port] on a new 'interface:' labelled line.
# The listen interfaces are not changed on reload, only on restart.
# interface: 2001:DB8::5
interface: 127.0.0.1
interface: 192.168.10.1
interface: 192.168.11.1
# specify the interfaces to send outgoing queries to authoritative
# server from by ip-address. If none, the default (all) interface
# is used. Specify every interface on a 'outgoing-interface:' line.
# outgoing-interface: 192.0.2.153
# outgoing-interface: 2001:DB8::5
# the time to live (TTL) value lower bound, in seconds. Default 0.
# If more than an hour could easily give trouble due to stale data.
cache-min-ttl: 60
# the time to live (TTL) value cap for RRsets and messages in the
# cache. Items are not cached for longer. In seconds.
cache-max-ttl: 172800
# control which clients are allowed to make (recursive) queries
# to this server. Specify classless netblocks with /size and action.
# By default everything is refused, except for localhost.
# Choose deny (drop message), refuse (polite error reply),
# allow (recursive ok), allow_snoop (recursive and nonrecursive ok)
access-control: 0.0.0.0/0 refuse
access-control: 127.0.0.0/8 allow
access-control: 192.168.10.0/23 allow
# Use 0x20-encoded random bits in the query to foil spoof attempts.
# This feature is an experimental implementation of draft dns-0x20.
# use-caps-for-id: no
# Enforce privacy of these addresses. Strips them away from answers. 
# It may cause DNSSEC validation to additionally mark 

Bug#699641: unbound: Returns SERVFAIL for every query if there was no internet access when started

[Roger Lynn]

On 02/02/13 20:07, Robert Edmonds wrote:
 Robert Edmonds wrote:
 hi, roger:
 
 i agree, that's definitely an issue.  it looks like there might have
 been some relevant fixes in unbound 1.4.19, do you think you could
 install unbound 1.4.19-1 from unstable and see if it behaves any better?
 i believe the dependencies are all the same, so you ought to be able to
 just pin the unbound packages from unstable.
 
 by the way, i believe you can set the domain-insecure option on your
 local domains in order to prevent DNSSEC failures from impacting the
 resolution of those domains.

Thank you for the suggestions and the quick response. It may be a couple of
weeks before I have an opportunity to carry out further testing.

Roger


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

Bug#695061: decode2text.sh: /usr/local/libexec/dovecot/xml2text is actually in /usr/lib/dovecot/

[Roger Lynn]

Package: dovecot-core
Version: 1:2.1.7-2
Severity: normal
File: /usr/lib/dovecot/decode2text.sh

Hi,

/usr/lib/dovecot/decode2text.sh references /usr/local/libexec/dovecot/xml2text
which is packaged in /usr/lib/dovecot/

Thanks,

Roger

-- Package-specific info:

dovecot configuration
-
# 2.1.7: /etc/dovecot/dovecot.conf
# OS: Linux 3.2.0-4-amd64 x86_64 Debian wheezy/sid 
auth_username_format = %Ln
first_valid_uid = 1000
last_valid_uid = 1
listen = 127.0.0.1, 217.xxx.xxx.xxx
mail_access_groups = sharedmail
mail_location = maildir:~/Maildir
mail_plugins =  zlib fts fts_squat acl
managesieve_notify_capability = mailto
managesieve_sieve_capability = fileinto reject envelope encoded-character 
vacation subaddress comparator-i;ascii-numeric relational regex imap4flags copy 
include variables body enotify environment mailbox date ihave
namespace {
  list = children
  location = maildir:/home/%%n/Maildir:INDEX=~/Maildir/shared/%%n
  prefix = shared/%%n/
  separator = /
  subscriptions = no
  type = shared
}
namespace inbox {
  inbox = yes
  location = 
  prefix = 
  separator = /
  type = private
}
passdb {
  driver = pam
}
plugin {
  acl = vfile
  acl_anyone = allow
  acl_shared_dict = file:/var/lib/dovecot/shared-mailboxes
  antispam_backend = pipe
  antispam_pipe_program = /usr/bin/spamc
  antispam_pipe_program_notspam_arg = --reporttype=revoke
  antispam_pipe_program_spam_arg = --reporttype=report
  antispam_pipe_tmpdir = /tmp
  antispam_spam = Junk;Junk E-mail
  antispam_trash = Trash;Deleted Items
  fts = squat
  fts_decoder = decode2text
  fts_squat = partial=4 full=10
  sieve = ~/Maildir/dovecot.sieve
  sieve_before = /etc/dovecot/before.sieve
  sieve_dir = ~/Maildir/sieve
}
protocols =  imap lmtp sieve
service auth {
  unix_listener auth-client {
user = Debian-exim
  }
}
service decode2text {
  executable = script /usr/lib/dovecot/decode2text.sh
  unix_listener decode2text {
mode = 0666
  }
  user = dovecot
}
ssl_cert = /etc/ssl/certs/mail_server.pem
ssl_cipher_list = HIGH
ssl_key = /etc/ssl/private/mail_privatekey.pem
userdb {
  driver = passwd
}
protocol lmtp {
  mail_plugins =  zlib fts fts_squat acl sieve
}
protocol imap {
  imap_idle_notify_interval = 5 mins
  mail_plugins =  zlib fts fts_squat acl imap_zlib antispam imap_acl
}

-- System Information:
Debian Release: wheezy/sid
  APT prefers testing-updates
  APT policy: (500, 'testing-updates'), (500, 'testing-proposed-updates'), 
(500, 'testing')
Architecture: amd64 (x86_64)

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

Versions of packages dovecot-core depends on:
ii  adduser 3.113+nmu3
ii  libbz2-1.0  1.0.6-4
ii  libc6   2.13-37
ii  libpam-runtime  1.1.3-7.1
ii  libpam0g1.1.3-7.1
ii  libssl1.0.0 1.0.1c-4
ii  openssl 1.0.1c-4
ii  ucf 3.0025+nmu3
ii  zlib1g  1:1.2.7.dfsg-13

dovecot-core recommends no packages.

Versions of packages dovecot-core suggests:
pn  dovecot-gssapinone
ii  dovecot-imapd 1:2.1.7-2
pn  dovecot-ldap  none
ii  dovecot-lmtpd 1:2.1.7-2
ii  dovecot-managesieved  1:2.1.7-2
pn  dovecot-mysql none
pn  dovecot-pgsql none
pn  dovecot-pop3d none
ii  dovecot-sieve 1:2.1.7-2
pn  dovecot-solr  none
pn  dovecot-sqlitenone
ii  ntp   1:4.2.6.p5+dfsg-2

Versions of packages dovecot-core is related to:
ii  dovecot-core [dovecot-common]  1:2.1.7-2
pn  dovecot-dbgnone
pn  dovecot-devnone
pn  dovecot-gssapi none
ii  dovecot-imapd  1:2.1.7-2
pn  dovecot-ldap   none
ii  dovecot-lmtpd  1:2.1.7-2
ii  dovecot-managesieved   1:2.1.7-2
pn  dovecot-mysql  none
pn  dovecot-pgsql  none
pn  dovecot-pop3d  none
ii  dovecot-sieve  1:2.1.7-2
pn  dovecot-sqlite none

-- 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#688634: roundcube-sqlite upgrade causes serious data-loss

[Roger Lynn]

On 24/11/2012 15:03, Dominik George wrote:
 I have asked people that did successfuly upgrade real sqlite databse to
 MySQL if they could provide directions or a script but they don't
 remember how they did it exactly. If nobody can come up with a script,
 we will just have to put a note in the release notes about this. I
 personnaly don't think that there are large installations using SQLite
 databases.
 
 Honestly, I think making a release note out of it is the way to go. Admins 
 should be capable of migrating the data themselves.

I installed the sqlite version of Roundcube at work because I don't
understand databases (we are too small to employ a sysadmin, and if we did
we would probably end up with a Windows server). At the rate things are
going my (20) users are going to lose data and I wish I had installed
Squirrelmail as I did at home.

Roger


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

Bug#691852: openbsd-inetd: inetd -l segfaults when internal services are enabled

[Roger Lynn]

Package: openbsd-inetd
Version: 0.20091229-2
Severity: normal

When internal services such as daytime or echo are enabled and 
OPTIONS=-l is set, openbsd-inetd segfaults when a connection is made 
to the service.

For example, telnet localhost daytime gives in syslog:

kernel: [1040052.300462] inetd[15842]: segfault at 0 ip 7fb847ada35c sp 
7fff6dcf0d68 error 4 in libc-2.13.so[7fb8479c2000+17d000]

The relevant line in inetd.conf reads:

daytime stream  tcp nowait  rootinternal

This is on an up to date Wheezy machine installed with the Wheezy Beta1 
installer.

Thanks,

Roger

-- System Information:
Debian Release: wheezy/sid
  APT prefers testing-updates
  APT policy: (500, 'testing-updates'), (500, 'testing-proposed-updates'), 
(500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-3-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages openbsd-inetd depends on:
ii  libc6 2.13-35
ii  libwrap0  7.6.q-24
ii  lsb-base  4.1+Debian7
ii  tcpd  7.6.q-24
ii  update-inetd  4.43

openbsd-inetd recommends no packages.

openbsd-inetd 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#691469: fetchmail apprently uses mboxo format, which irrecoverably corrupts mail

[Roger Lynn]

On 26/10/2012 02:24, Christoph Anton Mitterer wrote:
 This is basically the same as Debian bugs #690741 and #633799.
 I used severity critical, as the mboxo format causes irrecoverable
 mail corruption, which is unknown to most users.

I don't think the severity of critical is justified. This is an artefact of
the way email has been stored for decades. Just because Christoph was not
previously aware of it does not suddenly make it a critical bug. This is
also the way mail is handled by the default MTA in a standard Debian
installation. Not that I'm saying it shouldn't be improved, just that it
hasn't yet caused the world to end.

Roger

(Just a Fetchmail user. Not speaking for Debian or Fetchmail)


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

Bug#691407: logrotate(8) does not mention all reasons for ignoring included files

[Roger Lynn]

Package: logrotate
Version: 3.8.1-4
Severity: normal

Under the include directive, logrotate(8) says:

The only files which are ignored are files which are not regular files 
(such as directories and named pipes) and files whose names end with one 
of the taboo extensions, as specified by the tabooext directive.

This is not true. It would appear that files are also ignored because of 
some unspecified bad file modes, which include being group writeable. 
Unfortunately logrotate does not mention that it is ignoring these files 
unless it is especially run in verbose mode, which makes tracking down 
this problem more difficult. Other configuration errors usually generate 
notification emails.

Thanks,

Roger

-- Package-specific info:
Contents of /etc/logrotate.d
total 96
-rw-r--r-- 1 root root 173 Jun 29 13:31 apt
-rw-r--r-- 1 root root  79 Jun  9 11:14 aptitude
-rw-r--r-- 1 root root 215 Oct 27  2010 checksecurity
-rw-r--r-- 1 root root 209 Oct 11 20:20 clamav-daemon
-rw-r--r-- 1 root root 230 Oct 11 20:20 clamav-freshclam
-rw-r--r-- 1 root root 232 Jun 17 10:05 dpkg
-rw-r--r-- 1 root root 147 Aug 26 01:21 exim4-base
-rw-r--r-- 1 root root 146 Jun 23 18:16 exim4-base.dist
-rw-r--r-- 1 root root 146 Jun 23 18:16 exim4-base~
-rw-r--r-- 1 root root 126 Jun 23 18:16 exim4-paniclog
-rw-r--r-- 1 root root 150 Oct 16 17:04 local
-rw-rw-r-- 1 root root 142 Oct 16 17:00 local~
-rw-r--r-- 1 root root 356 Aug  4 17:17 nginx
-rw-r--r-- 1 root root  94 Jun 22 22:44 ppp
-rw-r--r-- 1 root root  88 Nov 15  2011 razor
-rw-r--r-- 1 root root 536 Oct 16 17:02 rsyslog
-rw-r--r-- 1 root root 515 Jun  9 20:54 rsyslog.dist
-rw-r--r-- 1 root root 517 Aug 26 01:20 rsyslog~
-rw-r--r-- 1 root root 322 Aug  5 18:07 samba
-rw-r--r-- 1 root root 108 Jul  3 00:31 shorewall
-rw-r--r-- 1 root root  85 Jul  3 00:29 shorewall-init
-rw-r--r-- 1 root root 109 Jul  3 00:32 shorewall6
-rw-r--r-- 1 root root 298 Jun  3 19:38 stunnel4
-rw-r--r-- 1 root root 148 Jun  9 21:45 ulogd


-- System Information:
Debian Release: wheezy/sid
  APT prefers testing-updates
  APT policy: (500, 'testing-updates'), (500, 'testing-proposed-updates'), 
(500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-3-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages logrotate depends on:
ii  base-passwd 3.5.26
ii  cron [cron-daemon]  3.0pl1-124
ii  libc6   2.13-35
ii  libpopt01.16-7
ii  libselinux1 2.1.9-5

Versions of packages logrotate recommends:
ii  bsd-mailx [mailx]  8.1.2-0.2006cvs-1

logrotate suggests no packages.

-- Configuration Files:
/etc/logrotate.conf changed:
weekly
rotate 4
create
tabooext + .dist
include /etc/logrotate.d
/var/log/wtmp {
missingok
monthly
create 0664 root utmp
rotate 1
}
/var/log/btmp {
missingok
monthly
create 0660 root utmp
rotate 1
}


-- 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#691409: shorewall refresh ignores AUTOMAKE option

[Roger Lynn]

Package: shorewall
Version: 4.5.5.3-2
Severity: normal

Hi,

From the documentation, shorewall refresh appears to be intended to be a 
lighter version of restart, however unlike restart it always performs 
the compilation step, ignoring the AUTOMAKE option. In addition refresh 
has no -f option which suppresses compilation during a restart.

Thanks,

Roger

-- System Information:
Debian Release: wheezy/sid
  APT prefers testing-updates
  APT policy: (500, 'testing-updates'), (500, 'testing-proposed-updates'), 
(500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-3-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages shorewall depends on:
ii  bc 1.06.95-2+b1
ii  debconf [debconf-2.0]  1.5.46
ii  iproute20120521-3
ii  iptables   1.4.14-3
ii  perl-modules   5.14.2-14
ii  shorewall-core 4.5.5.3-2

shorewall recommends no packages.

Versions of packages shorewall suggests:
ii  linux-image-3.2.0-3-amd64 [linux-image]  3.2.23-1
ii  make 3.81-8.2
ii  shorewall-doc4.5.5-1

-- Configuration Files:
/etc/default/shorewall changed:
startup=0
OPTIONS=
STARTOPTIONS=
RESTARTOPTIONS=
INITLOG=/dev/null
SAFESTOP=1

/etc/shorewall/params [Errno 13] Permission denied: u'/etc/shorewall/params'
/etc/shorewall/shorewall.conf changed:
STARTUP_ENABLED=Yes
VERBOSITY=1
BLACKLIST_LOGLEVEL=debug
LOG_MARTIANS=No
LOG_VERBOSITY=1
LOGALLNEW=
LOGFILE=/var/log/ulog/syslogemu.log
LOGFORMAT=Shwl:%s:%s:
LOGTAGONLY=No
LOGLIMIT=10/sec:10
MACLIST_LOG_LEVEL=info
RELATED_LOG_LEVEL=
SFILTER_LOG_LEVEL=info
SMURF_LOG_LEVEL=info
STARTUP_LOG=/var/log/shorewall-init.log
TCP_FLAGS_LOG_LEVEL=info
CONFIG_PATH=${CONFDIR}/shorewall:${SHAREDIR}/shorewall
GEOIPDIR=/usr/share/xt_geoip/LE
IPTABLES=
IP=
IPSET=
LOCKFILE=
MODULESDIR=
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin
PERL=/usr/bin/perl
RESTOREFILE=restore
SHOREWALL_SHELL=/bin/sh
SUBSYSLOCK=
TC=
ACCEPT_DEFAULT=none
DROP_DEFAULT=Drop
NFQUEUE_DEFAULT=none
QUEUE_DEFAULT=none
REJECT_DEFAULT=Reject
RCP_COMMAND='scp ${files} ${root}@${system}:${destination}'
RSH_COMMAND='ssh ${root}@${system} ${command}'
ACCOUNTING=Yes
ACCOUNTING_TABLE=filter
ADD_IP_ALIASES=No
ADD_SNAT_ALIASES=No
ADMINISABSENTMINDED=Yes
AUTO_COMMENT=Yes
AUTOMAKE=Yes
BLACKLISTNEWONLY=Yes
CLAMPMSS=No
CLEAR_TC=Yes
COMPLETE=Yes
DELETE_THEN_ADD=Yes
DETECT_DNAT_IPADDRS=No
DISABLE_IPV6=No
DONT_LOAD=
DYNAMIC_BLACKLIST=Yes
EXPAND_POLICIES=No
EXPORTMODULES=Yes
FASTACCEPT=Yes
FORWARD_CLEAR_MARK=
IMPLICIT_CONTINUE=No
IPSET_WARNINGS=Yes
IP_FORWARDING=On
KEEP_RT_TABLES=No
LEGACY_FASTSTART=No
LOAD_HELPERS_ONLY=Yes
MACLIST_TABLE=filter
MACLIST_TTL=
MANGLE_ENABLED=Yes
MAPOLDACTIONS=No
MARK_IN_FORWARD_CHAIN=No
MODULE_SUFFIX=ko
MULTICAST=No
MUTEX_TIMEOUT=30
NULL_ROUTE_RFC1918=Yes
OPTIMIZE=31
OPTIMIZE_ACCOUNTING=Yes
REQUIRE_INTERFACE=No
RESTORE_DEFAULT_ROUTE=Yes
RETAIN_ALIASES=No
ROUTE_FILTER=Yes
SAVE_IPSETS=No
TC_ENABLED=Internal
TC_EXPERT=No
TC_PRIOMAP=2 3 3 3 2 3 1 1 2 2 2 2 2 2 2 2
TRACK_PROVIDERS=No
USE_DEFAULT_RT=No
USE_PHYSICAL_NAMES=No
ZONE2ZONE=2
BLACKLIST_DISPOSITION=DROP
MACLIST_DISPOSITION=REJECT
RELATED_DISPOSITION=ACCEPT
SMURF_DISPOSITION=DROP
SFILTER_DISPOSITION=DROP
TCP_FLAGS_DISPOSITION=DROP
TC_BITS=
PROVIDER_BITS=
PROVIDER_OFFSET=
MASK_BITS=
ZONE_BITS=0
IPSECFILE=zones


-- debconf information:
  shorewall/dont_restart:
  shorewall/major_release:
  shorewall/invalid_config:


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

Bug#614582: harmless warning about acls from btrfs

[Roger Lynn]

Package: squashfs-tools
Version: 1:4.2-5
Followup-For: Bug #614582

These warning also occur with ext4.

Thanks,

Roger

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

Kernel: Linux 3.2.0-3-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages squashfs-tools depends on:
ii  libc6  2.13-35
ii  liblzma5   5.1.1alpha+20120614-1
ii  liblzo2-2  2.06-1
ii  zlib1g 1:1.2.7.dfsg-13

squashfs-tools recommends no packages.

squashfs-tools 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#690129: netplug: Please make clear the differences between netplug and ifplugd in the long description

[Roger Lynn]

Package: netplug
Version: 1.2.9.2-1
Severity: wishlist

Hi,

Netplug claims to be better than ifplugd, but it does not support all of 
ifplugd's functions (in particular: Can be configured to ignore short 
unplugged or plugged periods). Please indicate which ifplugd fuctions 
are not supported in the package's long description.

Thanks,

Roger

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

Kernel: Linux 3.2.0-3-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages netplug depends on:
ii  iproute  20120521-3
ii  libc62.13-35

netplug recommends no packages.

netplug 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#688789: /sbin/lvcreate: lvcreate/lvremove --quiet are not quiet

[Roger Lynn]

Package: lvm2
Version: 2.02.95-4
Severity: normal
File: /sbin/lvcreate

Every invocation of lvcreate --quiet or lvremove --quiet from a /bin/sh 
script called from bash outputs:

File descriptor 3 (/usr/share/bash-completion/completions) leaked on lvcreate 
invocation. Parent PID 32675: /bin/sh
  Logical volume backup created

or:

File descriptor 3 (/usr/share/bash-completion/completions) leaked on lvremove 
invocation. Parent PID 32675: /bin/sh
  Logical volume backup successfully removed

Having wasted quite a bit of time investigating this error message at least 
I know that is apparently meaningless and can be safely ignored. Perhaps this 
will be useful to other people encountering this error.

Thanks,

Roger

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

Kernel: Linux 3.2.0-3-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages lvm2 depends on:
ii  dmsetup   2:1.02.74-4
ii  initscripts   2.88dsf-32
ii  libc6 2.13-35
ii  libdevmapper-event1.02.1  2:1.02.74-4
ii  libdevmapper1.02.12:1.02.74-4
ii  libreadline5  5.2-11
ii  libudev0  175-7
ii  lsb-base  4.1+Debian7

lvm2 recommends no packages.

lvm2 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#586757: /usr/bin/mksquashfs: Re: please add --one-filesytem to mksquashfs

[Roger Lynn]

Package: squashfs-tools
Version: 1:4.2-5
Followup-For: Bug #586757

Hi,

It seems surprising that mksquashfs does not have a --one-file-system 
option when so many related commands include it and it would make using 
squashfs for backup purposes much easier.

I am struggling to find any record of this issue being forwarded to the
squashfs-devel mailing list in any list archives. When was this done?

Thanks,

Roger

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

Kernel: Linux 3.2.0-3-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages squashfs-tools depends on:
ii  libc6  2.13-35
ii  liblzma5   5.1.1alpha+20120614-1
ii  liblzo2-2  2.06-1
ii  zlib1g 1:1.2.7.dfsg-13

squashfs-tools recommends no packages.

squashfs-tools 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#687437: shorewall: README.Debian gives wrong location for default configuration files

[Roger Lynn]

Package: shorewall
Version: 4.5.5.3-1
Severity: minor

README.Debian and upstream's documentation give the location of the 
default upstream configuration files as 
/usr/share/doc/shorewall/default-config/ whereas they actually appear to 
be in /usr/share/shorewall/configfiles/

Thanks,

Roger

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

Kernel: Linux 3.2.0-3-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages shorewall depends on:
ii  bc 1.06.95-2+b1
ii  debconf [debconf-2.0]  1.5.46
ii  iproute20120521-3
ii  iptables   1.4.14-3
ii  perl-modules   5.14.2-12
ii  shorewall-core 4.5.5.3-1

shorewall recommends no packages.

Versions of packages shorewall suggests:
ii  linux-image-3.2.0-3-amd64 [linux-image]  3.2.23-1
ii  make 3.81-8.2
ii  shorewall-doc4.5.5-1

-- Configuration Files:
/etc/default/shorewall changed:
startup=0
OPTIONS=
STARTOPTIONS=
RESTARTOPTIONS=
INITLOG=/dev/null
SAFESTOP=1

/etc/shorewall/params [Errno 13] Permission denied: u'/etc/shorewall/params'
/etc/shorewall/shorewall.conf changed:
STARTUP_ENABLED=Yes
VERBOSITY=1
BLACKLIST_LOGLEVEL=info
LOG_MARTIANS=Yes
LOG_VERBOSITY=2
LOGALLNEW=
LOGFILE=/var/log/ulog/syslogemu.log
LOGFORMAT=Shwl:%s:%s:
LOGTAGONLY=No
LOGLIMIT=10/sec:10
MACLIST_LOG_LEVEL=info
RELATED_LOG_LEVEL=
SFILTER_LOG_LEVEL=info
SMURF_LOG_LEVEL=info
STARTUP_LOG=/var/log/shorewall-init.log
TCP_FLAGS_LOG_LEVEL=info
CONFIG_PATH=${CONFDIR}/shorewall:${SHAREDIR}/shorewall
GEOIPDIR=/usr/share/xt_geoip/LE
IPTABLES=
IP=
IPSET=
LOCKFILE=
MODULESDIR=
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin
PERL=/usr/bin/perl
RESTOREFILE=restore
SHOREWALL_SHELL=/bin/sh
SUBSYSLOCK=
TC=
ACCEPT_DEFAULT=none
DROP_DEFAULT=Drop
NFQUEUE_DEFAULT=none
QUEUE_DEFAULT=none
REJECT_DEFAULT=Reject
RCP_COMMAND='scp ${files} ${root}@${system}:${destination}'
RSH_COMMAND='ssh ${root}@${system} ${command}'
ACCOUNTING=Yes
ACCOUNTING_TABLE=filter
ADD_IP_ALIASES=No
ADD_SNAT_ALIASES=No
ADMINISABSENTMINDED=Yes
AUTO_COMMENT=Yes
AUTOMAKE=Yes
BLACKLISTNEWONLY=Yes
CLAMPMSS=No
CLEAR_TC=Yes
COMPLETE=Yes
DELETE_THEN_ADD=Yes
DETECT_DNAT_IPADDRS=No
DISABLE_IPV6=No
DONT_LOAD=
DYNAMIC_BLACKLIST=Yes
EXPAND_POLICIES=No
EXPORTMODULES=Yes
FASTACCEPT=Yes
FORWARD_CLEAR_MARK=
IMPLICIT_CONTINUE=No
IPSET_WARNINGS=Yes
IP_FORWARDING=On
KEEP_RT_TABLES=No
LEGACY_FASTSTART=No
LOAD_HELPERS_ONLY=Yes
MACLIST_TABLE=filter
MACLIST_TTL=
MANGLE_ENABLED=Yes
MAPOLDACTIONS=No
MARK_IN_FORWARD_CHAIN=No
MODULE_SUFFIX=ko
MULTICAST=No
MUTEX_TIMEOUT=30
NULL_ROUTE_RFC1918=Yes
OPTIMIZE=31
OPTIMIZE_ACCOUNTING=Yes
REQUIRE_INTERFACE=No
RESTORE_DEFAULT_ROUTE=Yes
RETAIN_ALIASES=No
ROUTE_FILTER=Yes
SAVE_IPSETS=No
TC_ENABLED=Simple
TC_EXPERT=No
TC_PRIOMAP=2 3 3 3 2 3 1 1 2 2 2 2 2 2 2 2
TRACK_PROVIDERS=No
USE_DEFAULT_RT=No
USE_PHYSICAL_NAMES=No
ZONE2ZONE=2
BLACKLIST_DISPOSITION=DROP
MACLIST_DISPOSITION=REJECT
RELATED_DISPOSITION=ACCEPT
SMURF_DISPOSITION=DROP
SFILTER_DISPOSITION=DROP
TCP_FLAGS_DISPOSITION=DROP
TC_BITS=
PROVIDER_BITS=
PROVIDER_OFFSET=
MASK_BITS=
ZONE_BITS=0
IPSECFILE=zones


-- debconf information:
  shorewall/dont_restart:
  shorewall/major_release:
  shorewall/invalid_config:


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

Bug#588349: shorewall: tcpri ports

[Roger Lynn]

On 07/07/2010 15:57, Roger Lynn wrote:
 It would be useful if it was possible to specify source and destination 
 ports separately in /etc/shorewall/tcpri

Upon rereading the documentation (shorewall-tcpri(5)) for this feature for a
new installation, it is not clear whether the port column refers to the
source or destination port and I may have previously misunderstood its
function. If it is the source, as the adjacent address column is, then it is
of limited use as the source port for connections is rarely predictable.

Roger


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

Bug#679491: marked as done ([fetchmail] Spamassassin-Fetchmail depedenty boot order needs fixing)

[Roger Lynn]

On 30/08/2012 15:00, Debian Bug Tracking System wrote:
 Closing this bug report. Imho this report is bogus and there has been no 
 further activity.

Then how should one ensure that Fetchmail starts after Spamassassin, which
is the only startup order that makes sense?

Roger


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

Bug#684128: false advertising

[Roger Lynn]

On 08/08/12 07:20, Didier 'OdyX' Raboud wrote:
 Le mardi, 7 août 2012 22.46:03, Roger Lynn a écrit :
 This has caught me out in the past. When it says gigabyte I expect 2^30
 bytes. Hopefully this time when I do an installation I will remember to get
 a calculator out. The people who don't care are mostly those who don't know
 what a gigabyte is.
 
 (FTR, that's near to be insulting in my standards…)

I'm sorry, that was over the top.

 I know what giga- and gibi-bytes are, but I still don't care right now; we 
 are 
 actually trying to get Wheezy out and there are other priorities (such as 572 
 Release-Critical bugs) than this type of problem.

Absolutely agreed. I wouldn't hope to see this fixed for Wheezy - even just
changing the wording of the text requires an enormous amount of work at this
stage - it's just frustrating to see it apparently being dismissed out of
hand as not being a problem.

Thanks,

Roger


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

Bug#684128: false advertising

[Roger Lynn]

On 08/08/2012 09:19, Herbert Kaminski wrote:
 Please have a look at IEC 60027-2 (or Wikipedia) to make clear that 
 the wording is absolutely correct. So if anybody wants to change 
 the units of measurement, a change to the wording _and_ the code 
 is required. 

I don't think anyone has suggested that the wording is wrong, just not what
is expected by many users. (Not that I agree with those standards, but
that's irrelevant.)

Roger


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

Bug#684164: ppp: Allow MTU to be increased up to 1500

[Roger Lynn]

Package: ppp
Severity: wishlist

Please consider applying the upstream patch at 
http://git.ozlabs.org/?p=ppp.git;a=commit;h=fd1dcdf758418f040da3ed801ab001b5e46854e7
to allow the MTU to be increased up to 1500 bytes for PPPoe connections.

Thanks,

Roger


-- System Information:
Debian Release: 6.0.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 
'stable'), (150, 'testing-proposed-updates'), (150, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


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

Bug#684128: false advertising

[Roger Lynn]

On Tue, 7 Aug 2012 14:11:05 +0200,
Christian PERRIER bubu...@debian.org wrote:
 I think you probably have a strange definition of just about
 everybody. In reality, I think that just about nobody cares about
 gigabytes being 2^30, or 10. This is basically splitting
 hairs, which wishlist perfectly fits.

This has caught me out in the past. When it says gigabyte I expect 2^30
bytes. Hopefully this time when I do an installation I will remember to get
a calculator out. The people who don't care are mostly those who don't know
what a gigabyte is.

Roger


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

Bug#678955: /etc/ntp.conf: Add discard and limited commands to default configuration

[Roger Lynn]

Package: ntp
Version: 1:4.2.6.p2+dfsg-1+b1
Severity: normal
File: /etc/ntp.conf

Hi,

In addition to adding the limited option to the restrict command, I would
suggest adding a discard command to override the default minimum request
period of 2 seconds, which will block ntpdate clients older than 4.2.7p22.

I use:

discard average 6 minimum 1
restrict default kod notrap nomodify nopeer noquery limited

A discard average of 6 (64 seconds) is possibly too aggressive for a default
setting and this could be left at its default of 3 (8 seconds).

This is mentioned in http://lists.ntp.org/pipermail/pool/2012-June/005885.html

Thanks,

Roger


-- System Information:
Debian Release: 6.0.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 
'stable'), (150, 'testing')
Architecture: i386 (i686)

Kernel: Linux 2.6.32-5-686 (SMP w/1 CPU core)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages ntp depends on:
ii  adduser3.112+nmu2add and remove users and groups
ii  dpkg   1.15.8.12 Debian package management system
ii  libc6  2.11.3-4  Embedded GNU C Library: Shared lib
ii  libcap21:2.19-3  support for getting/setting POSIX.
ii  libedit2   2.11-20080614-2   BSD editline and history libraries
ii  libopts25  1:5.10-1.1automated option processing librar
ii  libssl0.9.80.9.8o-4squeeze13 SSL shared libraries
ii  lsb-base   3.2-23.2squeeze1  Linux Standard Base 3.2 init scrip
ii  netbase4.45  Basic TCP/IP networking system

Versions of packages ntp recommends:
ii  perl   5.10.1-17squeeze3 Larry Wall's Practical Extraction 

Versions of packages ntp suggests:
pn  ntp-doc   none (no description available)

-- Configuration Files:
/etc/ntp.conf 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#676655: /usr/sbin/ntpdate-debian: Doesn't recognise tabs in ntp.conf

[Roger Lynn]

Package: ntpdate
Version: 1:4.2.6.p2+dfsg-1+b1
Severity: normal
File: /usr/sbin/ntpdate-debian

Hi,

When scanning ntp.conf for servers, ntpdate-debian appears to require
precisely one space between the server or peer statement and the address.
In particular it fails to recognise addresses preceded by tabs or multiple
spaces, which means that it can fail to find any servers at all in a nicely
formatted ntp.conf file.

Thank you,

Roger


-- System Information:
Debian Release: 6.0.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 
'stable'), (150, 'testing')
Architecture: i386 (i686)

Kernel: Linux 2.6.32-5-686 (SMP w/1 CPU core)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages ntpdate depends on:
ii  dpkg   1.15.8.12 Debian package management system
ii  libc6  2.11.3-3  Embedded GNU C Library: Shared lib
ii  libcap21:2.19-3  support for getting/setting POSIX.
ii  libssl0.9.80.9.8o-4squeeze13 SSL shared libraries
ii  netbase4.45  Basic TCP/IP networking system

Versions of packages ntpdate recommends:
ii  lockfile-progs0.1.15 Programs for locking and unlocking

ntpdate 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#568880: ~/.spamassassin/bayes_journal owned by root after sa-compile

[Roger Lynn]

Package: spamassassin
Version: 3.3.1-1
Severity: normal

On Mon, 8 Feb 2010 18:25:11 +0100, Alexander Wirt formo...@formorer.de wrote:
 As I told you on IRC: if you run software as root you should expect that you
 end with files that root created. 
 
 The docs may be improved a little bit, but this is only wishlist. I fail to
 see any bug here. 

But sa-compile is run as root by /etc/cron.daily/spamassassin. Surely that
is a bug? It results in bayes failing after nearly every rules update.

Thanks,

Roger


-- System Information:
Debian Release: 6.0.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 
'stable'), (150, 'testing')
Architecture: i386 (i686)

Kernel: Linux 2.6.32-5-686 (SMP w/1 CPU core)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages spamassassin depends on:
pn  libarchive-tar-perlnone(no description available)
ii  libdigest-sha1-perl2.13-1NIST SHA-1 message digest algorith
ii  libhtml-parser-perl3.66-1collection of modules that parse H
ii  libnet-dns-perl0.66-2Perform DNS queries from a Perl sc
ii  libnetaddr-ip-perl 4.028+dfsg-1  IP address manipulation module
ii  libsocket6-perl0.23-1Perl extensions for IPv6
ii  libsys-hostname-long-p 1.4-2 Figure out the long (fully-qualifi
ii  libwww-perl5.836-1   Perl HTTP/WWW client/server librar
ii  perl   5.10.1-17squeeze3 Larry Wall's Practical Extraction 
ii  perl-modules [libio-zl 5.10.1-17squeeze3 Core Perl modules

Versions of packages spamassassin recommends:
ii  gcc4:4.4.5-1 The GNU C compiler
ii  gnupg  1.4.10-4  GNU privacy guard - a free PGP rep
ii  libc6-dev  2.11.3-3  Embedded GNU C Library: Developmen
ii  libio-socket-inet6-per 2.65-1.1  Object interface for AF_INET6 doma
ii  libmail-spf-perl   2.007-1   Perl implementation of Sender Poli
ii  make   3.81-8An utility for Directing compilati
ii  perl [libsys-syslog-pe 5.10.1-17squeeze3 Larry Wall's Practical Extraction 
ii  re2c   0.13.5-1  tool for generating fast C-based r
ii  spamc  3.3.1-1   Client for SpamAssassin spam filte

Versions of packages spamassassin suggests:
pn  libdbi-perlnone(no description available)
pn  libio-socket-ssl-perl  none(no description available)
ii  libmail-dkim-perl  0.38-1cryptographically identify the sen
pn  libnet-ident-perl  none(no description available)
ii  perl [libcompress-zlib 5.10.1-17squeeze3 Larry Wall's Practical Extraction 
ii  pyzor  1:0.5.0-2 spam-catcher using a collaborative
ii  razor  1:2.85-3  spam-catcher using a collaborative

-- Configuration Files:
/etc/cron.daily/spamassassin changed:
CRON=0
test -f /etc/default/spamassassin  . /etc/default/spamassassin
test -x /usr/bin/sa-update || exit 0
test -x /etc/init.d/spamassassin || exit 0
if [ $CRON = 0 ] ; then
exit 0
fi
die_with_lint() {
spamassassin --lint -D 21
exit 1
}
do_compile() {
if [ -x /usr/bin/re2c -a -x /usr/bin/sa-compile \
-a -d /var/lib/spamassassin/compiled ]; then
sa-compile --quiet
# Fixup perms -- group and other should be able to
# read and execute, but never write.  Works around
# sa-compile's failure to obey umask.
if [ -d /var/lib/spamassassin ]; then
chmod -R go-w,go+rX /var/lib/spamassassin/
fi
fi
}
reload() {
# Reload
if which invoke-rc.d /dev/null 21; then
invoke-rc.d spamassassin reload  /dev/null
else
/etc/init.d/spamassassin reload  /dev/null
fi
if [ -d /etc/spamassassin/sa-update-hooks.d ]; then
run-parts --lsbsysinit /etc/spamassassin/sa-update-hooks.d
fi
}
RANGE=3600
number=`od -vAn -N2 -tu4  /dev/urandom`
number=`expr $number % $RANGE`
sleep $number
umask 022
sa-update
case $? in
0)
# got updates!
su -s /bin/sh -c spamassassin --lint spamd || die_with_lint
do_compile
reload
;;
1)
# no updates
#exit 0
;;
2)
# lint failed!
die_with_lint
;;
*)
echo sa-update failed for unknown reasons 12
;;
esac
su -s /bin/sh -c sa-learn --force-expire spamd

/etc/default/spamassassin changed:
ENABLED=1
OPTIONS=-u spamd --allow-tell
PIDFILE=/var/run/spamd.pid
CRON=1

/etc/spamassassin/local.cf changed:
time_limit 50
clear_report_template
report Host _HOSTNAME_, requires _REQD_ points.
report _SUMMARY_
clear_unsafe_report_template
unsafe_report **UNSAFE SPAM**
unsafe_report Host _HOSTNAME_, requires _REQD_ points.
unsafe_report _SUMMARY_
auto_whitelist_path 

Bug#623861: /etc/cron.daily/spamassassin running sa-update as root

[Roger Lynn]

Package: spamassassin
Version: 3.3.1-1
Severity: normal

On Sat, 23 Apr 2011 12:35:58 -0700, Jameson Graef Rollins 
jroll...@finestructure.net wrote:
 The cron script (/etc/cron.daily/spamassassin) runs sa-update as root.
 However, sa-update pulls spamassassin rules from the net
 (updates.spamassassin.org by default).  It seems to me that running
 sa-update as root is a really BAD idea.  I do not want the root user
 on my system to be pulling data off of the net if it can be avoided.
 And it seems like it can in this case, since sa-update could be run by
 a non-priviledged user.

In addition to the above, that cron script also runs sa-compile as root,
which is a cause (but not the only one) of bugs #568880 and #504154.

 I think that /etc/cron.daily/spamassassin should either be modified to
 run sa-update as a non-priviledged user (presumably something like
 spamd).  Either that or the sa-update portion itself should be run
 under the non-priviledged user in /etc/cron.d/spamassassin.

The same should also be done for sa-compile. Can the whole script be run
as a different user?

Thanks,

Roger


-- System Information:
Debian Release: 6.0.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 
'stable'), (150, 'testing')
Architecture: i386 (i686)

Kernel: Linux 2.6.32-5-686 (SMP w/1 CPU core)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages spamassassin depends on:
pn  libarchive-tar-perlnone(no description available)
ii  libdigest-sha1-perl2.13-1NIST SHA-1 message digest algorith
ii  libhtml-parser-perl3.66-1collection of modules that parse H
ii  libnet-dns-perl0.66-2Perform DNS queries from a Perl sc
ii  libnetaddr-ip-perl 4.028+dfsg-1  IP address manipulation module
ii  libsocket6-perl0.23-1Perl extensions for IPv6
ii  libsys-hostname-long-p 1.4-2 Figure out the long (fully-qualifi
ii  libwww-perl5.836-1   Perl HTTP/WWW client/server librar
ii  perl   5.10.1-17squeeze3 Larry Wall's Practical Extraction 
ii  perl-modules [libio-zl 5.10.1-17squeeze3 Core Perl modules

Versions of packages spamassassin recommends:
ii  gcc4:4.4.5-1 The GNU C compiler
ii  gnupg  1.4.10-4  GNU privacy guard - a free PGP rep
ii  libc6-dev  2.11.3-3  Embedded GNU C Library: Developmen
ii  libio-socket-inet6-per 2.65-1.1  Object interface for AF_INET6 doma
ii  libmail-spf-perl   2.007-1   Perl implementation of Sender Poli
ii  make   3.81-8An utility for Directing compilati
ii  perl [libsys-syslog-pe 5.10.1-17squeeze3 Larry Wall's Practical Extraction 
ii  re2c   0.13.5-1  tool for generating fast C-based r
ii  spamc  3.3.1-1   Client for SpamAssassin spam filte

Versions of packages spamassassin suggests:
pn  libdbi-perlnone(no description available)
pn  libio-socket-ssl-perl  none(no description available)
ii  libmail-dkim-perl  0.38-1cryptographically identify the sen
pn  libnet-ident-perl  none(no description available)
ii  perl [libcompress-zlib 5.10.1-17squeeze3 Larry Wall's Practical Extraction 
ii  pyzor  1:0.5.0-2 spam-catcher using a collaborative
ii  razor  1:2.85-3  spam-catcher using a collaborative

-- Configuration Files:
/etc/cron.daily/spamassassin changed:
CRON=0
test -f /etc/default/spamassassin  . /etc/default/spamassassin
test -x /usr/bin/sa-update || exit 0
test -x /etc/init.d/spamassassin || exit 0
if [ $CRON = 0 ] ; then
exit 0
fi
die_with_lint() {
spamassassin --lint -D 21
exit 1
}
do_compile() {
if [ -x /usr/bin/re2c -a -x /usr/bin/sa-compile \
-a -d /var/lib/spamassassin/compiled ]; then
sa-compile --quiet
# Fixup perms -- group and other should be able to
# read and execute, but never write.  Works around
# sa-compile's failure to obey umask.
if [ -d /var/lib/spamassassin ]; then
chmod -R go-w,go+rX /var/lib/spamassassin/
fi
fi
}
reload() {
# Reload
if which invoke-rc.d /dev/null 21; then
invoke-rc.d spamassassin reload  /dev/null
else
/etc/init.d/spamassassin reload  /dev/null
fi
if [ -d /etc/spamassassin/sa-update-hooks.d ]; then
run-parts --lsbsysinit /etc/spamassassin/sa-update-hooks.d
fi
}
RANGE=3600
number=`od -vAn -N2 -tu4  /dev/urandom`
number=`expr $number % $RANGE`
sleep $number
umask 022
sa-update
case $? in
0)
# got updates!
su -s /bin/sh -c spamassassin --lint spamd || die_with_lint
do_compile
reload
;;
1)
# no updates
#exit 0
;;
2)
# 

Bug#668903: The installer marks everything manually installed.

[Roger Lynn]

This is one of the reasons why I don't install tasks from the installer,
and one of the first things I do on a new system is to mark most
packages (especially libs) as automatically installed. I would be
grateful if a way could be found to improve this.

Thanks for your work on Debian,

Roger



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

Bug#652564: roundcube: please package new upstream 0.7

[Roger Lynn]

On 19/12/11 10:12, Roger Lynn wrote:
 A Backport to Squeeze would also be very much appreciated, if it's not too 
 much
 trouble.

I wrote that without checking the dependencies first, as it's not
something one has to worry about when installing from Backports.

Having now checked, it appears that Testing Roundcube's dependencies can
be almost entirely satisfied from Stable. The only exceptions are
libjs-jquery (and -mousewheel for -plugins-extra), which is in Backports
(and is installable from Testing anyway), and presumably in the future
php-mail-mime 1.8.2, which should be installable from Testing.

So I personally don't need a Backport and I withdraw this request, but
one might still be useful for those who wouldn't consider installing
something from Testing.

Thanks again,

Roger



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

Bug#632299: nano: Very slow scrolling since installing Squeeze

[Roger Lynn]

Hi,

In addition to the very slow scrolling, pasting about 6kB of text into a
nano running in an ssh session in an xterm locks nano up for about 30
seconds, using 99% CPU time. The first three times I tried it I thought
my ssh session had hung, but it actually seems that nano has a serious
performance problem.

Regards,

Roger



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

Bug#614817: Tabs in /etc/sources.list*

[Roger Lynn]

On Tue, 05 Jul 2011 23:16:29 +0200, Rodolphe Pelloux-Prayer
rodol...@damsy.net wrote:
 The attached patch fixe this bug and add the ability to highlight the
 file in /etc/apt/sources.list.d/*.list.

I've applied it directly to the installed files on a Squeeze system. It
seems to do the job, thank you.

Roger



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

Bug#636592: New versions of Horde are available

[Roger Lynn]

Package: horde3
Severity: wishlist


Hi,

It would be great if Horde 4 could be packaged in time to get it into
wheezy.

Thank you for all your work on Debian,

Roger


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

Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash



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

Bug#581565: improve documentation for exim integration

[Roger Lynn]

Package: postgrey
Version: 1.32-6.1
Severity: normal

On Tue, 4 Jan 2011 13:21:22 +, Antonio Radici anto...@dyne.org wrote:
 thanks for your bug report, the exim user experience can definitely
 being improved, this will be fixed in the next upload (1.33-2).

Was this change ever applied to the package?

Thanks,

Roger

-- System Information:
Debian Release: 6.0.3
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 
'stable'), (150, 'testing')
Architecture: i386 (i686)

Kernel: Linux 2.6.32-5-686 (SMP w/1 CPU core)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages postgrey depends on:
ii  adduser3.112+nmu2add and remove users and groups
ii  debconf [debconf-2.0]  1.5.36.1  Debian configuration management sy
ii  libberkeleydb-perl 0.42-1~squeeze1   use Berkeley DB 4 databases from P
ii  libnet-dns-perl0.66-2Perform DNS queries from a Perl sc
ii  libnet-server-perl 0.97-1An extensible, general perl server
ii  perl   5.10.1-17squeeze2 Larry Wall's Practical Extraction 
ii  ucf3.0025+nmu1   Update Configuration File: preserv

Versions of packages postgrey recommends:
ii  exim44.72-6+squeeze2 metapackage to ease Exim MTA (v4) 
ii  libdigest-sha1-perl  2.13-1  NIST SHA-1 message digest algorith
pn  libnet-rblclient-perlnone  (no description available)
ii  libparse-syslog-perl 1.10-1  Perl module for parsing syslog ent

postgrey suggests no packages.

-- debconf information:
  postgrey/1.32-3_changeport:



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