Greeting all,
I am very new to Foreman, so my issues could simply be ignorance. Do all
the hosts have to be on the same network for the commands to be successful
using the Remote Execution 0.1 on Foreman 1.10.0-RC-3? When I try to run a
job, they all time out.
1: Exit status: EXCEPTION
2: Error initializing command #
3: Errno::ETIMEDOUT Connection timed out - connect(2)
I am testing out different scenarios to which I need to be able to send
remote commands to devices regardless of what network they are on. I was
running Spacewalk but it wasn't stable on debian based clients. So far my
testing with Foreman has been excellent.
Additionally, when I try to install the Remote Excecution plugin on a
debian based system, regardless of a fresh install or not, I get the
following error:
PG::DuplicateColumn: ERROR: column "version" of relation
"dynflow_schema_info" already exists
I was able to get everything to install properly on a CentOS system, which
is how I am testing the above. What is the appropriate method to report an
issue with a plugin? Since my linux experience is with Debian bases
systems, I would feel more comfortable with getting that working. Again,
please excuse my lack of knowledge.
Thanks!
Carl
> From: "Carl Davis" <carl.davis@inreality.com>
> To: "Foreman users" <foreman-users@googlegroups.com>
> Sent: Monday, November 30, 2015 2:06:35 PM
> Subject: [foreman-users] Remote Execution questions/issue
>
>
> Greeting all,
>
> I am very new to Foreman, so my issues could simply be ignorance. Do all
> the hosts have to be on the same network for the commands to be successful
> using the Remote Execution 0.1 on Foreman 1.10.0-RC-3? When I try to run a
> job, they all time out.
>
> 1: Exit status: EXCEPTION
> 2: Error initializing command #
> 3: Errno::ETIMEDOUT Connection timed out - connect(2)
>
> I am testing out different scenarios to which I need to be able to send
> remote commands to devices regardless of what network they are on. I was
> running Spacewalk but it wasn't stable on debian based clients. So far my
> testing with Foreman has been excellent.
Remote Execution uses SSH, so the particular smart proxy needs to be able
to reach the host on port 22. It sounds like it can't.
>
> Additionally, when I try to install the Remote Excecution plugin on a
> debian based system, regardless of a fresh install or not, I get the
> following error:
>
> PG::DuplicateColumn: ERROR: column "version" of relation
> "dynflow_schema_info" already exists
How are you installing the plugin?
Can you provide more logs? Perhaps the output of foreman-rake db:migrate,
and anything that looks interesting in /var/log/foreman.
···
----- Original Message -----
I was able to get everything to install properly on a CentOS system, which
is how I am testing the above. What is the appropriate method to report an
issue with a plugin? Since my linux experience is with Debian bases
systems, I would feel more comfortable with getting that working. Again,
please excuse my lack of knowledge.
Thanks!
Carl
–
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+unsubscribe@googlegroups.com.
To post to this group, send email to foreman-users@googlegroups.com.
Visit this group at http://groups.google.com/group/foreman-users.
For more options, visit https://groups.google.com/d/optout.
Thanks for the response. Regarding the timeout, I dug further into some of
the logs of the failed attempts and it appears as if they do indeed need to
be on the same network or have a FQDN. My use case is that all the hosts
will be spread all over and sitting on a basic network with no port
forwarding available. Additionally, I will not be able to set a truly
FQDN, A records, etc. I was able to get around it by installing NeoRouter
on the Server and the hosts, then setting the virtual NIC that NeoRouter
configures (nrtap) as the NIC that execution commands are run on. From
there, everything worked as expected.
Regarding the install issues on Debian, I tried two slightly different
methods, but both based off the Plugin Manual found
here: Foreman :: Plugin Manuals My
first attempt was following the Quick Install of Foreman 1.10, enrolled a
few devices to make sure things were working properly, then running
foreman-installer --enable-foreman-plugin-remote-execution
–enable-foreman-plugin-tasks
–enable-foreman-proxy-plugin-remote-execution-ssh
The second attempt was following the Quick Install of foreman and instead
of running just foreman-installer the first time to install foreman, I ran
the above command. There was a third attempt following the Quick Install
followed by the directions for manually installing the plugin. That
resulted in the following error:
ruby-smart-proxy-remote-execution-ssh : Depends: ruby-net-ssh (<= 2.1.0)
but 1:2.6.8-1 is to be installed
Here is the CLI output from the installation, unfortunately I do not recall
if it was the first or second attempt.
root@fedfor:~# foreman-installer --enable-foreman-plugin-remote-execution
–enable-foreman-proxy-plugin-remote-execution-ssh
Execution of '/usr/bin/apt-get -q -y -o DPkg::Options::=–force-confold
install ruby-smart-proxy-remote-execution-ssh' returned 100: Reading
package lists…
/Stage[main]/Foreman_proxy::Plugin::Remote_execution::Ssh/Foreman_proxy::Plugin[remote_execution_ssh]/Package[ruby-smart-proxy-remote-execution-ssh]/ensure:
change from purged to present failed: Execution of '/usr/bin/apt-get -q -y
-o DPkg::Options::=–force-confold install
ruby-smart-proxy-remote-execution-ssh' returned 100: Reading package
lists…
/Stage[main]/Foreman_proxy::Register/Foreman_smartproxy[fedfor.inreality.com]:
Failed to call refresh: Proxy fedfor.inreality.com cannot be registered
(Could not load data from https://fedfor.inreality.com
/Stage[main]/Foreman_proxy::Register/Foreman_smartproxy[fedfor.inreality.com]:
Proxy fedfor.inreality.com cannot be registered (Could not load data from
https://fedfor.inreality.com
Installing Done
[100%]
[…]
Something went wrong! Check the log for ERROR-level output
There was no foreman-installer.log, but this came from /var/log/syslog
Nov 23 11:27:51 fedfor libapache2-mod-passenger: apache2_invoke: Enable
module passenger
Nov 23 11:27:57 fedfor crontab[5037]: (root) LIST (root)
Nov 23 11:28:05 fedfor puppet-agent[5405]: Reopening log files
Nov 23 11:28:05 fedfor puppet-agent[5405]: Starting Puppet client version
3.8.4
Nov 23 11:28:05 fedfor puppet-agent[5409]: Unable to fetch my node
definition, but the agent run will continue:
Nov 23 11:28:05 fedfor puppet-agent[5409]: Connection refused - connect(2)
Nov 23 11:28:05 fedfor puppet-agent[5409]: (/File[/var/lib/puppet/facts.d])
Failed to generate additional resources using 'eval_generate': Connection
refused - connect(2)
Nov 23 11:28:05 fedfor puppet-agent[5409]: (/File[/var/lib/puppet/facts.d])
Could not evaluate: Could not retrieve file metadata for
puppet://fedfor.inreality.com/pluginfacts: Connection refused - connect(2)
Nov 23 11:28:05 fedfor puppet-agent[5409]: (/File[/var/lib/puppet/lib])
Failed to generate additional resources using 'eval_generate': Connection
refused - connect(2)
Nov 23 11:28:05 fedfor puppet-agent[5409]: (/File[/var/lib/puppet/lib])
Could not evaluate: Could not retrieve file metadata for
puppet://fedfor.inreality.com/plugins: Connection refused - connect(2)
Nov 23 11:28:06 fedfor puppet-agent[5409]: Could not retrieve catalog from
remote server: Connection refused - connect(2)
Nov 23 11:28:06 fedfor puppet-agent[5409]: Using cached catalog
Nov 23 11:28:06 fedfor puppet-agent[5409]: Could not retrieve catalog;
skipping run
Nov 23 11:28:06 fedfor puppet-agent[5409]: Could not send report:
Connection refused - connect(2)
Nov 23 11:29:46 fedfor kernel: [ 426.234465] perf samples too long (20057
> 20000), lowering kernel.perf_event_max_sample_rate to 6250
Nov 23 11:30:01 fedfor CRON[6609]: (foreman) CMD ( cd ${FOREMAN_HOME} &&
/usr/sbin/foreman-rake trends:counter >/var/log/foreman/cron.log 2>&1)
Nov 23 11:30:01 fedfor CRON[6610]: (foreman) CMD ( cd ${FOREMAN_HOME} &&
/usr/sbin/foreman-rake ldap:refresh_usergroups >>/var/log/foreman/cron.log
2>&1)
I'll dig back through things and see if there is anything else.
Thanks again!
Carl
···
On Tuesday, December 1, 2015 at 12:24:08 AM UTC-5, stephen wrote:
>
>
>
> ----- Original Message -----
> > From: "Carl Davis" <carl....@inreality.com >
> > To: "Foreman users" <forema...@googlegroups.com >
> > Sent: Monday, November 30, 2015 2:06:35 PM
> > Subject: [foreman-users] Remote Execution questions/issue
> >
> >
> > Greeting all,
> >
> > I am very new to Foreman, so my issues could simply be ignorance. Do
> all
> > the hosts have to be on the same network for the commands to be
> successful
> > using the Remote Execution 0.1 on Foreman 1.10.0-RC-3? When I try to
> run a
> > job, they all time out.
> >
> > 1: Exit status: EXCEPTION
> > 2: Error initializing command #
> > 3: Errno::ETIMEDOUT Connection timed out - connect(2)
> >
> > I am testing out different scenarios to which I need to be able to send
> > remote commands to devices regardless of what network they are on. I
> was
> > running Spacewalk but it wasn't stable on debian based clients. So far
> my
> > testing with Foreman has been excellent.
>
>
> Remote Execution uses SSH, so the particular smart proxy needs to be able
> to reach the host on port 22. It sounds like it can't.
>
>
> >
> > Additionally, when I try to install the Remote Excecution plugin on a
> > debian based system, regardless of a fresh install or not, I get the
> > following error:
> >
> > PG::DuplicateColumn: ERROR: column "version" of relation
> > "dynflow_schema_info" already exists
>
> How are you installing the plugin?
>
> Can you provide more logs? Perhaps the output of `foreman-rake
> db:migrate`,
> and anything that looks interesting in /var/log/foreman.
>
>
> > I was able to get everything to install properly on a CentOS system,
> which
> > is how I am testing the above. What is the appropriate method to report
> an
> > issue with a plugin? Since my linux experience is with Debian bases
> > systems, I would feel more comfortable with getting that working.
> Again,
> > please excuse my lack of knowledge.
> >
> > Thanks!
> >
> > Carl
> >
> > --
> > 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 http://groups.google.com/group/foreman-users.
> > For more options, visit https://groups.google.com/d/optout.
> >
>
> From: "Carl Davis" <carl.davis@inreality.com>
> To: "Foreman users" <foreman-users@googlegroups.com>
> Cc: stephen@redhat.com
> Sent: Tuesday, December 1, 2015 3:20:56 PM
> Subject: Re: [foreman-users] Remote Execution questions/issue
>
> Thanks for the response. Regarding the timeout, I dug further into some of
> the logs of the failed attempts and it appears as if they do indeed need to
> be on the same network or have a FQDN. My use case is that all the hosts
> will be spread all over and sitting on a basic network with no port
> forwarding available. Additionally, I will not be able to set a truly
> FQDN, A records, etc. I was able to get around it by installing NeoRouter
> on the Server and the hosts, then setting the virtual NIC that NeoRouter
> configures (nrtap) as the NIC that execution commands are run on. From
> there, everything worked as expected.
The only requirement is Foreman needs to be able reach the host, which is not
the same thing as in the same network. NeoRouter is a VPN? That sounds awfully
overcomplicated.
We determine the IP we connect to in the following order:
- the IP of the interface marked "execution" (there's a checkbox)
- any interface that has a valid IP
- the IP the FQDN resolves to
DNS shouldn't be a requirement if you have an IP set in Foreman for the host.
Also, thanks for the Debian info below, this helps. We haven't had many testers on
Debian since the developers are mostly all Red Hat people, I appreciate you trying
it out! I'll poke around and see what I can figure out.
···
----- Original Message -----
Regarding the install issues on Debian, I tried two slightly different
methods, but both based off the Plugin Manual found
here: Foreman :: Plugin Manuals My
first attempt was following the Quick Install of Foreman 1.10, enrolled a
few devices to make sure things were working properly, then running
foreman-installer --enable-foreman-plugin-remote-execution
–enable-foreman-plugin-tasks
–enable-foreman-proxy-plugin-remote-execution-ssh
The second attempt was following the Quick Install of foreman and instead
of running just foreman-installer the first time to install foreman, I ran
the above command. There was a third attempt following the Quick Install
followed by the directions for manually installing the plugin. That
resulted in the following error:
ruby-smart-proxy-remote-execution-ssh : Depends: ruby-net-ssh (<= 2.1.0)
but 1:2.6.8-1 is to be installed
Here is the CLI output from the installation, unfortunately I do not recall
if it was the first or second attempt.
root@fedfor:~# foreman-installer --enable-foreman-plugin-remote-execution
–enable-foreman-proxy-plugin-remote-execution-ssh
Execution of ‘/usr/bin/apt-get -q -y -o DPkg::Options::=–force-confold
install ruby-smart-proxy-remote-execution-ssh’ returned 100: Reading
package lists…
/Stage[main]/Foreman_proxy::Plugin::Remote_execution::Ssh/Foreman_proxy::Plugin[remote_execution_ssh]/Package[ruby-smart-proxy-remote-execution-ssh]/ensure:
change from purged to present failed: Execution of ‘/usr/bin/apt-get -q -y
-o DPkg::Options::=–force-confold install
ruby-smart-proxy-remote-execution-ssh’ returned 100: Reading package
lists…
/Stage[main]/Foreman_proxy::Register/Foreman_smartproxy[fedfor.inreality.com]:
Failed to call refresh: Proxy fedfor.inreality.com cannot be registered
(Could not load data from https://fedfor.inreality.com
/Stage[main]/Foreman_proxy::Register/Foreman_smartproxy[fedfor.inreality.com]:
Proxy fedfor.inreality.com cannot be registered (Could not load data from
https://fedfor.inreality.com
Installing Done
[100%]
[…]
Something went wrong! Check the log for ERROR-level output
There was no foreman-installer.log, but this came from /var/log/syslog
Nov 23 11:27:51 fedfor libapache2-mod-passenger: apache2_invoke: Enable
module passenger
Nov 23 11:27:57 fedfor crontab[5037]: (root) LIST (root)
Nov 23 11:28:05 fedfor puppet-agent[5405]: Reopening log files
Nov 23 11:28:05 fedfor puppet-agent[5405]: Starting Puppet client version
3.8.4
Nov 23 11:28:05 fedfor puppet-agent[5409]: Unable to fetch my node
definition, but the agent run will continue:
Nov 23 11:28:05 fedfor puppet-agent[5409]: Connection refused - connect(2)
Nov 23 11:28:05 fedfor puppet-agent[5409]: (/File[/var/lib/puppet/facts.d])
Failed to generate additional resources using ‘eval_generate’: Connection
refused - connect(2)
Nov 23 11:28:05 fedfor puppet-agent[5409]: (/File[/var/lib/puppet/facts.d])
Could not evaluate: Could not retrieve file metadata for
puppet://fedfor.inreality.com/pluginfacts: Connection refused - connect(2)
Nov 23 11:28:05 fedfor puppet-agent[5409]: (/File[/var/lib/puppet/lib])
Failed to generate additional resources using ‘eval_generate’: Connection
refused - connect(2)
Nov 23 11:28:05 fedfor puppet-agent[5409]: (/File[/var/lib/puppet/lib])
Could not evaluate: Could not retrieve file metadata for
puppet://fedfor.inreality.com/plugins: Connection refused - connect(2)
Nov 23 11:28:06 fedfor puppet-agent[5409]: Could not retrieve catalog from
remote server: Connection refused - connect(2)
Nov 23 11:28:06 fedfor puppet-agent[5409]: Using cached catalog
Nov 23 11:28:06 fedfor puppet-agent[5409]: Could not retrieve catalog;
skipping run
Nov 23 11:28:06 fedfor puppet-agent[5409]: Could not send report:
Connection refused - connect(2)
Nov 23 11:29:46 fedfor kernel: [ 426.234465] perf samples too long (20057
20000), lowering kernel.perf_event_max_sample_rate to 6250
Nov 23 11:30:01 fedfor CRON[6609]: (foreman) CMD ( cd ${FOREMAN_HOME} &&
/usr/sbin/foreman-rake trends:counter >/var/log/foreman/cron.log 2>&1)
Nov 23 11:30:01 fedfor CRON[6610]: (foreman) CMD ( cd ${FOREMAN_HOME} &&
/usr/sbin/foreman-rake ldap:refresh_usergroups >>/var/log/foreman/cron.log
2>&1)
I’ll dig back through things and see if there is anything else.
Thanks again!
Carl
On Tuesday, December 1, 2015 at 12:24:08 AM UTC-5, stephen wrote:
----- Original Message -----
From: “Carl Davis” <carl....@inreality.com <javascript:>>
To: “Foreman users” <forema...@googlegroups.com <javascript:>>
Sent: Monday, November 30, 2015 2:06:35 PM
Subject: [foreman-users] Remote Execution questions/issue
Greeting all,
I am very new to Foreman, so my issues could simply be ignorance. Do
all
the hosts have to be on the same network for the commands to be
successful
using the Remote Execution 0.1 on Foreman 1.10.0-RC-3? When I try to
run a
job, they all time out.
1: Exit status: EXCEPTION
2: Error initializing command #
3: Errno::ETIMEDOUT Connection timed out - connect(2)
I am testing out different scenarios to which I need to be able to send
remote commands to devices regardless of what network they are on. I
was
running Spacewalk but it wasn’t stable on debian based clients. So far
my
testing with Foreman has been excellent.
Remote Execution uses SSH, so the particular smart proxy needs to be able
to reach the host on port 22. It sounds like it can’t.
Additionally, when I try to install the Remote Excecution plugin on a
debian based system, regardless of a fresh install or not, I get the
following error:
PG::DuplicateColumn: ERROR: column “version” of relation
"dynflow_schema_info" already exists
How are you installing the plugin?
Can you provide more logs? Perhaps the output of foreman-rake db:migrate,
and anything that looks interesting in /var/log/foreman.
I was able to get everything to install properly on a CentOS system,
which
is how I am testing the above. What is the appropriate method to report
an
issue with a plugin? Since my linux experience is with Debian bases
systems, I would feel more comfortable with getting that working.
Again,
please excuse my lack of knowledge.
Thanks!
Carl
–
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 <javascript:>.
To post to this group, send email to forema...@googlegroups.com
<javascript:>.
Visit this group at http://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+unsubscribe@googlegroups.com.
To post to this group, send email to foreman-users@googlegroups.com.
Visit this group at http://groups.google.com/group/foreman-users.
For more options, visit https://groups.google.com/d/optout.
Stephen,
My issue is that these will be devices that sit behind a firewall/router on
some network somewhere in the country. IT departments won't be setting up
any sort of port forwarding to my devices and some will even restrict
inbound connections. My current test setup is a Foreman instance residing
on a DigitalOcean server. I then have 8 or so devices that are disbursed
between my office, my house, and one or two other locations. Those hosts
are just another device on the network, there is no special demilitarized
zone, port forwarding, etc. So the IP address that gets reported back to
Foreman is 192.168.x.x or 10.0.x.x, essentially private IP addresses. As
such, the Forman instance does not know how to get to 192.168.x.x. Again,
I am just coming up to speed on systems like Foreman and Puppet, so I might
be over or under thinking things.
I tinkered with Spacewalk for a little bit and was able to get remote
commands to work, but they only ran when the host reached out to the
Spacewalk server. They did have a process to where you setup OSAD and
Jabber to tell the host that a "message" was waiting for the host and that
it should check in. However, Spacewalk for Debian was not reliable and
where I am excited about Foreman's reliability. Running Spacewalk, if the
device's network connection dropped at any point, it would not check back
in with the server until the device was rebooted. Many of my devices are
going to be Raspberry Pis, which is the reason for Debian support. I need
to check and see if Puppet has any sort of process similar to OSAD/Jabber.
For the moment, that is where NeoRouter comes in. It is a VPN solution,
but it allows for a "LAN-like" network. It's actually very simple. So far
that has allowed me to circumvent any firewall restrictions that might be
put into place. I am open to hearing how other people are getting around
these potential restrictions, I am certainly all for simplicity.
I'm not opposed to getting up to speed on RedHat, but Debian is my comfort
zone.
Thanks again for all the help and patience while I educate myself.
Carl
···
On Tuesday, December 1, 2015 at 9:47:11 PM UTC-5, stephen wrote:
>
>
>
> ----- Original Message -----
> > From: "Carl Davis" <carl....@inreality.com >
> > To: "Foreman users" <forema...@googlegroups.com >
> > Cc: ste...@redhat.com
> > Sent: Tuesday, December 1, 2015 3:20:56 PM
> > Subject: Re: [foreman-users] Remote Execution questions/issue
> >
> > Thanks for the response. Regarding the timeout, I dug further into some
> of
> > the logs of the failed attempts and it appears as if they do indeed need
> to
> > be on the same network or have a FQDN. My use case is that all the
> hosts
> > will be spread all over and sitting on a basic network with no port
> > forwarding available. Additionally, I will not be able to set a truly
> > FQDN, A records, etc. I was able to get around it by installing
> NeoRouter
> > on the Server and the hosts, then setting the virtual NIC that NeoRouter
> > configures (nrtap) as the NIC that execution commands are run on. From
> > there, everything worked as expected.
>
> The only requirement is Foreman needs to be able reach the host, which is
> not
> the same thing as in the same network. NeoRouter is a VPN? That sounds
> awfully
> overcomplicated.
>
> We determine the IP we connect to in the following order:
>
> - the IP of the interface marked "execution" (there's a checkbox)
> - any interface that has a valid IP
> - the IP the FQDN resolves to
>
> DNS shouldn't be a requirement if you have an IP set in Foreman for the
> host.
>
> Also, thanks for the Debian info below, this helps. We haven't had many
> testers on
> Debian since the developers are mostly all Red Hat people, I appreciate
> you trying
> it out! I'll poke around and see what I can figure out.
>
>
> >
> > Regarding the install issues on Debian, I tried two slightly different
> > methods, but both based off the Plugin Manual found
> > here: http://theforeman.org/plugins/foreman_remote_execution/0.1/ My
> > first attempt was following the Quick Install of Foreman 1.10, enrolled
> a
> > few devices to make sure things were working properly, then running
> >
> > foreman-installer --enable-foreman-plugin-remote-execution
> > --enable-foreman-plugin-tasks
> > --enable-foreman-proxy-plugin-remote-execution-ssh
> >
> > The second attempt was following the Quick Install of foreman and
> instead
> > of running just foreman-installer the first time to install foreman, I
> ran
> > the above command. There was a third attempt following the Quick
> Install
> > followed by the directions for manually installing the plugin. That
> > resulted in the following error:
> > ruby-smart-proxy-remote-execution-ssh : Depends: ruby-net-ssh (<= 2.1.0)
> > but 1:2.6.8-1 is to be installed
> >
> >
> >
> > Here is the CLI output from the installation, unfortunately I do not
> recall
> > if it was the first or second attempt.
> > root@fedfor:~# foreman-installer
> --enable-foreman-plugin-remote-execution
> > --enable-foreman-proxy-plugin-remote-execution-ssh
> > Execution of '/usr/bin/apt-get -q -y -o DPkg::Options::=--force-confold
> > install ruby-smart-proxy-remote-execution-ssh' returned 100: Reading
> > package lists...
> >
> /Stage[main]/Foreman_proxy::Plugin::Remote_execution::Ssh/Foreman_proxy::Plugin[remote_execution_ssh]/Package[ruby-smart-proxy-remote-execution-ssh]/ensure:
>
> > change from purged to present failed: Execution of '/usr/bin/apt-get -q
> -y
> > -o DPkg::Options::=--force-confold install
> > ruby-smart-proxy-remote-execution-ssh' returned 100: Reading package
> > lists...
> > /Stage[main]/Foreman_proxy::Register/Foreman_smartproxy[
> fedfor.inreality.com]:
> > Failed to call refresh: Proxy fedfor.inreality.com cannot be registered
> > (Could not load data from https://fedfor.inreality.com
> > /Stage[main]/Foreman_proxy::Register/Foreman_smartproxy[
> fedfor.inreality.com]:
> > Proxy fedfor.inreality.com cannot be registered (Could not load data
> from
> > https://fedfor.inreality.com
> > Installing Done
> > [100%]
> >
> [........................................................................................................................................................................]
>
> > Something went wrong! Check the log for ERROR-level output
> > * Foreman is running at https://fedfor.inreality.com
> > Initial credentials are admin /
> > * Foreman Proxy is running at https://fedfor.inreality.com:8443
> > * Puppetmaster is running at port 8140
> > The full log is at /var/log/foreman-installer/foreman-installer.log
> >
> >
> > There was no foreman-installer.log, but this came from /var/log/syslog
> > Nov 23 11:27:51 fedfor libapache2-mod-passenger: apache2_invoke: Enable
> > module passenger
> > Nov 23 11:27:57 fedfor crontab[5037]: (root) LIST (root)
> > Nov 23 11:28:05 fedfor puppet-agent[5405]: Reopening log files
> > Nov 23 11:28:05 fedfor puppet-agent[5405]: Starting Puppet client
> version
> > 3.8.4
> > Nov 23 11:28:05 fedfor puppet-agent[5409]: Unable to fetch my node
> > definition, but the agent run will continue:
> > Nov 23 11:28:05 fedfor puppet-agent[5409]: Connection refused -
> connect(2)
> > Nov 23 11:28:05 fedfor puppet-agent[5409]:
> (/File[/var/lib/puppet/facts.d])
> > Failed to generate additional resources using 'eval_generate':
> Connection
> > refused - connect(2)
> > Nov 23 11:28:05 fedfor puppet-agent[5409]:
> (/File[/var/lib/puppet/facts.d])
> > Could not evaluate: Could not retrieve file metadata for
> > puppet://fedfor.inreality.com/pluginfacts: Connection refused -
> connect(2)
> > Nov 23 11:28:05 fedfor puppet-agent[5409]: (/File[/var/lib/puppet/lib])
> > Failed to generate additional resources using 'eval_generate':
> Connection
> > refused - connect(2)
> > Nov 23 11:28:05 fedfor puppet-agent[5409]: (/File[/var/lib/puppet/lib])
> > Could not evaluate: Could not retrieve file metadata for
> > puppet://fedfor.inreality.com/plugins: Connection refused - connect(2)
> > Nov 23 11:28:06 fedfor puppet-agent[5409]: Could not retrieve catalog
> from
> > remote server: Connection refused - connect(2)
> > Nov 23 11:28:06 fedfor puppet-agent[5409]: Using cached catalog
> > Nov 23 11:28:06 fedfor puppet-agent[5409]: Could not retrieve catalog;
> > skipping run
> > Nov 23 11:28:06 fedfor puppet-agent[5409]: Could not send report:
> > Connection refused - connect(2)
> > Nov 23 11:29:46 fedfor kernel: [ 426.234465] perf samples too long
> (20057
> > > 20000), lowering kernel.perf_event_max_sample_rate to 6250
> > Nov 23 11:30:01 fedfor CRON[6609]: (foreman) CMD ( cd ${FOREMAN_HOME}
> &&
> > /usr/sbin/foreman-rake trends:counter >/var/log/foreman/cron.log 2>&1)
> > Nov 23 11:30:01 fedfor CRON[6610]: (foreman) CMD ( cd ${FOREMAN_HOME}
> &&
> > /usr/sbin/foreman-rake ldap:refresh_usergroups
> >>/var/log/foreman/cron.log
> > 2>&1)
> >
> >
> > I'll dig back through things and see if there is anything else.
> >
> > Thanks again!
> >
> > Carl
> >
> > On Tuesday, December 1, 2015 at 12:24:08 AM UTC-5, stephen wrote:
> > >
> > >
> > >
> > > ----- Original Message -----
> > > > From: "Carl Davis" <carl....@inreality.com >
> > > > To: "Foreman users" <forema...@googlegroups.com >
> > > > Sent: Monday, November 30, 2015 2:06:35 PM
> > > > Subject: [foreman-users] Remote Execution questions/issue
> > > >
> > > >
> > > > Greeting all,
> > > >
> > > > I am very new to Foreman, so my issues could simply be ignorance.
> Do
> > > all
> > > > the hosts have to be on the same network for the commands to be
> > > successful
> > > > using the Remote Execution 0.1 on Foreman 1.10.0-RC-3? When I try
> to
> > > run a
> > > > job, they all time out.
> > > >
> > > > 1: Exit status: EXCEPTION
> > > > 2: Error initializing command #
> > > > 3: Errno::ETIMEDOUT Connection timed out - connect(2)
> > > >
> > > > I am testing out different scenarios to which I need to be able to
> send
> > > > remote commands to devices regardless of what network they are on.
> I
> > > was
> > > > running Spacewalk but it wasn't stable on debian based clients. So
> far
> > > my
> > > > testing with Foreman has been excellent.
> > >
> > >
> > > Remote Execution uses SSH, so the particular smart proxy needs to be
> able
> > > to reach the host on port 22. It sounds like it can't.
> > >
> > >
> > > >
> > > > Additionally, when I try to install the Remote Excecution plugin on
> a
> > > > debian based system, regardless of a fresh install or not, I get the
> > > > following error:
> > > >
> > > > PG::DuplicateColumn: ERROR: column "version" of relation
> > > > "dynflow_schema_info" already exists
> > >
> > > How are you installing the plugin?
> > >
> > > Can you provide more logs? Perhaps the output of `foreman-rake
> > > db:migrate`,
> > > and anything that looks interesting in /var/log/foreman.
> > >
> > >
> > > > I was able to get everything to install properly on a CentOS system,
> > > which
> > > > is how I am testing the above. What is the appropriate method to
> report
> > > an
> > > > issue with a plugin? Since my linux experience is with Debian bases
> > > > systems, I would feel more comfortable with getting that working.
> > > Again,
> > > > please excuse my lack of knowledge.
> > > >
> > > > Thanks!
> > > >
> > > > Carl
> > > >
> > > > --
> > > > 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 http://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-user...@googlegroups.com .
> > To post to this group, send email to forema...@googlegroups.com
> .
> > Visit this group at http://groups.google.com/group/foreman-users.
> > For more options, visit https://groups.google.com/d/optout.
> >
>
> Stephen,
>
> My issue is that these will be devices that sit behind a firewall/router on
> some network somewhere in the country. IT departments won't be setting up
> any sort of port forwarding to my devices and some will even restrict
> inbound connections. My current test setup is a Foreman instance residing
> on a DigitalOcean server. I then have 8 or so devices that are disbursed
> between my office, my house, and one or two other locations. Those hosts
> are just another device on the network, there is no special demilitarized
> zone, port forwarding, etc. So the IP address that gets reported back to
> Foreman is 192.168.x.x or 10.0.x.x, essentially private IP addresses. As
> such, the Forman instance does not know how to get to 192.168.x.x. Again,
> I am just coming up to speed on systems like Foreman and Puppet, so I might
> be over or under thinking things.
The way that Foreman can deal with this is you would put a Smart Proxy
in 192.168.x.x network that also has an IP that the foreman can talk to.
It would handle proxying the ssh requests from the Foreman to the
unreachable hosts. You can have many smart proxies.
Spacewalk is a totally different architecture. Your use case might be
supported better by something like Salt whenever we add an execution
provider for it.
···
On Wed, Dec 02, 2015 at 09:12:16AM -0800, Carl Davis wrote:
I tinkered with Spacewalk for a little bit and was able to get remote
commands to work, but they only ran when the host reached out to the
Spacewalk server. They did have a process to where you setup OSAD and
Jabber to tell the host that a “message” was waiting for the host and that
it should check in. However, Spacewalk for Debian was not reliable and
where I am excited about Foreman’s reliability. Running Spacewalk, if the
device’s network connection dropped at any point, it would not check back
in with the server until the device was rebooted. Many of my devices are
going to be Raspberry Pis, which is the reason for Debian support. I need
to check and see if Puppet has any sort of process similar to OSAD/Jabber.
For the moment, that is where NeoRouter comes in. It is a VPN solution,
but it allows for a “LAN-like” network. It’s actually very simple. So far
that has allowed me to circumvent any firewall restrictions that might be
put into place. I am open to hearing how other people are getting around
these potential restrictions, I am certainly all for simplicity.
I’m not opposed to getting up to speed on RedHat, but Debian is my comfort
zone.
Thanks again for all the help and patience while I educate myself.
Carl
On Tuesday, December 1, 2015 at 9:47:11 PM UTC-5, stephen wrote:
----- Original Message -----
From: “Carl Davis” <carl....@inreality.com <javascript:>>
To: “Foreman users” <forema...@googlegroups.com <javascript:>>
Cc: ste...@redhat.com <javascript:>
Sent: Tuesday, December 1, 2015 3:20:56 PM
Subject: Re: [foreman-users] Remote Execution questions/issue
Thanks for the response. Regarding the timeout, I dug further into some
of
the logs of the failed attempts and it appears as if they do indeed need
to
be on the same network or have a FQDN. My use case is that all the
hosts
will be spread all over and sitting on a basic network with no port
forwarding available. Additionally, I will not be able to set a truly
FQDN, A records, etc. I was able to get around it by installing
NeoRouter
on the Server and the hosts, then setting the virtual NIC that NeoRouter
configures (nrtap) as the NIC that execution commands are run on. From
there, everything worked as expected.
The only requirement is Foreman needs to be able reach the host, which is
not
the same thing as in the same network. NeoRouter is a VPN? That sounds
awfully
overcomplicated.
We determine the IP we connect to in the following order:
- the IP of the interface marked “execution” (there’s a checkbox)
- any interface that has a valid IP
- the IP the FQDN resolves to
DNS shouldn’t be a requirement if you have an IP set in Foreman for the
host.
Also, thanks for the Debian info below, this helps. We haven’t had many
testers on
Debian since the developers are mostly all Red Hat people, I appreciate
you trying
it out! I’ll poke around and see what I can figure out.
Regarding the install issues on Debian, I tried two slightly different
methods, but both based off the Plugin Manual found
here: Foreman :: Plugin Manuals My
first attempt was following the Quick Install of Foreman 1.10, enrolled
a
few devices to make sure things were working properly, then running
foreman-installer --enable-foreman-plugin-remote-execution
–enable-foreman-plugin-tasks
–enable-foreman-proxy-plugin-remote-execution-ssh
The second attempt was following the Quick Install of foreman and
instead
of running just foreman-installer the first time to install foreman, I
ran
the above command. There was a third attempt following the Quick
Install
followed by the directions for manually installing the plugin. That
resulted in the following error:
ruby-smart-proxy-remote-execution-ssh : Depends: ruby-net-ssh (<= 2.1.0)
but 1:2.6.8-1 is to be installed
Here is the CLI output from the installation, unfortunately I do not
recall
if it was the first or second attempt.
root@fedfor:~# foreman-installer
–enable-foreman-plugin-remote-execution
–enable-foreman-proxy-plugin-remote-execution-ssh
Execution of ‘/usr/bin/apt-get -q -y -o DPkg::Options::=–force-confold
install ruby-smart-proxy-remote-execution-ssh’ returned 100: Reading
package lists…
/Stage[main]/Foreman_proxy::Plugin::Remote_execution::Ssh/Foreman_proxy::Plugin[remote_execution_ssh]/Package[ruby-smart-proxy-remote-execution-ssh]/ensure:
change from purged to present failed: Execution of ‘/usr/bin/apt-get -q
-y
-o DPkg::Options::=–force-confold install
ruby-smart-proxy-remote-execution-ssh’ returned 100: Reading package
lists…
/Stage[main]/Foreman_proxy::Register/Foreman_smartproxy[
fedfor.inreality.com]:
Failed to call refresh: Proxy fedfor.inreality.com cannot be registered
(Could not load data from https://fedfor.inreality.com
/Stage[main]/Foreman_proxy::Register/Foreman_smartproxy[
fedfor.inreality.com]:
Proxy fedfor.inreality.com cannot be registered (Could not load data
from
https://fedfor.inreality.com
Installing Done
[100%]
[…]
Something went wrong! Check the log for ERROR-level output
There was no foreman-installer.log, but this came from /var/log/syslog
Nov 23 11:27:51 fedfor libapache2-mod-passenger: apache2_invoke: Enable
module passenger
Nov 23 11:27:57 fedfor crontab[5037]: (root) LIST (root)
Nov 23 11:28:05 fedfor puppet-agent[5405]: Reopening log files
Nov 23 11:28:05 fedfor puppet-agent[5405]: Starting Puppet client
version
3.8.4
Nov 23 11:28:05 fedfor puppet-agent[5409]: Unable to fetch my node
definition, but the agent run will continue:
Nov 23 11:28:05 fedfor puppet-agent[5409]: Connection refused -
connect(2)
Nov 23 11:28:05 fedfor puppet-agent[5409]:
(/File[/var/lib/puppet/facts.d])
Failed to generate additional resources using ‘eval_generate’:
Connection
refused - connect(2)
Nov 23 11:28:05 fedfor puppet-agent[5409]:
(/File[/var/lib/puppet/facts.d])
Could not evaluate: Could not retrieve file metadata for
puppet://fedfor.inreality.com/pluginfacts: Connection refused -
connect(2)
Nov 23 11:28:05 fedfor puppet-agent[5409]: (/File[/var/lib/puppet/lib])
Failed to generate additional resources using ‘eval_generate’:
Connection
refused - connect(2)
Nov 23 11:28:05 fedfor puppet-agent[5409]: (/File[/var/lib/puppet/lib])
Could not evaluate: Could not retrieve file metadata for
puppet://fedfor.inreality.com/plugins: Connection refused - connect(2)
Nov 23 11:28:06 fedfor puppet-agent[5409]: Could not retrieve catalog
from
remote server: Connection refused - connect(2)
Nov 23 11:28:06 fedfor puppet-agent[5409]: Using cached catalog
Nov 23 11:28:06 fedfor puppet-agent[5409]: Could not retrieve catalog;
skipping run
Nov 23 11:28:06 fedfor puppet-agent[5409]: Could not send report:
Connection refused - connect(2)
Nov 23 11:29:46 fedfor kernel: [ 426.234465] perf samples too long
(20057
20000), lowering kernel.perf_event_max_sample_rate to 6250
Nov 23 11:30:01 fedfor CRON[6609]: (foreman) CMD ( cd ${FOREMAN_HOME}
&&
/usr/sbin/foreman-rake trends:counter >/var/log/foreman/cron.log 2>&1)
Nov 23 11:30:01 fedfor CRON[6610]: (foreman) CMD ( cd ${FOREMAN_HOME}
&&
/usr/sbin/foreman-rake ldap:refresh_usergroups
/var/log/foreman/cron.log
2>&1)
I’ll dig back through things and see if there is anything else.
Thanks again!
Carl
On Tuesday, December 1, 2015 at 12:24:08 AM UTC-5, stephen wrote:
----- Original Message -----
From: “Carl Davis” <carl....@inreality.com <javascript:>>
To: “Foreman users” <forema...@googlegroups.com <javascript:>>
Sent: Monday, November 30, 2015 2:06:35 PM
Subject: [foreman-users] Remote Execution questions/issue
Greeting all,
I am very new to Foreman, so my issues could simply be ignorance.
Do
all
the hosts have to be on the same network for the commands to be
successful
using the Remote Execution 0.1 on Foreman 1.10.0-RC-3? When I try
to
run a
job, they all time out.
1: Exit status: EXCEPTION
2: Error initializing command #
3: Errno::ETIMEDOUT Connection timed out - connect(2)
I am testing out different scenarios to which I need to be able to
send
remote commands to devices regardless of what network they are on.
I
was
running Spacewalk but it wasn’t stable on debian based clients. So
far
my
testing with Foreman has been excellent.
Remote Execution uses SSH, so the particular smart proxy needs to be
able
to reach the host on port 22. It sounds like it can’t.
Additionally, when I try to install the Remote Excecution plugin on
a
debian based system, regardless of a fresh install or not, I get the
following error:
PG::DuplicateColumn: ERROR: column “version” of relation
"dynflow_schema_info" already exists
How are you installing the plugin?
Can you provide more logs? Perhaps the output of foreman-rake db:migrate,
and anything that looks interesting in /var/log/foreman.
I was able to get everything to install properly on a CentOS system,
which
is how I am testing the above. What is the appropriate method to
report
an
issue with a plugin? Since my linux experience is with Debian bases
systems, I would feel more comfortable with getting that working.
Again,
please excuse my lack of knowledge.
Thanks!
Carl
–
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 <javascript:>.
To post to this group, send email to forema...@googlegroups.com
<javascript:>.
Visit this group at http://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-user...@googlegroups.com <javascript:>.
To post to this group, send email to forema...@googlegroups.com
<javascript:>.
Visit this group at http://groups.google.com/group/foreman-users.
For more options, visit https://groups.google.com/d/optout.
–
Best Regards,
Stephen Benjamin
Red Hat Engineering
