Re: [foreman-users] Katello 3.3 RC2 released

[Pavel Hladík]

Thank you. Expectantly waiting for production release. :)

Dne pondělí 30. ledna 2017 22:06:35 UTC+1 jsherril napsal(a):
>
> We are happy to announce the second release candidate for Katello 3.3 (Baltic 
> Porter).
>
> Your help is appreciated to ensure our GA release is solid, by either
> installing a new instance or upgrading a test server.
>
> A list of the changes in Katello 3.3 is in our release notes:
> https://theforeman.org/plugins/katello/3.3/release_notes/release_notes.html
>
> Notable Changes:
>
> * Capsules are now referred to as "Smart Proxies" sometimes "with Content"
> * Our Docs have moved theforeman.org  
> https://theforeman.org/plugins/katello/
>
>
> Installation or Upgrade
> ==
>
> For installation, please see the instructions at:
>
>   Server:  
> https://theforeman.org/plugins/katello/3.3/installation/index.html
>   Smart Proxy:  
> https://theforeman.org/plugins/katello/3.3/installation/smart_proxy.html 
>
> For those testing upgrades, please use the instructions below and file
> any issues you encounter. Please note that there are separate upgrade
> instructions for the Katello server and Smart Proxies:
>
>   Server:  https://theforeman.org/plugins/katello/3.3/upgrade/index.html
>   Smart Proxy: 
> https://theforeman.org/plugins/katello/3.3/upgrade/smart_proxy.html
>
> Bug reporting
> ===
> If you come across a bug in your testing, please file it and note the
> version of Katello that you're using in the report and set the release
> to 3.3.0.
>
>   http://projects.theforeman.org/projects/katello/issues/new
>
> Thanks!
>
> -Justin Sherrill
>

-- 
You received this message because you are subscribed to the Google Groups 
"Foreman users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to foreman-users+unsubscr...@googlegroups.com.
To post to this group, send email to foreman-users@googlegroups.com.
Visit this group at https://groups.google.com/group/foreman-users.
For more options, visit https://groups.google.com/d/optout.

Re: [foreman-users] Excessive looping while loading host edit page

[Stefan Lasiewski]

Can we remove the interfaces from the WebUI besides deleting the host and 
re-run puppet? Won't we lose configuration data when we delete the host 
from Foreman?

-= Stefan

On Thursday, February 2, 2017 at 3:29:37 PM UTC-8, Stefan Lasiewski wrote:
>
> How funny. I was just looking this up also. Also running Puppet 3.8 & 
> Foreman 1.12.x, and a dozen Docker hosts. Turns out that Foreman doesn't 
> like 12 hosts with dozens of interfaces on each!
>
> Looks like this has also been fixed in Foreman 1.14. See 
> http://projects.theforeman.org/issues/16834 , which adds 'veth*' to 
> ignored_interface_identifiers 
> .
>
> -= Stefan
>
> On Thursday, February 2, 2017 at 12:35:49 PM UTC-8, Chris Baldwin wrote:
>>
>> I think the other way would be to avoid managing the host directly. Since 
>> we only use Foreman as an ENC, all class management could (should) be moved 
>> to a hostgroup, therefor never having to load the NICs.
>>
>> On Thursday, February 2, 2017 at 3:31:08 PM UTC-5, Tomer Brisker wrote:
>>>
>>> A possible workaround, if you don't need to manage all of those 
>>> interfaces in foreman, is to ignore some of them during fact import using 
>>> the ignored_interface_identifiers setting. 
>>> You may need to delete the host and re-run puppet for the ignored 
>>> interfaces to be removed.
>>>
>>> On Thu, Feb 2, 2017 at 10:22 PM, Chris Baldwin  
>>> wrote:
>>>
 Huh, that's interesting. The affected hosts do have a 
 larger-than-average (10+) number of interfaces as they're docker servers, 
 which is a commonality I hadn't noticed.

 Do you guys need/want any other logs to help w/ the issue? Is there any 
 kind of workaround that you've found?

 On Thursday, February 2, 2017 at 3:12:12 PM UTC-5, Tomer Brisker wrote:
