Bug#974563: corosync unable to communicate with pacemaker 1.1.16-1+deb9u1 which contains the fix for CVE-2020-25654
Hi Markus, The problem is still the same here: Nov 12 18:14:46 srv1 lrmd[990]: warning: Rejecting IPC request 'lrmd_rsc_info' from unprivileged client crmd Nov 12 18:14:46 srv1 lrmd[990]: warning: Rejecting IPC request 'lrmd_rsc_register' from unprivileged client crmd Nov 12 18:14:46 srv1 crmd[993]:error: Could not add resource dummy_activenode to LRM nmsrv1 Nov 12 18:14:46 srv1 crmd[993]:error: Invalid resource definition for dummy_activenode [root@srv1 root]# dpkg -l pacemaker ii pacemaker 1.1.16-1+deb9u1.1 amd64 cluster resource manager Downgrading to "pacemaker=1.1.16-1" fixed it again. On 2020. november 12., csütörtök 17:51:28 CET, Markus Koschany wrote: Thanks for reporting. This is a permission problem. I assume your clients are local and not remote and you don't use the tls_backend. I have prepared another update that should grant the local hacluser clients the necessary privileges. You can download the source and binary files from https://people.debian.org/~apo/lts/pacemaker/ Please report back if this fixes the problem. If not, please send me your log file via private email after you have set the logfile_priority to debug in corosync.conf.
Bug#800722: [Pkg-php-pecl] Bug#800722: h(M)set: Segfaults for NULL and boolean values
Hi, 2015-10-03 21:24 GMT+02:00 Jonas Genannt : >> Long story short: https://github.com/phpredis/phpredis/issues/524 >> Easy to reproduce by the github report. It's a common problem, please >> consider a fix for stable. Backported 2.2.7 works well for me. >> >> I am using Debian Jessie, php5-fpm with nginx. > > it was reported here: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=789596 > > Back then I was not able to replicate the problem. If you could provide a > easy script > that will trigger the error we are happy to try to fix it. Seems like I can not reproduce in test environment with an easy script. Test code injected into our complex site triggers but that's pretty far from the easy. I'll try to boil it down sometime. Thanks.
Bug#800722: h(M)set: Segfaults for NULL and boolean values
Package: php5-redis Version: 2.2.5-1 Long story short: https://github.com/phpredis/phpredis/issues/524 Easy to reproduce by the github report. It's a common problem, please consider a fix for stable. Backported 2.2.7 works well for me. I am using Debian Jessie, php5-fpm with nginx.
Bug#706676: sysvinit: /sbin/init doesn't support LXC gracefull shutdown via lxc-shutdown
The problem is lxc has to watch the jail's utmp file to guess when it wants to halt, because Linux kernels before version 3.4 does not provide any function to reboot or halt a container from inside. It has leaded to a dirty hack in lxc-utils that failed now. First problem is the overlaid /run; the Wheezy initscript mounts a tmpfs in /run and (re)creates utmp file there but lxc-utils won't notice it. This could be fixed several ways: 1. do not give permission for the container to mount file systems, drop sys_admin capability 2. mount tmpfs in /run from the container's lxc config before the container mounts it Second problem is the absolute symlink in /var/run; lxc-utils does not expect absolute symlink there so it will watch the host's utmp file for changes that pretty useless. You cannot replace this absolute link in a Wheezy container, the initscript will restore that on next boot. A trivial solution to patch lxc-utils to prefer /run over /var/run for utmp watching, see my attachment. Yes, my patch just an another hack, but not worth much effort to properly fix it, because the next Debian-stable will get rid of this utmp-hack as the kernel will support reboot() in process namespaces.. prefer_run_for_utmp_watching.diff Description: Binary data
Bug#620201: linux-image-2.6.38-1-amd64: Kernel panic with enabled RPS on a highly loaded LVS
2011/3/31 Ben Hutchings : > On Wed, 2011-03-30 at 19:28 +0200, Roland Pallai wrote: > [...] >> Before the building I applied the lightweight "forward_shared-2.6.37-2.diff" >> patch from Julian Anastasov (and I bumped the version to -1.1~magex). >> forward_shared is enabled (by default) on all interfaces. >> >> I think the problem isn't depend on the small forward_shared patch. > [...] > > Please remove it and verify that. Currently I can't, the forward_shared feature cruical for the network. I try to figure out how can I get rid of forward_shared on the next week, but I'm not sure if it's possible. On the other hand, is enough evidence that the problem doesn't depend on the forward_shared patch if the LVS box is stable in the current configuration (br0 disabled, forward_shared enabled) for a week? Later I can enable br0 again to make sure that the panic depends on the bridge interface. Disabled RPS with enabled br0 is another interesting experiment. Experiments with enabled forward_shared would be much easier for me than remove that feature. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#406684: patch
Hi!
Ah, I spent a hour to debug why my IPSec connections are freezing after Etch
upgrade at fixed intervals. Here is a fix.
--
dap
--- racoon-tool.orig 2007-02-07 09:42:10.0 +0100
+++ racoon-tool 2007-04-23 18:41:25.0 +0200
@@ -707,7 +707,8 @@
$stuff = $sainfo{$template};
if ( $template eq '%default' ) {
foreach my $property ( keys %sainfo_addons ) {
- next if defined $hndl->{'pfs_group'} && $hndl->{'pfs_group'} eq 'none';
+ next if $property eq "pfs_group" &&
+defined $hndl->{'pfs_group'} && $hndl->{'pfs_group'} eq 'none';
if ( defined $hndl->{"$property"} ) {
$stuff =~ s/^(\s*sainfo.*)$/${1}\n\t${sainfo_addons{"$property"}}/m;
}
