Bug#245423: /sbin is always changed directly after doing a aide --update
user [EMAIL PROTECTED] usertags #245423 close-20070331 thanks On Tue, Dec 12, 2006 at 04:18:25PM +0100, Marc Haber wrote: > After going through another update round, changing both upstream aide > and the aide cron job, can you guys please re-try with aide 0.13 from > Debian testing (it backports nicely if you're running stable) and > gzip_dbout enabled? > > I would really like to know if we finally catched this issue. Since no negative feedback was received, I have now flagged this bug to be closed by the end of March 2007. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#245423: /sbin is always changed directly after doing a aide --update
On Tue, Dec 12, 2006 at 04:18:25PM +0100, Marc Haber wrote: > After going through another update round, changing both upstream aide > and the aide cron job, can you guys please re-try with aide 0.13 from > Debian testing (it backports nicely if you're running stable) and > gzip_dbout enabled? I was unable to reproduce the problem with 0.13.1-2 on my test system. It fixes the problem for me... -- William Aoki KD7YAF[EMAIL PROTECTED]5-1924 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#245423: /sbin is always changed directly after doing a aide --update
On Fri, Apr 23, 2004 at 01:54:57PM +1000, Pete de Zwart wrote: > After doing a: > > aide --update > > mv /var/lib/aide/aide.db.new /var/lib/aide.db > > aide --check > > All the files in /sbin are declared as "added", which seems a bit odd, > sometimes a further --update cycle will fix it, sometime the DB needs to be > initialised again. During further debugging, this was tracked down to gzip_dbout=yes being set in the Debian configuration. After going through another update round, changing both upstream aide and the aide cron job, can you guys please re-try with aide 0.13 from Debian testing (it backports nicely if you're running stable) and gzip_dbout enabled? I would really like to know if we finally catched this issue. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#245423: /sbin is always changed directly after doing a aide --update
On Fri, Jul 28, 2006 at 03:11:07PM -0600, Will Aoki wrote: > It took me a while (the problem mysteriously disappeared for a while on > my machines that still use aide), but here's the output. The changes > (/var/cfengine, et cetara) are correct, but the additions are not. > $ sudo aide --compare --before='database_new=file:///var/lib/aide/aide.db.new' > Not enough parameters in db:143132 Can you please check if line 143132 of the database is actually mangled? If so, please disable gzip_dbout and try to reproduce the issue. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#245423: /sbin is always changed directly after doing a aide --update
On Mon, Mar 13, 2006 at 09:13:01AM +0100, Richard van den Berg wrote:
> Last week I saw something similar on one of my systems. The problem was
> with my aide.db.gz being corrupted (bad block on fd0). I don't think the
> same issue applies here, but it might have to do with aide not reading
> in the old database completely. Running a --compare manually after the
> --update has triggered the problem would be interesting. Maybe this
> gives us a reproducible test case without the need for an image of the
> whole system.
It took me a while (the problem mysteriously disappeared for a while on
my machines that still use aide), but here's the output. The changes
(/var/cfengine, et cetara) are correct, but the additions are not.
Process:
$ sudo aide -u | less
[ lots of output]
$ sudo cp /var/lib/aide/aide.db{.new,}
$ sudo aide --compare --before='database_new=file:///var/lib/aide/aide.db.new'
Not enough parameters in db:143132
AIDE found differences between the two databases!!
Start timestamp: 2006-07-28 14:31:40
Summary:
Total number of files:143529
Added files: 402
Removed files:0
Changed files:14
---
Added files:
---
added:/lib/security/pam_lastlog.so
added:/lib/security/pam_listfile.so
added:/lib/security/pam_mail.so
added:/lib/security/pam_permit.so
added:/lib/security/pam_rhosts_auth.so
added:/lib/security/pam_rootok.so
added:/lib/security/pam_stress.so
added:/lib/security/pam_time.so
added:/lib/security/pam_warn.so
added:/lib/security/pam_access.so
added:/lib/security/pam_deny.so
added:/lib/security/pam_filter.so
added:/lib/security/pam_group.so
added:/lib/security/pam_limits.so
added:/lib/security/pam_nologin.so
added:/lib/security/pam_securetty.so
added:/lib/security/pam_shells.so
added:/lib/security/pam_tally.so
added:/lib/security/pam_wheel.so
added:/lib/security/pam_unix.so
added:/lib/security/pam_userdb.so
added:/lib/security/pam_motd.so
added:/lib/security/pam_mkhomedir.so
added:/lib/security/pam_issue.so
added:/lib/security/pam_unix_acct.so
added:/lib/security/pam_unix_passwd.so
added:/lib/security/pam_unix_auth.so
added:/lib/security/pam_unix_session.so
added:/lib/security/pam_krb5.so
added:/lib/security/pam_ldap.so
added:/lib/security/pam_debug.so
added:/lib/iptables/libipt_standard.so
added:/lib/iptables/libipt_tcp.so
added:/lib/iptables/libipt_udp.so
added:/lib/iptables/libipt_icmp.so
added:/lib/iptables/libipt_mac.so
added:/lib/iptables/libipt_limit.so
added:/lib/iptables/libipt_MASQUERADE.so
added:/lib/iptables/libipt_REJECT.so
added:/lib/iptables/libipt_LOG.so
added:/lib/iptables/libipt_unclean.so
added:/lib/iptables/libipt_state.so
added:/lib/iptables/libipt_multiport.so
added:/lib/iptables/libipt_tos.so
added:/lib/iptables/libipt_TOS.so
added:/lib/iptables/libipt_mark.so
added:/lib/iptables/libipt_MARK.so
added:/lib/iptables/libipt_owner.so
added:/lib/iptables/libipt_SNAT.so
added:/lib/iptables/libipt_DNAT.so
added:/lib/iptables/libipt_IPV4OPTSSTRIP.so
added:/lib/iptables/libipt_REDIRECT.so
added:/lib/iptables/libipt_MIRROR.so
added:/lib/iptables/libipt_SAME.so
added:/lib/iptables/libipt_TCPMSS.so
added:/lib/iptables/libipt_TTL.so
added:/lib/iptables/libipt_ULOG.so
added:/lib/iptables/libipt_ah.so
added:/lib/iptables/libipt_esp.so
added:/lib/iptables/libipt_tcpmss.so
added:/lib/iptables/libipt_ttl.so
added:/lib/iptables/libipt_ipv4options.so
added:/lib/iptables/libipt_NETMAP.so
added:/lib/iptables/libip6t_ipv6header.so
added:/lib/iptables/libipt_length.so
added:/lib/iptables/libipt_mport.so
added:/lib/iptables/libipt_nth.so
added:/lib/iptables/libipt_pkttype.so
added:/lib/iptables/libipt_pool.so
added:/lib/iptables/libipt_POOL.so
added:/lib/iptables/libipt_psd.so
added:/lib/iptables/libipt_quota.so
added:/lib/iptables/libipt_random.so
added:/lib/iptables/libipt_realm.so
added:/lib/iptables/libipt_time.so
added:/lib/iptables/libip6t_tcp.so
added:/lib/iptables/libip6t_udp.so
added:/lib/iptables/libip6t_icmpv6.so
added:/lib/iptables/libip6t_standard.so
added:/lib/iptables/libip6t_MARK.so
added:/lib/iptables/libip6t_mark.so
added:/lib/iptables/libip6t_LOG.so
added:/lib/iptables/libip6t_REJECT.so
added:/lib/iptables/libip6t_multiport.so
added:/lib/iptables/libip6t_length.so
added:/lib/iptables/libip6t_owner.so
added:/lib/iptables/libip6t_limit.so
added:/lib/iptables/libip6t_mac.so
added:/lib/iptables/libipt_CONNMARK.so
added:/lib/iptables/libip6t_condition.so
added:/lib/iptables/libipt_dscp.so
added:/lib/iptables/libipt_connlimit.so
added:/lib/iptables/libipt_ecn.so
added:/lib/iptables/libipt_helper.so
added:/lib/iptables/libipt_iprange.so
added:/lib/iptables/libipt_physdev.so
added:/lib/iptables/libipt_DSCP.so
added:/lib/iptables/libipt_ECN.so
added:/lib/iptables/libipt_rpc.so
added:/lib/iptables/libipt_sctp.so
added:/lib/iptables/libipt_CLASSIFY.so
added:/lib/iptables/libipt_NOTRACK.so
added:/lib/iptables/libipt_connmark.
Bug#245423: /sbin is always changed directly after doing a aide --update
An update basically is an --init with a --compare to the old database. When aide does a compare, it builds a tree for the new db, and removes all files from the old db from that tree (and checks if they should be reported as changed). When that process has finished, all files still in the tree are reported as added. So for some reason, aide fails to remove the /sbin files from the new tree. Last week I saw something similar on one of my systems. The problem was with my aide.db.gz being corrupted (bad block on fd0). I don't think the same issue applies here, but it might have to do with aide not reading in the old database completely. Running a --compare manually after the --update has triggered the problem would be interesting. Maybe this gives us a reproducible test case without the need for an image of the whole system. Sincerely, Richard van den Berg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
