I've got a chef deployment script that works well. To start the script off all users a logged off, application installed and then system rebooted with
reboot "app_requires_reboot" do
action :request_reboot
reason "Need to reboot when the run completes successfully."
delay_mins 0
end
Instead of rebooting I want to have the script logon the user instead.
I can't see to find the command to make this work.
Any ideas?
Related
We have a .CMD script that we are triggering from Control-M.
A main.cmd is being called from Control-M. This script is run as 'accnt_svc' service account which we also configured in Control-M. Prior to setting up in Control-M, we testing this running fine when ran from command prompt (as administrator) and via Windows Task Scheduler being run as the 'acct_svc' service account.
When running in Control M, the log shows error saying a subscript (say sub.cmd is being called from main.cmd) saying the sub.cmd is invalid.
We checked the permissions and they both have the same settings.
We tried another script, this time we created a wrapper which 'calls' the main script. This worked fine.
Please check following wrapper:
SET V_CMDDRV=E:
%V_CMDDRV%
CD %V_CMDDIR%
CALL CALL %V_CMDDIR%\main.cmd
When we create a Main_Wrapper.cmd calling the main.cmd this works fine.
May I know why Control-M behaves this way?
Thanks
When issuing a command via Control-M it will by default run from your run as users home directory. From the output you've attached it looks like main.cmd might need to be run from E: instead of the %HOMEPATH% of the acct_svc service account.
I'm getting permissions errors with the create action on windows servers.
Initially I was doing this in one recipe:
directory "C:/topdir" do
rights :full_control, 'Users'
action :create
end
directory "C:/topdir/subdir" do
action :create
recursive true
end
If I run this in test kitchen or even login to a bootstrapped server and run chef-client it completes with no errors.
But I see these errors on Chef server when it runs automatically:
Description: Error executing action `create` on resource 'directory[C:/topdir/subdir]'
Chef::Exceptions::InsufficientPermissions
Cannot create directory[C:/topdir/subdir] at C:/topdir/subdir due to insufficient permissions
It seems I "fixed" this by replacing rights :fullcontrol, 'Users' with rights :fullcontrol, 'Everyone' but I don't want that and it doesn't make sense to me why that would be necessary.
Why is this happening?
Also, how can I test this if the errors only happen during automated chef runs- I can only see errors in chef server reporting. How can I see what user this is even running in? I assumed local system but I guess not? It works running chef-client locally from an elevated prompt so why would it not work when running on schedule?
My knowledge of Windows is limited, but in general I think services get run as a dedicated SYSTEM user, which is not part of the Users group.
I have been trying to configure regular automated backups to a shared network drive using the Windows Server Backup console. When I backup manually, it works, however it does not run on its own as scheduled. I have made sure to enable run backup while not logged in. There are no error messages when it does not run according to schedule, it just skips to logging the next scheduled backup as the next day.
I have also tried using the wbadmin command line. My script is similar to the following:
wbadmin enable backup –addtarget:\backupshare\myshare –include: c:\ –user:DOMAIN\mylogin –password:mypassword –schedule:19:00 -systemState -quiet -allowDeleteOldBackups -
I have not received any errors with my script and the windows command line acknowledges that there is a scheduled backup to run. However, the backup does not run and when I check wbadmin get status at the time it is scheduled, it will tell me there is no back up running at the moment with no error codes.
I am not sure why my back ups will not run as scheduled as they will run manually.
Any help would be greatly appreciated,
Thanks!
I’m going to assume that you’re running it with heightened privileges and for running the task you’re using a Domain Admin account, I would suggest running the command manually from command line and add in this argument “get status > \task.log”
I have Jenkins running on OSX 10.8.2. I will often leave a session logged in and su'd into the Jenkins account.
On occasion I will get a cryptic call/email/text from a socially inept user who say simply that "Jenkins is broken" and attaches a useless log snippet indicating that Jenkins could not talk to a remote host because the keys were invalid. The Jenkins build fails. The first thing I do is a "whoami" on the session I'm logged into.
whoami -> _assetcache
I type "exit"
whoami -> root
sudo su - jenkins
whoami -> jenkins
What causes it to think the user has become _assetcache? Why is it fixed by simply logging back into the account? When I check ownership on the jenkins user files they show _assetserver for the user and group too, but logging out and back in seems to clear the issue every time. Any idea what may be causing the issue?
Thanks
I would still like to know what causes this, but I have a hack that addresses the issue and for whatever reason, as strange as it may seem, it works:
As root I run a cron script once a hour that executes: sudo su - jenkins
I don't consider the problem solved, but at least that's a workaround. Longer term, I'm recommending that we simply move off the OSX platform and onto a AWS platform.
I have a complex script - that Jenkins executes on build - which needs to check for events in /var/log/syslog. In order to do so, I added the user "jenkins" to the group syslog belongs to and set the file permissions to 0640.
The script above runs perfectly fine when manually executed, but when invoked by Jenkins build system it fails: indeed, the output console shows that the script has not the permission to read /var/log/syslog when invoked via Jenkins.
A quick check with whoami shows that the building process runs with "jenkins" as user, though. Hence, I cannot understand why the script behavior is different.
I haven't used jenkins, so this might not be what's going on, but do you know if you are running under SELinux or any other sort of mandatory-access-control system?
That tends to be my knee-jerk reaction to strange permissions issues.
If SELinux is enabled, try checking /var/log/audit/audit.log to see if there are any denials to read /var/log/syslog.
If you are on Linux, the command "getenforce" should tell you whether SELinux is running or not.