Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 7 Sep 2011 02:17:25 +0100
From:      Frank Shute <>
To:        Polytropon <>
Cc:        Pierre-Luc Drouin <>,
Subject:   Re: Best Server OS for Someone That Does not Want to Touch a Shell on a Regular Basis?
Message-ID:  <>
In-Reply-To: <>
References:  <> <> <> <> <> <>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help

Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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=20
> > the past few years, updating softwares through ports has been requiring=
> > more user intervention, due to the way some dependencies are being=20
> > 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?




 Contact info:

Content-Type: application/pgp-signature
Content-Disposition: inline

Version: GnuPG v2.0.16 (FreeBSD)



Want to link to this message? Use this URL: <>