Date: Tue, 16 Sep 2014 14:55:58 +0200 From: Polytropon <freebsd@edvax.de> To: Gregory Orange <gregory.orange@calorieking.com> Cc: freebsd-questions@freebsd.org Subject: Re: Remove distribution sets Message-ID: <20140916145558.b731c672.freebsd@edvax.de> In-Reply-To: <54179A2A.8090406@calorieking.com> References: <54169E42.5020108@calorieking.com> <20140915120948.569f5458.freebsd@edvax.de> <54179A2A.8090406@calorieking.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 16 Sep 2014 10:02:18 +0800, Gregory Orange wrote: > On 15/09/14 18:09, Polytropon wrote: > > On Mon, 15 Sep 2014 16:07:30 +0800, Gregory Orange wrote: > >> Can one remove distribution sets from FreeBSD 8.x? > > > > The system doesn't provide a _dedicated_ means to do this. > > Thank you (despite it being less than ideal news) - I wondered, but > couldn't find anything stating it as such. I had thought of a "make deinstall" command for the particular parts in the /usr/src directory tree, but you can only do "make install" for most components. Removing them, it seems, has to be done manually. > Yes I neglected to mention this URL: > https://forums.freebsd.org/viewtopic.php?&t=1136 > > Noone responded to edogawaconan regarding a register of the components > installed. I'll have a play with it, and particularly with > feebsd-update.conf and see how I go. This involves doing an upgrade of the system, but if this is to be done anyway, it _might_ work and remove parts. > > The best way to tune an installation is at install time. > -snip- > > Agreed. I've just heard back from hosting provider: They only have one > 8.3 OS image to install, and it has this extra material in it. They're > not planning a 8.4 image, so I'll have to get us to 9.x or later at some > point. I'd suggest, if possible, to follow 10.0 / 10.1 as soon as possible. You could probably even do a "network install", preparing a customized 10.0 image with stuff left out, and then "copying" it to the server "over the present install". This of course has to be done with a backup and an emergency recovery plan in mind. ;-) > > It's also possible to "prepare" a stripped-down system > > elsewhere and then use it to replace the installation in > > question. > > I wonder if I'll need to pursue that. I'd rather not. But it seems to be the easiest thing, "easy" in comparison with the alternatives (like manually removing parts from the system). > > A comparable way is provided via freebsd-update where parts > > to be subject of an update can be selected using its configuration > > file; see "man freebsd-update.conf" for the "Components" > > keyword. > > This might be my best option. It _should_ remove the "outdated" components and _not_ install their new counterparts if the configuration file says so. I'm not sure how it handles "hidden" dependencies, but the distribution parts should be quite independent of each other, so for example removing manpages does not break anything, it's just that there are no manpages anymore; removing sendmail, on the other hand, will render the whole system unusable. > > Probably you won't save much disk space anyway... > > I don't care about the disk space. The aim is twofold: > > 1. Reduce any extra content that widens the risk profile on a machine. > If code is present, there is some chance for it to contain bugs, which > leads to some chance of a security risk. Yes, that is a very important aspect (which I'm scared of whenever I have to deal with stock Linux installations). Also for dedicated systems, I tend to strip down the OS and the kernel, as I'm doing source updates anyway from a different system, so for example it's no big deal if there is no C compiler on the target system, no troff, and no loadable kernel modules. > 2. Ease upgrades. Already the machine has a custom kernel which I need > to replace with generic. The upgrade process requires a lot of manual > intervention (see below), and I'll be dealing with a number of these > machines. This also sounds interesting. For binary updates, using a custom kernel makes things more complicated, but if you trim your freebsd-update.conf and rely on "preprocessed" parts, updates should be quick and easy. > Manual intervention: > lots of prompting with "these files don't match, what do I do?" and > frustratingly, an editor session opens up to compare - in the vast > majority (all but a handful) of cases the differences are just the > header line which doesn't matter to me. There is something comparable when doing source upgrades: You can configure mergemaster not to annoy you. The file to do this is /etc/mergemaster.rc, see "man mergemaster" for details. This part of the upgrade process can be adjusted to be less frustrating. :-) -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140916145558.b731c672.freebsd>