>
> Hi Chris,
>
> Thank you for reporting this.
> This looks like you are hitting 
> http://projects.theforeman.org/issues/7829 which has to do with a 
> large number of interfaces on the host, leading to the interface partial 
> being rendered for each interface.
>
> On Thu, Feb 2, 2017 at 9:50 PM, Chris Baldwin  
> wrote:
>
>> Hi,
>>
>> My setup:
>> * Multiple Foreman servers, all on 1.12.1
>> * memcached shared between them
>> * shared backend DB (psql, 9.4.5)
>> * Foreman is a puppet 3.8 ENC only
>>
>> I have a reasonably large Foreman install. For some reason, some 
>> hosts take forever to load when clicking on 'edit'. The only thing I see 
>> in 
>> the logs is some obscene amount of rendering messages, to the tune of 
>> 445+ 
>> seconds of 
>>
>> 2017-02-02 11:36:43 [app] [I]   Rendered nic/_base_form.html.erb 
>> (27.1ms)
>> 2017-02-02 11:36:43 [app] [I]   Rendered nic/_virtual_form.html.erb 
>> (1.2ms)
>> 2017-02-02 11:36:43 [app] [I]   Rendered nic/_
>> provider_specific_form.html.erb (0.1ms)
>> 2017-02-02 11:36:43 [app] [I]   Rendered 
>> nic/manageds/_managed.html.erb (29.9ms)
>>
>> over and over. 
>>
>> I have a few questions about this:
>> * I got this info from debug. What else can I look at to get more 
>> information?
>> * Why is it rendering the same four items over and over? 
>> * I actually deleted the host from Foreman and re-ran puppet, that 
>> seemed to fix the issue temporarily. However, I don't understand *why* 
>> that 
>> made a difference. Can someone shed some light on this?
>>
>> -Chris (oogs/oogs_/oogs_werk on IRC)
>>
>> This log is for a good host. In a bad host, add about 100 times the 
>> stanzas I listed above.
>>
>> 2017-02-02 11:36:42 [app] [I] Started GET "/hosts/
>> testhost.domain.com/edit" for 127.0.0.101 at 2017-02-02 11:36:42 
>> -0800
>> 2017-02-02 11:36:42 [app] [I] Processing by HostsController#edit as 
>> HTML
>> 2017-02-02 11:36:42 [app] [I]   Parameters: {"id"=>"
>> testhost.domain.com"}
>> 2017-02-02 11:36:42 [app] [D] Cache read: 
>> _session_id:1234567890asdfghjkl
>> 2017-02-02 11:36:42 [app] [D] Setting current user thread-local 
>> variable to oogs
>> 2017-02-02 11:36:42 [app] [D] Cache read: authorize_login_delegation
>> 2017-02-02 11:36:42 [app] [D] Cache read: authorize_login_delegation
>> 2017-02-02 11:36:42 [app] [D] Cache read: idle_timeout
>> 2017-02-02 11:36:42 [app] [D] Setting current organization 
>> thread-local variable to none
>> 2017-02-02 11:36:42 [app] [D] Setting current location thread-local 
>> variable to none
>> 2017-02-02 11:36:42 [app] [I]   Rendered hosts/_progress.html.erb 
>> (0.2ms)
>> 2017-02-02 11:36:42 [app] [D] Setting current organization 
>> thread-local variable to MyOrg
>> 2017-02-02 11:36:42 [app] [D] Setting current location thread-local 
>> variable to MyLoc
>> 2017-02-02 11:36:42 [app] [I]   Rendered config_groups/_
>> config_group.html.erb (41.7ms)
>> 2017-0

Re: [foreman-users] Excessive looping while loading host edit page

[Stefan Lasiewski]

How funny. I was just looking this up also. Also running Puppet 3.8 & 
Foreman 1.12.x, and a dozen Docker hosts. Turns out that Foreman doesn't 
like 12 hosts with dozens of interfaces on each!

Looks like this has also been fixed in Foreman 1.14. 
See http://projects.theforeman.org/issues/16834 , which adds 'veth*' to 
ignored_interface_identifiers 
.

-= Stefan

On Thursday, February 2, 2017 at 12:35:49 PM UTC-8, Chris Baldwin wrote:
>
> I think the other way would be to avoid managing the host directly. Since 
> we only use Foreman as an ENC, all class management could (should) be moved 
> to a hostgroup, therefor never having to load the NICs.
>
> On Thursday, February 2, 2017 at 3:31:08 PM UTC-5, Tomer Brisker wrote:
>>
>> A possible workaround, if you don't need to manage all of those 
>> interfaces in foreman, is to ignore some of them during fact import using 
>> the ignored_interface_identifiers setting. 
>> You may need to delete the host and re-run puppet for the ignored 
>> interfaces to be removed.
>>
>> On Thu, Feb 2, 2017 at 10:22 PM, Chris Baldwin  wrote:
>>
>>> Huh, that's interesting. The affected hosts do have a 
>>> larger-than-average (10+) number of interfaces as they're docker servers, 
>>> which is a commonality I hadn't noticed.
>>>
>>> Do you guys need/want any other logs to help w/ the issue? Is there any 
>>> kind of workaround that you've found?
>>>
>>> On Thursday, February 2, 2017 at 3:12:12 PM UTC-5, Tomer Brisker wrote:

 Hi Chris,

 Thank you for reporting this.
 This looks like you are hitting 
 http://projects.theforeman.org/issues/7829 which has to do with a 
 large number of interfaces on the host, leading to the interface partial 
 being rendered for each interface.

 On Thu, Feb 2, 2017 at 9:50 PM, Chris Baldwin  
 wrote:

> Hi,
>
> My setup:
> * Multiple Foreman servers, all on 1.12.1
> * memcached shared between them
> * shared backend DB (psql, 9.4.5)
> * Foreman is a puppet 3.8 ENC only
>
> I have a reasonably large Foreman install. For some reason, some hosts 
> take forever to load when clicking on 'edit'. The only thing I see in the 
> logs is some obscene amount of rendering messages, to the tune of 445+ 
> seconds of 
>
> 2017-02-02 11:36:43 [app] [I]   Rendered nic/_base_form.html.erb 
> (27.1ms)
> 2017-02-02 11:36:43 [app] [I]   Rendered nic/_virtual_form.html.erb 
> (1.2ms)
> 2017-02-02 11:36:43 [app] [I]   Rendered nic/_
> provider_specific_form.html.erb (0.1ms)
> 2017-02-02 11:36:43 [app] [I]   Rendered 
> nic/manageds/_managed.html.erb (29.9ms)
>
> over and over. 
>
> I have a few questions about this:
> * I got this info from debug. What else can I look at to get more 
> information?
> * Why is it rendering the same four items over and over? 
> * I actually deleted the host from Foreman and re-ran puppet, that 
> seemed to fix the issue temporarily. However, I don't understand *why* 
> that 
> made a difference. Can someone shed some light on this?
>
> -Chris (oogs/oogs_/oogs_werk on IRC)
>
> This log is for a good host. In a bad host, add about 100 times the 
> stanzas I listed above.
>
> 2017-02-02 11:36:42 [app] [I] Started GET "/hosts/
> testhost.domain.com/edit" for 127.0.0.101 at 2017-02-02 11:36:42 -0800
> 2017-02-02 11:36:42 [app] [I] Processing by HostsController#edit as 
> HTML
> 2017-02-02 11:36:42 [app] [I]   Parameters: {"id"=>"
> testhost.domain.com"}
> 2017-02-02 11:36:42 [app] [D] Cache read: 
> _session_id:1234567890asdfghjkl
> 2017-02-02 11:36:42 [app] [D] Setting current user thread-local 
> variable to oogs
> 2017-02-02 11:36:42 [app] [D] Cache read: authorize_login_delegation
> 2017-02-02 11:36:42 [app] [D] Cache read: authorize_login_delegation
> 2017-02-02 11:36:42 [app] [D] Cache read: idle_timeout
> 2017-02-02 11:36:42 [app] [D] Setting current organization 
> thread-local variable to none
> 2017-02-02 11:36:42 [app] [D] Setting current location thread-local 
> variable to none
> 2017-02-02 11:36:42 [app] [I]   Rendered hosts/_progress.html.erb 
> (0.2ms)
> 2017-02-02 11:36:42 [app] [D] Setting current organization 
> thread-local variable to MyOrg
> 2017-02-02 11:36:42 [app] [D] Setting current location thread-local 
> variable to MyLoc
> 2017-02-02 11:36:42 [app] [I]   Rendered config_groups/_
> config_group.html.erb (41.7ms)
> 2017-02-02 11:36:42 [app] [I]   Rendered config_groups/_
> config_group.html.erb (31.5ms)
> 2017-02-02 11:36:42 [app] [I]   Rendered config_groups/_
> config_group.html.erb (29.7ms)
> 2017-02-02 11:36:42 [app] [I]   Rendered config_groups/_
> config_group.html.erb (27.2ms)
> 2017-02-02 11:36:42 [app] [I]   Rendered config_groups/_
> config_group.html.erb (18.1ms)
> 2017-0

Re: [foreman-users] Excessive looping while loading host edit page

[Chris Baldwin]

I think the other way would be to avoid managing the host directly. Since 
we only use Foreman as an ENC, all class management could (should) be moved 
to a hostgroup, therefor never having to load the NICs.

On Thursday, February 2, 2017 at 3:31:08 PM UTC-5, Tomer Brisker wrote:
>
> A possible workaround, if you don't need to manage all of those interfaces 
> in foreman, is to ignore some of them during fact import using the 
> ignored_interface_identifiers 
> setting. 
> You may need to delete the host and re-run puppet for the ignored 
> interfaces to be removed.
>
> On Thu, Feb 2, 2017 at 10:22 PM, Chris Baldwin  > wrote:
>
>> Huh, that's interesting. The affected hosts do have a larger-than-average 
>> (10+) number of interfaces as they're docker servers, which is a 
>> commonality I hadn't noticed.
>>
>> Do you guys need/want any other logs to help w/ the issue? Is there any 
>> kind of workaround that you've found?
>>
>> On Thursday, February 2, 2017 at 3:12:12 PM UTC-5, Tomer Brisker wrote:
>>>
>>> Hi Chris,
>>>
>>> Thank you for reporting this.
>>> This looks like you are hitting 
>>> http://projects.theforeman.org/issues/7829 which has to do with a large 
>>> number of interfaces on the host, leading to the interface partial being 
>>> rendered for each interface.
>>>
>>> On Thu, Feb 2, 2017 at 9:50 PM, Chris Baldwin  wrote:
>>>
 Hi,

 My setup:
 * Multiple Foreman servers, all on 1.12.1
 * memcached shared between them
 * shared backend DB (psql, 9.4.5)
 * Foreman is a puppet 3.8 ENC only

 I have a reasonably large Foreman install. For some reason, some hosts 
 take forever to load when clicking on 'edit'. The only thing I see in the 
 logs is some obscene amount of rendering messages, to the tune of 445+ 
 seconds of 

 2017-02-02 11:36:43 [app] [I]   Rendered nic/_base_form.html.erb 
 (27.1ms)
 2017-02-02 11:36:43 [app] [I]   Rendered nic/_virtual_form.html.erb 
 (1.2ms)
 2017-02-02 11:36:43 [app] [I]   Rendered 
 nic/_provider_specific_form.html.erb 
 (0.1ms)
 2017-02-02 11:36:43 [app] [I]   Rendered nic/manageds/_managed.html.erb 
 (29.9ms)

 over and over. 

 I have a few questions about this:
 * I got this info from debug. What else can I look at to get more 
 information?
 * Why is it rendering the same four items over and over? 
 * I actually deleted the host from Foreman and re-ran puppet, that 
 seemed to fix the issue temporarily. However, I don't understand *why* 
 that 
 made a difference. Can someone shed some light on this?

 -Chris (oogs/oogs_/oogs_werk on IRC)

 This log is for a good host. In a bad host, add about 100 times the 
 stanzas I listed above.

 2017-02-02 11:36:42 [app] [I] Started GET "/hosts/
 testhost.domain.com/edit" for 127.0.0.101 at 2017-02-02 11:36:42 -0800
 2017-02-02 11:36:42 [app] [I] Processing by HostsController#edit as HTML
 2017-02-02 11:36:42 [app] [I]   Parameters: {"id"=>"testhost.domain.com
 "}
 2017-02-02 11:36:42 [app] [D] Cache read: 
 _session_id:1234567890asdfghjkl
 2017-02-02 11:36:42 [app] [D] Setting current user thread-local 
 variable to oogs
 2017-02-02 11:36:42 [app] [D] Cache read: authorize_login_delegation
 2017-02-02 11:36:42 [app] [D] Cache read: authorize_login_delegation
 2017-02-02 11:36:42 [app] [D] Cache read: idle_timeout
 2017-02-02 11:36:42 [app] [D] Setting current organization thread-local 
 variable to none
 2017-02-02 11:36:42 [app] [D] Setting current location thread-local 
 variable to none
 2017-02-02 11:36:42 [app] [I]   Rendered hosts/_progress.html.erb 
 (0.2ms)
 2017-02-02 11:36:42 [app] [D] Setting current organization thread-local 
 variable to MyOrg
 2017-02-02 11:36:42 [app] [D] Setting current location thread-local 
 variable to MyLoc
 2017-02-02 11:36:42 [app] [I]   Rendered 
 config_groups/_config_group.html.erb 
 (41.7ms)
 2017-02-02 11:36:42 [app] [I]   Rendered 
 config_groups/_config_group.html.erb 
 (31.5ms)
 2017-02-02 11:36:42 [app] [I]   Rendered 
 config_groups/_config_group.html.erb 
 (29.7ms)
 2017-02-02 11:36:42 [app] [I]   Rendered 
 config_groups/_config_group.html.erb 
 (27.2ms)
 2017-02-02 11:36:42 [app] [I]   Rendered 
 config_groups/_config_group.html.erb 
 (18.1ms)
 2017-02-02 11:36:42 [app] [I]   Rendered 
 config_groups/_config_group.html.erb 
 (17.7ms)
 2017-02-02 11:36:42 [app] [I]   Rendered 
 config_groups/_config_group.html.erb 
 (17.6ms)
 2017-02-02 11:36:42 [app] [I]   Rendered 
 config_groups/_config_group.html.erb 
 (18.1ms)
 2017-02-02 11:36:42 [app] [I]   Rendered 
 config_groups/_config_group.html.erb 
 (18.0ms)
 2017-02-02 11:36:43 [app] [I]   Rendered 
 config_groups/_config_group.html.erb 
 (44.3ms)
 2017-02-

Re: [foreman-users] Excessive looping while loading host edit page

[Tomer Brisker]

A possible workaround, if you don't need to manage all of those interfaces
in foreman, is to ignore some of them during fact import using the
ignored_interface_identifiers
setting.
You may need to delete the host and re-run puppet for the ignored
interfaces to be removed.

On Thu, Feb 2, 2017 at 10:22 PM, Chris Baldwin  wrote:

> Huh, that's interesting. The affected hosts do have a larger-than-average
> (10+) number of interfaces as they're docker servers, which is a
> commonality I hadn't noticed.
>
> Do you guys need/want any other logs to help w/ the issue? Is there any
> kind of workaround that you've found?
>
> On Thursday, February 2, 2017 at 3:12:12 PM UTC-5, Tomer Brisker wrote:
>>
>> Hi Chris,
>>
>> Thank you for reporting this.
>> This looks like you are hitting http://projects.theforeman.org
>> /issues/7829 which has to do with a large number of interfaces on the
>> host, leading to the interface partial being rendered for each interface.
>>
>> On Thu, Feb 2, 2017 at 9:50 PM, Chris Baldwin  wrote:
>>
>>> Hi,
>>>
>>> My setup:
>>> * Multiple Foreman servers, all on 1.12.1
>>> * memcached shared between them
>>> * shared backend DB (psql, 9.4.5)
>>> * Foreman is a puppet 3.8 ENC only
>>>
>>> I have a reasonably large Foreman install. For some reason, some hosts
>>> take forever to load when clicking on 'edit'. The only thing I see in the
>>> logs is some obscene amount of rendering messages, to the tune of 445+
>>> seconds of
>>>
>>> 2017-02-02 11:36:43 [app] [I]   Rendered nic/_base_form.html.erb (27.1ms)
>>> 2017-02-02 11:36:43 [app] [I]   Rendered nic/_virtual_form.html.erb
>>> (1.2ms)
>>> 2017-02-02 11:36:43 [app] [I]   Rendered 
>>> nic/_provider_specific_form.html.erb
>>> (0.1ms)
>>> 2017-02-02 11:36:43 [app] [I]   Rendered nic/manageds/_managed.html.erb
>>> (29.9ms)
>>>
>>> over and over.
>>>
>>> I have a few questions about this:
>>> * I got this info from debug. What else can I look at to get more
>>> information?
>>> * Why is it rendering the same four items over and over?
>>> * I actually deleted the host from Foreman and re-ran puppet, that
>>> seemed to fix the issue temporarily. However, I don't understand *why* that
>>> made a difference. Can someone shed some light on this?
>>>
>>> -Chris (oogs/oogs_/oogs_werk on IRC)
>>>
>>> This log is for a good host. In a bad host, add about 100 times the
>>> stanzas I listed above.
>>>
>>> 2017-02-02 11:36:42 [app] [I] Started GET "/hosts/testhost.domain.com/ed
>>> it" for 127.0.0.101 at 2017-02-02 11:36:42 -0800
>>> 2017-02-02 11:36:42 [app] [I] Processing by HostsController#edit as HTML
>>> 2017-02-02 11:36:42 [app] [I]   Parameters: {"id"=>"testhost.domain.com
>>> "}
>>> 2017-02-02 11:36:42 [app] [D] Cache read: _session_id:1234567890asdfghjk
>>> l
>>> 2017-02-02 11:36:42 [app] [D] Setting current user thread-local variable
>>> to oogs
>>> 2017-02-02 11:36:42 [app] [D] Cache read: authorize_login_delegation
>>> 2017-02-02 11:36:42 [app] [D] Cache read: authorize_login_delegation
>>> 2017-02-02 11:36:42 [app] [D] Cache read: idle_timeout
>>> 2017-02-02 11:36:42 [app] [D] Setting current organization thread-local
>>> variable to none
>>> 2017-02-02 11:36:42 [app] [D] Setting current location thread-local
>>> variable to none
>>> 2017-02-02 11:36:42 [app] [I]   Rendered hosts/_progress.html.erb (0.2ms)
>>> 2017-02-02 11:36:42 [app] [D] Setting current organization thread-local
>>> variable to MyOrg
>>> 2017-02-02 11:36:42 [app] [D] Setting current location thread-local
>>> variable to MyLoc
>>> 2017-02-02 11:36:42 [app] [I]   Rendered 
>>> config_groups/_config_group.html.erb
>>> (41.7ms)
>>> 2017-02-02 11:36:42 [app] [I]   Rendered 
>>> config_groups/_config_group.html.erb
>>> (31.5ms)
>>> 2017-02-02 11:36:42 [app] [I]   Rendered 
>>> config_groups/_config_group.html.erb
>>> (29.7ms)
>>> 2017-02-02 11:36:42 [app] [I]   Rendered 
>>> config_groups/_config_group.html.erb
>>> (27.2ms)
>>> 2017-02-02 11:36:42 [app] [I]   Rendered 
>>> config_groups/_config_group.html.erb
>>> (18.1ms)
>>> 2017-02-02 11:36:42 [app] [I]   Rendered 
>>> config_groups/_config_group.html.erb
>>> (17.7ms)
>>> 2017-02-02 11:36:42 [app] [I]   Rendered 
>>> config_groups/_config_group.html.erb
>>> (17.6ms)
>>> 2017-02-02 11:36:42 [app] [I]   Rendered 
>>> config_groups/_config_group.html.erb
>>> (18.1ms)
>>> 2017-02-02 11:36:42 [app] [I]   Rendered 
>>> config_groups/_config_group.html.erb
>>> (18.0ms)
>>> 2017-02-02 11:36:43 [app] [I]   Rendered 
>>> config_groups/_config_group.html.erb
>>> (44.3ms)
>>> 2017-02-02 11:36:43 [app] [I]   Rendered 
>>> config_groups/_config_group.html.erb
>>> (21.1ms)
>>> 2017-02-02 11:36:43 [app] [I]   Rendered 
>>> config_groups/_config_group.html.erb
>>> (20.7ms)
>>> 2017-02-02 11:36:43 [app] [I]   Rendered 
>>> config_groups/_config_group.html.erb
>>> (18.7ms)
>>> 2017-02-02 11:36:43 [app] [I]   Rendered 
>>> config_groups/_config_group.html.erb
>>> (17.4ms)
>>> 2017-02-02 11:36:43 [app] [I]   Rendered 
>>> config_groups/_config_group.ht

Re: [foreman-users] Excessive looping while loading host edit page

[Chris Baldwin]

Huh, that's interesting. The affected hosts do have a larger-than-average 
(10+) number of interfaces as they're docker servers, which is a 
commonality I hadn't noticed.

Do you guys need/want any other logs to help w/ the issue? Is there any 
kind of workaround that you've found?

On Thursday, February 2, 2017 at 3:12:12 PM UTC-5, Tomer Brisker wrote:
>
> Hi Chris,
>
> Thank you for reporting this.
> This looks like you are hitting http://projects.theforeman.org/issues/7829 
> which 
> has to do with a large number of interfaces on the host, leading to the 
> interface partial being rendered for each interface.
>
> On Thu, Feb 2, 2017 at 9:50 PM, Chris Baldwin  > wrote:
>
>> Hi,
>>
>> My setup:
>> * Multiple Foreman servers, all on 1.12.1
>> * memcached shared between them
>> * shared backend DB (psql, 9.4.5)
>> * Foreman is a puppet 3.8 ENC only
>>
>> I have a reasonably large Foreman install. For some reason, some hosts 
>> take forever to load when clicking on 'edit'. The only thing I see in the 
>> logs is some obscene amount of rendering messages, to the tune of 445+ 
>> seconds of 
>>
>> 2017-02-02 11:36:43 [app] [I]   Rendered nic/_base_form.html.erb (27.1ms)
>> 2017-02-02 11:36:43 [app] [I]   Rendered nic/_virtual_form.html.erb 
>> (1.2ms)
>> 2017-02-02 11:36:43 [app] [I]   Rendered 
>> nic/_provider_specific_form.html.erb (0.1ms)
>> 2017-02-02 11:36:43 [app] [I]   Rendered nic/manageds/_managed.html.erb 
>> (29.9ms)
>>
>> over and over. 
>>
>> I have a few questions about this:
>> * I got this info from debug. What else can I look at to get more 
>> information?
>> * Why is it rendering the same four items over and over? 
>> * I actually deleted the host from Foreman and re-ran puppet, that seemed 
>> to fix the issue temporarily. However, I don't understand *why* that made a 
>> difference. Can someone shed some light on this?
>>
>> -Chris (oogs/oogs_/oogs_werk on IRC)
>>
>> This log is for a good host. In a bad host, add about 100 times the 
>> stanzas I listed above.
>>
>> 2017-02-02 11:36:42 [app] [I] Started GET "/hosts/
>> testhost.domain.com/edit" for 127.0.0.101 at 2017-02-02 11:36:42 -0800
>> 2017-02-02 11:36:42 [app] [I] Processing by HostsController#edit as HTML
>> 2017-02-02 11:36:42 [app] [I]   Parameters: {"id"=>"testhost.domain.com"}
>> 2017-02-02 11:36:42 [app] [D] Cache read: _session_id:1234567890asdfghjkl
>> 2017-02-02 11:36:42 [app] [D] Setting current user thread-local variable 
>> to oogs
>> 2017-02-02 11:36:42 [app] [D] Cache read: authorize_login_delegation
>> 2017-02-02 11:36:42 [app] [D] Cache read: authorize_login_delegation
>> 2017-02-02 11:36:42 [app] [D] Cache read: idle_timeout
>> 2017-02-02 11:36:42 [app] [D] Setting current organization thread-local 
>> variable to none
>> 2017-02-02 11:36:42 [app] [D] Setting current location thread-local 
>> variable to none
>> 2017-02-02 11:36:42 [app] [I]   Rendered hosts/_progress.html.erb (0.2ms)
>> 2017-02-02 11:36:42 [app] [D] Setting current organization thread-local 
>> variable to MyOrg
>> 2017-02-02 11:36:42 [app] [D] Setting current location thread-local 
>> variable to MyLoc
>> 2017-02-02 11:36:42 [app] [I]   Rendered 
>> config_groups/_config_group.html.erb (41.7ms)
>> 2017-02-02 11:36:42 [app] [I]   Rendered 
>> config_groups/_config_group.html.erb (31.5ms)
>> 2017-02-02 11:36:42 [app] [I]   Rendered 
>> config_groups/_config_group.html.erb (29.7ms)
>> 2017-02-02 11:36:42 [app] [I]   Rendered 
>> config_groups/_config_group.html.erb (27.2ms)
>> 2017-02-02 11:36:42 [app] [I]   Rendered 
>> config_groups/_config_group.html.erb (18.1ms)
>> 2017-02-02 11:36:42 [app] [I]   Rendered 
>> config_groups/_config_group.html.erb (17.7ms)
>> 2017-02-02 11:36:42 [app] [I]   Rendered 
>> config_groups/_config_group.html.erb (17.6ms)
>> 2017-02-02 11:36:42 [app] [I]   Rendered 
>> config_groups/_config_group.html.erb (18.1ms)
>> 2017-02-02 11:36:42 [app] [I]   Rendered 
>> config_groups/_config_group.html.erb (18.0ms)
>> 2017-02-02 11:36:43 [app] [I]   Rendered 
>> config_groups/_config_group.html.erb (44.3ms)
>> 2017-02-02 11:36:43 [app] [I]   Rendered 
>> config_groups/_config_group.html.erb (21.1ms)
>> 2017-02-02 11:36:43 [app] [I]   Rendered 
>> config_groups/_config_group.html.erb (20.7ms)
>> 2017-02-02 11:36:43 [app] [I]   Rendered 
>> config_groups/_config_group.html.erb (18.7ms)
>> 2017-02-02 11:36:43 [app] [I]   Rendered 
>> config_groups/_config_group.html.erb (17.4ms)
>> 2017-02-02 11:36:43 [app] [I]   Rendered 
>> config_groups/_config_group.html.erb (17.8ms)
>> 2017-02-02 11:36:43 [app] [I]   Rendered 
>> config_groups/_config_group.html.erb (18.0ms)
>> 2017-02-02 11:36:43 [app] [I]   Rendered 
>> config_groups/_config_group.html.erb (18.2ms)
>> 2017-02-02 11:36:43 [app] [I]   Rendered 
>> config_groups/_config_group.html.erb (18.8ms)
>> 2017-02-02 11:36:43 [app] [I]   Rendered 
>> config_groups/_config_group.html.erb (18.4ms)
>> 2017-02-02 11:36:43 [app] [I]   Rendered 
>> config_groups/_config_groups_selection.html

Re: [foreman-users] Excessive looping while loading host edit page

[Tomer Brisker]

Hi Chris,

Thank you for reporting this.
This looks like you are hitting
http://projects.theforeman.org/issues/7829 which
has to do with a large number of interfaces on the host, leading to the
interface partial being rendered for each interface.

On Thu, Feb 2, 2017 at 9:50 PM, Chris Baldwin  wrote:

> Hi,
>
> My setup:
> * Multiple Foreman servers, all on 1.12.1
> * memcached shared between them
> * shared backend DB (psql, 9.4.5)
> * Foreman is a puppet 3.8 ENC only
>
> I have a reasonably large Foreman install. For some reason, some hosts
> take forever to load when clicking on 'edit'. The only thing I see in the
> logs is some obscene amount of rendering messages, to the tune of 445+
> seconds of
>
> 2017-02-02 11:36:43 [app] [I]   Rendered nic/_base_form.html.erb (27.1ms)
> 2017-02-02 11:36:43 [app] [I]   Rendered nic/_virtual_form.html.erb (1.2ms)
> 2017-02-02 11:36:43 [app] [I]   Rendered nic/_provider_specific_form.html.erb
> (0.1ms)
> 2017-02-02 11:36:43 [app] [I]   Rendered nic/manageds/_managed.html.erb
> (29.9ms)
>
> over and over.
>
> I have a few questions about this:
> * I got this info from debug. What else can I look at to get more
> information?
> * Why is it rendering the same four items over and over?
> * I actually deleted the host from Foreman and re-ran puppet, that seemed
> to fix the issue temporarily. However, I don't understand *why* that made a
> difference. Can someone shed some light on this?
>
> -Chris (oogs/oogs_/oogs_werk on IRC)
>
> This log is for a good host. In a bad host, add about 100 times the
> stanzas I listed above.
>
> 2017-02-02 11:36:42 [app] [I] Started GET "/hosts/testhost.domain.com/edit"
> for 127.0.0.101 at 2017-02-02 11:36:42 -0800
> 2017-02-02 11:36:42 [app] [I] Processing by HostsController#edit as HTML
> 2017-02-02 11:36:42 [app] [I]   Parameters: {"id"=>"testhost.domain.com"}
> 2017-02-02 11:36:42 [app] [D] Cache read: _session_id:1234567890asdfghjkl
> 2017-02-02 11:36:42 [app] [D] Setting current user thread-local variable
> to oogs
> 2017-02-02 11:36:42 [app] [D] Cache read: authorize_login_delegation
> 2017-02-02 11:36:42 [app] [D] Cache read: authorize_login_delegation
> 2017-02-02 11:36:42 [app] [D] Cache read: idle_timeout
> 2017-02-02 11:36:42 [app] [D] Setting current organization thread-local
> variable to none
> 2017-02-02 11:36:42 [app] [D] Setting current location thread-local
> variable to none
> 2017-02-02 11:36:42 [app] [I]   Rendered hosts/_progress.html.erb (0.2ms)
> 2017-02-02 11:36:42 [app] [D] Setting current organization thread-local
> variable to MyOrg
> 2017-02-02 11:36:42 [app] [D] Setting current location thread-local
> variable to MyLoc
> 2017-02-02 11:36:42 [app] [I]   Rendered config_groups/_config_group.html.erb
> (41.7ms)
> 2017-02-02 11:36:42 [app] [I]   Rendered config_groups/_config_group.html.erb
> (31.5ms)
> 2017-02-02 11:36:42 [app] [I]   Rendered config_groups/_config_group.html.erb
> (29.7ms)
> 2017-02-02 11:36:42 [app] [I]   Rendered config_groups/_config_group.html.erb
> (27.2ms)
> 2017-02-02 11:36:42 [app] [I]   Rendered config_groups/_config_group.html.erb
> (18.1ms)
> 2017-02-02 11:36:42 [app] [I]   Rendered config_groups/_config_group.html.erb
> (17.7ms)
> 2017-02-02 11:36:42 [app] [I]   Rendered config_groups/_config_group.html.erb
> (17.6ms)
> 2017-02-02 11:36:42 [app] [I]   Rendered config_groups/_config_group.html.erb
> (18.1ms)
> 2017-02-02 11:36:42 [app] [I]   Rendered config_groups/_config_group.html.erb
> (18.0ms)
> 2017-02-02 11:36:43 [app] [I]   Rendered config_groups/_config_group.html.erb
> (44.3ms)
> 2017-02-02 11:36:43 [app] [I]   Rendered config_groups/_config_group.html.erb
> (21.1ms)
> 2017-02-02 11:36:43 [app] [I]   Rendered config_groups/_config_group.html.erb
> (20.7ms)
> 2017-02-02 11:36:43 [app] [I]   Rendered config_groups/_config_group.html.erb
> (18.7ms)
> 2017-02-02 11:36:43 [app] [I]   Rendered config_groups/_config_group.html.erb
> (17.4ms)
> 2017-02-02 11:36:43 [app] [I]   Rendered config_groups/_config_group.html.erb
> (17.8ms)
> 2017-02-02 11:36:43 [app] [I]   Rendered config_groups/_config_group.html.erb
> (18.0ms)
> 2017-02-02 11:36:43 [app] [I]   Rendered config_groups/_config_group.html.erb
> (18.2ms)
> 2017-02-02 11:36:43 [app] [I]   Rendered config_groups/_config_group.html.erb
> (18.8ms)
> 2017-02-02 11:36:43 [app] [I]   Rendered config_groups/_config_group.html.erb
> (18.4ms)
> 2017-02-02 11:36:43 [app] [I]   Rendered 
> config_groups/_config_groups_selection.html.erb
> (513.9ms)
> 2017-02-02 11:36:43 [app] [I]   Rendered 
> puppetclasses/_selectedClasses.html.erb
> (0.0ms)
> 2017-02-02 11:36:43 [app] [I]   Rendered 
> puppetclasses/_classes_in_groups.html.erb
> (2.6ms)
> 2017-02-02 11:36:43 [app] [I]   Rendered puppetclasses/_classes.html.erb
> (33.2ms)
> 2017-02-02 11:36:43 [app] [I]   Rendered 
> puppetclasses/_class_selection.html.erb
> (678.5ms)
> 2017-02-02 11:36:43 [app] [I]   Rendered nic/_base_form.html.erb (55.6ms)
> 2017-02-02 11:36:43 [app] [I]   Rendered n

[foreman-users] Excessive looping while loading host edit page

[Chris Baldwin]

Hi,

My setup:
* Multiple Foreman servers, all on 1.12.1
* memcached shared between them
* shared backend DB (psql, 9.4.5)
* Foreman is a puppet 3.8 ENC only

I have a reasonably large Foreman install. For some reason, some hosts take 
forever to load when clicking on 'edit'. The only thing I see in the logs 
is some obscene amount of rendering messages, to the tune of 445+ seconds 
of 

2017-02-02 11:36:43 [app] [I]   Rendered nic/_base_form.html.erb (27.1ms)
2017-02-02 11:36:43 [app] [I]   Rendered nic/_virtual_form.html.erb (1.2ms)
2017-02-02 11:36:43 [app] [I]   Rendered 
nic/_provider_specific_form.html.erb (0.1ms)
2017-02-02 11:36:43 [app] [I]   Rendered nic/manageds/_managed.html.erb 
(29.9ms)

over and over. 

I have a few questions about this:
* I got this info from debug. What else can I look at to get more 
information?
* Why is it rendering the same four items over and over? 
* I actually deleted the host from Foreman and re-ran puppet, that seemed 
to fix the issue temporarily. However, I don't understand *why* that made a 
difference. Can someone shed some light on this?

-Chris (oogs/oogs_/oogs_werk on IRC)

This log is for a good host. In a bad host, add about 100 times the stanzas 
I listed above.

2017-02-02 11:36:42 [app] [I] Started GET "/hosts/testhost.domain.com/edit" 
for 127.0.0.101 at 2017-02-02 11:36:42 -0800
2017-02-02 11:36:42 [app] [I] Processing by HostsController#edit as HTML
2017-02-02 11:36:42 [app] [I]   Parameters: {"id"=>"testhost.domain.com"}
2017-02-02 11:36:42 [app] [D] Cache read: _session_id:1234567890asdfghjkl
2017-02-02 11:36:42 [app] [D] Setting current user thread-local variable to 
oogs
2017-02-02 11:36:42 [app] [D] Cache read: authorize_login_delegation
2017-02-02 11:36:42 [app] [D] Cache read: authorize_login_delegation
2017-02-02 11:36:42 [app] [D] Cache read: idle_timeout
2017-02-02 11:36:42 [app] [D] Setting current organization thread-local 
variable to none
2017-02-02 11:36:42 [app] [D] Setting current location thread-local 
variable to none
2017-02-02 11:36:42 [app] [I]   Rendered hosts/_progress.html.erb (0.2ms)
2017-02-02 11:36:42 [app] [D] Setting current organization thread-local 
variable to MyOrg
2017-02-02 11:36:42 [app] [D] Setting current location thread-local 
variable to MyLoc
2017-02-02 11:36:42 [app] [I]   Rendered 
config_groups/_config_group.html.erb (41.7ms)
2017-02-02 11:36:42 [app] [I]   Rendered 
config_groups/_config_group.html.erb (31.5ms)
2017-02-02 11:36:42 [app] [I]   Rendered 
config_groups/_config_group.html.erb (29.7ms)
2017-02-02 11:36:42 [app] [I]   Rendered 
config_groups/_config_group.html.erb (27.2ms)
2017-02-02 11:36:42 [app] [I]   Rendered 
config_groups/_config_group.html.erb (18.1ms)
2017-02-02 11:36:42 [app] [I]   Rendered 
config_groups/_config_group.html.erb (17.7ms)
2017-02-02 11:36:42 [app] [I]   Rendered 
config_groups/_config_group.html.erb (17.6ms)
2017-02-02 11:36:42 [app] [I]   Rendered 
config_groups/_config_group.html.erb (18.1ms)
2017-02-02 11:36:42 [app] [I]   Rendered 
config_groups/_config_group.html.erb (18.0ms)
2017-02-02 11:36:43 [app] [I]   Rendered 
config_groups/_config_group.html.erb (44.3ms)
2017-02-02 11:36:43 [app] [I]   Rendered 
config_groups/_config_group.html.erb (21.1ms)
2017-02-02 11:36:43 [app] [I]   Rendered 
config_groups/_config_group.html.erb (20.7ms)
2017-02-02 11:36:43 [app] [I]   Rendered 
config_groups/_config_group.html.erb (18.7ms)
2017-02-02 11:36:43 [app] [I]   Rendered 
config_groups/_config_group.html.erb (17.4ms)
2017-02-02 11:36:43 [app] [I]   Rendered 
config_groups/_config_group.html.erb (17.8ms)
2017-02-02 11:36:43 [app] [I]   Rendered 
config_groups/_config_group.html.erb (18.0ms)
2017-02-02 11:36:43 [app] [I]   Rendered 
config_groups/_config_group.html.erb (18.2ms)
2017-02-02 11:36:43 [app] [I]   Rendered 
config_groups/_config_group.html.erb (18.8ms)
2017-02-02 11:36:43 [app] [I]   Rendered 
config_groups/_config_group.html.erb (18.4ms)
2017-02-02 11:36:43 [app] [I]   Rendered 
config_groups/_config_groups_selection.html.erb (513.9ms)
2017-02-02 11:36:43 [app] [I]   Rendered 
puppetclasses/_selectedClasses.html.erb (0.0ms)
2017-02-02 11:36:43 [app] [I]   Rendered 
puppetclasses/_classes_in_groups.html.erb (2.6ms)
2017-02-02 11:36:43 [app] [I]   Rendered puppetclasses/_classes.html.erb 
(33.2ms)
2017-02-02 11:36:43 [app] [I]   Rendered 
puppetclasses/_class_selection.html.erb (678.5ms)
2017-02-02 11:36:43 [app] [I]   Rendered nic/_base_form.html.erb (55.6ms)
2017-02-02 11:36:43 [app] [I]   Rendered nic/_virtual_form.html.erb (1.2ms)
2017-02-02 11:36:43 [app] [I]   Rendered 
nic/_provider_specific_form.html.erb (0.2ms)
2017-02-02 11:36:43 [app] [I]   Rendered nic/manageds/_managed.html.erb 
(58.6ms)
2017-02-02 11:36:43 [app] [I]   Rendered nic/_base_form.html.erb (27.2ms)
2017-02-02 11:36:43 [app] [I]   Rendered nic/_virtual_form.html.erb (1.3ms)
2017-02-02 11:36:43 [app] [I]   Rendered 
nic/_provider_specific_form.html.erb (0.1ms)
2017-02-02 11:36:43 [app] [I]   R

[foreman-users] Could not deactivate host on PuppetDB: SSL_connect SYSCALL returned=5 errno=0 state=unknown state

['oliver.simon.1977' via Foreman users]

Hi Group,

I am currently running 2 clusters with foreman, puppetserver 4 and 
puppetdb. Almost everything is working perfectly, only deleting hosts in 
foreman throws a 

Error: Could not deactivate host on PuppetDB: SSL_connect SYSCALL returned=5 
errno=0 state=unknown state

on the foreman page. The other integration works fine, and for example on 
the cmd I can do a 



r...@install..com:/etc/puppetlabs/puppetdb# puppet node status 
atf31..com

Currently active
Last catalog: 2017-02-01T21:27:08.832Z
Last facts: 2017-02-01T21:27:06.390Z
r...@install..com:/etc/puppetlabs/puppetdb

or

r...@install..com:/etc/puppetlabs/puppetdb# puppet node deactivate 
dev-a..com  
Submitted 'deactivate node' for dev-atf13..com with UUID e6e79475--
45aa--157fc645e001
r...@install..com:/etc/puppetlabs/puppetdb# 


which then shows the inactive host on Monitor -> Puppet DB Dashboard under 
"Inactive Nodes in the population"

I already tried puppetdb ssl-setup, also with -f to force copying, and I 
also tried the key/truststore thing with the (I guess) correct certificates 
from puppetserver itself.

Can someone maybe answer the question WHICH certificates do I have to use 
in puppetdb configuration, or isnt it possible in the setup we run here ? 

- puppetserver 2.7.2-1puppetlabs1
- puppetdb 4.3.0-1puppetlabs1
- foreman 1.14.0-1
- ruby-puppetdb-foreman 2.0.0-1

foreman puppetdb settings under Administer -> Settings -> Puppetdb 

("puppet" is aliassed to 127.0.0.1 in /etc/hosts on the server)
puppetdb_address https://puppet:8081/pdb/cmd/v1
puppetdb_dashboard_address http://puppet:8080/pdb/dashboard
puppetdb_enabled Yes

we also have in foreman/settings.yaml

:puppetdb: 
  :enabled: false 
  :address: 'https://puppet:8081/pdb/cmd/v1' 
  :dashboard_address: 'http://puppet:8080/pdb/dashboard' 
  :puppetdb_ssl_ca_file: '/etc/puppetlabs/puppet/ssl/
certs/ca.pem' 
  :puppetdb_ssl_certificate: 
'/etc/puppetlabs/puppet/ssl/certs/install..com.pem' 
  :puppetdb_ssl_private_key: 
'/etc/puppetlabs/puppet/ssl/private_keys/install..com.pem' 

As I said, all the rest seems to work fine, only deleting hosts doesnt work.

We would really appreciate if someone could shed some light into this 

thanks in advance, Oliver 

-- 
You received this message because you are subscribed to the Google Groups 
"Foreman users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to foreman-users+unsubscr...@googlegroups.com.
To post to this group, send email to foreman-users@googlegroups.com.
Visit this group at https://groups.google.com/group/foreman-users.
For more options, visit https://groups.google.com/d/optout.

[foreman-users] Could not deactivate host on PuppetDB: SSL_connect SYSCALL returned=5 errno=0 state=unknown state

['oliver.simon.1977' via Foreman users]

Hi Group,

I am currently running 2 clusters with foreman, puppetserver 4 and 
puppetdb. Almost everything is working perfectly, only deleting hosts in 
foreman throws a 

Error: Could not deactivate host on PuppetDB: SSL_connect SYSCALL returned=5 
errno=0 state=unknown state

on the foreman page. The other integration works fine, and for example on 
the cmd I can do a 



r...@install..com:/etc/puppetlabs/puppetdb# puppet node status 
atf31..com

Currently active
Last catalog: 2017-02-01T21:27:08.832Z
Last facts: 2017-02-01T21:27:06.390Z
r...@install..com:/etc/puppetlabs/puppetdb

or

r...@install..com:/etc/puppetlabs/puppetdb# puppet node deactivate 
dev-a.cl1.audisto.com 
Submitted 'deactivate node' for dev-atf13..com with UUID e6e79475--
45aa--157fc645e001
r...@install..com:/etc/puppetlabs/puppetdb# 


which then shows the inactive host on Monitor -> Puppet DB Dashboard under 
"Inactive Nodes in the population"

I already tried puppetdb ssl-setup, also with -f to force copying, and I 
also tried the key/truststore thing with the (I guess) correct certificates 
from puppetserver itself.

Can someone maybe answer the question WHICH certificates do I have to use 
in puppetdb configuration, or isnt it possible in the setup we run here ? 

- puppetserver 2.7.2-1puppetlabs1
- puppetdb 4.3.0-1puppetlabs1
- foreman 1.14.0-1
- ruby-puppetdb-foreman 2.0.0-1

foreman puppetdb settings under Administer -> Settings -> Puppetdb 

("puppet" is aliassed to 127.0.0.1 in /etc/hosts on the server)
puppetdb_address https://puppet:8081/pdb/cmd/v1
puppetdb_dashboard_address http://puppet:8080/pdb/dashboard
puppetdb_enabled Yes

we also have in foreman/settings.yaml

:puppetdb: 
  :enabled: false 
  :address: 'https://puppet:8081/pdb/cmd/v1' 
  :dashboard_address: 'http://puppet:8080/pdb/dashboard' 
  :puppetdb_ssl_ca_file: '/etc/puppetlabs/puppet/ssl/certs/ca.pem' 
  :puppetdb_ssl_certificate: 
'/etc/puppetlabs/puppet/ssl/certs/install..com.pem' 
  :puppetdb_ssl_private_key: 
'/etc/puppetlabs/puppet/ssl/private_keys/install..com.pem' 

As I said, all the rest seems to work fine, only deleting hosts doesnt work.

We would really appreciate if someone could shed some light into this 

thanks in advance, Oliver 

-- 
You received this message because you are subscribed to the Google Groups 
"Foreman users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to foreman-users+unsubscr...@googlegroups.com.
To post to this group, send email to foreman-users@googlegroups.com.
Visit this group at https://groups.google.com/group/foreman-users.
For more options, visit https://groups.google.com/d/optout.

[foreman-users] Katello 3.1 Monthly Sync Plans

[Louis Bohm]

I just installed Katello with the following:

   1. CentOS 7.3
   2. Foreman 1.12.4
   3. Katello 3.1.0
   4. Puppet 3.8.7
   5. Pulp server 2.8.7

The Katello 3.1 docs say there is a Sync Plan interval of monthly but I do 
not see it in the GUI.  I looked around and found the hammer command to add 
a sync plan and tried to add a monthly plan that way.  Instead I got an 
error that there was only hourly, daily and weekly.

Since this is a new install I am open to upgrading to 3.2 if that has a fix 
for this.  However, I did not see anything in the release notes.

Thanks,
Louis

-- 
You received this message because you are subscribed to the Google Groups 
"Foreman users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to foreman-users+unsubscr...@googlegroups.com.
To post to this group, send email to foreman-users@googlegroups.com.
Visit this group at https://groups.google.com/group/foreman-users.
For more options, visit https://groups.google.com/d/optout.

Re: [foreman-users] foreman and tftp boot

[Lukas Zapletal]

Someone had to change foreman_url / unattended_url global setting. We
are not aware that installer is doing that automatically.

LZ

On Thu, Feb 2, 2017 at 2:40 AM, Alfredo De Luca
 wrote:
> Hi Lukas.
> The problem was that in the file
> /var/lib/tftpboot/pxelinux.cfg/01-00-50-56-01-06-06 the token was with https
> but changing to http worked ok.
> Not sure why because we need http now since we always deployed with https. I
> think recently my colleague upgraded Foreman to 1.11.4...
> what would may have changed?
>
>
>
> On Wed, Feb 1, 2017 at 10:13 PM, Lukas Zapletal  wrote:
>>
>> Network, firewall issue, most likely.
>>
>> LZ
>>
>> On Wed, Feb 1, 2017 at 11:17 AM, Alfredo De Luca
>>  wrote:
>> > Hi Lukas. I ve already boot up from a live cd then ping and wget what is
>> > in
>> > that token and seems to work fine.
>> >
>> > What are the logs I can check? I ve done already production.log and
>> > proxy.log and all the systems logs... but nothing relevant as far as I
>> > can
>> > see.
>> >
>> > Regards
>> >
>> >
>> > On Tue, Jan 31, 2017 at 11:07 PM, Lukas Zapletal 
>> > wrote:
>> >>
>> >> I believe you need to investigate production.log file at the moment
>> >> when Anaconda tries to fetch the template.
>> >>
>> >> Try to access the url using wget. Ping the hostname, check DNS,
>> >> routing, firewalls etc. Usual stuff.
>> >>
>> >> LZ
>> >>
>> >> On Tue, Jan 31, 2017 at 3:22 AM, Alfredo De Luca
>> >>  wrote:
>> >> > Hi Lukas. The settings for the token is 360 minutes... so I think
>> >> > it's
>> >> > the
>> >> > default.
>> >> >
>> >> > Alfredo
>> >> >
>> >> >
>> >> > On Mon, Jan 30, 2017 at 9:50 PM, Lukas Zapletal 
>> >> > wrote:
>> >> >>
>> >> >> Is it possible that you are hitting expired tokens? Can you check
>> >> >> the
>> >> >> token duration setting?
>> >> >>
>> >> >> LZ
>> >> >>
>> >> >> On Mon, Jan 30, 2017 at 4:30 AM, Alfredo De Luca
>> >> >>  wrote:
>> >> >> > Hi all.
>> >> >> > I have foreman 1.11.4-1 on centos 7. I am trying to create a VM on
>> >> >> > vmware
>> >> >> > (as I did so many times) and usually works perfectly but this time
>> >> >> > seems
>> >> >> > to
>> >> >> > have some issues.
>> >> >> > I have attached the screenshot from the vmware console.
>> >> >> > Any idea? all the file under /var/lib/tftpboot/pxelinux.cfg are
>> >> >> > fine.
>> >> >> > I
>> >> >> > even
>> >> >> > tried to boot live cd and then get the token and it works
>> >> >> > fine.
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > --
>> >> >> > Alfredo
>> >> >> >
>> >> >> > --
>> >> >> > You received this message because you are subscribed to the Google
>> >> >> > Groups
>> >> >> > "Foreman users" group.
>> >> >> > To unsubscribe from this group and stop receiving emails from it,
>> >> >> > send
>> >> >> > an
>> >> >> > email to foreman-users+unsubscr...@googlegroups.com.
>> >> >> > To post to this group, send email to
>> >> >> > foreman-users@googlegroups.com.
>> >> >> > Visit this group at https://groups.google.com/group/foreman-users.
>> >> >> > For more options, visit https://groups.google.com/d/optout.
>> >> >>
>> >> >>
>> >> >>
>> >> >> --
>> >> >> Later,
>> >> >>   Lukas @lzap Zapletal
>> >> >>
>> >> >> --
>> >> >> You received this message because you are subscribed to the Google
>> >> >> Groups
>> >> >> "Foreman users" group.
>> >> >> To unsubscribe from this group and stop receiving emails from it,
>> >> >> send
>> >> >> an
>> >> >> email to foreman-users+unsubscr...@googlegroups.com.
>> >> >> To post to this group, send email to foreman-users@googlegroups.com.
>> >> >> Visit this group at https://groups.google.com/group/foreman-users.
>> >> >> For more options, visit https://groups.google.com/d/optout.
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > Alfredo
>> >> >
>> >> > --
>> >> > You received this message because you are subscribed to the Google
>> >> > Groups
>> >> > "Foreman users" group.
>> >> > To unsubscribe from this group and stop receiving emails from it,
>> >> > send
>> >> > an
>> >> > email to foreman-users+unsubscr...@googlegroups.com.
>> >> > To post to this group, send email to foreman-users@googlegroups.com.
>> >> > Visit this group at https://groups.google.com/group/foreman-users.
>> >> > For more options, visit https://groups.google.com/d/optout.
>> >>
>> >>
>> >>
>> >> --
>> >> Later,
>> >>   Lukas @lzap Zapletal
>> >>
>> >> --
>> >> You received this message because you are subscribed to the Google
>> >> Groups
>> >> "Foreman users" group.
>> >> To unsubscribe from this group and stop receiving emails from it, send
>> >> an
>> >> email to foreman-users+unsubscr...@googlegroups.com.
>> >> To post to this group, send email to foreman-users@googlegroups.com.
>> >> Visit this group at https://groups.google.com/group/foreman-users.
>> >> For more options, visit https://groups.google.com/d/optout.
>> >
>> >
>> >
>> >
>> > --
>> > Alfredo
>> >
>> > --
>> > You received this message because you are subscribed to the Google
>> > Groups
>> > "Foreman users" group.
>> > To unsubsc

[foreman-users] no package groups in katello / foreman

[Christian Froestl]

Hi everybody,

I don't see package groups in repo content UI.
All packages are synced and on the detail page of a repository I see that 
there are about 15000 packages, 4000 erratas and 202 package groups, but 
when I click on the package groups, I get an empty view.
Also it is not possible to install a group on a subscriped host. yum 
groupinstall "X Window System" gets an error message, that the group has no 
packages.

Any hints?

Kind regards,
Christian

-- 
You received this message because you are subscribed to the Google Groups 
"Foreman users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to foreman-users+unsubscr...@googlegroups.com.
To post to this group, send email to foreman-users@googlegroups.com.
Visit this group at https://groups.google.com/group/foreman-users.
For more options, visit https://groups.google.com/d/optout.

Re: [foreman-users] Re: foreman-installer needs to be run every reboot

[Dominic Cleal]

On 31/01/17 13:04, klmueller80 via Foreman users wrote:
> Hi Dominic,
> 
> it seems that foremanitself won`t start.

The log only shows that PostgreSQL isn't started, which would prevent
Foreman connecting to the database. Foreman itself (under Apache) should
be running according to the log.

> puppetdb, puppetserver and
> puppet agent are up and runnig. i added a verbose output of
> foreman-installer, perhaps you can see what went wrong.

The two log lines in the installer log show that PostgreSQL is not
started. This would affect Foreman's connection to the database.

  [ WARN 2017-01-31 13:54:33 verbose]
/Stage[main]/Postgresql::Server::Config/File[systemd-override]: Ensure
set to :present but file type is link so no content will be synced

This suggests that /etc/systemd/system/postgresql.service is a symlink,
you should probably remove that and re-run the installer so the module
can install the file as designed.

This might have prevented Puppet from configuring systemd to start
postgresql.service at boot.

  [ WARN 2017-01-31 13:54:35 verbose]
/Stage[main]/Postgresql::Server::Service/Service[postgresqld]/ensure:
ensure changed 'stopped' to 'running'

This is the module starting postgresql.service manually. After fixing
the above, this might not be necessary. Else try running "systemctl
enable postgresql.service".

-- 
Dominic Cleal
domi...@cleal.org

-- 
You received this message because you are subscribed to the Google Groups 
"Foreman users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to foreman-users+unsubscr...@googlegroups.com.
To post to this group, send email to foreman-users@googlegroups.com.
Visit this group at https://groups.google.com/group/foreman-users.
For more options, visit https://groups.google.com/d/optout.

[foreman-users] Foreman 1.14.1 bug fix release

[Dominic Cleal]

Foreman 1.14.1 is now out with over forty bug fixes across the project,
fixing many web UI errors, an issue starting the smart proxy on Windows,
and a couple of new issues found in 1.14.0.

Please see the release notes for the full list of changes:
https://theforeman.org/manuals/1.14/index.html#Releasenotesfor1.14.1


Information
===
For installation or upgrade instructions, see:

Installation quick start:
https://theforeman.org/manuals/1.14/quickstart_guide.html

Upgrade instructions:
https://theforeman.org/manuals/1.14/index.html#3.6Upgrade

Release notes:
https://theforeman.org/manuals/1.14/index.html#Releasenotesfor1.14

Do take note of the upgrade warnings and deprecations in this release:
https://theforeman.org/manuals/1.14/index.html#Upgradewarnings


Downloads
=
Packages may be found in the 1.14 directories on both deb.foreman.org
and yum.theforeman.org, and tarballs are on downloads.theforeman.org.

The GPG key used for RPMs and tarballs has the following fingerprint:
  AF74 2A91 BF76 6333 E9FF 5EAA BFE5 1511 F06D 8950
  (https://theforeman.org/security.html#GPGkeys)


Bug reporting
=
If you come across a bug, please file it and note the version of Foreman
that you're using in the report.

Foreman: http://projects.theforeman.org/projects/foreman/issues/new
Proxy: http://projects.theforeman.org/projects/smart-proxy/issues/new
Installer: http://projects.theforeman.org/projects/puppet-foreman/issues/new

-- 
Dominic Cleal
domi...@cleal.org


-- 
You received this message because you are subscribed to the Google Groups 
"Foreman users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to foreman-users+unsubscr...@googlegroups.com.
To post to this group, send email to foreman-users@googlegroups.com.
Visit this group at https://groups.google.com/group/foreman-users.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature