HOWTO articles for migrating from Linux to FreeBSD, especially for pkg?

[Kevin Bowling]

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 <amijaresp at gmail.com> wrote:
>>>> On Thu, Jul 17, 2014 at 2:58 PM, Adrian Chadd <adrian at 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 at freebsd.org mailing list
>>> http://lists.freebsd.org/mailman/listinfo/freebsd-current
>>> To unsubscribe, send any mail to
>>> "freebsd-current-unsubscribe at 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