[PC-BSD Dev] RFC: Choice of a Less Error-Prone Scripting Language for Configuration Scripts + Standard Data Format

Rob Messick robmessick at gmail.com
Fri Mar 8 10:56:31 PST 2013

Torsten, I agree with your points about using shell scripts and the
advantages of using a common data format and I'm certainly not trying to
argue against you doing work on PC-BSD.  I believe the work the
installer is doing would be better moved somewhere else. See comments

On 03/08/2013 04:10 AM, Torsten Eichstädt wrote:
> Rob, if some (inclusion of existing) standards and guidelines get
> agreed upon the PC-BSD developers, will you join? Or are you already
> one of those?
No, I am not a PCBSD developer. I speak only for one user.
> The main focus of PCBSD install & cfg is _basic_ configuration of a
> _single_ computer. Hopefully iXsystems is not building up a nice
> botnet with PC-BSD ;)
Configuration management tools are useful even for scenarios when you
have one system. Ensuring services are enabled, packages installed,
permission set, and generating/modifying configuration files using
parameters injected from data sources that use a common data format.

There are two issues at play here ( or maybe I turned this into a
discussion of two issues), installing PC-BSD and configuring PC-BSD. I
would hope that as much configuration would be done outside the
installer as possible. Other than setting up the loader.conf is there
much configuration that couldn't be deferred to some sort of
configuration management tool?  The installer (or other GUI system
management tools) could write out a set of parameters, in a common data
format, that would then be applied by the configuration management tool.

> Of course there's an automated install. But I'd say that most
> companies & institutions who want to integrate a pool of
> FreeBSD/PC-BSD clients already have a heterogeneous network as well as
> some of the various cfg-mgmt suites. It wouldn't be wise to ship them
> one more. If they do not have one already, they probably want to
> choose themselves.
I do and disable PC-BSD features and have to be extra careful about
upgrades clobbering my configurations. It would be nice to provide a
nice easy auditable way for me to hook into the configurations that are
applied by PCBSDs scripts (maybe there is one that I'm not using?). A
user could always disable this service.
> I'm certainly not the Napoleon Bonaparte of Software Engineering. But
> frankly, I did not propose Python on purpose. It's too big.
I'm not sure what you mean by "too big" but python is included in the
base PCBSD system (At least indirectly by the inclusion of py-fail2ban
in base metapkg). PC-BSD is a significantly fat distribution by most
standards but I think that can be an advantage because ideas like this
could be considered.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pcbsd.org/pipermail/dev/attachments/20130308/c0ae173a/attachment.html>

More information about the Dev mailing list