Package: postfix
Version: 2.7.1-1~bpo50+1
Severity: normal
I have permit_mynetworks before reject_unauth_pipelining in my
main.cf file. Despite this, postfix logs an entry about improper
pipelining when a mail client doesn't wait for a response before
sending the next command.
As soon as I upgr
MRTG doesn't work at all in daemon mode, and hasn't for over a year.
This is a problem for me. What can I do to increase the visibility of
this problem?
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.de
I am having this problem on more than one machine. MRTG in daemon mode
on my server at home hasn't worked since September 18, 2004.
No activity in five months. Any idea what's wrong?
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Troubl
On 9/7/2012 8:36 PM, Shawn Heisey wrote:
I am having this problem on more than one machine. MRTG in daemon
mode on my server at home hasn't worked since September 18, 2004.
I meant 2011, not 2004.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subje
Package: linux-2.6
Version: 2.6.32-48squeeze4
Severity: important
This is a continuation of archived bug number 596390. The problem has
never been solved. I have a workaround that I consider unsatisfactory.
With everything set to auto-negotiate, and starting from a powered off
system, the NIC h
On 10/12/2013 8:52 PM, Ben Hutchings wrote:
> In this original broken configuration, were there any ethtool settings
> in /etc/network/interfaces ?
>
> Is the firmware-realtek package installed?
>
> Can you provide the boot log messages from r8169
> (grep r8169/var/log/dmesg) ?
When I first set
I left out the answer to one of your questions. Yes, the
firmware-realtek package is installed. It is version 0.28+squeeze1.
During my temporary 3.2 backports kernel experiment, I also upgraded all
the firmware packages to the matching version from backports.
This may be indirectly significant -
On 10/13/2013 11:42 AM, Ben Hutchings wrote:
> - There is no firmware patch for your LAN-on-motherboard chip
> (RTL8168B).
>
> - There is a firmware patch for the chip on the PCIe card (RTL8168D),
> but this was never included in the driver in Debian kernels (except in
> some experimental versions
Package: mrtg
Version: 2.16.3-3
Severity: important
*** Please type your report below this line ***
I had a working configuration. The other day I discovered that none of
my MRTG
graphs had updated since last year, specifically on September 14, 2011. I am
running in daemon mode. I have reduc
Here is some strace output. I have redacted part of the domain name.
There was a few minutes between the restart_syscall line and the rest of
it. I do not have an index.html in /var/www/mrtg ... what's in there is
the index.php for a simple app that lists the index files created by
indexmake
On 3/20/2012 6:12 PM, Adam Majer wrote:
On Tue, Mar 20, 2012 at 04:29:42PM -0600, Shawn Heisey wrote:
Here is some strace output. I have redacted part of the domain
name. There was a few minutes between the restart_syscall line and
the rest of it. I do not have an index.html in /var/www/mrtg
On 3/20/2012 10:38 PM, Adam Majer wrote:
You seem to be passing "Workdir: /var/www/mrtg". Your complaint seems
to be centred around the issue that /var/www/mrtg/* does not contain
the WorkDir does not exist, but this is the configuration file that
will be created in slcigw1.cfg What WorkDir is
Pastebin of full slcigw1.cfg, with certain information redacted. The
slcigw2.cfg file is similar, but has a slightly different complement of
interfaces:
http://pastebin.com/Jy6hjzZd
Commands to show files and permissions:
mcp:/etc/mrtg# ls -al slcigw*
-rw-r- 1 root mrtg 7702 Mar 20 10:4
I can confirm that this is a problem with Daemon mode. I shut the
daemon down, added two lines to /etc/cron.d/mrtg, and it's working.
*/5 * * * * rootif [ -x /usr/bin/mrtg ] && [ -r
/etc/mrtg/slcigw1.cfg ]; then env LANG=C /usr/bin/mrtg
/etc/mrtg/slcigw1.cfg 2>&1 | tee -a /var/log/mrt
Package: ldirectord
Version: 1.0.3-4
When ldirectord does https health checks, they fail because newer LWP
versions validate the hostname used against the hostname in the
certificate, and ldirectord is almost always configured with IP addresses.
The simple fix for this is here:
https://github.co
I just checked the git page for the project, and that commit was made in
Oct 2013, but the latest release (3.9.5) was made Feb 2013, so I guess
it's not very weird that Debian and Ubuntu don't have the fix yet.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject
On 11/20/2014 12:22 PM, Kurt Roeckx wrote:
> This fix is just plain wrong and you might as well stop using
> HTTPS in that case. Please fix the certificate instead. It can
> contain IP addresses just as well as hostnames. It's recommended
> to use the SubjectAltName, but you can put it in the CN
On 11/20/2014 1:59 PM, Salvatore Bonaccorso wrote:
> Note that this is #739608, and already fixed both in wheezy and
> jessie.
Thanks for the info. The problem remains in Ubuntu 14, should I file a
bug against their package?
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
I've filed that Ubuntu bug.
https://bugs.launchpad.net/ubuntu/+source/resource-agents/+bug/1394759
Looks like all that's needed here is getting the package in sid patched.
Thanks,
Shawn
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trou
Package: logcheck-database
Version: 1.2.54
Severity: normal
Tags: patch
When views are used in bind, the logcheck filters don't catch the common
informational log messages.
Added regex bits to the filter definitions.
-- System Information:
Debian Release: 4.0
APT prefers stable
APT policy:
Package: linux-2.6
Version: 2.6.32-20~bpo50+1
Severity: important
WHen I boot this kernel, my ethernet port stops working. The light on
the switch goes out. It is a Cisco 3550 switch with 10 10/100/1000 ports
and two GBIC ports. This server is plugged into a 10/100/1000 port.
In order to get
On 9/10/2010 4:57 PM, Ben Hutchings wrote:
Please test a newer version. There was a bug fix to r8169 in version
2.6.32-16 which might address this.
I was already on the -20 version. Then I tried the -21 recently added
to the backports archive, with no change.
After a little experimentati
On 11/20/2010 11:55 AM, Ben Hutchings wrote:
Try 'mii-tool -vv eth0'?
New output. Just in case, I tried it with a third and fourth v, no
difference. This is with it hard-set to 100 full, I can do it with it
set to auto when I get home.
frodo:~# mii-tool -vv eth0
Using SIOCGMIIPHY=0x8947
e
Package: xymon
Version: 4.3.0~beta2.dfsg-5~bpo50+1
Severity: normal
I cannot zoom on Xymon's graphs. Similar problems have been reported on
the mailing list for the upstream package. Neither of the fixes mentioned
in the URLs below is working for me, even when implemented together.
I am using F
Correction. The zoom does work, but you can't tell that it is working,
or exactly what you're going to get.
The cursor does not change to a cross when over the zoomable area. When
you drag the mouse in that area, you don't see a rectangle, it looks
like you're doing drag/drop with the image.
Package: mysql-server-5.1
Version: 5.1.44-3~bpo50+1
Severity: normal
mysql-zrm complained with an error from mysqlhotcopy:
dailyrun:backup:ERROR: Output of command: 'mysqlhotcopy' is {
DBD::mysql::db do failed: You can't use locks with log tables. at
/usr/bin/mysqlhotcopy line 452.
}
Here is t
Package: psmisc
Version: 22.3-1
Severity: important
I cannot seem to get fuser to report the PID of a process listening on
a given TCP port (9100). I'm trying to port a script used on a redhat
system. If I use lsof, I can see the information:
bigindy0:~# lsof | grep 9100
java 29196eas
Very strange. I had already tried port 80 and got no results, but then
just for giggles I tried more ports and it actually worked when it hit
port 25:
bigindy0:~# fuser -n tcp 80
bigindy0:~# fuser -n tcp www
bigindy0:~# fuser -n tcp smtp
smtp/tcp: 3437
bigindy0:~# fuser -n tcp 25
2
The Sun JVM that is listening on port 9100 is a 32-bit version bundled
with the software (Progress EasyAsk), but that doesn't explain why
apache2 and openssh-server are not working either, as they are the
standard 64-bit packages.
bigindy0:~# /opt/easyask/jre/bin/java -version
java version "1
On 9/11/2010 8:15 PM, Ben Hutchings wrote:
Please try this while running kernel version 2.6.32:
1. Enable additional error logging by running: ethtool -s eth0 msglvl 0x3f
2. Enable autoneg again
3. Disconnect and reconnect the cable
4. Check for any new error messages in the kernel log
Also send
On 11/20/2010 10:20 AM, Shawn Heisey wrote:
Unknown RealTek chip (mask: 0x2800)
I found what looks like a bug report and resolution for this same chip
and problem in FreeBSD.
http://www.pubbs.net/200904/netbsd/15177-50rc3-messed-up-rtl8111dl-onboard-nic.html
I know there are licensing
31 matches
Mail list logo
