How to setup manifest to manage SSH Server Config File Only if the server is Redhat or Ubuntu

July 18, 2013, 12:14 pm

≫ Next: Logging into Puppet Enterprise console from script

I have two things I want to accomplish. I want to setup a manifest to manage the ssh server configuration file, only if the server is Redhat, and ensure that password based login is not possible, and only key based authentication is possible. This manifest/config should also disable root based ssh login. I also want to be able to Restarts the ssh server every time the ssh server configuration file has changed.

↧

Logging into Puppet Enterprise console from script

August 15, 2013, 2:00 pm

≫ Next: cron authentication failure

≪ Previous: How to setup manifest to manage SSH Server Config File Only if the server is Redhat or Ubuntu

I would like to extract some data from the Puppet Enterprise console, and it appears pretty easy to do once authenticated. For instance, I browsed to the URL (PE running in a VM on my machine): https://192.168.216.141/node_classes?format=json This printed a JSON response that I want to parse and use in a script. However, I'm not sure how to gain access to the URL from a script because the console implements its own authentication form. Does anyone have any insight about how to authenticate programmatically? Worst case, I could use Perl's [WWW::Mechanize module](http://search.cpan.org/~jesse/WWW-Mechanize-1.72/), but I hoped for a simpler solution.

↧

cron authentication failure

March 26, 2013, 5:13 am

≫ Next: Problem with active directory authentication

≪ Previous: Logging into Puppet Enterprise console from script

I'm creating a simple cron with puppet and I got the folowing info: notice: /Stage[main]/Four_pm::Puppet_chron/Cron[run-puppet]/ensure: created Authentication failure You (root) are not allowed to access to (crontab) because of pam configuration. notice: /Stage[main]/Four_pm::Puppet_chron/Service[puppet]/ensure: ensure changed 'running' to 'stopped' notice: Finished catalog run in 5.59 seconds I gues it is a config problem bit i'm not so into linux to know the solution

↧

Problem with active directory authentication

March 12, 2014, 11:50 am

≫ Next: HTTP API ACLs in auth.conf make it impossible to specify access rules for specific nodes

≪ Previous: cron authentication failure

Problem with active directory authentication. Enabling active directory authentication overrides local authentication. (i.e I am unable to log in with my local credentials). Is there a reason for this? I edited the code below with my information and replaced objectClass = person with bbjectClass= user. If anyone has another way of doing this please advice. authenticator: - class: CASServer::Authenticators::ActiveDirectoryLDAP ldap: host: ad.example.net port: 389 base: dc=example,dc=net filter: (objectClass=person) auth_user: authenticator auth_password: itsasecret

↧

HTTP API ACLs in auth.conf make it impossible to specify access rules for specific nodes

August 5, 2014, 2:56 am

≫ Next: Verifying that localhost can SSH to localhost.localdomain. [localhost.localdomain] Could not open an SSH connection: Could not establish connection: Authentication failed for user root@localhost.localdomain.

≪ Previous: Problem with active directory authentication

As far as I can tell, it is impossible to specify in auth.conf that an agent is allowed a specific level of access. The problem is that the ACLs match on path and then apply to the allow statement, thus ignoring later statements that applies to the same path. e.g.: path / auth any allow mymachine.mydomain.com If I put this at the top of auth.conf, it successfully lets mymachine do anything. But then it will then ignore all statements below it because it's already applied a rule for "path /". Thus all other agents will be unable to access anything on the puppet master and will give a 403 error on every request. But if I put that example ACL near the bottom of auth.conf, mymachine will be as restricted as usual, because restrictive rules above it have been applied to mymachine. This appears to be a significant limitation in the way ACLs have been implemented, unless I have missed something?

↧

Verifying that localhost can SSH to localhost.localdomain. [localhost.localdomain] Could not open an SSH connection: Could not establish connection: Authentication failed for user root@localhost.localdomain.

September 27, 2014, 12:38 pm

≫ Next: unable to establish connection between agent and master.

≪ Previous: HTTP API ACLs in auth.conf make it impossible to specify access rules for specific nodes

i try to install puppet on a vm-ware server with linux (Centos). After submitting the form localhost:3000 i get the message: Verifying that localhost can SSH to localhost.localdomain. [localhost.localdomain] Could not open an SSH connection: Could not establish connection: Authentication failed for user root@localhost.localdomain. What's the problem and how can i resolve this.

↧

unable to establish connection between agent and master.

October 23, 2014, 9:59 pm

≫ Next: address already in use bind(2)??

≪ Previous: Verifying that localhost can SSH to localhost.localdomain. [localhost.localdomain] Could not open an SSH connection: Could not establish connection: Authentication failed for user root@localhost.localdomain.

