I'm fairly new to doing DevOps stuff in Windows so I think the issue here is a gap in my own knowledge that so far I've been unable to plug despite trawling the web for hours and hours.
I'm using Vagrant to spin up a VM then the Chef Client provisioner to actually provision that VM.
I've configured Vagrant to log in via WinRM using an Administrator account, which then installs and runs chef under that user.
One of the executables I'm installing with Chef installs it's own dependencies (Microsoft SQL Local Database) as the 'SYSTEM' user, and then the program as the Admin user. For some reason, the installation of the exe fails because it can't access the LocalDB server because it's installed as 'SYSTEM'.
In my Chef recipe there is a task to set up the chef client to run as a Windows scheduled task under the 'SYSTEM' user. Is there anyway to get Vagrant to provision the chef client, instruct it what role/recipes I want to use, but only run it under the 'system' user as a scheduled task?
Thanks for any help in advance.
Related
I´m trying to install JBOSS EAP 7.4 on Windows Server as a service and I´m having trouble with two issues. All batch files where executed from the command line (cmd.exe) in admin mode.
Installation of Service with local system account
I´m using the service.bat to install it as a service. When checking in the properties of the service for the user context, it says it was installed under a Local Service user.This leads to numerous errors in the startup log, as the service is not allowed to access the file system in R/W mode. Manually setting this to “Local System Account” solves the problem, it runs just fine.
So, how do I configure the installation script that the service will use “Local System Account” or, how can I grant R/W access to this “Local Service”?
Shutdown
The manual states, that you must use the parameter /jbossuser (and password) for the installation. If I don´t, it is not possible to shut down the service via the Windows Services Tool, timeout…
If I add a user to the installation, it can be shutdown. As long as it runs in the “Local Service” context. If I change it to Local System Account, it doesn´t shutdown anymore, timeout…
Beside, this is a productive installation on a virtual server. It will not be possible to have a permanent, dedicated user on such a machine.
How do I configure this correctly?
Current installation params, generated by the service.bat:
"D:\jboss-eap-7.4.6\jboss-eap-7.4\bin\prunsrv.exe" install MyApp
--DisplayName=MyApp
--Description="JBoss Enterprise Application Platform 7"
--LogLevel=INFO
--LogPath="D:\jboss-eap-7.4.6\jboss-eap-7.4\standalone\log"
--LogPrefix=service
--StdOutput=auto
--StdError=auto
--StartMode=exe
--Startup=manual
--StartImage=cmd.exe
--StartPath="D:\jboss-eap-7.4.6\jboss-eap-7.4\bin" ++StartParams="/c#set#NOPAUSE=Y#&&#standalone.bat#-Djboss.server.base.dir=D:\jboss-eap-7.4.6\jboss-eap-7.4\standalone#--server-config=standalone.xml"
--StopMode=exe
--StopImage=cmd.exe
--StopPath="D:\jboss-eap-7.4.6\jboss-eap-7.4\bin"
++StopParams="/c jboss-cli.bat --controller=localhost:9990 --connect --user=ABC --password='12345' --command=:shutdown"
Any help is appreciated!
I am running Teamcity on a windows VM and have installed the awscli.
I am trying to pull a zip from aws S3. But I get this error:
" aws : The term 'aws' is not recognized as the name of a cmdlet, function, script file"
When I run the command in both cmd and powershell it works just fine.
I have also checked that the awscli path is in both user and system paths.
Any ideas?
I figured it out.
The build agent was not running as a service and was running as a user account that didn't have the correct permissions. Installed a new agent, ran it as a windows service and as a service account.
I hope this helps someone in the future that faces this frustrating issue.
Background : Chef Server Version 12 and a Windows workstation SDK 0.10 targeting windows nodes
I've created recipes and bootstrapped local windows servers into the Chef manager and applied recipes so the very basics are all working.
Question : when running the bootstrap commands for a hosted server (e.g azure / aws) I need the command to come from the Chef Server not the workstation.
I had hoped that the knife.rb with the Chef_server_url would force all commands to come from there.
WireShark shows the WinRM connections trying to come from my workstation.
Is there any setting I can implement that forces this in the knife.rb or elsewhere?
I had tried to add the following from searches but they've not been successful :
chef_zero.enabled false
local_mode false
Is this resolved through Chef Provisioning rather than Chef knife commands?
many thanks in advance for any assistance you can give.
"when running the bootstrap commands for a hosted server (e.g azure / aws) I need the command to come from the Chef Server not the workstation." is not correct. Knife commands that manipulate servers go directly from your workstation, and this is how it is supposed to work. The way the bootstrap functions is it starts the cloud machine using the relevant provider API, then connects to the new VM via SSH or WinRM and installs Chef, and then launches chef-client using a configuration file based on your knife settings (this is where chef_server_url comes in).
I have windows 7_x64 Virtual Machine on Server machine running on Windows Server 2008 R2. I want to run this VM from jenkins (CI tool which executes batch file, running on same server).
I am using vmrun utility to do so.
When i run
vmrun -T ws -gu *** -gp *** start "vmx file path.vmx"
this executes fine on server command prompt (locally). but when i try to exceute the same from any of the client machine (by visiting jenkins site) I get
Error: There was an error in communication
After some troubleshooting, I can say vmrun command is not responding whenever it is evoked remotely. but it is confusing me, because I have jenkins which is running those commands is installed on same server. i am just running job from thin client. how does that make any difference?
Could anyone help me troubleshooting this issue?
Thanks!
For reference:
*Server machine(host): Windows Server 2008 R2
*Virtual machine(guest): Windows 7 x64
*Jenkins : Installed on same server (host)
*client : remote windows machine, accesses the jenkins instance from browser and triggers the job
*problem/error : vmrun commands dont execute.
Jenkins does not execute anything on "client" (i.e. the machine with the browser from which you accessed Jenkins instance). Jenkins will only execute anything on Master (what you called "server machine") or Slave nodes.
Now, there can be several differences between running the command from your local command prompt (on server) and through Jenkins. The primary difference is that Jenkins runs under a separate session, usually under a separate user, which may have different permissions, however that depends on how you have installed and configured the Jenkins session.
To identify if there are any Environment variable differences, type set on your local command prompt, and then execute Jenkins with just set in the build step. Compare the two. Other than Jenkins specific variables, everything else should be same.
Also, verify that your Jenkins user (the one running the service) has permissions to do whatever your are doing.
I installed the Rundeck server in one Linux machine.
Tomcat is running in a Windows 7 machine.
Now, I want to stop and start the Tomcat service in the Windows machine by creating a job in Rundeck (on the Linux machine).
Is it possible?
Yes, this is possible.
Install Cygwin, including openssh-server to the Windows machine. Generate a public key for the Rundeck server user and add it to the .authorized_hosts file on the Windows machine. Ensure you have port 22 or an alternate port accessible for SSH.
In rundeck, create a new job which fires the Tomcat executable or any commands you prefer for starting/stopping the service.
It may help to prefix the Rundeck job command with some $PATH variables if the connecting user account has trouble locating executables in the Windows/Cygwin environment.