Date: Sun, 12 Jul 2015 17:44:39 -0400 From: Derek Schrock <dereks@lifeofadishwasher.com> To: Dan Busarow <dan@buildingonline.com> Cc: freebsd-questions@freebsd.org Subject: Re: freebsd-update and whatis Message-ID: <20150712214439.GA25794@ircbsd> In-Reply-To: <55A273D9.5080108@buildingonline.com> References: <20150712130057.45FA6BCFE10@alisocreek.buildingonline.net> <55A273D9.5080108@buildingonline.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Ran in the same problem and if anyone disagrees please correct me this
is all based off my observations.
Your whatis database file is being rebuilt on a weekly basis and your
system has some third party or orphaned base files.
/etc/periodic/weekly/320.whatis is ran on a weekly basis:
$ fgrep weekly /etc/crontab
# Perform daily/weekly/monthly maintenance.
15 4 * * 6 root periodic weekly
You can see this by running freebsd-update, 320.whatis, then
freebsd-update again:
# freebsd-update fetch
Looking up update.FreeBSD.org mirrors... 5 mirrors found.
Fetching metadata signature for 10.1-RELEASE from update5.freebsd.org... done.
Fetching metadata index... done.
Inspecting system... done.
Preparing to download files... done.
The following files will be updated as part of updating to 10.1-RELEASE-p14:
/usr/share/man/whatis
# freebsd-update install
Installing updates... done.
# freebsd-update fetch
Looking up update.FreeBSD.org mirrors... 5 mirrors found.
Fetching metadata signature for 10.1-RELEASE from update5.freebsd.org... done.
Fetching metadata index... done.
Inspecting system... done.
Preparing to download files... done.
No updates needed to update system to 10.1-RELEASE-p14.
# /etc/periodic/weekly/320.whatis
Rebuilding whatis database:
# freebsd-update fetch
Looking up update.FreeBSD.org mirrors... 5 mirrors found.
Fetching metadata signature for 10.1-RELEASE from update6.freebsd.org... done.
Fetching metadata index... done.
Inspecting system... done.
Preparing to download files... done.
The following files will be updated as part of updating to 10.1-RELEASE-p14:
/usr/share/man/whatis
But why is your base not in sync with the environment that builds the
freebsd-update binaries? When you run freebsd-update there's a
possibility that between updates (more likely between major updates)
there's a chance old files were removed. These could be libs, include,
binaries, man pages (in this case).
ex: Upgrade from 9.X to 10.X pkg_* was removed including the binaries,
support, and man files among other things that changed in 9->10.
I haven't tested this yet however freebsd-update.conf does have an
option:
AllowDelete The single parameter following this keyword must be
``yes'' or ``no'' and specifies whether freebsd-update
is allowed to delete files, directories, and symlinks
as part of updates downloaded.
I don't know if this cleans the no older used/orphaned files it doesn't
appear to retroactively clean up if you've had it off.
I believe another option is to use /usr/src/Makefile if you have
/usr/src (or a checked out source tree). I don't know if using
github.com/freebsd/freebsd/ releng/10.1 or stable/10 branch is correct.
Using a system installed /usr/src that's updated via freebsd-update
might be the correct way to go.
ex:
$ fgrep delete-old Makefile
# delete-old - Delete obsolete directories/files.
# delete-old-dirs - Delete obsolete directories.
# delete-old-files - Delete obsolete files.
# delete-old-libs - Delete obsolete libraries.
# 9. `make delete-old'
# 11. `make delete-old-libs' (in case no 3rd party program uses them
# anymore)
delete-old delete-old-dirs delete-old-files delete-old-libs \
# git branch
master
releng/10.1
* stable/10
# make delete-old
>>> Removing old files (only deletes safe to delete libs)
remove /usr/share/man/man9/NDHASGIANT.9.gz?
.....
I would like to know the best way to clean up old/orphaned base files.
- freebsd-update (but then how do you clean up from previous updates
when you had AllowDelete set to the default value no?).
- /usr/src/Makefile
# make -C /usr/src/ delete-old # delete-old{,-dirs,-files,-libs)
I believe the only risk here is if you delete a lib that's still
being used by a third party utility
- or some other method I didn't mention. Parsing INDEX files from
freebsd-update server might be an option however very risky.
Side note: It appears there was once a handbook article for
delete-old and delete-old-{dirs,files,libs} however it was removed.
Should it return?
On Sun, Jul 12, 2015 at 08:04:09AM -0600, Dan Busarow wrote:
> I have 9 servers running 9.3-RELEASE p19
>
> They are all pretty much identical at the / and /usr level with
> differences in /usr/local
>
> On two of these servers, freebsd-update keeps updating
> /usr/share/man/whatis after periodic weekly updates whatis
>
> The other 7 don't care.
>
> I know I can add /usr/share/man/whatis to freebsd-update.com IgnorePaths
>
> But.. what I'd really like to know is what may have triggered this
> behavior only on two out of 9 servers?
>
> Thanks,
> Dan
>
>
> -------- Forwarded Message --------
> Subject: alisocreek.buildingonline.net security updates
> Date: Sun, 12 Jul 2015 06:00:57 -0700 (PDT)
> From: Charlie Root <root@buildingonline.net>
> To: root@buildingonline.net
>
> Looking up update.FreeBSD.org mirrors... none found.
> Fetching metadata signature for 9.3-RELEASE from update.FreeBSD.org... done.
> Fetching metadata index... done.
> Inspecting system... done.
> Preparing to download files... done.
>
> The following files will be updated as part of updating to 9.3-RELEASE-p19:
> /usr/share/man/whatis
>
>
> _______________________________________________
> freebsd-questions@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to "freebsd-questions-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150712214439.GA25794>