Best Server OS for Someone That Does not Want to Touch a Shell on a Regular Basis?

[Frank Shute]

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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-questions/attachments/20110907/48a80fe3/attachment.pgp