User-Agent: Build Identifier: From IT#54302: I've discovered an isue concerning updatedb.updatedb seems to collect /.automount/blablabla files and records them in it's database. The /etc/cron.daily/slocate.cron file contains: #!/bin/sh renice +19 -p $$ >/dev/null 2>&1 /usr/bin/updatedb -f "nfs,smbfs,ncpfs,proc,devpts" -e "/tmp,/var/tmp,/usr/tmp,/afs,/net" One would think that the "nfs" and "/net" types would be ignored as expected. The database does indeed NOT include any found files BEGINNING with /net but the database doe contain found files beginning with /.automount EVEN though these are files found over nfs filesystems. With potentially hundreds of mounts being established on a machine and that creating the possibility of thousands if not hundreds of thousounds of files to be recoreded into the updatedb database; this database coulld grow rather large. The size of the database I'm not too worried about. I'm more worried about hundreds if not thousands of machines (especially as we deploy more and more RHEL nodes) all collecting the same data at the same time. This'll create a network burst that potentially could disrupt nightly work related traffic. Also network monitoring teams taking notice and deciding to shut off switches to curve any network bursts that may occur. These network teams may insist that there is a volunerabilty hack occurring. W don't want them thinking security vulnerabilities of Red Hat linux do we ;-) ? I'm more concerned though about the tool itself allowing these nfs mounted filess to be collected even though the default configuration tells updatedb to skip nfs filesystems. Reproducible: Always Steps to Reproduce: 1.Check the slocate database 2. 3. Actual Results: it can contain .automount files Expected Results: Shouldn't have nfs files in the database Suggest changing slocate.cron to contain: /usr/bin/updatedb -f "nfs,smbfs,ncpfs,proc,devpts" -e "/tmp,/var/tmp,/usr/tmp,/afs,/net,/.automount" This is similar to the problem described here: http://www.redhat.com/archives/redhat-list/1999-July/msg00425.html
More from the Issue - simply adding /.automount won't solve the problem. -------------- But we are still seeing this issue. With further investigation this is how I believe we're seeing this issue. We have: /etc/auto-master CONTAINS /opt/corp/lb /etc/auto_loadbuild Directories exists as: /opt/corp -> /opt/soe /opt/soe/lb AS SUCH /opt/corp/lb exists and satisfies the auto map. A request is made for /opt/corp/lb/blablabla and the mount is established with an entry recorded in the /etc/mtab file as /opt/corp/lb/blablabla updatedb runs and correctly skips the /opt/corp/* stuff because of the entry in slocate.cron :: the added /opt/corp to the dash 'e' (-e) list. updatedb has not been told to skip /opt/soe stuff but was told to skip nfs filesystems. updatedb traverses /opt/soe and ends up recording everything (EVERYTHING even thrugh nfs) it finds there. However /opt/soe/lb is a mounted filesystem; WELL actually /opt/corp/lb is the mounted filesystem recorded in mtab but corp links to soe and soe actually owns the lb directory which got mounted. So updatedb's syntax to exlude nfs has been circumvented. This I think is a bug and in our environment needlessly causes network storms (of light weight data mind you:: just file names not file contents) traffic, performance issues with each machine that runs updatedb and also huge slocate.db files (as seen above 225Mg) [snip] Here is an update of this issues events this weekend after I removed the link entry "/opt/corp" from slocate.cron and replaced it with the directory enry /opt/soe Again the link /opt/corp points at /opt/soe [snip] NOTCIE the size [of the database] is now only 2.8Mg as opposed to 225Mg. [snip] SOCATE.CRON FILE LOOKS LIKE: [root@wcary468 cron.daily]# cat slocate.cron #!/bin/sh renice +19 -p $$ >/dev/null 2>&1 /usr/bin/updatedb -f "nfs,mvfs,smbfs,ncpfs,proc,devpts" -e "/tmp,/var/tmp,/usr/tmp,/afs,/net,/.automount,/opt/soe" [root@wcary468 cron.daily]# So it seems having a 'link name' in a 'mount path' can circumvent the checks for nfs mounted file systems that updatedb performs (whatever the nature of that check is).
*** Bug 144921 has been marked as a duplicate of this bug. ***
problem is that a symbolic link can hide an NFS mount from updatedb. For example, if /a/b is an NFS mount point and /a/linktob is a symbolic link to /a/b, updatedb will correctly NOT go down /a/b, but it will go down /a/linktob because it does not detect it as an NFS mount, presumably because the /a/linktob path is not in its list of NFS mounts. Will this fix prevent slocate from traversing nfs mounts that are symlinked?
AFAICS, the scenario in comment #10 should not be a problem simply because updatedb never follows symbolic links to directories. The scenario in comment #2 indeed looks possible, but that's only because amd incorrectly writes a non-canonical path to /etc/mtab; mount(8) writes only paths with no symbolic links there. Steve, please file a separate bug against am-utils about this behavior; I'm sorry I have not noticed this earlier.
(In reply to comment #11) > The scenario in comment #2 indeed looks possible, but that's only because amd > incorrectly writes a non-canonical path to /etc/mtab; mount(8) writes > only paths with no symbolic links there. Steve, please file a separate > bug against am-utils about this behavior; I'm sorry I have not noticed > this earlier. Sorry again... it seems autofs has (had?) a similar problem, so slocate should handle symlinks in /etc/mtab correctly. It will be fixed together with the other automounting issues.
We're seeing this happen when slocate accesses a symlink to an nfs mount point.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2005-345.html
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2005-346.html