On 7/18/2014 1:18 PM, Alfred Perlstein wrote:
On 7/18/14, 6:28 AM, Allan Jude wrote:
On 2014-07-17 16:12, Adrian Chadd wrote:
On 17 July 2014 13:03, Alberto Mijares <amijar...@gmail.com> wrote:
On Thu, Jul 17, 2014 at 2:58 PM, Adrian Chadd <adr...@freebsd.org>
wrote:
Hi!
3) The binary packages need to work out of the box
4) .. which means, when you do things like pkg install apache, it
can't just be installed and not be enabled, because that's a bit of a
problem;
No. Please NEVER do that! The user must be able to edit the files and
start the service by himself.
Cool, so what's the single line command needed to type in to start a
given package service?
-a
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to
"freebsd-current-unsubscr...@freebsd.org"
We could make 'service apache22 enable'
which can run: sysrc -f /etc/rc.conf apache22_enable="YES"
and 'service apache22 disable'
that can use sysrc -x
And then ports can individually extend the functionality if they require.
I like this a lot.
That said, if other distros are setting up apache in 2 steps and we
require 3 then we require 50% MORE STEPs!
Or they require 33% LESS steps than us.
Just to put it into perspective. Should FreeBSD be 50% more difficult
or time consuming to configure?
-Alfred
Yes. As someone who works on a large fleet of Ubuntu systems, the worst
thing dpkg does is auto-start services and it even auto-restarts them on
updates in some cases.
* Starting a service is a security risk. Especially before it has been
configured, either manually or with tools. This is potentially true
even with "sane defaults" - for instance, the pkg may be installed from
an image/media and need to be updated from an internet repo because the
image has aged.
* Mandatory (re)starting of a service may happen before all deps are
upgraded/installed, requiring multiple pointless and time consuming
restarts.
* Likewise, starting a service before the manual or CM policy hits can
cause all sorts of problems, difficulties, and again even security
implications.
The way of doing things for large infrastructure is using some type of
config management or orchestration tool like Puppet, Chef, Salt,
Ansible, cfengine. This is even the case for small deployments for the
types of users Craig was talking about in the initial post.
Regards,
Kevin
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
