Re: [foreman-users] Re: Puppet upgrade from 3.x to 4.x fails

[Lachlan Musicman]

It was the first thing I did after sending that email.

http://projects.theforeman.org/issues/18548

Let me know if you need any more information.

cheers
L.

--
The most dangerous phrase in the language is, "We've always done it this
way."

- Grace Hopper

On 18 February 2017 at 13:44, Eric D Helms  wrote:

> Could you please file a bug report with this information including your
> fix or add it to an existing report so that we can look at getting this
> fixed in the upcoming 3.3 release?
>
> Thanks
> Eric
>
>
> On Feb 16, 2017 11:58 PM, "Lachlan Musicman"  wrote:
>
> GOT IT.
>
> GADDAM.
>
> Edited
>
> /usr/share/katello-installer-base/hooks/pre/31-upgrade-puppet.rb
>
> commented out lines 21 and 22:
>
>   success << Kafo::Helpers.execute('mv /var/lib/puppet/ssl
> /etc/puppetlabs/puppet') if File.directory?('/var/lib/puppet/ssl')
>   success << Kafo::Helpers.execute('mv /var/lib/puppet/foreman_cache_data
> /opt/puppetlabs/puppet/cache/') if File.directory?('/var/lib/pupp
> et/foreman_cache_data')
>
> did a diff on the two folders in both, made sure they were matching.
>
> Ran foreman-installer --upgrade-puppet and it worked.
>
> Un commented to two lines,  ran Klass's 18131 bug solution after it, and
> all worked fine.
>
> cheers
> L.
>
>
> --
> The most dangerous phrase in the language is, "We've always done it this
> way."
>
> - Grace Hopper
>
> On 17 February 2017 at 14:54, Lachlan Musicman  wrote:
>
>> Daniel,
>>
>> running the instructions as per the puppet upgrade page failed again.
>>
>> On issue we kept running into was this, from
>> /var/log/foreman-installer/katello.log
>>
>> [ERROR 2017-02-17 13:44:48 main] mv: cannot move ‘/var/lib/puppet/ssl’ to
>> ‘/etc/puppetlabs/puppet/ssl’: File exists
>> [ERROR 2017-02-17 13:44:48 main] mv: cannot move
>> ‘/var/lib/puppet/foreman_cache_data’ to 
>> ‘/opt/puppetlabs/puppet/cache/foreman_cache_data’:
>> File exists
>> [ERROR 2017-02-17 13:44:48 main] Upgrade step copy_data failed. Check
>> logs for more information.
>>
>> If you could point me to the log file that this message is talking about,
>> I'd appreciate that. Note that physically removing the offending files
>> doesn't seem to work - obviously there is some part of the
>> --foreman-installer --update-puppet execution that  recreates them
>>
>> Moving onto the next page, we start to do the whole thing by hand, as per
>> http://projects.theforeman.org/projects/foreman/wiki/Upgradi
>> ng_from_Puppet_3_to_4
>>
>> Again, Step 1a and 1b completes fine, except for 1b.5 again - this time
>> we did a grep on the whole of /etc/httpd/conf.d - there is no mention of
>> /var/lib/puppet/ssl in there at all
>>
>>
>> Moving onto Step 2, I ran the instructions with the changes you suggested
>> - adding --forman to some of the command line options.
>>
>> ERROR: Unrecognised option '--foreman-puppet-server-implementation'
>>
>> See: 'foreman-installer --help'
>>
>> So I look at the help:
>>
>> # foreman-installer --help | grep implementation
>> --capsule-puppet-server-implementation  Puppet master
>> implementation, either "master" (traditional
>>
>> And then if I do a grep on reset, none of these commands exist?
>>
>> I tried noop with capsule-puppet-server-implementation=puppetserver with
>> both --foreman-reset-puppet-X (as per your recommendation) and
>> --reset-foreman-puppet-X (format in line with other options) and neither
>> worked - all died with "ERROR: Unrecognised option '--X-puppet-autosign'"
>>
>>
>> Any other pointers would be appreciated.
>>
>> cheers
>> L.
>>
>>
>> --
>> The most dangerous phrase in the language is, "We've always done it this
>> way."
>>
>> - Grace Hopper
>>
>> On 17 February 2017 at 11:18, Lachlan Musicman  wrote:
>>
>>> Great - thanks all. VM snapshot from last week has been restored. We
>>> will try again now.
>>>
>>> cheers
>>> L.
>>>
>>> --
>>> The most dangerous phrase in the language is, "We've always done it this
>>> way."
>>>
>>> - Grace Hopper
>>>
>>> On 16 February 2017 at 22:06, Daniel Lobato Garcia 
>>> wrote:
>>>
 On 02/13, Lachlan Musicman wrote:
 > Ok, I've found the itemized puppet upgrade instructions that are here:
 >
 > http://projects.theforeman.org/projects/foreman/wiki/
 > Upgrading_from_Puppet_3_to_4
 >
 > and the place where the doc'd process fails. I start there.
 >
 > When I get to Step 1b. Environments, SSL and Apache; part 5 states
 "Update
 > SSL paths in /etc/httpd/conf.d/05-foreman-ssl.conf or
 > /etc/apache2/sites-available/05-foreman-ssl.conf, changing
 > /var/lib/puppet/ssl to /etc/puppetlabs/puppet/ssl"
 >
 > but our /etc/httpd/conf.d/05-foreman-ssl.conf contains no reference
 to
 > *either* reference?
 >
 > Skip it.
 >
 > Go to next step, figuring we have little if any manual
 customisations, I do
 > step 2 and the first run give teh 

Re: [foreman-users] katello centos-base repo not syncing

[Eric D Helms]

Does the sync task itself fail? If so, what do you see on the errors tab of
the task? Is Pulp throwing an error?

Thanks
Eric

On Feb 16, 2017 10:07 PM, "Edson Manners"  wrote:

Hate to bump the thread but I have the same issue. Katello 3.1.

The sync worked in this repo: http://vault.centos.org/7.1.1503/os/x86_64/
and did 8652 packages 3 months ago. A few yum updates later and now it wont
do it again or this repo:
http://vault.centos.org/7.2.1511/os/x86_64/

On Tuesday, October 25, 2016 at 4:42:55 PM UTC-4, steved0ca wrote:
>
> It seems the pulp-streaming service stopped running. After restarting it I
> was able to kill the sync tasks and restart them, but they still don't
> actually download any packages for Centos-base or -updates repos.
>
> On Mon, Oct 24, 2016 at 1:35 PM, steved0ca  wrote:
>
>> I tried all three options without any luck.
>>
>> After restarting the host, I tried to sync again with the 'background'
>> option and a manual sync and now I have an endless 'Result: Pending'
>> spinning circle for both the centos-base repo, and another repo that was
>> previously working.
>>
>> Here is the foreman production.log but I don't see anything helpful.
>> https://drive.google.com/file/d/0B7s4TFC-GYcAdVM1MH
>> NaOWZfR3c/view?usp=sharing
>>
>> On Monday, 24 October 2016 01:12:12 UTC-7, Klaas Demter wrote:
>>>
>>> Hi,
>>> try to change the download policy to "Immediate", I have had problems
>>> with "On demand" for some repositories.
>>>
>>> Greetings
>>> Klaas
>>>
>>>
>>>
>>> - Ursprüngliche Mail -
>>> Von: "steved0ca" 
>>> An: "Foreman users" 
>>> Gesendet: Sonntag, 23. Oktober 2016 21:03:59
>>> Betreff: [foreman-users] katello centos-base repo not syncing
>>>
>>> I have successfully synced other repos ie 'epel' without any difficulty.
>>>
>>> I've created a product 'centos-base' with a repo called 'centos-base'
>>> and
>>> attempted to sync the repo but no packages will sync. Same problem with
>>> centos-updates. Not sure where to start troubleshooting this, the
>>> foreman
>>> production.log doesn't have any obvious errors.
>>>
>>> The content host does display the repo including package count:
>>> # yum repolist
>>> ...
>>> repo id
>>>
>>> repo name status
>>> *!Default_Organization_CentOS-Base_CentOS-Base
>>>
>>>   CentOS-Base9,007*
>>> !Default_Organization_CentOS-Gluster-3_7_CentOS-Gluster-3_7
>>>
>>> CentOS-Gluster-3.714
>>> !Default_Organization_CentOS-Updates_CentOS-Updates
>>>
>>> CentOS-Updates 2,548
>>> !Default_Organization_epel_epel
>>>
>>> epel  11,215
>>> !Default_Organization_filebeat_filebeat
>>>
>>> filebeat  44
>>> !Default_Organization_glusterfs-nagios-epel_glusterfs-nagios-epel
>>>
>>> glusterfs-nagios-epel 10
>>> !Default_Organization_katello-agent_katello-agent
>>>
>>> katello-agent 15
>>> !Default_Organization_pcic_internal_pcic_internal
>>>
>>> pcic_internal 13
>>> base/7/x86_64
>>>
>>> CentOS-7 - Base*9,007*
>>> epel/x86_64
>>>
>>> Extra Packages for Enterprise Linux 7 - x86_6410,751
>>> extras/7/x86_64
>>>
>>> CentOS-7 - Extras393
>>> updates/7/x86_64
>>>
>>>  CentOS-7 - Updates 2,548
>>> repolist: 45,565
>>>
>>>
>>> Katello version 3.1
>>> Foreman 1.12.3
>>> Foreman OS CentOS 7.2
>>>
>>> pulp journal:
>>> Oct 23 11:45:03 foreman.my.domain.name pulp[12865]:
>>> kombu.transport.qpid:INFO: Connected to qpid with SASL mechanism
>>> ANONYMOUS
>>> Oct 23 11:45:04 foreman.my.domain.name pulp[299]:
>>> celery.worker.strategy:INFO: Received task:
>>> pulp.server.async.tasks._queue_reserved_task[060c2ae6-44a4-483f-ad90-be54e872ffec]
>>>
>>> Oct 23 11:45:04 foreman.my.domain.name pulp[322]:
>>> celery.worker.strategy:INFO: Received task:
>>> pulp.server.managers.repo.sync.sync[a3070bfa-6723-40c4-971e-2781746212c5]
>>>
>>> Oct 23 11:45:04 foreman.my.domain.name pulp[322]:
>>> celery.worker.strategy:INFO: Received task:
>>> pulp.server.async.tasks._release_resource[1f2bfee7-af00-4b0c-adb5-6dae94460415]
>>>
>>> Oct 23 11:45:04 foreman.my.domain.name pulp[648]:
>>> pulp_rpm.plugins.importers.yum.sync:INFO: Downloading metadata from
>>> http://mirror.it.ubc.ca/centos/7.2.1511/os/x86_64/.
>>> Oct 23 11:45:04 foreman.my.domain.name pulp[299]:
>>> celery.worker.job:INFO:
>>> Task
>>> pulp.server.async.tasks._queue_reserved_task[060c2ae6-44a4-483f-ad90-be54e872ffec]
>>>
>>> succeeded in 0.0428758189082s: None
>>> Oct 23 11:45:04 

Re: [foreman-users] Re: Puppet upgrade from 3.x to 4.x fails

[Eric D Helms]

Could you please file a bug report with this information including your fix
or add it to an existing report so that we can look at getting this fixed
in the upcoming 3.3 release?

Thanks
Eric

On Feb 16, 2017 11:58 PM, "Lachlan Musicman"  wrote:

GOT IT.

GADDAM.

Edited

/usr/share/katello-installer-base/hooks/pre/31-upgrade-puppet.rb

commented out lines 21 and 22:

  success << Kafo::Helpers.execute('mv /var/lib/puppet/ssl
/etc/puppetlabs/puppet') if File.directory?('/var/lib/puppet/ssl')
  success << Kafo::Helpers.execute('mv /var/lib/puppet/foreman_cache_data
/opt/puppetlabs/puppet/cache/') if File.directory?('/var/lib/
puppet/foreman_cache_data')

did a diff on the two folders in both, made sure they were matching.

Ran foreman-installer --upgrade-puppet and it worked.

Un commented to two lines,  ran Klass's 18131 bug solution after it, and
all worked fine.

cheers
L.


--
The most dangerous phrase in the language is, "We've always done it this
way."

- Grace Hopper

On 17 February 2017 at 14:54, Lachlan Musicman  wrote:

> Daniel,
>
> running the instructions as per the puppet upgrade page failed again.
>
> On issue we kept running into was this, from /var/log/foreman-installer/kat
> ello.log
>
> [ERROR 2017-02-17 13:44:48 main] mv: cannot move ‘/var/lib/puppet/ssl’ to
> ‘/etc/puppetlabs/puppet/ssl’: File exists
> [ERROR 2017-02-17 13:44:48 main] mv: cannot move
> ‘/var/lib/puppet/foreman_cache_data’ to 
> ‘/opt/puppetlabs/puppet/cache/foreman_cache_data’:
> File exists
> [ERROR 2017-02-17 13:44:48 main] Upgrade step copy_data failed. Check logs
> for more information.
>
> If you could point me to the log file that this message is talking about,
> I'd appreciate that. Note that physically removing the offending files
> doesn't seem to work - obviously there is some part of the
> --foreman-installer --update-puppet execution that  recreates them
>
> Moving onto the next page, we start to do the whole thing by hand, as per
> http://projects.theforeman.org/projects/foreman/wiki/Upgradi
> ng_from_Puppet_3_to_4
>
> Again, Step 1a and 1b completes fine, except for 1b.5 again - this time we
> did a grep on the whole of /etc/httpd/conf.d - there is no mention of
> /var/lib/puppet/ssl in there at all
>
>
> Moving onto Step 2, I ran the instructions with the changes you suggested
> - adding --forman to some of the command line options.
>
> ERROR: Unrecognised option '--foreman-puppet-server-implementation'
>
> See: 'foreman-installer --help'
>
> So I look at the help:
>
> # foreman-installer --help | grep implementation
> --capsule-puppet-server-implementation  Puppet master implementation,
> either "master" (traditional
>
> And then if I do a grep on reset, none of these commands exist?
>
> I tried noop with capsule-puppet-server-implementation=puppetserver with
> both --foreman-reset-puppet-X (as per your recommendation) and
> --reset-foreman-puppet-X (format in line with other options) and neither
> worked - all died with "ERROR: Unrecognised option '--X-puppet-autosign'"
>
>
> Any other pointers would be appreciated.
>
> cheers
> L.
>
>
> --
> The most dangerous phrase in the language is, "We've always done it this
> way."
>
> - Grace Hopper
>
> On 17 February 2017 at 11:18, Lachlan Musicman  wrote:
>
>> Great - thanks all. VM snapshot from last week has been restored. We will
>> try again now.
>>
>> cheers
>> L.
>>
>> --
>> The most dangerous phrase in the language is, "We've always done it this
>> way."
>>
>> - Grace Hopper
>>
>> On 16 February 2017 at 22:06, Daniel Lobato Garcia 
>> wrote:
>>
>>> On 02/13, Lachlan Musicman wrote:
>>> > Ok, I've found the itemized puppet upgrade instructions that are here:
>>> >
>>> > http://projects.theforeman.org/projects/foreman/wiki/
>>> > Upgrading_from_Puppet_3_to_4
>>> >
>>> > and the place where the doc'd process fails. I start there.
>>> >
>>> > When I get to Step 1b. Environments, SSL and Apache; part 5 states
>>> "Update
>>> > SSL paths in /etc/httpd/conf.d/05-foreman-ssl.conf or
>>> > /etc/apache2/sites-available/05-foreman-ssl.conf, changing
>>> > /var/lib/puppet/ssl to /etc/puppetlabs/puppet/ssl"
>>> >
>>> > but our /etc/httpd/conf.d/05-foreman-ssl.conf contains no reference to
>>> > *either* reference?
>>> >
>>> > Skip it.
>>> >
>>> > Go to next step, figuring we have little if any manual customisations,
>>> I do
>>> > step 2 and the first run give teh error
>>>
>>> I think all of these flags would be required and by removing them is why
>>> you see all of the errors. In order to use them, I think you can by
>>> appending --foreman to them, like:
>>>
>>>--foreman-puppet-server-implementation
>>>--foreman-reset-puppet-autosign
>>>etc...
>>>
>>> >
>>> > ERROR: Unrecognised option '--puppet-server-implementation'
>>> >
>>> > remove it, get
>>> >
>>> > ERROR: Unrecognised option '--reset-puppet-autosign'
>>> >
>>> > remove it, get
>>> >
>>> > ERROR: 

[foreman-users] Re: PXE-Less from remote network

[ZS-Man]

Hi,

in log on discovered node is only this:

Feb 17 14:00:53 fdi /usr/bin/discovery-menu[834]: Entering screen_facts
Feb 17 14:00:53 fdi /usr/bin/discovery-menu[834]: TUI executing: kexec 
--version
Feb 17 14:01:07 fdi /usr/bin/discovery-menu[834]: Registering host at (
https://172.17.129.51:8443)
Feb 17 14:01:08 fdi /usr/bin/discovery-menu[834]: Detecting the first NICs 
with link
Feb 17 14:01:08 fdi /usr/bin/discovery-menu[834]: Interface with link 
found: 54:53:ed:af:aa:7d (enp4s0)
Feb 17 14:01:08 fdi /usr/bin/discovery-menu[834]: Detecting the first NICs 
with link
Feb 17 14:01:08 fdi /usr/bin/discovery-menu[834]: Interface with link 
found: 54:53:ed:af:aa:7d (enp4s0)
Feb 17 14:01:09 fdi /usr/bin/discovery-menu[834]: Response from server 200:
Feb 17 14:01:09 fdi /usr/bin/discovery-menu[834]: Wrote result 200 to 
/tmp/discovery-http-success
Feb 17 14:01:09 fdi /usr/bin/discovery-menu[834]: Entering screen_status

After Provision, nothing happens on discovered host. No more lines in log, 
no error... nothing Host stay on Status screen, log stay on "Entering 
screen_status"

Any idea? 
Thanks.



-- 
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] unable to remove discovered host that failed provisioning

[Fran Terry]

The same as the other poster on this thread, version 1.13.4.

Have created a ticket for this: http://projects.theforeman.org/issues/18550 
 I did assign to yourself, however have changed it

Thanks

Fran

On Wednesday, 15 February 2017 12:09:28 UTC, Lukas Zapletal wrote:
>
> Which error do you see again? 
>
> Which version of Foreman and Discovery is this? Can you file a ticket 
> please? 
>
> LZ 
>
> On Tue, Feb 14, 2017 at 3:58 PM, Fran Terry  > wrote: 
> > Hi Lukas, 
> > 
> > I'm also seeing the same error with Foreman, is there a way of forcing 
> this 
> > discovered host from the system other than the method you mentioned 
> above 
> > which does not work in this instance. 
> > 
> > Thanks 
> > 
> > Fran 
> > 
> > 
> > On Monday, 10 October 2016 16:15:52 UTC+1, Lukas Zapletal wrote: 
> >> 
> >> 
> >> NoMethodError: undefined method `operatingsystem' for 
> >> > # 
> >> >  from 
> >> > /opt/rh/sclo-ror42/root/usr/share/gems/gems/activemodel- 
> >> > 4.2.5.1/lib/active_model/attribute_methods.rb:433:in 
> >> > `method_missing' 
> >> >  from 
> >> > /usr/share/foreman/app/models/concerns/orchestration/tftp.rb:16:in 
> >> > `tftp?' 
> >> 
> >> This was introduced by the UEFI patch, you are testing 1.13 I assume. 
> >> 
> >> If you confirm, please file an issue with this backtrace. The code 
> >> assumes operatingsystem is present, but it is not for Discovered hosts. 
> >> 
> >> LZ 
> >> 
> >> -- 
> >> 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-user...@googlegroups.com . 
> > To post to this group, send email to forema...@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.