Re: Proposal: Bcfg2 Branching Model

I've updated http://trac.mcs.anl.gov/projects/bcfg2/wiki/DevelopmentBranchingModel
to reflect your feedback.

I still believe we should adopt git-flow as a tool for managing
merges, tags and publishing. I think this will be justified once I've
written up the steps involved with the most common bcfg2.git
repository maintenance tasks using it.

git-flow does not restrict us to their default workflow, as was
proposed in the wiki's original format. The major difference the tool
'imposes' is that the maint branch in git-workflow(7) is replaced by
the prefix release/* branches. I don't see this as a bad thing. There
will be times, as with v1.2.1, v1.2.2 and v1.3.0, when three or more
release branches will need to be worked on at the same time. In this
case v1.3.0 work would be committed to master and the other two
branches would be release/v1.2.1 and release/v1.2.2.

The production branch comes for 'free' with git-flow and has the
advantage that diffs and log searches can be handled using branch
tools instead of using tags. The difference is not really a big deal
because of how git works, but research and troubleshooting with
branches is a little easier for me to get my head around.

CI, I believe, would do its testing against master and would build
releases against tags or the production branch depending on which is
easiest to automate. I'll know better when I outline the steps in
detail.

To summarize:

Unified bcfg2.spec file?

Hello list,
all the talk about the spec file last week made me wonder why we
currently have two of them (misc/bcfg2.spec and redhat/bcfg2.spec.in)
and who is using which one.

Them educationated folks on IRC clarified for me that the latter file
can be used to build with "make rpmdist" from git (or previously, from
svn) directly (at least as long as you retain the .git/ directory,
from which the version info is fetched). The misc/ file can be used
with the open build service, rpmbuild, and mock, and it seems to have
received a little more love recently (the redhat one does not build
the bcfg2-web package, f.e.). But then again, the misc/ version still
uses the debian init-scripts and /etc/defaults directory (and so does
the, most likely derived, fedora package, and some of my own
packages).

On IRC, everybody seemed to be using the file in misc/. Is anybody on
this list using the redhat/ flavor?

On top of the above differences, at least the Fedora project (Fabian
Affolter et al) and myself (openSUSE, someday maybe even SLES again)
roll our own, so we have all these versions:
    https://github.com/Bcfg2/bcfg2/blob/master/misc/bcfg2.spec
    https://github.com/Bcfg2/bcfg2/blob/master/redhat/bcfg2.spec.in
    http://pkgs.fedoraproject.org/gitweb/?p=bcfg2.git;a=blob;f=bcfg2.spec;hb=HEAD
    https://build.opensuse.org/package/view_file?file=bcfg.spec&package=bcfg2-stable&project=home%3Am4z&rev=97acdd17c95e23e1cb99cd4bfcddf2f7
(that's one out of five-and-a-half different ones I currently have to
build.)

In other words, we have a zoo of different files that I'd like to either

Re: Unified bcfg2.spec file?

At fermi we start with the file in misc and then make some changes based 
on our installation.
Like adding in the bcfg2.conf file and the ca file we need for 
authentication.

lisa

On 2/7/12 8:02 AM, 686f6c6d wrote:
> Hello list,
> all the talk about the spec file last week made me wonder why we
> currently have two of them (misc/bcfg2.spec and redhat/bcfg2.spec.in)
> and who is using which one.
>
> Them educationated folks on IRC clarified for me that the latter file
> can be used to build with "make rpmdist" from git (or previously, from
> svn) directly (at least as long as you retain the .git/ directory,
> from which the version info is fetched). The misc/ file can be used
> with the open build service, rpmbuild, and mock, and it seems to have
> received a little more love recently (the redhat one does not build
> the bcfg2-web package, f.e.). But then again, the misc/ version still
> uses the debian init-scripts and /etc/defaults directory (and so does
> the, most likely derived, fedora package, and some of my own
> packages).
>
> On IRC, everybody seemed to be using the file in misc/. Is anybody on
> this list using the redhat/ flavor?
>
> On top of the above differences, at least the Fedora project (Fabian
> Affolter et al) and myself (openSUSE, someday maybe even SLES again)
> roll our own, so we have all these versions:

Bcfg2/bcfg2/examples

I'd like to change the examples folder for the CI work. Is anyone
currently using it as it for anything? I'll also check the docs and
trac site before I start making changes.

https://github.com/Bcfg2/bcfg2/tree/master/examples

Re: Bcfg2 Enhancement Proposal: SELinux support

I've started implementing this, and I've run into a few areas where I
need further input.  Both SELinux booleans and SELinux modules can be
enumerated trivially.  Should Bcfg2 inventory these entries and
present extra entries if there are, for instance, booleans that aren't
listed in your config?

I'm leaning towards inventorying booleans, since they would be fairly
simple to add to a base config, but not inventorying modules, since
that would require copying the .pp files from an installed system, and
there's really no value-add there.

Another possibility would be to add a no-op SEModule tag -- sort of
like <Package ... version='any'/> -- that would simply say, "expect
there to be a qemu module, but do not specify what it must be."  That
would afford some measure of protection against spurious SELinux
modules showing up without making setup of a new distro an exercise in
tedium.

My second (or second-and-a-half?) quandary: when a new module is
pushed out to a machine, should I just create a temp file to hold the
module data until it can be loaded, or should I leave the file
permanently on the machine in, e.g., /usr/share/selinux/$SELINUXTYPE/?
 (Or should they go elsewhere?)

Thoughts on either are welcome.  Thanks!

On Wed, Dec 14, 2011 at 9:29 AM, Chris St. Pierre
<chris.a.st.pierre <at> gmail.com> wrote:
> This is a BEP - a Bcfg2 Enhancement Proposal.  I'm probably going to
> be sending out a few of these in the coming days/weeks as I start to

Re: Bcfg2 Enhancement Proposal: SELinux support

Re: Bcfg2 Enhancement Proposal: SELinux support

To be honest, I went with the approach of just handling modules and
booleans because that's really all I've done with SELinux before,
largely because I didn't have a good way to manage things like ports
and persist them across machine rebuilds.  I definitely think what
you've listed above is better than the approach I've been taking.

The question remains: to inventory, or not to inventory?  It still
seems nice to inventory as much as possible -- and everything semanage
handles seems appropriate -- but modules are sticky still.

On Tue, Feb 28, 2012 at 8:19 AM, Jonathan Billings <jsbillin <at> umich.edu> wrote:
> On Mon, Feb 27, 2012 at 4:19 PM, Chris St. Pierre
> <chris.a.st.pierre <at> gmail.com> wrote:
>>
>> I'm leaning towards inventorying booleans, since they would be fairly
>> simple to add to a base config, but not inventorying modules, since
>> that would require copying the .pp files from an installed system, and
>> there's really no value-add there.
>
>
> Why only manage booleans and modules?  There are a variety of knobs to
> selinux you could manage.   For example, there are ports, fcontext, login
> mappings, and permissive domains.  Wouldn't it be better to use something
> like <selinux type="module" name="whatever" version="any"/> as well as
> <selinux type="port" selinuxtype="ssh_port_t" proto="tcp" port="8022"/> for
> example.
>
> To get an idea of all the different selinux settings you're using, just take
> a look at the output of 'semanage -o -' to print it to stdout.  By the way,
> this option to semanage was introduced in RHEL6 and isn't in RHEL5 or
> earlier.
>
>
> --
> Jonathan Billings <jsbillin <at> umich.edu>
> College of Engineering - CAEN - Unix and Linux Support
>
>

--

-- 
Chris St. Pierre

Re: Bcfg2 Enhancement Proposal: SELinux support