From owner-freebsd-questions@FreeBSD.ORG Wed Sep 7 01:17:30 2011 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 14696106566B for ; Wed, 7 Sep 2011 01:17:30 +0000 (UTC) (envelope-from frank@esperance-linux.co.uk) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by mx1.freebsd.org (Postfix) with ESMTP id 94B878FC08 for ; Wed, 7 Sep 2011 01:17:28 +0000 (UTC) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id p871HQl0015126; Wed, 7 Sep 2011 02:17:27 +0100 Received: from orange.esperance-linux.co.uk (host-92-22-113-217.as13285.net [92.22.113.217]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id p871HQIk015119; Wed, 7 Sep 2011 02:17:26 +0100 Received: by orange.esperance-linux.co.uk (Postfix, from userid 1001) id EFE0833C1F; Wed, 7 Sep 2011 02:17:25 +0100 (BST) Date: Wed, 7 Sep 2011 02:17:25 +0100 From: Frank Shute To: Polytropon Message-ID: <20110907011725.GA70734@orange.esperance-linux.co.uk> References: <4E644637.1030500@pldrouin.net> <20110905143102.68a797fa.freebsd@edvax.de> <4E64CC1D.90001@pldrouin.net> <20110905154358.187c9fba.freebsd@edvax.de> <4E64DAA6.60006@pldrouin.net> <20110905163623.98ebca0a.freebsd@edvax.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="EVF5PPMfhYS0aIcm" Content-Disposition: inline In-Reply-To: <20110905163623.98ebca0a.freebsd@edvax.de> User-Agent: Mutt/1.4.2.3i X-Face: *}~{PHnDTzvXPe'wl_-f%!@+r5; VLhb':*DsX%wEOPg\fDrXWQJf|2\,92"DdS%63t*BHDyQ|OWo@Gfjcd72eaN!4%NE{0]p)ihQ1MyFNtWL X-Operating-System: FreeBSD 8.2-STABLE amd64 X-Organisation: 'shute.org.uk' Cc: Pierre-Luc Drouin , freebsd-questions@freebsd.org Subject: Re: Best Server OS for Someone That Does not Want to Touch a Shell on a Regular Basis? X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Frank Shute List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Sep 2011 01:17:30 -0000 --EVF5PPMfhYS0aIcm 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= =20 > > web server in general (I am thinking of package availability, but also= =20 > > and in particular as a quasi-automated updating tool)? >=20 > 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. >=20 > You also may encounter a situation where _no_ package is > available for a port (e. g. too many options, or licensing > restrictions). >=20 > 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. >=20 > 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. >=20 > 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). >=20 >=20 >=20 > > I noticed that in=20 > > the past few years, updating softwares through ports has been requiring= =20 > > more user intervention, due to the way some dependencies are being=20 > > updated from one version to the next. Would using binary packages allow= =20 > > to avoid more such user intervention? >=20 > 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. >=20 > 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"). >=20 > 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. >=20 > 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). >=20 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, --=20 Frank Contact info: http://www.shute.org.uk/misc/contact.html --EVF5PPMfhYS0aIcm Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iEYEARECAAYFAk5mxiQACgkQHduKvUAgeK6yRACeKvw8VzHPe8EGTUr+8OVrFc18 cF4Ani31dTM+qW/u3oiM6mLce6l674U6 =WELW -----END PGP SIGNATURE----- --EVF5PPMfhYS0aIcm--