Re: [foreman-users] Re: discovery and disjoint subnet/dhcp ranges...

2016-06-17 Thread Matthew Nicholson
Actually, I'm now wondering if I'm simple mis-understanding the
docs...after re-reading this a few times (as well as asking a co-worker to
double check me):


While it is possible to define the same DHCP range in Foreman, it’s usually
good practice to select a range from outside the pool defined in the
installer, but still in the subnet. For the example above, it is
recommended to define the DHCP range from 10.0.0.1 to 10.0.0.99 in the
Foreman UI which gives the following IP address distribution:

   - 10.0.0.1 - 10.0.0.99 - addresses reserved during bare-metal
   provisioning by Foreman
   - 10.0.0.100 - 10.0.200 - addresses for dynamic clients in the subnet
   (discovered hosts, unmanaged hosts)



My assumption was that a discovered host would do its discovery in the
10.0.0.100-200 range, then be provisioned, just like any other host, into
the 10.0.0.1-99 range. Now i'm wondering if the intent the whole time was
for discovered hosts to always remain in that discovery range?



On Fri, Jun 17, 2016 at 2:28 PM Matt  wrote:

> So I did a bit more digging today, to no real success. (maybe this should
> goto -dev? )
>
> I found my infoblox dhcp plugin wasn't paying any attention to the
> from_ip_address and to_ip_address when finding unused ips, and fixed that,
> but I was pretty sure that wasn't the issue, and as expected, it didn't
> change this behavior.
>
>
> From cranking up the logs to debug, when provisioning a discovered host, I
> never see the "unsued ip" proxy request come in...
>
>
> Finally, digging into the discovery code a bit, it looks like the class
> ForemanDiscovery::HostConverter is whats doing the actual creation of a
> host, and since that just converts the discovered host object into a
> managed host, no change in hostname/ip/etc is done.
>
> help?
>
>
> Is this by designed? How does this take into account the disjoint dhcp
> scope as recommended by the docs?
>
>
> On Thursday, June 16, 2016 at 3:29:06 PM UTC-4, Matt wrote:
>>
>> So, i've been playing with discovery a bit, and am getting ready to
>> hopefully use it in a few hundred node bare metal deploy soon. However,
>> hitting a bit of a wall right now...first my setup:
>>
>> * Got a network hosts using discovery will be on. lets say its
>> 192.168.1.0/24.
>> * DHCP (which in this case is infoblox, but, it shouldn't mater AFAIK),
>> is setup with a dhcp range for 192.168.1.200->192.168.1.254.
>> * Subnet is defined in foreman, with the smart proxy managing it.
>> Optional start/end of IP address range there is 192.168.1.5->192.168.1.199.
>> So, as per the docs, disjoint.
>>  * Discovery rule setup for hosts come from this network/subnet
>>
>> My understanding would be that the following should happen:
>> node boots, PXE kicks in, it leases and address from the high range
>> (200->254). Downloads discovery image. Boots it, sends facts.
>> Foreman get facts, I click auto-provision.
>>
>> This is where it goes off the rails a bit...
>>
>> I would expect foreman to now select an IP from the defined range
>> (5->199), send that to the proxy to get put into dns, name the host
>> accordingly (I'm naming based on ip), and reboot the host.
>>
>> What happens is the host gets assigned the same IP it booted with(from
>> the DHCP defined range, not the one foreman has been told about), and the
>> hostname is based off of that.
>>
>> This give me a couple problems:
>> 1). That upper range will fill up with reservations, eventually leaving
>> no leases in the range for new hosts to use for discovery.
>> 2). Sadly, infoblox, when creating records inside a dhcp range, needs a
>> restart. So until that happens those records (which i don't want anyways)
>> aren't "live".
>>
>> What I've done to rule a few things out:
>> Started with direct discovery (no smart proxy plugin for discovery), and
>> with IPAM for the subnet set to DHCP.
>> Tried swapping to a smart-proxy discovery provider, no change, other than
>> now the smart-proxy is being used(which is a good thing).
>> Tried switching the IPAM setting to internal, hoping foreman would then
>> honor the IP range setting(s), no change.
>>
>> So this leave me asking...uh, what?
>>
>> Is this..expected behavior? Should the discovery provisioning process be
>> re-using the IP used in the first phase, or should it be asking for a new
>> one? (if i click provision and then go into the interface and have it
>> suggest a new IP, it gets it from the right range)
>>
>>
>> help?
>>
>> Matt
>>
>> --
> 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.
>

-- 
You received this message because you are 

[foreman-users] When signing with a LDAP user get Error

2016-06-17 Thread Braven36


It did work one time for my Active Directory user after I added administrator 
role. I have added a group and linked it to an Active Directory group. So when 
a member of the group logs in for the first time they are added to Foreman's 
user tab, their properties are imported into Foreman (email,given Name, and 
Surname) and then the user gets a 500 internal error page or the error below.



*Error:*

Oops, we're sorry but something went wrong stack level too deep



What I see in the /var/logs/foreman/production

*2016-06-17T11:23:21 [app] [I] Processing by UsersController#login as HTML*
*2016-06-17T11:23:21 [app] [I]   Parameters: {"utf8"=>"✓", 
"authenticity_token"=>"fiABRLssMi1dKw5/fICxWOeirxgh42CX/eM+wUfvF+4=", 
"login"=>{"login"=>"myUser", "password"=>"[FILTERED]"}, "commit"=>"Login"}*
*2016-06-17T11:23:26 [app] [I] Expire fragment 
views/tabs_and_title_records-4 (0.1ms)*
*2016-06-17T11:23:31 [app] [W] Action failed*
* | SystemStackError: stack level too deep*
* | 
/usr/share/foreman/vendor/ruby/2.0.0/gems/activesupport-4.1.14.2/lib/active_support/notifications/instrumenter.rb:23*
*2016-06-17T11:23:31 [app] [I]   Rendered common/500.html.erb within 
layouts/application (1.9ms)*
*2016-06-17T11:23:31 [app] [I]   Rendered 
layouts/_application_content.html.erb (0.7ms)*
*2016-06-17T11:23:31 [app] [I]   Rendered layouts/base.html.erb (0.9ms)*
*2016-06-17T11:23:31 [app] [I] Completed 500 Internal Server Error in 
9648ms (Views: 6.1ms | ActiveRecord: 11.0ms)*



-- 
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] Katello 3.0 upgrade from 3.0 RC8 no answer file exists?