I know this question has been asked before in many different variant. I read all the post related to the problem but I cannot get agent and master talking to each other. I boot up 2 vm via vmwork station both running on linuxmint 17. I'll start this thread by telling what's my /etc/hosts and /etc/hostname in client and puppetmaster looks like. In my client's vm my host name in /etc/hostname looks like the following: puppetclient my client's vm hosts in /etc/hosts looks like the following: 127.0.0.1 localhost 127.0.1.1 puppetclient 192.168.75.143 puppetmaster In my master's vm /etc/hostname looks like the following: puppetmaster My master's vm /etc/hosts looks like the following: 127.0.0.1 localhost 127.0.1.1 puppetmaster 192.168.75.144 puppetclient My /etc/puppet/puppet.conf in my master looks like the following: [main] logdir=/var/log/puppet vardir=/var/lib/puppet ssldir=/var/lib/puppet/ssl rundir=/var/run/puppet factpath=$vardir/lib/facter templatedir=$confdir/templates prerun_command=/etc/puppet/etckeeper-commit-pre postrun_command=/etc/puppet/etckeeper-commit-post [master] # These are needed when the puppetmaster is run by passenger # and can safely be removed if webrick is used. ssl_client_header = SSL_CLIENT_S_DN ssl_client_verify_header = SSL_CLIENT_VERIFY my /etc/puppet/puppet.conf in my client looks like the following: [main] logdir=/var/log/puppet vardir=/var/lib/puppet ssldir=/var/lib/puppet/ssl rundir=/var/run/puppet factpath=$vardir/lib/facter templatedir=$confdir/templates prerun_command=/etc/puppet/etckeeper-commit-pre postrun_command=/etc/puppet/etckeeper-commit-post [master] # These are needed when the puppetmaster is run by passenger # and can safely be removed if webrick is used. ssl_client_header = SSL_CLIENT_S_DN ssl_client_verify_header = SSL_CLIENT_VERIFY [agent] server=puppetmaster I have many variant of puppet.conf during my search and I don't feel like posting here. One of the variant is to have `server=puppetmaster`in [main] in both my client and master's vm. Anyways, for all the puppet.conf variants i tried, my first error when I run `sudo puppet agent --test` is always `warning: unable to fetch my node definitoin, but agent run will continue:`the error after that is different for each variant of puppet.conf I implement. Can anyone tell me the right configuration for my setup? Thanks

↧

address already in use bind(2)??

October 31, 2014, 3:51 pm

≫ Next: Samba/CIFS authentication?

≪ Previous: unable to establish connection between agent and master.

Hi All, I'm setting up puppetmaster using linux mint Below is the error. After much google I can't find any answer. sudo puppet master --verbose --no-daemonize Warning: Setting templatedir is deprecated. See http://links.puppetlabs.com/env-settings-deprecations (at /usr/lib/ruby/vendor_ruby/puppet/settings.rb:1134:in `issue_deprecation_warning') Notice: Starting Puppet master version 3.7.2 Error: Could not run: Address already in use - bind(2) *note: the linuxmint is freshly installed. No other puppetmasters or clients are running during this error occur.

↧

Samba/CIFS authentication?

April 11, 2015, 4:37 pm

≫ Next: 403 Forbidden Request -- Puppet Server

≪ Previous: address already in use bind(2)??

What's the best way to authenticate Samba/CIFS users using Puppet (ubuntu trusty x86_64)? I'd rather not leave passwords in cleartext in an *auto.smb.credentials* file.

↧

403 Forbidden Request -- Puppet Server

August 27, 2015, 1:52 pm

≫ Next: puppetlabs-aws: Infrequent Error: Failed to apply catalog: execution expired

≪ Previous: Samba/CIFS authentication?

