Can't login to the mission Portal of a fresh install
160 views
Skip to first unread message
kilia...@gmail.com
Apr 7, 2016, 10:34:58 AM4/7/16
to help-cfengine
I can't log on to the mission center of a newly installed CFEngine (Enterprise version 3.7.3 on Amazon Linux 2016.3). All the
documentation says that the credentials are supposed to be 'admin/admin', but I always get
"This username-password combination is wrong. Please try again."
for an answer.
However, I only get that answer after a very long time, about a minute.
I don't really see how I could have inadvertently changed the default credentials. What's more, I followed the advice in an old thread and
tried to query the server locally via
curl -u admin:admin http://127.0.0.1/api/
This works, and it only works with the password "admin", so I'm pretty sure that the credentials are actually correct and something else is
going wrong.
But what could it be?
documentation says that the credentials are supposed to be 'admin/admin', but I always get
"This username-password combination is wrong. Please try again."
for an answer.
However, I only get that answer after a very long time, about a minute.
I don't really see how I could have inadvertently changed the default credentials. What's more, I followed the advice in an old thread and
tried to query the server locally via
curl -u admin:admin http://127.0.0.1/api/
This works, and it only works with the password "admin", so I'm pretty sure that the credentials are actually correct and something else is
going wrong.
But what could it be?
kilia...@gmail.com
Apr 7, 2016, 11:04:14 AM4/7/16
to help-cfengine
On Thursday, April 7, 2016 at 5:00:15 PM UTC+2, Nick Anderson wrote:
> Thats weird. Can you try restarting the services?
> service cfengine3 restart
Oh, I have, several times.
Jan Bruun Andersen
Apr 15, 2016, 9:08:41 AM4/15/16
to help-c...@googlegroups.com
On Thursday, 7 April 2016 16:34:58 UTC+2, kilia...@gmail.com wrote:
I can't log on to the mission center of a newly installed CFEngine (Enterprise version 3.7.3 on Amazon Linux 2016.3). All the
documentation says that the credentials are supposed to be 'admin/admin', but I always get
"This username-password combination is wrong. Please try again."
I got bitten by that too. I probably need to restart CFEngine on the hub.
However, I only get that answer after a very long time, about a minute.
Make sure that your hub are able to resolve its own hostname both ways. Try this:
$ getent hosts $(hostname -f)
$ getent hosts $(hostname -i)
$ ping -c 1 $(hostname)
Jan Bruun Andersen
Apr 18, 2016, 9:48:56 AM4/18/16
to help-cfengine
Depending on your proxy setup, you might also have to fiddle with the http_proxy, https_proxy and no_proxy environment variables.
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN"><HTML><HEAD><TITLE>Unknown Host</TITLE></HEAD><BODY BGCOLOR="white" FGCOLOR="black"><H1>Unknown Host</H1><HR><FONT FACE="Helvetica,Arial"><B>Description: Unable to locate the server named "<EM>localhost (2)</EM>" --- the server does not have a DNS entry. Perhaps there is a misspelling in the server name, or the server no longer exists. Double-check the name and try again.</B></FONT><HR></BODY></HTML></B></FONT>
<!-- default "Cannot find server." response (502) -->
</BODY>
/var/cfengine/httpd/htdocs/application/libraries/Pest.php line:288
ERROR - 2016-04-18 13:42:47 --> Unable to create user<HEAD><TITLE>Cannot find server.</TITLE></HEAD>
When I used http_proxy to forward all requests to our central proxy-server, the CFEngine installer failed to correctly create a system account (CFE_ROBOT) on the hub because it tried to access the Mission Portal through http://localhost/api . But because of the http_proxy setting, that request got forwarded to the proxy server. For some reason (which I am not clear on) that request then failed with a "Host not found" and the CFE_ROBOT user was not created.
You will see something like this in the /var/cfengine/httpd/htdocs/application/logs/log-<yyyy-mm-dd>.php log-file (silly name):
<!-- default "Cannot find server." response (502) -->
</BODY>
/var/cfengine/httpd/htdocs/application/libraries/Pest.php line:288
ERROR - 2016-04-18 13:42:47 --> Unable to create user<HEAD><TITLE>Cannot find server.</TITLE></HEAD>
You can check that the CFE_ROBOT account is created by running:
echo 'SELECT * FROM USERS;' | /var/cfengine/bin/psql cfsettings
That should show you both the 'admin' user for logging into the Mission Portal and the CFE_ROBOT user.
Pablo Costa
Jul 27, 2016, 9:54:45 PM7/27/16
to help-cfengine
On Friday, April 15, 2016 at 3:08:41 PM UTC+2, Jan Bruun Andersen wrote:
Make sure that your hub are able to resolve its own hostname both ways. Try this:$ getent hosts $(hostname -f)$ getent hosts $(hostname -i)$ ping -c 1 $(hostname)
I understand this is not the same problem but this thread is the only useful stuff I've been able to find so far so I am bumping in here.
I have just upgraded 3.7.2-1 to 3.7.3-1 (debian package) and I am no longer able to log in the mission portal.
I tried to reset the admin password in the cfsettings database, but that was not the problem.
Not really documented, but I found this log file:
/var/cfengine/httpd/htdocs/application/logs/log-2016-07-28.php
And for every login attempt I get these two messages:
ERROR - 2016-07-28 01:22:22 --> login Pest_UnknownResponse Error encountered from API server: SSL: certificate subject name 'cfengine.example.com' does not match target host name 'cfengine' /var/cfengine/httpd/htdocs/application/libraries/Pest.php line:290
ERROR - 2016-07-28 01:22:22 --> Error encountered from API server: SSL: certificate subject name 'cfengine.example.com' does not match target host name 'cfengine'
I've checked Jan's suggestions, everything looks good:
root@cfengine:~# getent hosts $(hostname -f)
192.168.10.10 cfengine.example.com cfengine
root@cfengine:~# getent hosts $(hostname -i)
192.168.10.10 cfengine.example.com cfengine
root@cfengine:~# ping -c 1 $(hostname)
PING cfengine.example.com (192.168.10.10) 56(84) bytes of data.
64 bytes from cfengine.example.com (192.168.10.10): icmp_req=1 ttl=64 time=0.043 ms
--- cfengine.example.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.043/0.043/0.043/0.000 ms
I am pointing at https://cfengine.example.com and the certificate retrieved by the browser shows the FQDN as expected.
I guess there is a place somewehere in /var/cfengine/ where the hub hostname is referred to as "cfengine" instead of "cfengine.example.com" but it turns out "cfengine" is an unfortunate choice for the hub's hostname xD
I might start debugging this Pest.php library but looking at PHP does really hurt my eyes. Maybe someone around here knows the cause or has bumped onto this before.
I got the installer to regenerate the SSL certificates (by erasing the old ones and reinstalling) but I can confirm the certs were good, with the right FQDN.
Thanks & cheers!
Aleksey Tsalolikhin
Jul 27, 2016, 10:53:46 PM7/27/16
to Pablo Costa, help-cfengine
What does the hostname command return, Pablo?
--
You received this message because you are subscribed to the Google Groups "help-cfengine" group.
To unsubscribe from this group and stop receiving emails from it, send an email to help-cfengin...@googlegroups.com.
To post to this group, send email to help-c...@googlegroups.com.
Visit this group at https://groups.google.com/group/help-cfengine.
For more options, visit https://groups.google.com/d/optout.
Pablo Costa
Jul 28, 2016, 5:17:26 AM7/28/16
to Aleksey Tsalolikhin, help-cfengine
It returns "cfengine"
Now I tried to set it to the FQDN, with
hostname cfengine.example.com
Then restarted the cfengine service
Now the output of the hostname returns the FQDN and cfengine is logging me in. But this change is not persistent, it will revert when I reboot the server, and also I am afraid of possible side-effects on the system. It seems there is no consensus about whether the hostname should be the FQDN or the short name [1].
So perhaps the safest approach would be to explicitly configure cfengine's PHP application to use the FQDN, as cfengine is already using that choice at inatall time to create the SSL cert.
Perhaps the current approach works fine in RHEL? This seems a change from 3.7.2 to 3.7.3 though.
What are your thoughts about this?
[1] http://serverfault.com/questions/331936/setting-the-hostname-fqdn-or-short-name
Nick Anderson
Jul 28, 2016, 9:16:45 AM7/28/16
to Pablo Costa, Aleksey Tsalolikhin, help-cfengine
I did some digging.
Can you please try the following:
```
if (CLI === false)
{
$protocol = key_exists('HTTPS', $_SERVER) ? 'https://' : 'http://';
- $config['rest_server'] = $protocol . gethostname() . '/api';
+ // We need a fully qualifed host name (FQDN), not just a hostname,
therefore
+ // this long chain of gethost* functions.
+ $config['rest_server'] = $protocol .
gethostbyaddr(gethostbyname(gethostname())) . '/api';
}
```
Make the changes in
/var/cfengine/share/GUI/application/config/appsettings.php then run the
policy (cf-agent -KI) You should see a repair on appsettings.php in
/var/cfengine/httpd/htdocs/application/config/appsettings.php
Then try to log in.
On 07/28/2016 04:17 AM, Pablo Costa wrote:
> It returns "cfengine"
>
> Now I tried to set it to the FQDN, with
>
> hostname cfengine.example.com <http://cfengine.example.com>
> <http://cfengine.example.com> cfengine
> <mailto:help-c...@googlegroups.com>.
Can you please try the following:
```
if (CLI === false)
{
$protocol = key_exists('HTTPS', $_SERVER) ? 'https://' : 'http://';
- $config['rest_server'] = $protocol . gethostname() . '/api';
+ // We need a fully qualifed host name (FQDN), not just a hostname,
therefore
+ // this long chain of gethost* functions.
+ $config['rest_server'] = $protocol .
gethostbyaddr(gethostbyname(gethostname())) . '/api';
}
```
Make the changes in
/var/cfengine/share/GUI/application/config/appsettings.php then run the
policy (cf-agent -KI) You should see a repair on appsettings.php in
/var/cfengine/httpd/htdocs/application/config/appsettings.php
Then try to log in.
On 07/28/2016 04:17 AM, Pablo Costa wrote:
> It returns "cfengine"
>
> Now I tried to set it to the FQDN, with
>
>
> Then restarted the cfengine service
>
> Now the output of the hostname returns the FQDN and cfengine is logging
> me in. But this change is not persistent, it will revert when I reboot
> the server, and also I am afraid of possible side-effects on the system.
> It seems there is no consensus about whether the hostname should be the
> FQDN or the short name [1].
>
> So perhaps the safest approach would be to explicitly configure
> cfengine's PHP application to use the FQDN, as cfengine is already using
> that choice at inatall time to create the SSL cert.
>
> Perhaps the current approach works fine in RHEL? This seems a change
> from 3.7.2 to 3.7.3 though.
>
> What are your thoughts about this?
>
> [1]
> http://serverfault.com/questions/331936/setting-the-hostname-fqdn-or-short-name
>
>
> On Thu, 28 Jul 2016, 04:53 Aleksey Tsalolikhin,
> <ale...@verticalsysadmin.com <mailto:ale...@verticalsysadmin.com>> wrote:
>
> What does the hostname command return, Pablo?
>
>
> On Jul 27, 2016 6:54 PM, "Pablo Costa" <modul...@gmail.com
> Then restarted the cfengine service
>
> Now the output of the hostname returns the FQDN and cfengine is logging
> me in. But this change is not persistent, it will revert when I reboot
> the server, and also I am afraid of possible side-effects on the system.
> It seems there is no consensus about whether the hostname should be the
> FQDN or the short name [1].
>
> So perhaps the safest approach would be to explicitly configure
> cfengine's PHP application to use the FQDN, as cfengine is already using
> that choice at inatall time to create the SSL cert.
>
> Perhaps the current approach works fine in RHEL? This seems a change
> from 3.7.2 to 3.7.3 though.
>
> What are your thoughts about this?
>
> [1]
> http://serverfault.com/questions/331936/setting-the-hostname-fqdn-or-short-name
>
>
> On Thu, 28 Jul 2016, 04:53 Aleksey Tsalolikhin,
> <ale...@verticalsysadmin.com <mailto:ale...@verticalsysadmin.com>> wrote:
>
> What does the hostname command return, Pablo?
>
>
> On Jul 27, 2016 6:54 PM, "Pablo Costa" <modul...@gmail.com
> <mailto:modul...@gmail.com>> wrote:
>
> On Friday, April 15, 2016 at 3:08:41 PM UTC+2, Jan Bruun
> Andersen wrote:
>
>
> Make sure that your hub are able to resolve its own hostname
> both ways. Try this:
>
> $ getent hosts $(hostname -f)
> $ getent hosts $(hostname -i)
> $ ping -c 1 $(hostname)
>
>
> I understand this is not the same problem but this thread is the
> only useful stuff I've been able to find so far so I am bumping
> in here.
>
> I have just upgraded 3.7.2-1 to 3.7.3-1 (debian package) and I
> am no longer able to log in the mission portal.
>
> I tried to reset the admin password in the cfsettings database,
> but that was not the problem.
>
> Not really documented, but I found this log file:
>
> /var/cfengine/httpd/htdocs/application/logs/log-2016-07-28.php
>
> And for every login attempt I get these two messages:
>
> ERROR - 2016-07-28 01:22:22 --> login Pest_UnknownResponse
> Error encountered from API server: SSL: certificate subject name
> 'cfengine.example.com <http://cfengine.example.com>' does not
>
> On Friday, April 15, 2016 at 3:08:41 PM UTC+2, Jan Bruun
> Andersen wrote:
>
>
> Make sure that your hub are able to resolve its own hostname
> both ways. Try this:
>
> $ getent hosts $(hostname -f)
> $ getent hosts $(hostname -i)
> $ ping -c 1 $(hostname)
>
>
> I understand this is not the same problem but this thread is the
> only useful stuff I've been able to find so far so I am bumping
> in here.
>
> I have just upgraded 3.7.2-1 to 3.7.3-1 (debian package) and I
> am no longer able to log in the mission portal.
>
> I tried to reset the admin password in the cfsettings database,
> but that was not the problem.
>
> Not really documented, but I found this log file:
>
> /var/cfengine/httpd/htdocs/application/logs/log-2016-07-28.php
>
> And for every login attempt I get these two messages:
>
> ERROR - 2016-07-28 01:22:22 --> login Pest_UnknownResponse
> Error encountered from API server: SSL: certificate subject name
> match target host name 'cfengine'
> /var/cfengine/httpd/htdocs/application/libraries/Pest.php line:290
> ERROR - 2016-07-28 01:22:22 --> Error encountered from API
> server: SSL: certificate subject name 'cfengine.example.com
> <http://cfengine.example.com>' does not match target host name
> /var/cfengine/httpd/htdocs/application/libraries/Pest.php line:290
> ERROR - 2016-07-28 01:22:22 --> Error encountered from API
> server: SSL: certificate subject name 'cfengine.example.com
> 'cfengine'
>
> I've checked Jan's suggestions, everything looks good:
>
> root@cfengine:~# getent hosts $(hostname -f)
> 192.168.10.10 cfengine.example.com
> <http://cfengine.example.com> cfengine
>
> I've checked Jan's suggestions, everything looks good:
>
> root@cfengine:~# getent hosts $(hostname -f)
> 192.168.10.10 cfengine.example.com
> <http://cfengine.example.com> cfengine
>
> root@cfengine:~# ping -c 1 $(hostname)
> PING cfengine.example.com <http://cfengine.example.com>
> root@cfengine:~# ping -c 1 $(hostname)
> (192.168.10.10) 56(84) bytes of data.
> 64 bytes from cfengine.example.com <http://cfengine.example.com>
> (192.168.10.10): icmp_req=1 ttl=64 time=0.043 ms
>
> --- cfengine.example.com <http://cfengine.example.com> ping
>
> statistics ---
> 1 packets transmitted, 1 received, 0% packet loss, time 0ms
> rtt min/avg/max/mdev = 0.043/0.043/0.043/0.000 ms
>
> I am pointing at https://cfengine.example.com and the
> certificate retrieved by the browser shows the FQDN as expected.
>
> I guess there is a place somewehere in /var/cfengine/ where the
> hub hostname is referred to as "cfengine" instead of
> "cfengine.example.com <http://cfengine.example.com>" but it
> 1 packets transmitted, 1 received, 0% packet loss, time 0ms
> rtt min/avg/max/mdev = 0.043/0.043/0.043/0.000 ms
>
> I am pointing at https://cfengine.example.com and the
> certificate retrieved by the browser shows the FQDN as expected.
>
> I guess there is a place somewehere in /var/cfengine/ where the
> hub hostname is referred to as "cfengine" instead of
> turns out "cfengine" is an unfortunate choice for the hub's
> hostname xD
>
> I might start debugging this Pest.php library but looking at PHP
> does really hurt my eyes. Maybe someone around here knows the
> cause or has bumped onto this before.
>
> I got the installer to regenerate the SSL certificates (by
> erasing the old ones and reinstalling) but I can confirm the
> certs were good, with the right FQDN.
>
> Thanks & cheers!
>
> --
>
> You received this message because you are subscribed to the
> Google Groups "help-cfengine" group.
> To unsubscribe from this group and stop receiving emails from
> it, send an email to help-cfengin...@googlegroups.com
> <mailto:help-cfengin...@googlegroups.com>.
> hostname xD
>
> I might start debugging this Pest.php library but looking at PHP
> does really hurt my eyes. Maybe someone around here knows the
> cause or has bumped onto this before.
>
> I got the installer to regenerate the SSL certificates (by
> erasing the old ones and reinstalling) but I can confirm the
> certs were good, with the right FQDN.
>
> Thanks & cheers!
>
> --
>
> You received this message because you are subscribed to the
> Google Groups "help-cfengine" group.
> To unsubscribe from this group and stop receiving emails from
> it, send an email to help-cfengin...@googlegroups.com
> <mailto:help-c...@googlegroups.com>.
> Visit this group at https://groups.google.com/group/help-cfengine.
> For more options, visit https://groups.google.com/d/optout.
>
> For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google
> Groups "help-cfengine" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to help-cfengin...@googlegroups.com
> <mailto:help-cfengin...@googlegroups.com>.
> You received this message because you are subscribed to the Google
> Groups "help-cfengine" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to help-cfengin...@googlegroups.com
> To post to this group, send email to help-c...@googlegroups.com
> <mailto:help-c...@googlegroups.com>.
Aleksey Tsalolikhin
Jul 28, 2016, 9:19:01 AM7/28/16
to Pablo Costa, help-cfengine
Thought so. This is the same trouble I've had, and changing the hostname to the FQDN fixes it and lets me log in. :-)
I've been down this path before. As I recall, in the RHEL 5 documentation, Red Hat used to recommend using the FQDN, but they dropped that recommendation in the RHEL 6 version of the docs (now they say it can be either one).
Also, some Oracle applications don't work with the short hostname, so one of my clients uses CFEngine to change hostnames from short form to FQDN.
BTW, it's nice when log messages (shipped to a centralized logging system) have the full-form hostname. :) So whatever you go with, make sure you end up with the FQDN in the logs.
And whatever you pick, just standardize on it. (Make sure all machines have the same standard, even across OSes.)
Best,
Aleksey
ᐧ
ᐧ--
Pablo Costa
Aug 6, 2016, 4:53:06 AM8/6/16
to Nick Anderson, Aleksey Tsalolikhin, help-cfengine
On 28 July 2016 at 15:16, Nick Anderson <nick.a...@cfengine.com> wrote:
I did some digging.
Can you please try the following:
```
if (CLI === false)
{
$protocol = key_exists('HTTPS', $_SERVER) ? 'https://' : 'http://';
- $config['rest_server'] = $protocol . gethostname() . '/api';
+ // We need a fully qualifed host name (FQDN), not just a hostname,
therefore
+ // this long chain of gethost* functions.
+ $config['rest_server'] = $protocol .
gethostbyaddr(gethostbyname(gethostname())) . '/api';
}
```
Make the changes in
/var/cfengine/share/GUI/application/config/appsettings.php then run the
policy (cf-agent -KI) You should see a repair on appsettings.php in
/var/cfengine/httpd/htdocs/application/config/appsettings.php
Then try to log in.
Hey thanks for your work Nick! I've been AFK for a few days, please excuse me for the delay.
I can confirm that upon a reboot the hostname reverted to the short form and the login process was rejecting my attempts, as expected.
And with your patch it works well.
I can confirm that upon a reboot the hostname reverted to the short form and the login process was rejecting my attempts, as expected.
And with your patch it works well.
I see there is a new version of the enterprise edition, both for the hub and for the agents.
I would like to upgrade again; I can't find a detailed changelog so I don't know your patch is already upstream; Have you pushed it or should I file a bug report?
Cheers,
pablo
Aleksey Tsalolikhin
Aug 6, 2016, 8:51:16 AM8/6/16
to Pablo Costa, Nick Anderson, help-cfengine
On Sat, Aug 6, 2016 at 1:52 AM, Pablo Costa <modul...@gmail.com> wrote:
I see there is a new version of the enterprise edition, both for the hub and for the agents.I would like to upgrade again; I can't find a detailed changelog so I don't know your patch is already upstream; Have you pushed it or should I file a bug report?
Dear Pablo,
3.7.4 Changelogs (I found the links in the release announcement on www.cfengine.com/blog):
- Core: https://docs.cfengine.com/docs/3.7/guide-latest-release-whatsnew-changelog-core.html
- Enterprise: https://docs.cfengine.com/docs/3.7/guide-latest-release-whatsnew-changelog-enterprise.html
- Core: https://docs.cfengine.com/docs/3.7/guide-latest-release-whatsnew-changelog-core.html
- Enterprise: https://docs.cfengine.com/docs/3.7/guide-latest-release-whatsnew-changelog-enterprise.html
And it ain't in the changelog. :)
Best,
Aleksey
ᐧ
ᐧNick Anderson
Aug 6, 2016, 8:59:18 AM8/6/16
to Pablo Costa, Aleksey Tsalolikhin, help-cfengine
I pulled that patch from master. I think it's in the 3.9 build, but not in the recently released 3.7.4.
Sent from my mobile device.
Sent from my mobile device.
Reply all
Reply to author
Forward
0 new messages