2016-06-17 Thread Eric D Helms
For the record, we don't test or guarantee inter-RC upgrades. If you are
upgrading from 2.4, prior to the last round of commits after RC8 your
upgrade could end up in a position where the installer data is wrong or
missing values. If you are able to upgrade from your 2.4 to 3.0 we highly
recommend that. If not, we can try to fix your install.
On Jun 16, 2016 11:40 PM, "Dylan Baars"  wrote:

> Hi,
>
> I've run into a problem attempting to upgrade from RC8 to the production
> release, I get this message:
>
> foreman-installer --scenario katello --upgrade
> No answer file at /etc/katello-installer/answers.katello-installer.yaml
> found, can not continue
>
> I've done the following:
> 1. Updated kafo:
> rpm -ivh
> http://koji.katello.org/packages/rubygem-kafo/0.7.4/1.el7/noarch/rubygem-kafo-0.7.4-1.el7.noarch.rpm
>
> 2. Updated repos
> yum update -y
> http://fedorapeople.org/groups/katello/releases/yum/3.0/katello/el7/x86_64/katello-repos-latest.rpm
> yum update -y
> http://yum.theforeman.org/releases/1.11/el7/x86_64/foreman-release.rpm
>
> 3. Clean and update foreman-release-scl
> yum clean all
> yum update -y foreman-release-scl
>
> 4. Update the system
> yum -y update
>
> During this I spotted two warning/errors
>
> Warning: RPMDB altered outside of yum.
> ** Found 1 pre-existing rpmdb problem(s), 'yum check' output follows:
> rubygem-kafo-0.7.4-1.el7.noarch is a duplicate with
> rubygem-kafo-0.7.2-1.el7.noarch
> (OK fine, I updated this above ;-) )
>
> warning: %posttrans(foreman-installer-katello-3.0.1-2.el7.noarch)
> scriptlet failed, exit status 23
> Non-fatal POSTTRANS scriptlet failure in rpm package
> foreman-installer-katello-3.0.1-2.el7.noarch
>
> /etc/katello-installer has these files in it
>
> -rw---. 1 root root 6950 Mar  7 12:32
> answers.katello-installer.yaml.backup
> -rw---. 1 root root 1583 Dec 24 04:34
> answers.katello-installer.yaml.rpmnew
> -rw---. 1 root root  702 Mar 26 07:32
> capsule-certs-generate.yaml.rpmsave
> drwx--. 2 root root   32 Mar  4 13:11 d20160304-16237-1y53b5q
> -rw---. 1 root root 2385 Jun 17 15:33 katello-installer.yaml
> -rw---. 1 root root 2565 Apr 22 17:19 katello-installer.yaml.backup
>
>
> If I copy the latest katello-installer.yaml to
> answers.katello-installer.yaml and try the upgrade it doesn't like that at
> all
>
> foreman-installer --scenario katello --upgrade
> /usr/share/gems/gems/kafo-0.7.4/lib/kafo/puppet_module.rb:155:in
> `get_name': undefined method `gsub' for :name:Symbol (NoMethodError)
> from
> /usr/share/gems/gems/kafo-0.7.4/lib/kafo/puppet_module.rb:18:in `initialize'
> from
> /usr/share/gems/gems/kafo-0.7.4/lib/kafo/configuration.rb:88:in `new'
> from
> /usr/share/gems/gems/kafo-0.7.4/lib/kafo/configuration.rb:88:in `block in
> modules'
> from
> /usr/share/gems/gems/kafo-0.7.4/lib/kafo/configuration.rb:88:in `map'
> from
> /usr/share/gems/gems/kafo-0.7.4/lib/kafo/configuration.rb:88:in `modules'
> from
> /usr/share/gems/gems/kafo-0.7.4/lib/kafo/configuration.rb:184:in `params'
> from
> /usr/share/gems/gems/kafo-0.7.4/lib/kafo/configuration.rb:193:in
> `preset_defaults_from_puppet'
> from
> /usr/share/gems/gems/kafo-0.7.4/lib/kafo/kafo_configure.rb:253:in
> `set_parameters'
> from
> /usr/share/gems/gems/kafo-0.7.4/lib/kafo/kafo_configure.rb:96:in
> `initialize'
> from /usr/share/gems/gems/clamp-1.0.0/lib/clamp/command.rb:133:in
> `new'
> from /usr/share/gems/gems/clamp-1.0.0/lib/clamp/command.rb:133:in
> `run'
> from
> /usr/share/gems/gems/kafo-0.7.4/lib/kafo/kafo_configure.rb:150:in `run'
> from /sbin/foreman-installer:12:in `'
>
>
> Have I made a mistake in my upgrade process?
>
> --
> 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.
>

-- 
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: Katello 3.0 (Saison) Released

2016-06-17 Thread Eric D Helms
I see it:

https://fedorapeople.org/groups/katello/releases/yum/2.4/katello/RHEL/7Server/x86_64/tfm-rubygem-katello-2.4.4-1.el7.noarch.rpm
On Jun 17, 2016 6:25 AM, "Edgars M."  wrote:

> Hi
>
> I cannot find Katello 2.4.4 packages for CentOS 7.
> https://fedorapeople.org/groups/katello/releases/yum/2.4/katello/RHEL/7Server/x86_64/
> contains only Katello 2.4.1. Is there another repo?
>
> Edgars
>
> ceturtdiena, 2016. gada 16. jūnijs 17:21:14 UTC+2, Eric Helms rakstīja:
>>
>> Katello 3.0 (Saison) has been released! This has been a long release
>> process due to the large amount of features and bug fixes introduced with
>> over 650+ Redmine issues set to closed or resolved. This release is a
>> major version bump because it introduces some backwards incompatible
>> changes and the removal of all deprecations that existed through the 2.X
>> lifespan.
>>
>> UPGRADES - PLEASE READ
>> ==
>>
>> The features introduced in 3.0 bring changes that require some action and
>> thought before upgrading. We highly encourage reading over the pre-upgrade
>> considerations and the upgrade caveat before attempting any upgrades (
>> http://www.katello.org/docs/3.0/upgrade/index.html).
>>
>> Katello 2.4.4 has been released with special updates for upgrades. Please
>> ensure that you update to 2.4.4 and read through the upgrade steps on our
>> site before proceeding.
>>
>> Please feel free to contact us with questions before doing your upgrade
>> to ensure all your bases are covered. A big thanks to all the RC testers
>> that found a lot of upgrade issues prior to the release!
>>
>> Highlights
>> ===
>>
>>  * Foreman Remote Execution Integration
>>  * OSTree Content Support
>>  * Capsule Status Views
>>  * Lazy Sync
>>  * Mirror on Sync
>>  * Docker V2 Support
>>  * Inter-Server Sync
>>  * Host Unification
>>  * Installer Scenarios
>>
>> For a detailed list and information of the changes in Katello 3.0 is in
>> our release notes:
>> http://www.katello.org/docs/3.0/release_notes/release_notes.html
>>
>>
>> Installation
>> 
>>
>> For installation, please see the instructions at:
>>
>>Server: http://www.katello.org/docs/3.0/installation/index.html
>> 
>>Capsule: http://www.katello.org/docs/3.0/installation/capsule.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.0.0.
>>
>>http://projects.theforeman.org/projects/katello/issues/new
>>
>> --
>> Eric D. Helms
>> Red Hat Engineering
>> Ph.D. Student - North Carolina State University
>>
> --
> 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.
>

-- 
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.