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.
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'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
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 recently updated GitLab to version 7.14, and when I run
sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production
I get the following error
Check GitLab API access: FAILED: Failed to connect to internal API
gitlab-shell self-check failed
Try fixing it:
Make sure GitLab is running;
Check the gitlab-shell configuration file:
sudo -u git -H editor /home/git/gitlab-shell/config.yml
Please fix the error above and rerun the checks.
I have gitlab running behind a reverse proxy with the following rules set up
DNAT net loc:192.168.122.38:22 tcp 2227 - <externalip>
DNAT net loc:192.168.122.38:80 tcp 2280 - <externalip>
DNAT net loc:192.168.122.38:443 tcp 2443 - <externalip>
and gitlab-shell/config.yml looks like
GitLab user. git by default
user: git
# Url to gitlab instance. Used for api calls
gitlab_url: "https://<external_url>:2443/"
# Repositories path
repos_path: "/home/git/repositories"
# File used as authorized_keys for gitlab user
auth_file: "/home/git/.ssh/authorized_keys"
ssh_port: 2227
self_signed_cert: true
Based on the configuration you have described the issue is that gitlab-shell is trying to access GitLab at https://:2443. However, you point out that only ports 22, 80 and 443 are proxied. You need to adjust your gitlab-shell configuration so it either points at localhost at an appropriate port or at port 443 on the external URL.
I have an app running on port 9100 on a remote server serving http pages. After I ssh into the server I can curl localhost 9100 and I receive the response.
However I am unable to access the same app from the browser using http://ip:9100
I am also unable to telnet from my local PC. How do I debug it? Is there a way to traceroute a particular IP and port combination, to see where it is being blocked?
Any linux tools / commands / utilities will be appreciated.
Thanks,
Murtaza
You can use the default traceroute command for this purpose, then there will be nothing to install.
traceroute -T -p 9100 <IP address/hostname>
The -T argument is required so that the TCP protocol is used instead of UDP.
In the rare case when traceroute isn't available, you can also use ncat.
nc -Czvw 5 <IP address/hostname> 9100
tcptraceroute xx.xx.xx.xx 9100
if you didn't find it you can install it
yum -y install tcptraceroute
or
aptitude -y install tcptraceroute
you can use tcpdump on the server to check if the client even reaches the server.
tcpdump -i any tcp port 9100
also make sure your firewall is not blocking incoming connections.
EDIT: you can also write the dump into a file and view it with wireshark on your client if you don't want to read it on the console.
2nd Edit: you can check if you can reach the port via
nc ip 9100 -z -v
from your local PC.
Firstly, check the IP address that your application has bound to. It could only be binding to a local address, for example, which would mean that you'd never see it from a different machine regardless of firewall states.
You could try using a portscanner like nmap to see if the port is open and visible externally... it can tell you if the port is closed (there's nothing listening there), open (you should be able to see it fine) or filtered (by a firewall, for example).
it can be done by using this command: tcptraceroute -p destination port destination IP. like: tcptraceroute -p 9100 10.0.0.50 but don't forget to install tcptraceroute package on your system. tcpdump and nc by default installed on the system. regards
If you use the 'openssl' tool, this is one way to get extract the CA cert for a particular server:
openssl s_client -showcerts -servername server -connect server:443
The certificate will have "BEGIN CERTIFICATE" and "END CERTIFICATE" markers.
If you want to see the data in the certificate, you can do: "openssl x509 -inform PEM -in certfile -text -out certdata" where certfile is the cert you extracted from logfile. Look in certdata.
If you want to trust the certificate, you can add it to your CA certificate store or use it stand-alone as described. Just remember that the security is no better than the way you obtained the certificate.
https://curl.se/docs/sslcerts.html
After getting the certificate use keytool to install it.