I'm running Puppet Agent as a service on Windows but I'm unable to find in the docs how to modify the default behaviour --logdest eventlog to --logdest <FILE>. I want to have agent logs stored in a file, and not in the Windows Event Log, or better - if that's possible - have them sent back to the Puppet Master.
You can add the --logdest to the 'ImagePath' value located in this registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\pe-puppet
We add the switch through puppet code after the agent is installed, meaning that the first run output goes to the event log, but all the subsequent are sent to the local file. You can also modify the reg key during install through a powershell script.
Related
I have a python command line program that can retrieve passwords for me.
I can run it from the command line and get the passwords.
Example command:
passwordmanpro_cli javaprops OpenWeatherMap_DEV
The response comes back fine.
I have the Jenkins agent installed on the machine. I have a "Execute Windows Batch Command" step which calls exactly the same commandline.
This USED to work without an issue. A month ago it stopped working. With an error:
ERROR Success not returned from passwordmanagerpro
Using URL - https://icsecpws.cc.ic.ac.uk:443/restapi/json/v1/resources (AUTHTOKEN ommitted - 36)
ResponseCode - 200
resJSON - {'operation': {'name': 'Authentication', 'result': {'status': 'Failed', 'message': 'User is not allowed to access from this host'}}}
IP Being used to send message might be: 155.198.31.184
Something is different from how this request is sent via a windows terminal and how it is sent from a windows batch step in Jenkins.
I have verified the windows batch command is being run as a correct user.
I have verified the username and password credentials being passed are the same
I have verified the source IP by adding debug lines in python.
The password manager we are using has an API user setup and you enter an IP address the API is allowed to be called from. Apparently the restriction is not done on source IP but a reverse hostname lookup.
Can anyone give me advice on how to debug this further?
Update 1
More debugging has revealed that the cause is the environment is being set wrong. The host machine is windows 10. I have an environment variable called PASSMANCLI_AUTHTOKEN and another called PASSMANCLI_URL
In control panel I am setting both variables system wide. NOT for a particular user.
What is really strange is that the PASSMANCLI_URL is changing and being picked up ok, but the PASSMANCLI_AUTHTOKEN variable is not. I have added a "set" windows batch command in the config and I have confirmed that the PASSMANCLI_AUTHTOKEN value is NOT coming from the system setting but somewhere else. I am wondering if Jenkins does anything special with this.
BTW: I have also used the whoami command as part of the project config and confirmed Jenkins is running as the same user.
Update 2
I have gone through the entire windows registery and looked at all Environment entries and deleted PASSMANCLI_AUTHTOKEN. I have confirmed it is not in the environment console. I have restarted the Jenkins agent and the entire server. I then run my jenkins job with a single command "Set" and it reads back the OLD value of the token!
update 3
I have created a brand new Jenkins job with 1 step which is the windows batch command. It simply has "set" so displays the environment variables. I can see PASSMANCLI_AUTHTOKEN is still being set even though I have completely wiped it from the machine.
update 4
I thought it might be something to do with the way the Jenkins runner uses JAVA. (Our Jenkins runner is using Java 8 32 bit). I wrote a Java program which runs
processBuilder.command("cmd.exe", "/c", "set");
and outputs the result.
I checked the output and the variable is NOT set, as expected.
I still don't know where this variable is coming from when executed via Jenkins.
I have an ansible script that starts puppet agent and then waits for /var/lib/puppet/state/agent_catalog_run.lock file.
I found that this file is not getting created on target machine.
Ansible version is: 1.9.7 and puppet agent version is: 3.8.7
I checked on target linux machine and puppet agent is in running state.
Below is ansible script line:
- name: ensure that puppet lock file is created
wait_for:
path: /var/lib/puppet/state/agent_catalog_run.lock
timeout: 1800
What are things that should be checked in this scenario ?
(Note: No puppet logs have been created.)
The code is simply checking for the wrong file.
As the name suggests, the agent_catalog_run.lock is:
A lock file to indicate that a puppet agent catalog run is currently in progress. The file contains the pid of the process that holds the lock on the catalog run.
In other words, that file will only be there if a Puppet agent run is occurring.
You may want the pidfile instead, which is:
The file containing the PID of a running process. This file is intended to be used by service management frameworks and monitoring systems to determine if a puppet process is still in the process table.
Default: $rundir/${run_mode}.pid
(Where $run_mode would be "agent".)
Note that you can inspect your actual settings using puppet config print, e.g.:
▶ puppet config print pidfile
/Users/alexharvey/.puppetlabs/var/run/main.pid
Yours will be different because mine is running as the non root user on a Mac OS X laptop. Thus, I think you will need to change your code to:
- name: wait for the puppet PID file to be created
wait_for:
path: /var/run/agent.pid
timeout: 1800
I'm trying to install weblogic server on Centos 7 with following instruction of oracle about console mode. Everything will be fine till weblogic file 's extracting on my computer. I get this message about
display enviroment variable failed
I google it and found xming as solution. But is there any solution to install weblogic without xming.
You need to do a silent install as mentioned. You can find the documentation here.
Basically, you need two files:
A response file
Here, you will set some parameters like ORACLE_HOME, proxy information if needed and installation type, etc.
An oraInst.loc file
In this file, you need to do the following(from documentation):
Replace oui_inventory_directory with the full path to the directory where you want the installer to create the inventory directory. Then, replace oui_install_group with the name of the group whose members have write permissions to this directory.
After doing all of this, you can run the command as follows;
java -jar distribution_name.jar -silent -responseFile file [-options] [()*]
I uploaded my own oraInst.loc and response files here for demonstration. I strongly suggest you to read the documentation though. Good luck.
We have a Jenkins instance running on Ubuntu that has several slaves in different systems. One of them is a Windows 7 host, having jenkins slave instance configured as a service.
We have a problem that when that machine is rebooted, master Jenkins doesn't realize it's gone. It looks to be just fine in the nodes view. Then, when a build is issued that is supposed to use that slave it gets stuck. If that is stopped, the next build fails immediately
Caused by: java.util.concurrent.TimeoutException: Ping started at 1457016721684 hasn't completed by 1457016961684
... 2 more
[EnvInject] - [ERROR] - SEVERE ERROR occurs: channel is already closed
When the slave has started up and it tries to connect back to master, connection is refused, and in the logs there is an error saying connection with that name already exists:
Server didn't accept the handshake: xxx is already connected to this master. Rejecting this connection.
There is issue JENKINS-5055 which claims a fix was committed allowing the same JNLP slave to reconnect without getting rejected, apparently this commit, and according to changelog, it was introduced in version 1.396 (2011/02/02). We are however using version 1.639 and seeing this. Somebody else seems to be seeing it as well. By looking at current codebase, I see where the error is coming from, but don't see the fix done in Jenkins-5055.
Any ideas on resolving this?
Edit: also asked on jenkins user mailing list, but no responses.
We faced the same issue. Used https://wiki.jenkins-ci.org/display/JENKINS/slave-status as workaround
Reinstalling the slave on a Windows Server 2012 R2 machine shows no signs of this behavior, so it seems that either there was a mistake done during installation steps or this is something caused by using a workstation Windows version.
Regardless, here were the steps to get it working, assuming a brand new installation of Windows, with no network connectivity, and master instance using a self-signed certificate:
Install JRE on the machine. If you have 64-bit operating system, install both 32-bit and 64-bit, otherwise go with 32-bit. Download link here
Install .NET 3.5 on the machine. This is needed by the Jenkins service. You can follow the steps outlined by my other answer for this.
Install Jenkins using Windows installer (.zipped) to C:\Jenkins. It can be downloaded from here.
Check your installation is responding by navigating to http://localhost:8080 . In case of trouble, check for logs in the jenkins folder. If there is a port conflict, edit jenkins.xml and change the httpPort to something else.
From the Windows computer, navigate to your master jenkins and configure a new node there.
Start a slave agent using Java Launch Agent in configure -> node screen (you need to be still using your Windows slave computer)
You should see a visible window opening. From there, select File -> Install as a service. (details and screenshots) If you experience an error without proper explanation, confirm .NET 3.5 is properly installed. If you see "WMI.WmiException: AccessDenied", save the jnlp file locally and start it from administrator prompt or otherwise with elevated privileges (details).
From the Administrative tools -> Services, stop and disable the Jenkins service, and stop Jenkins Slave Agent but leave it on Automatic so it will start up when starting up the computer.
This is only relevant if you're using a self-signed or otherwise problematic certificate:
download the previously mentioned Java Launch Agent file (.jnlp file) again and save it to C:\jenkins
open c:\jenkins\jenkins-slave.xml to your editor
change it to refer to your local .jnlp file by changing jnlp url parameter (file:/C:/jenkins/jenkins-slave.jnlp)
add -noCertificateCheck to parameters
replace the -secret parameter with -auth "user:pass", since otherwise automatic url get parameters will be added which will mess finding the .jnlp file
Start the Jenkins Slave Agent service again
For problems with jenkins slave service, check out jenkins-slave.err.log. For Windows Server 2012 R2, you can get the functionality of tail by using Get-Content .\jenkins-slave.err.log -Wait -Tail 10 in Powershell prompt. For older versions of Powershell, leave out -Tail 10.
I just installed nodejs on one of my build servers (Win Server 2008 R2) which hosts a Bamboo remote agent. After completing the installation and doing a reboot I got stuck in the following situation:
The remote Bamboo build agent is running as a windows service with user MyDomain\MyUser. When a build with an inline powershell task is executing it fails with the error (from the build agent log):
com.atlassian.utils.process.ProcessNotStartedException: powershell could not be started
...
java.io.IOException: Cannot run program "powershell"
...
java.io.IOException: CreateProcess error=2, The system cannot find the file specified
Loggin on to the server as MyDomain\MyUser, I have checked that powershell is in the path:
where powershell
C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
I have tried to restart the service and reboot the machine multiple times. No luck. The only thing that works is if I execute my scripts as a bat file with an absolute path to powershell - but I do not want that.
I have searched for solutions on this, but even though this one seems related: Hudson cannot find powershell after update to powershell 3 - the proposed solutions do not work.
What am I missing here?
If you do a default installation of nodejs you will see that it adds nodejs and npm to the path. Sometimes I have seen that the installer adds a user variable named PATH - it might be that the Bamboo agent decides to read the user path without "merging" it with the system path. I think it would be worth a try to give that a look.
As per Atlassian support page, this is related to a bug in Java Service Wrapper. I tried Workaround-2 since there was no user PATH variable in my system. I had to uninstall bamboo agent service and Java 64 versions from the agent machine to apply the workaround-2.