On Mon, Sep 05, 2011 at 04:36:23PM +0200, Polytropon wrote: > > On Mon, 05 Sep 2011 10:20:22 -0400, Pierre-Luc Drouin wrote: > > How well does it work to use binary packages only to maintain a FreeBSD > > web server in general (I am thinking of package availability, but also > > and in particular as a quasi-automated updating tool)? > > Quite well - as long as you're satisfied with the default > building options. You know that a binary package is a port, > compiled with the default set of options. This is okay in > most cases, but there may be situations where you explicitely > need to enable or disable a certain feature at compile time. > > You also may encounter a situation where _no_ package is > available for a port (e. g. too many options, or licensing > restrictions). > > This can be solved by portmaster which has an option to > go through all interactive configuration screens _before_ > starting any action. Those settings can be saved for the > next update run. > > The portmaster program itself can be instructed to _use_ > binary packages (just as pkg_add -r would do) with the -P > and -PP options. In this case, binary packages will be > used as long as possible, and only those ports that > require building (as no package exists) will be compiled. > See "man portmaster" for details. > > This is a good approach in combination with freebsd-update. > I have used that concept on some servers myself (especially > on smaller ones with low resources where compiling would > be too problematic). > > > > > I noticed that in > > the past few years, updating softwares through ports has been requiring > > more user intervention, due to the way some dependencies are being > > updated from one version to the next. Would using binary packages allow > > to avoid more such user intervention? > > Yes. All dependencies would be incorporated automatically. > Only ports without equivalent package that additionally have > OPTIONS to set would invoke a configuration screen, and this > screen would have to be dealt with only in the first run of > the updating process. > > There are also options for portmaster that can be used to > control program behaviour in case of problems (e. g. some > package not found, conflicting ports, versioning problem, > or port marked "broken"). > > Those solutions can also easily be scripted, e. g. check > one a week for possible updates and get the packages, but > do not install them automatically (which can be a security > requirement). If the list is approved, the updates will > be installed during night, creating a "fallback copy" just > in case something went wrong (e. g. malfunctioning new > software). Reports can be generated automatically and mailed > to the system administrator. > > I would also suggest to frequently check the mailing lists > of the software in use for bugs and security updates that > might be interesting in terms of system security. This sould > be done for any "major server software" (Apache, PHP, MySQL > and the services utilizing those software, whatever you > want to run on the server). >
I'd recommend installing ports-mgmt/portaudit to keep an eye out on any vulnerabilities that require an update of the ports/packages. Personally, I'd go for ports rather than packages. As long as your friend reads /usr/ports/UPDATING and he uses either portupgrade or portmaster, he shouldn't go too far wrong. Also couldn't your friend give you a key for his server so that you can ssh into it and fix things if it goes wrong? Regards, -- Frank Contact info: http://www.shute.org.uk/misc/contact.html
pgpCyzp8FB6dy.pgp
Description: PGP signature
