Bug#1040186: ipmitool: IANA PEN registry open failed: No such file or directory
Dear maintainer, > after upgrade to bookworm, ipmitool outputs this on every invocation: > > IANA PEN registry open failed: No such file or directory same here. After manual download of the file, ipmitool works: | cd /usr/share/misc | wget https://www.iana.org/assignments/enterprise-numbers.txt This seems to be fixed in 1.8.19-5 which will hopefully land in bookworm's first point release. -- Adi signature.asc Description: This is a digitally signed message part.
Bug#1033654: akonadi broken with libmariadb from s-p-u
Package: libmariadb3
Version: 1:10.5.19-0+deb11u1
Dear maintainers,
when trying to use libmariadb3 from stable-proposed-updates, akonadi (the
backend service for kde's pim tools) does not work any more and shows the
following error messages on the console:
| org.kde.pim.akonadiserver: New notification connection
| (registered as Akonadi::Server::NotificationSubscriber(0x7effcc0840e0) )
| org.kde.pim.akonadiserver: DATABASE ERROR:
| org.kde.pim.akonadiserver: Error code: "1292"
| org.kde.pim.akonadiserver: DB error: "Incorrect datetime value:
| '2023-03-29T12:31:24Z' for column `akonadi`.`pimitemtable`.`atime` at
row 1"
| org.kde.pim.akonadiserver: Error text: "Incorrect datetime value:
| '2023-03-29T12:31:24Z' for column `akonadi`.`pimitemtable`.`atime` at
row 1
| QMYSQL: Unable to execute query"
| org.kde.pim.akonadiserver: Values: QMap((":0", QVariant(QDateTime,
| QDateTime(2023-03-29 12:31:24.551 UTC Qt::UTC)))(":1",
QVariant(qlonglong, 18)))
| org.kde.pim.akonadiserver: Query: "UPDATE PimItemTable SET atime = :0
WHERE
| ( PimItemTable.collectionId = :1 )"
| org.kde.pim.akonadiserver: Unable to update item access time
Downgrading to 1:10.5.18-0+deb11u1 immediately fixes the issue. It would be
great if it was possible to tackle down this issue before the broken
package enters stable for the next point release. Please let me know if
there is anything I can do to help!
all the best,
Adi
signature.asc
Description: PGP signature
Bug#1031811: redmine: mercurial helper broken
Dear Jakob,
> I've enhanced the patch from the upstream bugtracker by file name
> encoding support as configured in redmine.
that is ingenious! Thank you very much!
> Could you test the new patch [1]?
>
> [1]
> https://salsa.debian.org/ruby-team/redmine/-/blob/bts1031811/debian/patches/mercurial-py3-fix
The patch works just fine except for one thing; the change in the ruby
adapter needs to read something like this:
| full_args << '--config' << "redminehelper.fileencoding=#{path_encoding}"
because using '<<' to add the path_encoding variable causes ruby to add a
space in front of -- in my case -- 'UTF-8' ultimately leading to this
error:
| hg: unknown command 'UTF-8'
| (use 'hg help' for a list of commands)
Except for that, everything works just fine! Thank you very much! :)
all the best,
Adi
signature.asc
Description: PGP signature
Bug#1031811: redmine: mercurial helper broken
Package: redmine
Version: 5.0.4-4
Tags: patch
Dear maintainers,
thank you very much for providing redmine and the backport to bullseye!
The mercurial integration of redmine relys on a helper shim that is written
in python 2 and is not compatible with python 3. The upstream issue[1]
already contains a patch[2] that works just fine for us. We only changed
the encoding from cp1252 back to utf-8[3]. Find attached the patch which
is only modified to use utf-8.
It would be great to get the mercurial helper updated for bookworm!
thank you and all the best,
Adi
[1] https://www.redmine.org/issues/33784
[2] https://www.redmine.org/attachments/download/30004/33784_Redmine_5.0.3.patch
[3] https://www.redmine.org/issues/33784#note-10
diff --git a/lib/redmine/scm/adapters/mercurial/redminehelper.py b/lib/redmine/scm/adapters/mercurial/redminehelper.py
index c187df8c2..38ad1c8a1 100644
--- a/lib/redmine/scm/adapters/mercurial/redminehelper.py
+++ b/lib/redmine/scm/adapters/mercurial/redminehelper.py
@@ -5,6 +5,9 @@
#
# This software may be used and distributed according to the terms of the
# GNU General Public License version 2 or any later version.
+
+# [Nomadia-changes] Patch from Redmine.org #33784 : adapt to Python 3.0
+
"""helper commands for Redmine to reduce the number of hg calls
To test this extension, please try::
@@ -45,17 +48,20 @@ Output example of rhmanifest::
"""
-import re, time, cgi, urllib
+import re, time, html, urllib
from mercurial import cmdutil, commands, node, error, hg, registrar
cmdtable = {}
command = registrar.command(cmdtable) if hasattr(registrar, 'command') else cmdutil.command(cmdtable)
-_x = cgi.escape
-_u = lambda s: cgi.escape(urllib.quote(s))
+_x = lambda s: html.escape(s.decode('utf-8')).encode('utf-8')
+_u = lambda s: html.escape(urllib.parse.quote(s)).encode('utf-8')
+
+def unquoteplus(*args, **kwargs):
+return urllib.parse.unquote_to_bytes(*args, **kwargs).replace(b'+', b' ')
def _changectx(repo, rev):
-if isinstance(rev, str):
+if isinstance(rev, bytes):
rev = repo.lookup(rev)
if hasattr(repo, 'changectx'):
return repo.changectx(rev)
@@ -70,10 +76,10 @@ def _tip(ui, repo):
except TypeError: # Mercurial < 1.1
return repo.changelog.count() - 1
tipctx = _changectx(repo, tiprev())
-ui.write('\n'
+ui.write(b'\n'
% (tipctx.rev(), _x(node.hex(tipctx.node()
-_SPECIAL_TAGS = ('tip',)
+_SPECIAL_TAGS = (b'tip',)
def _tags(ui, repo):
# see mercurial/commands.py:tags
@@ -84,7 +90,7 @@ def _tags(ui, repo):
r = repo.changelog.rev(n)
except error.LookupError:
continue
-ui.write('\n'
+ui.write(b'\n'
% (r, _x(node.hex(n)), _u(t)))
def _branches(ui, repo):
@@ -104,136 +110,145 @@ def _branches(ui, repo):
return repo.branchheads(branch)
def lookup(rev, n):
try:
-return repo.lookup(rev)
+return repo.lookup(str(rev).encode('utf-8'))
except RuntimeError:
return n
for t, n, r in sorted(iterbranches(), key=lambda e: e[2], reverse=True):
if lookup(r, n) in branchheads(t):
-ui.write('\n'
+ui.write(b'\n'
% (r, _x(node.hex(n)), _u(t)))
def _manifest(ui, repo, path, rev):
ctx = _changectx(repo, rev)
-ui.write('\n'
+ui.write(b'\n'
% (ctx.rev(), _u(path)))
known = set()
-pathprefix = (path.rstrip('/') + '/').lstrip('/')
+pathprefix = (path.decode('utf-8').rstrip('/') + '/').lstrip('/')
for f, n in sorted(ctx.manifest().iteritems(), key=lambda e: e[0]):
-if not f.startswith(pathprefix):
-continue
-name = re.sub(r'/.*', '/', f[len(pathprefix):])
+fstr = f.decode('utf-8')
+if not fstr.startswith(pathprefix):
+ continue
+name = re.sub(r'/.*', '/', fstr[len(pathprefix):])
if name in known:
continue
known.add(name)
if name.endswith('/'):
-ui.write('\n'
- % _x(urllib.quote(name[:-1])))
+ui.write(b'\n'
+ % _x(urllib.parse.quote(name[:-1]).encode('utf-8')))
else:
fctx = repo.filectx(f, fileid=n)
tm, tzoffset = fctx.date()
-ui.write('\n'
+ui.write(b'\n'
% (_u(name), fctx.rev(), _x(node.hex(fctx.node())),
tm, fctx.size(), ))
-ui.write('\n')
+ui.write(b'\n')
-@command('rhannotate',
- [('r', 'rev', '', 'revision'),
- ('u', 'user', None, 'list the author (long with -v)'),
- ('n', 'number', None, 'list the revision number (default)'),
- ('c', 'changeset', None, 'list the changeset'),
+@command(b'rhannotate',
+ [(b'r', b'rev', b'', b'revision'),
+ (b'u', b'user', None, b'list the author (long with -v)'),
+
Bug#1031000: keysize of generated certificates
Sorry, this time with the patch...
--- kxd-0.15.orig/kxgencert/kxgencert.go
+++ kxd-0.15/kxgencert/kxgencert.go
@@ -68,8 +68,8 @@ func main() {
}
}
- // Generate a private key (RSA 2048).
- privK, err := rsa.GenerateKey(crand.Reader, 2048)
+ // Generate a private key (RSA 4096).
+ privK, err := rsa.GenerateKey(crand.Reader, 4096)
if err != nil {
fatalf("Error generating key: %v\n", err)
}
signature.asc
Description: PGP signature
Bug#1031000: keysize of generated certificates
Package: kxgencert Version: 0.15-2 Severity: important Tags: patch Dear maintainers, thank you very much for providing kxd as a part of Debian! I recently did a test setup and noticed that kxgencert creates the ssl certificates used for secure luks passphrase exchange with 2048 bit which is even hardcoded in the go file and thus cannot be overridden by a command line flag. Based on ECRYPT[1] and BSI[2] recommendations, I'd suggest to switch to 4096 bits by default. Find attached a trivial patch that increases the key size to 4096bit. It would be great if this patch could make it into Bookworm... :) Thank you very much for your work! all the best, Adi [1] https://www.ecrypt.eu.org/csa/documents/D5.4-FinalAlgKeySizeProt.pdf [2] https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TG02102/BSI-TR-02102-1.pdf?__blob=publicationFile signature.asc Description: PGP signature
Bug#1022126: mpt3sas broken with xen dom0
Tags: patch
Dear maintainers,
after the discussion about the root cause of this issue on the linux-scsi
mailing list[1] there was one simple patch submitted to this list[2] that
just changes the logic of the selection of the dma mask: in case of a 64bit
host operating system, the driver chooses a 63/64bit mask.
We backported and tested this patch on our systems and everything works
just fine. Find our backported patch for 5.10 kernels attached. We tested
that patch with 5.10.149-2/5.10.0-19 and 5.10.158-2/5.10.0-20.
Note, however, this patch has not yet been merged upstream and thus there
is no backport of this to the lts kernels. I am pretty unsure about how to
proceed: currently we're using dkms to build binary module packages with
the attached patch (dkms mkbmdeb) and do deploy these to our servers but
we'd really love to see this patch upstream and downstream! :)
all the best,
Adi
[1] https://lore.kernel.org/linux-scsi/y1jkuktjvyrow...@eldamar.lan/T/
[2]
https://lore.kernel.org/linux-scsi/20221028091655.17741-2-sreekanth.re...@broadcom.com/T/
--- a/drivers/scsi/mpt3sas/mpt3sas_base.c 2022-12-14 18:08:44.136490166 +0100
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.c 2022-12-14 18:15:16.682042992 +0100
@@ -2823,9 +2823,7 @@
{
struct sysinfo s;
- if (ioc->is_mcpu_endpoint ||
- sizeof(dma_addr_t) == 4 || ioc->use_32bit_dma ||
- dma_get_required_mask(>dev) <= DMA_BIT_MASK(32))
+ if (ioc->is_mcpu_endpoint || sizeof(dma_addr_t) == 4)
ioc->dma_mask = 32;
/* Set 63 bit DMA mask for all SAS3 and SAS35 controllers */
else if (ioc->hba_mpi_version_belonged > MPI2_VERSION)
signature.asc
Description: PGP signature
Bug#1026035: xen netback broken with 5.10.0-20-amd64 in s-p-u
Dear Diederik, > > we just upgraded our xen test cluster's kernel to the latest kernel from > > s-p-u and noticed that network communication is broken. We do have a > > 'classic' setup with bridges in dom0. After upgrading dom0's kernel, no > > communication is possible for the domU. > > > > If there is anything we can do to help fixing that issue, we'll gladly do > > that! thank you very much for your help! > https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#s4.2.2 > describes a (relatively simple) way to test a patch. > > I found in current master/6.1 branch 2 commits which may be relevant: > > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/? > id=7dfa764e0223a324366a2a1fc056d4d9d4e95491 This patch did the trick; while digging through the source, I noticed that this fix is already included in the patch for XSA-423[1][2] referenced at the oss-sec list. Obviously the patch for XSA-423v1 has been included in 5.10.158-1 while XSA-423v2 is the most recent version of the patch. The difference between the two versions of that patch is exactly the initialization of the variable 'err' that just fixes this issue. > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/? > id=9e624651859214fb2c4e442b059eba0aefcd0801 This patch does not seem to be necessary as the patch for XSA-424 does alreay contain a different fix for this issue. > You'd possibly need to backport it to the 5.10 code, but if you can do that > and test whether the updated kernel fixes the issue, that would be great. Again: thank you very much for the quick response. I can confirm that the issue is indeed fixed with the first patch; maybe updating to XSA-423v2 is the more appropriate way to fix the issue. all the best, Adi [1] https://seclists.org/oss-sec/2022/q4/174 [2] https://seclists.org/oss-sec/2022/q4/att-174/xsa423-linux.patch signature.asc Description: PGP signature
Bug#1026035: xen netback broken with 5.10.0-20-amd64 in s-p-u
Source: linux Version: 5.10.158-1 Dear maintainers, we just upgraded our xen test cluster's kernel to the latest kernel from s-p-u and noticed that network communication is broken. We do have a 'classic' setup with bridges in dom0. After upgrading dom0's kernel, no communication is possible for the domU. We can see packets arrive at the domU and packets leave the domU; but they never arrive at the virtual interface in dom0 (rx counter stays at 0 and error counters stay at 0 too). When migrating the domU back to the other server which has not been upgraded, the machine is reachable again. If there is anything we can do to help fixing that issue, we'll gladly do that! Thank you very much! -- Adi signature.asc Description: PGP signature
Bug#1022126: mpt3sas broken with xen dom0
Package: linux-image-amd64 Dear maintainers, I noticed that my bugreport got sent to unknown-pack...@qa.debian.org as I seem to have specified a wrong package. Trying to fix that now... thanks, Adi signature.asc Description: PGP signature
Bug#1022126: mpt3sas broken with xen dom0
Package: linux-image-5.10.0-19-amd64 Version: 5.10.149-1 Severity: important Dear maintainers, with the upgrade to the latest bullseye kernel (5.10.149-1), our xen setup is unbootable due to swiotlb buffer errors: | sd 0:0:0:0: scsi_dma_map failed: request for 401408 bytes! and | mpt3sas :01:00.0: swiotlb buffer is full (sz: 401408 bytes), | total 32768 (slots), used 0 (slots) (the byte sizes vary between boots). After reading bug #850425[1], we also tried to force 32bit mode in the mpt3sas driver by specifying a dom0 memory below 4G; this lets the machine boot, but almost immediately after that fails with the same error. Notable difference is that the used slots are 128. Xen commandline: dom0_mem=4096M,max:4096M dom0_max_vcpus=4 dom0_vcpus_pin ucode=scan xpti=dom0=false,domu=true gnttab_max_frames=128 Using dom0-iommu=map-inclusive in some combinations with swiotlb on the kernel commandline gives us some used slots (way below 128) in the error message even in 64bit dma mode in the mpt3sas driver. The kernel works when booted without xen. We'd be more than happy to get pointers on how to fix that issue or patches to test! Thanks for your help! -- Adi [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850425 signature.asc Description: PGP signature
Bug#1021527: isc-dhcp-server: apt upgrade fails with sed error
Hi! This could happen when there is a comma in the list of interfaces (in /etc/default/isc-dhcp-server). Please check the output of | debconf-show isc-dhcp-server for commas in the 'isc-dhcp-server/interfaces' variable or the content of /etc/default/isc-dhcp-server and look for commas in INTERFACESv4 or INTERFACESv6. To specify more interfaces a space between the interfaces is sufficient. best regards, Adi Kriegisch signature.asc Description: PGP signature
Bug#1019238: ...a more upstream-like fix for the issue
Dear all, according to the corresponding github issue[1], the source of the problem is an old version of psych embedded into ruby2.5 (which already is eol upstream). While we're all eagerly awaiting a backport of redmine for bullseye, the issue can be mitigated by the following 3 steps: 1. install the patched version of yaml_column.rb: | mv /usr/share/rubygems-integration/all/gems/activerecord-5.2.2.1/lib/active_record/coders/yaml_column.rb \ | /usr/share/rubygems-integration/all/gems/activerecord-5.2.2.1/lib/active_record/coders/yaml_column.rb-orig | wget -O /usr/share/rubygems-integration/all/gems/activerecord-5.2.2.1/lib/active_record/coders/yaml_column.rb \ | https://raw.githubusercontent.com/skipkayhil/rails/5ab06e54b6868b249185e9fdf46349155665c54a/activerecord/lib/active_record/coders/yaml_column.rb 2. patch psych by overriding the class: | cat >> /usr/lib/ruby/2.5.0/psych.rb
Bug#990987: cfengine3 memory leak(s) -- with patches
I am very sorry, I forgot to attach the patches: so this time with patches!
best regards,
Adi Kriegisch
From f2bee6b45cfc617330b9a5057db6e8425943900b Mon Sep 17 00:00:00 2001
From: Ole Herman Schumacher Elgesem
Date: Mon, 3 Dec 2018 13:59:40 +0100
Subject: [PATCH] Fixed memory leak in filesexist function
Changelog: Title
Ticket: ENT-4313
Signed-off-by: Ole Herman Schumacher Elgesem
(cherry picked from commit 64589e5cb308e46646a46ef84cb57e487f4f7ddc)
---
libpromises/evalfunction.c | 1 +
1 file changed, 1 insertion(+)
Index: cfengine3-3.12.1/libpromises/evalfunction.c
===
--- cfengine3-3.12.1.orig/libpromises/evalfunction.c
+++ cfengine3-3.12.1/libpromises/evalfunction.c
@@ -7095,6 +7095,7 @@ static FnCallResult FnCallFileSexist(Eva
{
file_found = false;
}
+free(val);
el = JsonIteratorNextValueByType(, JSON_ELEMENT_TYPE_PRIMITIVE, true);
}
From afd1c1b21de0ea378c68b397df140979b1b96fa4 Mon Sep 17 00:00:00 2001
From: Ole Herman Schumacher Elgesem
Date: Thu, 8 Nov 2018 23:54:30 +0100
Subject: [PATCH] Fixed memory leak in JSON to policy conversion
Ticket: ENT-4136
Changelog: Title
Signed-off-by: Ole Herman Schumacher Elgesem
(cherry picked from commit b90dce1d265e51a3d4352ed8bf9016653a34d96c)
---
libpromises/policy.c | 2 ++
libpromises/rlist.c | 1 +
2 files changed, 3 insertions(+)
diff --git a/libpromises/policy.c b/libpromises/policy.c
index f433b66c062..d3b03639959 100644
--- a/libpromises/policy.c
+++ b/libpromises/policy.c
@@ -2111,6 +2111,7 @@ static Rval RvalFromJson(JsonElement *json_rval)
{
Rval list_value = RvalFromJson(JsonArrayGetAsObject(json_list, i));
RlistAppend(, list_value.item, list_value.type);
+RvalDestroy(list_value);
}
return ((Rval) { rlist, RVAL_TYPE_LIST });
@@ -2127,6 +2128,7 @@ static Rval RvalFromJson(JsonElement *json_rval)
Rval arg = RvalFromJson(json_arg);
RlistAppend(, arg.item, arg.type);
+RvalDestroy(arg);
}
FnCall *fn = FnCallNew(name, args);
diff --git a/libpromises/rlist.c b/libpromises/rlist.c
index 6e6024f5c0f..5048387c0aa 100644
--- a/libpromises/rlist.c
+++ b/libpromises/rlist.c
@@ -526,6 +526,7 @@ Rlist *RlistAppendScalar(Rlist **start, const char *scalar)
return RlistAppendRval(start, RvalCopyScalar((Rval) { (char *)scalar, RVAL_TYPE_SCALAR }));
}
+// NOTE: Copies item, does NOT take ownership
Rlist *RlistAppend(Rlist **start, const void *item, RvalType type)
{
return RlistAppendAllTypes(start, item, type, false);
From 7dc010d62474550cda7cddc2132988d6fcfeb51c Mon Sep 17 00:00:00 2001
From: Ole Herman Schumacher Elgesem
Date: Fri, 9 Nov 2018 00:10:18 +0100
Subject: [PATCH] Fixed small memory leak in cf-upgrade
Changelog: Title
Ticket: ENT-4136
Signed-off-by: Ole Herman Schumacher Elgesem
(cherry picked from commit ee55bbad775d7a104aa6a7c997b512334d978f90)
---
cf-upgrade/configuration.c | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/cf-upgrade/configuration.c b/cf-upgrade/configuration.c
index b4917907ecc..2f43504f233 100644
--- a/cf-upgrade/configuration.c
+++ b/cf-upgrade/configuration.c
@@ -61,12 +61,18 @@ void ConfigurationDestroy(Configuration **configuration)
{
return;
}
-free ((*configuration)->cf_upgrade);
-free ((*configuration)->backup_path);
-free ((*configuration)->backup_tool);
-free ((*configuration)->copy_path);
-free ((*configuration)->cfengine_path);
-free (*configuration);
+Configuration *config = *configuration;
+for (int i = 0; i < config->number_of_arguments; ++i)
+{
+free(config->arguments[i]);
+config->arguments[i] = NULL;
+}
+free(config->cf_upgrade);
+free(config->backup_path);
+free(config->backup_tool);
+free(config->copy_path);
+free(config->cfengine_path);
+free(config);
*configuration = NULL;
}
From 9a46bd2e529c8d4099613ec1e502b7b8350bbc05 Mon Sep 17 00:00:00 2001
From: Ole Herman Schumacher Elgesem
Date: Thu, 6 Dec 2018 16:41:31 +0100
Subject: [PATCH] Fixed memory leak in mustache rendering
Changelog: Title
Ticket: ENT-4313
Signed-off-by: Ole Herman Schumacher Elgesem
(cherry picked from commit 8078b566047095eda15d21d4a788efdcec6bc135)
---
cf-agent/verify_files.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/cf-agent/verify_files.c b/cf-agent/verify_files.c
index 9c29288a9c0..8283f335482 100644
--- a/cf-agent/verify_files.c
+++ b/cf-agent/verify_files.c
@@ -602,9 +602,12 @@ static PromiseResult RenderTemplateMustache(EvalContext *ctx, const Promise *pp,
{
PromiseResult result = PROMISE_RESULT_NOOP;
+JsonElement *destroy_this = NULL;
+
if (a.template_data == NULL)
{
a.template_data = DefaultTemplateData(ctx, NULL
Bug#990987: cfengine3 memory leak(s)
Source: cfengine3 Version: 3.12.1-2 Tags: patch, fixed-upstream, buster Severity: important Dear maintainer, while deploying cfengine3 in our network, we noticed that cf-execd and cf-monitord do have an ever increasing memory use. Reviewing the changelog[1] of the 3.12LTS release revealed several memory leak fixes. We extracted these fixes from the github commits, applied them on top of the current debian packages and verified that the memory leaks are indeed gone. It would be great if you could add these patches to the debian packages for buster. best regards, Adi Kriegisch [1] https://docs.cfengine.com/docs/3.12/guide-latest-release-whatsnew-changelog-core.html signature.asc Description: PGP signature
Bug#986800: CVE-2021-30163 CVE-2021-30164
Tags: security, patch
Dear maintainers,
I took the patches from upstream and rebased them; so far everything works
fine on our systems. I'd very much apprechiate an officially patched
version in buster-backports.
CVE-2021-31863:
https://www.redmine.org/projects/redmine/repository/revisions/20854
CVE-2021-31864:
https://www.redmine.org/projects/redmine/repository/revisions/20946
CVE-2021-31865:
https://www.redmine.org/projects/redmine/repository/revisions/20970
CVE-2021-31866:
https://www.redmine.org/projects/redmine/repository/revisions/20962
best regards,
Adi Kriegisch
Index: redmine-4.0.7/app/models/token.rb
===
--- redmine-4.0.7.orig/app/models/token.rb
+++ redmine-4.0.7/app/models/token.rb
@@ -113,11 +113,13 @@ class Token < ActiveRecord::Base
return nil unless action.present? && key =~ /\A[a-z0-9]+\z/i
token = Token.find_by(:action => action, :value => key)
-if token && (token.action == action) && (token.value == key) && token.user
- if validity_days.nil? || (token.created_on > validity_days.days.ago)
-token
- end
-end
+return unless token
+return unless token.action == action
+return unless ActiveSupport::SecurityUtils.secure_compare(token.value.to_s, key)
+return unless token.user
+return unless validity_days.nil? || (token.created_on > validity_days.days.ago)
+
+token
end
def self.generate_token_value
Index: redmine-4.0.7/app/controllers/sys_controller.rb
===
--- redmine-4.0.7.orig/app/controllers/sys_controller.rb
+++ redmine-4.0.7/app/controllers/sys_controller.rb
@@ -16,6 +16,8 @@
# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
class SysController < ActionController::Base
+ include ActiveSupport::SecurityUtils
+
before_action :check_enabled
def projects
@@ -74,7 +76,7 @@ class SysController < ActionController::
def check_enabled
User.current = nil
-unless Setting.sys_api_enabled? && params[:key].to_s == Setting.sys_api_key
+unless Setting.sys_api_enabled? && secure_compare(params[:key].to_s, Setting.sys_api_key.to_s)
render :plain => 'Access denied. Repository management WS is disabled or key is invalid.', :status => 403
return false
end
Index: redmine-4.0.7/app/controllers/mail_handler_controller.rb
===
--- redmine-4.0.7.orig/app/controllers/mail_handler_controller.rb
+++ redmine-4.0.7/app/controllers/mail_handler_controller.rb
@@ -16,6 +16,8 @@
# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
class MailHandlerController < ActionController::Base
+ include ActiveSupport::SecurityUtils
+
before_action :check_credential
# Displays the email submission form
@@ -37,7 +39,7 @@ class MailHandlerController < ActionCont
def check_credential
User.current = nil
-unless Setting.mail_handler_api_enabled? && params[:key].to_s == Setting.mail_handler_api_key
+unless Setting.mail_handler_api_enabled? && secure_compare(params[:key].to_s, Setting.mail_handler_api_key.to_s)
render :plain => 'Access denied. Incoming emails WS is disabled or key is invalid.', :status => 403
end
end
Index: redmine-4.0.7/test/unit/attachment_test.rb
===
--- redmine-4.0.7.orig/test/unit/attachment_test.rb
+++ redmine-4.0.7/test/unit/attachment_test.rb
@@ -151,6 +151,19 @@ class AttachmentTest < ActiveSupport::Te
end
end
+ def test_extension_update_should_be_validated_against_denied_extensions
+with_settings :attachment_extensions_denied => "txt, png" do
+ a = Attachment.new(:container => Issue.find(1),
+ :file => mock_file_with_options(:original_filename => "test.jpeg"),
+ :author => User.find(1))
+ assert_save a
+
+ b = Attachment.find(a.id)
+ b.filename = "test.png"
+ assert !b.save
+end
+ end
+
def test_valid_extension_should_be_case_insensitive
with_settings :attachment_extensions_allowed => "txt, Png" do
assert Attachment.valid_extension?(".pnG")
Index: redmine-4.0.7/app/models/attachment.rb
===
--- redmine-4.0.7.orig/app/models/attachment.rb
+++ redmine-4.0.7/app/models/attachment.rb
@@ -27,7 +27,8 @@ class Attachment < ActiveRecord::Base
validates_length_of :filename, :maximum => 255
validates_length_of :disk_filename, :maximum => 255
validates_length_of :description, :maximum => 255
- validate :validate_max_file_size, :validate_file_extension
+ validate :validate_max_file_
Bug#988795: keyring 1.3.1 broken with mercurial demand imports
Package: mercurial-keyring Version: 1.3.1-3 Severity: important Dear maintainer, mercurial-keyring is currently unusable in bullseye due to this bug: https://foss.heptapod.net/mercurial/mercurial_keyring/-/issues/69 that is already fixed upstream: https://foss.heptapod.net/mercurial/mercurial_keyring/-/commit/392dc26703721711ffad42c16e5c32af7428bc28 in version 1.3.2. It would be great to get at least the fix backported to the current version in bullseye in order to have a working mercurial-keyring package once stable gets released. A workaround for the user is to set "HGDEMANDIMPORT=disable", thus this bug does not render the package completely unusable. Thank you and all the best, Adi signature.asc Description: PGP signature
Bug#986671: aoe-sancheck and interface names
Dear Christoph, thank you very much for your quick response and your insightful comments in the upstream bug report. > Just in case, adding "net.ifnames=0" to the kernel command line restores the > old behaviour - but I understand there are various reasons, up to and > including > layer 9, to not do that. Of course... Up to now we managed to get around systemd and all the extra effects it has. As we are afraid that bullseye may be the last usable debian version that can be operated without systemd, we at least need to test an upgrade path. > > Looking into the source revealed that "eth" is hardcoded in aoe-sancheck.c > > to find valid interfaces. > Yeah, that doesn't make much sense nowadays. The code really should probe the > interface's capabilities instead, I've made a suggestion in the related > upstream bug. You are absolutely right; I refreshed the patch to check for: * IFF_NOARP * IFF_UP * IFF_LOOPBACK > > The trivial patch attached fixes the issue while still being able to > > correctly identify old interface names as well. > > We'd be very glad if this patch could still make it into bullseye... ;-) > Understood. I'll see what upstream will do about that, quite frankly, > your patch is rather last resort - and I know we're in a time frame > here. Thank you for asking for better solutions... :) I hope, the attache version two of the patch better fits the bill! all the best, Adi --- a/aoe-sancheck.c +++ b/aoe-sancheck.c @@ -513,8 +513,18 @@ ethlist(char **ifs, int nifs) ifr.ifr_ifindex = i; if (ioctl(s, SIOCGIFNAME, ) < 0) continue; - if (strncmp(ifr.ifr_name, "eth", 3)) +// get interface flags + if (ioctl(s, SIOCGIFFLAGS, ) < 0) continue; +// only use interfaces that use arp protocol +if (ifr.ifr_flags & IFF_NOARP) +continue; +// only use interfaces that are up +if (!(ifr.ifr_flags & IFF_UP)) +continue; +// skip loopback interfaces +if (ifr.ifr_flags & IFF_LOOPBACK) +continue; inserteth(ifs, nifs, ifr.ifr_name); n++; } signature.asc Description: PGP signature
Bug#986671: aoe-sancheck and interface names
Package: aoetools Version: 36-3 Tags: patch Dear maintainer, we recently tested aoe on a newly created bullseye test system and noticed that aoe-sancheck did not detect any interfaces. Up to now, we used bios device names and had no problems with this whatsoever but the test system uses the default interface names (enp*). Looking into the source revealed that "eth" is hardcoded in aoe-sancheck.c to find valid interfaces. The trivial patch attached fixes the issue while still being able to correctly identify old interface names as well. We'd be very glad if this patch could still make it into bullseye... ;-) Thank you for your work! best regards, Adi Kriegisch --- a/aoe-sancheck.c +++ b/aoe-sancheck.c @@ -513,7 +513,7 @@ ethlist(char **ifs, int nifs) ifr.ifr_ifindex = i; if (ioctl(s, SIOCGIFNAME, ) < 0) continue; - if (strncmp(ifr.ifr_name, "eth", 3)) + if (strncmp(ifr.ifr_name, "e", 1)) continue; inserteth(ifs, nifs, ifr.ifr_name); n++; signature.asc Description: PGP signature
Bug#787080: Bug#894119: libreoffice: Please add libreoffice-online to the debian repository.
Dear Rene, thank you very much for the hard work you've put in packaging libreoffice online. Starting from your salsa repo[1] I was able to successfully build loolwsd and loleaflet packages with the libreoffice packages from buster-backports. There were, however, some issues with the unit tests. After trying to investigate some of the issues, I decided to skip the test by adding an empty override_dh_auto_test target. Is there any reason why you use loolwsd's init script to configure it instead of setting the defaults in /etc/loolwsd/loolwsd.xml? With the current init script this does not work. May I suggest to use a simpler init script like this one: 8<-8<-8<-8<-8<-8<-8<-8<- #!/bin/sh # kFreeBSD do not accept scripts as interpreters, using #!/bin/sh and sourcing. if [ true != "$INIT_D_SCRIPT_SOURCED" ] ; then set "$0" "$@"; INIT_D_SCRIPT_SOURCED=true . /lib/init/init-d-script fi ### BEGIN INIT INFO # Provides: loolwsd # Required-Start:$remote_fs # Required-Stop: $remote_fs # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 # Short-Description: libreoffice online server # Description: libreoffice online server ### END INIT INFO DESC="libreoffice online server" DAEMON=/usr/bin/loolwsd DAEMON_ARGS="--daemon" START_ARGS="--chuid lool --user lool" ->8->8->8->8->8->8->8->8 I very much hope, you're going to continue your excellent work and libreoffice online hits the debian archive any time in a not too distant future! ;-) best regards, Adi Kriegisch [1] https://salsa.debian.org/libreoffice-team/libreoffice/libreoffice-online/ signature.asc Description: PGP signature
Bug#968997: fwupdmgr: "Successfully" updates BIOS firmware, no effect on reboot
Hi! I had the same issue with my Thinkpad and found the culprit: Besides the obvious settings (allow user updates and the like), one needs to disable "boot order locked" in the boot settings of the bios. best regards, Adi Kriegisch signature.asc Description: PGP signature
Bug#983862: PVH -- cannot remove vm with pci passthrough
Package: xen-utils-4.11 Version: 4.11.4+57-g41a822c392-2 Severity: minor Dear maintainers, we, by accident, added a pci passthrough device config to a pvh vm and were able to boot that machine. But shutdown did not work with the following error message: | xl: libxl_pci.c:1427: do_pci_remove: Assertion `type == LIBXL_DOMAIN_TYPE_PV' failed. To remove the virtual machine and free its resources a reboot of Dom0 was necessary. A corresponding assert when creating the machine seems to be missing. We consider this to be a bug, because we should not have been able to 'xl create' that machine in the first place (or would have needed a way to dispose the vm). best regards, Adi Kriegisch signature.asc Description: PGP signature
Bug#982960: creation of lvs broken on bullseye
Package: ganeti Version: 3.0.1-1 Severity: important Tags: Patch Dear maintainers, when using ganeti with a lvm backed disk template like plain, the subsequent creation of volumes fails due to signatures left on the disk with "WARNING: Device creation failed". The reason for this seems to be a changed behavior of lvcreate in Bullseye (compared to all previous Debian releases): lvcreate will now abort with exit code 5 when a preexisting signature was detected on the physical volume. Before Bullseye, the command showed the very same warning but then successfully continued with the creation of the volume. This has also been reported upstream: https://github.com/ganeti/ganeti/issues/1585 and a patch that supresses signature checking is available in this pull request: https://github.com/ganeti/ganeti/pull/1586 The patch was tested with Buster and Bullseye and just works on both. -- Adi signature.asc Description: PGP signature
Bug#972204: kdeconnect: CVE-2020-26164
Package: kdeconnect
Version: 1.3.3-2
Severity: grave
Tags: security, patch
Dear maintainers,
on the oss-security mailing list[1], severe bugs in kdeconnect were
published with links to commits that fix them. Find attached backports of
those patches fitting the version of kdeconnect in debian/stable (buster).
Please have a careful look at CVE-2020-26164_g_ssl_validation_checks.patch
and check, whether those two disconnect() calls should really be disabled;
while testing the patches I could not find any adverse effects.
best regards,
Adi Kriegisch
[1] https://www.openwall.com/lists/oss-security/2020/10/13/4
From b279c52101d3f7cc30a26086d58de0b5f1c547fa Mon Sep 17 00:00:00 2001
From: Albert Vaca Cintora
Date: Thu, 24 Sep 2020 17:01:03 +0200
Subject: [PATCH] Do not leak the local user in the device name.
Thanks Matthias Gerstner for reporting this.
---
core/kdeconnectconfig.cpp | 8 +---
1 file changed, 1 insertion(+), 1 deletions(-)
--- a/core/kdeconnectconfig.cpp 2020-10-14 08:57:39.290290968 +0200
+++ b/core/kdeconnectconfig.cpp 2020-10-14 08:57:57.650342491 +0200
@@ -148,7 +148,7 @@
QString KdeConnectConfig::name()
{
-QString defaultName = qgetenv("USER") + '@' + QHostInfo::localHostName();
+QString defaultName = QHostInfo::localHostName();
QString name = d->m_config->value(QStringLiteral("name"), defaultName).toString();
return name;
}
From d35b88c1b25fe13715f9170f18674d476ca9acdc Mon Sep 17 00:00:00 2001
From: Matthias Gerstner
Date: Thu, 24 Sep 2020 17:03:06 +0200
Subject: [PATCH] Fix use after free in LanLinkProvider::connectError()
If QSslSocket::connectToHost() hasn't finished running.
Thanks Matthias Gerstner for reporting this.
---
core/backends/lan/lanlinkprovider.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: kdeconnect-1.3.3/core/backends/lan/lanlinkprovider.cpp
===
--- kdeconnect-1.3.3.orig/core/backends/lan/lanlinkprovider.cpp
+++ kdeconnect-1.3.3/core/backends/lan/lanlinkprovider.cpp
@@ -224,7 +224,7 @@ void LanLinkProvider::connectError()
//The socket we created didn't work, and we didn't manage
//to create a LanDeviceLink from it, deleting everything.
delete m_receivedIdentityPackets.take(socket).np;
-delete socket;
+socket->deleteLater();
}
//We received a UDP packet and answered by connecting to them by TCP. This gets called on a succesful connection.
From 721ba9faafb79aac73973410ee1dd3624ded97a5 Mon Sep 17 00:00:00 2001
From: Aleix Pol
Date: Wed, 16 Sep 2020 02:27:13 +0200
Subject: [PATCH] Don't brute-force reading the socket
The package will arrive eventually, and dataReceived will be emitted.
Otherwise we just end up calling dataReceived to no end.
Thanks Matthias Gerstner for reporting this.
---
core/backends/lan/socketlinereader.cpp | 8 ---
tests/testsocketlinereader.cpp | 31 --
2 files changed, 29 insertions(+), 10 deletions(-)
Index: kdeconnect-1.3.3/core/backends/lan/socketlinereader.cpp
===
--- kdeconnect-1.3.3.orig/core/backends/lan/socketlinereader.cpp
+++ kdeconnect-1.3.3/core/backends/lan/socketlinereader.cpp
@@ -38,14 +38,6 @@ void SocketLineReader::dataReceived()
}
}
-//If we still have things to read from the socket, call dataReceived again
-//We do this manually because we do not trust readyRead to be emitted again
-//So we call this method again just in case.
-if (m_socket->bytesAvailable() > 0) {
-QMetaObject::invokeMethod(this, "dataReceived", Qt::QueuedConnection);
-return;
-}
-
//If we have any packets, tell it to the world.
if (!m_packets.isEmpty()) {
Q_EMIT readyRead();
Index: kdeconnect-1.3.3/tests/testsocketlinereader.cpp
===
--- kdeconnect-1.3.3.orig/tests/testsocketlinereader.cpp
+++ kdeconnect-1.3.3/tests/testsocketlinereader.cpp
@@ -24,16 +24,19 @@
#include
#include
#include
+#include
class TestSocketLineReader : public QObject
{
Q_OBJECT
public Q_SLOTS:
-void initTestCase();
+void init();
+void cleanup() { delete m_server; }
void newPacket();
private Q_SLOTS:
void socketLineReader();
+void badData();
private:
QTimer m_timer;
@@ -44,8 +47,9 @@ private:
SocketLineReader* m_reader;
};
-void TestSocketLineReader::initTestCase()
+void TestSocketLineReader::init()
{
+m_packets.clear();
m_server = new Server(this);
QVERIFY2(m_server->listen(QHostAddress::LocalHost, 8694), "Failed to create local tcp server");
@@ -96,6 +100,29 @@ void TestSocketLineReader::socketLineRea
}
}
+void TestSocketLineReader::badData()
+{
+const QList dataToSend = { "data1\n", "data" }; //does not end in a \n
+for
Bug#932081: sogo: Unable to connect to a remote IMAP server.
Dear Nicolas,
> It is very well possible this is fixed already upstream by this commit:
>
> https://github.com/inverse-inc/sogo/commit/
> f7f0af67d82cf1e15daf69247a9b54df8eefd155
>
> Can you try?
This commit does not fix the issue for me; I even tried to compile
upstream SOGo and it fails exactly the same (4.2.0 - 4.3.0) when SOPE is
compiled/linked with gnutls support; when using OpenSSL everything works
just fine.[1]
best regards,
Adi Kriegisch
[1] https://sogo.nu/bugs/view.php?id=4783
signature.asc
Description: This is a digitally signed message part.
Bug#931496: redmine: Missing in Debian Buster
Dear maintainers, > Currently the 4.0.4 version in unstable is working fine but > unfortunately it is blocked from entering testing, which is a > prerequisite for the backport. Redmine 4.0.4 entered testing some time ago; are there any other obstacles that need to be worked out? best regards, Adi Kriegisch signature.asc Description: PGP signature
Bug#932089: Bug
Dear all, we're experiencing exactly the same issues with OpenSSH in Debian/Buster on mips: our access points run Debian on top of an OpenWRT kernel (built via DebWRT scripts). Find attached our kernel config (which also does not provide AUDIT features). Funny thing is, we're able to authenticate via RSA key but not with ed25519 key. Most of the time the first connection attempt fails where subsequent authentications work. The disconnect itself seems to happen while loading pam config files. On successful authentications, we do get pam debug messages, but not on failures. We'd be glad to help with debugging this nasty issue. best regards, Adi Kriegisch # # Automatically generated file; DO NOT EDIT. # Linux/mips 4.4.53 Kernel Configuration # CONFIG_MIPS=y # # Machine selection # # CONFIG_MIPS_ALCHEMY is not set # CONFIG_AR7 is not set # CONFIG_ATH25 is not set CONFIG_ATH79=y # CONFIG_BMIPS_GENERIC is not set # CONFIG_BCM47XX is not set # CONFIG_BCM63XX is not set # CONFIG_MIPS_COBALT is not set # CONFIG_MACH_DECSTATION is not set # CONFIG_MACH_JAZZ is not set # CONFIG_MACH_INGENIC is not set # CONFIG_LANTIQ is not set # CONFIG_LASAT is not set # CONFIG_MACH_LOONGSON32 is not set # CONFIG_MACH_LOONGSON64 is not set # CONFIG_MACH_PISTACHIO is not set # CONFIG_MACH_XILFPGA is not set # CONFIG_MIPS_MALTA is not set # CONFIG_MIPS_SEAD3 is not set # CONFIG_NEC_MARKEINS is not set # CONFIG_MACH_VR41XX is not set # CONFIG_NXP_STB220 is not set # CONFIG_NXP_STB225 is not set # CONFIG_PMC_MSP is not set # CONFIG_RALINK is not set # CONFIG_SGI_IP22 is not set # CONFIG_SGI_IP27 is not set # CONFIG_SGI_IP28 is not set # CONFIG_SGI_IP32 is not set # CONFIG_SIBYTE_CRHINE is not set # CONFIG_SIBYTE_CARMEL is not set # CONFIG_SIBYTE_CRHONE is not set # CONFIG_SIBYTE_RHONE is not set # CONFIG_SIBYTE_SWARM is not set # CONFIG_SIBYTE_LITTLESUR is not set # CONFIG_SIBYTE_SENTOSA is not set # CONFIG_SIBYTE_BIGSUR is not set # CONFIG_SNI_RM is not set # CONFIG_MACH_TX39XX is not set # CONFIG_MACH_TX49XX is not set # CONFIG_MIKROTIK_RB532 is not set # CONFIG_CAVIUM_OCTEON_SOC is not set # CONFIG_NLM_XLR_BOARD is not set # CONFIG_NLM_XLP_BOARD is not set # CONFIG_MIPS_PARAVIRT is not set # # Atheros AR71XX/AR724X/AR913X machine selection # CONFIG_ATH79_MACH_AP121=y CONFIG_ATH79_MACH_AP136=y # CONFIG_ATH79_MACH_AP81 is not set CONFIG_ATH79_MACH_DB120=y CONFIG_ATH79_MACH_PB44=y CONFIG_ATH79_MACH_UBNT_XM=y CONFIG_ATH79_MACH_A60=y CONFIG_ATH79_MACH_ALFA_AP120C=y CONFIG_ATH79_MACH_ALFA_AP96=y CONFIG_ATH79_MACH_HORNET_UB=y CONFIG_ATH79_MACH_ALFA_NX=y CONFIG_ATH79_MACH_TUBE2H=y CONFIG_ATH79_MACH_SC1750=y CONFIG_ATH79_MACH_SC300M=y CONFIG_ATH79_MACH_SC450=y CONFIG_ATH79_MACH_ALL0258N=y CONFIG_ATH79_MACH_ALL0315N=y CONFIG_ATH79_MACH_ANTMINER_S1=y CONFIG_ATH79_MACH_ANTMINER_S3=y CONFIG_ATH79_MACH_ANTROUTER_R1=y CONFIG_ATH79_MACH_ARDUINO_YUN=y CONFIG_ATH79_MACH_AP132=y CONFIG_ATH79_MACH_AP143=y CONFIG_ATH79_MACH_AP147=y CONFIG_ATH79_MACH_AP152=y CONFIG_ATH79_MACH_AP531B0=y CONFIG_ATH79_MACH_AP90Q=y CONFIG_ATH79_MACH_AP96=y CONFIG_ATH79_MACH_PB42=y CONFIG_ATH79_MACH_C55=y CONFIG_ATH79_MACH_C60=y CONFIG_ATH79_MACH_AW_NR580=y CONFIG_ATH79_MACH_F9K1115V2=y CONFIG_ATH79_MACH_EPG5000=y CONFIG_ATH79_MACH_ESR1750=y CONFIG_ATH79_MACH_PQI_AIR_PEN=y CONFIG_ATH79_MACH_SOM9331=y CONFIG_ATH79_MACH_SR3200=y CONFIG_ATH79_MACH_BHR_4GRV2=y CONFIG_ATH79_MACH_WHR_HP_G300N=y CONFIG_ATH79_MACH_WLAE_AG300N=y CONFIG_ATH79_MACH_WLR8100=y CONFIG_ATH79_MACH_WZR_HP_AG300H=y CONFIG_ATH79_MACH_WZR_HP_G300NH=y CONFIG_ATH79_MACH_WZR_HP_G300NH2=y CONFIG_ATH79_MACH_WZR_HP_G450H=y CONFIG_ATH79_MACH_WZR_450HP2=y CONFIG_ATH79_MACH_WP543=y CONFIG_ATH79_MACH_WPE72=y CONFIG_ATH79_MACH_WPJ342=y CONFIG_ATH79_MACH_WPJ344=y CONFIG_ATH79_MACH_WPJ531=y CONFIG_ATH79_MACH_WPJ558=y CONFIG_ATH79_MACH_XD3200=y CONFIG_ATH79_MACH_DGL_5500_A1=y CONFIG_ATH79_MACH_DHP_1565_A1=y CONFIG_ATH79_MACH_DIR_505_A1=y CONFIG_ATH79_MACH_DIR_600_A1=y CONFIG_ATH79_MACH_DIR_615_C1=y CONFIG_ATH79_MACH_DIR_615_I1=y CONFIG_ATH79_MACH_DIR_825_B1=y CONFIG_ATH79_MACH_DIR_825_C1=y CONFIG_ATH79_MACH_DIR_869_A1=y CONFIG_ATH79_MACH_DLAN_HOTSPOT=y CONFIG_ATH79_MACH_DLAN_PRO_500_WP=y CONFIG_ATH79_MACH_DLAN_PRO_1200_AC=y CONFIG_ATH79_MACH_DOMYWIFI_DW33D=y CONFIG_ATH79_MACH_DR344=y CONFIG_ATH79_MACH_DR531=y CONFIG_ATH79_MACH_DRAGINO2=y CONFIG_ATH79_MACH_E2100L=y CONFIG_ATH79_MACH_ESR900=y CONFIG_ATH79_MACH_EW_DORIN=y CONFIG_ATH79_MACH_EL_M150=y CONFIG_ATH79_MACH_EL_MINI=y CONFIG_ATH79_MACH_GL_AR150=y CONFIG_ATH79_MACH_GL_AR300=y CONFIG_ATH79_MACH_GL_AR300M=y CONFIG_ATH79_MACH_GL_DOMINO=y CONFIG_ATH79_MACH_GL_MIFI=y CONFIG_ATH79_MACH_GL_INET=y CONFIG_ATH79_MACH_EAP120=y CONFIG_ATH79_MACH_EAP300V2=y CONFIG_ATH79_MACH_GS_MINIBOX_V1=y CONFIG_ATH79_MACH_GS_OOLITE=y CONFIG_ATH79_MACH_HIWIFI_HC6361=y CONFIG_ATH79_MACH_JA76PF=y CONFIG_ATH79_MACH_JWAP003=y CONFIG_ATH79_MACH_JWAP230=y CONFIG_ATH79_MACH_WRT160NL=y CONFIG_ATH79_MACH_WRT400N=y CONFIG_ATH79_MACH_WRTNODE2Q=y CONFIG_ATH79_MACH_R602N=y CONFIG_ATH79_MACH_R6100
Bug#768005: xl / xen bash completion
Hi!
> Reassigning to Debian Xen team, since I that makes more sense. We
> totally missed this on our (release) radar.
>
> And indeed, we're shipping the upstream completion file now. Adi, I see
> how you're improving it, and I like it.
I'm happy you like it...
> So, we should probably ship this instead, but at the same time, the
> right (tm) place to move this is upstream. We're activetly trying to get
> rid of "adjusted copies of upstream stuff" in the packaging.
I think it would be great if you could ship that for Buster because I don't
think upstream will merge it within the next month... ;-)
> Would you mind making an upstream patch out of this? I can help with
> that if needed. Then it gets proper review, and upstream can maintain it
> when commands are added/changed etc.
Find the patch attached; it is based on upstream's repository[1]. Feel free
to submit it upstream (no need to credit me; this is just copied together
from xm and upstream's command list).
best regards,
Adi
[1] https://xenbits.xen.org/git-http/xen.git
diff --git a/tools/xl/bash-completion b/tools/xl/bash-completion
index b7cd6b3992..9d492c6be5 100644
--- a/tools/xl/bash-completion
+++ b/tools/xl/bash-completion
@@ -1,20 +1,218 @@
+# bash completion for xl -*- shell-script -*-
# Copy this file to /etc/bash_completion.d/xl.sh
+# this is the original bash completion script for xm modified for use with xl
+
+_xen_domain_names()
+{
+COMPREPLY=( $( compgen -W "$( xl list 2>/dev/null | \
+awk '!/Name|Domain-0/ { print $1 }' )" -- "$cur" ) )
+}
+
+_xen_domain_ids()
+{
+COMPREPLY=( $( compgen -W "$( xl list 2>/dev/null | \
+awk '!/Name|Domain-0/ { print $2 }' )" -- "$cur" ) )
+}
_xl()
{
- local IFS=$'\n,'
+local cur prev words cword
+_init_completion || return
- local cur opts xl
- COMPREPLY=()
- cur="${COMP_WORDS[COMP_CWORD]}"
- xl=xl
+# TODO: _split_longopt
- if [[ $COMP_CWORD == 1 ]] ; then
- opts=`${xl} help 2>/dev/null | sed '1,4d' | awk '/^ [^ ]/ {print $1}' | sed 's/$/ ,/g'` && COMPREPLY=( $(compgen -W "${opts}" -- ${cur}) )
- return 0
- fi
+local args command commands options
- return 0
-}
+# command list is taken from xen-util-common's xl.sh command completion
+commands=$(xl help 2>/dev/null | sed '1,4d' | awk '/^ [^ ]/ {print $1}' | tr '\n' ' ')
+
+if [[ $cword -eq 1 ]] ; then
+COMPREPLY=( $( compgen -W "$commands" -- "$cur" ) )
+else
+if [[ "$cur" == *=* ]]; then
+prev=${cur/=*/}
+cur=${cur/*=/}
+fi
+
+command=${words[1]}
+if [[ "$cur" == -* ]]; then
+# possible options for the command
+case $command in
+create)
+options='-c'
+;;
+dmesg)
+options='--clear'
+;;
+list)
+options='--long'
+;;
+reboot)
+options='-w -a'
+;;
+shutdown)
+options='-w -a -R -H'
+;;
+sched-credit)
+options='-d -w -c'
+;;
+block-list|network-list|vtpm-list|vnet-list)
+options='-l --long'
+;;
+getpolicy)
+options='--dumpxml'
+;;
+new)
+options='-h --help --help_config -q --quiet --path= -f=
+--defconfig= -F= --config= -b --dryrun -x --xmldryrun
+-s --skipdtd -p --paused -c --console_autoconnect'
+;;
+esac
+COMPREPLY=( $( compgen -W "$options" -- "$cur" ) )
+else
+case $command in
+console|destroy|domname|domid|list|mem-set|mem-max| \
+pause|reboot|rename|shutdown|unpause|vcpu-list|vcpu-pin| \
+vcpu-set|block-list|network-list|vtpm-list)
+_count_args
+case $args in
+2)
+_xen_domain_names
+;;
+esac
+;;
+migrate)
+_count_args
+case $args in
+2)
+_xen_domain_names
+;;
+3)
+_known_hosts_real -- "$cur"
+;;
+esac
+;;
+restore|dry-run|vnet-create)
+_filedir
+;;
+save)
+_count_args
+case $args in
+2)
+_xen_domain_names
+;;
+
Bug#768005: [Bash-completion-devel] Bug#768005: Please support xl xen management command
Tags: patch Hi! This kind of annoyed me too for a long time. xen-utils-common provides a rudimentary bash completion that completes all commands from it gets from parsing 'xl help' but none of the more advanced completions of the xm completion worked. Find attached a version of xl completion that is mainly a copy of the xm completion with the following changes: * used the command expansion from /usr/share/bash-completion/completions/xl.sh * adapted the create command to use the full path to the config file. I'd very much apprechiate if that could be added to either bash-completion or xen-utils-common... best regards, Adi Kriegisch xl.sh Description: Bourne shell script signature.asc Description: PGP signature
Bug#865830: RFP: seafile-server - An online file storage and collaboration tool
Dear Alex, thank you very much for packaging seafile server! There is a small issue with the seahub package: it should depend on python-tz. On a minimal system with 'APT::Install-Recommends "0";' and 'APT::Install-Suggests "0";' the current package leads to the following stack trace on install: | Setting up seahub (6.2.5+dfsg-1~pre+1~bpo90+1) ... | Traceback (most recent call last): | File "/usr/bin/django-admin", line 21, in | management.execute_from_command_line() | File "/usr/lib/python2.7/dist-packages/django/core/management/__init__.py", line 367, in execute_from_command_line | utility.execute() | File "/usr/lib/python2.7/dist-packages/django/core/management/__init__.py", line 341, in execute | django.setup() | File "/usr/lib/python2.7/dist-packages/django/__init__.py", line 27, in setup | apps.populate(settings.INSTALLED_APPS) | File "/usr/lib/python2.7/dist-packages/django/apps/registry.py", line 108, in populate | app_config.import_models(all_models) | File "/usr/lib/python2.7/dist-packages/django/apps/config.py", line 199, in import_models | self.models_module = import_module(models_module_name) | File "/usr/lib/python2.7/importlib/__init__.py", line 37, in import_module | __import__(name) | File "/usr/lib/python2.7/dist-packages/seahub/base/models.py", line 15, in | from seahub.utils.timeutils import datetime_to_isoformat_timestr | File "/usr/lib/python2.7/dist-packages/seahub/utils/timeutils.py", line 3, in | import pytz | ImportError: No module named pytz | dpkg: error processing package seahub (--configure): | subprocess installed post-installation script returned error exit status 1 | dpkg: dependency problems prevent configuration of seafile-server: | seafile-server depends on seahub; however: | Package seahub is not configured yet. | | dpkg: error processing package seafile-server (--configure): | dependency problems - leaving unconfigured best regards, Adi Kriegisch PS: would you consider building libccnet with mysql and postgres support? :-) signature.asc Description: PGP signature
Bug#504748: initscripts: mountall.sh must not mount ocfs2, gfs
Dear Dmitry,
> Dear submitter, my apologies. Could you please refresh patch aganist
> sysvinit=2.93-2?
find the refreshed patch attached. I noticed, ceph support was added.
I've no idea if ceph also needs its own stack available before being
mounted. For now, I've left ceph's code path unchanged.
best regards,
Adi
> [2011-08-17 17:58] Adi Kriegisch
> > part 1 text/plain 769
> > Tags: patch
> >
> > Find a patch attached that really removes ocfs2 and gfs from
> > /etc/init.d/mountnfs.sh
> > /etc/init.d/umountnfs.sh and
> > /etc/network/if-up.d/mountnfs
Index: sysvinit-2.93/debian/src/initscripts/etc/network/if-up.d/mountnfs
===
--- sysvinit-2.93.orig/debian/src/initscripts/etc/network/if-up.d/mountnfs
+++ sysvinit-2.93/debian/src/initscripts/etc/network/if-up.d/mountnfs
@@ -84,7 +84,7 @@ set_env() {
# what the options are.
start_nfs=yes
;;
- smbfs|cifs|coda|ncp|ncpfs|ocfs2|gfs|ceph)
+ smbfs|cifs|coda|ncp|ncpfs|ceph)
;;
*)
FSTYPE=
Index: sysvinit-2.93/debian/src/initscripts/etc/init.d/mountnfs.sh
===
--- sysvinit-2.93.orig/debian/src/initscripts/etc/init.d/mountnfs.sh
+++ sysvinit-2.93/debian/src/initscripts/etc/init.d/mountnfs.sh
@@ -37,7 +37,7 @@ do_wait_async_mount() {
;;
esac
case "$FSTYPE" in
- nfs|nfs4|smbfs|cifs|coda|ncp|ncpfs|ocfs2|gfs|ceph)
+ nfs|nfs4|smbfs|cifs|coda|ncp|ncpfs|ceph)
;;
*)
continue
Index: sysvinit-2.93/debian/src/initscripts/etc/init.d/umountnfs.sh
===
--- sysvinit-2.93.orig/debian/src/initscripts/etc/init.d/umountnfs.sh
+++ sysvinit-2.93/debian/src/initscripts/etc/init.d/umountnfs.sh
@@ -51,7 +51,7 @@ do_stop () {
;;
esac
case "$FSTYPE" in
- nfs|nfs4|smbfs|ncp|ncpfs|cifs|coda|ocfs2|gfs|ceph)
+ nfs|nfs4|smbfs|ncp|ncpfs|cifs|coda|ceph)
DIRS="$MTPT $DIRS"
;;
proc|procfs|linprocfs|devpts|usbfs|usbdevfs|sysfs)
@@ -60,7 +60,13 @@ do_stop () {
esac
case "$OPTS" in
_netdev|*,_netdev|_netdev,*|*,_netdev,*)
- DIRS="$MTPT $DIRS"
+ case "$FSTYPE" in
+ ocfs2|gfs)
+;;
+ *)
+DIRS="$MTPT $DIRS"
+;;
+ esac
;;
esac
done < /etc/mtab
signature.asc
Description: This is a digitally signed message part.
Bug#798283: clvmd: stack smashing detected -- solved
Hi! > Unfortunately Jessie did not have the dbgsym packages so > I cannot get any clue of the given stack. > > Was or is this still an issue for Stretch or testing? No, because openais has been removed from Stretch. Thus, closing this issue should be save. > Also it looks like this daemon got removed last month > from upstream git [1]. As I understand it, clvm will continue to live in lvm2 while lvm3(?) will use lvmlockd to replace it. I was unable to find an official announcement for that, but there is for example a recent version of the lvmlockd manpage[2] that describes lvmlockd as the newer cluster aware approach in lvm. > If it can still be observed with a more recent clvmd > package version, please submit the "stack smashing detected" > log along with the package version. I think you may just close this issue. thanks, Adi [1] https://sourceware.org/git/?p=lvm2.git;a=commit;h=3e781ea446bb7ddc9a494cbba6b6104dd51c3910 [2] http://man7.org/linux/man-pages/man8/lvmlockd.8.html signature.asc Description: PGP signature
Bug#880427: tinyproxy: If tinyproxy receives SIGHUP...
Dear maintainer, are there any plans to release an update to Stretch? The current package without the patch requires manual intervention after every logrotate invocation... -- Adi signature.asc Description: Digital signature
Bug#861419: Kernel Oops during resume after upgrade to Stretch
Hi! There seems to be a patch upstream for kernel 4.11: https://patchwork.kernel.org/patch/9479343/ (found via https://bbs.archlinux.org/viewtopic.php?id=224098) Maybe there is a chance to get this backported? -- Adi signature.asc Description: Digital signature
Bug#807044: Okular scales down A4 to A5 on printing
Hi! There seem to be several upstream issues dealing with this, eg. https://bugs.kde.org/show_bug.cgi?id=348171 Okular in its current version in Stretch (16.08.2-1+b1) cannot be used for printing. -- Adi signature.asc Description: Digital signature
Bug#844632: Drupal: SA-CORE-2016-005
Package: drupal7 Version: 7.32-1+deb8u7 Severity: grave Tags: security Hi! The Drupal Security Team publicly announced a fix for an external URL injection flaw in Drupal7: https://www.drupal.org/SA-CORE-2016-005 -- Adi signature.asc Description: Digital signature
Bug#826663: regression with gemfile-adjustments.patch
Package: redmine
Version: 3.0~20140825-8~deb8u3
Severity: important
Tags: patch
Dear maintainers,
the patch to load all database drivers for the recent update in Jessie
causes some regression when having these instances running as different
users (and thus different owners on files and directories).
Upgrade process itself runs just fine, but starting Redmine from uwsgi for
example causes an error, because the database config of the other instances
cannot be loaded:
| Tue Jun 7 16:25:54 2016 - *** Operational MODE: preforking ***
| Tue Jun 7 16:25:54 2016 - *** uWSGI is running in multiple interpreter
mode ***
| Tue Jun 7 16:25:54 2016 - spawned uWSGI master process (pid: 2678)
| Tue Jun 7 16:25:54 2016 - spawned uWSGI worker 1 (pid: 2700, cores: 1)
| Tue Jun 7 16:25:54 2016 - spawned uWSGI worker 2 (pid: 2701, cores: 1)
| Tue Jun 7 16:25:54 2016 - /usr/share/redmine/Gemfile:53:in `read':
| Permission denied @ rb_sysopen - /etc/redmine/project1/database.yml
(Errno::EACCES)
| Tue Jun 7 16:25:54 2016 - from /usr/share/redmine/Gemfile:53:in
`block in eval_gemfile'
| Tue Jun 7 16:25:54 2016 - from /usr/share/redmine/Gemfile:52:in `each'
| ...
| Tue Jun 7 16:25:55 2016 - DAMN ! worker 1 (pid: 2700) died :( trying
respawn ...
| Tue Jun 7 16:25:55 2016 - Respawned uWSGI worker 1 (new pid: 2881)
| Tue Jun 7 16:25:55 2016 - DAMN ! worker 2 (pid: 2701) died :( trying
respawn ...
| Tue Jun 7 16:25:55 2016 - Respawned uWSGI worker 2 (new pid: 2882)
The following patch fixes this while still retaining the intended behaviour
on upgrade:
| --- /usr/share/redmine/Gemfile.orig 2016-06-07 16:54:13.609621700 +0200
| +++ /usr/share/redmine/Gemfile 2016-06-07 16:53:24.393621700 +0200
| @@ -50,7 +50,8 @@
| Dir['{config,/etc/redmine/*}/database.yml'].select do |f|
|File.exists?(f)
| end.each do |database_file|
| - database_config = YAML::load(ERB.new(IO.read(database_file)).result)
| + database_config = YAML::load(ERB.new(IO.read(database_file)).result) \
| +rescue YAML::load("production:\n adapter: none")
|adapters = database_config.values.map {|c| c['adapter']}.compact.uniq
|if adapters.any?
| adapters.each do |adapter|
In case of an unreadable file, a faked YAML with no database adapter is
foisted by 'rescue'; thus startup isn't interrupted by an unreadable file.
Thanks for providing Redmine in Debian and thanks for providing
multi-instance support!! :)
-- Adi
PS: here is an example uwsgi config for running redmine (just in case you
need it for reproducing the issue). To run it that way, you need to
create an account named 'redmine' (see uid/gid) and install
uwsgi and uwsgi-plugin-rack-ruby2.1.
| uwsgi:
| plugins: rack
| rack: config.ru
| env: RAILS_ENV=production
| env: X_DEBIAN_SITEID=default
| chdir: /usr/share/redmine/
| uid: redmine
| gid: redmine
|
| # parameters that depend on the redmine instance
| pid: /var/run/uwsgi/app/redmine-default/pid
| log: /var/log/redmine/default/production.log
|
| master: true
| lazy-apps: true
| memory-report: 1
| reload-on-rss: 256
| post-buffering: 4096
| #default socket is /run/uwsgi/app/redmine-default/socket
| chown-socket: www-data
--- /usr/share/redmine/Gemfile.orig 2016-06-07 16:54:13.609621700 +0200
+++ /usr/share/redmine/Gemfile 2016-06-07 16:53:24.393621700 +0200
@@ -50,7 +50,8 @@
Dir['{config,/etc/redmine/*}/database.yml'].select do |f|
File.exists?(f)
end.each do |database_file|
- database_config = YAML::load(ERB.new(IO.read(database_file)).result)
+ database_config = YAML::load(ERB.new(IO.read(database_file)).result) \
+rescue YAML::load("production:\n adapter: none")
adapters = database_config.values.map {|c| c['adapter']}.compact.uniq
if adapters.any?
adapters.each do |adapter|
signature.asc
Description: Digital signature
Bug#824177: Segfault in (clustered) Samba
Package: samba Version: 2:4.2.10+dfsg-0+deb8u2 Severity: important Tags: patch,upstream,fixed-upstream Dear maintainers, after upgrading out clustered samba to samba 4.2.10 (thanks for that btw, it solved quite a few headaches of mine!) we started to exprience weird panics in samba that looked like this: BACKTRACE: 25 stack frames: #0 /usr/lib/x86_64-linux-gnu/libsmbconf.so.0(log_stack_trace+0x1a) [0x7f8fead79f5a] #1 /usr/lib/x86_64-linux-gnu/libsmbconf.so.0(smb_panic_s3+0x20) [0x7f8fead7a040] #2 /usr/lib/x86_64-linux-gnu/libsamba-util.so.0(smb_panic+0x2f) [0x7f8feca33e5f] #3 /usr/lib/x86_64-linux-gnu/samba/libsmbd-base.so.0(update_num_read_oplocks+0x101) [0x7f8fec638881] #4 /usr/lib/x86_64-linux-gnu/samba/libsmbd-base.so.0(+0x1082dd) [0x7f8fec5e52dd] #5 /usr/lib/x86_64-linux-gnu/samba/libsmbd-base.so.0(+0x10a2b1) [0x7f8fec5e72b1] #6 /usr/lib/x86_64-linux-gnu/samba/libsmbd-base.so.0(create_file_default+0x19c) [0x7f8fec5e86ac] #7 /usr/lib/x86_64-linux-gnu/samba/libsmbd-base.so.0(+0x1de8d9) [0x7f8fec6bb8d9] #8 /usr/lib/x86_64-linux-gnu/samba/libsmbd-base.so.0(smb_vfs_call_create_file+0x77) [0x7f8fec5eef87] #9 /usr/lib/x86_64-linux-gnu/samba/libsmbd-base.so.0(smbd_smb2_request_process_create+0xdd8) [0x7f8fec61bdf8] #10 /usr/lib/x86_64-linux-gnu/samba/libsmbd-base.so.0(smbd_smb2_request_dispatch+0x9be) [0x7f8fec614fce] #11 /usr/lib/x86_64-linux-gnu/samba/libsmbd-base.so.0(+0x138be8) [0x7f8fec615be8] #12 /usr/lib/x86_64-linux-gnu/libsmbconf.so.0(run_events_poll+0x171) [0x7f8fead99a01] #13 /usr/lib/x86_64-linux-gnu/libsmbconf.so.0(+0x49c77) [0x7f8fead99c77] #14 /usr/lib/x86_64-linux-gnu/libtevent.so.0(_tevent_loop_once+0x8d) [0x7f8fe979c12d] #15 /usr/lib/x86_64-linux-gnu/libtevent.so.0(tevent_common_loop_wait+0x1b) [0x7f8fe979c2cb] #16 /usr/lib/x86_64-linux-gnu/samba/libsmbd-base.so.0(smbd_process+0x718) [0x7f8fec6044a8] #17 /usr/sbin/smbd(+0xadd0) [0x7f8fed090dd0] #18 /usr/lib/x86_64-linux-gnu/libsmbconf.so.0(run_events_poll+0x171) [0x7f8fead99a01] #19 /usr/lib/x86_64-linux-gnu/libsmbconf.so.0(+0x49c77) [0x7f8fead99c77] #20 /usr/lib/x86_64-linux-gnu/libtevent.so.0(_tevent_loop_once+0x8d) [0x7f8fe979c12d] #21 /usr/lib/x86_64-linux-gnu/libtevent.so.0(tevent_common_loop_wait+0x1b) [0x7f8fe979c2cb] #22 /usr/sbin/smbd(main+0x17e5) [0x7f8fed08d5e5] #23 /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5) [0x7f8fe940eb45] #24 /usr/sbin/smbd(+0x76e4) [0x7f8fed08d6e4] There also is an upstream bug[1] dealing with a slightly different issue that contains a fix[2] for this bug. After recompiling the debian version of samba with this patch applied, the issue has gone. Would be great to get that fix into Jessie: it is kind of a regression caused by the major update of ctdb and the tdb libs. -- Adi [1] https://bugzilla.samba.org/show_bug.cgi?id=11844 [2] https://attachments.samba.org/attachment.cgi?id=12042 signature.asc Description: Digital signature
Bug#816730: UnicodeEncodeError: 'ascii' codec can't encode character u'\\xc4' in German MoinMoin wiki
Hi! Thanks for providing a patch/workaround for the issue; I also found an upstream bug report with some suggestions: https://moinmo.in/MoinMoinBugs/1.9.8NonAsciiURL-UnicodeEncodeError I think the main issue is that sys.getfilesystemencoding() returns 'utf-8' in interactive use while it does not when running inside apache. Neither setting a default encoding nor providing a WSGIDaemonProcess config as suggested upstream changed that for me. -- Adi signature.asc Description: Digital signature
Bug#801690: [Pkg-samba-maint] Bug#801690: 'smbstatus -b' leads to broken ctdb cluster
Hi! > I'm not able to reproduce the bug under current sid. Even fixed with recent update in Jessie! :-) YEAH! Thanks for your support! > As ctdb in jessie was in another repository than samba, I suspect an > API incompatibility. Actually I am not quite sure if that really is an API incompatibility; from what I found out, the issue would have been fixed with an update to ctdb 2.5.6 which includes a lot of fixes in general. For the records: when trying to run ctdb with gdb, the issue did not occur -- but ctdb was painfully slow. Next I tried to read the messages on the socket, like this: | mv /var/run/ctdb/ctdbd.socket /var/run/ctdb/ctdbd.socket-orig | socat -t100 -x -v \ |UNIX-LISTEN:/var/run/ctdb/ctdbd.socket,mode=777,reuseaddr,fork \ |UNIX-CONNECT:/var/run/ctdb/ctdbd.socket-orig | mv /var/run/ctdb/ctdbd.socket-orig /var/run/ctdb/ctdbd.socket That just slowed down ctdb a little, but everything worked like a charm. So I suspect some kind of race condition to be the root cause of the issue. > I'm tempted to mark this as fixed under sid, but can you setup a sid > box and test yourself with a similar config? You may even mark this as fixed in jessie with version 4.2.10+... Thank you very much for your help! -- Adi signature.asc Description: Digital signature
Bug#813406: [Pkg-samba-maint] Bug#813406: ctdb, raw sockets and CVE-2015-8543
Hi! > There are two set of patches: > - yours that basically keep the same behavior as pre-CVE-2015-8543 (proto=0) I just desperately tried to get my cluster going again... ;-) > - Amitay's that restore the intented behavior (proto=255) [...] > I think I'll got for Amitay's patch which probably fixes a lot of > weird behaviors I've seen pre-CVE-2015-8543 (i.e TCP connections not > reset, Ip not properly relocated). This is -- of course -- the way better approach! > I plan to fix this for wheezy and jessie. stretch will come with next > upstream release. > > Givent the importance of the bug, I think it can go thru -security. I think so too -- especially as it is some kind of regression. Thank you very much for taking care of this! -- Adi signature.asc Description: Digital signature
Bug#813406: ctdb, raw sockets and CVE-2015-8543
Package: ctdb
Severity: grave
Tags: patch,upstream
Hi!
The kernel upgrade for CVE-2015-8543 showed a bug in CTDB that leads to a
broken cluster:
| s = socket(AF_INET, SOCK_RAW, htons(IPPROTO_RAW));
htons(IPPROTO_RAW) leads to 0xff00 which causes "-1 EINVAL (Invalid
argument)" because of CVE-2015-8543.
The fix for the issue is quite simple: remove IPPROTO_RAW; to make the fix
more consistent with what was used before, use IPPROTO_IP (which is 0).
Error messages related to this bug are:
| We are still serving a public IP 'x.x.x.x' that we should not be serving.
Removing it
| common/system_common.c:89 failed to open raw socket (Invalid argument)
| Could not find which interface the ip address is hosted on. can not release
it
and
| common/system_linux.c:344 failed to open raw socket (Invalid argument)
As a result, IP addresses cannot be released and multiple nodes in the
cluster serve the same address, which obviously does not work.
Upstream bug: https://bugzilla.samba.org/show_bug.cgi?id=11705 and mailing
list conversation:
https://lists.samba.org/archive/samba/2016-January/197389.html
-- Adi
--- a/common/system_common.c2016-01-19 15:20:37.437683526 +0100
+++ b/common/system_common.c2016-01-19 15:20:50.417683526 +0100
@@ -83,7 +83,7 @@
struct ifconf ifc;
char *ptr;
- s = socket(AF_INET, SOCK_RAW, htons(IPPROTO_RAW));
+ s = socket(AF_INET, SOCK_RAW, IPPROTO_IP);
if (s == -1) {
DEBUG(DEBUG_CRIT,(__location__ " failed to open raw socket (%s)\n",
strerror(errno)));
--- a/common/system_linux.c 2016-01-19 16:06:53.021491231 +0100
+++ b/common/system_linux.c 2016-01-19 16:07:05.817491231 +0100
@@ -338,7 +338,7 @@
ip4pkt.tcp.check= tcp_checksum((uint16_t *), sizeof(ip4pkt.tcp), );
/* open a raw socket to send this segment from */
- s = socket(AF_INET, SOCK_RAW, htons(IPPROTO_RAW));
+ s = socket(AF_INET, SOCK_RAW, IPPROTO_IP);
if (s == -1) {
DEBUG(DEBUG_CRIT,(__location__ " failed to open raw socket (%s)\n",
strerror(errno)));
signature.asc
Description: Digital signature
Bug#801690: [Pkg-samba-maint] Bug#801690: 'smbstatus -b' leads to broken ctdb cluster
Hi! Thanks for getting back to me! :) > > I recently upgraded a samba cluster from Wheezy (with Kernel, ctdb, samba > > and glusterfs from backports) to Jessie. The cluster itself is way older > > and basically always worked. Since the upgrade to Jessie 'smbstatus -b' > > (almost always) just hangs the whole cluster; I need to interrupt the call > > with ctrl+c (or run with 'timeout 2') to avoid a complete cluster lockup > > leading to the other cluster nodes being banned and the node I run smbstatus > > on to have ctdbd run at 100% load but not being able to recover. > > How do you recover then? KILL-ing ctdbd? Killing the loaded node is the easiest; manual unbanning of the other nodes is still required. Combinations of enabling and disabling nodes may fix the situation too. > > Calling 'smbstatus --locks' and 'smbstatus --shares' works just fine. > > Have you tried which of --processes, --notify hangs? Does it hangs > with "-b --fast"? Ah, I missed that: '--brief --fast' works just fine. So obviously the validation does not work... > > 'strace'ing ctdbd leads to a massive amount of these messages: > > | > > write(58,"\240\4\0\0BDTC\1\0\0\0\215U\336\25\5\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., > > | 1184) = -1 EAGAIN (Resource temporarily > > unavailable) > > fd 58 is probably the ctdb socket. Can you confirm? Right. > To have more usefull info, can you install gdb, ctdb-dbg and samba-dbg > and send the stacktrace of ctdbd at the write? Ok, I will report back the stack traces in a few days (I'm afraid I can only do these during the weekend). All the best, Adi signature.asc Description: Digital signature
Bug#801690: vs. Bug#801609
Hi! You're submitting this discussion to bug #801690[1] which is a completely different bug. Although I'd be glad if you could help me fixing that issue, I think you should rather CC bug #801609[2]... all the best, Adi [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=801690 [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=801609 signature.asc Description: Digital signature
Bug#802635: samba: Can't delete files
Hi! I actually don't think this will happen: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=688059 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=704761 -- Adi signature.asc Description: Digital signature
Bug#798283: clvmd: stack smashing detected -- solved
Hi! Do you have any plans to fix that bug for Jessie? If so, within what timeframe? -- Adi signature.asc Description: Digital signature
Bug#801690: 'smbstatus -b' leads to broken ctdb cluster
Package: ctdb Version: 2.5.4+debian0-4 Dear maintainers, I recently upgraded a samba cluster from Wheezy (with Kernel, ctdb, samba and glusterfs from backports) to Jessie. The cluster itself is way older and basically always worked. Since the upgrade to Jessie 'smbstatus -b' (almost always) just hangs the whole cluster; I need to interrupt the call with ctrl+c (or run with 'timeout 2') to avoid a complete cluster lockup leading to the other cluster nodes being banned and the node I run smbstatus on to have ctdbd run at 100% load but not being able to recover. The cluster itself consists of three nodes sharing three cluster ips. The only service ctdb manages is Samba. The lock file is located on a mirrored glusterfs volume. running and interrupting the hanging smbstatus leads to the following log messages in /var/log/ctdb/log.ctdb: | 2015/10/13 15:09:24.923002 [19378]: Starting traverse on DB | smbXsrv_session_global.tdb (id 2592646) | 2015/10/13 15:09:25.505302 [19378]: server/ctdb_traverse.c:644 Traverse | cancelled by client disconnect for database:0x6b06a26d | 2015/10/13 15:09:25.505492 [19378]: Could not find idr:2592646 | [...] | 2015/10/13 15:09:25.507553 [19378]: Could not find idr:2592646 'ctdb getdbmap' lists that database, but also lists a second entry for smbXsrv_session_global.tdb: | dbid:0x521b7544 name:smbXsrv_version_global.tdb path:/var/lib/ctdb/smbXsrv_version_global.tdb.0 | dbid:0x6b06a26d name:smbXsrv_session_global.tdb path:/var/lib/ctdb/smbXsrv_session_global.tdb.0 (I have no idea if that has always been the case or if that happened after the upgrade). Calling 'smbstatus --locks' and 'smbstatus --shares' works just fine. 'strace'ing ctdbd leads to a massive amount of these messages: | write(58,"\240\4\0\0BDTC\1\0\0\0\215U\336\25\5\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., | 1184) = -1 EAGAIN (Resource temporarily unavailable) Running 'ctdb_diagnostics' is only possible shortly after the cluster is started (ie. while smbstatus -b works) and yields the following messages: | ERROR[1]: /etc/krb5.conf is missing on node 0 | ERROR[2]: File /etc/hosts is different on node 1 | ERROR[3]: File /etc/hosts is different on node 2 | ERROR[4]: File /etc/samba/smb.conf is different on node 1 | ERROR[5]: File /etc/samba/smb.conf is different on node 2 | ERROR[6]: File /etc/fstab is different on node 1 | ERROR[7]: File /etc/fstab is different on node 2 | ERROR[8]: /etc/multipath.conf is missing on node 0 | ERROR[9]: /etc/pam.d/system-auth is missing on node 0 | ERROR[10]: /etc/default/nfs is missing on node 0 | ERROR[11]: /etc/exports is missing on node 0 | ERROR[12]: /etc/vsftpd/vsftpd.conf is missing on node 0 | ERROR[13]: Optional file /etc/ctdb/static-routes is not present on node 0 '/etc/hosts' differs in some newlines and comments while 'smb.conf' only has some different log levels on the nodes. The rest of the messages does not affect ctdb as it only manages samba. Feel free to ask if you need any more information. -- Adi signature.asc Description: Digital signature
Bug#798283: clvmd: stack smashing detected -- solved
Tags: patch
Severity: important
Hey!
I finally found the source of the problem: During cluster initialization an
int is casted to a uint64_t which triggered the stack protection in gcc-4.9:
| int select_fd;
| (...)
| saLckSelectionObjectGet(lck_handle, (SaSelectionObjectT *)_fd);
I fixed the issue by declaring select_fd as uint64_t, as SaSelectionObjectT
defined in /usr/include/openais/saAis.h is:
| typedef uint64_t SaUint64T;
| typedef SaUint64T SaSelectionObjectT;
To make the issue more explicit I casted it back to an int. Patch is
attached.
-- Adi
PS: What I do not understand is why gcc-4.9 does not raise this issue at
compile time: all type information is already there...
--- a/daemons/clvmd/clvmd-openais.c 2015-09-09 08:15:24.036478491 +
+++ b/daemons/clvmd/clvmd-openais.c 2015-09-09 08:15:56.609011149 +
@@ -309,7 +309,7 @@
{
SaAisErrorT err;
SaVersionT ver = { 'B', 1, 1 };
- int select_fd;
+ uint64_t select_fd;
node_hash = dm_hash_create(100);
lock_hash = dm_hash_create(10);
@@ -357,7 +357,7 @@
DEBUGLOG("Our local node id is %d\n", our_nodeid);
saLckSelectionObjectGet(lck_handle, (SaSelectionObjectT *)_fd);
- add_internal_client(select_fd, lck_dispatch);
+ add_internal_client((int)select_fd, lck_dispatch);
DEBUGLOG("Connected to OpenAIS\n");
signature.asc
Description: Digital signature
Bug#798283: clvmd: stack smashing detected
Package: clvm Version: 2.02.111-2.2 Severity: normal Hi! After upgrading one of my machines from wheezy to jessie, clvmd did not start with the following error: | *** stack smashing detected ***: clvmd terminated (also see attached log). The cluster stack in use is OpenAIS (which worked fine, even after the upgrade). In an attempt to bisect the issue, I first started to use the old binary from wheezy (v2.02.95) which instantly worked, then tried to build the sources (v2.02.100, v2.02.105, v2.02.110 and v2.02.111) on a wheezy machine (sorry, I have no devel box with jessie available atm). Interesting enough, all binaries built on wheezy work; just the one from the package does not (with said error message). The builds were done using dpkg-buildpackage with the upstream debian directory. The binary built and stripped on wheezy is slightly smaller in size: | -rwxr-xr-x 1 root root 912832 Sep 7 18:27 /usr/sbin/clvmd-v111-self vs | -rwxr-xr-x 1 root root 937792 Sep 7 18:22 /usr/sbin/clvmd-v111-deb Inspecting the binaries with ldd showed that the version built on wheezy is linked against libudev.so.0 too (not just libudev.so.1 as the jessie version is): | libudev.so.0 => /lib/x86_64-linux-gnu/libudev.so.0 (0x7f1955441000) I'd be happy to help in ironing out that bug. Do you need any more information? Are there any tests I should run? -- Adi root@host:~# clvmd -T20 -Iopenais -f -d1 local socket: connect failed: No such file or directory CLVMD[5b171800]: Sep 7 18:34:27 CLVMD started CLVMD[5b171800]: Sep 7 18:34:27 Our local node id is 60 CLVMD[5b171800]: Sep 7 18:34:27 Add_internal_client, fd = 8 CLVMD[5b171800]: Sep 7 18:34:27 Connected to OpenAIS *** stack smashing detected ***: clvmd terminated === Backtrace: = /lib/x86_64-linux-gnu/libc.so.6(+0x731ff)[0x7fb7592a11ff] /lib/x86_64-linux-gnu/libc.so.6(__fortify_fail+0x37)[0x7fb7593244c7] /lib/x86_64-linux-gnu/libc.so.6(__fortify_fail+0x0)[0x7fb759324490] clvmd(+0x16482)[0x7fb75aebb482] clvmd(+0xe8fb)[0x7fb75aeb38fb] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0x7fb75924fb45] clvmd(+0xee00)[0x7fb75aeb3e00] === Memory map: 7fb758277000-7fb75828d000 r-xp fd:00 655438 /lib/x86_64-linux-gnu/libgcc_s.so.1 7fb75828d000-7fb75848c000 ---p 00016000 fd:00 655438 /lib/x86_64-linux-gnu/libgcc_s.so.1 7fb75848c000-7fb75848d000 rw-p 00015000 fd:00 655438 /lib/x86_64-linux-gnu/libgcc_s.so.1 7fb75848d000-7fb75858d000 rw-s 00:12 53705 /run/shm/dispatch_buffer-tLzRBo (deleted) 7fb75858d000-7fb75868d000 rw-s 00:12 53705 /run/shm/dispatch_buffer-tLzRBo (deleted) 7fb75868d000-7fb75878d000 rw-s 00:12 53704 /run/shm/response_buffer-NNnWgi (deleted) 7fb75878d000-7fb75888d000 rw-s 00:12 53700 /run/shm/dispatch_buffer-qisWgZ (deleted) 7fb75888d000-7fb75898d000 rw-s 00:12 53700 /run/shm/dispatch_buffer-qisWgZ (deleted) 7fb75898d000-7fb7589f9000 r-xp fd:00 655368 /lib/x86_64-linux-gnu/libpcre.so.3.13.1 7fb7589f9000-7fb758bf9000 ---p 0006c000 fd:00 655368 /lib/x86_64-linux-gnu/libpcre.so.3.13.1 7fb758bf9000-7fb758bfa000 r--p 0006c000 fd:00 655368 /lib/x86_64-linux-gnu/libpcre.so.3.13.1 7fb758bfa000-7fb758bfb000 rw-p 0006d000 fd:00 655368 /lib/x86_64-linux-gnu/libpcre.so.3.13.1 7fb758bfb000-7fb758c0 r-xp fd:00 790269 /usr/lib/libcoroipcc.so.4.0.0 7fb758c0-7fb758dff000 ---p 5000 fd:00 790269 /usr/lib/libcoroipcc.so.4.0.0 7fb758dff000-7fb758e0 r--p 4000 fd:00 790269 /usr/lib/libcoroipcc.so.4.0.0 7fb758e0-7fb758e01000 rw-p 5000 fd:00 790269 /usr/lib/libcoroipcc.so.4.0.0 7fb758e01000-7fb758e22000 r-xp fd:00 655442 /lib/x86_64-linux-gnu/libselinux.so.1 7fb758e22000-7fb759022000 ---p 00021000 fd:00 655442 /lib/x86_64-linux-gnu/libselinux.so.1 7fb759022000-7fb759023000 r--p 00021000 fd:00 655442 /lib/x86_64-linux-gnu/libselinux.so.1 7fb759023000-7fb759024000 rw-p 00022000 fd:00 655442 /lib/x86_64-linux-gnu/libselinux.so.1 7fb759024000-7fb759026000 rw-p 00:00 0 7fb759026000-7fb75902d000 r-xp fd:00 655909 /lib/x86_64-linux-gnu/librt-2.19.so 7fb75902d000-7fb75922c000 ---p 7000 fd:00 655909 /lib/x86_64-linux-gnu/librt-2.19.so 7fb75922c000-7fb75922d000 r--p 6000 fd:00 655909 /lib/x86_64-linux-gnu/librt-2.19.so 7fb75922d000-7fb75922e000 rw-p 7000 fd:00 655909 /lib/x86_64-linux-gnu/librt-2.19.so 7fb75922e000-7fb7593cd000 r-xp fd:00 655937 /lib/x86_64-linux-gnu/libc-2.19.so
Bug#796243: SA-CORE-2015-003 -- please also fix for backports...
Package: drupal7
Version: 7.32-1+deb8u3~bpo70+1
Tags: patch,security
Severity: grave
Hi!
As SA-CORE-2015-003[1] is already public, I extracted the patch (diff
between 7.38 and 7.39 plus removed the version bumps).
It would be great if you could upload to wheezy-backports too
(SA-CORE-2015-002 is missing for this version too, afaik)...
Thanks!
-- Adi
[1] https://www.drupal.org/SA-CORE-2015-003
diff -Nru drupal-7.38/includes/ajax.inc drupal-7.39/includes/ajax.inc
--- drupal-7.38/includes/ajax.inc 2015-06-17 20:38:44.0 +0200
+++ drupal-7.39/includes/ajax.inc 2015-08-19 23:20:31.0 +0200
@@ -230,6 +230,10 @@
* functions.
*/
function ajax_render($commands = array()) {
+ // Although ajax_deliver() does this, some contributed and custom modules
+ // render Ajax responses without using that delivery callback.
+ ajax_set_verification_header();
+
// Ajax responses aren't rendered with html.tpl.php, so we have to call
// drupal_get_css() and drupal_get_js() here, in order to have new files added
// during this request to be loaded by the page. We only want to send back
@@ -487,6 +491,9 @@
}
}
+ // Let ajax.js know that this response is safe to process.
+ ajax_set_verification_header();
+
// Print the response.
$commands = ajax_prepare_response($page_callback_result);
$json = ajax_render($commands);
@@ -577,6 +584,29 @@
}
/**
+ * Sets a response header for ajax.js to trust the response body.
+ *
+ * It is not safe to invoke Ajax commands within user-uploaded files, so this
+ * header protects against those being invoked.
+ *
+ * @see Drupal.ajax.options.success()
+ */
+function ajax_set_verification_header() {
+ $added = drupal_static(__FUNCTION__);
+
+ // User-uploaded files cannot set any response headers, so a custom header is
+ // used to indicate to ajax.js that this response is safe. Note that most
+ // Ajax requests bound using the Form API will be protected by having the URL
+ // flagged as trusted in Drupal.settings, so this header is used only for
+ // things like custom markup that gets Ajax behaviors attached.
+ if (empty($added)) {
+drupal_add_http_header('X-Drupal-Ajax-Token', '1');
+// Avoid sending the header twice.
+$added = TRUE;
+ }
+}
+
+/**
* Performs end-of-Ajax-request tasks.
*
* This function is the equivalent of drupal_page_footer(), but for Ajax
@@ -764,7 +794,12 @@
$element['#attached']['js'][] = array(
'type' = 'setting',
- 'data' = array('ajax' = array($element['#id'] = $settings)),
+ 'data' = array(
+'ajax' = array($element['#id'] = $settings),
+'urlIsAjaxTrusted' = array(
+ $settings['url'] = TRUE,
+),
+ ),
);
// Indicate that Ajax processing was successful.
diff -Nru drupal-7.38/includes/database/database.inc drupal-7.39/includes/database/database.inc
--- drupal-7.38/includes/database/database.inc 2015-06-17 20:38:44.0 +0200
+++ drupal-7.39/includes/database/database.inc 2015-08-19 23:20:31.0 +0200
@@ -626,7 +626,7 @@
* A sanitized version of the query comment string.
*/
protected function filterComment($comment = '') {
-return preg_replace('/(\/\*\s*)|(\s*\*\/)/', '', $comment);
+return strtr($comment, array('*' = ' * '));
}
/**
diff -Nru drupal-7.38/includes/form.inc drupal-7.39/includes/form.inc
--- drupal-7.38/includes/form.inc 2015-06-17 20:38:44.0 +0200
+++ drupal-7.39/includes/form.inc 2015-08-19 23:20:31.0 +0200
@@ -1128,6 +1128,17 @@
drupal_alter($hooks, $form, $form_state, $form_id);
}
+/**
+ * Helper function to call form_set_error() if there is a token error.
+ */
+function _drupal_invalid_token_set_form_error() {
+ $path = current_path();
+ $query = drupal_get_query_parameters();
+ $url = url($path, array('query' = $query));
+
+ // Setting this error will cause the form to fail validation.
+ form_set_error('form_token', t('The form has become outdated. Copy any unsaved work in the form below and then a href=@linkreload this page/a.', array('@link' = $url)));
+}
/**
* Validates user-submitted form data in the $form_state array.
@@ -1162,16 +1173,11 @@
}
// If the session token was set by drupal_prepare_form(), ensure that it
- // matches the current user's session.
+ // matches the current user's session. This is duplicate to code in
+ // form_builder() but left to protect any custom form handling code.
if (isset($form['#token'])) {
-if (!drupal_valid_token($form_state['values']['form_token'], $form['#token'])) {
- $path = current_path();
- $query = drupal_get_query_parameters();
- $url = url($path, array('query' = $query));
-
- // Setting this error will cause the form to fail validation.
- form_set_error('form_token', t('The form has become outdated. Copy any unsaved work in the form below and then a href=@linkreload this page/a.', array('@link' = $url)));
-
+if
Bug#789165: SA-CORE-2015-002 -- please also fix for backports...
Package: drupal7
Version: 7.32-1+deb8u3~bpo70+1
Tags: patch,security
Severity: grave
Hi!
As SA-CORE-2015-002[1] is already public, I extracted the patch (diff
between 7.37 and 7.38 plus removed the version bumps).
It would be great if you could upload to wheezy-backports too...
Thanks!
-- Adi
[1] https://www.drupal.org/SA-CORE-2015-002
diff -Nru drupal-7.37/includes/common.inc drupal-7.38/includes/common.inc
--- drupal-7.37/includes/common.inc 2015-05-07 06:13:18.0 +0200
+++ drupal-7.38/includes/common.inc 2015-06-17 20:38:44.0 +0200
@@ -6329,13 +6329,21 @@
}
if (!empty($granularity)) {
+$cache_per_role = $granularity DRUPAL_CACHE_PER_ROLE;
+$cache_per_user = $granularity DRUPAL_CACHE_PER_USER;
+// User 1 has special permissions outside of the role system, so when
+// caching per role is requested, it should cache per user instead.
+if ($user-uid == 1 $cache_per_role) {
+ $cache_per_user = TRUE;
+ $cache_per_role = FALSE;
+}
// 'PER_ROLE' and 'PER_USER' are mutually exclusive. 'PER_USER' can be a
// resource drag for sites with many users, so when a module is being
// equivocal, we favor the less expensive 'PER_ROLE' pattern.
-if ($granularity DRUPAL_CACHE_PER_ROLE) {
+if ($cache_per_role) {
$cid_parts[] = 'r.' . implode(',', array_keys($user-roles));
}
-elseif ($granularity DRUPAL_CACHE_PER_USER) {
+elseif ($cache_per_user) {
$cid_parts[] = u.$user-uid;
}
diff -Nru drupal-7.37/modules/field_ui/field_ui.admin.inc drupal-7.38/modules/field_ui/field_ui.admin.inc
--- drupal-7.37/modules/field_ui/field_ui.admin.inc 2015-05-07 06:13:18.0 +0200
+++ drupal-7.38/modules/field_ui/field_ui.admin.inc 2015-06-17 20:38:44.0 +0200
@@ -2105,6 +2105,10 @@
$destinations = !empty($_REQUEST['destinations']) ? $_REQUEST['destinations'] : array();
if (!empty($destinations)) {
unset($_REQUEST['destinations']);
+ }
+ // Remove any external URLs.
+ $destinations = array_diff($destinations, array_filter($destinations, 'url_is_external'));
+ if ($destinations) {
return field_ui_get_destinations($destinations);
}
$admin_path = _field_ui_bundle_admin_path($entity_type, $bundle);
diff -Nru drupal-7.37/modules/field_ui/field_ui.test drupal-7.38/modules/field_ui/field_ui.test
--- drupal-7.37/modules/field_ui/field_ui.test 2015-05-07 06:13:18.0 +0200
+++ drupal-7.38/modules/field_ui/field_ui.test 2015-06-17 20:38:44.0 +0200
@@ -445,6 +445,19 @@
$this-assertText(t('The machine-readable name is already in use. It must be unique.'));
$this-assertUrl($url, array(), 'Stayed on the same page.');
}
+
+ /**
+ * Tests that external URLs in the 'destinations' query parameter are blocked.
+ */
+ function testExternalDestinations() {
+$path = 'admin/structure/types/manage/article/fields/field_tags/field-settings';
+$options = array(
+ 'query' = array('destinations' = array('http://example.com')),
+);
+$this-drupalPost($path, NULL, t('Save field settings'), $options);
+
+$this-assertUrl('admin/structure/types/manage/article/fields', array(), 'Stayed on the same site.');
+ }
}
/**
diff -Nru drupal-7.37/modules/openid/openid.module drupal-7.38/modules/openid/openid.module
--- drupal-7.37/modules/openid/openid.module 2015-05-07 06:13:18.0 +0200
+++ drupal-7.38/modules/openid/openid.module 2015-06-17 20:38:44.0 +0200
@@ -365,14 +365,20 @@
// to the OpenID Provider, we need to do discovery on the returned
// identififer to make sure that the provider is authorized to
// respond on behalf of this.
-if ($response_claimed_id != $claimed_id) {
+if ($response_claimed_id != $claimed_id || $response_claimed_id != $response['openid.identity']) {
$discovery = openid_discovery($response['openid.claimed_id']);
+ $uris = array();
if ($discovery !empty($discovery['services'])) {
-$uris = array();
foreach ($discovery['services'] as $discovered_service) {
- if (in_array('http://specs.openid.net/auth/2.0/server', $discovered_service['types']) || in_array('http://specs.openid.net/auth/2.0/signon', $discovered_service['types'])) {
-$uris[] = $discovered_service['uri'];
+ if (!in_array('http://specs.openid.net/auth/2.0/server', $discovered_service['types']) !in_array('http://specs.openid.net/auth/2.0/signon', $discovered_service['types'])) {
+continue;
}
+ // The OP-Local Identifier (if different than the Claimed
+ // Identifier) must be present in the XRDS document.
+ if ($response_claimed_id != $response['openid.identity'] (!isset($discovered_service['identity']) || $discovered_service['identity'] != $response['openid.identity'])) {
+
Bug#779834: redmine with redmine_dmsf yields a locale error
Hi! [...] The interesting part here is that somehow /usr/lib/ruby/vendor_ruby/../locales/en.yml gets added to the list of translations to load; this path, of course, does not exist and the loading fails. [...] /usr/lib/ruby/vendor_ruby/../locales/en.yml, [...] Can you look for the guilty package in your system? I think this command should find something: $ grep -rl /__FILE__.*\.\.\/locales/ /usr/lib/ruby/vendor_ruby/ Thank you for helping me out! simple_enum (the legacy-1.x branch[1]) is the culprit: | # setup i18n load path... | I18n.load_path File.join(File.dirname(__FILE__), '..', 'locales', 'en.yml') Please close that bug report; I'll file a bug for simple_enum... Thanks and sorry for the noise! -- Adi [1] https://github.com/lwe/simple_enum/blob/legacy-1.x/lib/simple_enum.rb signature.asc Description: Digital signature
Bug#761360: possible fix.
Hey! I had a similar issue on a fresh setup with NVidia drivers from backports. After resume fonts disappeared and graphic/rendering was 'unstable'. I added 'NVreg_RegisterForACPIEvents=1' to the NVidia kernel modules' options and all the issues were gone. Maybe this helps? In /etc/modprobe.d/nvidia-kernel-common.conf: - options nvidia NVreg_DeviceFileUID=0 NVreg_DeviceFileGID=44 NVreg_DeviceFileMode=0660 + options nvidia NVreg_DeviceFileUID=0 NVreg_DeviceFileGID=44 NVreg_DeviceFileMode=0660 NVreg_RegisterForACPIEvents=1 NVreg_EnableMSI=1 -- Adi signature.asc Description: Digital signature
Bug#780404: icedove/ppc: jemallocCompile-time page size does not divide the runtime one.
Package: icedove Version: 31.5.0-1 Hi! (I am very sorry, I missed reporting this issue earlier as I did for iceweasel in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=763900) When starting icedove on Jessie on an iMac G5, I get the following message: | jemallocCompile-time page size does not divide the runtime one. | Segmentation fault This can be fixed with the following patch: --- a/mozilla/memory/mozjemalloc/jemalloc.c 2014-08-25 15:17:22.0 +0200 +++ b/mozilla/memory/mozjemalloc/jemalloc.c 2014-10-03 11:30:51.183346370 +0200 @@ -1088,7 +1088,7 @@ * controlling the malloc behavior are defined as compile-time constants * for best performance and cannot be altered at runtime. */ -#if !defined(__ia64__) !defined(__sparc__) !defined(__mips__) +#if !defined(__ia64__) !defined(__sparc__) !defined(__mips__) !defined(__powerpc__) #define MALLOC_STATIC_SIZES 1 #endif Hope, this still makes it into Jessie! -- Adi signature.asc Description: Digital signature
Bug#780398: weak/insecure diffie-hellman parameters
Package: apache2 Version: 2.2.22-13+deb7u4 Hi! As Wheezy will be around for some more time (and squeeze-lts might also be interested in getting a little extra security), would you please consider backporting the DHE parameter size feature of Apache 2.4 to Apache 2.2 as you did with EC support? Thanks all the best, Adi Kriegisch PS: If you need more information and/or reasoning, please let me know! signature.asc Description: Digital signature
Bug#779834: redmine with redmine_dmsf yields a locale error
Package: redmine
Version: 2.5.1-2~bpo70+5
Severity: minor
Tags: patch
Hey!
I am running redmine from backports and packaged the necessary dependencies
of the redmine_dmsf[1] plugin. After installing (rake) the plugin, I get
the following error message:
| Rendered admin/plugins.html.erb within layouts/admin (64.9ms)
| Completed 500 Internal Server Error in 149.0ms
|
| ActionView::Template::Error (can not load translations from
| /usr/lib/ruby/vendor_ruby/../locales/en.yml: #TypeError: no implicit
| conversion from nil to integer):
| 1: %= title l(:label_plugins) %
| 2:
| 3: % if @plugins.any? %
| 4: table class=list plugins
| lib/redmine/i18n.rb:153:in `init_translations'
| lib/redmine/i18n.rb:167:in `lookup'
| lib/redmine/i18n.rb:27:in `l'
| app/views/admin/plugins.html.erb:1:in
| `_app_views_admin_plugins_html_erb__1842134549454110237_58120100'
The interesting part here is that somehow
/usr/lib/ruby/vendor_ruby/../locales/en.yml gets added to the list of
translations to load; this path, of course, does not exist and the loading
fails.
This is the list of files to load without plugins:
/usr/lib/ruby/vendor_ruby/active_support/locale/en.yml,
/usr/lib/ruby/vendor_ruby/active_model/locale/en.yml,
/usr/lib/ruby/vendor_ruby/active_record/locale/en.yml,
/usr/lib/ruby/vendor_ruby/action_view/locale/en.yml,
/usr/share/redmine/config/locales/en.yml
when adding/enabling redmine_dmsf these paths get added:
/usr/lib/ruby/vendor_ruby/active_support/locale/en.yml,
/usr/lib/ruby/vendor_ruby/active_model/locale/en.yml,
/usr/lib/ruby/vendor_ruby/active_record/locale/en.yml,
/usr/lib/ruby/vendor_ruby/action_view/locale/en.yml,
+ /usr/lib/ruby/vendor_ruby/../locales/en.yml,
/usr/share/redmine/config/locales/en.yml,
+ /usr/share/redmine/plugins/redmine_dmsf/config/locales/en.yml
Reporting this to the module's author[2] did not lead to any helpful answer
yet. The same issue has been reported before[3] together with a different
bug that has been fixed.
I am pretty sure that this issue is thightly related to the redmine_dmsf
plugin as other plugins do not show that behavior...
I created a workaround for the issue (see attached patch) that checks if a
translation exists before loading it.
I hope you can help me find a better solution!
-- Adi
[1] https://github.com/danmunn/redmine_dmsf
[2] https://github.com/danmunn/redmine_dmsf/issues/354
[3] https://github.com/danmunn/redmine_dmsf/issues/288
--- a/redmine/lib/redmine/i18n.rb 2014-03-29 17:56:41.0 +0100
+++ b/redmine/lib/redmine/i18n.rb 2015-02-20 20:12:41.381991935 +0100
@@ -148,7 +148,7 @@
def init_translations(locale)
locale = locale.to_s
- paths = ::I18n.load_path.select {|path| File.basename(path, '.*') == locale}
+ paths = ::I18n.load_path.select {|path| File.basename(path, '.*') == locale File.exists?(path)}
load_translations(paths)
translations[locale] ||= {}
end
signature.asc
Description: Digital signature
Bug#779196: breaks on non-existing license file
Package: dh-make-drupal
Version: 1.8-1
Severity: minor
Tags: patch
Hey!
I had to package some third party Drupal plugins which are admittetly in a
bad shape; the license file was missing. This led to the following error
message:
| /usr/bin/dh-make-drupal:330:in `join': can't convert nil into String
(TypeError)
| from /usr/bin/dh-make-drupal:330:in `setup_copyright'
| from /usr/bin/dh-make-drupal:191:in `build_structure'
| from /usr/bin/dh-make-drupal:1152:in `run'
| from /usr/bin/dh-make-drupal:1161:in `main'
the reason for this:
| def find_license
| files_at_root.select {|f| f =~ /license/i}
| end
(...skip to line 330...)
| if license = File.join(@instdir, find_license[0])
nil (aka file does not exists) cannot be converted to a String; so the
error handling that is in place does not work as expected:
| else
| Logger.instance.warn('No license file found in distribution, cannot' +
| 'guess copyright information - Please check by' +
| 'hand.')
To make it work the way it is expected to feel free to use the attached
patch that just checks find_license[0] to be not nil...
Thank you for your work; it is very much appreciated!
-- Adi
PS: I backported v1.8 to wheezy as I had lots of issues with v1.3; I'd love
to see an 'official' backport of dh-make-drupal! ;-)
--- a/dh-make-drupal 2015-02-25 12:21:41.676214005 +0100
+++ b/dh-make-drupal 2015-02-25 11:48:54.0 +0100
@@ -327,7 +327,7 @@
# Canonically, Drupal modules include LICENSE.txt. Even more,
# canonically it is the GPLv2 - For further joy, it's usually
# one of two exact same files! :-)
- if license = File.join(@instdir, find_license[0])
+ if find_license[0] != nil license = File.join(@instdir, find_license[0])
data = File.read(license) || '' # Avoid an exception if file is missing
if [998ed0c116c0cebfcd9b2107b0d82973,
b234ee4d69f5fce4486a80fdaf4a4263].include? Digest::MD5.hexdigest(data)
signature.asc
Description: Digital signature
Bug#745419: [Pkg-xen-devel] Bug#745419: xen-utils-4.1: Pygrub fails to boot from LVM LV when something installed in the volume boot record
Tags: patch I think this can be fixed with the following patch; it at least worked for me: http://lists.xen.org/archives/html/xen-devel/2011-01/txtLboGgCEUdF.txt -- Adi --- xen-4.1.0/tools/pygrub/src/pygrub.orig 2010-12-31 15:24:11.0 + +++ xen-4.1.0/tools/pygrub/src/pygrub 2011-01-30 18:58:17.0 + @@ -96,6 +96,7 @@ fd = os.open(file, os.O_RDONLY) buf = os.read(fd, 512) +offzerocount = 0 for poff in (446, 462, 478, 494): # partition offsets # MBR contains a 16 byte descriptor per partition @@ -105,6 +106,7 @@ # offset == 0 implies this partition is not enabled if offset == 0: +offzerocount += 1 continue if type == FDISK_PART_SOLARIS or type == FDISK_PART_SOLARIS_OLD: @@ -123,6 +125,9 @@ else: part_offs.append(offset) +if offzerocount == 4: +# Might be a grub boot sector pretending to be an MBR +part_offs.append(0) return part_offs class GrubLineEditor(curses.textpad.Textbox): signature.asc Description: Digital signature
Bug#764674: redis-server: Update wheezy backports to version = 2.8.9
Thank you very much for the backport of 2:2.8.17-1~bpo70+1. But that backport is uninstallable due to a dependency on libc6 = 2.14 which isn't available... Would it be possible to lower the dependency? -- Adi signature.asc Description: Digital signature
Bug#763900: iceweasel/ppc: jemallocCompile-time page size does not divide the runtime one.
Package: iceweasel Version: 31.1.0esr-1 I recently upgraded an iMac G5 to Debian/Jessie. Now iceweasel does not start anymore with the following error message: | jemallocCompile-time page size does not divide the runtime one. | Segmentation fault This seems to be a reoccurance of a rather old upstream bug[1] that can also be found on redhat's bugtracker[2]. This patch (inspired by the patch attached to the redhat bugtracker[3]) seems to fix the issue: --- a/memory/mozjemalloc/jemalloc.c 2014-08-25 15:17:22.0 +0200 +++ b/memory/mozjemalloc/jemalloc.c 2014-10-03 11:30:51.183346370 +0200 @@ -1088,7 +1088,7 @@ * controlling the malloc behavior are defined as compile-time constants * for best performance and cannot be altered at runtime. */ -#if !defined(__ia64__) !defined(__sparc__) !defined(__mips__) +#if !defined(__ia64__) !defined(__sparc__) !defined(__mips__) !defined(__powerpc__) #define MALLOC_STATIC_SIZES 1 #endif A local build with this patch applied works on my machine. -- Adi PS: I have the same error on Icedove too; will start a build with the same patch over the weekend and report the bug there too... [1] https://bugzilla.mozilla.org/show_bug.cgi?id=851859 [2] https://bugzilla.redhat.com/show_bug.cgi?id=852698 [3] https://bugzilla.redhat.com/attachment.cgi?id=610408 signature.asc Description: Digital signature
Bug#756004: Redmine (2.5.1-2~bpo70+1) requires a newer version of ruby-mime-types
Package: redmine
Version: 2.5.1-2~bpo70+1
Hey!
There is another issue with that backport: it requires a newer version of
ruby-mime-types:
| ActionView::Template::Error (undefined method `find' for
| MIME::Types:Class):
| 1: div class=attachments
| 2: % for attachment in attachments %
| 3: p%= link_to_attachment attachment, :class = 'icon
icon-attachment', :download = true -%
| 4: % if attachment.is_text? %
| 5: %= link_to image_tag('magnifier.png'),
| 6: :controller = 'attachments', :action = 'show',
| lib/redmine/mime_type.rb:63:in `block in of'
| lib/redmine/mime_type.rb:66:in `yield'
| lib/redmine/mime_type.rb:66:in `default'
| lib/redmine/mime_type.rb:66:in `of'
| lib/redmine/mime_type.rb:78:in `main_mimetype_of'
| lib/redmine/mime_type.rb:85:in `is_type?'
| app/models/attachment.rb:217:in `is_text?'
| app/views/attachments/_links.html.erb:3:in `block in
| _app_views_attachments__links_html_erb___1975547646385983842_56322060'
| app/views/attachments/_links.html.erb:2:in
| `_app_views_attachments__links_html_erb___1975547646385983842_56322060'
| app/helpers/attachments_helper.rb:31:in `link_to_attachments'
| app/views/wiki/show.html.erb:46:in
| `_app_views_wiki_show_html_erb___4419406770341271523_36907160'
| app/controllers/wiki_controller.rb:97:in `show'
I backported the version currently in sid and everything seems to work
fine. All wiki pages with attachments were affected by this issue.
-- Adi
signature.asc
Description: Digital signature
Bug#756004: Redmine (2.5.1-2~bpo70+1) requires a newer version of ruby-mime-types
Hey! Thanks for the information. I have just uploaded a new ruby-mime-types to wheezy-backports as well. Thank you and the whole Debian Ruby team for your excellent work! all the best to you on this years sysadmin day! ;-) -- Adi signature.asc Description: Digital signature
Bug#643970: Fixed upstream in 2.4.27 (ITS#6548)
Dear all, that issue is fixed upstream in v2.4.27 and was upstream bug #6548 and #7092; from the changelog[1]: | Fixed slapd no_connection warnings with ldapi (ITS#6548,ITS#7092) So that issue does not exist anymore since version 2.4.28-1 (as 2.4.27 never got packaged). Please close that bug report. -- Adi [1] http://www.openldap.org/software/release/changes.html signature.asc Description: Digital signature
Bug#704761: [Pkg-samba-maint] Bug#704761: Files not deleted, smbstatus shows Segmentation fault
Those two patches were added to 3.6.8. It would be great if it is possible [...] This bug probably qualifies for an update in a wheezy point release, though. I'm sorry, I noticed this issue already got reported as #688059. Please consider merging those two issues! Thanks, Adi Kriegisch signature.asc Description: Digital signature
Bug#704761: Files not deleted, smbstatus shows Segmentation fault
Package: samba Version: 3.6.6-5 Tags: patch Severity: important Dear maintainers, I recently upgraded samba to version 3.6.6 (from backports) in preparation of upgrade to Debian Wheezy. After upgrading I stumbled upon this issue: https://bugzilla.samba.org/show_bug.cgi?id=9058 (Files not deleted, smbstatus shows Segmentation fault) which can be fixed by applying those two patches (from within that upstream bug report): https://bugzilla.samba.org/attachment.cgi?id=7809 and https://bugzilla.samba.org/attachment.cgi?id=7817 Those two patches were added to 3.6.8. It would be great if it is possible to get those patches into samba before the release of Wheezy because that bug renders samba unusable for me (and most probably others). Thanks! -- Adi signature.asc Description: Digital signature
Bug#695351: Unable to handle kernel paging request at ffff880002908000
I just noticed the very same issue on one of my machines. Besides stumbling over this bug report I also found this one: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=642154 There was one follow up message that did not make it through to the Debian Bug Tracker but is archived here: http://xen.1045712.n5.nabble.com/Re-Bug-642154-BUG-unable-to-handle-kernel-paging-request-at-8803bb6ad000-td4822570.html quoting from there: For the record, same problem here with Xen 4.0 and an Intel Xeon CPU E31220 with microcode 0x14. (and the problem doesn't exists with a CPU E31220 without that microcode). The xen parameter noxsaveopt solved it. Probably the issue is somehow related? My CPU is a Core-i5 3470T that lists xsaveopt in /proc/cpuinfo. Up to now I wasn't able to trigger this issue any more on my machine. -- Adi signature.asc Description: Digital signature
Bug#690239: ExpressCard hotplug detection fails on Thinkpad T61 (workaround)
A workaround for the issue is to echo 1 /sys/bus/pci/rescan. But hotplug doesn't work any more... -- Adi signature.asc Description: Digital signature
Bug#690142: remote named DoS on recursor (CVE-2012-5166)
Package: bind9
Tags: security
Severity: grave
A security relevant bug on all versions of bind9 has been discovered. Only
recursive servers are vulnerable. To mitigate the effects of a possible
attack it should be sufficient to set minimal-responses yes; in the
global options {} section.
As information on that bug already leaked (and even got mailed to
full-disclosure by Mandriva), I am reporting to the Debian bugtracker.
See http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-5166 and
https://kb.isc.org/article/AA-00801 for details.
best regards,
Adi Kriegisch
signature.asc
Description: Digital signature
Bug#690142: remote named DoS on recursor (CVE-2012-5166)
Tags: security, patch
find the Ubuntu patch attached.
best regards,
Adi Kriegisch
=== modified file 'bin/named/query.c'
--- bin/named/query.c 2011-11-16 14:22:11 +
+++ bin/named/query.c 2012-10-05 09:45:39 +
@@ -1024,13 +1024,6 @@
mname = NULL;
}
- /*
- * If the dns_name_t we're looking up is already in the message,
- * we don't want to trigger the caller's name replacement logic.
- */
- if (name == mname)
- mname = NULL;
-
*mnamep = mname;
CTRACE(query_isduplicate: false: done);
@@ -1228,6 +1221,7 @@
if (dns_rdataset_isassociated(rdataset)
!query_isduplicate(client, fname, type, mname)) {
if (mname != NULL) {
+ INSIST(mname != fname);
query_releasename(client, fname);
fname = mname;
} else
@@ -1288,11 +1282,13 @@
mname = NULL;
if (!query_isduplicate(client, fname,
dns_rdatatype_a, mname)) {
-if (mname != NULL) {
- query_releasename(client, fname);
- fname = mname;
-} else
- need_addname = ISC_TRUE;
+if (mname != fname) {
+ if (mname != NULL) {
+ query_releasename(client, fname);
+ fname = mname;
+ } else
+ need_addname = ISC_TRUE;
+}
ISC_LIST_APPEND(fname-list, rdataset, link);
added_something = ISC_TRUE;
if (sigrdataset != NULL
@@ -1331,11 +1327,13 @@
mname = NULL;
if (!query_isduplicate(client, fname,
dns_rdatatype_, mname)) {
-if (mname != NULL) {
- query_releasename(client, fname);
- fname = mname;
-} else
- need_addname = ISC_TRUE;
+if (mname != fname) {
+ if (mname != NULL) {
+ query_releasename(client, fname);
+ fname = mname;
+ } else
+ need_addname = ISC_TRUE;
+}
ISC_LIST_APPEND(fname-list, rdataset, link);
added_something = ISC_TRUE;
if (sigrdataset != NULL
@@ -1846,22 +1844,24 @@
crdataset-type == dns_rdatatype_) {
if (!query_isduplicate(client, fname, crdataset-type,
mname)) {
-if (mname != NULL) {
- /*
- * A different type of this name is
- * already stored in the additional
- * section. We'll reuse the name.
- * Note that this should happen at most
- * once. Otherwise, fname-link could
- * leak below.
- */
- INSIST(mname0 == NULL);
+if (mname != fname) {
+ if (mname != NULL) {
+ /*
+ * A different type of this name is
+ * already stored in the additional
+ * section. We'll reuse the name.
+ * Note that this should happen at most
+ * once. Otherwise, fname-link could
+ * leak below.
+ */
+ INSIST(mname0 == NULL);
- query_releasename(client, fname);
- fname = mname;
- mname0 = mname;
-} else
- need_addname = ISC_TRUE;
+ query_releasename(client, fname);
+ fname = mname;
+ mname0 = mname;
+ } else
+ need_addname = ISC_TRUE;
+}
ISC_LIST_UNLINK(cfname.list, crdataset, link);
ISC_LIST_APPEND(fname-list, crdataset, link);
added_something = ISC_TRUE;
=== modified file 'debian/changelog'
--- debian/changelog 2012-09-12 16:16:57 +
+++ debian/changelog 2012-10-05 09:45:39 +
@@ -1,3 +1,12 @@
+bind9 (1:9.7.3.dfsg-1ubuntu4.5) oneiric-security; urgency=low
+
+ * SECURITY UPDATE: denial of service via specific combinations of RDATA
+- bin/named/query.c: fix logic
+- Patch backported from 9.8.3-P4
+- CVE-2012-5166
+
+ -- Marc Deslauriers marc.deslauri...@ubuntu.com Fri, 05 Oct 2012 09:45:39 -0400
+
bind9 (1:9.7.3.dfsg-1ubuntu4.4) oneiric-security; urgency=low
* SECURITY UPDATE: denial of service via large crafted resource record
signature.asc
Description: Digital signature
Bug#686248: race condition in ufw
Package: ufw Version: 0.29.3-1 Concurrent invocation of 'ufw delete' leads to inconsistent state: While automatically removing blocked hosts after a certain amount of time I discovered the following behavior: | root@host:~# ufw insert 1 deny from 1.2.3.4 to any | Rule inserted | root@host:~# ufw insert 1 deny from 1.2.3.5 to any | Rule inserted | root@host:~# echo ufw delete deny from 1.2.3.4 to any | at now + 1 minute | warning: commands will be executed using /bin/sh | job 1 at Thu Aug 30 16:20:00 2012 | root@host:~# echo ufw delete deny from 1.2.3.5 to any | at now + 1 minute | warning: commands will be executed using /bin/sh | job 2 at Thu Aug 30 16:20:00 2012 Note that both jobs get scheduled at the same time. After the jobs get executed (ie. both rules get deleted) I get two mails: one stating rule deleted and the other saying iptables: Resource temporarily unavailable. Rule deleted. ufw status shows the following: | root@host:~# ufw status | Status: active | | To Action From | -- -- | Anywhere DENY1.2.3.4 when running ufw delete deny from 1.2.3.4 to any again, I get: iptables: Bad rule (does a matching rule exist in that chain?). Rule deleted and the rule is finally gone. I am not sure if this is a feature request to implement locking in ufw or a documentation bug. In any way I consider this to be a very bad behavior for security software because one cannot trust the output and/or state of ufw any more. -- Adi Kriegisch signature.asc Description: Digital signature
Bug#638302: Issues with LSBHeaders and shutdown order
Package: ocfs2-tools Version: 1.4.4-3 Tags: patch Severity: important Doing a clean shutdown of a cluster node (with 11 volumes mounted) does not work and lead to exactly one volume with a still active heartbeat. This is the console message on shutdown: Stopping O2CB cluster dataserver: Failed Unable to stop cluster as heartbeat region still active First issue was to actually get the error message, as o2cb isn't stopped on my system (using insserv). To make it stop, those dependencies in the init scripts are required: * in /etc/init.d/o2cb: # Required-Stop: $network * in /etc/init.d/ocfs2: # Required-Stop: $local_fs $network o2cb (see attached patch) This leads to a system trying to shut down the ocfs2 cluster stack. The active heartbeat region results from sendsigs running in parallel with ocfs2 script trying to kill all running processes and sending a kill signal to umount -a -t ocfs2 ran by ocfs2 init script. This is why just one volume (no matter how many volumes one has) needs to be recovered in the cluster. Killing umount leads to a still active heartbeat region in the filesystem while umount moves on to the next mounted filesystem. To fix this adding # X-Stop-After: sendsigs to /etc/init.d/ocfs2 is required. Interesting enough, having just some ocfs2 volumes does not lead to that condition as the unmounting does not take that long. (Depending on your server's speed and stuff like that, of course) I have discussed the issue with Petter Reinholdtsen (the maintainer of insserv and initscripts that contain sendsigs) in a different bug[1] requesting a feature in insserv to let a task (like sendsigs) run exclusively on system shutdown. He basically said that ocfs2-tools should put the correct dependencies in the LSB header to make things work. In a different bug report[2] I sent a patch to prevent mountnfs and umountnfs from touching ocfs2 (and gfs) filesystems as this leads to error messages about being unable to mount ocfs2 volumes without the cluster stack. A possible different aproach to the issue could be to ditch ocfs2 script and force o2cb startup to happen before mountnfs and shutdown after umountnfs. That way ocfs2 could be handled like a generic network file system. But I guess it is not up to me to decide which way to go... ;-) Find a patch attached that adds shutdown dependencies to LSB headers of init scripts that works for me and seem to be sane. Thanks, Adi [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=590892 [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=504748 diff -Nru etc/init.d/o2cb etc/init.d/o2cb --- etc/init.d/o2cb 2011-08-18 13:09:41.0 +0200 +++ etc/init.d/o2cb 2011-08-18 13:10:00.0 +0200 @@ -8,7 +8,7 @@ # Provides: o2cb # Required-Start: $network # Should-Start: -# Required-Stop: +# Required-Stop: $network # Default-Start: S # Default-Stop: 0 6 # Short-Description: Load O2CB cluster services at system boot. diff -Nru etc/init.d/ocfs2 etc/init.d/ocfs2 --- etc/init.d/ocfs2 2011-08-18 13:10:27.0 +0200 +++ etc/init.d/ocfs2 2011-08-18 13:10:16.0 +0200 @@ -8,9 +8,10 @@ ### BEGIN INIT INFO # Provides: ocfs2 # Required-Start: $local_fs $network o2cb -# Required-Stop: $local_fs +# Required-Stop: $local_fs $network o2cb # X-UnitedLinux-Should-Start: # X-UnitedLinux-Should-Stop: +# X-Stop-After: sendsigs # Default-Start: S # Default-Stop: 0 6 # Short-Description: Mount OCFS2 volumes at boot.
Bug#590892: interactive not honored on shutdown, sindsigs not interactive
I am currently running into this exact situation with /etc/init.d/ocfs2: The script takes care of (un)mounting all ocfs2 volumes. In my case I have 11 volumes to be unmounted which takes some time, sendsigs tries to kill umount -a -t ocfs2 which leads to an open heartbeat on exactly one volume (the one unmounted in parallel with sendsigs trying to kill umount). I understand that a system shutdown should not be interactive and that setting # X-Interactive: true isn't the way to go. So probably introducing # X-Exclusive: true could be a viable solution to the problem of providing a somewhat similar feature to system shutdown? In case you think that this is an issue with ocfs2-tools (the package providing /etc/init.d/ocfs2), please tell me what a good/working LSB header would look like. From what I've read I'd rather think that a script that needs to run in an exclusive fashion should indicate that (which means that this bug needs to be reasigned to initscripts which provides /etc/init.d/sendsigs). best regards, Adi Kriegisch -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#590892: interactive not honored on shutdown, sindsigs not interactive
On Wed, Aug 17, 2011 at 03:50:24PM +0200, Petter Reinholdtsen wrote: [Adi Kriegisch] I am currently running into this exact situation with /etc/init.d/ocfs2: The script takes care of (un)mounting all ocfs2 volumes. In my case I have 11 volumes to be unmounted which takes some time, sendsigs tries to kill umount -a -t ocfs2 which leads to an open heartbeat on exactly one volume (the one unmounted in parallel with sendsigs trying to kill umount). Is it enough to make sure the script run before sendsigs? If not, why do you need to run it alone? Yes, it is enough to run the script either before or after sendsigs. Actually the ocfs2 script *could* even run in parallel with sendsigs, provided sendsigs does not kill this script's tasks. ;-) In case you think that this is an issue with ocfs2-tools (the package providing /etc/init.d/ocfs2), please tell me what a good/working LSB header would look like. From what I've read I'd rather think that a script that needs to run in an exclusive fashion should indicate that (which means that this bug needs to be reasigned to initscripts which provides /etc/init.d/sendsigs). I would suspect changing the header to make sure the script is running before sendsigs would be enough, but I do not really understand the problem. The problem is that a script (sendsigs) is killing tasks from other init scripts that happen to run in parallel to it. This has started to happen since the switch to insserv, obviously. I consider a script that acts destructive to other scripts without even giving a hint (aka need to run exclusively) a problem. IMHO sendsigs needs to avoid killing stuff from other scripts. Actually I am quite surprised that ocfs2 is obviously the only script affected by this... So in your opinion the right way to deal with the issue is to file a bug against ocfs2-tools telling them that it is necessary to add a dependency on sendsigs to avoid getting killed when using more than just some volumes (I think this started to take too long to umount at around 7 or 8 volumes)? Thanks for your quick response! -- Adi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#590892: interactive not honored on shutdown, sindsigs not interactive
On Wed, Aug 17, 2011 at 04:30:49PM +0200, Petter Reinholdtsen wrote: [Adi Kriegisch] Actually I am quite surprised that ocfs2 is obviously the only script affected by this... Well, most scripts have fairly correct dependency information, and when they do, this problem will not occur. Hmmm... Judging from a grep on the init scripts on my system almost all of them depend on $remote_fs which will avoid being killed by sendsigs. So, I think you're right: ocfs2 is (kind of) providing a remote filesystem and should therefor include a sendsigs dependency. Perhaps it should have a stop dependency on sendsigs, or perhaps it should depend on $remote_fs, or perhaps it should register a omit file to avoid being killed by sendsigs. I do not know, but what you descripe defintely sound like a bug in the ocfs2-tools package. Registering an omit file for a task run by an init script on system shutdown (umount -a -t ocfs2) sounds futile to me, but probably isn't because ocfs2 is running before sendsigs starts. On the other hand a dependency seems to be a cleaner way of getting rid of that stuff. IMHO the ocfs2 script should run after sendsigs and in parallel with the rest of $remote_fs as it is providing the same features. I will submit a patch for bug #504748 (initscripts: mountall.sh must not mount ocfs2, gfs) as [u]mountnfs is not the right place to handle ocfs2 stuff. Thanks for your help and the insights on insserv! -- Adi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#504748: initscripts: mountall.sh must not mount ocfs2, gfs
Tags: patch Find a patch attached that really removes ocfs2 and gfs from /etc/init.d/mountnfs.sh /etc/init.d/umountnfs.sh and /etc/network/if-up.d/mountnfs OCFS2 needs ocfs2-tools package to work which provides o2cb and the cluster stack necessary to mount ocfs2 file systems. Trying to mount those filesystems in other init scripts will fail. Besides that ocfs2-tools provides a second script -- /etc/init.d/ocfs2 -- that takes care of the mounting and unmounting. I assume this issue is very similar to GFS. Thanks, Adi PS: I think the severity of this bug can be downgraded to 'normal' or even 'minor' as the attempt of mounting and umounting ocfs2 volumes by the initscript's files results in an error message but basically has no effect besides that message. --- etc/network/if-up.d/mountnfs 2011-08-17 17:37:24.0 +0200 +++ etc/network/if-up.d/mountnfs 2011-08-17 17:37:51.0 +0200 @@ -71,7 +71,7 @@ # NFSv4 requires idmapd, so start nfs-common no matter what the options are. start_nfs=yes ;; - smbfs|cifs|coda|ncp|ncpfs|ocfs2|gfs) + smbfs|cifs|coda|ncp|ncpfs) ;; *) FSTYPE= --- etc/init.d/mountnfs.sh 2011-08-17 17:06:59.0 +0200 +++ etc/init.d/mountnfs.sh 2011-08-17 17:36:44.0 +0200 @@ -40,7 +40,7 @@ ;; esac case $FSTYPE in - nfs|nfs4|smbfs|cifs|coda|ncp|ncpfs|ocfs2|gfs) + nfs|nfs4|smbfs|cifs|coda|ncp|ncpfs) ;; *) continue --- etc/init.d/umountnfs.sh 2011-08-17 17:06:54.0 +0200 +++ etc/init.d/umountnfs.sh 2011-08-17 17:09:30.0 +0200 @@ -63,7 +63,7 @@ ;; esac case $FSTYPE in - nfs|nfs4|smbfs|ncp|ncpfs|cifs|coda|ocfs2|gfs) + nfs|nfs4|smbfs|ncp|ncpfs|cifs|coda) DIRS=$MTPT $DIRS ;; proc|procfs|linprocfs|devpts|usbfs|usbdevfs|sysfs) @@ -72,7 +72,13 @@ esac case $OPTS in _netdev|*,_netdev|_netdev,*|*,_netdev,*) - DIRS=$MTPT $DIRS + case $FSTYPE in + ocfs2|gfs) +;; + *) +DIRS=$MTPT $DIRS +;; + esac ;; esac done
Bug#590892: interactive not honored on shutdown, sindsigs not interactive
On Wed, Aug 17, 2011 at 07:10:40PM +0200, Petter Reinholdtsen wrote: [Adi Kriegisch] Registering an omit file for a task run by an init script on system shutdown (umount -a -t ocfs2) sounds futile to me, but probably isn't because ocfs2 is running before sendsigs starts. On the other hand a dependency seems to be a cleaner way of getting rid of that stuff. The omit file would be registered in the start part of the script, and created during boot, not during shutdown. The point would be to let the boot system know that the service is supposed to survive until the very end of the shutdown. rsyslog do this, if you need an example. Yes, I know how to do that. But what gets killed isn't a service but just the umount command issued by ocfs2 script. ocfs2 script just mounts and unmounts all ocfs2 volumes and displays the mount status of ocfs2 filesystems. Parts of the functionalty just duplicate the mountnfs and umountnfs code. That is why I think it is futile to register the pid of 'umount -a -t ocfs2' within an omit file. And that is why I still (at least partly) think that there should be some kind of 'X-Exclusive' for system shutdown in insserv: because sendsigs might kill commands executed by other init scripts that might run a little longer for some reaon. Thanks for your answer! -- Adi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#636304: texlive-base 2009-12 is broken on upgrade
Hi! As a temporary fix, replace the return 0 with exit 0 in /etc/libpaper.d/texlive-base (line 48). This way you can at least complete the upgrade... -- Adi signature.asc Description: Digital signature
Bug#614837: dvb-usb crash with dib0700 (Hauppauge Nova-T Stick)
Package: linux-2.6
Version: 2.6.37-1
Severity: important
Tags: patch
Trying to watch TV with Hauppauge Nova-T Stick leads to a kernel panic with
'unable to handle kernel NULL pointer'. This worked just fine with kernel
2.6.32 and below.
The same issue has been reported:
http://bugs.gentoo.org/show_bug.cgi?id=326511 and
https://bugzilla.kernel.org/show_bug.cgi?id=20372
Patch for the issue: https://patchwork.kernel.org/patch/534231/
I applied this patch, recompiled the modules and it works fine, again.
Debug information
Loading the driver:
usb 2-1: new high speed USB
device using ehci_hcd and address 4
usb 2-1: New USB device found, idVendor= 2040, idProduct=7050
usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 2-1: Product: Nova-T Stick
usb 2-1: Manufacturer: Hauppauge
usb 2-1: SerialNumber: 4027567780
IR NEC protocol handler initialized
IR RC5(x) protocol handler initialized
dib0700: loaded with support for 15 different device-types
dvb-usb: found a 'Hauppauge Nova-T Stick ' in cold state, will try to load a
firmware
IR RC6 protocol handler initialized
IR JVC protocol handler initialized
IR Sony protocol handler initialized
dvb-usb: downloading firmware from file 'dvb-usb-dib0700-1.20.fw'
lirc_dev: IR Remote Control driver registered, major 252
IR LIRC bridge handler initialized
dib0700: firmware started successfully.
dvb-usb: found a 'Hauppauge Nova-T Stick' in warm state.
dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer.
DVB: registering new adapter (Hauppauge Nova-T Stick)
DVB: registering adapter 0 frontend 0 (DiBcom 7000MA/MB/PA/PB/MC)...
MT2060: successfully identified (IF1 = 1230)
Registered IR keymap rc-dib0700-rc5
input: IR-receiver inside an USB DVB receiver as
/devices/pci:00/:00:1d.7/usb2/2-1/rc/rc0/input11
rc0: IR-receiver inside an USB
DVB receiver as /devices/pci:00/:00:1d.7/usb2/2-1/rc/rc0
dvb-usb: schedule remote query interval to 50 msecs.
dvb-usb: Hauppauge Nova-T Stick successfully initialized and connected.
usbcore: registered new interface driver dvb_usb_dib0700
starting any app to make use of the DVB-T stick ('scan' in this case):
BUG: unable to handle kernel NULL pointer dereference at 0012
IP: [a040cce4] i2c_transfer+0x1a/0xdd [i2c_core]
PGD 204ff067 PUD 204fe067 PMD 0
Oops: [#1] SMP
[SNIP]
Pid: 27243, comm: scan Tainted: GW 2.6.37-1-amd64 #1 8889ALG/8889ALG
RIP: 0010:[a040cce4] [a040cce4] i2c_transfer+0x1a/0xdd
[i2c_core]
RSP: 0018:88001742fc28 EFLAGS: 00010286
RAX: ffa1 RBX: 0002 RCX:
RDX: 0002 RSI: 88001742fc68 RDI: 0002
RBP: R08: 88003734acc0 R09: 0001
R10: dead00100100 R11: 810fd070 R12: c900099f
R13: 88001742fc68 R14: 0002 R15:
FS: 7f09212c5700() GS:88007ec0() knlGS:
CS: 0010 DS: ES: CR0: 8005003b
CR2: 0012 CR3: 317da000 CR4: 06f0
DR0: DR1: DR2:
DR3: DR6: 0ff0 DR7: 0400
Process scan (pid: 27243, threadinfo 88001742e000, task 88007c373600)
Stack:
00eb
c900099f 0001 a019e109
00020070 88001742fc98 000200010070 88001742fc88
Call Trace:
[a019e109] ? dib7000p_read_word+0x6e/0xbe [dib7000p]
[a0132c53] ? usb_urb_submit+0x26/0x67 [dvb_usb]
[a019ed17] ? dib7000p_pid_filter_ctrl+0x1f/0x7b [dib7000p]
[a013209d] ? dvb_usb_ctrl_feed+0xcb/0x113 [dvb_usb]
[a00a70b0] ? dmx_section_feed_start_filtering+0xfa/0x14e [dvb_core]
[a00a5a2e] ? dvb_dmxdev_filter_start+0x230/0x301 [dvb_core]
[a00a61a8] ? dvb_demux_do_ioctl+0x1be/0x4a6 [dvb_core]
[81103338] ? dput+0x2c/0x12f
[a00a43da] ? dvb_usercopy+0xc2/0x14a [dvb_core]
[81103338] ? dput+0x2c/0x12f
[a00a5fea] ? dvb_demux_do_ioctl+0x0/0x4a6 [dvb_core]
[a00a4fb5] ? dvb_demux_ioctl+0x10/0x14 [dvb_core]
[81100360] ? do_vfs_ioctl+0x4a2/0x4ef
[811003f8] ? sys_ioctl+0x4b/0x6f
[810f1fe5] ? do_sys_open+0xcf/0xde
[81009a12] ? system_call_fastpath+0x16/0x1b
Code: 05 48 89 c7 eb e2 41 5b 48 83 c7 20 e9 80 1b f1 e0 41 56 41 89 d6 b8 a1
ff ff ff 41 55 49 89 f5 41 54 55 53 48 89 fb 48 83 ec 10 48 8b 57 10 48 83 3a
00 0f 84 a8 00 00 00 65 48 8b 04 25 48 cc
RIP [a040cce4] i2c_transfer+0x1a/0xdd [i2c_core]
RSP 88001742fc28
CR2: 0012
---[ end trace d1043442e31b11f5 ]---
signature.asc
Description: Digital signature
Bug#613554: Scribus package description falsely references QT3 as dependency
Package: scribus Version: 1.3.9.dfsg+svn20110210-1 Severity: minor Subject says it all; package description contains this line: Graphic formats which can be placed in Scribus as images include PDF, Encapsulated Post Script (eps), TIFF, JPEG, PNG and XPixMap(xpm), and any bitmap type supported by QT3. which -- of course -- isn't true anymore! ;-) Thanks, Adi Kriegisch -- System Information: Debian Release: wheezy/sid (not necessary) signature.asc Description: Digital signature
Bug#577788: dom0 kernels should suggest irqbalance
Package: xen-linux-system-2.6.32-4-xen-686 Version: 2.6.32-11 Severity: minor I recently[1] noticed that a kernel booted as Dom0 does attach all interrupts to CPU0 which may lead to performance issues. Suggesting/recomending 'irqbalance' and probably mention the issue in README.Debian should suffice, I guess. RedHat Enterprise Server[2] seems to have this package installed by default; I could not find any details about Novell/SuSE... -- Adi [1] http://lists.xensource.com/archives/html/xen-users/2010-04/msg00577.html [2] https://www.redhat.com/security/data/metrics/cpelist-rhel5server-default-install.txt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#500993: xserver-xglamo: needs to be setuid root
Package: xserver-xglamo Version: 1.3.0.0+git20080807-3 When trying to start Xglamo the following error message is presented: Fatal server error: LinuxInit: Server must be suid root chmod u+s /usr/bin/Xglamo obviously fixes the situation. ...on the other hand: is this really necessary? ls -l /usr/bin/Xorg -rwxr-xr-x 1 root root 1675980 Sep 30 23:54 /usr/bin/Xorg Thanx for providing the possibility to run Debian even on my FR! :-) -- Adi signature.asc Description: Digital signature
Bug#397751: depend on correct hypervisor
Package: linux-image-2.6.18-1-xen-k7 Version: =2.6.18-3 (This report is for all xen versions of the linux kernel!) kernel 2.6.18-2 and below worked (only) with the hypervisor of the unstable xen series (xen-hypervisor-3.0-unstable-1-i386). With 2.6.18-3 (and above) this behavior changed: xen-hypervisor-3.0.3-1-i386 is required. I found this behavior documented in the changelog but I think the right way is to depend on the correct hypervisor. best regards, Adi Kriegisch -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#391345: aoetools: Postinst fails with missing devices
Hi! The same happened to me... Thanx for the bug report -- as I am new to AoE it was very helpful! ;-) Btw: for me it was a new installation not an upgrade, but the message was the same and I am using udev as well! best regards, Adi Kriegisch pgpdWRM9pHFpC.pgp Description: PGP signature
Bug#387402: New upstream release: 0.3.8
Package: strigi Version: 0.3.2-3 Severity: wishlist Hi! A new upstream release of strigi is available: 0.3.8 -- would be cool to get that soon! ;-) best regards, Adi Kriegisch PS: Keep up the good work! pgpGqofChoNhh.pgp Description: PGP signature
Bug#348932: yaSSL added the FLOSS extension to its license
Hi! Just to provide an update to the bug report: - yaSSL added FLOSS extension to its license - mysql integrated the new version of yaSSL into release 5.0.25... Now I think it should be possible to ship mysql with SSL support (by default)?! :-) best regards, Adi Kriegisch -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#360707: please add powerpc to os.dat
Package: rkhunter Version: 1.2.8-1 Hi! Please add a line like 710:Debian testing/unstable (powerpc):/usr/bin/md5sum:/bin: [probably this applies for all Debian platforms? -- maybe all of them should be added... I just found i386, sparc64 and x86_64 in os.dat] to /var/lib/rkhunter/db/os.dat to avoid messages like: - [EMAIL PROTECTED]:~# rkhunter -c Rootkit Hunter 1.2.8 is running Determining OS... Unknown Warning: This operating system is not fully supported! Warning: Cannot find md5_not_known All MD5 checks will be skipped! -- [EMAIL PROTECTED]:~# uname Linux [EMAIL PROTECTED]:~# uname -m ppc [EMAIL PROTECTED]:~# uname -a Linux server 2.6.8-powerpc #1 Sun Mar 20 14:09:41 CET 2005 ppc GNU/Linux -- Keep up the good work! best regards, Adi Kriegisch pgp2vbwKHHCrR.pgp Description: PGP signature
Bug#310371: Please add patch for kernel 2.6
Package: kernel-patch-nfs-ngroups A patch for kernel 2.6 is available as well; could you add it to the package? (http://frankvm.xs4all.nl/nfs-ngroups/) Thank you! Adi Kriegisch pgpBOI43LDwt7.pgp Description: PGP signature
Bug#292935: on local delivery some mails arrive/some do not...
On Monday 31 January 2005 17:45, Richard A Nelson wrote: Aha... yes, that would do it - thanks, I'm hoping the package gets built before I have to board the plane... To fix this now, add this to your sendmail.mc and rebuild sendmail.cf MODIFY_MAILER_FLAGS(`LOCAL', `-m')dnl worked fine for me! Thank you very much!! If it was the same problem for Joao then you might close the bug, I guess. best regards, Adi Kriegisch pgpuzN5uyNRys.pgp Description: PGP signature
Bug#292935: on local delivery some mails arrive/some do not...
I think I have a similar problem here: (I only noted this with my root mails
at the moment!)
There are three local users getting root mails. They are in one line
in /etc/aliases with their username (no alias)
root: usera,userb,userc
yesterday only one of them (the last -- userc) recieved the mail today userb
and userc. usera did not recieve email. (I did the update 3 days ago;
rootmail should be delivered at least every day in the morning at 6:30).
usera never got root mails.
And now for the funny part: The log says the following (anonymized):
Jan 31 06:29:57 myserver sm-mta[2660]: myuniqeid1234: to=usera,userb,userc,
ctladdr=[EMAIL PROTECTED] (0/0), delay=00:00:05, xdelay=00:00:00,
mailer=local, pri=95718, dsn=2.0.0, stat=Sent
before updating there was a line for every user in the mail log; now it trys
to deliver at once (as I found out because of the m option in
LOCAL_MAILER_FLAGS?!) and eats some of the mails for unknown reason.
I used 8.13.3-1 before and did an upgrade to 8.13.3-3. The only significant
change I noted was: (diff -u sendmail.cf.old sendmail.cf)
[cut documentation and time stamp changes]
@@ -212,7 +212,7 @@
# Configuration version number
-DZ8.13.3/Debian-1
+DZ8.13.3/Debian-3
@@ -1760,10 +1760,10 @@
R$+$@ $1 @ *LOCAL* add local qualification
-Mlocal,P=/usr/sbin/sensible-mda, F=lsDFMAw5:/|@qSPhnu,
S=EnvFromL/HdrFromL, R=EnvToL/HdrToL,
+Mlocal,P=/usr/sbin/sensible-mda, F=lsDFMAw5:/|@qPmn9S,
S=EnvFromL/HdrFromL, R=EnvToL/HdrToL,
T=DNS/RFC822/X-Unix,
A=sensible-mda $g $u $h ${client_addr}
-Mprog, P=/usr/lib/sm.bin/smrsh, F=lsDFMoqu, S=EnvFromL/HdrFromL,
R=EnvToL/HdrToL, D=$z:/,
+Mprog, P=/usr/lib/sm.bin/smrsh, F=lsDFMoqeu9, S=EnvFromL/HdrFromL,
R=EnvToL/HdrToL, D=$z:/,
T=X-Unix/X-Unix/X-Unix,
A=smrsh -c $u
..the change in the LOCAL_MAILER_FLAGS.
Any help highly appreciated!! If you need my config files and/or mail.log
please tell me and I will send them to you in private.
best regards,
Adi Kriegisch
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#292893: smartmontools produce scsi: unknown opcode 0x4d
Package: smartmontools Version: 5.32-2 (I hope this is the right place to report this bug) After one of the last kernel upgrades (I didn't reboot since 2.6.8-11) -- either 2.6.8-12 or 2.6.8-13 -- introduced something that makes smartctl and smartd to produce the following kernel messages every time they access smart information from my harddisks: scsi: unknown opcode 0x4d running smartctl -a /dev/sda produces about 20 entries. From what I found out of kernel-source-2.6.8-13 changelog: * scsi-ioctl.dpatch Provide a warning about unknown opcodes (Andres Salomon). I would say that this might be related somehow. Anyways, I hope this is the right place to report this bug. As kernel 2.6.8 and smartmontools 5.32 should go into sarge maybe this should get fixed somehow... best regards, Adi Kriegisch
