Hi,
I have been browsing through the log files containing the error messages
and I found a very surprising pattern. In the last two weeks, the errors
were caused (exclusively) by the following files:
> /backups/HIS/history/2009-04-15_13h00m01s/172.26.26.1/xxx/berichten/2626/klaar/15632
> /backups
Hi,
For over two years I am experiencing the same problem when hardlinking
large amounts of data. However, on my servers it is /not/ reproducible.
The error occurs in an automated process and concerns different files
every time. Furthermore, it does not occur every day.
> cp: cannot create hard l
What's the state of this bug?
Stable (Lenny) is frozen, but it is (obviously) allowed to upload new
versions to unstable and/or experimental. Many users are using those
"unstable" packages, because GnuCash is under heavy development.
Thanks!
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ..
I've just downloaded the WebSVN 2.1 tarball and it is not vulnerable for
this issue. Therefore, reporting to upstream doesn't make any sense...
However, WebSVN 2.0 will appear in Lenny. I think the fix should be
backported to 2.0 or Lenny should contain WebSVN 2.1.
--
To UNSUBSCRIBE, email to
Florian Weimer wrote:
> * Bas van Schaik:
>
>> When WebSVN is configured to use an SVN authz file to check user
>> permissions, it only lists the repositories to which the user has
>> been granted authorization (like expected).
>>
> Thanks. Has this be
Package: websvn
Version: 2.0-4
Severity: grave
Tags: security
Justification: user security hole
When WebSVN is configured to use an SVN authz file to check user
permissions, it only lists the repositories to which the user has
been granted authorization (like expected).
However, a malicious (auth
Package: zabbix-server-mysql
Version: 1:1.6-1
Severity: important
Every few days the host running the Zabbix server runs out of memory
(both 'real memory' and swap). A simple 'top' clearly shows a large
amount of zabbix_server processes (about 40 of them), using up to 270M
of memory (VIRT) each. R
Michael Ablassmeier wrote:
> hi Bas,
>
> On Tue, Oct 07, 2008 at 01:58:17PM +0200, Bas van Schaik wrote:
>
>> I didn't get any dbconfig-common question at all. Maybe it is important
>> to note that my MySQL server is actually running on another server?
>>
Michael Ablassmeier wrote:
> hi,
>
> On Wed, Oct 01, 2008 at 08:53:02PM +0200, Bas van Schaik wrote:
>
>> After upgrading my Zabbix 1.4.6 installation from Lenny to Zabbix 1.6
>> from Sid Zabbix does not work anymore, complaining about "unknown column
>>
Package: zabbix
Version: 1.6
Severity: grave
Justification: renders package unusable
After upgrading my Zabbix 1.4.6 installation from Lenny to Zabbix 1.6
from Sid Zabbix does not work anymore, complaining about "unknown column
'g.gui_access'" and "unknown column 'g.users_status'". Clearly, upgrad
Package: zabbix
Severity: wishlist
Subject: New version available: zabbix 1.6
Package: zabbix
Severity: wishlist
About a week ago Zabbix 1.6 was released. It would be nice to have this
version in experimental or unstable to test the new functionalities
(ipv6, escalation and repeated notification
Thanks for the quick fix, Michael! I hope upstream will fix this soon so
the patch will appear in testing.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Hi Michael,
I'm sorry, I should have been a little bit more clear about this. The
zabbix_agentd process runs as zabbix:zabbix indeed, but the so called
"UserParameter" scripts run with user:group zabbix:root. Or at least,
this is the output of such a script calling `id`:
> uid=110(zabbix) gid=111(
Package: zabbix-agent
Version: 1:1.1.4-10
Severity: important
The zabbix-agentd process runs as user 'zabbix' by default, which is of
course very desirable. However, the process' gid defaults to 0 (root)
which did really surprise me. On systems using this group for
administrative purposes, this (u
I forgot to attach the second chart, here it is.
<>
Package: zabbix-frontend-php
Version: 1:1.4.2-2
Severity: normal
I've created a graph in a template called 'Linux_template' which shows the disk
usage on mountpoint /backups. The graph for host 'infinity' is absolutely
marvelous for time up to about 2 days and 5 hours ago. Before that, the graph
A database upgrade is indeed required to fix the following error when
trying to switch to a queue view:
> Can't use an undefined value as a HASH reference at
> /usr/share/otrs//Kernel/System/Ticket/Article.pm line 1409.
FYI, these are the two SQL statements that need to be executed on the
OTRS ta
Upstream marks this bug as "Debian only" with a reasonable explanation:
> Problems with SSL on Debian are well known, and it is due to the fact
> that they long ago patched OpenLDAP 2.1 to compile against GnuTLS
> (note, I don't say *work*, just compile).
>
> When you use their 2.2 and 2.3 packages
Paul Slootman wrote:
> On Wed 04 Jul 2007, Bas van Schaik wrote:
>
>>> --chmod=Dg+s,ug+w,Fo-w,+X
>>>
>>>
>> Wow, why didn't I see that?
>>
>> But wait... I can't find such a line in my manpages (clean Debian Etch
Paul Slootman wrote:
> On Sun 24 Jun 2007, Bas van Schaik wrote:
>
>
>> May users send their backups to my central rsync server and I'm using
>> the 'incoming chmod' option to correct permissions which are too
>> restrictive. This way, I can have a non-
Package: rsync
Version: 2.6.9-2
Severity: wishlist
May users send their backups to my central rsync server and I'm using
the 'incoming chmod' option to correct permissions which are too
restrictive. This way, I can have a non-privileged user maintaining the
backups by using the rsyncd.conf 'uid' o
Did you check if hda and hdc got swapped by accident? I once had a
mainboard which had some awful bug: it swapped controllers after a
warm-boot (i.e. reboot). Controllers were somehow presented in another
sequence and Debian detected them the other way around. So: hda became
hdc, hdc became hda.
H
Is there any progression in this bug? Since two people have taken a
serious look at this bug and one patch with suggestions is available, I
don't think we're far away from fixing this!
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTE
Package: pdns
Version: 2.9.20-8
Severity: grave
Justification: causes non-serious data loss
When a (super)master nameserver sends NOTIFY-packets to it's slave
nameserver(s), those will queue an AXFR for the modified zone. However,
if this AXFR fails (for example, because of a master nameserver get
Package: pdns
Version: 2.9.20-8
Severity: normal
When a zone gets deleted from a (MySQL backended) supermaster
nameserver, the accompanying slave nameservers (also configured with a
MySQL backend) get confused when doing a periodic retrieve/refresh of
the zone:
> May 14 06:37:25 callisto pdns[1726
Maybe this bug is related to #400301 ?
Anyway, if the hash-driver actually is malfunctioning, I think it should
fixed, or removed from Etch. Or there should be a _very_ big warning
when installing dspam, because this behavior causes most MTAs to defer mail.
--
To UNSUBSCRIBE, email to [EMAIL PR
(last bug comment was obviously a mispost, should have been posted to
#408455)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
I'm very sorry, but the files causing the problems were accidentally
removed, so I can't reproduce the problem anymore. However, I'm sure
that there was something weird going on there, but as long as this
behavior can't be reproduced, we'll never now what was the cause of my
problem.
Thanks anyway
Sorry, I missed Kurts last post about the hash-driver.
I'm indeed using the hash-driver, but IMHO this should work without
mysterious failures _or_ there should be a very big warning that one
shouldn't use the buggy hash-driver _or_ the driver should be removed
from Etch.
--
To UNSUBSCRIBE, ema
Same behavior here: up-to-date Etch installation with Postfix --> DSpam
--> Amavis --> Cyrus (using content_filter directive). After a week of
excellent performance, DSpam started crashing. Currently, I'm able to
start the daemon process, but it crashes without any trace in the logs
when feeding a
Jim Meyering wrote:
> Bas van Schaik <[EMAIL PROTECTED]> wrote:
>
>> Package: coreutils
>> Version: 5.97-5
>> Severity: normal
>>
>> When using
>>
>>> cp -lar srcdir/* targetdir
>>>
>> on a srcdir containing fil
Package: coreutils
Version: 5.97-5
Severity: normal
When using
> cp -lar srcdir/* targetdir
on a srcdir containing files (no matter how deep in srcdir) with spaces in
their filenames, cp complains:
> cp: cannot create hard link `targetdir/(...)/filename' to
> `targetdir/(...)/filename': No suc
How is the status of this bug? As far as I can see, Cyril Chaboisseau
has posted a report of a successful installation using PHP5, or am I wrong?
I would really like to see this bug resolved, because I need PHP5 and
want to run Tikiwiki on the same machine.
By the way, I see that you needed some
Jeroen van Wolffelaar wrote:
> On Thu, Dec 07, 2006 at 04:10:06PM +0100, Bas van Schaik wrote:
>
>> Just like stated in the TODO.Debian file: the package is missing an
>> initscript to automatically export devices at boot time.
>>
>
> Some comments:
> (
Package: ethstatus
Version: 0.4.3
Severity: wishlist
Currently, ethstatus isn't capable of detecting my line speed
automatically, causing the beautiful graph to be underscaled by default.
I have to manually pass a commandline option to tell ethstatus about my
ethernet connection speed, but this in
Just noticed an error in the initscript: after sending a normal kill to
the process ids, an "killall -9 $pids" is issued, which is of course not
valid.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Package: vblade
Version: 11-1
Severity: wishlist
Tags: patch
Just like stated in the TODO.Debian file: the package is missing an
initscript to automatically export devices at boot time.
(tried to contact the maintainer with an example file, but he seems too
busy and doesn't respond, hence the pa
Ah, I see: unix-status-server assumes that one is using a 2.4 kernel (?)
and expects an other type of /proc/meminfo. This means that
unix-status-server should be 2.6-aware!
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Package: remstats-servers
Version: 1.0.13a-5
Severity: normal
On line 848 of unix-status-server, you'll find the following statement:
> if( /^Mem:\s+(\d+)/) {
However, on my (Debian Sarge) system, /proc/meminfo doesn't contain a
entry like "^Mem:", however, it does contain "^MemTotal:" which is t
Package: remstats-servers
Version: 1.0.13a-5
Severity: important
I noticed that remstats didn't always receive correct information from
the remstats-servers, so I decided to dry-run them. When executing
"/usr/lib/remstats/bin/unix-status-server"
[begin quote]
unix-status-server> PROCDISKIO
unix-s
Package: otrs
Version: 1:1.3.3p01-1
Severity: normal
Line 331 of /usr/share/otrs/Kernel/Modules/SystemStats.pm says:
if (!$graph->can('png')) {
$Ext = 'png';
}
Obviously, the negation inside the if-clause should be removed: if
graph can't draw png, then $Ext shouldn't be png!
This typo
Package: wnpp
Severity: wishlist
Owner: Bas van Schaik <[EMAIL PROTECTED]>
* Package name: enbd
Version : 2.4.32+2.4.33pre-1
Upstream Author : Peter T. Breuer <[EMAIL PROTECTED]>
* URL : http://www.it.uc3m.es/ptb/nbd/
* License : GPL
Package: otrs
Version: 2.0.4p01-1
Severity: important
In the default OTRS configuration, the Package Manager complains about
not having enough permissions on the OTRS home directory (whatever that
may be).
It turns out, the OTRS home directory is /usr/share/otrs on Debian, but
some files are store
Package: flyspray
Version: 0.9.8-5
Severity: important
Flyspray from unstable (currently 0.9.8-5) depends on phpapi, which obviously
isn't correct. phpapi is (AFAIK) only used by PHP modules, but correct me if
I'm wrong!
Cheers and keep up the good work,
--Bas
-- System Information:
Debian Rel
Package: cyrus-common
Version: 1.5.19-20
This afternoon, I decided to purge cyrus-common (while cyrus21-common
was installed, up and running) which ended up in deleting
/var/spool/cyrus/mail without confirming this to the user. Especially
when this directory is used by another package (like cyrus2
45 matches
Mail list logo
