Bug#897139: bind9: named periodically logs large number of "error sending response: permission denied" lines
Package: bind9 Version: 1:9.11.3+dfsg-1 Severity: normal Dear Maintainer, Periodically, I see large number of "permission denied" log lines showing up in various logs: Apr 28 15:07:22 fidelity named[879]: client @0xb23daa80 10.0.5.255#61981 (gs-loc.apple.com): error sending response: permission denied Apr 28 15:07:23 fidelity named[879]: client @0xb313a730 10.0.5.255#61981 (gs-loc.apple.com): error sending response: permission denied Apr 28 15:07:25 fidelity named[879]: client @0xb2318e40 10.0.5.255#61981 (gs-loc.apple.com): error sending response: permission denied Apr 28 15:07:29 fidelity named[879]: client @0xb075cb10 10.0.5.255#61981 (gs-loc.apple.com): error sending response: permission denied Apr 28 15:07:35 fidelity named[879]: client @0xb0754d40 10.0.5.255#55290 (p31-fmip.icloud.com): error sending response: permission denied Apr 28 15:07:37 fidelity named[879]: client @0xb1d94c80 10.0.5.255#61981 (gs-loc.apple.com): error sending response: permission denied Apr 28 15:08:07 fidelity named[879]: client @0xb1d431f0 10.0.5.255#51460 (p31-fmip.icloud.com): error sending response: permission denied Apr 28 15:08:08 fidelity named[879]: client @0xb1d431f0 10.0.5.255#51460 (p31-fmip.icloud.com): error sending response: permission denied Apr 28 15:08:10 fidelity named[879]: client @0xb1d431f0 10.0.5.255#51460 (p31-fmip.icloud.com): error sending response: permission denied Apr 28 15:08:14 fidelity named[879]: client @0xb1d431f0 10.0.5.255#51460 (p31-fmip.icloud.com): error sending response: permission denied Apr 28 15:08:38 fidelity named[879]: client @0xb1d6c430 10.0.5.255#51460 (p31-fmip.icloud.com): error sending response: permission denied Apr 28 15:08:47 fidelity named[879]: client @0xb237dab0 10.0.5.255#50319 (www.icloud.com): error sending response: permission denied Apr 28 15:08:47 fidelity named[879]: client @0xb23e0a60 10.0.5.255#56916 (apple.com): error sending response: permission denied It doesn't seem to negatively impact named's ability to function. It started happening around April 9th, 2018 but I had not done any significant upgrades around that time. (I upgraded the bind9 package on March 28). I can resolve the relevant domains listed above with no difficulty. When I review the last month's worth of the data, they appear to be centered around Apple domains. Here's a breakdown from a representative day: 61 (init-p01st.push.apple.com): 54 (www.icloud.com): 54 (apple.com): 45 (gs-loc.apple.com): 41 (push.apple.com): 16 (mesu.apple.com): 14 (p31-fmip.icloud.com): Happy to run more diagnostics on my side. thank you! -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 4.15.0-2-686-pae (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages bind9 depends on: ii adduser3.117 ii bind9utils 1:9.11.3+dfsg-1 ii debconf [debconf-2.0] 1.5.66 ii libbind9-160 1:9.11.3+dfsg-1 ii libc6 2.27-2 ii libcap21:2.25-1.2 ii libcom-err21.44.0-1 ii libdns1100 1:9.11.3+dfsg-1 ii libgeoip1 1.6.12-1 ii libgssapi-krb5-2 1.16-2 ii libisc169 1:9.11.3+dfsg-1 ii libisccc1601:9.11.3+dfsg-1 ii libisccfg160 1:9.11.3+dfsg-1 ii libjson-c3 0.12.1-1.3 ii libk5crypto3 1.16-2 ii libkrb5-3 1.16-2 ii liblmdb0 0.9.21-1 ii liblwres1601:9.11.3+dfsg-1 ii libssl1.1 1.1.0g-2 ii libxml22.9.4+dfsg1-6.1 ii lsb-base 9.20170808 ii net-tools 1.60+git20161116.90da8a0-2 ii netbase5.4 bind9 recommends no packages. Versions of packages bind9 suggests: pn bind9-doc ii dnsutils1:9.11.3+dfsg-1 pn resolvconf pn ufw -- Configuration Files: /etc/apparmor.d/local/usr.sbin.named changed [not included] /etc/bind/db.local changed [not included] /etc/bind/named.conf.local changed [not included] /etc/bind/named.conf.options changed [not included] -- debconf information: bind9/different-configuration-file: bind9/start-as-user: bind bind9/run-resolvconf: true
Bug#883022:
I'm seeing a similar issue: Feb 18 12:02:12 fidelity kernel: [ 55.945224] audit: type=1400 audit(1518984132.951:11): apparmor="DENIED" operation="open" profile="/usr/sbin/ntpd" name="/usr/local/sbin/" pid=2474 comm="ntpd" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 Feb 18 12:02:12 fidelity kernel: [ 55.945230] audit: type=1400 audit(1518984132.951:12): apparmor="DENIED" operation="open" profile="/usr/sbin/ntpd" name="/usr/local/bin/" pid=2474 comm="ntpd" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 I think that part of the problem is that I have /usr/local in my path: # ps ax | grep ntp ntp 2563 0.0 0.1 10020 3044 ?Ssl 12:02 0:00 /usr/sbin/ntpd -p /var/run/ntpd.pid -g -u 111:113 # cat /proc/2563/environ JOURNAL_STREAM=9:19427PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/binINVOCATION_ID=5defcd39b2f748c39d7b90e20b4f2469LANG=en_USPWD=/ so I assume that it's searching the path for a binary. the /usr/local bit is defined in /etc/profile it works for me, so not going to worry about it for now.
Bug#511715: gallery3 Debian package
/etc/gallery3/apache.conf has the /gallery3 alias disabled by default - for testing purposes you'll most likely want to uncomment out the alias and restart apache. Ok, I've got it installed. Some notes: 1) In the current state with the Alias disabled by default, it's not usable after installation and there are no instructions on how to make it usable. Why not enable the /gallery3 alias by default? 2) After enabling the /gallery3 alias it then takes me to the installer, which it should not have to. There's enough information there for the debian package to set it up automatically. A few notes on what we should be doing: - I don't like /var/lib/gallery3/g3data -- it's too close to g2data and is bound to cause some confusion. I think we should just use /var/lib/gallery3 as the directory and not have a subdir. - /usr/share/gallery3/var should be a symlink to /var/lib/gallery3 - The package installer should be doing the install as well. This is as easy as running: php5 /usr/share/gallery3/installer/index.php \ -u root \ -p mysql_root_pw \ -d gallery3 If you do those steps in the debian package, then after the package install is finished, Gallery 3 is ready to go at /gallery3, which is the desired result. Anything less than that will result in a ton of forum support for us, which is not what we want out of this. Upon upgrade, the package should run php5 index.php upgrade after installing new files and it's good to go. -Bharat -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#511715: ...time passes
On 1/10/2011 8:27 PM, Michael Schultheiss wrote: Bharat Mediratta wrote: It's been 3 months since the last activity on this bug. Can we please get this packaged? Michael, I am more than happy to beat the bushes to find a new maintainer but right now this seems to be going nowhere which is very frustrating. I apologize for the continued delays - I'll get the packaging finished ASAP. Michael, it's now been another 12 days which brings this to over two years that we've been waiting on you to make some progress on making a Debian package for Gallery 3. I'm gearing up to release Gallery 3.0.1 this weekend which means that Debian users have not had a package for the 3.0 release at all. I've asked nicely, sent polite pings, given plenty of notice and heard lots of promises but seen no results. This is very frustrating. In a week or so if I don't see any progress, I'm going to officially ask the broadest possible audience for somebody to take over packaging Gallery 3 for Debian. regards, -Bharat -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#511715: ...time passes
On 1/22/11 10:58 PM, Michael Schultheiss wrote: Bharat Mediratta wrote: In a week or so if I don't see any progress, I'm going to officially ask the broadest possible audience for somebody to take over packaging Gallery 3 for Debian. The Debian packages for 3.0.1 were uploaded a few minutes ago. Since this is a new package, they will not be available in Debian Unstable until after the FTP Masters process the upload. I can host packages on people.debian.org in the meantime. Thanks, Michael. Roughly when will it show up in unstable? I'd love to test it out. -Bharat -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#511715: ...time passes
It's been 3 months since the last activity on this bug. Can we please get this packaged? Michael, I am more than happy to beat the bushes to find a new maintainer but right now this seems to be going nowhere which is very frustrating. thanks, -Bharat -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#511715: Ping
We're on the cusp of release Gallery 3.0 -- who should I talk to about getting this packaged up for Debian? Thanks! -Bharat -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#511715: Ping
On 9/6/2010 8:11 PM, Michael Schultheiss wrote: Bharat Mediratta wrote: We're on the cusp of release Gallery 3.0 -- who should I talk to about getting this packaged up for Debian? Thanks! I'm planning on packaging Gallery 3.0 for Debian as I've done with Gallery 1 and Gallery 2. Awesome, thanks Michael. Let me know how I can help. -Bharat -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#501066: chkrootkit: chkdirs called with wrong arguments
Package: chkrootkit Version: 0.48-5 Severity: important My nightly chkrootkit now gives this error: chkdirs [-n] dir ... chkdirs: Warning: Possible LKM Trojan installed If I run 'chkrootkit -x' I see that it's running chkdirs. Poking in the code, I see that it's going to run chkdirs with a series of directory arguments, so to simulate that I tried running it by hand: $ cd /usr/lib/chkrootkit $ ./chkdirs /tmp chkdirs [-n] dir ... Same error. Marked as important since this is going to spam anybody who's running chkrootkit in a daily sweep, and false securiy spam is bad news. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable') Architecture: powerpc (ppc) Kernel: Linux 2.6.26-1-powerpc Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/bash Versions of packages chkrootkit depends on: ii binutils2.18.1~cvs20080103-7 The GNU assembler, linker and bina ii debconf [debconf-2. 1.5.22 Debian configuration management sy ii libc6 2.7-13 GNU C Library: Shared libraries ii net-tools 1.60-20 The NET-3 networking toolkit ii procps 1:3.2.7-8/proc file system utilities chkrootkit recommends no packages. chkrootkit suggests no packages. -- debconf information: * chkrootkit/run_daily: true * chkrootkit/run_daily_opts: -q * chkrootkit/diff_mode: false -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#401649: crypt++el: cleartext data gets corrupted after unencryption
Package: crypt++el Version: 2.92-1 Severity: grave Justification: causes non-serious data loss I store my passwords in an encrypted file, and used crypt++el mode to edit them so that I don't have a plaintext version of sensitive data on disk. However, after typing in the password in Emacs, the unencrypted data has little changes scattered throughout the file. At first I thought I was making typos but if I fix the character, the exact same corruption happens again. This problem has been plaguing me for about a year on multiple boxes. I've been regularly upgrading XEmacs and crypt++el, to no avail. This bug is filed on the ppc platform, but I've also reproduced it on amd64. Please let me know Steps to reproduce: 1. Unpack http://www.menalto.com/.outgoing/debian/crypt++el-bug.zip 2. Run crypt test test.cry and see what the data should look like 3. Run xemacs test.cry and enter test as the password 4. See lines 5 and 8 are mangled like this: - low security: (no passwordB common^Ûsecure password: a0b1c2d3 (hopefully the special character between common and secure comes across in this bug report). If I had to take a wild guess at this, I'd say that it's something to do with emacs codepages. But I don't know enough to be sure and haven't spent enough time digging. This is a particularly scary problem though because if it makes a subtle corruption to one of my passwords (which are already random values) then I'll have a hard time figuring out and fixing it. ++ -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (990, 'testing') Architecture: powerpc (ppc) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-1-powerpc Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages crypt++el depends on: ii xemacs21-mule [emacsen] 21.4.19-1 highly customizable text editor -- crypt++el recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#222501: Can we close this bug?
This bug appears to be fixed in 2.92. Can we mark the bug as done so that it doesn't raise flags in apt-listbugs? Thanks. -Bharat -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#294012: php4-apd: phpapi revision requires a new upload in sid
Adam Conrad said on Mon, 07 Feb: Due to the simplicity and non-intrusiveness of these changes, if I don't see uploads in the next 24 hours, I will happily NMU to fix the affected packages. Adam, it's been a couple of weeks without an update on this from Jonathan. Would you please consider doing the NMU now? Thanks! -Bharat -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
