Bug#819342: More brokenness in date(1) around DST

2024-03-31 Thread Andras Korn
Hi,

my timezone is CEST; we switched from CET today.

% TZ=Europe/Budapest LC_TIME=C date --date 'tomorrow 2:30'
date: invalid date ‘tomorrow 2:30’

2:30 would be invalid today (2:00am became 3:00am), but it exists tomorrow, and 
date(1) can print that date if I request it in a different way:

% TZ=Europe/Budapest LC_TIME=C date --date 'now+10 hours+30 minutes'
Mon Apr  1 02:30:51 CEST 2024

This also works:

% TZ=Europe/Budapest LC_TIME=C date --date @1711931400
Mon Apr  1 02:30:00 CEST 2024

Best regards,

András

-- 
To shoot a mime, do you use a silencer?



Bug#1051187: [Pkg-zfsonlinux-devel] Bug#1051187: Avoid building module for kernels that have appropriate zfs-modules- package installed

2024-01-05 Thread Andras Korn
On Fri, Jan 05, 2024 at 07:04:02AM +, 陈 晟祺 wrote:

Hi,

> > zfs-dkms is the failsafe in case the zfs-modules- package is 
> > *not* installed
> > (for example, because this is the first slow box I'm installing this kernel 
> > or this version of
> > zfs-dkms on and I don't yet have a corresponding zfs-modules package).
> 
> Let's imagine you install modules pkg first, then dkms pkg, which skips 
> building because you have
> "same" modules installed. After some days you accidentally uninstalled the 
> modules pkg, then how
> would the dkms pkg know and start the building? There is no such mechanism 
> according to my knowledge.

I'd like to start by saying that installing a zfs-modules- 
package is something only few people would probably do, people who have good 
reasons for going off the beaten path.

I submit that it's not unreasonable to expect such people to be extra careful 
and be aware of the risks inherent in what they are doing.

That said, I suppose a dpkg trigger could be used; or the postrm script of the 
zfs-modules- package could trigger the module build if zfs-dkms 
is installed. But frankly, I'm a great believer in allowing people to shoot 
themselves in the foot if they so desire. Expert features (which this would be) 
don't call for nanny automation.

> Even though such mechanism can be implemented by dkms, let's dig deeper into 
> details: how would dkms
> know that your prebuilt version and dkms source files are "the exact same" 
> and decide to skip? Designing
> such a mechanism would be either cumbersome for developers, or confusing for 
> users, I suppose.

I don't think it needs to do that. If the zfs-modules- package 
is installed, that means the admin is taking care of things.

If they have outdated kernel modules installed, it's their problem and not up 
to dkms or zfs-dkms maintainers to fix for them. You don't have to do 
everything for everyone.

I'd say it would be sufficient to document that installing a 
zfs-modules- package is not officially supported, and has the 
following consequences:

 1. zfs-dkms won't build a new module for ;
 2. if you subsequently remove zfs-modules-, you'll be left 
without a zfs module for  unless you trigger a zfs-dkms build 
yourself.

FWIW, you could also look at it from a green angle: building the modules when 
it's not necessary consumes extra electricity and is thus wasteful.

Best regards,

András

-- 
  I break into song if I can't find the key.



Bug#1054537: Squid 6.3: multiple vulnerabilities, patches available

2023-10-25 Thread Andras Korn
Package: squid
Version: 6.3-1
Severity: grave
Tags: security patch
X-Debbugs-Cc: Debian Security Team 

Hi,

https://wid.cert-bund.de/portal/wid/securityadvisory?name=WID-SEC-2023-2725 
links to a bunch of squid advisories, three of which have CVSS scores of 9+:

https://github.com/squid-cache/squid/security/advisories/GHSA-2g3c-pg7q-g59w
https://github.com/squid-cache/squid/security/advisories/GHSA-phqj-m8gv-cq4g
https://github.com/squid-cache/squid/security/advisories/GHSA-543m-w2m2-g255
https://github.com/squid-cache/squid/security/advisories/GHSA-j83v-w3p4-5cqh

Squid 6.4 includes the fix; patches for 6.3 are provided, but don't apply 
cleanly to the Debian sources.

Please package a non-vulnerable version ASAP.

Thanks!

András

-- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (350, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Init: runit (via /run/runit.stopit)
LSM: AppArmor: enabled

-- 
   Computers are not intelligent. They only think they are.



Bug#1053358: Breaks if user-defined zfs properties contain whitespace

2023-10-03 Thread Andras Korn
On Mon, Oct 02, 2023 at 04:00:57PM -0400, Michael Jeanson wrote:

Hi,

> Can you open a bug upstream? I would prefer to go with a fix approved by 
> upstream.

Sure, will do.

> Also I'm not sure I understand under which circumstances the content of
> '$value' could be controlled by an 'adversary'? Can you explain shortly what
> would be an exploitation scenario you envision?

It doesn't have to be an adversary; you could also have some free-text comment 
in a zfs user property that, if passed to a shell unescaped, does something you 
don't want. My examples were perhaps extreme.

That said, at least two feasible scenarios exist:

1. the admin could be delegating the permission to set properties to users 
(using zfs allow), who would then potentially be adversaries. If "userprop" is 
delegated, the user can create their own free-text properties.

2. you could be working with a zfs pool created by an adversary (e.g. as part 
of a forensic examination).

András

-- 
Crawlers never stumble.



Bug#1053358: Breaks if user-defined zfs properties contain whitespace

2023-10-02 Thread Andras Korn
OK, that quick fix will work for whitespace but still break on apostrophes.

How about using the escapeshellparam sub? 
https://github.com/jimsalterjrs/sanoid/blob/61000c9da2f8762424ba2de8a49abb1b7ec5154d/syncoid#L2070

Or, better yet, replace that sub with this: 
https://metacpan.org/dist/String-ShellQuote/source/ShellQuote.pm (why reinvent 
the wheel?).

András

-- 
  Minél távolabbról nézzük, annál messzebbről látjuk.



Bug#1053358: Breaks if user-defined zfs properties contain whitespace

2023-10-02 Thread Andras Korn
Package: sanoid
Version: 2.2.0-1
Severity: important
Tags: upstream patch

Hi,

line 496 of syncoid reads

$recvoptions .= " -o $key=$value";

this string is then apparently passed to a shell, which will split $value into 
words on whitespace, causing the zfs command line to become invalid at best and 
do something nasty at worst (think e.g. "zfs set foo='; zpool destroy tank'" or 
"zfs set foo='$(cat /path/to/secret/file)'" -- I haven't determined whether 
these would "work" but they might).

The following looks like a valid quick fix, but I don't know enough perl to be 
sure:

$recvoptions .= " -o $key='''$value'''";

Justification for severity 'important': this is serious (potentially security 
relevant) breakage but it doesn't affect everyone.

András

-- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (350, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=hu_HU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8
Init: runit (via /run/runit.stopit)

sanoid recommends no packages.

sanoid suggests no packages.

-- 
 I've often asked myself what kind of idiot makes up taglines, and now I know.



Bug#1036095: freerdp2-x11: Compile with Kerberos support

2023-09-25 Thread Andras Korn
Hi,

I've tried a kerberos-enabled build of freerdp2; it didn't actually work. I 
asked the freerdp people in #freerdp on irc.oftc.net and they said to use 
FreeRDP3:

14:49 -> hi, I'm trying to use kerberos authentication to connect to a Windows 
server using xfreerdp (compiled with gssapi support); I can see it request a 
kerberos ticket successfully, but then authentication fails with 
"[ERROR][com.winpr.sspi.Kerberos] - Init GSS security context failed : can't 
use Kerberos" and "[WARN][com.winpr.sspi] -  InitializeSecurityContextA status 
SEC_E_INTERNAL_ERROR [0x80090304]" (also "NLA begin failed") -- what could be 
wrong?
14:50 < hardening2[m]> switch to FreeRDP3 (master)
14:51 < hardening2[m]> it's not working with freerdp2

Since FreeRDP3 appears to be in late beta I think it would already be 
appropriate to include it in sid.

Getting the current packaging to work with it doesn't look too difficult, only 
some hardwired 2s need to be changed to 3s, and there is this bit in 
debian/rules:

sed -E -i \
-e "s$(xSEDx)$${o}=[^=]+=\. $(xSEDx)$(xSEDx)g;" \
-e "s$(xSEDx) $${o}=[^=]+=\.$(xSEDx)$(xSEDx)g;" \
obj-$(DEB_HOST_GNU_TYPE)/*/*/buildflags.h 
obj-$(DEB_HOST_GNU_TYPE)/*/*/*/buildflags.h 

(There are several buildflags.h files now.)

András

-- 
   To err is human; to forgive, infrequent.



Bug#1051187: [Pkg-zfsonlinux-devel] Bug#1051187: Avoid building module for kernels that have appropriate zfs-modules- package installed

2023-09-04 Thread Andras Korn
On Mon, Sep 04, 2023 at 08:19:45AM +0200, Petter Reinholdtsen wrote:

> [Andras Korn]
> > I have computers that take forever to build kernel modules; therefore,
> > while I have zfs-dkms installed as a failsafe, I also strive to always
> > install zfs-modules- preemptively.
> 
> How do you imagine zfs-dkms should work as a failsafe if it is not built
> when the zfs-modules- package is installed?

That's not the case I need the failsafe for. :)

zfs-dkms is the failsafe in case the zfs-modules- package is 
*not* installed (for example, because this is the first slow box I'm installing 
this kernel or this version of zfs-dkms on and I don't yet have a corresponding 
zfs-modules package).

András

-- 
Need an ark to save two of every species of animal? I noah guy.



Bug#1051187: Avoid building module for kernels that have appropriate zfs-modules- package installed

2023-09-03 Thread Andras Korn
Package: zfs-dkms
Version: 2.1.12-2
Severity: normal

Hi,

I have computers that take forever to build kernel modules; therefore, while I 
have zfs-dkms installed as a failsafe, I also strive to always install 
zfs-modules- preemptively.

Unfortunately, the zfs-dkms postinst still causes the zfs modules to be built 
for kernels that already have the exact same zfs modules provided by the 
installed zfs-modules package.

I don't know enough about dkms to be able to suggest where a check that avoids 
this build belongs; please feel free to reassign this bug to the dkms package 
if that's more appropriate.

Thanks

András

-- System Information:
Debian Release: trixie/sid
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (350, 'unstable'), (1, 'experimental')
merged-usr: no
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.4.0-3-amd64 (SMP w/8 CPU threads; PREEMPT)
Init: runit (via /run/runit.stopit)

-- 
 I'd love to go out with you, but there is a disturbance in the Force.



Bug#1051186: *-dkms packages shouldn't fail postinst if all modules to be installed already exist in identical versions

2023-09-03 Thread Andras Korn
Package: dkms
Version: 3.0.11-3
Severity: normal

Hi,

I have computers where I install both zfs-dkms and sometimes 
zfs-modules- packages.

When zfs-modules- is installed, zfs-dkms fails postinst:

[...]
zzstd.ko:
Running module version sanity check.
Module version 1.4.5a-2.1.12-2 for zzstd.ko
exactly matches what is already found in kernel 6.4.0-3-amd64.
DKMS will not replace this module.
You may override by specifying --force.
Error! Installation aborted.
dpkg: error processing package zfs-dkms (--configure):
 installed zfs-dkms package post-installation script subprocess returned error 
exit status 6

I think that when all modules to be installed exactly match the ones already in 
place, that shouldn't result in a failure.

In case you wonder why I'm doing this: these computers take forever to build 
kernel modules, so whenever possible, I install pre-built modules and want to 
keep dkms only as a failsafe, to make sure the zfs modules are in place before 
I reboot (because they're needed for booting).

I'm filing the bugreport against dkms because it contains these lines of code 
(around line 800):

if [[ ! "$force" ]]; then
# if the module has neither version nor srcversion/checksum, check 
the binary files instead
local verinfo="$(get_module_verinfo "${dkms_module}")"
if [[ "$(echo "$verinfo" | tr -d '[:space:]')" ]] || diff 
"${kernels_module}" "${dkms_module}" &>/dev/null; then
echo $"Module version $(echo "$verinfo" | head -n 1) for 
$4${module_suffix}" >&2
echo $"exactly matches what is already found in kernel $1." >&2
echo $"DKMS will not replace this module." >&2
echo $"You may override by specifying --force." >&2
return 1
fi
fi

I believe that "return 1" should be a "return 0" because there is no failure. A 
binary with the exact same version and/or contents is already installed; that's 
exactly the outcome dkms was asked to achieve.

I'll file a separate bug against zfs-dkms asking to avoid building the module 
for kernels for which an appropriate zfs-modules- package is installed.

András

-- System Information:
Debian Release: trixie/sid
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (350, 'unstable'), (1, 'experimental')
merged-usr: no
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.4.0-3-amd64 (SMP w/8 CPU threads; PREEMPT)
Init: runit (via /run/runit.stopit)

-- 
  Give a man a fire and he's warm for a day, but set
  fire to him and he's warm for the rest of his life.



Bug#1051138: 3.0pl1-166 introduced undeclared dependency on usrmerge

2023-09-03 Thread Andras Korn
Package: cron
Version: 3.0pl1-174
Severity: important

Hi,

with /bin gone from the default PATH in /etc/crontab (due to #1042894), cron 
will no longer find run-parts(8), which is in /bin, unless /bin is merged into 
/usr/bin.

I ran into this on dozens of systems that were upgraded to sid semi-regularly 
but have existed for several years. Cron was suddenly unable to run hourly, 
daily, weekly and monthly jobs, which would all have involved run-parts, 
effectively breaking cron on these systems almost completely (which is my 
justification for the "important" severity).

I believe it would make sense to either

 1. add an explicit dependency on usrmerge; or

 2. modify the default crontab to at least invoke run-parts itself with its 
full path (although this may still lead to breakage if the jobs themselves 
assume /bin and /sbin are in the PATH); or

 3. revert the change to the default PATH; or

 4. somehow make the PATH dependent on whether /bin is a symlink to /usr/bin.

I only include the fourth option for completeness; I don't think it would be a 
good idea.

András

-- System Information:
Debian Release: trixie/sid
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (350, 'unstable'), (1, 'experimental')
merged-usr: no
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.4.0-3-amd64 (SMP w/8 CPU threads; PREEMPT)
Init: runit (via /run/runit.stopit)

-- 
   To be or to not be, that is the split infinitive.



Bug#1050217: Better coexistence with libpam-tmpdir

2023-08-22 Thread Andras Korn
Package: tmpreaper
Version: 1.6.17
Severity: normal

Hi,

having libpam-tmpdir installed results in PAM creating a 
/tmp/user/ directory for every user when they start a 
session, setting TMP and TMPDIR to this directory.

Long-running processes such as web applications started e.g. via sudo -u 
someuser may end up with their TMP set to /tmp/user/, which is 
desirable because it makes /tmp attacks against them harder.

However, if they don't use their individual tmp directories frequently, 
tmpreaper with its default settings may delete them, breaking the application.

I suggest that the default configuration be changed thusly:

TMPREAPER_PROTECT_EXTRA='/tmp/user/[0-9]*'
TMPREAPER_DIRS='/tmp/. /tmp/user/*/.'

This would (I hope) cause the per-user tmp directories themselves to be left 
alone but their contents cleaned up.

Thanks

András

-- System Information:
Debian Release: trixie/sid
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (350, 'unstable'), (1, 'experimental')
merged-usr: no
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Locale: LANG=en_US.UTF-8, LC_CTYPE=hu_HU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8
Init: runit (via /run/runit.stopit)
LSM: AppArmor: enabled

Versions of packages tmpreaper depends on:
ii  debconf [debconf-2.0]  1.5.82
ii  libc6  2.37-7
ii  libmount1  2.38.1-5devuan1+b1

tmpreaper recommends no packages.

tmpreaper suggests no packages.

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

-- debconf information excluded



Bug#1039740: Please ship slapm-ppm

2023-06-28 Thread Andras Korn
Package: slapd-contrib
Version: 2.5.13+dfsg-5
Severity: wishlist

Hi,

please build and ship contrib/slapd-modules/ppm. It greatly enhances the 
functionality of the password policy overlay by allowing the user to implement 
semi-complex password policies (such as "have characters from at least 4 of 
these 5 character classes").

Thanks!

András

-- 
Who is General Failure, and why is he reading MY disk??



Bug#1038158: Uses /etc/nullmailer/../mailname instead of /etc/mailname; misleading message

2023-06-21 Thread Andras Korn
On Wed, Jun 21, 2023 at 10:18:13AM +0300, David Bremner wrote:

> > I began using a revision tracking system for some configfiles. This
> > involved replacing /etc/nullmailer with a symlink to a directory
> > within the local working copy.
> 
> I don't know if it's practical for you, but as a workaround etckeeper
> works fine with the current nullmailer, since it doesn't use symlinks.

Thanks for the suggestion, but no, it's not practical.

> > Also, printing messages to /dev/console isn't terribly useful in the
> > case of remote headless servers.
> 
> I don't (yet) see what is explicitely opening /dev/console. How are you
> starting nullmailer? For example, I would expect systemd to capture
> stdout. Although README.Debian mentions /dev/console, this patching to
> change upstream's logging is no longer done in the current version of
> nullmailer.

I'm running nullmailer-send via runit. stdout is definitely a pipe (and so is 
stderr); somewhere it opens /dev/console explicitly.

My runit 'run' script for nullmailer is:

--- >8 ---
#!/bin/sh
exec 2>&1
if [ ! -c /var/spool/nullmailer/trigger ]; then 
   
rm -f /var/spool/nullmailer/trigger 
   
mkfifo /var/spool/nullmailer/trigger
   
fi  
   
chown mail:root /var/spool/nullmailer/trigger
chmod 0622 /var/spool/nullmailer/trigger
exec chpst -u mail nullmailer-send
--- 8< ---

In other instances, I start nullmailer-send from cron to process its queue 
every once in a while, using this script:

--- >8 ---
#!/bin/sh
trigger=/var/spool/nullmailer/trigger
[ -r /etc/nullmailer/pausetime ] || exit 0
[ -x /usr/sbin/nullmailer-send ] || exit 0
if [ "$(cat /etc/nullmailer/pausetime)" = "0" ]; then
rm -f /service/nullmailer-send
if [ ! -c $trigger ]; then  
  
[ -e $trigger ] && rm -f $trigger   
 
mkfifo $trigger 
  
fi  
   
chown mail:root $trigger
chmod 0622 $trigger
exec chpst -L /var/lock/nullmailer-oneshot.lock nullmailer-send -s 
>/dev/null 2>&1
else
exit 0
fi
--- 8< ---

> > 1. in order to avoid violating the principle of least surprise, don't 
> > disregard /etc/nullmailer/me. If it's there, the admin put it there for a 
> > reason.
> 
> I would have to go back and read the (ancient) bugs for why this change
> was made in the first place. I guess allowing /etc/nullmailer/me to
> override /etc/mailname will break some existing configurations.

I suppose that's possible; but since nullmailer has been printing warnings 
about this file all this time, it would be my guess that not many people have 
it.

> > 2. if /etc/nullmailer/me doesn't exist, default to "/etc/mailname",
> > not "/etc/nullmailer/../mailname".
> 
> Offhand I don't understand why it doesn't use an absolute path there. Maybe 
> someone (tm) can change the appropriate line in hostname.cc and test the 
> result.

Well, that at least is easy. In 
debian/patches/0005-Provide-for-etc-mailname.patch, you have:

diff --git a/lib/hostname.cc b/lib/hostname.cc
index 5a7bde2..ac94ffc 100644
--- a/lib/hostname.cc
+++ b/lib/hostname.cc
@@ -24,6 +24,7 @@
 #include "configio.h"
 #include "hostname.h"
 #include "canonicalize.h"
+#include "fdbuf/fdbuf.h"
 
 mystring me;
 mystring defaulthost;
@@ -33,7 +34,13 @@ void read_hostnames()
 {
   int nome;
   nome = 0;
-  if (!config_read("me", me)) {
+  // introduced as bugfix for #120660, #157259, #158412 in 1.00RC5-17;
+  // still there since it's more appropriate for Debian systems
+  mystring disregard;
+  if (config_read("me", disregard)) {
+ferr << "Warning: On Debian systems, nullmailer's 'me' is disregarded; 
please use '/etc/mailname' instead." << endl;
+  }
+  if (!config_read("../mailname", me)) {
 nome = 1;
 me = "me";
   }
diff --git a/test/functions.in b/test/functions.in
index bc62b67..9f8c922 100644
--- a/test/functions.in
+++ b/test/functions.in
@@ -154,6 +154,6 @@ EOF
 
 export PATH=/bin:/usr/bin:/usr/local/bin
 rm -f $SYSCONFDIR/*
-echo f.q.d.n >$SYSCONFDIR/me
+echo f.q.d.n >$SYSCONFDIR/../mailname
 echo q.d.n >$SYSCONFDIR/defaultdomain
 set -e

I do

Bug#1038158: Uses /etc/nullmailer/../mailname instead of /etc/mailname; misleading message

2023-06-16 Thread Andras Korn
Package: nullmailer
Version: 1:2.2-3+b1
Severity: normal

Hi,

I began using a revision tracking system for some configfiles. This involved 
replacing /etc/nullmailer with a symlink to a directory within the local 
working copy.

I noticed that locally generated mail was suddenly referencing literal 
"defaulthost".

I tried to create /etc/nullmailer/me with the correct hostname in it, but this 
didn't help. I attached strace to cron in an attempt to see what was going on 
and found this:

openat(AT_FDCWD, "/etc/nullmailer/me", O_RDONLY) = 
3/etc/nullmailer/me>
read(3/etc/nullmailer/me>, 
"my-correct-hostname-here\n", 4096) = 27
close(3/etc/nullmailer/me>) = 0  
write(2>, "Warning: On Debian systems, nullmailer's 'me' 
is disregarded; please use '/etc/mailname' instead.\n", 98) = 98
getuid()= 0
geteuid()   = 0
openat(AT_FDCWD, "/etc/nullmailer/../mailname", O_RDONLY) = -1 ENOENT (No such 
file or directory)

So, while nullmailer prints a message instructing me to fill /etc/mailname, it 
doesn't actually use /etc/mailname but /etc/nullmailer/../mailname, which 
doesn't necessarily exist and isn't necessarily the correct file if 
/etc/nullmailer is a symlink.

Also, printing messages to /dev/console isn't terribly useful in the case of 
remote headless servers.

I suggest the following changes:

1. in order to avoid violating the principle of least surprise, don't disregard 
/etc/nullmailer/me. If it's there, the admin put it there for a reason.

2. if /etc/nullmailer/me doesn't exist, default to "/etc/mailname", not 
"/etc/nullmailer/../mailname".

3. if these two changes are made, the message becomes unnecessary and can be a 
simple README.Debian item.

4. if you must print a message, log it to syslog instead of (or, if you insist, 
in addition to) writing it to /dev/console. However, can't writing to 
/dev/console block e.g. due to flow control on the terminal device? If so, I'd 
leave /dev/console alone.

Best regards,

András

-- 
 Mishearing the voices in his head, our hero wonders how he's supposed
  to kill the mall.



Bug#1034363: firefox: Non-default fonts no longer work

2023-04-14 Thread Andras Korn
Hi,

possibly related: since upgrading to 112.0, some custom fonts set by websites 
are no longer rendered.

For example, on https://www.teletal.hu/etlap/16, there is supposed to be a 
leftmost column of row labels in the table, saying "RE1", "RE2", "A1", "A2" and 
so on.

If the setting "Allow pages to choose their own fonts, instead of your 
selections above" (browser.display.use_document_fonts) is enabled, these labels 
are invisible (you can select them and their space will be highlighted, but the 
letters are not rendered).

Disabling use_document_fonts causes the labels to be rendered correctly (in the 
font chosen in the preferences).

The same problem occurs with most text on facebook.com and messenger.com as 
well.

I was able to replicate this with a blank new browser profile, using firefox 
112.0-1 and up to date sid as of today.

András

-- 
 I ? Unicode.



Bug#1022837: /lib/runit/run_sysv_scripts uses wrong test to skip initscripts

2023-03-28 Thread Andras Korn
On Tue, Mar 28, 2023 at 01:10:36AM +0200, Lorenzo wrote:

Hi,

> Please follow up and let me know if my idea would solve this issue or at 
> least improve the situation from your point of view:
> > 
> > Checking for /etc/sv/$name and skipping initscripts if those directories 
> > exist is wrong for two reasons:
> > 
> >  1. /etc/sv/$name may not be symlinked into /etc/service (false positive);
> > 
> >  2. /etc/service may contain a symlink to a service directory for this 
> > service that is elsewhere in the filesystem, not in /etc/sv (false 
> > negative).
> > 
> > As a minimum, I suggest the following: instead of /etc/sv/$name, check for 
> > /etc/service/$name (and $name-daemon if necessary), and not with "-d" but 
> > "-L" (because when running rcS.d, the target of the symlink may only appear 
> > later, for example when a new filesystem is mounted).
> 
> I propose the following:
> 
> * patch runit-helper, update-service and /lib/runit/trigger_sv so that every 
> (package provided) runit service is always represented in /etc/service/, 
> either with a foo symlink (enabled) or with a .foo symlink (disabled).

OK, this works (although I don't see why it's necessary), as long as nothing 
gets confused by the existence of both symlinks. For example, under this 
scheme, I may have:

/service/ssh -> /some/dir/where/I/keep/my/services/ssh  # created "manually"
/service/.ssh -> /etc/sv/ssh# created during 
container provisioning to prevent the ssh package from installing its version 
of the service (otherwise it creates /etc/service/ssh/ssh)

If there is potential for confusion, then a mechanism to delete the .ssh 
symlink if/when the plain ssh symlink is present would also be needed.

>   This way I (as a packager) can test /etc/service/ to know if a runscript 
> exists in /etc/sv/.

You can, but I'm not sure I see why you have to. The /etc/sv location is not 
special per se; why does it matter whether there is anything there in 
particular?

>   For users that have their own runscripts collection somewhere in the 
> filesystem: they will enable their services by creating the foo symlink, and 
> they can have the sysv emulation skip certain services (let's say a bar 
> service) by creating a /etc/service/.bar symlink.

That's a needless extra hoop to jump through. When deciding whether to skip 
invoking /etc/init.d/bar, why is it better to check for the existence of 
"/etc/service/.bar" than "/etc/service/bar"? The latter needs to exist anyway, 
because that's what will cause runit to start the service.

>   This would also prevent runit package (and runit-helper) to enable the bar 
> service, if any /etc/sv/bar exists, because the logic in runit-helper and 
> sv_trigger only test if the symlink (or dot-symlink) exists, but it doesn't 
> care where it points.

Again, to me it seems that the existence of /etc/service/bar should be 
sufficient. If it exists, the service is enabled. If it needs to be disabled in 
a way that it can be re-enabled later, you can rename the existing bar symlink 
to ".bar", regardless of where it points.

>   In any case runit/runit-helper only creates and remove links in the 
> /etc/runit/runsvdir/default directory, so if you point runsvdir to another 
> directory runit package doesn't enable or disable anything for you.

Perhaps it should be called debian-default; but it's good to know that using a 
differently-named runsvdir is a way of opting out of much of the 
nanny-automation I find so annoying. :)

> * turn the run_sysv_scripts into a runit service that test for 
> /etc/service/$name. Two main reason for this:

This needs to be thought through carefully (it would need to only run once, but 
finish before other services are started -- for example, it could do a 
runsvchdir in ./finish).

>   1. users can disable it, or change it at their will, while any change into 
> /lib/runit/run_sysv_scripts is overwritten by the package, so users are 
> forced to change stage 2 and create their own version of the script

You could also achieve this by preferring /etc/runit/lib/run_sysv_scripts if it 
is executable, and only running /lib/runit/run_sysv_scripts if not. Even more 
complex setups would also be possible, with /lib/runit/run_sysv_scripts relying 
on shell functions that a user-supplied sourced file could override, but I 
think that would go too far.

>   2. when runit services are mixed with sysv scripts in the start sequence, 
> the run_sysv_scripts can be RC-buggy, see #1024969 [1] for an example

Yeah, that's a hard problem to solve cleanly.

Maybe you just shouldn't ship (or enable by default) runit services that 
initscript-based stuff frequently depends on. I'm not sure how much else there 
is, other than dbus.

Alternatively, you could ship a one-shot runit service that depends on the dbus 
service and that invokes all initscripts that declare a dependency on dbus... 
Far from my idea of clean.

I also have another idea but it's so complex th

Bug#1031742: Please make reboot command configurable

2023-02-21 Thread Andras Korn
Package: unattended-upgrades
Version: 2.9.1+nmu3
Severity: wishlist

Hi,

not all flavours of shutdown(8) support a time argument; for example, runit's 
only supports 'now' or no time.

When unattended-upgrades tries to schedule a reboot on runit systems, 
shutdown(8) prints an error, causing unattended-upgrades to become sad.

I'd like to provide my own mechanism for scheduling reboots (e.g. via at(1)). 
Please add a config tunable for this.

Thanks!

András

-- System Information:
Init: runit (via /run/runit.stopit)

-- 
 Keves, mint terdkalacsban a mazsola.



Bug#1030747: Acknowledgement (fuser(1) tries to use statx() which is not available on older kernels and prints misleading error when it can't)

2023-02-20 Thread Andras Korn
fwiw, psmisc 23.5-3 still works even if the kernel doesn't support statx().

The changelog for 23.6 says "fuser: Use modern statn where possible", but it's 
regrettably also used where not possible.

András

-- 
Is 6 afraid of 7, 'cause 7 8 9?



Bug#1031295: pcp fails to install without systemd

2023-02-16 Thread Andras Korn
Hi,

it seems to me that in postinst, instead of

if $do_systemd
then
systemctl start pmcd.service >/dev/null
systemctl start pmlogger.service >/dev/null
elif which invoke-rc.d >/dev/null 2>&1
then
invoke-rc.d pmcd start
invoke-rc.d pmlogger start
else
/etc/init.d/pmcd start
/etc/init.d/pmlogger start
fi

You could just do

service pmcd start
service pmlogger start

Additionally, I think a case can be made for ignoring failures to start these 
services in postinst. If the package fails to configure, that'll break 
unattended-upgrades which will then also not install security updates.

András

-- 
   A hangover: the wrath of grapes.



Bug#1030747: fuser(1) tries to use statx() which is not available on older kernels and prints misleading error when it can't

2023-02-06 Thread Andras Korn
Package: psmisc
Version: 23.6-1
Severity: normal

Hi,

fuser(1) will call statx():

statx(0>, "/", AT_STATX_DONT_SYNC|AT_NO_AUTOMOUNT, 
STATX_TYPE|STATX_INO, 0x7fffb96603a0) = -1 ENOSYS (Function not implemented)

which is not avilable on kernels before, I think, 4.11.

When that fails, fuser(1) prints

"Cannot find socket's device number.
Cannot stat /: Invalid argument"

which is not helpful in finding out what's wrong.

I realize that Debian doesn't ship such old kernels anymore, but I think it 
would be desirable to be more backwards compatible, and, failing that, to print 
an error message that actually explains what went wrong.

To me it looks like it would be best to fall back to the older stat* calls if 
statx() is not available at runtime.

A point could also be made to refuse installation/upgrade on kernels older than 
4.11, or kernels that don't have statx, unless the user creates some flag file 
to override this (e.g. because they don't need fuser(1)).

Best regards,

András

-- System Information:
Debian Release: sid
  APT prefers unstable
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.337-vs2.3.9.13 (SMP w/24 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=hu_HU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8
Shell: /bin/sh linked to /bin/dash
Init: runit (via /run/runit.stopit)
LSM: AppArmor: enabled

Versions of packages psmisc depends on:
ii  libc6  2.36-8
ii  libtinfo6  6.4-2

psmisc recommends no packages.

psmisc suggests no packages.

-- no debconf information

-- 
  I've always wanted to change my legal name to ';DROP DATABASE; -- '
and see what kind of havoc ensues.



Bug#1030349: gdbm module is missing from zsh package again

2023-02-03 Thread Andras Korn
Package: zsh
Version: 5.9-3
Severity: normal
Tags: patch

Hi,

this was last reported as #951457.

Apparently this change (from zsh changelog):

2020-01-06  Daniel Shahaf  

* 45213: README, configure.ac: Make --enable-gdbm default to
false, rather than default to true with an unavoidable warning.

... caused zsh to be build without gdbm support unless --enable-gdbm were 
passed to configure.

Please add --enable-gdm to debian/rules: "CONFIGFLAGS += --enable-gdbm"

Thanks.

András

-- 
  Knowledge is power - if you know it about the right person.



Bug#1030225: /etc/runit/2 assumes it runs in an environment that can mount filesystems

2023-02-02 Thread Andras Korn
On Thu, Feb 02, 2023 at 12:27:04AM +0100, Lorenzo wrote:

Hi,

> > /etc/runit/2 ships with this snippet:
> > 
> > mkdir -p /run/runit/supervise
> > mkdir -p /run/runit/sv
> > mount -t tmpfs -o size=20M,mode=0755 runtimesv /run/runit/sv
> > cp -a /etc/sv/* /run/runit/sv/  #TODO do this with
> > 'CPSV_DIR=/run/runit/sv cpsv --sync'
> > 
> > If runit is used in an unprivileged container,
> with runit you mean runit as init or simply respawn runsvdir via stage
> 2?

Both, but in my specific case, runit-as-init.

> The mount can be moved to stage 1, where other mount invocations already
> happen; however this will cause a relevant difference when runit is
> used as init vs when only stage 2/runsvdir is run..

I don't think it makes sense to move it, but it *would* make sense to provide a 
way to turn this off.

> > mount -t tmpfs -o size=20M,mode=0755 runtimesv /run/runit/sv
> the idea is to have a copy of services there and to run services there,
> like /etc/service points to /etc/runit/runsvdir/deafult.run that
> contains links to directories in /run/runit/sv/

But why must these directories be on a separate fs under /run? Why can't they 
just be wherever it suits the administartor to put them?

> without that mount line:
> Problem 1: run is mounted 'noexec', so each runsv fails

This is true, but, to me, all the more reason not to try to put executable 
stuff under /run. :)

> Problem 2: there are mechanism (cpsv) that copy services in /run and by 
> limiting the size I want to avoid that an abuse of such mechanism could 
> result in eating all space in /run mount (very unlikely but still..)

I never quite got the point of cpsv either, so thanks for explaining it below.

> Reasons why I'm thinking of running services in /run/runit/sv/ :
> 
> A) anything in /etc/sv is a conffile, so special care is needed when
>   upgrade happens to detect and not overwrite local changes. That is
>   handled by dpkg or ucf, but they work on files, while a service for
>   runit is a directory. I think ideally the entire service should be
>   considered locally modified if the run file (or finish, or control/*
>   and probably also log/run) has local changes.

I don't agree. I don't think it's important not to install a new 'finish' 
script if 'run' was locally modified by 'finish' wasn't.

On the other hand, the more complexity you add to the service scripts, the more 
dangerous it will be to upgrade them piecemeal, so you have a point there. My 
reaction would be to try and avoid the complexity instead of increasing it by 
adding a new indirection layer.

I think systemd gets this particular thing more or less right, with shipping 
distribution files (which are not conffiles) in /lib, but allowing local files 
with the same name in /etc to override them.

I think the way you could do this in runit would be to ship your services in 
/lib/runit/sv, but have /etc/sv directories too, where /etc/sv/foo/run is, by 
default, a symlink to /lib/runit/sv/foo/run. If the admin wants to customize, 
he can replace the symlink with a file, and if a particular service looks too 
complex to feel good about leaving only half-customized, he can replace all 
symlinks with files.

>   I can think of many ways to break a service by retaining the local
>   version of a run file while finish or control/* are changed/upgraded.

So can I, but most of those start with making run, finish or control/* more 
complex (and thus fragile) than necessary.

I see runit as a system that is intended to be robust in its simplicity; 
instead of trying to be clever and generic with service scripts, I'd like to 
keep them straightforward.

On the whole, I also don't think runit needs to ship a plethora of service 
scripts that invite any kind of customization. How many users are there, and 
how many of them need or want the package to ship services? (I know I'd be 
perfectly happy if the runit and runit-init packages only contained the runit 
framework and I had to supply all service directories myself.)

> B) related to A, but different problem: think of what happens if a
>   foo service crashes while dpkg is upgrading (file by file) the service
>   directory: the automatic restart performed by runsv can exec a mix of
>   old and new files inside foo directory, with unexpected results like
>   in A, but temporary (only during the upgrade).

Noted, but I still don't think overengineering is the way to address this. If 
service scripts were mostly minimal, changes wouldn't have to happen frequently 
(I have some services scripts I wrote 15 years ago that still work perfectly). 
Instead of adding more and more complexity to address rare scenarios (and 
likely introduce additional brittleness that will break in other unexpected 
ways that may not be immediately obvious), I'd prefer to retain simplicity.

>   Ideally the entire service directory should be updated atomically but
>   that requires to address the old.directory with a symlink, creating a
>   new.directory o

Bug#1030225: /etc/runit/2 assumes it runs in an environment that can mount filesystems

2023-02-01 Thread Andras Korn
Package: runit
Version: 2.1.2-53
Severity: minor

Hi,

/etc/runit/2 ships with this snippet:

mkdir -p /run/runit/supervise
mkdir -p /run/runit/sv
mount -t tmpfs -o size=20M,mode=0755 runtimesv /run/runit/sv
cp -a /etc/sv/* /run/runit/sv/  #TODO do this with 'CPSV_DIR=/run/runit/sv cpsv 
--sync'

If runit is used in an unprivileged container, the mount command may fail. 
Currently this is just a cosmetic problem (/lib/runit/sv will not be a separate 
filesystem and an error will be printed), but please don't start depending on 
this mount succeeding.

Please also provide some reasoning (e.g. in a README.Debian file) why you're 
doing this at all, what the motivation is.

-- 
A police officer just knocked on my door and told me my dogs are chasing people 
on bikes. That’s ridiculous. My dogs don’t even own bikes.



Bug#1030224: Inverted test for /etc/runit/no.emulate.sysv in /etc/runit/2

2023-02-01 Thread Andras Korn
Package: runit
Version: 2.1.2-53
Severity: normal
Tags: patch

Hi,

/etc/runit/2 ships with this snippet:

if [ "$runsv_dir" != solo ] || [ ! -e /etc/runit/no.emulate.sysv ]; then
/lib/runit/async-timeout /lib/runit/run_sysv_scripts 
'/etc/rc2.d'
fi

This means that the rc2.d scripts are run if EITHER $runsv_dir does not equal 
"solo" OR the file /etc/runit/no.emulate.sysv doesn't exist.

In other words, for rc2.d scripts to be skipped, BOTH of the following 
conditions must be true:

 1. $runsv_dir has to equal solo; AND
 2. /etc/runit/no.emulate.sysv has to exist.

I think that rc2.d should be skipped if /etc/runit/no.emulate.sysv exists, 
regardless of the value of $runsv_dir. This is also what the README suggests:

* /etc/runit/no.emulate.sysv
 Skip all sysv scripts enabled in rc2.d during the boot sequence, even if
 there is no correspondent native runscript in /etc/sv/

(I still also think that /etc/sv is the wrong place to check; the directory 
monitored by runsvdir, e.g. /etc/service, could contain a symlink to a service 
that resides somewhere else, not in /etc/sv/, and the existence of such a 
symlink should also cause the initscript invocation to be skipped.)

For this particular issue in /etc/runit/2, I recommend just replacing the || 
with &&, so the snippet becomes:

if [ "$runsv_dir" != solo ] && [ ! -e /etc/runit/no.emulate.sysv ]; then
/lib/runit/async-timeout /lib/runit/run_sysv_scripts 
'/etc/rc2.d'
fi

András

-- 
   If debugging is removing bugs, then programming must be putting them in.



Bug#1023476: runit: Improve default-syslog check

2022-11-23 Thread Andras Korn
On Wed, Nov 16, 2022 at 02:03:14PM +0100, Lorenzo wrote:

> > > lsof /dev/log >/dev/null || exit 1
> > 
> > I think
> > 
> > fuser /dev/log >/dev/null 2>/dev/null || exit 1
> > 
> > is more efficient, but there is a problem with both approaches: the process 
> > that is listening on /dev/null may be invisible to us, because it may be 
> > running in a different namespace.
> 
> Thanks for the above: I didn't thought about using this service inside a 
> container (when the logger is outside) and I agree it's a nice to have 
> extension (assuming that you mean listening on /dev/log, otherwise I fail to 
> understand what you are talking about)

Yes, sorry, my brain hit a bad sector there. /dev/log of course.

> > The only way to reliably determine whether there is a Unix server listening 
> > on the /dev/log socket is to try to connect to the socket.
> > 
> > One approach I can think of is to use
> > 
> > unixclient /dev/log /bin/true 2>&1 | grep -q '^connect: Protocol wrong type 
> > for socket' || exit 1
> > 
> > This creates a SOCK_STREAM socket and tries to connect it to /dev/log, 
> > which will fail with EPROTOTYPE if there is a listening server (which will 
> > use SOCK_DGRAM) and with ECONNREFUSED if not.
> > 
> > Using unixclient would introduce a semi-esoteric dependency on ucspi-unix, 
> > but it's a tiny package which is a good match for the runit ecosystem 
> > anyway, so maybe it's acceptable.
> > 
> > A more mainstream but much more heavyweight approach would be to use 
> > socat(1) or netcat-openbsd with the -U option.
> > 
> > Alternatively, socklog provides its own socklog-check, which does exactly 
> > what is necessary, but the whole point of trying to detect whether *any* 
> > syslog daemon is running is to avoid having to install a particular one 
> > like socklog, so we probably shouldn't use it.
> > 
> > OTOH, it's such a tiny program, and so unlikely to require changes ever, 
> > you might even ship (a copy of) it as part of the runit package.
> 
> I'm ok with ucspi-unix or socklog-check, but this can happen only after the 
> bookworm release.

How about you make default-syslog/check use socklog-check or unixclient if they 
are available, and fall back to the current heuristics if not? Something like 
this:

#!/bin/sh

# note: only socklog exists as runit service in Debian right now

socklog-check && exit 0

unixclient /dev/log /bin/true 2>&1 | grep -q '^connect: Protocol wrong type for 
socket' && exit 0

fuser /dev/log >/dev/null 2>/dev/null && exit 0

for service in rsyslog socklog socklog-unix syslog-ng busybox-syslogd 
inetutils-syslogd ; do
sv u $service && sv check $service && exit 0
done

exit 1

If socklog-check and unixclient aren't installed, those commands will just fail 
and the script will fall back to the next attempt.

The only way I can see this being worse than the current solution is if 
searching PATH for executables is pathologically slow (e.g. due to an NFS 
outage maybe).

> This bug can probably renamed as "default-syslog: useless inside a 
> container", right ?

I don't think so; that wouldn't be accurate. It's only useless if the syslog 
daemon and the check script run in different namespaces; if they run in the 
same container, it works, and it also fails if check runs on the host and it's 
the syslog daemon that's in the container (this should be rare though).

I'd call it "default-syslog: check for running syslogd not robust" or something.

András

-- 
 Desk: A very large wastebasket with drawers.



Bug#1022172: Bug#1024082: Bug#1022172: /lib/modprobe.d/50-nfs.conf causes initramfs-tools to stop including sunrpc module for nfs

2022-11-18 Thread Andras Korn
On Tue, Nov 15, 2022 at 10:00:43PM +0100, Salvatore Bonaccorso wrote:

Hi,

> > Try something like this in /lib/udev/rules.d/60-nfs.rules:
> > 
> > ACTION=="add", SUBSYSTEM=="module", KERNEL=="sunrpc", \
> >   RUN+="/sbin/sysctl -q --pattern ^sunrpc --system"
> > ACTION=="add", SUBSYSTEM=="module", KERNEL=="rpcrdma", \
> >   RUN+="/sbin/sysctl -q --pattern ^sunrpc.svc_rdma --system"
> > ACTION=="add", SUBSYSTEM=="module", KERNEL=="lockd", \
> >   RUN+="/sbin/sysctl -q --pattern ^fs.nfs.n[sl]m --system"
> > ACTION=="add", SUBSYSTEM=="module", KERNEL=="nfsv4", \
> >   RUN+="/sbin/sysctl -q --pattern 
> > ^fs.nfs.(nfs_callback_tcpport|idmap_cache_timeout) --system"
> > ACTION=="add", SUBSYSTEM=="module", KERNEL=="nfs", \
> >   RUN+="/sbin/sysctl -q --pattern ^fs.nfs --system"
> > 
> > Differently from the original file I tired anchoring the patterns, which 
> > looks more correct to me.
> 
> Thanks, I will try to test this and bring to nfs-utils upstream.
> Michael or Andras, if you can help testing it in your use cases that
> would be helpful.

I don't have a real world test case for this; I don't set any of those sysctls.

Incidentally, busybox sysctl doesn't support --pattern, so if this 
functionality is important, nfs-kernel-server needs to force inclusion of the 
"big" /sbin/sysctl in the initramfs.

András

-- 
 To understand recursion, we must first understand recursion.



Bug#1022103: gdisk: sgdisk produces only errors

2022-11-16 Thread Andras Korn
On Mon, Oct 24, 2022 at 11:18:03AM +0200, Andras Korn wrote:

Hi,

> unfortunately the bug is still not fixed despite the NMU; while sgdisk 
> doesn't print errors anymore, it also doesn't actually perform the requested 
> operations.

I can no longer reproduce the problem. I don't know what happened.

These versions work for me:

ii  gdisk  1.0.9-2.1amd64GPT fdisk text-mode partitioning 
tool
ii  libpopt0:amd64 1.19+dfsg-1  amd64lib for parsing cmdline parameters

András

-- 
   I hope we grow as old as we look.



Bug#1023476: runit: Improve default-syslog check

2022-11-07 Thread Andras Korn
Hi,

> the check could be just something like
>
> lsof /dev/log >/dev/null || exit 1

I think

fuser /dev/log >/dev/null 2>/dev/null || exit 1

is more efficient, but there is a problem with both approaches: the process 
that is listening on /dev/null may be invisible to us, because it may be 
running in a different namespace.

The only way to reliably determine whether there is a Unix server listening on 
the /dev/log socket is to try to connect to the socket.

One approach I can think of is to use

unixclient /dev/log /bin/true 2>&1 | grep -q '^connect: Protocol wrong type for 
socket' || exit 1

This creates a SOCK_STREAM socket and tries to connect it to /dev/log, which 
will fail with EPROTOTYPE if there is a listening server (which will use 
SOCK_DGRAM) and with ECONNREFUSED if not.

Using unixclient would introduce a semi-esoteric dependency on ucspi-unix, but 
it's a tiny package which is a good match for the runit ecosystem anyway, so 
maybe it's acceptable.

A more mainstream but much more heavyweight approach would be to use socat(1) 
or netcat-openbsd with the -U option.

Alternatively, socklog provides its own socklog-check, which does exactly what 
is necessary, but the whole point of trying to detect whether *any* syslog 
daemon is running is to avoid having to install a particular one like socklog, 
so we probably shouldn't use it.

OTOH, it's such a tiny program, and so unlikely to require changes ever, you 
might even ship (a copy of) it as part of the runit package.

András

-- 
  I break into song if I can't find the key.



Bug#1022837: /lib/runit/run_sysv_scripts uses wrong test to skip initscripts

2022-11-04 Thread Andras Korn
On Wed, Nov 02, 2022 at 01:45:24PM +0100, Lorenzo wrote:

Hi,

> Am I correct that this is not a regression introduced with recent changes to 
> runit? [relevant to understand if I have to revert something in case I can't 
> fix this before the freeze]

Yes. I just started using the default config files (/etc/runit/1 mainly) that 
you ship, and noticed this problem due to that.

> Anyway, let me clarify this one first:
> > 
> > Uh, what runtime directory? /etc/sv is currently a repository for 
> > package-supplied and admin-provided service directories. Why would you move 
> > that to /run, which is volatile?
> >
> 
> A. package supplied
> B. admin-provided
> C. runtime directory ( the directory that is actually
> monitored by a runsv process when the service is enabled)
> 
> with the current setup, A,B and C are overlapped in /etc/sv/: what I plan to 
> do is to separate these in 3 different path, like
> 
> A. /usr/share/runit/sv/ (package supplied runscript, source format -->
> symlinks are missing)
> B. /etc/sv/ (reserved for local admin provided runscript)
> C. /run/runit/sv/ (runtime copy of services)
> 
> At system boot (see TODO comment in stage 2) a specialised cpsv(8) tool is 
> used to copy relevant runscript in C; when a 'name' runscript exists both in 
> A and B, the copy in B takes precedence. C is kept in sync with A and B 
> during runtime thanks to a trigger that is activated when a package that ship 
> a service is installed/ removed/ upgraded. To pick up changes to B, the local 
> admin will have to call cpsv (either with --sync or with -a).
> 
> Now, cpsv is still WIP, and I can make A and C somehow configurable, and make 
> run_sysv_script behave consistently with cpsv, but is this really usefull?

My first impression is you're trying to solve what is not a problem, and 
introducing unneeded complexity, where part of runit's appeal (at least for me) 
is its simplicity and straightforwardness. You're building extra layers around 
runit so that people who are familiar with runit per se aren't able to use the 
Debian runit packages without jumping through hoops. There may be good reasons, 
but personally, I don't like this direction.

I would just as soon manage my /etc/service/* symlinks without any package 
automation.

That said, I would be grateful for ways of getting rid of the following 
annoying behaviours:

 1. openssh ships its /etc/sv/ssh directory, which gets symlinked to 
/etc/service during installation, but which never worked for me (unfortunately 
I didn't investigate, just replaced the symlink with one to my own 
/var/lib/svn-checkout/services/ssh);
 2. a default-syslog service is created by something, and all it does on my 
systems is sleep indefinitely (I use socklog as my syslogd, but have my own 
service directory for that as well, and its name is just "socklog", so the 
magic "check" script won't pick it up -- and neither will it pick up a syslogd 
that is not managed by runit. Maybe just try to see if something is listening 
on /dev/log in "check"?).

If I could override /etc/sv/ssh with my own directory (e.g. if "B" were a 
configurable list of locations in order of precedence), that would solve #1.

If it were possible to disable the "default-syslog" service conclusively, 
permanently, by creating something somewhere during installation, or writing a 
line into a file, that would be great.

Being able to opt out completely of all Debian specific runit glue would be 
even better; I accept that it's convenient for new or casual users, but for me 
in particular it's mostly just frustrating due to it being different from 
upstream runit, which I started using in around 2004 (switching to it from 
daemontools).

> A: with the new layout, what would be the reason for you to checkout your svn 
> somewhere else than /etc/sv/ ?

 1. /etc is for configuration. /var/lib/svn-checkout/services is not 
configuration; it's more like your /usr/share/runit/sv (except it's not shipped 
by a package, but it might as well be).
 2. I see /etc/sv as a place to instantiate template-based services; like 
systemd has openvpn@foo, I have /etc/sv/openvpn-foo, whose run script is a 
symlink to my svn checkout's openvpn-template/run (and the script infers what 
openvpn config to use based on the "-foo" suffix of the runit service name).

Mixing local instantiations with upstream svn content would be hard to maintain 
(e.g. "svn status" output would be cluttered).

> C: to some extent is already configurable, because I need that for the 
> transition and I want to support user services (in /home/ ), but I'm not sure 
> there is a reasonable use case beyond that..

FWIW, user-template is another such service I instantiate separately for each 
user who needs to be able to have their own runit services. But you lost me 
again: what is already configurable to some extent?

> > > >  1. /etc/sv/$name may not be symlinked into /etc/service (false 
> > > > positive);
> > > >  2. /etc/service may

Bug#1022837: /lib/runit/run_sysv_scripts uses wrong test to skip initscripts

2022-10-29 Thread Andras Korn
On Fri, Oct 28, 2022 at 03:07:07PM +0200, Lorenzo wrote:

Hi,

> > Package: runit
> > Version: 2.1.2-50
> > Severity: normal
> > 
> > Hi,
> > 
> > /lib/runit/run_sysv_scripts has this:
> > 
> > for script in "$initdir/$rX"* ; do
> > [ ! -x "$script" ] && continue
> > path=$(realpath "$script")
> > name=${path##*/}
> > # Special case for wicd. Runscript is called "wicd-daemon",
> > # to match binary package name.
> > [ -d "/etc/sv/$name" ] && continue
> > [ -d "/etc/sv/$name-daemon" ] && continue
> > "$script" "$rcommand"
> > done
> > 
> > Checking for /etc/sv/$name and skipping initscripts if those
> > directories exist is wrong for two reasons:
> > 
> >  1. /etc/sv/$name may not be symlinked into /etc/service (false
> > positive);
> 
> The runit service exists and is not enabled, so why one would want to
> start a sysv instance instead? 
> To me 1. looks correct, can you make an example when it causes
> unexpected/buggy results?

Our expectations are apparently different. I would expect 
/lib/runit/run_sysv_scripts to do what it says on the tin: run sysv scripts. 
The only reason to skip a script (as far as I'm concerned) is that running it 
would conflict with a runit service.

It's not just about starting services either: if /etc/sv/$name exists but the 
service is not managed by runit (that is, /etc/service/$name doesn't exist), 
and I start the service manually via the initscript, run_sysv_scripts will also 
fail to stop it.

I understand that you're thinking of /etc/sv/ as "configuration", but in this 
instance I would prefer configuration to be more explicit; if I want to disable 
a service I'll make sure it can't be started (e.g. by modifying its 
/etc/default file), not just refrain from creating a /etc/service/ symlink for 
it.

If I just want to disable automatic startups, I'll create 
/etc/service/servicename/down.

> >  2. /etc/service may contain a symlink to a service directory for this 
> > service that is elsewhere in the filesystem, not in /etc/sv (false 
> > negative).

Example:

lrwxrwxrwx 1 root root 34 Feb  9  2009 /etc/service/atd -> 
/var/lib/svn-checkout/services/atd

This isn't in /etc/sv, but it still means atd(8) is managed by runit.

> > As a minimum, I suggest the following: instead of /etc/sv/$name, check for 
> > /etc/service/$name (and $name-daemon if necessary), and not with "-d" but 
> > "-L" (because when running rcS.d, the target of the symlink may only appear 
> > later, for example when a new filesystem is mounted).
> > 
> > This is still imperfect during boot because /etc/service may point to some 
> > directory that is not the one we'll switch to with runsvdir in stage 2. I 
> > don't know what the best way of handling this (likely rare) case is, but 
> > the following solutions come to mind:
> 
> 2. is an issue, especially because I'm thinking of moving the runtime
> directory form /etc/sv/ --> /run/runit/sv/ : this move requires a
> long transition period where both the old and the new path are
> supported as runtime directories..

Uh, what runtime directory? /etc/sv is currently a repository for 
package-supplied and admin-provided service directories. Why would you move 
that to /run, which is volatile?

> On the other hand I don't know if with systemd or Sysvinit is even possible 
> to boot the system with a custom path for services; I don't want to make it 
> unnecessary hard to do it with runit, but I think it's reasonable to expect 
> some effort on admin side for such setup.

I'm sorry, you lost me completely (or maybe I lost you; see my example symlink 
above).

> >  1. have a /etc/runit/override-init.d/ directory. If $name exists in it, 
> > don't invoke the initscript in /lib/runit/run_sysv_scripts. This places the 
> > entire administration/configuration burden on the admin but is very simple 
> > to do, and easy enough for the admin to automate (e.g. your own service 
> > scripts can just create these files when they're first run).
> 
> I'm ok with adding this, but it's unclear to me if the above is theoretical 
> reasoning or you have an actual problem with your setup: in case of the 
> latter please add more detail to avoid the unhappy case where the fix that i 
> push doesn't solve your issue

Yes.

For example, I have an atd service whose service directory is 
/var/lib/svn-checkout/services/atd. This is symlinked into /etc/service. 
run_sysv_scritps doesn't detect it as a runit-supervised service, because the 
directory is different from /etc/sv/atd, and starts another instance via the 
initscript.

I have many such services. I keep my runit service directories in Subversion 
and have a checkout of the repository on all systems. I just symlink the 
appropriate directory from the checkout into /etc/service if I want to run a 
service.

I use /etc/sv to instantiate services that I have templates for; for example, I 
have an openvpn runit service template, so I'll create /etc/sv/openvpn-foobar 
and create a /etc/sv/open

Bug#1022837: /lib/runit/run_sysv_scripts uses wrong test to skip initscripts

2022-10-26 Thread Andras Korn
Package: runit
Version: 2.1.2-50
Severity: normal

Hi,

/lib/runit/run_sysv_scripts has this:

for script in "$initdir/$rX"* ; do
[ ! -x "$script" ] && continue
path=$(realpath "$script")
name=${path##*/}
# Special case for wicd. Runscript is called "wicd-daemon",
# to match binary package name.
[ -d "/etc/sv/$name" ] && continue
[ -d "/etc/sv/$name-daemon" ] && continue
"$script" "$rcommand"
done

Checking for /etc/sv/$name and skipping initscripts if those directories exist 
is wrong for two reasons:

 1. /etc/sv/$name may not be symlinked into /etc/service (false positive);

 2. /etc/service may contain a symlink to a service directory for this service 
that is elsewhere in the filesystem, not in /etc/sv (false negative).

As a minimum, I suggest the following: instead of /etc/sv/$name, check for 
/etc/service/$name (and $name-daemon if necessary), and not with "-d" but "-L" 
(because when running rcS.d, the target of the symlink may only appear later, 
for example when a new filesystem is mounted).

This is still imperfect during boot because /etc/service may point to some 
directory that is not the one we'll switch to with runsvdir in stage 2. I don't 
know what the best way of handling this (likely rare) case is, but the 
following solutions come to mind:

 1. have a /etc/runit/override-init.d/ directory. If $name exists in it, don't 
invoke the initscript in /lib/runit/run_sysv_scripts. This places the entire 
administration/configuration burden on the admin but is very simple to do, and 
easy enough for the admin to automate (e.g. your own service scripts can just 
create these files when they're first run).

 2. pass the name of the /etc/runit/runsv directory that we expect to be used 
to /lib/runit/run_sysv_scripts somehow (for example, in an environment 
variable). This looks brittle (riddled with race conditions) and complicated to 
me, but it would require no effort from the admin.

 3. invoke runsvchdir earlier during boot. This is problematic on systems where 
/ is read-only before some initscripts are run.

 4. [other kludges]

András

-- 
 Reality is merely an illusion, albeit a very persistent one.



Bug#1022814: /etc/runit/1 could be more readable

2022-10-26 Thread Andras Korn
Package: runit
Version: 2.1.2-50
Severity: minor
Tags: patch

Hi,

I'm not satisfied with this bit from /etc/runit/1:

--- 8< ---
if [ -f /etc/runit/native.boot.run ] || [ -n "$bootrun" ]; then
bootrun=1
fi

if [ -d /etc/runit/boot-run ] && [ ! -z $bootrun ]; then
for f in /etc/runit/boot-run/*.sh; do
[ -r "$f" ] && . "$f"
done
else
/lib/runit/run_sysv_scripts '/etc/rcS.d'
fi

--- >8 ---

On the one hand, '-z $bootrun' looks like an accident waiting to happen due to 
the missing quotes around "$bootrun". On the other, '[ ! -z "$bootrun" ]' and 
'[ -n "$bootrun ]' mean the same thing, so why do it two different ways within 
five lines?

Furthermore, the two ifs seem redundant; I think the code would be more 
succinct and more readable the following way:

--- 8< ---

if [ -f /etc/runit/native.boot.run -o -n "$bootrun" ] && [ -d 
/etc/runit/boot-run ]; then
bootrun=1   # set this because sourced scripts might use it, I 
guess (although they wouldn't get run if bootrun weren't set, so setting 
bootrun=1 looks completely superfluous)
for f in /etc/runit/boot-run/*.sh; do
[ -r "$f" ] && . "$f"
done
else
/lib/runit/run_sysv_scripts '/etc/rcS.d'
fi

--- >8 ---

I think this is equivalent with the exception that it only sets bootrun=1 if 
the /etc/runit/boot-run directory exists; but since nothing in the original 
script uses $bootrun, this doesn't seem to matter (and, as noted above, setting 
bootrun=1 seems completely redundant).

András

-- 
   A conclusion is where you got tired of thinking.



Bug#1022103: gdisk: sgdisk produces only errors

2022-10-24 Thread Andras Korn
Hi,

unfortunately the bug is still not fixed despite the NMU; while sgdisk doesn't 
print errors anymore, it also doesn't actually perform the requested operations.

See e.g.

# sgdisk --zap-all /dev/sda 

Creating new GPT entries in memory.
GPT data structures destroyed! You may now partition the disk using fdisk or
other utilities.

Looks good, but no partition table has actually been created:

# parted -s /dev/sda print
Error: /dev/sda: unrecognised disk label
Model: VMware Virtual disk (scsi)
Disk /dev/sda: 10.7GB
Sector size (logical/physical): 512B/512B
Partition Table: unknown
Disk Flags: 

So let's create a partition table with parted and verify that it's there:

# parted -s /dev/sda mklabel gpt
# parted -s /dev/sda print  
Model: VMware Virtual disk (scsi)
Disk /dev/sda: 10.7GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags: 

Number  Start  End  Size  File system  Name  Flags

Now let's try to create a partition with sgdisk:

# sgdisk --set-alignment=1 --new=1:0:4M --typecode=1:EF02 --change-name=1:grub

No error message, but the partition isn't there:

# parted -s /dev/sda print
Model: VMware Virtual disk (scsi)
Disk /dev/sda: 10.7GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags: 

Number  Start  End  Size  File system  Name  Flags

Best regards,

András

-- 
 Money can't buy friends, but you can afford a better class of enemy.



Bug#1022172: /lib/modprobe.d/50-nfs.conf causes initramfs-tools to stop including sunrpc module for nfs

2022-10-22 Thread Andras Korn
On Fri, Oct 21, 2022 at 03:11:27PM +0200, Marco d'Itri wrote:

Hi,

> > I thought --ignore-install was completely broken, but no, because without 
> > it, the output contains *more* "install" lines:
> What you are actually seeing is that --ignore-install is applied only to 
> the nfs module (the one which you have requested to load) but not to its 
> own dependencies:

Yes, and this is in fact in agreement with the documentation:

 -i, --ignore-install, --ignore-remove
This option causes modprobe to ignore install and remove commands in the 
configuration file (if any) *for the module specified on the command line (any 
dependent modules are still subject to commands set for them in the 
configuration file)*.

This doesn't look like useful behaviour to me, but I don't pretend to be aware 
of all use-cases (the only one I *am* aware of is the one in mkinitramfs, which 
this behaviour breaks).

Unfortunately the current output can't, as I see it, be parsed to obtain a list 
of dependencies, because the 'install' commands can be arbitrary command lines 
with arbitrary side effects, any of which might be loading a module that isn't 
even named in the command line.

> No matter what happens to --ignore-install I suggest that  nfs-kernel-server 
> will replace the modprobe configuration with some udev  rules like this one 
> (untested):
> 
> ACTION=="add", SUBSYSTEM=="module", KERNEL=="sunrpc", RUN+="/sbin/sysctl -q 
> --pattern sunrpc --system"

I see several ways forward:

1. packages that obfuscate module dependencies by supplying 'install' commands 
for modules that other modules may depend on should be required to include 
initramfs (and dracut?) hooks that install all dependencies in the initramfs if 
a depending module is installed in it. This is arguably the correct solution; 
in the case of nfs-kernel-server, for example, the 'install' command wants to 
invoke sysctl --pattern, but the busybox sysctl installed in the initramfs by 
default doesn't support --pattern. So the package would need to force initramfs 
to include the /sbin/sysctl from procps, and maybe also any pertinent files 
from /etc/sysctl.d.

2. in addition to looking at modprobe output, mkinitramfs should also look at 
the depends: line in modinfo(8) output to find dependencies, and transitively 
close the set of modules it includes. This seems like a relatively easy 
workaround but it's not correct in that it won't cause /sbin/sysctl to be 
included even if an 'install' command calls it (or whatever other binary and 
configuration may be needed).

3. Debian could forbid including 'install' commands for modules that other 
modules depend on and that may (frequently?) need to be included in an 
initramfs (requiring, for example, the kind of udev rule Marco proposed).

András

-- 
 The bride got a new name and a dress.



Bug#1022172: /lib/modprobe.d/50-nfs.conf causes initramfs-tools to stop including sunrpc module for nfs

2022-10-21 Thread Andras Korn
Package: kmod
Version: 30+20220905-1
Severity: important

Hi,

I noticed that the sunrpc module was strangely absent from my initramfs, which 
resulted in a failure to netboot (which is my justification for the severity).

Upon examination, it turns out that the way module dependencies are worked out 
for initramfs generation depend on the output of this command:

# /sbin/modprobe --all --set-version="6.0.0-1-amd64" --ignore-install --quiet 
--show-depends nfs
insmod /lib/modules/6.0.0-1-amd64/kernel/fs/netfs/netfs.ko 
insmod /lib/modules/6.0.0-1-amd64/kernel/fs/fscache/fscache.ko 
insmod /lib/modules/6.0.0-1-amd64/kernel/net/sunrpc/sunrpc.ko 
insmod /lib/modules/6.0.0-1-amd64/kernel/fs/nfs_common/grace.ko 
insmod /lib/modules/6.0.0-1-amd64/kernel/fs/lockd/lockd.ko 
insmod /lib/modules/6.0.0-1-amd64/kernel/fs/nfs/nfs.ko 

This, above, is what the output looked like with versions of nfs-kernel-server 
before 1:2.6.2-1+b1, which didn't ship /lib/modprobe.d/50-nfs.conf.

With the new version of nfs-kernel-server, the output becomes:

# /sbin/modprobe --all --set-version="6.0.0-1-amd64" --ignore-install --quiet 
--show-depends nfs
insmod /lib/modules/6.0.0-1-amd64/kernel/fs/netfs/netfs.ko 
insmod /lib/modules/6.0.0-1-amd64/kernel/fs/fscache/fscache.ko 
install /sbin/modprobe --ignore-install sunrpc $CMDLINE_OPTS && { /sbin/sysctl 
-q --pattern sunrpc --system; exit 0; } 
insmod /lib/modules/6.0.0-1-amd64/kernel/fs/nfs_common/grace.ko 
install /sbin/modprobe --ignore-install lockd $CMDLINE_OPTS && { /sbin/sysctl 
-q --pattern fs.nfs.n[sl]m --system; exit 0; } 
insmod /lib/modules/6.0.0-1-amd64/kernel/fs/nfs/nfs.ko 

This confuses manual_add_modules() from 
/usr/share/initramfs-tools/hook-functions, which expects to only see insmod 
lines, not install lines here.

I thought --ignore-install was completely broken, but no, because without it, 
the output contains *more* "install" lines:

# /sbin/modprobe --all --set-version="6.0.0-1-amd64" --quiet --show-depends nfs
insmod /lib/modules/6.0.0-1-amd64/kernel/fs/netfs/netfs.ko
insmod /lib/modules/6.0.0-1-amd64/kernel/fs/fscache/fscache.ko
install /sbin/modprobe --ignore-install sunrpc $CMDLINE_OPTS && { /sbin/sysctl 
-q --pattern sunrpc --system; exit 0; }
insmod /lib/modules/6.0.0-1-amd64/kernel/fs/nfs_common/grace.ko
install /sbin/modprobe --ignore-install lockd $CMDLINE_OPTS && { /sbin/sysctl 
-q --pattern fs.nfs.n[sl]m --system; exit 0; }
install /sbin/modprobe --ignore-install nfs $CMDLINE_OPTS && { /sbin/sysctl -q 
--pattern fs.nfs --system; exit 0; }

If the /lib/modprobe.d/50-nfs.conf shipped by nfs-kernel-server is valid, then 
modprobe --ignore-install doesn't handle it correctly; if it's invalid, then I 
suppose modprobe should print an error. There seems to be a problem with 
modprobe either way, unless initramfs-tools misunderstands the purpose of 
--ignore-install.

Best regards,

András

-- System Information:
Debian Release: bookworm/sid
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (350, 'unstable'), (1, 'experimental')
merged-usr: no
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.17.15-caeeng (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=hu_HU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8
Shell: /bin/sh linked to /bin/dash
Init: runit (via /run/runit.stopit)
LSM: AppArmor: enabled

-- 
 Perl: The only language that looks the same before and after RSA encryption.



Bug#1016553: Recently (since early 2022?), broken terminal handling in LXC consoles (lxc-attach inside screen or tmux)

2022-08-02 Thread Andras Korn
Package: joe
Version: 4.6-1+b1
Severity: important

Hi,

as of recently, if I start screen (or tmux, doesn't seem to matter) on a Linux 
host, then use lxc-attach to enter a running LXC container, and start joe 
inside that container, the terminal behaves in a hard to describe, but 
completely broken way, making the editor essentially unusable.

Some examples:

1. Subsequent lines appear concatenated and then broken at an off-by-one 
location. A file that contains

<<<
#
# foo
>>>

would be rendered as

<<<
# [... spaces up to the end of the terminal line ... ] #
foo
>>>

CTRL-R has no apparent effect. Enabling syntax highlighting seems to make it 
worse (mangling more lines), but not always.

2. When typing, the cursor keeps jumping back to column 2 or 3, and the typed 
characters are hidden, as if they were off-screen to the left. Pressing CTRL-R 
fixes this problem temporarily. After pressing CTRL-R, pressing END (but not 
^E) repeatedly moves the cursor to somewhere around colum 40, but the column 
display in the upper right corner displays the correct position even after the 
first END press (or ^E press).

3. Similar to #2, but happens especially when editing a new file, or an empty 
line: instead of echoing the typed characters, either spaces echo, or the 
cursor stays at the leftmost position.

If you can suggest a way for me to record what I see on the screen and the keys 
I press concurrently, I suppose I can produce a "movie" of the breakage.

Other editors are unaffected (I tried vim, mcedit and nano).

I can't reproduce the problem without screen or tmux (ssh host, lxc-attach 
container, joe works).

I can't reproduce the problem if I start the container's joe binary by 
chrooting into the container's filesystem from the host.

I can't reproduce the problem if I ssh into the container instead of entering 
it via lxc-attach, not even if I subsequently start screen inside the container 
and joe inside screen.

I experimented with downgrading screen, ncurses, and joe itself, but either I 
wasn't systematic enough or it really didn't help.

I experimented with using different terminal applications to ssh into the LXC 
host (xterm, konsole), and it seemed to make no difference.

I *can* reproduce the problem by starting screen(1) locally, then ssh'ing into 
the LXC host, using lxc-attach, then starting joe inside the container.

screen(1) sets my TERM to screen.xterm-256color. Setting TERM to just "screen" 
apparently fixes problem #1 but not the others.

In tmux (whether started locally or on the LXC host doesn't matter), which sets 
TERM to "screen-256color", breakage #1 is less pronounced and slightly 
different: some lines are just visually missing their first character, but it's 
not rendered at the end of the previous line. The other two problems are just 
as in screen(1).

If I start tmux locally, then ssh into the LXC host and start screen there, 
TERM is set to just "screen" but after lxc-attach, problem #1 is present again.

As a demonstration, I opened a 150x47 terminal, reproduced problem #1, and used 
the X clipboard to copy and paste the contents of the window (with 
/etc/login.defs opened in joe) into this message below, disabling automatic 
line breaks:

--- 8< ---
IW   /etc/login.defs
 Row 45   Col 1   
 Enable display of unknown usernames when login failures are recorded.
#   
 # WARNING: 
Unknown usernames may become world readable. 
# See #290803 and #298773 for details about how this could become a security
# concern
LOG_UNKFAIL_ENABno

#   
 # Enable 
logging of successful logins
#   
 
LOG_OK_LOGINS   no

#   
 # Enable 
"syslog" logging of su activity - in addition to sulog file logging.
# SYSLOG_SG_ENAB does the same for newgrp and sg.
#   
 
SYSLOG_SU_ENAB  yes
SYSLOG_SG_ENAB  yes

#   
 # If 
defined, all su activity is logged to this file.
#   

Bug#1003225: on resume, tries to openat() mountpoint of remote nfs mounts that are not yet available, thus delaying network configuration

2022-07-13 Thread Andras Korn
On Mon, Jul 11, 2022 at 10:47:26AM +0300, Martin-Éric Racine wrote:

> On Thu, 6 Jan 2022 18:38:47 +0100 Michael Biebl  wrote:
> > On 06.01.22 17:26, Andras Korn wrote:
> > > Package: systemd-timesyncd
> > > Version: 249.7-1
> > > Severity: normal
> > > Tags: upstream
> > >
> > > Hi,
> > >
> > > I noticed that it took a while for the network to become available after 
> > > my
> > > laptop wakes up from suspend.
> > >
> > > I traced the problem to systemd-timesyncd.
> > >
> > > I use dhcpcd5, which ships /lib/dhcpcd/dhcpcd-hooks/64-timesyncd.conf,
> which
> > > contains the line "systemctl try-restart systemd-timesyncd.service || :".
> >
> > That file is not shipped by systemd. Why does it restart timesyncd?
> > Why does it so blockingly? Why does it restart timesyncd when the
> > network is still down? 
> 
> This is dhcpcd's attempt at adding the NTP servers received via DHCP options 
> to
> timesyncd's configuration and restarting timesyncd to use them. This should
> only happen once the network has been raised, though, since this is an exit
> hook.

Is there any particular reason you can't invoke systemctl with --no-block here?

András

-- 
Buy an atlas and see the world.



Bug#1014876: Please make it possible to override /etc/tmpreaper.conf from a user configfile

2022-07-13 Thread Andras Korn
Package: tmpreaper
Version: 1.6.17
Severity: wishlist

Hi,

I think you should add something like

[ -r /etc/default/tmpreaper ] && . /etc/default/tmpreaper

at the bottom of /etc/tmpreaper.conf.

Currently, every upgrade that adds some new setting to tmpreaper.conf
requires the user to re-edit the file if they had modified it -- either to
re-add SHOWWARNING=false, or to add the new option (in the most recent case,
RUNFROMCRON=true) to it.

I happen to want to set SHOWWARNING=false AND RUNFROMCRON=true, and the
suggested modification would make my life easier without, I think, breaking
anything.

Thanks

András

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

Kernel: Linux 5.17.15 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=hu_HU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8
Shell: /bin/sh linked to /bin/dash
Init: runit (via /run/runit.stopit)
LSM: AppArmor: enabled

Versions of packages tmpreaper depends on:
ii  debconf [debconf-2.0]  1.5.79
ii  libc6  2.33-7
ii  libmount1  2.38-4devuan1

tmpreaper recommends no packages.

tmpreaper suggests no packages.

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

-- debconf information excluded

-- 
Healthy people live longer - but they spend more time jogging.



Bug#1007205: Please consider (re)including my start-stop-daemon.runit script

2022-03-28 Thread Andras Korn
On Thu, Mar 24, 2022 at 01:05:34AM +0100, Lorenzo wrote:

> [1] I'll deal with this in a separate bug, but just to give you an idea:
> why divert start-stop-daemon is better than diverting invoke-rc.d
> and update-rc.d? Or, another example, why not abuse the ancient
> policy-rc.d hack?

I think it's better because start-stop-daemon is the common denominator.
Diverting it will do the right thing even if someone invokes /etc/init.d/foo
manually; the other solutions only affect well-written maintainer scripts.

András

-- 
  Birthdays are good for you - the more you have the longer you live.



Bug#1007205: Please consider (re)including my start-stop-daemon.runit script

2022-03-13 Thread Andras Korn
Sorry, naturally I found a typo in the script just after sending it:

Index: start-stop-daemon.runit
===
--- start-stop-daemon.runit (revision 1347)
+++ start-stop-daemon.runit (working copy)
@@ -71,7 +71,7 @@
 read -A cmdline 

Bug#1007205: Please consider (re)including my start-stop-daemon.runit script

2022-03-13 Thread Andras Korn
Package: runit
Version: 2.1.2-45
Severity: wishlist

Hi,

Back in 2012 I sent Gerrit a start-stop-daemon.runit script (see
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=678985) that could be used
as a drop-in replacement for the real start-stop-daemon. It's a fairly
feature complete wrapper around the real start-stop-daemon that manages
runit services if they are present and passes calls to the real
start-stop-daemon if they are not.

I dpkg-divert /sbin/start-stop-daemon to /sbin/start-stop-daemon.real on all
my systems and install this script as /sbin/start-stop-daemon.

This way, initscript work transparently whether a service is managed by
runit or not. Without this script, care must be taken to avoid the real
start-stop-daemon starting daemons like e.g. ntpd or smartd alongside a
runit-managed instance.

The script used to be included in runit under /usr/share/doc until Dmitry
removed in 2016 because it was "unused".

I think it can be useful even if the package doesn't use it explicitly, but
a case could be made for runit to perform this diversion on install and ship
my script as /sbin/start-stop-daemon.

The only drawback (that I can see) is that this would introduce a dependency
on zsh, because that's what I wrote the script in. Maybe Suggests: zsh, make
installing my script both optional and contingent on zsh being present? (Of
course, people could still shoot themselves in the foot by removing zsh
afterwards. Can dpkg run a trigger when zsh is uninstalled?)

I'm attaching the current version of the script, which contains some
improvements over the 2012 version.

András

-- 
  Government corruption is always reported in the past tense.
#!/bin/zsh
#
# This script is intended to wrap start-stop-daemon. It will call the
# original start-stop-daemon with the supplied arguments unless the daemon
# to be started appears to exist as a runit service, in which case it will
# map the start-stop-daemon call to an sv(8) call.
#
# Copyright 2012-2022 András Korn.
#
# Licensed under the GPL v3, or, at your option, under the same license as
# the runit package.

# If called by non-root user, fall back to original start-stop-daemon
# unconditionally
[[ $UID -gt 0 ]] && exec /sbin/start-stop-daemon.real $@

set -A args $@

SVDIR=${SVDIR:-/etc/service}

unset mode signal exec timeout startas testmode oknodo quiet verbose command 
svstat candidates
oknodo=0
quiet=0

typeset -U candidates

while [[ -n "$1" ]]; do
case "$1" in
-S|--start) mode=start;;
-K|--stop)  mode=stop;;
-T|--status)mode=status;;
-H|--help|-V|--version) exec /sbin/start-stop-daemon.real 
$args;;
-x|--exec)  shift; exec="$1";   
candidates=($candidates ${1:t});;
-s|--signal)shift; signal=$1;;
--signal=*) signal="${1/--signal=/}";;
-R|--retry) shift; timeout="$1";;
--retry=*)  timeout="${1/--retry=/}";;
-a|--startas)   shift; startas="$1" 
candidates=($acndidates ${1:t});;
-t|--test)  testmode=1;;
-o|--oknodo)oknodo=1;;
-q|--quiet) quiet=1; exec >/dev/null;;
-v|--verbose)   verbose=1;;
-m|--make-pidfile)  make_pidfile=1;;
--remove-pidfile)   remove_pidfile=1;;
-n|--name)  shift;  
candidates=($candidates $1);;
-p|--pidfile)   shift; pidfile="$1";
candidates=($candidates ${1:t:r});;
--pidfile=*)pidfile="${1#--pidfile=}";  
candidates=($candidates ${1:t:r});;

-u|--user|-g|--group|--pid|--ppid|-c|--chuid|-r|--chroot|-d|--chdir|-O|--output|-N|--nicelevel|-P|--procsched|-I|--iosched|-k|--umask)
 shift;; # ignored

-b|--background|--nicelevel=*|--procsched=*|--iosched=*|--umask=*|-C|--no-close)
:;; # ignored
--notify-wait)  echo "Warning: this version of 
start-stop-daemon.runit ignores --notify-wait." >&2;;
--notify-timeout)   echo "Warning: this version of 
start-stop-daemon.runit ignores --notify-timeout." >&2;;
--) break;; # What follows is args to the 
daemon. Avoid parsing those accidentally.
*)  command="$1"; break;; # Assume the 
previous was the last option; the rest is the name of the daemon plus args, of 
which we only care about the daemon.
esac
shift
done

# returns success if $1 appears to be the name of a runit service
function issvname() {
[[ -d "$SVDIR/$1/supervise/." ]] && return 0
# 'supervise' could still be a symlink to a directory that doesn't 
exist yet
[[ -L $SVDIR/$1/super

Bug#983726: runsv(8) incorrect regarding control/[dx]

2022-02-25 Thread Andras Korn
On Thu, Feb 24, 2022 at 12:26:51PM +0100, Lorenzo wrote:

> > However, if there were a natural-language explanation or flowchart, I
> > think I could summarize it succinctly in a manner appropriate for the
> > man page, within a day.
> > 
> > Alas, that's all the help I can offer at the moment.
> > 
> > András
> > 
> 
> an attempt to fully explain the actual behavior is ( only for d, the
> same goes for x)

So I suggest the following:

--- 8< ---
CUSTOMIZE CONTROL

   For each control character c except "d" and "x" sent to the control
   pipe, runsv first checks if service/control/c exists and is
   executable. If so, it starts service/control/c and waits for it to
   terminate, before interpreting the command. If the program exits with
   return code 0, runsv refrains from sending the service the
   corresponding signal. The command o is always considered as command
   u. On command d first service/control/t is checked, and then
   service/control/d. On command x first service/control/t is checked,
   and then service/control/x. Specifically:

   If the service is running or paused, control characters "d" and "x" are 
handled as follows:

   1. runsv checks whether control/t exists and is executable and runs it 
if yes.
   2. If control/t exits nonzero, or is not executable or doesn't exist, 
runsv sends the service a TERM signal.
   3. runsv sends the service a CONT signal, disregarding control/c even if 
it exists and is executable.
   4. Runsv checks whether control/d (or control/x) exists and is 
executable and runs it if yes. Its exit status is ignored.

   The control of the optional log service cannot be customized.

--- >8 ---

I believe this is clear; I don't know if it's accurate.

András

-- 
Depression is merely anger without enthusiasm.



Bug#983726: runsv(8) incorrect regarding control/[dx]

2022-02-24 Thread Andras Korn
On Tue, Feb 22, 2022 at 02:36:23PM +0100, Lorenzo wrote:

> > On Mon, 19 Apr 2021 09:45:53 +0200
> > Andras Korn  wrote:
> > 
> > > Additionally, the documentation as it is now is clear and
> > > straightforward, with few special cases; while the actual behaviour
> > > of runsv, while I agree it can make sense, is more difficult to
> > > explain clearly.
> 
> --- ./runsv.8-orig  2022-01-03 03:00:49.0 +0100
> +++ ./runsv.8   2022-02-22 01:12:29.438824451 +0100
> @@ -185,16 +185,18 @@
>  .IR u .
>  On command
>  .I d
> -first
> +first the service receives the TERM signal, subject to the
>  .I service\fR/control/t
> -is checked, and then
> -.I service\fR/control/d.
> +check, then the service receives a CONT signal and finally
> +.I service\fR/control/d
> +is checked.
>  On command
>  .I x
> -first
> +first the service receives the TERM signal, subject to the
>  .I service\fR/control/t
> -is checked, and then
> -.I service\fR/control/x.
> +check, then the service receives a CONT signal and finally
> +.I service\fR/control/x
> +is checked.
>  The control of the optional log service cannot be customized.
>  .SH SIGNALS
>  If
> 
> 
> I'm not fully satisfied but it should at least make clear that you
> can't prevent a TERM with control/[dx]..
> Still doesn't tell that control/c is disregarded and that for
> control/[dx] checked only means exists and is executable.

Thanks for keeping tabs on this!

Unfortunately it's been so long that I have trouble reconstructing what the
actual behaviour (as opposed to the documented one) is, and I don't have
time to reread the source code just now.

However, if there were a natural-language explanation or flowchart, I think
I could summarize it succinctly in a manner appropriate for the man page,
within a day.

Alas, that's all the help I can offer at the moment.

András

-- 
Well, to be Frank, I'd have to change my name.



Bug#665774: Messes up $PATH

2022-02-21 Thread Andras Korn
FWIW, this is now fixed in the latest upstream master:

https://github.com/dell/dkms/pull/193/commits/775a3389ebbafb4fb5d59747667e604cf4f4d903

András

-- 
 Crime is merely politics without the excuses.



Bug#1003225: on resume, tries to openat() mountpoint of remote nfs mounts that are not yet available, thus delaying network configuration

2022-01-06 Thread Andras Korn
Package: systemd-timesyncd
Version: 249.7-1
Severity: normal
Tags: upstream

Hi,

I noticed that it took a while for the network to become available after my
laptop wakes up from suspend.

I traced the problem to systemd-timesyncd.

I use dhcpcd5, which ships /lib/dhcpcd/dhcpcd-hooks/64-timesyncd.conf, which
contains the line "systemctl try-restart systemd-timesyncd.service || :".

During this try-restart operation, a timesyncd process is started and hangs
for several seconds in D state for each nfs mountpoint that is unreachable.
(I'm attaching an strace log; the nfs server also exports
nfs-mountpoint-2/subdir to this client separately, so technically that's
nfs-mountpoint-3.)

dhcpcd5 doesn't continue setting up the network before the hook script
returns, but without the network, the hook script takes a long time to
finish.

I don't see why timesyncd has to try to openat() a directory on every
mountpoint. I assume this is due to some generic code it pulls in from maybe
libsystemd; if it can't be avoided, perhaps timesyncd should be started in a
restricted mount namespace that doesn't contain anything but the (local)
mountpoints it absolutely needs to function. (This would be desirable anyway
from a security perspective.) I'm not sure if this can also be done for
try-restart, though.

András

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

Kernel: Linux 5.14.15-pf8-luna (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=hu_HU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8
Shell: /bin/sh linked to /usr/bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-- 
 Good documentation is not written to satisfy a quota specified in cubic feet.
read(3, "REDACTED"..., 1024) = 1024 <0.20>
read(3, "REDACTED"..., 1024) = 1024 <0.22>
read(3, "REDACTED", 1024) = 18 <0.06>
read(3, "REDACTED", 1024) = 0 <0.06>
openat(AT_FDCWD, "/run/systemd/unit-root/run/credentials", 
O_RDONLY|O_NOFOLLOW|O_CLOEXEC|O_PATH) = 
4 <0.18>
mount(NULL, "/proc/self/fd/4", NULL, 
MS_RDONLY|MS_NOSUID|MS_NODEV|MS_NOEXEC|MS_REMOUNT|MS_BIND, NULL) = 0 <0.11>
close(4) = 0 <0.08>
lseek(3, 0, SEEK_SET) = 0 <0.06>
read(3, "REDACTED"..., 1024) = 1024 <0.29>
lstat("/proc", {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0 <0.08>
lstat("/proc/self", {st_mode=S_IFLNK|0777, st_size=0, ...}) = 0 <0.06>
readlink("/proc/self", "63713", 4095)   = 5 <0.06>
lstat("/proc/63713", {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0 <0.06>
lstat("/proc/63713/mountinfo", {st_mode=S_IFREG|0444, st_size=0, ...}) = 0 
<0.05>
read(3, "REDACTED"..., 1024) = 1024 <0.17>
read(3, "REDACTED"..., 1024) = 1024 <0.17>
read(3, "REDACTED"..., 1024) = 1024 <0.23>
read(3, "REDACTED"..., 1024) = 1024 <0.25>
read(3, "REDACTED"..., 1024) = 1024 <0.17>
read(3, "REDACTED"..., 1024) = 1024 <0.18>
read(3, "REDACTED"..., 1024) = 1024 <0.14>
read(3, "REDACTED"..., 1024) = 1024 <0.15>
read(3, "REDACTED"..., 1024) = 1024 <0.16>
read(3, "REDACTED"..., 1024) = 1024 <0.12>
read(3, "REDACTED"..., 1024) = 1024 <0.15>
read(3, "REDACTED"..., 1024) = 1024 <0.13>
read(3, "REDACTED"..., 1024) = 1024 <0.12>
read(3, "REDACTED"..., 1024) = 1024 <0.14>
read(3, "REDACTED", 1024) = 18 <0.05>
read(3, "REDACTED", 1024) = 0 <0.05>
lseek(3, 0, SEEK_SET) = 0 <0.05>
read(3, "REDACTED"..., 1024) = 1024 <0.18>
lstat("/proc", {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0 <0.06>
lstat("/proc/self", {st_mode=S_IFLNK|0777, st_size=0, ...}) = 0 <0.05>
readlink("/proc/self", "63713", 4095)   = 5 <0.06>
lstat("/proc/63713", {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0 <0.06>
lstat("/proc/63713/mountinfo", {st_mode=S_IFREG|0444, st_size=0, ...}) = 0 
<0.05>
read(3, "REDACTED"..., 1024) = 1024 <0.20>
read(3, "REDACTED"..., 1024) = 1024 <0.15>
read(3, "REDACTED"..., 1024) = 1024 <0.16>
read(3, "REDACTED"..., 1024) = 1024 <0.17>
read(3, "REDACTED"..., 1024) = 1024 <0.13>
read(3, "REDACTED"..., 1024) = 1024 <0.15>
read(3, "REDACTED"..., 1024) = 1024 <0.14>
read(3, "REDACTED"..., 1024) = 1024 <0.15>
read(3, "REDACTED"..., 1024) = 1024 <0.16>
read(3, "REDACTED"..., 1024) = 1024 <0.11>
read(3, "REDACTED"..., 1024) = 1024 <0.14>
read(3, "REDACTED"..., 1024) = 1024 <0.12>
read(3, "REDACTED"..., 1024) = 1024 <0.12>
read(3, "REDACTED"..., 1024) = 1024 <0.14>
read(3, "REDACTED", 1024) = 18 <0.05>
read(3, "REDACTED", 1024) = 0 <0.05>
openat(AT_FDCWD, "/run/systemd/unit-root/run/systemd/incoming", 
O_RDONLY|O_NOFOLLOW|O_CLOEXEC|O_PATH) = 
4 <0.08>
mount(NULL, "/proc/self/fd/4", NULL, 
MS_RDONLY|MS_NOSUID|MS_NODEV|MS_NOEXEC|MS_REMOUNT|MS_BIND, NULL) =

Bug#1002733: Improve /sbin/runlevel for runlevels 0 and 6

2022-01-06 Thread Andras Korn
On Thu, Jan 06, 2022 at 01:07:01AM +0100, lorenzo wrote:

Hi,

> > You now have two flag files and unconditinally use
> > /lib/runit.runlevel.6 first if it exists, even if
> > /lib/runit.runlevel.0 also exists and is newer.
> 
> Please look at
> https://salsa.debian.org/debian/runit/-/commit/2c56dadf15fef1bc809c00aec903970617aeb948

Yes, that's what I was looking at.

> The flag file is /run/runit.runlevel.$LAST and /run is mounted as tmpfs
> in Debian by default, so it's not persistent across reboots.
> Am I loosing something relevant?

Yes; I think you place too much faith in things being nice and clean and
standard everywhere. :)

In reality, I think people will have systems where /run isn't a tmpfs;
they'll have homebrew scripts that muck around with the runit flag files in
strange and wonderful ways; they'll initiate a reboot, then change their
minds and try to shut down; they'll restore the contents of /run from a
backup that accidentally included it; they'll syncrhonize it with another
computer; etc. etc.

Some computers are left running for years without rebooting, and may see a
dozen new runit package versions being installed in the meantime (I'd be
willing to bet there are still running runit instances that will look for
/etc/runit/stopit instead of /run/runit.stopit). It's really impossible to
anticipate all the kinds of messy environment your code will be expected to
run in.

Considering that

 1. runit's philosphoy is to try to avoid race conditions and fragiliy
arising from e.g. the use of PID files; and that

 2. it's not terribly hard to get it right(er) by using the flag file that
is most recent,

I think it's worthwhile to do so. It certainly doesn't seem like a good idea
to me to explicitly implement fragility (depending on /run being "clean").

> > (FWIW, I think the technically correct solution would be to have a
> > "runit runlevel daemon": a simple process that provides a fifo to
> > read the current runlevel from, and another fifo to write into when
> > the runlevel changes; but this is overkill as the concept of a
> > 'runlevel' is very rarely needed.)
> 
> I see it in a different way: the proper solution here would have to have
> a native set of runit boot and shutdown scripts, and drop most of the
> Sysv compatibility.

That's the high-maintenance solution, yes. However, in this particular case
I think it's possible and worthwhile to achieve a limited but sufficient
degree of compatibility (and to make it as robust in the face of unexpected
messes as is possible without making it too complex).

> I don't have time to maintain such set of scripts right now, so my
> second best option is to use initscripts and keep some minimum level of
> Sysv compatibility.

Glad we're on the same page. :)

András

-- 
  Dave, put down those Windows disks. Dave, please. DAVE! - HAL 9000



Bug#1002733: Improve /sbin/runlevel for runlevels 0 and 6

2022-01-05 Thread Andras Korn
On Sun, Jan 02, 2022 at 11:45:27PM +0100, Lorenzo wrote:

Hi,

> > I'd argue that introducing stricter requirements on the existence and
> > correct mode of /run/runit.reboot that apply over the whole uptime of
> > the system is a more dangerous and invasive change than introducing a
> > new control file with semantics that are obvious and well defined
> > from the beginning.
> > 
> >[ ...]
> > The problem with this is that runit hasn't so far cared about the
> > mode of runit.reboot before stage 3, and people may set runit.reboot
> > to mode 100 early, for example out of a desire to make sure a box
> > will reboot instead of shut down if pid 1 were to receive a CONT
> > signal for any reason.
> 
> Didn't thought about that: I'm not sure is a good idea but I'll
> let the local admin have that call.
> So I'm going with flag files, runit.runlevel.$LAST as you suggested
> in your first message.

Thanks, but that's not quite what I suggested. :)

You now have two flag files and unconditinally use /lib/runit.runlevel.6
first if it exists, even if /lib/runit.runlevel.0 also exists and is newer.

If you want one flag file per runlevel, I'd suggest something like

#!/bin/sh
ls -t /lib/runit.runlevel.[0-9] 2>/dev/null \
| sed 's@.*/@@g;s/^runit\.runlevel\.//;/^[0-9S]$/!d' \
| while read level; do
exec printf "N $level"
done
exec printf 'N 2'

(The ugly sed command makes sure we only print numbers even if some joker
creates a file called literally '/lib/runit.runlevel.[0-9]'. The while loop
makes sure we only execute the first printf if there was actually something
to read.)

I'm not sure this is better than using the first character of the contents
of /lib/runit.runlevel, or making it a symlink instead of a file and using
the first character of its target (we can also implement the former without
depending on head(1)).

(FWIW, I think the technically correct solution would be to have a "runit
runlevel daemon": a simple process that provides a fifo to read the current
runlevel from, and another fifo to write into when the runlevel changes; but
this is overkill as the concept of a 'runlevel' is very rarely needed.)

Best regards,

András

-- 
  Aunt Em. Hate Kansas. Hate you. Took dog. Dorothy.



Bug#1002733: Improve /sbin/runlevel for runlevels 0 and 6

2021-12-30 Thread Andras Korn
On Thu, Dec 30, 2021 at 10:02:55AM +0100, Andras Korn wrote:

> On Wed, Dec 29, 2021 at 03:07:38AM +0100, Lorenzo wrote:
> 
> > I'm going to accept a fix for this issue, but I prefer to not have to
> > parse a file and also to not add another flag file only for this, if
> > it's possible.
> 
> Well, getting the first character from a file and printing it verbatim is
> hardly "parsing". :)

I gave this more thought.

I hadn't considered that even /etc/runit/3 depends on /run/runit.reboot
being present and having the correct mode.

I checked the source of runit-init and it creates /run/runit.reboot if it
doesn't exist, not just sets its mode.

Thus, purely for the purpose of rebooting via kexec, depending on
/run/runit.reboot existing and having the correct mode at the time
/etc/runit/3 is executed seems adequate (even if technically racy).

I still worry that by changing the behaviour of runlevel(8) so it depends on
/run/runit.reboot will break something for someone somewhere, but I suppose
you can say they broke it for themselves by fiddling with /run/runit.reboot.

I can think of more convoluted ways of keeping track of the runlevel and
reporting it, but I'll spare you. :) (Avoiding race conditions completely is
not possible since no matter what we do, "check runlevel"; "do something
based on runlevel" will never be an atomic operation in the kexec
initscript. While technically correct is the best kind of correct, it's
probably not worth it to aim for perfection in this instance.)

András

-- 
In the context of marriage, a moral victory is something you'll
  invariably end up celebrating on your own.



Bug#1002733: Improve /sbin/runlevel for runlevels 0 and 6

2021-12-30 Thread Andras Korn
On Wed, Dec 29, 2021 at 03:07:38AM +0100, Lorenzo wrote:

> I'm going to accept a fix for this issue, but I prefer to not have to
> parse a file and also to not add another flag file only for this, if
> it's possible.

Well, getting the first character from a file and printing it verbatim is
hardly "parsing". :)

> > #!/bin/sh
> > # /etc/runit/3 should update /run/runit.runlevel before starting stop
> > scripts unset CURLEVEL
> > CURLEVEL="$(head -c 1 /run/runit.runlevel 2>/dev/null)"
> > if [ -z "$CURLEVEL" ]; then
> > CURLEVEL=2
> > fi
> > exec printf "N $CURLEVEL"
> > 
> 
> Because of #1000867 I'm going to create /run/runit.reboot in stage1,
> so can't we just use stat in runlevel script (at least for runlevel 6)?

I thought of that, but I don't think it's quite this foolproof.

kexec can be critical (for example, if you have an HP raid controller in a
non-HP server, recent firmware versions hang during POST depending on BIOS
settings, even before entering the BIOS setup, so kexec may be the only way
to reboot without taking the computer apart first).

You create /run/runit.reboot once at reboot, which could have been years
ago; anything might have befallen that file in the meantime. For example, it
may not exist anymore, and 'init 6' won't create it, just set its mode if it
exists.

So far nothing depended on runit.reboot existing and having a "correct" mode
outside of runit stage 3.

We have no idea what else (other than kexec) depends on the output of
runlevel(8) and how.

I'd argue that introducing stricter requirements on the existence and
correct mode of /run/runit.reboot that apply over the whole uptime of the
system is a more dangerous and invasive change than introducing a new
control file with semantics that are obvious and well defined from the
beginning.

But, it's mostly your show: if that's how you want to do it, you obviously
can. It'll work for me.

> Something like
> #!/bin/sh
> if [ $(stat -c %a /run/runit.reboot) = 100 ]; then
>   exec printf 'N 6'
> else
>   exec printf 'N 2'
> fi

The problem with this is that runit hasn't so far cared about the mode of
runit.reboot before stage 3, and people may set runit.reboot to mode 100
early, for example out of a desire to make sure a box will reboot instead of
shut down if pid 1 were to receive a CONT signal for any reason.

Like I said, I think making the meaning of the mode bits of runit.reboot
meaningful in a broader context is dangerous.

> Will it work for kexec?

It should. (You'll want a 2>/dev/null on the stat(1) invocation for cases
where the file doesn't exist, /run isn't mounted etc.)

> Also, do we have to cover the 'N 0' shutdown case because of some
> other init scripts that you know of?

I'm not aware of any, but then I didn't know about kexec a week ago, so this
doesn't necessarily mean anything. :)

András

-- 
What if the lottery was just invented by the government
   to capture time travelers?



Bug#1002733: Improve /sbin/runlevel for runlevels 0 and 6

2021-12-28 Thread Andras Korn
On Tue, Dec 28, 2021 at 03:16:30PM +0100, Andras Korn wrote:

> If /sbin/runlevel looked like this instead:
> 
> #!/bin/sh
> # This only does anything useful if /etc/runit/3 updates /run/runit.runlevel 
> before starting stop scripts
> if [ -s /run/runit.runlevel ]; then
>   CURLEVEL="$(head -c 1 /run/runit.runlevel)"
> else
>   CURLEVEL=2
> fi
> exec printf "N $CURLEVEL"

It just occurred to me that technically the above is racy; a non-racy but
less readable solution would be something like

#!/bin/sh
# /etc/runit/3 should update /run/runit.runlevel before starting stop scripts
unset CURLEVEL
CURLEVEL="$(head -c 1 /run/runit.runlevel 2>/dev/null)"
if [ -z "$CURLEVEL" ]; then
CURLEVEL=2
fi
exec printf "N $CURLEVEL"

András

-- 
 Expect disappointment and you won't be disappointed.



Bug#1002733: Improve /sbin/runlevel for runlevels 0 and 6

2021-12-28 Thread Andras Korn
Package: runit-init
Version: 2.1.2-43
Severity: normal
Tags: patch upstream

Hi,

currently /sbin/runlevel always prints "2 N", which is fine most of the time.

However, runit can invoke initscripts that change behaviour based on
runlevel; for example, the kexec initscript from the kexec package has this:

if [ -d /run/systemd/system ]; then
systemctl list-jobs systemd-kexec.service | grep -q 
systemd-kexec.service
if [ $? -ne 0 ]; then
exit 0
fi
else if [ -x /sbin/runlevel -a "$(runlevel | awk '{ print $2 }')" != "6" ]; 
then 
exit 0
fi
fi

This means that when /etc/runit/3 invokes /etc/rc6.d/K??kexec, the
initscript will just exit instead of performing a kexec(8) and you end up with
a plain reboot.

If /sbin/runlevel looked like this instead:

#!/bin/sh
# This only does anything useful if /etc/runit/3 updates /run/runit.runlevel 
before starting stop scripts
if [ -s /run/runit.runlevel ]; then
CURLEVEL="$(head -c 1 /run/runit.runlevel)"
else
CURLEVEL=2
fi
exec printf "N $CURLEVEL"

And the following patch were applied to /etc/runit/3:


--- a/3   2021-12-28 15:03:01.179691038 +0100
+++ b/3   2021-12-28 15:03:30.266943564 +0100
@@ -9,6 +9,7 @@
 # executable bit set on 'noexec' filesystem as executable, and /run
 # often is mounted as 'noexec'.
 [ $(stat -c %a /run/runit.reboot) = 100 ] && LAST=6
+printf "$LAST" >/run/runit.runlevel
 
 echo 'Waiting for services to stop...'
 sv force-stop /etc/service/*


Then the kexec package would work.

If you're willing to accept this patch I can also update the runlevel(8) 
manpage.

I'm also fine with /etc/runit/3 creating /run/runit.runlevel.$LAST and
/sbin/runlevel checking for those in some order (this would avoid calling
head(1) in /sbin/runlevel), if you prefer.

András

Ps. incidentally, happy new year!

-- System Information:
Architecture: amd64 (x86_64)

Init: runit (via /run/runit.stopit)

-- 
   I'm sure if Vimes were to say 'Jump!', Detritus would say 'What colour?'



Bug#993602: /etc/runit/nosync should not have been moved to /run

2021-09-05 Thread Andras Korn
On Sat, Sep 04, 2021 at 05:38:50PM +0200, lorenzo wrote:

> > Not wanting to invoke sync() on shutdown is a permanent property of a
> > system, not an ephemeral one. Thus, the flag file for this behaviour
> > should be in a permanent location (like /etc/runit, where it
> > originally was), not under /run, where it would need to be created on
> > every boot.
> 
> The only issue with reverting to /etc is that as long as /etc is mounted
> readonly it will not be possible to write this file: but as the use
> case is a container I guess the file will be written during the
> container setup, before runtime, right?

Exactly. This isn't something you need to change at runtime, ever.

A case could even be made for runit to automatically skip sync in
containers, but considering runit's minimalist design, that'd be creeping
featurism.

Best regards,

András

-- 
  Ha a vasutallomas az, ahol a vasut megall, akkor a munkaallomas...



Bug#942382: A living fork of dstat seems to be available

2021-09-04 Thread Andras Korn
Package: dstat
Version: 0.7.4-6.1
Followup-For: Bug #942382

Hi,

there seems to be a fork of dstat called dool, with some recent commits 
indicating that it's still being developed:

https://github.com/scottchiefbaker/dool

While unfortunately, #942382 is still present in it, maybe Debian could switch 
to this fork from the archived original dstat codebase?

Best regards,

András

-- System Information:
Debian Release: 11.0
  APT prefers unstable
  APT policy: (350, 'unstable'), (350, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-8-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=hu_HU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8
Shell: /bin/sh linked to /bin/bash
Init: runit (via /run/runit.stopit)
LSM: AppArmor: enabled

Versions of packages dstat depends on:
ii  python3  3.9.2-3
ii  python3-six  1.16.0-2

dstat recommends no packages.

dstat suggests no packages.

-- no debconf information

-- 
My cold is better this morning; I've been practising all night.



Bug#993602: /etc/runit/nosync should not have been moved to /run

2021-09-03 Thread Andras Korn
Package: runit
Version: 2.1.2-42
Severity: normal

Hi,

I'm the guy who originally submitted the patch to support a 'nosync' flag
file to avoid syncing on shutdown.

I noted with some amazement in the changelog for version 2.1.2-42 that this
file had been moved to /run sometime in the past, with no mention in the
changelog.

I think this change should be reverted.

The use case of the nosync flag file is when running runit in a container
like LXC or linux-vserver. When you stop one of these (or hundreds of these
simultaneously), you don't want them to sync() because the host itself isn't
stopping, so there is neither a need nor a benefit to invoking sync().

Not wanting to invoke sync() on shutdown is a permanent property of a
system, not an ephemeral one. Thus, the flag file for this behaviour should
be in a permanent location (like /etc/runit, where it originally was), not
under /run, where it would need to be created on every boot.

Best regards,

András

-- System Information:
Debian Release: 11.0
  APT prefers unstable
  APT policy: (350, 'unstable'), (350, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-8-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=hu_HU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8
Shell: /bin/sh linked to /bin/bash
Init: runit (via /run/runit.stopit)
LSM: AppArmor: enabled

-- 
  A computer's attention span is as long as it's power cord.



Bug#991896: New upstream version 2.1.0 available

2021-08-04 Thread Andras Korn
Package: zfs-dkms
Version: 2.0.3-9
Severity: wishlist

Hi,

https://github.com/openzfs/zfs/releases/tag/zfs-2.1.0 has been out for more 
than a month.

It would be great if it could be packaged for Debian because it contains many 
interesting new features.

Thanks!

-- System Information:
Debian Release: 11.0
  APT prefers unstable
  APT policy: (350, 'unstable'), (350, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-6-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=hu_HU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8
Shell: /bin/sh linked to /bin/bash
Init: runit (via /run/runit.stopit)
LSM: AppArmor: enabled



Bug#978065: lxc: After upgrade lxc to 4.0.5-1, cannot start with lxc.cap.drop sys_admin

2021-06-25 Thread Andras Korn
On Fri, Jun 11, 2021 at 09:59:51PM +0200, Pierre-Elliott Bécue wrote:

Hi,

> > FWIW, both host and guest use runit, so systemd is not involved; runit 
> > doesn't interfere with cgroups or capabilities on its own in any way.
> 
> It's not possible if the init in the container is systemd, as far as I
> know.

That's as may be, but my systems don't use systemd; like I said above, it's all 
runit. I'm still hitting the issue.

András

-- 
   Mary had a little lamb, she tied it to a pylon.
  A thousand volts went up its ass and turned it into Nylon.



Bug#987266: preinst check for kernel release > 255 may no longer be needed

2021-04-20 Thread Andras Korn
Package: libc6
Version: 2.31-11
Severity: normal

Hi,

due to 
https://salsa.debian.org/glibc-team/glibc/-/commit/6ddfa57577af0d96df9ddd7be401f5ce9a9bcc0f
 (a commit from 2004) the preinst script for glibc checks whether the "z" in 
the "x.y.z" of the kernel version is less than 255. If yes, the package refuses 
to install.

I hit this problem on a box with a custom 4.9.266 kernel.

Based on this lkml thread: 
https://lore.kernel.org/lkml/7pR0YCctzN9phpuEChlL7_SS6auHOM80bZBcGBTZPuMkc6XjKw7HUXf9vZUPi-IaV2gTtsRVXgywQbja8xpzjGRDGWJsVYSGQN5sNuX1yaQ=@protonmail.com/T/,
 the check is no longer needed because the kernel caps the version code it 
reports to 255, even if uname prints a higher number.

Of course, you could conceivably still hit the problem with earlier kernels, so 
I suppose the logic of the check should be modified, not removed entirely, to 
be technically correct.

If forced at gunpoint to make a guess, I would guess, though, that removing the 
check would have very little actual impact; it also doesn't protect the user 
from installing a kernel with an unsupported version number after having 
installed glibc.

Best regards,

András

-- 
 A ham sandwich is better than nothing. Nothing is better than eternal
 happiness. So a ham sandwich is better than eternal happiness.



Bug#983726: runsv(8) incorrect regarding control/[dx]

2021-04-19 Thread Andras Korn
On Sat, Apr 10, 2021 at 11:11:05PM +0200, Lorenzo wrote:

Hi,

> > runsv(8) says:
> > 
> > CUSTOMIZE CONTROL
> >For each control character c sent to the control pipe, runsv
> > first checks if service/control/c exists and is executable. If so, it
> >starts service/control/c and waits for it to terminate, before
> >interpreting the command. If the program exits with return
> > code 0, runsv refrains from sending the service the corresponding
> > signal. The command o is always considered as command u. On command d
> > first service/control/t is checked, and then service/control/d. On
> > command x first service/control/t is checked, and then
> > service/control/x. The control of the optional log service cannot be
> > customized.
> > 
> > This is, however, not what the code actually does.
> > 
> > [ ... ]
> > 
> > i.e. the control/d or control/x script is only run after runsv sent
> > its child a SIGTERM, not before as the manpage suggests.
> 
> Right. Also it looks that with control/[dx] an override on the CONT
> signal is disregarded. It's reasonable but it should be documented too.
> 
> > 
> > I would suggest that the code should be changed to reflect the
> > documented behaviour, not vice versa.
> 
> Ideally Gerrit Pape should make a call on this, but it's not
> happening, so:
> Could you elaborate more on why you want to update the code instead of
> fixing the manpage?
> 
> If you add an override for the TERM signal it would be run before [dx],
> so what you want is a way to do a custom action that is not run when
> the service receives a plain TERM signal but is run only when runsv is
> told to set the service down or to exit.
> Do you have an example/use case for this?

Nothing specific; I was basing my recommendation on the following:

 * this code and documentation has been around for a long time;

 * this part of the code is relatively rarely used;

 * there are likely setups that were created on the assumption that the
   documentation was correct, but not tested extensively (I know I'm guilty
   of this). (I have, of course, no idea how many setups exist that rely on
   the existing but undocumented behaviour.)

Additionally, the documentation as it is now is clear and straightforward,
with few special cases; while the actual behaviour of runsv, while I agree
it can make sense, is more difficult to explain clearly.

In the case of runsv, I suppose I see the manpage as a specification for,
not an explanation of, what the code does.

All of these arguments are weak. The main point is that the documentation
should accurately reflect what the code does; I realize that fixing the
documentation is easier. I also see the merit in your arguments.

> > Credits to https://serverfault.com/users/135556/keith for pointing
> > the bug out.
> 
> I can only see some info about the reporter profile, do you have a link
> where I can read what was the reporter complaining of?

Sure. In
https://serverfault.com/questions/612458/runit-does-not-kill-process-on-sv-stop-or-sv-reload/625822,
someone was looking for a way to stop child processes of a runit-supervised
service on service shutdown. I suggested a custom 'd' script, and "Keith"
pointed out the discrepancy between the documentation and the code in a
his comment 
https://serverfault.com/questions/612458/runit-does-not-kill-process-on-sv-stop-or-sv-reload/625822#comment1375192_625822.

(It's also true that in this specific case, the poster would need a 't'
script in addition to the 'd' script even if the documentation were correct;
otherwise 'sv t' would still leave his sub-processes around.)

Best regards,

András

-- 
 To whom the gods destroy, they first teach Windows...



Bug#983726: runsv(8) incorrect regarding control/[dx]

2021-02-28 Thread Andras Korn
Package: runit
Version: 2.1.2-39.1
Severity: normal
Tags: upstream

Hi,

runsv(8) says:

CUSTOMIZE CONTROL
   For each control character c sent to the control pipe, runsv first
   checks if service/control/c exists and is executable. If so, it
   starts service/control/c and waits for it to terminate, before
   interpreting the command. If the program exits with return code 0,
   runsv refrains from sending the service the corresponding signal. The
   command o is always considered as command u. On command d first
   service/control/t is checked, and then service/control/d. On command
   x first service/control/t is checked, and then service/control/x. The
   control of the optional log service cannot be customized.

This is, however, not what the code actually does.

For the 'd' control character 
(https://github.com/vulk-archive/runit/blob/master/src/runsv.c#L324):

  case 'd': /* down */
s->want =W_DOWN;
update_status(s);
if (s->state == S_RUN) stopservice(s);
break;

'x' is handled analogously.

The stopservice() function 
(https://github.com/vulk-archive/runit/blob/master/src/runsv.c#L246) looks like 
this:

void stopservice(struct svdir *s) {
  if (s->pid && ! custom(s, 't')) {
kill(s->pid, SIGTERM);
s->ctrl |=C_TERM;
update_status(s);
  }
  if (s->want == W_DOWN) {
kill(s->pid, SIGCONT);
custom(s, 'd'); return;
  }
  if (s->want == W_EXIT) {
kill(s->pid, SIGCONT);
custom(s, 'x');
  }
}

i.e. the control/d or control/x script is only run after runsv sent its child a 
SIGTERM, not before as the manpage suggests.

I would suggest that the code should be changed to reflect the documented 
behaviour, not vice versa. Perhaps the following code would work (but I have 
not tested it):

void stopservice(struct svdir *s) {
  if (s->pid) {
if (s->want == W_DOWN) {
  kill(s->pid, SIGCONT);
  if (custom(s, 'd')) return;
}
if (s->want == W_EXIT) {
  kill(s->pid, SIGCONT);
  if (custom(s, 'x')) return;
}
if (! custom(s, 't')) {
  kill(s->pid, SIGTERM);
  s->ctrl |=C_TERM;
  update_status(s);
}
  }
}

Credits to https://serverfault.com/users/135556/keith for pointing the bug out.

Best regards,

András

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (350, 'unstable'), (350, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-3-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=hu_HU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8
Shell: /bin/sh linked to /bin/bash
Init: runit (via /run/runit.stopit)
LSM: AppArmor: enabled

Versions of packages runit depends on:
ii  libc6   2.31-9
ii  sysuser-helper  1.3.5.1

Versions of packages runit recommends:
ii  runit-init  2.1.2-39.1

Versions of packages runit suggests:
ii  socklog  2.1.0+repack-4+b1

-- Configuration Files:
/etc/runit/1 changed [not included]
/etc/runit/2 changed [not included]
/etc/runit/3 changed [not included]

-- no debconf information

-- 
Laughing stock: cattle with a sense of humour.



Bug#978065: lxc: After upgrade lxc to 4.0.5-1, cannot start with lxc.cap.drop sys_admin

2021-01-25 Thread Andras Korn
Hi,

I hit the same issue.

I upgraded from 1:4.0.4-6 to 1:4.0.5-2, and from kernel 5.9.0-4-amd64 to 
5.10.0-2-amd64, and some of my containers that used to work before don't work 
anyomre. The ones that still work don't drop sys_admin.

stracing lxc-start I see this:

openat2(33, "/sys/fs/cgroup", 
{flags=O_RDONLY|O_CLOEXEC|O_PATH, 
resolve=RESOLVE_NO_XDEV|RESOLVE_NO_MAGICLINKS|RESOLVE_NO_SYMLINKS|RESOLVE_BENEATH},
 24) = -1 EXDEV (Invalid cross-device link)

The corresponding message from lxc-start with loglevel debug is:

lxc-start unifiadmin 20210125231743.129 ERRORconf - 
conf.c:lxc_mount_auto_mounts:727 - Invalid cross-device link - Failed to mount 
"/sys/fs/cgroup"

Some context from lxc-start log output:

lxc-start unifiadmin 20210125231742.854 INFO start - start.c:lxc_init:837 - 
Container "unifiadmin" is initialized
lxc-start unifiadmin 20210125231742.876 WARN cgfsng - 
cgroups/cgfsng.c:mkdir_eexist_on_last:1152 - File exists - Failed to create 
directory "/sys/fs/cgroup/cpuset//lxc.monitor.unifiadmin"
lxc-start unifiadmin 20210125231742.886 INFO cgfsng - 
cgroups/cgfsng.c:cgfsng_monitor_create:1368 - The monitor process uses 
"lxc.monitor.unifiadmin" as cgroup
lxc-start unifiadmin 20210125231742.904 WARN cgfsng - 
cgroups/cgfsng.c:mkdir_eexist_on_last:1152 - File exists - Failed to create 
directory "/sys/fs/cgroup/cpuset//lxc.payload.unifiadmin"
lxc-start unifiadmin 20210125231742.916 INFO cgfsng - 
cgroups/cgfsng.c:cgfsng_payload_create:1471 - The container process uses 
"lxc.payload.unifiadmin" as cgroup
lxc-start unifiadmin 20210125231742.944 INFO start - start.c:lxc_spawn:1700 
- Cloned CLONE_NEWNS
lxc-start unifiadmin 20210125231742.944 INFO start - start.c:lxc_spawn:1700 
- Cloned CLONE_NEWPID
lxc-start unifiadmin 20210125231742.945 INFO start - start.c:lxc_spawn:1700 
- Cloned CLONE_NEWUTS
lxc-start unifiadmin 20210125231742.945 INFO start - start.c:lxc_spawn:1700 
- Cloned CLONE_NEWIPC
lxc-start unifiadmin 20210125231742.945 INFO start - start.c:lxc_spawn:1700 
- Cloned CLONE_NEWNET
lxc-start unifiadmin 20210125231742.945 DEBUGstart - 
start.c:lxc_try_preserve_namespaces:166 - Preserved mnt namespace via fd 31
lxc-start unifiadmin 20210125231742.945 DEBUGstart - 
start.c:lxc_try_preserve_namespaces:166 - Preserved pid namespace via fd 32
lxc-start unifiadmin 20210125231742.946 DEBUGstart - 
start.c:lxc_try_preserve_namespaces:166 - Preserved uts namespace via fd 33
lxc-start unifiadmin 20210125231742.946 DEBUGstart - 
start.c:lxc_try_preserve_namespaces:166 - Preserved ipc namespace via fd 34
lxc-start unifiadmin 20210125231742.946 DEBUGstart - 
start.c:lxc_try_preserve_namespaces:166 - Preserved net namespace via fd 35
lxc-start unifiadmin 20210125231742.949 INFO cgfsng - 
cgroups/cgfsng.c:cgfsng_setup_limits_legacy:2881 - Limits for the legacy cgroup 
hierarchies have been setup
lxc-start unifiadmin 20210125231742.955 WARN cgfsng - 
cgroups/cgfsng.c:cgfsng_setup_limits:2942 - Invalid argument - Ignoring cgroup2 
limits on legacy cgroup system
lxc-start unifiadmin 20210125231743.315 INFO network - 
network.c:instantiate_veth:285 - Retrieved mtu 1500 from intra
lxc-start unifiadmin 20210125231743.666 INFO network - 
network.c:instantiate_veth:333 - Attached "veth-unifi" to bridge "intra"
lxc-start unifiadmin 20210125231743.687 DEBUGnetwork - 
network.c:instantiate_veth:449 - Instantiated veth tunnel "veth-unifi <--> 
vethv7jzuF"
lxc-start unifiadmin 20210125231743.699 WARN start - start.c:do_start:1166 
- Using /dev/null from the host for container init's standard file descriptors. 
Migration will not work
lxc-start unifiadmin 20210125231743.704 INFO start - start.c:do_start:1198 
- Unshared CLONE_NEWCGROUP
lxc-start unifiadmin 20210125231743.731 DEBUGstorage - 
storage/storage.c:get_storage_by_name:211 - Detected rootfs type "dir"
lxc-start unifiadmin 20210125231743.734 DEBUGconf - 
conf.c:lxc_mount_rootfs:1259 - Mounted rootfs "/var/lib/lxc/unifiadmin/rootfs" 
onto "/usr/lib/x86_64-linux-gnu/lxc/rootfs" with options "(null)"
lxc-start unifiadmin 20210125231743.738 INFO conf - 
conf.c:setup_utsname:751 - Set hostname to "unifiadmin"
lxc-start unifiadmin 20210125231743.740 DEBUGnetwork - 
network.c:lxc_network_setup_in_child_namespaces_common:3510 - Network device "" 
has been setup
lxc-start unifiadmin 20210125231743.977 DEBUGnetwork - 
network.c:setup_hw_addr:3360 - Mac address "00:16:3e:11:22:33" on "eth0" has 
been setup
lxc-start unifiadmin 20210125231743.103 DEBUGnetwork - 
network.c:lxc_network_setup_in_child_namespaces_common:3510 - Network device 
"eth0" has been setup
lxc-start unifiadmin 20210125231743.103 INFO network - 
network.c:lxc_setup_network_in_child_namespaces:3532 - Network has been setup
lxc-start unifiadmin 20210125231743.116 DEBUGconf - conf.c:mount_entry:1943 
- Remounting "/shared/cache/apt/lists" on 
"/usr/lib/x86_64-linux-gnu/lxc/rootfs/

Bug#979995: There should be a sensible compile time default for the location of the file that contains trusted CA certificates

2021-01-14 Thread Andras Korn
On Wed, Jan 13, 2021 at 05:12:39PM -0800, Ryan Tandy wrote:

Hi,

> > Can you somehow make the library complain very loudly when an attempt is
> > made to use CACERTDIR, but the setting is ignored?
> 
> This is not sarcastic, but a good faith question: if it had printed
> something to stderr, would you have seen it?

Yes. I have sssd logging to stderr and use svlogd to write the messages to
files. Whatever the library printed on stderr would have appeared among the
sssd log messages.

> I don't think I have any way to
> make something appear in (for example) sssd's own log file.

Probably not. The realistic alternatives are stderr and syslog.

> In fact, it does already log a warning, but I suppose most applications
> using the library probably don't enable any log level.

Exactly. I had to use an (at the time) undocumented setting to turn up
libldap debugging in sssd to see what was going on.

> https://git.openldap.org/openldap/openldap/-/blob/OPENLDAP_REL_ENG_2_4/libraries/libldap/tls_g.c#L187-190

Yes, this is the warning I eventually saw, once I knew where to look.

Since a configuration where no CA certificates are trusted and you still try
to use TLS is unlikely to be useful, I think a loud warning to stderr would
be appropriate in this case.

> On Wed, Jan 13, 2021 at 01:44:07PM +0100, Andras Korn wrote:
> > OK, looking further, part of the problem is that I didn't have
> > libldap-common installed, thus no /etc/ldap/ldap.conf.
> > 
> > Since this (and the accompanying manpage) is all that libldap-common
> > contains: what's the rationale for having these in a separate package?
> 
> Policy 8.2: "If your package contains files whose names do not change with
> each change in the library shared object version, you must not put them in
> the shared library package."

Okay, that makes sense. :(

I'm not sure what a good solution would be. It doesn't seem appropriate to
Depends on libldap-common, because libldap can definitely be used without
it; on the other hand, Debian does have sensible defaults for CAECERT & co,
but those are only enabled when the user installs a package that's merely
Recommended and thus easily missed.

As a user, my expectation would be not to have to configure CACERT* for
distribution packages, because the distribution has a well-known location
for system-wide trusted CA certificates; I would expect all packages to
default to using that. The status quo appears to violate the principle of
least surprise.

> > The libldap package only Recommends libldap-common (which is why I didn't
> > have it); however, it is libldap-common that enables the sensible defaults.
> > 
> > Why shouldn't libldap come with the sensible defaults itself?
> 
> It's your decision whether to install Recommends or not, but AFAIK it's
> generally not considered a bug if some feature or behaviour is missing when
> Recommends are not installed.

I don't think it's worthwhile to debate whether this is technically a bug or
not; it's an unfortunate situation, and I hope there is some way we (well,
mostly you and the other maintainers) can improve it.

> Why isn't the default in the code of libldap → this is upstream's decision,
> and I won't introduce a Debian-local change to override it, sorry.

In fact, it seems wrong that these defaults (and configuration) should be
specific to libldap; to me it would seem appropriate for Debian to ship
libgnutls so that by default it uses the CA certificate store of the
distribution. The upstream default of not trusting any certificates by
default makes sense for the upstream project, but not, IMO, for a
distribution that's expected to be integrated and self-consistent.

András

-- 
 Optimist: Someone who doesn't know all the facts yet.



Bug#979995: There should be a sensible compile time default for the location of the file that contains trusted CA certificates

2021-01-13 Thread Andras Korn
On Tue, Jan 12, 2021 at 10:47:22AM -0800, Ryan Tandy wrote:

> > On 2021-01-12 Andras Korn  wrote:
> > > I think I shouldn't need to specify `ldap_tls_cacert =
> > > /etc/ssl/certs/ca-certificates.crt` when using a Debian package, since
> > > this is the default location of trusted CA certificates in Debian.
> > > Configuration should only be necessary for non-default setups.
> 
> The libldap-common package ships a default /etc/ldap/ldap.conf which
> contains exactly this default TLS_CACERT value. It should be picked up
> automatically by programs using the library. If sssd does something to
> override that, I don't think libldap can be blamed.

OK, looking further, part of the problem is that I didn't have
libldap-common installed, thus no /etc/ldap/ldap.conf.

Since this (and the accompanying manpage) is all that libldap-common
contains: what's the rationale for having these in a separate package?

The libldap package only Recommends libldap-common (which is why I didn't
have it); however, it is libldap-common that enables the sensible defaults.

Why shouldn't libldap come with the sensible defaults itself?

András

-- 
  For Sale: parachute, used once, never opened, small stain.



Bug#979995: There should be a sensible compile time default for the location of the file that contains trusted CA certificates

2021-01-13 Thread Andras Korn
On Tue, Jan 12, 2021 at 10:47:22AM -0800, Ryan Tandy wrote:

Hi,

thanks for clearing up some misunderstandings.

> On Tue, Jan 12, 2021 at 07:04:41PM +0100, Andreas Metzler wrote:
> > On 2021-01-12 Andras Korn  wrote:
> > > I think I shouldn't need to specify `ldap_tls_cacert =
> > > /etc/ssl/certs/ca-certificates.crt` when using a Debian package, since
> > > this is the default location of trusted CA certificates in Debian.
> > > Configuration should only be necessary for non-default setups.
> 
> The libldap-common package ships a default /etc/ldap/ldap.conf which
> contains exactly this default TLS_CACERT value. It should be picked up
> automatically by programs using the library. If sssd does something to
> override that, I don't think libldap can be blamed.
> 
> > GnuTLS offers a sane compile default for the trust store (See
> > gnutls_x509_trust_list_add_system_trust()), which can be used by the
> > application. - I have therefore retitled the bug.
> > 
> > From the upstream bug report:
> > 2021-01-12 17:52:00.657730500 [be[ldap]] [sss_ldap_debug] (0x4000): 
> > libldap: TLS: warning: cacertdir not implemented for gnutls
> > 
> > GnuTLS has supported using a directory instead of a file since version
> > 3.3.6 (released 2014-07-23), so it looks like a missing thing in libldap.
> 
> There are two things here:
> 
> 1. libldap 2.4.x indeed does not support TLS_CACERTDIR when linked with
> GnuTLS. This is fixed in the 2.5 branch. (ITS#8155)
> 
> 2. It is intentional by upstream that *no* CA certificates are used when
> there is no explicit TLS_CACERT or TLS_CACERTDIR configured. There's some
> discussion about this in ITS#5582. (Bearing in mind that in Debian we *do*
> configure a default TLS_CACERT in ldap.conf).
> 
> <https://bugs.openldap.org/show_bug.cgi?id=5582>
> 
> Is there still something you think needs to be changed or fixed in the
> libldap package?

I'm not sure. Can you somehow make the library complain very loudly when an 
attempt is made to use CACERTDIR, but the setting is ignored?

The sssd issue was very hard to trobuleshoot because initially all I saw after 
a dist-upgrade was "unknown error".

András

-- 
   If debugging is removing bugs, then programming must be putting them in.



Bug#979995: There should be a sensible compile time default for the location of the file that contains trusted CA certificates

2021-01-12 Thread Andras Korn
Package: libgnutls30
Version: 3.7.0-3
Severity: wishlist

Hi,

I was just bitten by https://github.com/SSSD/sssd/issues/5444.

Briefly:

 * sssd relies on libldap to query LDAP servers.
 * libldap can be linked against libssl (openssl) or gnutls for SSL/TLS support.
 * libssl supports an ldap_tls_cacertdir option; you can point it to 
/etc/ssl/certs and it'll trust all CA certificates that are in this directory.
 * gnutls doesn't have this cacertdir mechanism and needs `ldap_tls_cacert = 
/etc/ssl/certs/ca-certificates.crt` instead.
 * my sssd.conf only had ldap_tls_cacertdir, not ldap_tls_cacert; thus, gnutls 
didn't know which CA certificates to trust and failed to validate my LDAP 
server certificates.
 * The root cause of the problem only became visible after enabling LDAP 
library debugging in sssd.conf. 

I think I shouldn't need to specify `ldap_tls_cacert = 
/etc/ssl/certs/ca-certificates.crt` when using a Debian package, since this is 
the default location of trusted CA certificates in Debian. Configuration should 
only be necessary for non-default setups.

Best regards,

András

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

Init: runit (via /run/runit.stopit)

-- no debconf information



Bug#977600: Please don't conflict with other log daemons

2020-12-17 Thread Andras Korn
Package: socklog
Version: 2.1.0-8.1
Severity: normal

Hi,

it's entirely valid and possible to run socklog to handle locally generated
logs and e.g. syslog-ng to handle remote syslog clients.

The new Conflicts: in the socklog package makes this unnecessarily hard in
an attempt to prevent people from shooting themselves in the foot.

Please also see #506173 and #893882.

At the extreme, there could be a socklog-bin package that only provides the
binaries with no configuration, no automatic service startup; and a socklog
package which retains the Conflicts and Depends on socklog-bin.

Thanks!

András

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

Kernel: Linux 4.4.244-vs2.3.9.9 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=hu_HU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8
Shell: /bin/sh linked to /bin/bash
Init: runit (via /run/runit.stopit)

Versions of packages socklog depends on:
ii  adduser  3.118
ii  libc62.31-4

Versions of packages socklog recommends:
ii  ipsvd1.0.0-3.1+b1
ii  runit2.1.2-36
pn  socklog-run  

socklog suggests no packages.

-- no debconf information



Bug#975437: Regression: no longer accepts '--splitting process' or '--secure-splitting'

2020-11-22 Thread Andras Korn
Package: clsync
Version: 0.4.5-1
Severity: normal

Hi,

with clsync 0.4.2-1, the documented "--splitting process" or 
"--splitting=process" argument worked.

In the current version, it gives the error message

Error: argument "process" can't be parsed as a number
Error: Unable to process option "splitting" (with argument: "process") from 
"cli_arguments"

Similarly, --secure-splitting is not recognized:

clsync: unrecognized option '--secure-splitting'

However, the manpage documents it:

SECURITY OPTIONS
   --secure-splitting
  Implies "--splitting=process --check-execvp-arguments 
--seccomp-filter --forbid-devices"

Confusingly, --splitting *will* accept a numerical argument, but it's unclear 
what it'll do.

Looking through the changelog, I think it's disabling seccomp support that
broke these options. Indeed, the source confirms it, at least for 
secure-splitting:

# ifdef SECCOMP_SUPPORT
{"secure-splitting",no_argument,NULL,   
SECURESPLITTING},
# endif

Can't you disable seccomp support only for the architectures where it's not
usable?

Thanks and best regards,

András

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

Kernel: Linux 4.4.244-vs2.3.9.9 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=hu_HU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8
Shell: /bin/sh linked to /bin/bash
Init: runit (via /run/runit.stopit)

Versions of packages clsync depends on:
ii  init-system-helpers  1.58+devuan1
ii  libc62.31-4
ii  libcgroup1   0.41-10
ii  libglib2.0-0 2.66.3-1
ii  lsb-base 11.1.0

Versions of packages clsync recommends:
ii  rsync  3.2.3-2

clsync suggests no packages.

-- no debconf information

-- 
   Life is complex. It consists of real and imaginary parts.



Bug#954343: Error message 'Unable to parse package file (1)' unhelpful

2020-03-25 Thread Andras Korn
On Sat, Mar 21, 2020 at 10:34:24AM +0100, David Kalnischkies wrote:

> On Fri, Mar 20, 2020 at 03:41:06PM +0100, Andras Korn wrote:
> > with the sources.list entry:
> > 
> > deb http://winswitch.org/beta/ buster main
> 
> While the error message certainly doesn't help much, I have to highlight
> that this repository is currently broken. Looks like a mistake in their
> transition from python2 to python3 guessing by all the "b'…'" currently in
> https://winswitch.org/beta/buster/Release
> 
> apt refuses such a Release file by default as insecure (missing Date,
> missing all hashes, … due to the incorrect field names), have you
> perhaps forced it to go along anyhow?

I did.

I don't doubt that the repository is broken (even though it happens to work
with older apt); I think the messages apt prints for broken repositories
should make it easier to diagnose the problem.

In this case, apt did complain about weak security (I don't have the exact
wording anymore, and the repository seems fixed), but that's not so unusual
for 3rd party repositories.

Best regards,

András

-- 
  A soldier who survived mustard gas and pepper spray is a seasoned veteran.



Bug#954343: Error message 'Unable to parse package file (1)' unhelpful

2020-03-20 Thread Andras Korn
Package: apt
Version: 2.0.0
Severity: normal

Hi,

with the sources.list entry:

deb http://winswitch.org/beta/ buster main

apt-get as of 2.0 update prints the unhelpful error message:

E: Unable to parse package file  (1)

apt 1.8.4 has no problem with this repository.

I could only find out which sources.list entry was causing the issue by way of 
successive elimination.

I would suggest the following:

1. identify the type of file in the message (e.g. Packages file, Release file, 
whatever); 'package file' is vague.

2. in the message, identify the sources.list entry the problematic file is 
related to.

3. the message should say why the file in question could not be parsed; at the 
very least, print the number of the line where the problem was encountered.

Thanks!

András

-- 
There will be a rain dance Friday, weather permitting.

-- System Information:
Debian Release: bullseye/sid
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Locale: LANG=en_US.UTF-8, LC_CTYPE=hu_HU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: runit (via /run/runit.stopit)



Bug#945442: Possible to backspace past beginning of string, which appears to be identical to having pressed Enter immediately, without any backspace

2020-03-03 Thread Andras Korn
On Mon, Mar 02, 2020 at 01:45:26PM -0500, Marvin Renich wrote:

Hi,

> I don't have a github account, and do not wish to get one for this.
> Will someone (Debian maintainer for neomutt, or someone else interested
> in this bug) please file this with upstream as a separate bug, pointing
> out that the other github issue is not the same as this bug, even though
> some of the same code may be involved.

I filed https://github.com/neomutt/neomutt/issues/2161.

Best regards,

András

-- 
Microsoft follows standards the same way fish follow migrating caribou.



Bug#945442: Possible to backspace past beginning of string, which appears to be identical to having pressed Enter immediately, without any backspace

2020-03-02 Thread Andras Korn
On Mon, Mar 02, 2020 at 03:18:54PM +0100, Andreas Henriksson wrote:

> > Your rationale for downgrading the severity of an issue like this is that it
> > doesn't bother you personally?
> 
> My rationale, if you must know, is that if this is an important issue,
> then the people who consider it an important issue will ofcourse work on
> getting it fixed.

I'm curious -- what exactly do you have in mind? How should the users
bothered by this bug "work on it"? What would you consider a reasonable,
acceptable level of effort?

> There's nothing in debian policy (the document who defines the severity
> levels for the bug tracking system) that says 'If you raise the severity
> of a bug report then "someone else" has to do the work for you'.

Nobody "has" to "do the work". It's just that if the work is not done, the
issue stays open. If it meets the definition of a "grave" bug, then it stays
grave. You're right in that if it's important enough for *the right people*,
then it'll get fixed eventually. It's entirely possible that the the users
affected by a bug are not the right ones to effect a fix.

You can argue with the severity, but I don't think you should downgrade it
for frivolous reasons like "I'm not interested in fixing it", or "I don't
like the attitude of a commenter; I think they're being lazy."

> Scratch your own itch.

Sorry, no, that's not how this works. I'll scratch my own itch if/when I
can, and also the itches of others if/when I can. This is not a bug I can
realistically fix, but that doesn't affect either its severity or its
existence.

You don't get to downgrade a bug that meets the criteria for being "grave"
just because you aren't personally affected by it, or because the user who
reported it (or someone who commented on it) is unable or unwilling to fix
it himself/herself. I'm sure you don't need me to tell you that.

> The previously provided suggestion that this might lead to data loss is
> a bit far fetched if you ask me.

That's a valid argument. FWIW, I have no opinion. I filed the bug with a
normal priority and won't insist on it being grave. If you think you can
downgrade it for the right reasons, go ahead (as far as I'm concerned).

Best regards,

András

-- 
  Get married and share the problems you didn't know you had.



Bug#945442: Possible to backspace past beginning of string, which appears to be identical to having pressed Enter immediately, without any backspace

2020-03-02 Thread Andras Korn
On Mon, Mar 02, 2020 at 02:22:44PM +0100, Andreas Henriksson wrote:

Hi,

> > when mutt prompts for something (e.g. To: address, Subject etc.) it
> > previously was possible to just keep pressing backspace until whatever
> > default text was there disappeared.
> > 
> > As of this version, it's possible to keep erasing back beyond the first
> > character of the string;
> [...]
> 
> On Fri, Feb 14, 2020 at 11:31:53AM -0500, Marvin Renich wrote:
> > Control: -1 severity grave
> > 
> > I'm increasing the severity of this bug, as it can cause unintended
> [...]
> 
> I just NMUed a new upstream version of neomutt, 20191207+dfsg.1-1,
> which fixes the two other outstanding RC bugs.
> It seems I can still reproduce this issue however (with the first prompt
> I get which is the imap password prompt for me).
> 
> This seems somewhat like a possible UX design fail. This is done
> upstream and not in debian. Do you know if there's already been any
> discussion regarding this upstream? If not could you please file an
> upstream bug report about this?

https://github.com/neomutt/neomutt/issues/2002

> The behaviour hasn't really bothered me and I probably wouldn't even
> have noticed it if it wasn't for this bug showing up on the RC bug radar
> while doing my NMU, so I'm quite tempted to downgrade severity again.

Your rationale for downgrading the severity of an issue like this is that it
doesn't bother you personally?

Best regards,

András

-- 
 My wife said I needed to grow up. I was speechless.
 It's hard to say anything when you have 45 gummy bears in your mouth.



Bug#951841: New upstream version available

2020-02-22 Thread Andras Korn
Package: rawtherapee
Version: 5.7-1
Severity: wishlist

Hi,

5.8 was released on February 4. Please package it.

No packaging changes seem necessary from 5.7 (at first glance).

Thanks!

András

-- System Information:
Init: runit (via /run/runit.stopit)



Bug#951457: Please ship gdbm module

2020-02-16 Thread Andras Korn
Package: zsh
Version: 5.7.1-1+b1
Severity: wishlist

Hi,

zshmodules(1) mentions the "zsh/db/gdbm" module, but it's not actually shipped 
by the package:

% zmodload zsh/db/gdbm
zsh: failed to load module `zsh/db/gdbm': 
/usr/lib/x86_64-linux-gnu/zsh/5.7.1/zsh/db/gdbm.so: cannot open shared object 
file: No such file or directory

I suppose (paraphrasing xkcd) this module is like a blockchain or a
grappling hook: if you encounter a situation where it's the right solution,
it's very cool, but it happens rarely. :)

I think I have just found such a situation and was disappointed to see that
the gdbm module wasn't available.

Thanks

András

-- Package-specific info:
Packages which depend, recommend, suggest or enhance a zsh package and hence 
may provide code meant to be sourced in .zshrc:

Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   Version  Architecture Description
+++-==---===
ii  grml-etc-core  0.16.1   all  core etcetera files for the Grml 
system
ii  grml-scripts   2.9.0amd64Collection of little tools

The following files were modified:

/etc/minimal-shellrc

-- System Information:
Debian Release: 10.0
  APT prefers unstable
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Init: runit (via /run/runit.stopit)

Versions of packages zsh depends on:
ii  libc6   2.29-3
ii  libcap2 1:2.27-1
ii  libtinfo6   6.1+20191019-1
ii  zsh-common  5.7.1-1

Versions of packages zsh recommends:
ii  libc6 2.29-3
ii  libncursesw6  6.1+20191019-1
ii  libpcre3  2:8.39-12+b1

Versions of packages zsh suggests:
pn  zsh-doc  

-- no debconf information



Bug#951192: Missing German localization

2020-02-12 Thread Andras Korn
Package: trac
Version: 1.2.3+dfsg-1
Severity: normal
Tags: l10n

Hi,

trac 1.2 contained /usr/lib/python2.7/dist-packages/trac/locale/de, but trac
1.2.3+dfsg-1 no longer does.

This, naturally, breaks German localization.

The cause is likely this (happens during package build):

catalog trac/locale/de/LC_MESSAGES/tracini.po is marked as fuzzy, skipping
catalog trac/locale/de/LC_MESSAGES/messages-js.po is marked as fuzzy, skipping
catalog trac/locale/de/LC_MESSAGES/messages.po is marked as fuzzy, skipping

Wouldn't a fuzzy catalog be better than no catalog?

András

-- System Information:
Init: runit (via /run/runit.stopit)



Bug#951061: linux_vserver detection broken, easy fix

2020-02-10 Thread Andras Korn
Package: virt-what
Version: 1.19-1
Severity: normal
Tags: patch

Hi,

This is broken in two ways:

# Check for Linux-VServer
if test -e "${root}/proc/self/status" \
   && cat "${root}/proc/self/status" | grep -q "VxID: [0-9]*"; then
echo linux_vserver
if grep -q "VxID: 0$" "${root}/proc/self/status"; then
echo linux_vserver-host
else
echo linux_vserver-guest
fi
fi

1. The regex should be "VxID:[[:space:]]+[1-9][0-9]*" (and use egrep), since
different versions of the linux-vserver patch may use different amounts and
kinds of whitespace in /proc/self/status.

2. linux_vserver-host should never be printed. The host is not running
virtualized; printing that virtualization is available just confuses scripts
that need to detect whether they're running on bare metal or not. When not
running virtualized, the script should print nothing.

It's also inconsistent: the script (naturally) doesn't print anything if the
box would be capable of running kvm guests (whether it's currently running
any or not).

Thus, the code above should be changed to this:

# Check for Linux-VServer
if test -e "${root}/proc/self/status" \
   && egrep -q "VxID:[[:space:]]+[1-9][0-9]*"; then
 echo linux_vserver-guest
fi

Best regards,

András

-- System Information:
Debian Release: 10.0
  APT prefers unstable
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.4.206-vs2.3.9.8 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=hu_HU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: runit (via /run/runit.stopit)

Versions of packages virt-what depends on:
ii  dmidecode  3.2-2
ii  libc6  2.29-3

virt-what recommends no packages.

virt-what suggests no packages.

-- no debconf information

-- 
Help Wanted: Telepath. You know where to apply.



Bug#947952: dpkg-repack compatibility: (optionally?) remove deleted files from /var/lib/dpkg/pkgname.list

2020-01-02 Thread Andras Korn
Package: localepurge
Version: 0.7.3.8
Severity: wishlist

Hi,

dpkg-repack fails when localepurge is in use (see #947951).

If dpkg-repack doesn't get fixed, a possible workaround would be to have
localepurge remove entries from /var/lib/dpkg/pkgname.list as it deletes the
files.

I'm not sure how that would work with --path-exclude.

Thanks!

András

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

Kernel: Linux 4.4.207-vs2.3.9.8 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=hu_HU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: runit (via /run/runit.stopit)

Versions of packages localepurge depends on:
ii  debconf [debconf-2.0]  1.5.73
ii  locales2.29-6
ii  perl   5.30.0-9
ii  procps 2:3.3.12-3+devuan2.1
ii  ucf3.0038+nmu1

localepurge recommends no packages.

Versions of packages localepurge suggests:
pn  bleachbit  
ii  debfoster  2.7-2.1+b1
ii  deborphan  1.7.32

-- debconf information excluded

-- 
   Always address your elders with respect; they could leave you a fortune.



Bug#947951: Fails if packages pruned by localepurge

2020-01-02 Thread Andras Korn
Package: dpkg-repack
Version: 1.46
Severity: normal

Hi,

the localepurge package can be used to automatically remove unneeded locale
files (and thereby conserve disk space as well as inodes).

dpkg-repack used to just print warnings for non-existent files, but
currently it fails on such packages and only prints a vague warning, e.g.:

dpkg-repack: warning: problems found processing kde-style-breeze, the package 
may be broken

In fact, no actual .deb is generated at all; the dpkg build directory is
missing DEBIAN/control.

Please do one or more of the following:

1. turn this error into a warning again (in line 248, replace 'error("cannot 
find file '$fn'")' with 'warning("cannot find file '$fn'")').

2. make sure the actual error message is printed, in addition to the vague 
warning; also, make it clear that no .deb was generated and that dpkg-repack 
exits unsuccessfully.

3. make this behaviour depend on a command line option; e.g. 
--ignore-missing-files, or --ignore-missing-locale, or --fail-on-missing-files 
or whatever.

I would argue that if files are missing, the generated .deb should just not
contain them. After all, dpkg-repack's description says "dpkg-repack creates
a .deb file out of a package that has already been installed. If any changes
have been made to the package while it was unpacked (i.e. files in /etc were
modified), the new package will inherit the changes.

This utility can make it easy to copy packages from one computer to another,
or to recreate packages that are installed on your system, but no longer
available elsewhere, or to store the current state of a package before you
upgrade it."

Removing files represents "changes made to the package" that dpkg-repack
should preserve.

Whether the .list file should include the missing files or not is an
interesting question, but irrelevant for my use case (backup before
upgrade); I think it would be better to include them if possible, because
then if you install the generated .deb, it's still obvious that those files
are missing from it.

Best regards,

András

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

Kernel: Linux 4.4.207-vs2.3.9.8 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=hu_HU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: runit (via /run/runit.stopit)

Versions of packages dpkg-repack depends on:
ii  libdpkg-perl  1.19.7
ii  perl  5.30.0-9

dpkg-repack recommends no packages.

Versions of packages dpkg-repack suggests:
ii  fakeroot  1.24-1

-- no debconf information

-- 
 The important thing is that we are moving forward - never mind the direction.



Bug#945442: Possible to backspace past beginning of string, which appears to be identical to having pressed Enter immediately, without any backspace

2019-11-24 Thread Andras Korn
Package: neomutt
Version: 2019+dfsg.1-1
Severity: normal

Hi,

when mutt prompts for something (e.g. To: address, Subject etc.) it
previously was possibly to just keep pressing backspace until whatever
default text was there disappeared.

As of this version, it's possible to keep erasing back beyond the first
character of the string; for example, when composing mail, backspacing
beyond the beginning of the offered Subject brings up the editor
with the message being composed; saving and exiting shows that the Subject
is in fact not empty but the default (e.g. "Re: original subject").

Backspacing beyond the beginning of the To: prompt likewise confirms the
default To: address and goes to the Subject prompt.

This behaviour is completely counter-intuitive and hopefully not
intentional.

I can reproduce it with mutt -F /dev/null, leading me to beleive it's not a
problem with my configuration.

Andras

-- Package-specific info:
NeoMutt 2019
Copyright (C) 1996-2016 Michael R. Elkins and others.
NeoMutt comes with ABSOLUTELY NO WARRANTY; for details type 'neomutt -vv'.
NeoMutt is free software, and you are welcome to redistribute it
under certain conditions; type 'neomutt -vv' for details.

System: Linux 4.4.185-vs2.3.9.8+uksm (x86_64)
ncurses: ncurses 6.1.20191019 (compiled with 6.1.20191019)
libidn: 1.33 (compiled with 1.33)
GPGme: 1.13.1-unknown
hcache backends: tokyocabinet

Compiler:
Using built-in specs.
COLLECT_GCC=cc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/9/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:hsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 9.2.1-19' 
--with-bugurl=file:///usr/share/doc/gcc-9/README.Bugs 
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,gm2 --prefix=/usr 
--with-gcc-major-version-only --program-suffix=-9 
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id 
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix 
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu 
--enable-libstdcxx-debug --enable-libstdcxx-time=yes 
--with-default-libstdcxx-abi=new --enable-gnu-unique-object 
--disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib 
--with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch 
--disable-werror --with-arch-32=i686 --with-abi=m64 
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic 
--enable-offload-targets=nvptx-none,hsa --without-cuda-driver 
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu 
--target=x86_64-linux-gnu
Thread model: posix
gcc version 9.2.1 20191109 (Debian 9.2.1-19) 

Configure options: --build=x86_64-linux-gnu --prefix=/usr 
{--includedir=${prefix}/include} {--mandir=${prefix}/share/man} 
{--infodir=${prefix}/share/info} --sysconfdir=/etc --localstatedir=/var 
--disable-silent-rules {--libdir=${prefix}/lib/x86_64-linux-gnu} 
{--libexecdir=${prefix}/lib/x86_64-linux-gnu} --disable-maintainer-mode 
--disable-dependency-tracking --mandir=/usr/share/man --libexecdir=/usr/libexec 
--with-mailpath=/var/mail --gpgme --lua --notmuch --with-ui --gnutls --gss 
--idn --mixmaster --sasl --tokyocabinet

Compilation CFLAGS: -g -O2 
-fdebug-prefix-map=/build/neomutt-jdVSn8/neomutt-2019+dfsg.1=. 
-fstack-protector-strong -Wformat -Werror=format-security -std=c99 
-D_ALL_SOURCE=1 -D_GNU_SOURCE=1 -D__EXTENSIONS__ -I/usr/include 
-I/usr/include/lua5.3 -DNCURSES_WIDECHAR -isystem /usr/include/mit-krb5

Default options:
  +attach_headers_color +compose_to_sender +compress +cond_date +debug 
  +encrypt_to_self +forgotten_attachments +forwref +ifdef +imap +index_color 
  +initials +limit_current_thread +multiple_fcc +nested_if +new_mail +nntp +pop 
  +progress +quasi_delete +regcomp +reply_with_xorig +sensible_browser +sidebar 
  +skip_quoted +smtp +status_color +timeout +tls_sni +trash 

Compile options:
  -autocrypt +bkgdset +color +curs_set +fcntl -flock -fmemopen +futimens 
  +getaddrinfo +gnutls +gpgme +gss +hcache -homespool +idn +inotify 
  -locales_hack +lua +meta +mixmaster +nls +notmuch -openssl +pgp +sasl +smime 
  -sqlite +start_color +sun_attachment +typeahead 
MAILPATH="/var/mail"
MIXMASTER="mixmaster"
PKGDATADIR="/usr/share/neomutt"
SENDMAIL="/usr/sbin/sendmail"
SYSCONFDIR="/etc"

To learn more about NeoMutt, visit: https://neomutt.org
If you find a bug in NeoMutt, please raise an issue at:
https://github.com/neomutt/neomutt/issues
or send an email to: 

-- System Information:
Debian Release: 10.0
  APT prefers unstable
  APT policy: (350, 'unstable'), (350, 'stable'), (98, 'eoan-updates'), (98, 
'eoan-security'), (98, 'eoan-proposed'), (98, 'eoan-backports'), (98, 'eoan'), 
(1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.4.185-vs2.3.9.8+uksm (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=hu_HU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell

Bug#930869: Please keep pm-utils

2019-11-14 Thread Andras Korn
Hi,

I just stumbled on this bugreport.

I'm a happy pm-utils user and would like the package to stick around. I use
it on dozens of computers ranging from servers to desktops to laptops.

>From reading the bugreport, there doesn't appear to be any identifiable,
specific, actionable reason for removing it, does there?

Thanks!

András

-- 
Days since last off-by-one incident: -1



Bug#248496: missing font 8x16

2019-11-03 Thread Andras Korn
Hi,

I just encountered the same problem.

I'm fairly certain the root cause is that the game assumes some specific
named font is available, and fails when it isn't (i.e. missing dependency).

I looked at it using xtruss
(https://www.chiark.greenend.org.uk/~sgtatham/xtruss/) and it seems to try
to use a font called "8x16":

OpenFont(fid=f#0463, name="8x16")
ChangeGC(gc=g#0462, foreground=0x, background=0x, 
font=f#0463)
ChangeWindowAttributes(window=w#0461, event-mask=Exposure)
ConfigureWindow(window=w#0461, stack-mode=Above)
MapWindow(window=w#0461)
 ... OpenFont(fid=f#0463, name="8x16") = BadName
 ... ChangeGC(gc=g#0462, foreground=0x, background=0x, 
font=f#0463) = BadFont(font=f#)
--- Expose(window=w#0461, x=0, y=0, width=1, height=1, count=0)
X Error of failed request:  BadName (named color or font does not exist)
  Major opcode of failed request:  45 (X_OpenFont)
  Serial number of failed request:  27
  Current serial number in output stream:  31

I have no idea how to provide the game with the required font; the
xfonts-base package, which contains /usr/share/fonts/X11/misc/8x16.pcf.gz,
is installed, fwiw.

HTH.

Andras

-- 
  The trouble with political humor is that so many jokes are elected.



Bug#930803: new program: runcached

2019-06-26 Thread Andras Korn
On Wed, Jun 26, 2019 at 12:18:25PM +0200, Andras Korn wrote:

> > > I just wrote this script:
> > > https://gist.github.com/akorn/51ee2fe7d36fa139723c851d87e56096 and thought
> > > it might be a good addition to moreutils.
> > > 
> > > It caches the stdout, stderr and exit status of arbitrary commands for a
> > > configurable length of time, returning data from cache on subsequent
> > > invocations if the cache is still fresh.
> > 
> > thanks for your suggestion; I think it's quite an interesting idea!
> > And you made me curious:  which commands are you running through
> > 'runcached'?  All programs I thought of have their basic functionality
> > based on side-effects as file system or network access.
> 
> Examples:
> 
>  * I have a Makefile to regenerate the data.cdb file for tinydns whenever
>any of the local source files changed. Part of the process is downloading
>some remote DNS zones with axfr-get, which is relatively slow. The remote
>zones don't change frequently; I don't want to download them each time,
>but I do want to download them at least once every eight hours or so. So
>I run axfr-get via runcached, with a cache ttl of 8 hours.
> 
>  * Some monitoring systems like Zabbix and Munin need to run data-gathering
>stuff that is time-consuming; it sometimes happens that several plugins
>need to run the same thing, but extract different data from its output.
>Instead of having separate, ad-hoc caching in all such plugins, it's
>better to have a generic caching solution.
> 
>  * When looking for space hogs in the filesystem, I often use
>'du -hscx * .* | sort -h' and then dig down further. Without runcached
>I would have to either save the output separately, or keep opening new
>sessions in screen(1), or wait for the same output to be generated again,
>when I go up to the higher level directory again. With runcached, `du` is
>cheap the 2nd time, and I don't care if the numbers are slightly off when
>they come from the cache.
> 
>  * Same for ad-hoc log analysis sessions: I may grep through a bunch of
>logs, then grep for something else, then grep for the same thing again.
>With runcached, I don't need to worry about saving output I may need
>again, because runcached does it for me.

* Oh, and ldapsearch. I have some scheduled scripts that each do something
  to members of the same group; before, I had an ad-hoc cache for group
  members, but with runcached I can just re-run ldapsearch with the same
  arguments and get cached results.

András

-- 
Win any staring contest: slowly go in for a kiss without breaking eye contact.



Bug#930803: new program: runcached

2019-06-26 Thread Andras Korn
On Tue, Jun 25, 2019 at 08:22:12PM +0200, Nicolas Schier wrote:

Hi,

> > I just wrote this script:
> > https://gist.github.com/akorn/51ee2fe7d36fa139723c851d87e56096 and thought
> > it might be a good addition to moreutils.
> > 
> > It caches the stdout, stderr and exit status of arbitrary commands for a
> > configurable length of time, returning data from cache on subsequent
> > invocations if the cache is still fresh.
> 
> thanks for your suggestion; I think it's quite an interesting idea!
> And you made me curious:  which commands are you running through
> 'runcached'?  All programs I thought of have their basic functionality
> based on side-effects as file system or network access.

Examples:

 * I have a Makefile to regenerate the data.cdb file for tinydns whenever
   any of the local source files changed. Part of the process is downloading
   some remote DNS zones with axfr-get, which is relatively slow. The remote
   zones don't change frequently; I don't want to download them each time,
   but I do want to download them at least once every eight hours or so. So
   I run axfr-get via runcached, with a cache ttl of 8 hours.

 * Some monitoring systems like Zabbix and Munin need to run data-gathering
   stuff that is time-consuming; it sometimes happens that several plugins
   need to run the same thing, but extract different data from its output.
   Instead of having separate, ad-hoc caching in all such plugins, it's
   better to have a generic caching solution.

 * When looking for space hogs in the filesystem, I often use
   'du -hscx * .* | sort -h' and then dig down further. Without runcached
   I would have to either save the output separately, or keep opening new
   sessions in screen(1), or wait for the same output to be generated again,
   when I go up to the higher level directory again. With runcached, `du` is
   cheap the 2nd time, and I don't care if the numbers are slightly off when
   they come from the cache.

 * Same for ad-hoc log analysis sessions: I may grep through a bunch of
   logs, then grep for something else, then grep for the same thing again.
   With runcached, I don't need to worry about saving output I may need
   again, because runcached does it for me.

> > It currently has semi-esoteric dependencies: it's written in zsh and uses
> > chpst from the runit package for locking. If you're willing to include the
> > script I can change it to use flock(1) instead, but I'm not rewriting it in
> > POSIX sh.
> 
> Adding new scripts to the moreutils collection is usually done by
> forwarding to the upstream maintainer (Joey Hess ) and
> asking for script inclusion.  But, as Joey keeps more than just one eye
> on cross platform compatibility, I expect non-POSIX implementations to
> be rejected.  Do you keep your non-POSIX statement?

I modified it to use zsh's system module for locking, but I'm sticking with
zsh; I have no interest in rewriting it in plain Bourne sh. zsh isn't much
less cross-platform than, say, perl or Python.

The --prune-cache functionality probably depends on GNU find(1).

I'm offering the script in the belief that it might be useful to others, but
getting it into moreutils is no priority for me.

> Did you think about the license you want to stick it to? GPL2+?

I was thinking GPLv3+, but if the rest of moreutils is GPL2+, I'm fine with
that too.

András

-- 
A synonym is a word you use when you can't spell the other one.



Bug#930803: new program: runcached

2019-06-20 Thread Andras Korn
Package: moreutils
Version: 0.62-1
Severity: wishlist

Hi,

I just wrote this script:
https://gist.github.com/akorn/51ee2fe7d36fa139723c851d87e56096 and thought
it might be a good addition to moreutils.

It caches the stdout, stderr and exit status of arbitrary commands for a
configurable length of time, returning data from cache on subsequent
invocations if the cache is still fresh.

It currently has semi-esoteric dependencies: it's written in zsh and uses
chpst from the runit package for locking. If you're willing to include the
script I can change it to use flock(1) instead, but I'm not rewriting it in
POSIX sh.

Best regards,

András

-- 
  Want to make  using your computer? hold shift and press '4' four times.



Bug#927480: Performance: if an fs reports EOPNOTSUPP for xattr/acl calls, don't keep trying

2019-04-20 Thread Andras Korn
Package: rsync
Version: 3.1.3-6
Severity: wishlist
Tags: upstream

Hi,

according to strace -c, getxattr() and similar calls can take up a lot of
runtime (around ten percent) if there are many files to be synced and other
stuff (I/O, network) is reasonably fast.

It would make sense for rsync to skip such calls for files on a filesystem
that replied with EOPNOTSUPP and save some time.

The stat() family of calls tell rsync which fs the file is on, so that you
just need to wrap the ACL/xattr calls in a wrapper that checks whether the
fs in question is known to not support ACLs/xattrs before calling the actual
syscall/library function.

Counterarguments:

1. "don't call rsync with -AX if your fs doesn't support ACLs/xattrs".
Apparently valid, but maybe I'm syncing a huge tree with more than one
mountpoint, and some of the mounted filesystems support ACLs/xattrs while
others don't.

2. it's possible for an fs to be remounted with ACL/xattr support while
rsync is running; if my suggestion were implemented, rsync could miss some
ACLs/xattrs. My response to that is "don't do that then". :)

András

-- 
 I spilled spot remover on my dog, and now he's gone!



Bug#919699: Please support -w switch to halt(8)

2019-03-12 Thread Andras Korn
On Tue, Mar 12, 2019 at 06:37:45PM +, Dmitry Bogatov wrote:

Hi,

> [2019-03-11 16:24] Lorenzo Puliti 
> > Package: runit-init
> > Version: 2.1.2-25helpers1
> > Followup-For: Bug #919699
> >
> > Hi,
> >
> > >I am okay with accepting patch to implement writing `wtmp' entry, if it
> > >is reasonably small, but I would prefer to delegate it to external
> > >implementation, like https://git.suckless.org/utmp (not sure it is
> > >applicable).
> >
> > Just in case you don't know, there is already a 'sac' package that include a
> > 'writetmp - write special wtmp entries to a wtmp file.' program.
> >
> > https://packages.debian.org/sid/sac
> >
> > The only thing is that last sac release is dated around Dec 2004 and last
> > update of the Debian sac package is from Dec 2011, otherwise it looks the
> > right external tool.
> 
> Just noticed, that bin:runit too provides tool for wtmp -- utmpset(8).
> But it expects 'line' argument, and I do not know, what is correct value
> for it.
> 
> halt.c from src:sysvinit pass '~~' as line, but utmpset(8) rejects such
> usage. Any advice?

Indeed, sysvinit's halt.c does this:

write_wtmp("shutdown", "~~", 0, RUN_LVL, "~~");

and write_wtmp looks like this (some irrelevant lines omitted, some
commentary added):

void write_wtmp(
char *user, /* name of user */
char *id,   /* inittab ID */
int pid,/* PID of process */
int type,   /* TYPE of entry */
char *line) /* Which line is this */
{
int fd;
struct utmp utmp;
struct utsname uname_buf;
struct timeval tv;

/* [...] */

memset(&utmp, 0, sizeof(utmp));
#if defined(__GLIBC__)
gettimeofday(&tv, NULL);
utmp.ut_tv.tv_sec = tv.tv_sec;
utmp.ut_tv.tv_usec = tv.tv_usec;
#else
time(&utmp.ut_time);
#endif
utmp.ut_pid  = pid;
utmp.ut_type = type;
strncpy(utmp.ut_name, user, sizeof(utmp.ut_name));
strncpy(utmp.ut_id  , id  , sizeof(utmp.ut_id  ));
strncpy(utmp.ut_line, line, sizeof(utmp.ut_line));

/* Put the OS version in place of the hostname */
if (uname(&uname_buf) == 0)
strncpy(utmp.ut_host, uname_buf.release, sizeof(utmp.ut_host));

#if HAVE_UPDWTMP
updwtmp(WTMP_FILE, &utmp); /* Linux, NetBSD, Solaris etc. have updwtmp 
*/
#else
write(fd, (char *)&utmp, sizeof(utmp)); /* fallback */
#endif
close(fd);
}

In contrast, utmpset.c from runit does:

/* [...] */

  if (utmp_logout(*argv) == -1)
strerr_die4x(111, WARNING, "unable to logout line ", *argv,
 " in utmp: no such entry");
  if (wtmp)
if (wtmp_logout(*argv) == -1)
  strerr_die4sys(111, WARNING,
 "unable to logout line ", *argv, " in wtmp: ");

utmp_logout() tries to find a matching login entry, and since there is none,
it returns an error; thus, wtmp_logout is never called.

I tried to put the wtmp_logout() call above the utmp_logout() call, and
stepped through the wtmp_logout() function with gdb; it succeeds and writes
a record to wtmp, but it's in the wrong format.

Examining the code in wtmp_logout(), it seems it sets ut_type to
DEAD_PROCESS unconditionally, but it would need to be RUN_LVL; also, it
doesn't set ut_user or ut_id.

I have to conclude that utmpset is incapable of generating a shutdown
record.

I think that, as a minimum, 'halt -w' should become a no-op and exit
successfully immediately. Ideally, it should generate a valid
shutdown/reboot record the way halt.c from sysvinit does.

If you're short on time, I would suggest that you immediately change your
shutdown.c to just exit cleanly if '-w' is passed on the command line (as
per your existing patch), and wait for someone to send a patch to generate a
valid shutdown record. Since, as you can see above, the code to do that is
minimal, I'm not sure it makes sense to call an external program for it,
adding a dependency.

András

-- 
God heals, but always someone else wants a fee.



Bug#923924: Please review and apply attached patch to support shutdown on SIGPWR

2019-03-11 Thread Andras Korn
On Mon, Mar 11, 2019 at 06:12:06PM +, Dmitry Bogatov wrote:

> > On Fri, Mar 08, 2019 at 02:39:47PM +, Dmitry Bogatov wrote:
> > > [2019-03-07 12:57] Andras Korn 
> > > > part 1 text/plain 218
> > > > Sorry, I sent an earlier version of the patch by mistake.
> > > >
> > > > I'm attaching the correct one, which I tested and which works for me.
> > > > [...]
> > > > -  if (sigc && (stat(STOPIT, &s) != -1) && (s.st_mode & S_IXUSR)) {
> > > > +  if ((sigp) || (sigc && (stat(STOPIT, &s) != -1) && (s.st_mode & 
> > > > S_IXUSR))) {
> > > 
> > > As far as I can tell by glance on patch, you want SIGPWR trigger reboot.
> > > If so, why don't you create REBOOT file in, say, /etc/rc.local and make
> > > lxc controller to send SIGCONT?
> >
> > No -- I want SIGPWR to trigger a halt.
> >
> > For the purposes of LXC, any signal will do; I just need for a signal to
> > trigger a shutdown regardless of the permissions on runit.stopit and
> > runit.reboot.
> 
> Halt. Fine. But why can't you pre-provision you container with apporiate
> `stop.*' file with apporiate permissions?

Because that adds complexity elsewhere -- /etc/runit/1 as shipped creates
/run/runit.stopit with mode 0, so either all containers would need ot have a
custom /etc/runit/1, or run a custom script to chmod 100 /run/runit.stopit
on every boot, or have an immutable /run/runit.stopit.

It's not just about me; this affects everyone who wants to use runit inside
an lxc container.

My goal is to make using runit as hassle-free as possible, without
sacrificing any of its core values.

> > > By the way, SIGPWR is not in POSIX, according to signal(7).
> >
> > You're right; in that case, maybe we can use SIGQUIT?
> 
> SIGTERM feels better, imho. TERM is graceful termination, while SIGQUIT
> creates coredump. By default.

SIGPWR would be nice to use as the halt signal because it's the lxc default,
so that runit could be a drop-in replacement for sysvinit in LXC containers.

If we're not going to use SIGPWR it's pretty much all the same which signal
we use, because it will need to be configured explicitly in LXC (but that's
acceptable -- POSIX is important enough).

> But this naming only matters if you explain to me, how solution not
> involving changing C code does not suffice. Two lines for convenience in
> this case, three there -- and we all know where it ends.

I'm sorry, I don't buy the slippery slope argument. I'm not adding a DNS
resolver, a DHCP client or a QR encoder, merely making the user interface a
tiny bit more similar to sysvinit's, to make integration easier. This is
entirely in line with The Unix Way: making one program a drop-in replacement
for another such that other programs interfacing with them don't see a
difference unless they need to. It's why bzip2 and gzip take most of the
same switches etc.

Since you apparently don't agree that this is a good idea, should I take the
patch to Gerrit instead?

András

-- 
Warranty is void in case of nuclear war, whether caused by the program or not.



Bug#923924: Please review and apply attached patch to support shutdown on SIGPWR

2019-03-10 Thread Andras Korn
On Fri, Mar 08, 2019 at 02:39:47PM +, Dmitry Bogatov wrote:

Hi,

> [2019-03-07 12:57] Andras Korn 
> > part 1 text/plain 218
> > Sorry, I sent an earlier version of the patch by mistake.
> >
> > I'm attaching the correct one, which I tested and which works for me.
> > [...]
> > -  if (sigc && (stat(STOPIT, &s) != -1) && (s.st_mode & S_IXUSR)) {
> > +  if ((sigp) || (sigc && (stat(STOPIT, &s) != -1) && (s.st_mode & 
> > S_IXUSR))) {
> 
> As far as I can tell by glance on patch, you want SIGPWR trigger reboot.
> If so, why don't you create REBOOT file in, say, /etc/rc.local and make
> lxc controller to send SIGCONT?

No -- I want SIGPWR to trigger a halt.

For the purposes of LXC, any signal will do; I just need for a signal to
trigger a shutdown regardless of the permissions on runit.stopit and
runit.reboot.

> By the way, SIGPWR is not in POSIX, according to signal(7).

You're right; in that case, maybe we can use SIGQUIT?

I suppose the other option is to wrap all changes in #ifdefs so the new bits
are only built on Linux (since it's currently only relevant for Linux, this
might be appropriate), but I think that would make the code
disproportionately ugly.

András

-- 
   How to lose a guy in 10 days? Buy him a computer.



Bug#923957: /lib/runit/run_sysv_scripts shouldn't use 'sh -e'

2019-03-07 Thread Andras Korn
Package: runit-init
Version: 2.1.2-22
Severity: critical

Hi,

The supplied "/etc/runit/1" calls "/lib/runit/run_sysv_scripts /etc/rcS.d"
during boot.

/lib/runit/run_sysv_scripts runs under "sh -eu", which has the effect that
if any initscript exits unsuccesfully, all subsequent scripts are skipped.

This can lead to, for example, the "networking" initscript not being
started, which then results in no connectivity for the box and thus no way
to log in remotely. (This is my justification for the 'critical' severity:
"breaks the entire system".)

I think runit-init should do what /etc/init.d/rc does: log failures and
continue.

Thanks,

András

-- 
  It's not enough to have no opinion. You must also be unable to express it.



Bug#923924: Please review and apply attached patch to support shutdown on SIGPWR

2019-03-07 Thread Andras Korn
Sorry, I sent an earlier version of the patch by mistake.

I'm attaching the correct one, which I tested and which works for me.

András

-- 
Reality is that which, when you stop believing in it, doesn't go away.
diff --git a/runit-2.1.2/man/runit.8 b/runit-2.1.2/man/runit.8
index 6c07cf8..d597fdd 100644
--- a/runit-2.1.2/man/runit.8
+++ b/runit-2.1.2/man/runit.8
@@ -75,6 +75,12 @@ exists and has the execute by owner permission set,
 .B runit
 is told to shutdown the system.
 .P
+If
+.B runit
+receives a PWR signal,
+.B runit
+is told to shutdown the system.
+.P
 if
 .B runit
 receives an INT signal, a ctrl-alt-del keyboard request is triggered.
diff --git a/runit-2.1.2/src/runit.c b/runit-2.1.2/src/runit.c
index 2bb4794..35cda0a 100644
--- a/runit-2.1.2/src/runit.c
+++ b/runit-2.1.2/src/runit.c
@@ -30,6 +30,7 @@ const char * const stage[3] ={
 int selfpipe[2];
 int sigc =0;
 int sigi =0;
+int sigp =0;
 
 void sig_cont_handler (void) {
   sigc++;
@@ -39,6 +40,10 @@ void sig_int_handler (void) {
   sigi++;
   write(selfpipe[1], "", 1);
 }
+void sig_pwr_handler (void) {
+  sigp++;
+  write(selfpipe[1], "", 1);
+}
 void sig_child_handler (void) { write(selfpipe[1], "", 1); }
 
 void sync_if_needed() {
@@ -71,6 +76,8 @@ int main (int argc, const char * const *argv, char * const *envp) {
   sig_block(sig_hangup);
   sig_block(sig_int);
   sig_catch(sig_int, sig_int_handler);
+  sig_block(sig_pwr);
+  sig_catch(sig_pwr, sig_pwr_handler);
   sig_block(sig_pipe);
   sig_block(sig_term);
 
@@ -150,6 +157,7 @@ int main (int argc, const char * const *argv, char * const *envp) {
   sig_unblock(sig_child);
   sig_unblock(sig_cont);
   sig_unblock(sig_int);
+  sig_unblock(sig_pwr);
 #ifdef IOPAUSE_POLL
   poll(&x, 1, 14000);
 #else
@@ -161,6 +169,7 @@ int main (int argc, const char * const *argv, char * const *envp) {
   sig_block(sig_cont);
   sig_block(sig_child);
   sig_block(sig_int);
+  sig_block(sig_pwr);
   
   while (read(selfpipe[0], &ch, 1) == 1) {}
   while ((child =wait_nohang(&wstat)) > 0)
@@ -211,7 +220,7 @@ int main (int argc, const char * const *argv, char * const *envp) {
   }
 
   /* sig? */
-  if (!sigc  && !sigi) {
+  if (!sigc && !sigi && !sigp) {
 #ifdef DEBUG
 strerr_warn2(WARNING, "poll: ", &strerr_sys);
 #endif
@@ -244,7 +253,7 @@ int main (int argc, const char * const *argv, char * const *envp) {
 sigi =0;
 sigc++;
   }
-  if (sigc && (stat(STOPIT, &s) != -1) && (s.st_mode & S_IXUSR)) {
+  if ((sigp) || (sigc && (stat(STOPIT, &s) != -1) && (s.st_mode & S_IXUSR))) {
 int i;
 /* unlink(STOPIT); */
 chmod(STOPIT, 0);
@@ -286,7 +295,7 @@ int main (int argc, const char * const *argv, char * const *envp) {
 /* enter stage 3 */
 break;
   }
-  sigc =sigi =0;
+  sigc =sigi =sigp =0;
 #ifdef DEBUG
   strerr_warn2(WARNING, "no request.", 0);
 #endif
@@ -308,7 +317,7 @@ int main (int argc, const char * const *argv, char * const *envp) {
   switch (pid) {
   case  0:
   case -1:
-  if ((stat(REBOOT, &s) != -1) && (s.st_mode & S_IXUSR)) {
+  if ((!sigp) && ((stat(REBOOT, &s) != -1) && (s.st_mode & S_IXUSR))) {
 strerr_warn2(INFO, "system reboot.", 0);
 sync_if_needed();
 reboot_system(RB_AUTOBOOT);
diff --git a/runit-2.1.2/src/sig.c b/runit-2.1.2/src/sig.c
index 423d18e..9d9d69b 100644
--- a/runit-2.1.2/src/sig.c
+++ b/runit-2.1.2/src/sig.c
@@ -9,6 +9,7 @@ int sig_cont = SIGCONT;
 int sig_hangup = SIGHUP;
 int sig_int = SIGINT;
 int sig_pipe = SIGPIPE;
+int sig_pwr = SIGPWR;
 int sig_term = SIGTERM;
 
 void (*sig_defaulthandler)() = SIG_DFL;
diff --git a/runit-2.1.2/src/sig.h b/runit-2.1.2/src/sig.h
index 2a3c780..0ced62d 100644
--- a/runit-2.1.2/src/sig.h
+++ b/runit-2.1.2/src/sig.h
@@ -9,6 +9,7 @@ extern int sig_cont;
 extern int sig_hangup;
 extern int sig_int;
 extern int sig_pipe;
+extern int sig_pwr;
 extern int sig_term;
 
 extern void (*sig_defaulthandler)();


Bug#923924: Please review and apply attached patch to support shutdown on SIGPWR

2019-03-07 Thread Andras Korn
Package: runit
Version: 2.1.2-22
Severity: wishlist
Tags: upstream

Hi,

currently lxc can't cleanly shutdown a container running runit as its init
system, because all it can do to bring about a shutdown is send signals to
init (sigpwr by default), and runit requires additional steps to initiate a
shutdown.

I wrote a trivial patch that should add sigpwr support to runit. Please
review it and if you think it's OK, apply it and perhaps submit it to Gerrit
for inclusion.

Thanks!

András

-- 
 Enter any 11-digit prime number to continue.
diff --git a/runit-2.1.2/man/runit.8 b/runit-2.1.2/man/runit.8
index 6c07cf8..d597fdd 100644
--- a/runit-2.1.2/man/runit.8
+++ b/runit-2.1.2/man/runit.8
@@ -75,6 +75,12 @@ exists and has the execute by owner permission set,
 .B runit
 is told to shutdown the system.
 .P
+If
+.B runit
+receives a PWR signal,
+.B runit
+is told to shutdown the system.
+.P
 if
 .B runit
 receives an INT signal, a ctrl-alt-del keyboard request is triggered.
diff --git a/runit-2.1.2/src/runit.c b/runit-2.1.2/src/runit.c
index 2bb4794..584207a 100644
--- a/runit-2.1.2/src/runit.c
+++ b/runit-2.1.2/src/runit.c
@@ -30,6 +30,7 @@ const char * const stage[3] ={
 int selfpipe[2];
 int sigc =0;
 int sigi =0;
+int sigp =0;
 
 void sig_cont_handler (void) {
   sigc++;
@@ -39,6 +40,10 @@ void sig_int_handler (void) {
   sigi++;
   write(selfpipe[1], "", 1);
 }
+void sig_pwr_handler (void) {
+  sigp++;
+  write(selfpipe[1], "", 1);
+}
 void sig_child_handler (void) { write(selfpipe[1], "", 1); }
 
 void sync_if_needed() {
@@ -71,6 +76,7 @@ int main (int argc, const char * const *argv, char * const *envp) {
   sig_block(sig_hangup);
   sig_block(sig_int);
   sig_catch(sig_int, sig_int_handler);
+  sig_catch(sig_pwr, sig_pwr_handler);
   sig_block(sig_pipe);
   sig_block(sig_term);
 
@@ -244,7 +250,7 @@ int main (int argc, const char * const *argv, char * const *envp) {
 sigi =0;
 sigc++;
   }
-  if (sigc && (stat(STOPIT, &s) != -1) && (s.st_mode & S_IXUSR)) {
+  if ((sigp) || (sigc && (stat(STOPIT, &s) != -1) && (s.st_mode & S_IXUSR))) {
 int i;
 /* unlink(STOPIT); */
 chmod(STOPIT, 0);
@@ -308,7 +314,7 @@ int main (int argc, const char * const *argv, char * const *envp) {
   switch (pid) {
   case  0:
   case -1:
-  if ((stat(REBOOT, &s) != -1) && (s.st_mode & S_IXUSR)) {
+  if ((!sigp) && ((stat(REBOOT, &s) != -1) && (s.st_mode & S_IXUSR))) {
 strerr_warn2(INFO, "system reboot.", 0);
 sync_if_needed();
 reboot_system(RB_AUTOBOOT);
diff --git a/runit-2.1.2/src/sig.c b/runit-2.1.2/src/sig.c
index 423d18e..9d9d69b 100644
--- a/runit-2.1.2/src/sig.c
+++ b/runit-2.1.2/src/sig.c
@@ -9,6 +9,7 @@ int sig_cont = SIGCONT;
 int sig_hangup = SIGHUP;
 int sig_int = SIGINT;
 int sig_pipe = SIGPIPE;
+int sig_pwr = SIGPWR;
 int sig_term = SIGTERM;
 
 void (*sig_defaulthandler)() = SIG_DFL;
diff --git a/runit-2.1.2/src/sig.h b/runit-2.1.2/src/sig.h
index 2a3c780..0ced62d 100644
--- a/runit-2.1.2/src/sig.h
+++ b/runit-2.1.2/src/sig.h
@@ -9,6 +9,7 @@ extern int sig_cont;
 extern int sig_hangup;
 extern int sig_int;
 extern int sig_pipe;
+extern int sig_pwr;
 extern int sig_term;
 
 extern void (*sig_defaulthandler)();


Bug#920977: Breaks loading of db backends in Trac

2019-02-03 Thread Andras Korn
On Sat, Feb 02, 2019 at 11:00:30AM +0100, Julien Cristau wrote:

Hi,

> > as long as mercurial-common is installed, the postgres and sqlite db 
> > backend driver of Trac won't load:
> > 
> > 2019-01-31 08:58:49,372 Trac[loader] ERROR: Skipping "trac.db.postgres = 
> > trac.db.postgres_backend": 
> > Traceback (most recent call last):
> >   File "/usr/lib/python2.7/dist-packages/trac/loader.py", line 77, in 
> > _load_eggs
> > entry.load(require=True)
> >   File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 
> > 2346, in load
> > return self.resolve()
> >   File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 
> > 2352, in resolve
> > module = __import__(self.module_name, fromlist=['__name__'], level=0)
> >   File 
> > "/usr/lib/python2.7/dist-packages/hgdemandimport/demandimportpy2.py", line 
> > 172, in _demandimport
> > return _hgextimport(_origimport, name, globals, locals, fromlist, level)
> >   File 
> > "/usr/lib/python2.7/dist-packages/hgdemandimport/demandimportpy2.py", line 
> > 43, in _hgextimport
> > return importfunc(name, globals, *args, **kwargs)
> >   File "/usr/lib/python2.7/dist-packages/trac/db/postgres_backend.py", line 
> > 46, in 
> > psycopg2_version = get_pkginfo(psycopg).get('version',
> >   File "/usr/lib/python2.7/dist-packages/trac/util/__init__.py", line 806, 
> > in get_pkginfo
> > metadata = 'METADATA' if dist.has_metadata('METADATA') else 'PKG-INFO'
> >   File 
> > "/usr/lib/python2.7/dist-packages/hgdemandimport/demandimportpy2.py", line 
> > 151, in __getattr__
> > return getattr(self._module, attr)
> > AttributeError: 'module' object has no attribute 'has_metadata'
> > 2019-01-31 08:58:49,372 Trac[loader] DEBUG: Loading plugin "trac.db.sqlite" 
> > from "/usr/lib/python2.7/dist-packages"
> > 2019-01-31 08:58:49,374 Trac[loader] ERROR: Skipping "trac.db.sqlite = 
> > trac.db.sqlite_backend": 
> > Traceback (most recent call last):
> >   File "/usr/lib/python2.7/dist-packages/trac/loader.py", line 77, in 
> > _load_eggs
> > entry.load(require=True)
> >   File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 
> > 2346, in load
> > return self.resolve()
> >   File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 
> > 2352, in resolve
> > module = __import__(self.module_name, fromlist=['__name__'], level=0)
> >   File 
> > "/usr/lib/python2.7/dist-packages/hgdemandimport/demandimportpy2.py", line 
> > 172, in _demandimport
> > return _hgextimport(_origimport, name, globals, locals, fromlist, level)
> >   File 
> > "/usr/lib/python2.7/dist-packages/hgdemandimport/demandimportpy2.py", line 
> > 43, in _hgextimport
> > return importfunc(name, globals, *args, **kwargs)
> >   File "/usr/lib/python2.7/dist-packages/trac/db/sqlite_backend.py", line 
> > 45, in 
> > pysqlite_version_string = get_pkginfo(sqlite).get('version',
> >   File "/usr/lib/python2.7/dist-packages/trac/util/__init__.py", line 806, 
> > in get_pkginfo
> > metadata = 'METADATA' if dist.has_metadata('METADATA') else 'PKG-INFO'
> >   File 
> > "/usr/lib/python2.7/dist-packages/hgdemandimport/demandimportpy2.py", line 
> > 151, in __getattr__
> > return getattr(self._module, attr)
> > AttributeError: 'module' object has no attribute 'has_metadata'
> > 
> > I don't understand what the connection is, but removing mercurial-common
> > (which ships
> > /usr/lib/python2.7/dist-packages/hgdemandimport/demandimportpy2.py) helps.
> > 
> As far as I can tell for this to happen something must have called
> hgdemandimport.enable().  Can you track down what that is?

I'm afraid not; not only do I have almost no idea how, I also lack the time
to do it in the short term.

András

-- 
Politics: Poly = many, Tics = Blood sucking parasites.



Bug#914788: Please don't enable getty services for tty devices that don't exist

2019-02-03 Thread Andras Korn
On Wed, Jan 30, 2019 at 08:48:34PM +, Dmitry Bogatov wrote:

> > > What is so bad about cluttering environment of daemon?
> >
> > Normally you'd want to avoid passing unnecessary environment variables to
> > daemons. Maybe they'll affect its operation in some way; maybe they'll
> > affect a child process of the daemon that inherits them. It's relying on
> > undefined behaviour.
> 
> I do not buy this argument.  For ages we started daemons with
> /etc/init.d/{foo} scripts from root shell (and even with sudo), with all
> kind of environment variables, including rather nasty ones, like GREP or
> LESS, and we are still fine.

No we're not. :) Leaking shell envvars (stuff like LC_* and LD_* especially)
into daemon environments is one of the reasons initscripts are a bad idea.
Daemons should be called with a minimal required set of environment
variables.

> But probably executing services with `env -0' is good idea, thank you.

'env -0' will just modify the regular output of env(1), and will have no
effect if you use env to call a program; are you sure that's what you meant?

> > > > (But then /etc/default/foo would have to take precedence over 
> > > > sv/foo/conf,
> > > > because the /etc/default/foo variables would be lost during the exec 
> > > > since
> > > > we want to avoid exporting them.)
> > >
> > > This too. I want daemontools-style take precedence over sysvinit style.
> >
> > FWIW, I think the whole thing is creeping featurism,
> 
> One extra source of variables, implemented with 3 lines of shell? Well,
> your definition of 'featurism' is much stricter then mine.

I meant the entire shebang of having a funky shellscript as an interpreter
for 'run' scripts just so we can avoid 3 lines of shell code in each to set
environment variables is creeping featurism. The idea is original and
certainly has hack value; but I think the benefits don't warrant the added
complexity/abstraction.

However, since using it is entirely optional, it's probably not worth
arguing over; I write most of my run scripts in zsh anyway, so I won't even
be tempted to use the new interpreter.

> > > And what if there were no tty on installation time, and after that they
> > > appeared? (No idea, why, never dealt with devices without tty.)
> >
> > That's a pathological hypothetical case; I'd say we wait until it happens,
> > and then deal with it. (You might also ask: what about hypothetical systems
> > where /dev/tty* devices keep disappearing and reappearing in a rhythm that
> > always prevents getty from starting?)
> 
> Okay. I buy it. I will unconditionally include this code:
> 
>   if ! test -c /dev/@TTY@ ; then
>   rm /etc/service/getty-@TTY@
>   exit 0
>   fi
> 
> and upload to experimental. Should there be no report of that
> pathological case, I will merge these changes into unstable after
> Buster.  Will it do for you?

Most of the time, yes, thank you. (It won't work when the service directory
isn't /etc/service, but that's rare.)

András

-- 
 "Meow" ...splat... "Aarf" ...splat... (raining cats and dogs)



Bug#920977: Breaks loading of db backends in Trac

2019-01-31 Thread Andras Korn
Package: mercurial-common
Version: 4.8.2-1
Severity: important

Hi,

as long as mercurial-common is installed, the postgres and sqlite db backend 
driver of Trac won't load:

2019-01-31 08:58:49,372 Trac[loader] ERROR: Skipping "trac.db.postgres = 
trac.db.postgres_backend": 
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/trac/loader.py", line 77, in _load_eggs
entry.load(require=True)
  File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 2346, 
in load
return self.resolve()
  File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 2352, 
in resolve
module = __import__(self.module_name, fromlist=['__name__'], level=0)
  File "/usr/lib/python2.7/dist-packages/hgdemandimport/demandimportpy2.py", 
line 172, in _demandimport
return _hgextimport(_origimport, name, globals, locals, fromlist, level)
  File "/usr/lib/python2.7/dist-packages/hgdemandimport/demandimportpy2.py", 
line 43, in _hgextimport
return importfunc(name, globals, *args, **kwargs)
  File "/usr/lib/python2.7/dist-packages/trac/db/postgres_backend.py", line 46, 
in 
psycopg2_version = get_pkginfo(psycopg).get('version',
  File "/usr/lib/python2.7/dist-packages/trac/util/__init__.py", line 806, in 
get_pkginfo
metadata = 'METADATA' if dist.has_metadata('METADATA') else 'PKG-INFO'
  File "/usr/lib/python2.7/dist-packages/hgdemandimport/demandimportpy2.py", 
line 151, in __getattr__
return getattr(self._module, attr)
AttributeError: 'module' object has no attribute 'has_metadata'
2019-01-31 08:58:49,372 Trac[loader] DEBUG: Loading plugin "trac.db.sqlite" 
from "/usr/lib/python2.7/dist-packages"
2019-01-31 08:58:49,374 Trac[loader] ERROR: Skipping "trac.db.sqlite = 
trac.db.sqlite_backend": 
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/trac/loader.py", line 77, in _load_eggs
entry.load(require=True)
  File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 2346, 
in load
return self.resolve()
  File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 2352, 
in resolve
module = __import__(self.module_name, fromlist=['__name__'], level=0)
  File "/usr/lib/python2.7/dist-packages/hgdemandimport/demandimportpy2.py", 
line 172, in _demandimport
return _hgextimport(_origimport, name, globals, locals, fromlist, level)
  File "/usr/lib/python2.7/dist-packages/hgdemandimport/demandimportpy2.py", 
line 43, in _hgextimport
return importfunc(name, globals, *args, **kwargs)
  File "/usr/lib/python2.7/dist-packages/trac/db/sqlite_backend.py", line 45, 
in 
pysqlite_version_string = get_pkginfo(sqlite).get('version',
  File "/usr/lib/python2.7/dist-packages/trac/util/__init__.py", line 806, in 
get_pkginfo
metadata = 'METADATA' if dist.has_metadata('METADATA') else 'PKG-INFO'
  File "/usr/lib/python2.7/dist-packages/hgdemandimport/demandimportpy2.py", 
line 151, in __getattr__
return getattr(self._module, attr)
AttributeError: 'module' object has no attribute 'has_metadata'

I don't understand what the connection is, but removing mercurial-common
(which ships
/usr/lib/python2.7/dist-packages/hgdemandimport/demandimportpy2.py) helps.

Justification for severity important: breaks unrelated packages.

András

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

Kernel: Linux 4.4.169-vs2.3.9.8-caeeng (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=hu_HU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: runit (via /run/runit.stopit)

Versions of packages mercurial-common depends on:
ii  python  2.7.15-4

Versions of packages mercurial-common recommends:
ii  ca-certificates  20190110
ii  mercurial4.8.2-1
ii  sensible-utils   0.0.12

Versions of packages mercurial-common suggests:
pn  python-mysqldb   
pn  python-openssl   
ii  python-pygments  2.3.1+dfsg-1
pn  tk [wish]

-- debconf-show failed

-- 
With my luck, even suicide would only be a temporary solution.



Bug#914788: Please don't enable getty services for tty devices that don't exist

2019-01-27 Thread Andras Korn
On Sat, Jan 26, 2019 at 10:17:05AM +, Dmitry Bogatov wrote:

Hi,

> > I believe instead of
> >
> > rm /etc/service/getty-@TTY@
> >
> > you should do
> >
> > rm "$(pwd)"
> >
> > because then it won't matter what the service is called and where the
> > runsvdir root is (/etc/service or somewhere else).
> I find it unsafe. Explicit is better implicit.

Except when it doesn't work, because the service directory is somewhere
else... But whatever.

> > While invoke-run, as an interpreter, is an original idea, I'd make it a
> > scriptlet a run script can source via ". /lib/runit/invoke-run". Then it
> > wouldn't be necessary to export all variables the configuration sets and
> > thereby clutter the environment of the daemon.
> >
> > The envdir bit could be handled by a construct like
> >
> > if [ -z "$1" ]; then
> > SVDIR="$(dirname $(readlink -f "$0")"
> > if [ -e "$SVDIR/conf" ]; then
> > exec chpst -e "$SVDIR/conf" -- "$0" "envdir-done"
> > fi
> 
> Complicated. And depends on $0 trickery. We, at sysvinit team, had
> problems with $0 trickery.

How is this trickery? We're just obtaining the name of the script being
executed, and its path.

> What is so bad about cluttering environment of daemon?

Normally you'd want to avoid passing unnecessary environment variables to
daemons. Maybe they'll affect its operation in some way; maybe they'll
affect a child process of the daemon that inherits them. It's relying on
undefined behaviour.

> > (But then /etc/default/foo would have to take precedence over sv/foo/conf,
> > because the /etc/default/foo variables would be lost during the exec since
> > we want to avoid exporting them.)
> 
> This too. I want daemontools-style take precedence over sysvinit style.

FWIW, I think the whole thing is creeping featurism, but if you think you
must do it, I'd prefer it being done sensibly -- i.e. not depending on
undefined behaviour, not leaking environment variables. I think this is a
stronger argument than personal preference (yours or mine).

> > > Please,
> > > 
> > >  * build it (it will build runit-2.1.2-22, sorry for version havoc)
> > >  * install bin:runit
> > >  * install bin:getty-run
> > >  * write "yes" into /etc/getty-tty1/conf/GIVE_UP_ON_MISSING_TTY file
> >
> > While this would work, it doesn't improve my situation: you're making me
> > jump through hoops to get sensible behaviour. Creating these files isn't
> > less effort than deleting the getty services on installation, so it just
> > adds complexity and abstraction with no real benefit.
> 
> Not exactly. You mentioned that option to pre-seed debconf would help
> you.

Yes; I already preseed debconf with much other stuff. Adding one more
preseed response doesn't add appreciable complexity.

> I provide you with way to pre-provision system -- create
> /etc/default/getty-tty{1..6} before installing runit.

But this is a different mechanism than debconf. Like I said, it would work,
but it's not easier or more comfortable than removing the /service/getty*
symlinks after runit install. It adds complexity to the package without
improving the use-case it is aimed at.

> > I still think the postinst modification I suggested (not installing
> > getty services for non-existing tty devices) would be the cleanest
> > solution.
> 
> And what if there were no tty on installation time, and after that they
> appeared? (No idea, why, never dealt with devices without tty.)

That's a pathological hypothetical case; I'd say we wait until it happens,
and then deal with it. (You might also ask: what about hypothetical systems
where /dev/tty* devices keep disappearing and reappearing in a rhythm that
always prevents getty from starting?)

If you're so worried about providing a way to log in even in pathological
cases, you could start a getty on, say, tty7 from /etc/runit/1. (I have at
least one system where I do that.)

> As you can understand, I am wary about defaulting on behavior, that can
> leave user without means to login.

I understand and approve in general, but I think in this case you're taking
it too far, to cover a corner case that doesn't exist.

András

-- 
Quantum Mechanics: The dreams stuff is made of.



Bug#914788: Please don't enable getty services for tty devices that don't exist

2019-01-25 Thread Andras Korn
On Tue, Jan 22, 2019 at 07:16:43PM +, Dmitry Bogatov wrote:

Hi,

> > (Alternatively, the getty run scripts could start with something like this:
> >
> > [ -c /dev/ttyX ] || rm /etc/service/getty-ttyX
> >
> > and /etc/runit/1 could re-create these symlinks, just to be absolutely sure.
> >
> > I don't like this approach; there is too much going on automatically.)
> 
> I believe I found quite decent solution. Take a look at `bugfix/914788'
> branch.

Thanks for looking into this!

I believe instead of

rm /etc/service/getty-@TTY@

you should do

rm "$(pwd)"

because then it won't matter what the service is called and where the
runsvdir root is (/etc/service or somewhere else).

Also, this seems redundant:

#!/usr/bin/env /lib/runit/invoke-run

why not just "#!/lib/runit/invoke-run"?

While invoke-run, as an interpreter, is an original idea, I'd make it a
scriptlet a run script can source via ". /lib/runit/invoke-run". Then it
wouldn't be necessary to export all variables the configuration sets and
thereby clutter the environment of the daemon.

The envdir bit could be handled by a construct like

if [ -z "$1" ]; then
SVDIR="$(dirname $(readlink -f "$0")"
if [ -e "$SVDIR/conf" ]; then
exec chpst -e "$SVDIR/conf" -- "$0" "envdir-done"
fi

(But then /etc/default/foo would have to take precedence over sv/foo/conf,
because the /etc/default/foo variables would be lost during the exec since
we want to avoid exporting them.)

> Please,
> 
>  * build it (it will build runit-2.1.2-22, sorry for version havoc)
>  * install bin:runit
>  * install bin:getty-run
>  * write "yes" into /etc/getty-tty1/conf/GIVE_UP_ON_MISSING_TTY file

While this would work, it doesn't improve my situation: you're making me
jump through hoops to get sensible behaviour. Creating these files isn't
less effort than deleting the getty services on installation, so it just
adds complexity and abstraction with no real benefit.

I still think the postinst modification I suggested (not installing getty
services for non-existing tty devices) would be the cleanest solution.

András

-- 
No pixels were harmed in the creation of this program.



Bug#914788: Please don't enable getty services for tty devices that don't exist

2019-01-18 Thread Andras Korn
On Wed, Nov 28, 2018 at 06:47:59PM +, Dmitry Bogatov wrote:

Hi,

sorry, didn't look at bug mail for a while.

> > However, whenever the getty-run package is installed in a vserver, I have to
> > manually remove the /service/getty-tty* symlinks.
> >
> > Can you please modify the postinst script so it only installs getty services
> > for /dev/tty* devices that are actually there?
> 
> I do not like maintainer scripts. They are pain to get right.  I can
> propose you to pre-provision your servers with
> `/etc/sv/getty{1-6}-run/down' file. See runsv(8).

That would still leave the runsv processes around and clutter the output of
"sv status /service/*".

The following postinst snippet should work:

export NAME='getty-tty1'
if [ -c /dev/tty1 ]; then
export ENABLE='yes'
else
export ENABLE='no'
fi

# Unlike postrm, I can be sure, that runit-helper is present on
# postinst.
/lib/runit-helper/runit-helper postinst "$@"

... and so on for the other ttys. (A lesser man would have used a for loop. :)

(Alternatively, the getty run scripts could start with something like this:

[ -c /dev/ttyX ] || rm /etc/service/getty-ttyX

and /etc/runit/1 could re-create these symlinks, just to be absolutely sure.

I don't like this approach; there is too much going on automatically.)

Or, you could add a debconf question with low priority, defaulting to "yes",
on whether to add the getty service symlinks. I could pre-seed debconf in
vservers with "no".

> > Or can we come up with a way to help people avoid shooting themselves in the
> > foot while not requiring me to install getty-run in vservers? For example,
> > runit-init could depend on "getty-run | some-way-to-log-in-interactively",
> > and "some-way-to-log-in-interactively" could be provided by an empty
> > "runit-no-getty" package as well as an "ssh-run" package that sets up a
> > runit service for ssh.
> 
> If it would help you, I can add dependency on 'getty-run | access-run'.
> You are free to provide `access-run' in whatever way you like.

That would work for me if you also build a "runit-no-getty" or similar
(empty) package that provides "access-run". It should be in Debian; we
shouldn't force every container user to build their own fake empty
"access-run" package.

> I am fine with `bin:unsafe-no-tty-run' package too, but not now. I do not
> want to get stuck in NEW before freeze.

Sure, it can wait until the freeze starts. (I almost always use sid anyway.)

Thanks!

András

-- 
  What is life but a sexually transmitted disease with a 100% mortality rate?



Bug#919699: Please support -w switch to halt(8)

2019-01-18 Thread Andras Korn
Package: runit-init
Version: 2.1.2-22
Severity: wishlist
Tags: upstream

Hi,

the initscripts package ships /etc/init.d/umountnfs.sh, which is started on
shutdown and invokes "halt -w", which writes a shutdown record to
/var/log/wtmp.

The halt(8) binary shipped with runit-init, however, ignores the option and
tries to initiate a shutdown, waiting for it to complete, but a shutdown is
already in progress, waiting for /etc/init.d/umountnfs.sh to exit, which is
waiting for halt(8), which is waiting ...

I think as a minimum, halt -w and --wtmp-only should be a no-op and exit
immediately; but the clean solution would be to actually write that shutdown
record to wtmp.

András

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

Kernel: Linux 4.4.169-vs2.3.9.8-caeeng (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=hu_HU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: runit (via /run/runit.stopit)

Versions of packages runit-init depends on:
ii  getty-run   2.1.2-19
ii  initscripts 2.92~beta-2+devuan1.1
ii  libc6   2.28-3
ii  runit   2.1.2-22
ii  runit-helper2.7.3
ii  sysuser-helper  1.3.3
ii  sysv-rc 2.92~beta-2+devuan1.1

runit-init recommends no packages.

runit-init suggests no packages.

-- no debconf information

-- 
   Hit ESC once to quit, or twice to save your data.



Bug#914788: Please don't enable getty services for tty devices that don't exist

2018-11-27 Thread Andras Korn
Package: getty-run
Version: 2.1.2-18
Severity: wishlist

Hi,

I use runit as init extensively in linux-vserver guests which don't have
console devices and thus can't run getty.

Ideally, I wouldn't even have to install the getty-run package, but I
understand it's there to help avoid people shooting themselves in the foot
by installing runit and then not having any way to log in.

However, whenever the getty-run package is installed in a vserver, I have to
manually remove the /service/getty-tty* symlinks.

Can you please modify the postinst script so it only installs getty services
for /dev/tty* devices that are actually there?

Or can we come up with a way to help people avoid shooting themselves in the
foot while not requiring me to install getty-run in vservers? For example,
runit-init could depend on "getty-run | some-way-to-log-in-interactively",
and "some-way-to-log-in-interactively" could be provided by an empty
"runit-no-getty" package as well as an "ssh-run" package that sets up a
runit service for ssh.

András

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (350, 'unstable'), (350, 'stable'), (98, 'bionic'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Versions of packages getty-run depends on:
ii  runit 2.1.2-18
ii  runit-helper  2.7.3

Versions of packages getty-run recommends:
ii  fgetty  0.7-3

-- 
   Sure, drinking kills brain cells, but only the weak ones.



Bug#913876: PATH set in /etc/runit/2 doesn't contain /usr/local/bin and /usr/local/sbin, breaking existing run scripts

2018-11-16 Thread Andras Korn
Package: runit-init
Version: 2.1.2-18
Severity: normal

Hi,

sometime in the past year or so, you changed /etc/runit/2 so it sets a PATH
that no longer contains /usr/local/sbin and /usr/local/bin.

I think this is wrong; those are standard locations for locally installed
binaries, and they should occur in the PATH *before* their
distribution-managed counterparts, to allow locally installed software to
override whatever the distribution ships.

In my case, the change caused actual breakage when rebooting after the
upgrade, because some of my run scripts called stuff from /usr/local, which
was suddenly no longer in the PATH.

Of course, it would be possible to explcitily set the PATH in all run
scripts, but I'd prefer them to inherit a sane default.

Best regards,

András

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

Versions of packages runit-init depends on:
ii  getty-run 2.1.2-18
ii  initscripts   2.88dsf-59.9+devuan3
ii  libc6 2.27-8
ii  runit 2.1.2-18
ii  runit-helper  2.7.3
ii  sysv-rc   2.88dsf-59.9+devuan3

runit-init recommends no packages.

runit-init suggests no packages.

-- no debconf information

-- 
   Back to Nature - but not on foot.



  1   2   3   >