I'm new to puppet. I installed a VM with hostname puppet-mst and installed puppetserver 7 on it. Then I'm trying to sign itself. But to my surprise -- the puppet agent is trying to sign on puppet-mst.suse not puppet-mst. And even I added the item "puppet-mst.suse" to /etc/hosts, it still raises error as "Server hostname 'puppet-mst' did not match server certificate; expected one of puppet-mst.suse, DNS:puppet, DNS:puppet-mst.suse" --
puppet-mst:/etc/puppetlabs/puppet # cat /etc/hosts
127.0.0.1 localhost
192.168.160.131 puppet-mst puppet-mst.suse
puppet-mst:/etc/puppetlabs/puppet # hostname -f
puppet-mst
puppet-mst:/etc/puppetlabs/puppet # hostname
puppet-mst
puppet-mst:/etc/puppetlabs/puppet # cat puppet.conf
[main]
certname = puppet-mst
server = puppet-mst
# This file can be used to override the default puppet settings.
# See the following links for more details on what settings are available:
# - https://puppet.com/docs/puppet/latest/config_important_settings.html
# - https://puppet.com/docs/puppet/latest/config_about_settings.html
# - https://puppet.com/docs/puppet/latest/config_file_main.html
# - https://puppet.com/docs/puppet/latest/configuration.html
[server]
vardir = /opt/puppetlabs/server/data/puppetserver
logdir = /var/log/puppetlabs/puppetserver
rundir = /var/run/puppetlabs/puppetserver
pidfile = /var/run/puppetlabs/puppetserver/puppetserver.pid
codedir = /etc/puppetlabs/code
puppet-mst:/etc/puppetlabs/puppet # puppet agent --test --verbose
Info: Creating a new RSA SSL key for puppet-mst
Info: csr_attributes file loading from /etc/puppetlabs/puppet/csr_attributes.yaml
Info: Creating a new SSL certificate request for puppet-mst
Info: Certificate Request fingerprint (SHA256): 03:C4:E0:86:30:11:E8:4E:36:1A:52:DC:F7:0D:C2:78:E4:7A:D9:80:76:7E:93:92:19:4B:0C:3E:55:B7:0A:7C
Error: Server hostname 'puppet-mst' did not match server certificate; expected one of puppet-mst.suse, DNS:puppet, DNS:puppet-mst.suse
Error: Could not run: Server hostname 'puppet-mst' did not match server certificate; expected one of puppet-mst.suse, DNS:puppet, DNS:puppet-mst.suse
Does anyone know what's issue? -- I certainly put the item "server=puppet-mst" into the puppet.conf, why it still searching for this unknown site -- puppet-mst.suse?
Please kind help. Thanks
Regards
Eisen
Update
certname = puppet-mst
server = puppet-mst
to
certname = puppet-mst.suse
server = puppet-mst.suse
And try running puppet agent -t again.
If that still doesn't work you may need to regenerate the certificates, the steps to do that are here
https://puppet.com/docs/puppet/7/ssl_regenerate_certificates.html
As a general rule it's usefull stick to using the servers fqdn rather than the short name.
I'm presuming if you run facter fqdn you get back puppet-mst.suse
Related
I use puppet in AWS, and I get the following error when Puppet runs:
Puppet:Server hostname 'puppetmaster' did not match server certificate; expected one of puppetmaster.us-east-2.compute.internal, DNS:puppet,
Please find the following configurations:
#master /etc/hosts
ubuntu#puppetmaster:~$ cat /etc/hosts
127.0.0.1 localhost
172.31.16.177 puppetmaster puppet
172.31.19.211 ip-172-31-19-211 #client
#client
ubuntu#ip-172-31-19-211:~$ cat /etc/hosts
127.0.0.1 localhost
172.31.16.177 puppetmaster puppet
172.31.19.211 ip-172-31-19-211
ubuntu#ip-172-31-19-211:~$ cat /etc/puppetlabs/puppet/puppet.conf
# This file can be used to override the default puppet settings.
# See the following links for more details on what settings are available:
# - https://puppet.com/docs/puppet/latest/config_important_settings.html
# - https://puppet.com/docs/puppet/latest/config_about_settings.html
# - https://puppet.com/docs/puppet/latest/config_file_main.html
# - https://puppet.com/docs/puppet/latest/configuration.html
[main]
certname = ip-172-31-19-211
server = puppetmaster
The above are the host files of master and node machine and I have configured puppet.conf file as well in the node machine but still the client machine is not connected to the master.Please someone help me to fix the issue.
Puppet uses cryptographic certificates on both the client side and the server side to authenticate machine identities. The error message shows that this authentication is failing because the certificate the server presents to the client does not identify it as the machine the client expects.
Specifically, the machine expects the server to be identified as "puppetmaster", but that is not one of the identities listed in the cert. ("puppetmaster.us-east-2.compute.internal" is among those identities, but this is not equivalent for the purpose).
There is considerable flexibility in how all this is set up, but for the smoothest experience, one should
Configure the Puppet server and all Puppet clients with fully-qualified, DNS-resolvable hostnames. Do this on each machine before installing any Puppet software on that machine, or at least before starting any Puppet component for the first time.
Do not change Puppet client or server hostnames after Puppet is set up.
Always use the chosen fully-qualified name to connect to the Puppet server. In particular, specify this as the server name in clients' puppet.conf configuration files.
The question is unclear about the exact circumstances in which the error is observed, but probably it occurs on a new client, while initially trying to connect it to the server. In that case the easiest solution would probably be to update the client's puppet.conf to specify the server via the name on its cert: "puppetmaster.us-east-2.compute.internal". That supposes the server can indeed be reached via that name; if not, then a new cert will probably need to be generated for the server.
I have two VMs setup to learn Puppet - one running puppetserver as my master and another as just a Puppet agent for DNS.
The VMs are running in Hyper-V (Windows 10) and are on the same virtual switch.
After setting up the internal DNS server using this Puppet module - https://github.com/ajjahn/puppet-dns my second, DNS VM can no longer connect to the puppetserver. I receive this error on puppet agent -t runs:
Error: Could not request certificate: No route to host - connect(2) for "puppet.myname.homelab" port 8140
On the puppetserver I have reissued its own agent cert, which changed the cert from puppet <sha-omitted> to "puppet.myname.homelab" <sha omitted> (alt names: "DNS:puppet", "DNS:puppet.myname.homelab")
Running puppet agent -t on the puppetserver to update itself works fine post cert renewal.
I am able to successfully perform a nslookup on any of the hosts using the DNS server, and they do resolve with the new myname.homelab domain.
I still have DHCP enabled on my home router, but I have it set to be the second nameserver in /etc/resolv.conf on both VMs:
search myname.homelab
nameserver 192.168.1.107
nameserver 192.168.1.1
I am running Ubuntu 16.04 and Puppet 4 on both VMs. I have allowed port 8140 in UFW on both VMs, and have even tried disabling UFW with no luck.
I'm still learning Puppet and am a novice to networking, so any suggestions on what else to try and to point me in the right direction would be appreciated.
Thanks!
I slept on it and realized this morning that my router had reassigned my Puppetserver to a new IP, so the DNS A record for it was wrong, even though it was manually assigned in the router's DHCP.
Correcting that did the trick and now everything is working.
Same issue but another cause: the firewwall on the puppet server blocked port 8140. The can be checked on the client as follows:
$ curl -k -I https://puppet:8140
curl: (7) couldn't connect to host
After disabling the firewall on the server (e.g. systemctl stop firewalld):
$ curl -k -I https://puppet:8140
HTTP/1.1 404 Not Found
Date: Thu, 24 Oct 2019 11:27:26 GMT
Cache-Control: must-revalidate,no-cache,no-store
Content-Type: text/html; charset=ISO-8859-1
Content-Length: 278
Server: Jetty(9.2.z-SNAPSHOT)
which is the expected output, and also the puppet agent runs as expected.
I have the guest's HTTPS port set to 443 on it's Apache 2 installation.
In Vagrantfile
I have vm.forwarded_port set to forward from 443 to 8443
I have vm.hostname set to actualdomain.org
I've also installed the vagrant plugin install vagrant-hostsupdater so that actualdomain.org is written to my hosts file, so it pulls up the developer environment and not the actual site when it is requested.
List item
I ran vagrant connect...
I ran vagrant share --https 443 --domain actualdomain.org but it reports the following:
==> default: Detecting network information for machine...
default: Local machine address: 192.168.xx.10
default: Local HTTPS port: 443
==> default: Checking authentication and authorization...
==> default: Creating Vagrant Share session...
There was an error returned by the Vagrant Cloud server. The
error message is shown below:
Domain cannot be used with this account
But if I run vagrant share without the --domain parameter, I end up with the following in my logs when I try to contact the site remotely:
Hostname XXXXX-YYY-ZZZZ provided via SNI and hostname XXXXX-YYY-ZZZZ.vagrantshare.com provided via HTTP are different
And in the browser I am returned an HTTP 400 Bad Request.
Is there any easy way around this? It seems to me that this didn't happen the last time I used vagrant, and it seems as though there was something added to TLS that causes it to balk about the SNI error since then.
I even tried adding a server alias that was the same as the XXXXX-YYY-ZZZ.vagrantshare.com, and it still is giving me an issue; does that mean that I have to rebuild the certificate everytime the hashicorp URL changes if I want to show it off to somebody via their browser?
I have configured puppet master as explained in https://docs.puppetlabs.com/guides/install_puppet/post_install.html.
I started and it's running as, (Master cert has been generated to correctly to the hostname correctly)
[root#puppetmaster private_keys]# ps -aef | grep puppet
j2ee 2162 2160 0 08:08 ? 00:00:04 /usr/libexec/mysqld --defaults-file=/home/j2ee/.local/share/akonadi/mysql.conf --datadir=/home/j2ee/.local/share/akonadi/db_data/ --socket=/home/j2ee/.local/share/akonadi/socket-puppetmaster.ms.com/mysql.socket
puppet 2981 1 0 08:49 ? 00:00:01 /usr/bin/ruby /usr/bin/puppet master --no-daemonize
root 3292 2527 0 09:37 pts/1 00:00:00 grep --color=auto puppet
And puppet master is listening to port 8140
tcp 0 0 0.0.0.0:8140 0.0.0.0:* LISTEN 2981/ruby
But I am unable to generate create certificate signing requests from puppet agents.
[root#puppetagent1 j2ee]# puppet agent --test
Error: Could not request certificate: getaddrinfo: Name or service not known
Exiting; failed to retrieve certificate and waitforcert is disabled
can some one help me to identify / Debug this issue ?
Appreciate any one can introduce me a good complete tutorial to configure puppet masters and agents, I have followed this http://middlewaresnippets.blogspot.co.nz/2015/03/configure-linux-using-puppet.html and it's a good uscase/tutorial but I feel something missing on installing and configuring puppet-agent, may be I am wrong. (Not sure what would be the puppet.conf for puppet agent )
Thanks !
Elike!
Check on client side if you have communication with server by using ping and after telnet on port 8140 (default), collecting server from config:
puppet config print | grep -w server
After check the certificate name for the client:
puppet config print certname
And after, remove the directory of ssl files and dirs:
puppet config print | grep ssldir
rm -rf <ssldir_output>
On Server side, remove all information about the client node as root:
puppet node clean <clientServerName>
puppet node deactivate <clientServerName>
puppet cert --revoke <clientCertName>
puppet cert --clean <clientCertName>
On client side again, call puppet agent test:
puppet agent --test --waitforcert 60
Go to server, list and sign the client certificate:
puppet cert --list
puppet cert --sign <commandAboveOutput> (Just the client server name)
On client side the puppet will continue and start the configuration.
I'm following the Micro cloud Foundry Quick-Start guide here:
http://support.cloudfoundry.com/entries/20316811-micro-cloud-foundry-getting-started-guide
I'm on step 10: registering a new user and I'm not able to connect:
$ vmc target api.lsmith.cloudfoundry.me Host is not available or is
not valid: 'http://api.lsmith.cloudfoundry.me' Would you like see the
response? [yN]: y HTTP exception: Errno::ECONNREFUSED:Connection
refused - connect(2)
My VM is in NAT mode. The Current Configuration in my VM is listed as:
Current Configuration: Identity: lsmith.cloudfoundry.me (ok) IP
Address: 172.16.x.x (network up)
When I run the host command in my console I get:
$ host api.lsmith.cloudfoundry.me api.lsmith.cloudfoundry.me is an
alias for lsmith.cloudfoundry.me. lsmith.cloudfoundry.me has address
127.0.0.1
I'm not able to reach the vmc target in my browswer but when I visit http://172.16.x.x/info I get:
VCAP ROUTER: 404 - DESTINATION NOT FOUND
I think this is a DNS issue but have no idea what I need to do to fix it. I tried changing the nameserver IP in my /etc/resolv.conf from 127.0.0.1 to 172.16.x.x but that didn't work.
I was able to resolve this by reconfiguring my domain (option 4 in the VM) using a newly generated domain token at https://micro.cloudfoundry.com/dns