Hi, The file debian/aide.conf.d/31_aide_apt-file (in the source package) contains code that lists files in the apt-file cache. In apt-file 3, this cache has been removed (merged with APT regular cache) and accordingly this file may need to be updated. Thanks, ~Niels
Hi Niels, would you be interested in shipping your own aide rules in /etc/aide.conf.d/31_apt-file_apt-file? That way you could change them yourself. We would, in turn, remove /etc/aide/aide.conf.d/31_aide_apt-file from the aide package. This is actually the way the Debian aide team would prefer packages to interface with aide - who knows better about which files a package needs to touch than its maintainer? If you'd prefer to keep the /etc/aide/aide.conf.d/31_aide_apt-file in our turf, please let us know. Greetings Marc
Marc Haber: Hi Marc, Thanks for the offer, but I think it will be unnecessary. AFAICT (after figuring out what aide is), then the default rule for apt should now cover apt-file's default setup as well. At least it is implemented based on apt's "apt-get indextargets". So the /etc/aide/aide.conf.d/31_aide_apt-file file is probably redundant with apt-file 3. Thanks, ~Niels
So we can simply remove it? Greetings Marc
So we can simply remove it? Greetings Marc
9Marc Haber: Hi Marc, You would be able to, if [31_aide_apt] used apt-get indextargets to find all files that apt downloads. :) That file will need updates to support compressed indices and deb822 sources.list files (@cc deity so they are aware of that as well). Thanks, Niels [31_aide_apt]: https://anonscm.debian.org/cgit/pkg-aide/aide.git/tree/debian/aide.conf.d/31_aide_apt
9Marc Haber: Hi Marc, You would be able to, if [31_aide_apt] used apt-get indextargets to find all files that apt downloads. :) That file will need updates to support compressed indices and deb822 sources.list files (@cc deity so they are aware of that as well). Thanks, Niels [31_aide_apt]: https://anonscm.debian.org/cgit/pkg-aide/aide.git/tree/debian/aide.conf.d/31_aide_apt
Control: clone -1 -2 Control: severity -2 important Control: retitle -2 31_aide_apt uses apt internals Control: user deity@lists.debian.org Control: usertag -2 apt-internals Whatever that's doing it seems broken. It does not support compressed indexes, nor will it work if we suddenly change some filenames, for example, because if we moved to a hash based layout. I announced to do the former this month, see <20170909144829.ulxdkz6w2awnja7e@jak-x230> for details.
tags #879272 wontfix I understand that this is a knee-jerk response of the apt maintainers. The aide rule for apt NEEDS to "use" apt internals so that aide can avoid creating false alarms for files that apt changes. To report unexpected changes in files, it needs to know which files are expected to change. The aide maintainers are aware that aide will always be "behind" the packages, but since maintainers don't bother to tell aide beforehand when they change their package layout, this is something that cannot be avoided. We are trying to stay current especially for a package as important as apt, but of course that does not always work. The only way to stop aide from "using" apt internals this way would be to have apt ship an /etc/aide/aide.conf.d/31_apt_apt file containing current rules reflecting the files that apt regularly changes on updates. Please indicate whether you want to do that in future, and we will happily remove our own apt rule from aide. Until this has been sorted out, we need to continue shipping a rule "using" apt internals with aide, hence the "wontfix" tag. Greetings Marc
tags #879272 wontfix I understand that this is a knee-jerk response of the apt maintainers. The aide rule for apt NEEDS to "use" apt internals so that aide can avoid creating false alarms for files that apt changes. To report unexpected changes in files, it needs to know which files are expected to change. The aide maintainers are aware that aide will always be "behind" the packages, but since maintainers don't bother to tell aide beforehand when they change their package layout, this is something that cannot be avoided. We are trying to stay current especially for a package as important as apt, but of course that does not always work. The only way to stop aide from "using" apt internals this way would be to have apt ship an /etc/aide/aide.conf.d/31_apt_apt file containing current rules reflecting the files that apt regularly changes on updates. Please indicate whether you want to do that in future, and we will happily remove our own apt rule from aide. Until this has been sorted out, we need to continue shipping a rule "using" apt internals with aide, hence the "wontfix" tag. Greetings Marc
I don't see why you can't just query apt for locations and which files
there are. We have tools for that.
apt-get indextargets can tell you all compressed (or uncompressed) index file
names (but not pdiffs or Release files, so you can add them). So, just
add all of apt-get indextargets --format '$(FILENAME)' to the list of
variable files? (this gives you Packages, Sources, and Contents,
Translations, and other index files with correct compressors). You could
also strip compressors from that name (see the KEEPCOMPRESSEDAS field),
and then append .IndexDiff to handle pdiffs. This also solves the apt-file
problem.
Per-component release files as in
echo "$LISTSDIR/${HOST}${HOSTPATH}_dists_${dist}_${c}_source_(Sources|Release)$ VarFile"
are not fetched, so drop that?
Preferably also don't hardcode /var/lib/apt/lists and friends, but use
eval $(apt-config shell VARDIR Dir::State/d)
eval $(apt-config shell LISTSDIR Dir::State::Lists/d)
eval $(apt-config shell VARDIR Dir::Cache/d)
eval $(apt-config shell CACHEDIR Dir::Cache::Archives/d)
eval $(apt-config shell LOGDIR Dir::Log/d)
So you actually check the directories apt uses if they have been
reconfigured.
You also do some parsing or something of sources.list files, does that
work with deb822-style sources files?
Nah, that stuff is too nasty.
I don't see why you can't just query apt for locations and which files
there are. We have tools for that.
apt-get indextargets can tell you all compressed (or uncompressed) index file
names (but not pdiffs or Release files, so you can add them). So, just
add all of apt-get indextargets --format '$(FILENAME)' to the list of
variable files? (this gives you Packages, Sources, and Contents,
Translations, and other index files with correct compressors). You could
also strip compressors from that name (see the KEEPCOMPRESSEDAS field),
and then append .IndexDiff to handle pdiffs. This also solves the apt-file
problem.
Per-component release files as in
echo "$LISTSDIR/${HOST}${HOSTPATH}_dists_${dist}_${c}_source_(Sources|Release)$ VarFile"
are not fetched, so drop that?
Preferably also don't hardcode /var/lib/apt/lists and friends, but use
eval $(apt-config shell VARDIR Dir::State/d)
eval $(apt-config shell LISTSDIR Dir::State::Lists/d)
eval $(apt-config shell VARDIR Dir::Cache/d)
eval $(apt-config shell CACHEDIR Dir::Cache::Archives/d)
eval $(apt-config shell LOGDIR Dir::Log/d)
So you actually check the directories apt uses if they have been
reconfigured.
You also do some parsing or something of sources.list files, does that
work with deb822-style sources files?
Nah, that stuff is too nasty.
While I fully understand the issue, I am reluctant to automatically generate configuration like that. I admit that the aide package is somewhat inconsistent to itself here, regarding apt and other packages, and I do understand that apt is special here since it is present on each and every Debian system. Given the available time frame, I am however satisfied enough with the 60-of-100 accopmlishment that we currently have, and believe that we're doing "good enough" a service by catering for apt's default configuration. We place the burden of adapting aide's configuration to the local admin when she feels it necessary to configure apt to use other layouts etc. I really appreciate apt's flexibility and your efforts, but I don't think that aide needs to show the same automatic flexibility level. Its reports are only useful to an experienced admin anyway. Done. Committed. We are not checking them, we are excluding them from being checked. And the hard-coded path in the aide rules will hopefully make it more obvious when apt's configuration has been changed accidentally. Of course not :-( Fair enough. Then it's wontfix. Sorry about that. No offense intended. Greetings Marc
While I fully understand the issue, I am reluctant to automatically generate configuration like that. I admit that the aide package is somewhat inconsistent to itself here, regarding apt and other packages, and I do understand that apt is special here since it is present on each and every Debian system. Given the available time frame, I am however satisfied enough with the 60-of-100 accopmlishment that we currently have, and believe that we're doing "good enough" a service by catering for apt's default configuration. We place the burden of adapting aide's configuration to the local admin when she feels it necessary to configure apt to use other layouts etc. I really appreciate apt's flexibility and your efforts, but I don't think that aide needs to show the same automatic flexibility level. Its reports are only useful to an experienced admin anyway. Done. Committed. We are not checking them, we are excluding them from being checked. And the hard-coded path in the aide rules will hopefully make it more obvious when apt's configuration has been changed accidentally. Of course not :-( Fair enough. Then it's wontfix. Sorry about that. No offense intended. Greetings Marc