I'm having issues expanding a puppet-server deployment beyond ten nodes. Specifically, the issue appears to be authentication related, but I cannot track down what would cause it. **Deployment** I have a puppet-server deployment with an external CA. The master certificate is signed by an intermediate certificate and the agent certificates are signed by another intermediate. Both intermediates are signed by the same root. [This is the deployment as described in the Puppet documentation](https://docs.puppetlabs.com/puppet/latest/reference/config_ssl_external_ca.html#option-3-two-intermediate-cas-issued-by-one-root-ca). Additionally, I have a running Puppet DB deploy connected to Puppet. **The Problem** Before the problem started, I had 10 working nodes. I've had no issues with authentication using the external CA (certificates generated using EJBCA). When I attempted to add three additional nodes, each node has the same kind of errors that suggest authentication problems. These errors are 403 errors when running `puppet agent -t`. As an example, when attempting to run puppet, the following happens: # /opt/puppetlabs/bin/puppet agent -t Info: Retrieving pluginfacts Error: /File[/opt/puppetlabs/puppet/cache/facts.d]: Failed to generate additional resources using 'eval_generate': Error 403 on SERVER: Forbidden request: host01.local.test(XXX.XXX.XXX.XXX) access to /puppet/v3/file_metadata/pluginfacts [search] at :124 Error: /File[/opt/puppetlabs/puppet/cache/facts.d]: Could not evaluate: Could not retrieve file metadata for puppet:///pluginfacts: Error 403 on SERVER: Forbidden request: host01.local.test(XXX.XXX.XXX.XXX) access to /puppet/v3/file_metadata/pluginfacts [find] at :124 Info: Retrieving plugin Error: /File[/opt/puppetlabs/puppet/cache/lib]: Failed to generate additional resources using 'eval_generate': Error 403 on SERVER: Forbidden request: host01.local.test(XXX.XXX.XXX.XXX) access to /puppet/v3/file_metadata/plugins [search] at :124 Error: /File[/opt/puppetlabs/puppet/cache/lib]: Could not evaluate: Could not retrieve file metadata for puppet:///plugins: Error 403 on SERVER: Forbidden request: host01.local.test(XXX.XXX.XXX.XXX) access to /puppet/v3/file_metadata/plugins [find] at :124 Error: Could not retrieve catalog from remote server: Error 400 on SERVER: Evaluation Error: Error while evaluating a Function Call, $concat_basedir not defined. Try running again with pluginsync=true on the [master] and/or [main] section of your node's '/etc/puppet/puppet.conf'. at /etc/puppetlabs/code/environments/production/modules/concat/manifests/setup.pp:19:5 on node host01.local.test Warning: Not using cache on failed catalog Error: Could not retrieve catalog; skipping run Error: Could not send report: Error 403 on SERVER: Forbidden request: host01.local.test(XXX.XXX.XXX.XXX) access to /puppet/v3/report/host01.local.test [save] at :124 This happens on only the newest nodes. When I disable the authentication on the puppet server in `/etc/puppetlabs/puppet/auth.conf`, the `puppet agent -t` command completes successfully. So, this suggests that it is tied to the puppet server authentication. Because existing nodes were able to authenticate and run successfully, I revoked an existing certificate and generated a new certificate for one of the known working nodes. When running `puppet agent -t`, the run completes successfully. So, this suggests that the CA - client auth is working as expected since newly generated certificates work for existing nodes. Finally, when I test one of the node's client certificates against the puppet server, it appears to authenticate successfully: [root@host02 /etc/puppetlabs/puppet/ssl]# openssl s_client -host puppetserver.local.test -port 8140 -cert certs/host02.local.test.pem -key private_keys/host02.local.test.pem -CAfile certs/ca.pem CONNECTED(00000003) depth=2 C = US, ST = XXXXXXXX, L = CITY, O = ORGANIZATION, OU = ORGANIZATION Certificate Authority, CN = ORGANIZATION Root CA, emailAddress = email@local.test verify return:1 depth=1 C = US, ST = XXXXXXXX, O = ORGANIZATION, OU = ORGANIZATION Certificate Authority, CN = "ORGANIZATION Intermediate CA, Puppet Master", emailAddress = email@local.test verify return:1 depth=0 CN = puppetserver.local.test, O = "ORGANIZATION", C = US verify return:1 --- Certificate chain 0 s:/CN=puppetserver.local.test/O=ORGANIZATION/C=US i:/C=US/ST=XXXXXXXX/O=ORGANIZATION/OU=ORGANIZATION Certificate Authority/CN=ORGANIZATION Intermediate CA, Puppet Master/emailAddress=email@local.test 1 s:/C=US/ST=XXXXXXXX/O=ORGANIZATION/OU=ORGANIZATION Certificate Authority/CN=ORGANIZATION Intermediate CA, Puppet Master/emailAddress=email@local.test i:/C=US/ST=XXXXXXXX/L=CITY/O=ORGANIZATION/OU=ORGANIZATION Certificate Authority/CN=ORGANIZATION Root CA/emailAddress=email@local.test --- Server certificate -----BEGIN CERTIFICATE----- -----END CERTIFICATE----- subject=/CN=puppetserver.local.test/O=ORGANIZATION/C=US issuer=/C=US/ST=XXXXXXXX/O=ORGANIZATION/OU=ORGANIZATION Certificate Authority/CN=ORGANIZATION Intermediate CA, Puppet Master/emailAddress=email@local.test --- Acceptable client certificate CA names /C=US/ST=XXXXXXXX/L=CITY/O=ORGANIZATION/OU=ORGANIZATION Certificate Authority/CN=ORGANIZATION Root CA/emailAddress=email@local.test /C=US/ST=XXXXXXXX/O=ORGANIZATION/OU=ORGANIZATION Certificate Authority/CN=ORGANIZATION Intermediate CA, Puppet Agent/emailAddress=email@local.test --- SSL handshake has read 3581 bytes and written 5495 bytes --- New, TLSv1/SSLv3, Cipher is AES256-SHA256 Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1.2 Cipher : AES256-SHA256 Session-ID: 55DF7610FB120D65B86CF5AACFDA01A865A1922BB8F71B81F375F2BFA3AFC7D8 Session-ID-ctx: Master-Key: 799ED3E825FE614A1CC0D90D8F9CD9A696228C6077A4D25C6A0C80FE54017647B624F1C1D36D880723005E179924B98E Key-Arg : None Krb5 Principal: None PSK identity: None PSK identity hint: None Start Time: 1440708083 Timeout : 300 (sec) Verify return code: 0 (ok) --- I know Puppet Enterprise has a 10 node limitation, but I'm not running Puppet Enterprise. I'm running `puppetserver-2.1.1-1.el7`. Here are the currently installed puppet-related RPMs: [user@puppetserver]~% rpm -qa | grep puppet puppet-agent-1.2.2-1.el7.x86_64 puppetserver-2.1.1-1.el7.noarch puppetdb-termini-3.1.0-1.el7.noarch puppetlabs-release-pc1-0.9.2-1.el7.noarch **Questions** - Any ideas as to what might be causing these new nodes to fail? - Does Puppet Server have the same 10 node limitation as Puppet Enterprise?

