I've discussed a little of foreman organizations and locations at the fosdem with some of members of the foreman staff, Greg Sutcliffe said that there is an reflection about re-factor this in future version of foreman, and that the actual use-cases of organization/locations are welcome. So there is our organizations/locations use-cases:
We use Katello, so organization are enabled by default.
All hosts belongs to an org and a location.
We use organization in order to separate differents environements that are managed by different teams, and authenticated by different sources. 1 Org = 1 External auth source = 1 scope
We defined some parameters on the organization level to apply them to any host in this organization (.
We can't use nested organisation (because of katello ? i don't know if it possible in foreman nowadays). If it possible in the future and it permit us to share some resources managed by katello across different nested orgs, it can be an option for us, but the need here is most content sharing across orgs like it's possible in spacewalk.
We use nested location for geographical purposes (ex: country/city/DC) and we use parameters inheritance (for example timezone, keymap, some geographically defined server lists overrides…). We use it to attach for example some compute resource to an location too.
I heard about a "tagging implementation" of organizations and locations, but depending of the implementation it will break the params inheritance/override that we use today.
Thank you for detailed write-up! This will be very useful when we start
designing.
···
--
Marek
On Wednesday 09 of March 2016 11:36:36 Baptiste Agasse wrote:
Hi all,
I’ve discussed a little of foreman organizations and locations at the fosdem
with some of members of the foreman staff, Greg Sutcliffe said that there
is an reflection about re-factor this in future version of foreman, and
that the actual use-cases of organization/locations are welcome. So there
is our organizations/locations use-cases:
We use Katello, so organization are enabled by default.
All hosts belongs to an org and a location.
We use organization in order to separate differents environements that are
managed by different teams, and authenticated by different sources. 1 Org =
1 External auth source = 1 scope * We defined some parameters on the
organization level to apply them to any host in this organization (. * We
can’t use nested organisation (because of katello ? i don’t know if it
possible in foreman nowadays). If it possible in the future and it permit
us to share some resources managed by katello across different nested orgs,
it can be an option for us, but the need here is most content sharing
across orgs like it’s possible in spacewalk.
We use nested location for geographical purposes (ex: country/city/DC) and
we use parameters inheritance (for example timezone, keymap, some
geographically defined server lists overrides…). We use it to attach for
example some compute resource to an location too.
I heard about a “tagging implementation” of organizations and locations, but
depending of the implementation it will break the params
inheritance/override that we use today.
I'm also a user of Organizations and Locations as we have Foreman
implemented in a rather large company with multiple teams. I actually have
a blog post about how Organizations and Locations in our environment.
In short though, we have multiple data centers, remote offices and an AWS
footprint. Not all products live in all locations so we use Locations to
separate access, resources, host groups etc. We also have multiple
organizations that each have a number of actual products. We use
Organizations to define these and grant access accordingly. I know I've
heard in the past that Locations and Organizations are a heated topic
amongst Foreman as they introduce complexity within the code base, however
i truly believe that these features are a must if Foreman is to be
implemented successfully in large companies and especially in regulated
industries (healthcare, banking, etc).
My one complaint about these features, and it might be me doing something
wrong, is that when associating things to an Organization and/or Location
through the Manage Organization\Location page it still seems like I need to
make the association farther down the chain as well. For example if I
associate smart-proxy A to Location 5 from the Manage Locations page but
then go look at smart-proxy A it shows no locations being assigned.
Chris, first off, thank you for the links and sharing your experience.
I'll share my Use Case here, but I'd love to hear your take on the Org/Loc
and other Foreman meta-data issues I am starting to see…
I work for an IT Strategy Group somewhere in US Military. We're doing a
proof of concept to use Foreman and Puppet to manage mostly Linux Desktops.
Here are some vague details:
Provision and Manage 5-6000 Linux Desktops, maybe 100 servers.
Various distributions, mostly Red Hat Family, some Debian Family, and
some MacOSX.
7-10 geographic locations
10 distinct organizations, some organizations have presence is
multiple locations. e.g. 1 org has presence at two different bases, and
perhaps multiple buildings on each base.
My group will be responsible for the operations of the Foreman
infrastructure, but after install/config we will not have admin access to
the organizational puppet-masters as they have their own system admins.
Have need to restrict viewing outside of org… e.g. Org A's ppl have
no "need to know" to see Org B's nodes.
Have need for Org system admins to be able to roll their own puppet
modules
Have need for Strategy group to distribute compliance related puppet
modules to all masters/nodes
In the past few weeks we have just setup our first organizational
puppet-master, and today the org admin added his first two nodes, which
were pre-existing, not provisioned by foreman. The first puppet run failed
because of a class/environment mismatch on the org's puppet-master, this
mismatch was coerced by the default_hostgroup plugin - my fault. I fixed
that, but still Foreman shows the Org/Loc of this new node as undefined.
The org's system admin does not have the foreman role to allow org/loc
modification.
Another oddity, is that my org/group's puppet-master is also the puppetCA,
which means my SmartProxy/puppet-master must belong to all Orgs and all
Locs. This seems confusing, and perhaps we'll create a dedicated puppetca
in the near future.
What can we do to get around these without manual intervention? Is it
possible to coerce a node to inherit it's puppet-master's Org/Loc
membership?
Thanks for the advice!
···
On Wednesday, March 16, 2016 at 6:13:31 PM UTC-4, Christopher Pisano wrote:
>
> I'm also a user of Organizations and Locations as we have Foreman
> implemented in a rather large company with multiple teams. I actually have
> a blog post about how Organizations and Locations in our environment.
>
>
> https://chrispisano.wordpress.com/2016/01/22/locations-organizations-and-rbac/
>
> and the Foreman guest blog post
>
> http://theforeman.org/2016/01/locations-organizations-rbac.html
>
>
> In short though, we have multiple data centers, remote offices and an AWS
> footprint. Not all products live in all locations so we use Locations to
> separate access, resources, host groups etc. We also have multiple
> organizations that each have a number of actual products. We use
> Organizations to define these and grant access accordingly. I know I've
> heard in the past that Locations and Organizations are a heated topic
> amongst Foreman as they introduce complexity within the code base, however
> i truly believe that these features are a must if Foreman is to be
> implemented successfully in large companies and especially in regulated
> industries (healthcare, banking, etc).
>
> My one complaint about these features, and it might be me doing something
> wrong, is that when associating things to an Organization and/or Location
> through the Manage Organization\Location page it still seems like I need to
> make the association farther down the chain as well. For example if I
> associate smart-proxy A to Location 5 from the Manage Locations page but
> then go look at smart-proxy A it shows no locations being assigned.
>
I think what you are asking about is going beyond the purpose of this
thread, though I will say that you can address the issues you are seeing.
Organizations can be linked to multiple Locations and if you need to
separate buildings in a location for whatever reason (subnets or whatever)
then you can go the nested Locations route (not a fan) or use a Host Group
structure (my preference). Hosts that get added to Foreman need to have
their location and organization assigned to them manually unless you write
a custom fact in puppet and tell Foreman to use the value of said fact.
I'm not sure the confusion about the puppet CA belonging to all
organizations and locations. Do you have multiple puppet masters and puppet
CA servers for different locations and organizations? I can't really answer
this part without knowing your architecture.
Anyway if you want to chat more feel free to hit me up on IRC (discr33t).
···
On Thursday, April 7, 2016 at 4:25:02 PM UTC-4, Sean A wrote:
>
> Hi All!
>
> Chris, first off, thank you for the links and sharing your experience.
> I'll share my Use Case here, but I'd love to hear your take on the Org/Loc
> and other Foreman meta-data issues I am starting to see...
>
> I work for an IT Strategy Group somewhere in US Military. We're doing a
> proof of concept to use Foreman and Puppet to manage mostly Linux Desktops.
> Here are some vague details:
>
> - Provision and Manage 5-6000 Linux Desktops, maybe 100 servers.
> - Various distributions, mostly Red Hat Family, some Debian Family,
> and some MacOSX.
> - 7-10 geographic locations
> - 10 distinct organizations, some organizations have presence is
> multiple locations. e.g. 1 org has presence at two different bases, and
> perhaps multiple buildings on each base.
> - My group will be responsible for the operations of the Foreman
> infrastructure, but after install/config we will not have admin access to
> the organizational puppet-masters as they have their own system admins.
> - Have need to restrict viewing outside of org... e.g. Org A's ppl
> have no "need to know" to see Org B's nodes.
> - Have need for Org system admins to be able to roll their own puppet
> modules
> - Have need for Strategy group to distribute compliance related puppet
> modules to all masters/nodes
>
> In the past few weeks we have just setup our first organizational
> puppet-master, and today the org admin added his first two nodes, which
> were pre-existing, not provisioned by foreman. The first puppet run failed
> because of a class/environment mismatch on the org's puppet-master, this
> mismatch was coerced by the default_hostgroup plugin - my fault. I fixed
> that, but still Foreman shows the Org/Loc of this new node as undefined.
> The org's system admin does not have the foreman role to allow org/loc
> modification.
>
> Another oddity, is that my org/group's puppet-master is also the puppetCA,
> which means my SmartProxy/puppet-master must belong to all Orgs and all
> Locs. This seems confusing, and perhaps we'll create a dedicated puppetca
> in the near future.
>
> What can we do to get around these without manual intervention? Is it
> possible to coerce a node to inherit it's puppet-master's Org/Loc
> membership?
>
> Thanks for the advice!
>
> On Wednesday, March 16, 2016 at 6:13:31 PM UTC-4, Christopher Pisano wrote:
>>
>> I'm also a user of Organizations and Locations as we have Foreman
>> implemented in a rather large company with multiple teams. I actually have
>> a blog post about how Organizations and Locations in our environment.
>>
>>
>> https://chrispisano.wordpress.com/2016/01/22/locations-organizations-and-rbac/
>>
>> and the Foreman guest blog post
>>
>> http://theforeman.org/2016/01/locations-organizations-rbac.html
>>
>>
>> In short though, we have multiple data centers, remote offices and an AWS
>> footprint. Not all products live in all locations so we use Locations to
>> separate access, resources, host groups etc. We also have multiple
>> organizations that each have a number of actual products. We use
>> Organizations to define these and grant access accordingly. I know I've
>> heard in the past that Locations and Organizations are a heated topic
>> amongst Foreman as they introduce complexity within the code base, however
>> i truly believe that these features are a must if Foreman is to be
>> implemented successfully in large companies and especially in regulated
>> industries (healthcare, banking, etc).
>>
>> My one complaint about these features, and it might be me doing something
>> wrong, is that when associating things to an Organization and/or Location
>> through the Manage Organization\Location page it still seems like I need to
>> make the association farther down the chain as well. For example if I
>> associate smart-proxy A to Location 5 from the Manage Locations page but
>> then go look at smart-proxy A it shows no locations being assigned.
>>
>
I agree that perhaps it's beyond the scope of the thread, but it is my
Org/Loc user story.
The problem of adding pre-existing hosts into Foreman with Orgs/Logs and
Groups seems difficult in my mind, perhaps I'm overthinking the issue. I
guess I had the hope that since I have only one puppet server per
organization, that when a new node appears it would inherit it's master's
org. Similarly, that the node might inherit the location based on how
subnets are assigned to locations. I realize there are some many-to-one
and one-to-many relationship issues that arise but to date none of those
would appear in my user story.
At the moment, I guess I'm not connecting how you tell foreman to use your
location fact, maybe this is because I don't use (and have never played
with) Hiera. Do I understand correctly that you are using Hiera to set the
Foreman location with the value delivered by the custom location fact? I
guess I'll have to look into how I can use Hiera if that's the case, but
it's backwards of the way I thought that Hiera worked. I thought Hiera
provided data to puppet, not from puppet to foreman.
The issue of the CA is something I just noticed and hadn't thought much
about when I sent the post. The confusion comes from the exposure of the
puppet master with the CA to everyone (e.g. when selecting this data in a
host group or node definition). I think I'll be able to solve this when we
roll out the enterprise architecture. I will have a single puppetCA that
is not also my Org/Loc's puppet-master. That way, my Org's puppet server
won't be selectable by anyone outside my org/loc, e.g. so the org sys
admins can't assign their nodes to my puppet master by accident. I'll have
to test whether the SmartProxy can allow a puppet master to function only
as a puppetCA, so there would never be any confusion of what that puppet
master is used for.
The last thing is the RBAC stuff, is it possible to confine a user to an
Org?
Thanks for the reply and your thoughts, unfortunately I don't think IRC is
an approved protocol on this network, otherwise I'd love to chat sometime.
···
On Tuesday, April 12, 2016 at 10:29:31 AM UTC-4, Christopher Pisano wrote:
>
> Hey Sean,
>
> I think what you are asking about is going beyond the purpose of this
> thread, though I will say that you can address the issues you are seeing.
> Organizations can be linked to multiple Locations and if you need to
> separate buildings in a location for whatever reason (subnets or whatever)
> then you can go the nested Locations route (not a fan) or use a Host Group
> structure (my preference). Hosts that get added to Foreman need to have
> their location and organization assigned to them manually unless you write
> a custom fact in puppet and tell Foreman to use the value of said fact.
>
> I'm not sure the confusion about the puppet CA belonging to all
> organizations and locations. Do you have multiple puppet masters and puppet
> CA servers for different locations and organizations? I can't really answer
> this part without knowing your architecture.
>
> Anyway if you want to chat more feel free to hit me up on IRC (discr33t).
>
> On Thursday, April 7, 2016 at 4:25:02 PM UTC-4, Sean A wrote:
>>
>> Hi All!
>>
>> Chris, first off, thank you for the links and sharing your experience.
>> I'll share my Use Case here, but I'd love to hear your take on the Org/Loc
>> and other Foreman meta-data issues I am starting to see...
>>
>> I work for an IT Strategy Group somewhere in US Military. We're doing a
>> proof of concept to use Foreman and Puppet to manage mostly Linux Desktops.
>> Here are some vague details:
>>
>> - Provision and Manage 5-6000 Linux Desktops, maybe 100 servers.
>> - Various distributions, mostly Red Hat Family, some Debian Family,
>> and some MacOSX.
>> - 7-10 geographic locations
>> - 10 distinct organizations, some organizations have presence is
>> multiple locations. e.g. 1 org has presence at two different bases, and
>> perhaps multiple buildings on each base.
>> - My group will be responsible for the operations of the Foreman
>> infrastructure, but after install/config we will not have admin access to
>> the organizational puppet-masters as they have their own system admins.
>> - Have need to restrict viewing outside of org... e.g. Org A's ppl
>> have no "need to know" to see Org B's nodes.
>> - Have need for Org system admins to be able to roll their own puppet
>> modules
>> - Have need for Strategy group to distribute compliance related
>> puppet modules to all masters/nodes
>>
>> In the past few weeks we have just setup our first organizational
>> puppet-master, and today the org admin added his first two nodes, which
>> were pre-existing, not provisioned by foreman. The first puppet run failed
>> because of a class/environment mismatch on the org's puppet-master, this
>> mismatch was coerced by the default_hostgroup plugin - my fault. I fixed
>> that, but still Foreman shows the Org/Loc of this new node as undefined.
>> The org's system admin does not have the foreman role to allow org/loc
>> modification.
>>
>> Another oddity, is that my org/group's puppet-master is also the
>> puppetCA, which means my SmartProxy/puppet-master must belong to all Orgs
>> and all Locs. This seems confusing, and perhaps we'll create a dedicated
>> puppetca in the near future.
>>
>> What can we do to get around these without manual intervention? Is it
>> possible to coerce a node to inherit it's puppet-master's Org/Loc
>> membership?
>>
>> Thanks for the advice!
>>
>> On Wednesday, March 16, 2016 at 6:13:31 PM UTC-4, Christopher Pisano >> wrote:
>>>
>>> I'm also a user of Organizations and Locations as we have Foreman
>>> implemented in a rather large company with multiple teams. I actually have
>>> a blog post about how Organizations and Locations in our environment.
>>>
>>>
>>> https://chrispisano.wordpress.com/2016/01/22/locations-organizations-and-rbac/
>>>
>>> and the Foreman guest blog post
>>>
>>> http://theforeman.org/2016/01/locations-organizations-rbac.html
>>>
>>>
>>> In short though, we have multiple data centers, remote offices and an
>>> AWS footprint. Not all products live in all locations so we use Locations
>>> to separate access, resources, host groups etc. We also have multiple
>>> organizations that each have a number of actual products. We use
>>> Organizations to define these and grant access accordingly. I know I've
>>> heard in the past that Locations and Organizations are a heated topic
>>> amongst Foreman as they introduce complexity within the code base, however
>>> i truly believe that these features are a must if Foreman is to be
>>> implemented successfully in large companies and especially in regulated
>>> industries (healthcare, banking, etc).
>>>
>>> My one complaint about these features, and it might be me doing
>>> something wrong, is that when associating things to an Organization and/or
>>> Location through the Manage Organization\Location page it still seems like
>>> I need to make the association farther down the chain as well. For example
>>> if I associate smart-proxy A to Location 5 from the Manage Locations page
>>> but then go look at smart-proxy A it shows no locations being assigned.
>>>
>>
Yeah, users can be confined to one or more Organization and one or more Locations.
Permissions (what an user can do in an Org/Loc) can be set on a per-user basis,
but also you can map LDAP groups to Foreman user groups and set up permissions there.
···
On 04/12, Sean A wrote:
> Thanks Chris,
>
> The last thing is the RBAC stuff, is it possible to confine a user to an
> Org?
I'm not using Hiera to help set the location, I'm using a custom fact. I
have a fact (i actually think example code is in the blog post) that based
on subnet determines which location a host is in. In my foreman settings I
tell foreman to set the location based on the value of that fact. All hosts
that are not provisioned via foreman but rather created via fact upload
have a proper location already assigned. You could do the same for
organization though in my environment i'd be relying upon hostnames which i
absolutely never rely upon.
···
On Tuesday, April 12, 2016 at 12:05:55 PM UTC-4, Sean A wrote:
>
> Thanks Chris,
>
> I agree that perhaps it's beyond the scope of the thread, but it is my
> Org/Loc user story.
>
> The problem of adding pre-existing hosts into Foreman with Orgs/Logs and
> Groups seems difficult in my mind, perhaps I'm overthinking the issue. I
> guess I had the hope that since I have only one puppet server per
> organization, that when a new node appears it would inherit it's master's
> org. Similarly, that the node might inherit the location based on how
> subnets are assigned to locations. I realize there are some many-to-one
> and one-to-many relationship issues that arise but to date none of those
> would appear in my user story.
>
> At the moment, I guess I'm not connecting how you tell foreman to use your
> location fact, maybe this is because I don't use (and have never played
> with) Hiera. Do I understand correctly that you are using Hiera to set the
> Foreman location with the value delivered by the custom location fact? I
> guess I'll have to look into how I can use Hiera if that's the case, but
> it's backwards of the way I thought that Hiera worked. I thought Hiera
> provided data to puppet, not from puppet to foreman.
>
> The issue of the CA is something I just noticed and hadn't thought much
> about when I sent the post. The confusion comes from the exposure of the
> puppet master with the CA to everyone (e.g. when selecting this data in a
> host group or node definition). I think I'll be able to solve this when we
> roll out the enterprise architecture. I will have a single puppetCA that
> is not also my Org/Loc's puppet-master. That way, my Org's puppet server
> won't be selectable by anyone outside my org/loc, e.g. so the org sys
> admins can't assign their nodes to my puppet master by accident. I'll have
> to test whether the SmartProxy can allow a puppet master to function only
> as a puppetCA, so there would never be any confusion of what that puppet
> master is used for.
>
> The last thing is the RBAC stuff, is it possible to confine a user to an
> Org?
>
>
> Thanks for the reply and your thoughts, unfortunately I don't think IRC is
> an approved protocol on this network, otherwise I'd love to chat sometime.
>
> On Tuesday, April 12, 2016 at 10:29:31 AM UTC-4, Christopher Pisano wrote:
>>
>> Hey Sean,
>>
>> I think what you are asking about is going beyond the purpose of this
>> thread, though I will say that you can address the issues you are seeing.
>> Organizations can be linked to multiple Locations and if you need to
>> separate buildings in a location for whatever reason (subnets or whatever)
>> then you can go the nested Locations route (not a fan) or use a Host Group
>> structure (my preference). Hosts that get added to Foreman need to have
>> their location and organization assigned to them manually unless you write
>> a custom fact in puppet and tell Foreman to use the value of said fact.
>>
>> I'm not sure the confusion about the puppet CA belonging to all
>> organizations and locations. Do you have multiple puppet masters and puppet
>> CA servers for different locations and organizations? I can't really answer
>> this part without knowing your architecture.
>>
>> Anyway if you want to chat more feel free to hit me up on IRC (discr33t).
>>
>> On Thursday, April 7, 2016 at 4:25:02 PM UTC-4, Sean A wrote:
>>>
>>> Hi All!
>>>
>>> Chris, first off, thank you for the links and sharing your experience.
>>> I'll share my Use Case here, but I'd love to hear your take on the Org/Loc
>>> and other Foreman meta-data issues I am starting to see...
>>>
>>> I work for an IT Strategy Group somewhere in US Military. We're doing a
>>> proof of concept to use Foreman and Puppet to manage mostly Linux Desktops.
>>> Here are some vague details:
>>>
>>> - Provision and Manage 5-6000 Linux Desktops, maybe 100 servers.
>>> - Various distributions, mostly Red Hat Family, some Debian Family,
>>> and some MacOSX.
>>> - 7-10 geographic locations
>>> - 10 distinct organizations, some organizations have presence is
>>> multiple locations. e.g. 1 org has presence at two different bases, and
>>> perhaps multiple buildings on each base.
>>> - My group will be responsible for the operations of the Foreman
>>> infrastructure, but after install/config we will not have admin access to
>>> the organizational puppet-masters as they have their own system admins.
>>> - Have need to restrict viewing outside of org... e.g. Org A's ppl
>>> have no "need to know" to see Org B's nodes.
>>> - Have need for Org system admins to be able to roll their own
>>> puppet modules
>>> - Have need for Strategy group to distribute compliance related
>>> puppet modules to all masters/nodes
>>>
>>> In the past few weeks we have just setup our first organizational
>>> puppet-master, and today the org admin added his first two nodes, which
>>> were pre-existing, not provisioned by foreman. The first puppet run failed
>>> because of a class/environment mismatch on the org's puppet-master, this
>>> mismatch was coerced by the default_hostgroup plugin - my fault. I fixed
>>> that, but still Foreman shows the Org/Loc of this new node as undefined.
>>> The org's system admin does not have the foreman role to allow org/loc
>>> modification.
>>>
>>> Another oddity, is that my org/group's puppet-master is also the
>>> puppetCA, which means my SmartProxy/puppet-master must belong to all Orgs
>>> and all Locs. This seems confusing, and perhaps we'll create a dedicated
>>> puppetca in the near future.
>>>
>>> What can we do to get around these without manual intervention? Is it
>>> possible to coerce a node to inherit it's puppet-master's Org/Loc
>>> membership?
>>>
>>> Thanks for the advice!
>>>
>>> On Wednesday, March 16, 2016 at 6:13:31 PM UTC-4, Christopher Pisano >>> wrote:
>>>>
>>>> I'm also a user of Organizations and Locations as we have Foreman
>>>> implemented in a rather large company with multiple teams. I actually have
>>>> a blog post about how Organizations and Locations in our environment.
>>>>
>>>>
>>>> https://chrispisano.wordpress.com/2016/01/22/locations-organizations-and-rbac/
>>>>
>>>> and the Foreman guest blog post
>>>>
>>>> http://theforeman.org/2016/01/locations-organizations-rbac.html
>>>>
>>>>
>>>> In short though, we have multiple data centers, remote offices and an
>>>> AWS footprint. Not all products live in all locations so we use Locations
>>>> to separate access, resources, host groups etc. We also have multiple
>>>> organizations that each have a number of actual products. We use
>>>> Organizations to define these and grant access accordingly. I know I've
>>>> heard in the past that Locations and Organizations are a heated topic
>>>> amongst Foreman as they introduce complexity within the code base, however
>>>> i truly believe that these features are a must if Foreman is to be
>>>> implemented successfully in large companies and especially in regulated
>>>> industries (healthcare, banking, etc).
>>>>
>>>> My one complaint about these features, and it might be me doing
>>>> something wrong, is that when associating things to an Organization and/or
>>>> Location through the Manage Organization\Location page it still seems like
>>>> I need to make the association farther down the chain as well. For example
>>>> if I associate smart-proxy A to Location 5 from the Manage Locations page
>>>> but then go look at smart-proxy A it shows no locations being assigned.
>>>>
>>>
