If I externalise my Puppet module config to a directory outside of Puppet by adding the modulepath / manifestdir settings:
[main]
pluginsync=true
modulepath=/home/user/project/etc/puppet/modules
manifestdir=/home/user/project/etc/puppet/manifests
the agents log the following error:
"Could not evaluate: Could not retrieve information from source(s) puppet://my-dns-name/plugins"
so looks as if they no longer seem to be able to find the Facter facts I have installed in $modulepath//lib/facter ?
If I comment out the modulepath / manifestdir settings and copy the configuration back to the /etc/puppet install directory the agents work fine.
Do I maybe need to set the pluginsource setting also and if so, where to?
Any pointers gratefully appreciated!
Are the permissions on your home directory restricted, e.g. to 0750? The puppetmaster will typically run as a dedicated puppet user rather than root, so it probably can't read a private home directory.
The other possibility is SELinux if you're using it. I'd expect that the files in your home directory aren't labeled to permit access by a puppetmaster process. Do you see any AVC denials in syslog?
Related
We are facing a peculiar problem on one of our 2 environments. A PutFile processor throws the following error
PutFile[id=xxx] Penalizing StandardFlowFileRecord[uuid=xxx,claim=StandardContentClaim [resourceClaim=StandardResourceClaim[id=xxx, container=default, section=1012], offset=94495, length=9778],offset=0,name=xxxxxxxxxxxxxxxx_PROD_20200513020001.json.gz,size=9778] and routing to 'failure' because the output directory /data/home/datadelivery/OUT/Test does not exist and Processor is configured not to create missing directories
After enabling the creation of missing directories, the error changes to:
Could not set create directory with permissions 664 because /data/home/datadelivery/OUT/Test: java.nio.file.AccessDeniedException: /data/home/datadelivery/OUT/TestPutFile[id=xxx...
Based on the error message one would think that it is an issue with file and folder permissions, however, the path /data/home/datadelivery/OUT/Test exists, and the nifi user can access and create files and folders in there as well (verified from the command line). The same folder permissions and ownership rights are configured on our DEV environment, where the PutFile processor works as expected. We could change the configuration to use a different location, but I'd rather find the root cause instead.
Where should I start debugging?
Thank you for your help in advance!
Kind regards, Julius
Strange issue, I would try to set full permission on the folder/file you want to write (ie chmod 777 + chown nifi:nifi + recursively), and see if the error is still there. If not it's kind of a start ...
Restarting the NiFi service solved the problem. The issue was that the Unix user (nifi) was modified months after starting the NiFi service. Most probably this was the reason the PutFile processor wasn't able to access a folder which the nifi unix user could.
Here is the situation. I got a number of hosts that I'd like to maintain via Ansible. The baseline configuration of the hosts like logins/users/etc is controlled by corporate IT overlords, so I can only change things that are related to application not general host setup. Some of the tasks related to application require running as 'root' or some other privileged user.
I do have a password-less sudo access on all the hosts, however all user home directories are located on NFS mounted volume. From my understanding how ansible works it first logs in into the target host as a regular user and places some files into $HOME/.ansible directory, then it switches to root user using sudo and tries to run the stuff from that directory.
But here is the problem. As I mentioned above the home directories are on NFS volume, so after ansible process on the target machine becomes root it can no longer access the $HOME/.ansible directory anymore due to NFS restrictions. Is there a way to tell ansible to put these work files outside of home directory on some non-NFS volume.
There were two parameters for the ansible.cfg configuration file introduced in Ansible 2.1 which allow specifying the location of temporary directory on target and control machines:
remote_tmp
Ansible works by transferring modules to your remote machines, running them, and then cleaning up after itself. In some cases, you may not wish to use the default location and would like to change the path. You can do so by altering this setting:
remote_tmp = ~/.ansible/tmp
local_tmp
When Ansible gets ready to send a module to a remote machine it usually has to add a few things to the module: Some boilerplate code, the module’s parameters, and a few constants from the config file. This combination of things gets stored in a temporary file until ansible exits and cleans up after itself. The default location is a subdirectory of the user’s home directory. If you’d like to change that, you can do so by altering this setting:
local_tmp = $HOME/.ansible/tmp
While doing "sudo puppet agent -t" on puppet agent I am getting below error
Error: Could not retrieve catalog from remote server: Error 400 on SERVER: Permission denied - /etc/puppet/manifests/site.pp
As per the error it seems like my site.pp in my puppet master has not been set correctly, but I checked all the permissions but all seems to be good.
Are there other reasons that I could get this error on my puppet agents?
The puppetmaster process is the one attempting to access /etc/puppet/manifests/site.pp. The correct ownership depends on whether you're running through WEBrick or Apache. Make sure that the puppetmaster user can access the site.pp file. Try changing to the puppetmaster user and make sure you can access the file.
Also, it could be SELinux causing the access problem, if you're using a RedHat based distro.
I have set up ubuntu server on an old pc with webmin as well. I am not sure what was going on but i restarted the server and when it boots it now get this when Apache tries to start.
* Starting web server apache2
apache2: Syntax error on line 237 of /etc/apache2/apache2.conf: Could not open configuration file /etc/apache2/sites-enabled/000-default: No such file or directory
Action 'start' failed.
The Apache error log may have more information.
I have checked this file on this line and it looks like this:
# Include the virtual host configurations:
Include sites-enabled/
I have removed Apache and re installed it but not sure why it still fails.
As also answered by Qben, the issue was an invalid symlink in the sites-enabled folder. Removing the broken symlink and adding a valid one will fix the issue.
You do not have a default site enabled:
/etc/apache2/sites-enabled/000-default: No such file or directory
site-enabled should contain symlinks to files in site-available and I guess your 000-default symlink does not link to a real file in site-available.
I guess this Ubuntu guide might be of interest for you.
One of the reason may be that you might have some site that is not enabled.To check that
Go to /etc/apache2/sites-enabled
Out of many/some [sitename].conf files , one/some may be crossed
Delete those found crossed
Restart apache server
sudo service apache2 restart.
Hope this has helped you , but may be some other reason too. Thank you.
I have been put in charge of an Ubuntu 13 server installation. Apache is configured to use /var/www as the default directory which is correct. The issue is that it seems there is a fallback directory configured that points to /usr/share. So if I type into a browser (www.address.com) it will serve the documents out of /var/www, but if I know the name of a directory in /usr/share and type in (www.address.com/sharedir) then it will serve out of the /usr/share directory. I have looked in the apache config file and default site config file and do not see this association. I do not want this behavior and am concerned that this is the default behavior out of the box.
Can anyone guide me to another areas where this behavior may be controlled/managed.
Thanks for any assistance.
Open your
/etc/apache2/sites-available/default
file and replace
/var/www
to
/path/to/folder/you/wish
save and it will be better to restart apache by
service apache2 restart
Now put website contents to the new location /path/to/folder/you/wish.
Once you changed the Document root of the of the site as mentioned above, Then no files will be fetched from any other location. Hopes this will help you. :)
[SOLVED] After a bunch more digging around I discovered that the user that originally set up this server erroneously put .conf files in the 'conf.d' directory and 'mods-enabled' directory that were routing traffic to the other directories. Sorry to anyone that noodled on this one.