↧

puppetlabs-aws: Infrequent Error: Failed to apply catalog: execution expired

March 7, 2016, 1:57 pm

≫ Next: How to setup manifest to manage SSH Server Config File Only if the server is Redhat or Ubuntu

≪ Previous: 403 Forbidden Request -- Puppet Server

I have a PE Master in AWS which uses the `puppetlabs-aws` module. I have created a user with admin privileges (to be pared down, eventually) for use speicifically for performing Puppet actions on our AWS environment; Creating Instances, routes, DNS entries, etc. Every now and then an action times out and throws the error in the subject. Ex.: # puppet apply --noop --verbose /etc/puppetlabs/code/environments/production/modules/aws_prod/manifests/init.pp Info: Loading facts Info: Loading facts Info: Loading facts Info: Loading facts Info: Loading facts Info: Loading facts Notice: Compiled catalog for puppetmaster.cspops.int in environment production in 0.07 seconds Info: Applying configuration version '1457384334' Error: Failed to apply catalog: execution expired Sometimes this happens each run. Other times it will actually go through and will continue to do so for a brief period of time. # puppet apply --noop --verbose /etc/puppetlabs/code/environments/production/modules/aws_prod/manifests/init.pp Info: Loading facts Info: Loading facts Info: Loading facts Info: Loading facts Info: Loading facts Info: Loading facts Notice: Compiled catalog for puppetmaster.cspops.int in environment production in 0.07 seconds Info: Applying configuration version '1457384457' Notice: /Stage[main]/Main/Ec2_instance[puppet_prov_test]/ensure: current_value absent, should be present (noop) Notice: Class[Main]: Would have triggered 'refresh' from 1 events Notice: Stage[main]: Would have triggered 'refresh' from 1 events Notice: Applied catalog in 11.04 seconds # puppet apply --verbose /etc/puppetlabs/code/environments/production/modules/aws_prod/manifests/init.pp Info: Loading facts Info: Loading facts Info: Loading facts Info: Loading facts Info: Loading facts Info: Loading facts Notice: Compiled catalog for puppetmaster.cspops.int in environment production in 0.07 seconds Info: Applying configuration version '1457384482' Info: Checking if instance puppet_prov_test is running in region us-east-1 Info: Checking if instance puppet_prov_test is stopped in region us-east-1 Info: Starting instance puppet_prov_test in region us-east-1 Notice: /Stage[main]/Main/Ec2_instance[puppet_prov_test]/ensure: changed absent to running Notice: Applied catalog in 11.47 seconds I understand this is likely something on the AWS side, but the error is from the module and doesn't give any further indication as to which direction the troubleshooting should go. Additionally, I never experience this issue when using the `AWS CLI`. I've looked for auth logs in AWS but have not been able to find anything. Has anyone else dealt with this and have something that might shed some light on why this intermittently breaks?

↧