Until we can implement our new HEAT SM system i am needing to create some workflows to ease our currently manual user administration processes.
I intend to use Powershell to execute the actual tasks but need to use VBS to send an argument to PS from an app.
My main question on this project is, Can an argument be sent to an already running Powershell process?
Example:
We have a PS menu app that we will launch in the AM and leave running all day.
I would love for there to be a way to allow PS to listen for commands/args and take action on them as they come in.
The reason I am wanting to do it this way is because one of the tasks needs to disable exchange features and the script will need to establish a connection a remote PSsession which, in our environment, can take between 10-45 seconds. If i were to invoke the command directly from HEAT (call-logging software) it would lock up while also preventing the tech from moving on to another case until the script terminates.
I have searched all over for similar functionality but i fear that this is not possible with PS.
Any suggestions?
I had already setup a script to follow this recommendation but i was curious to see if there was a more seamless approach
As suggested by one of the comments by #Tony Hinkle
I would have the PS script watch for a file, and then have the VBScript script create a file with the arguments. You would either need to start it on another thread (since the menu is waiting for user input), or just use a separate script that in turn starts another instance of the existing PS script with a param used to specify the needed action
Related
I'm using Ubuntu. I have two bash script files. Both will run in parallel. Now I want to continuously monitor on another file that it is running or not.
So any way to find that the file is currently executing or not ?
Numerous possibilities, it is a question of creativity...
Some suggestions:
periodically poll the process list and filter it by name or process id
start the script with control sockets, as long as the sockets are open the script runs
use the usual locking strategy in file system.
have the script do a lifebeat on a regular base, then watch that lifebeat.
start the script in a series of commands, the moment the script exists the next command will be executed by the calling shell. That one could be a notification script or something.
have the script do some wiggling on your desktop and watch it yourself.
start it using nohup and watch the log file.
implement a deamon inside the script and connect periodically.
open a file from within the script and watch the file system using the fuser system call.
periodically write a token into a file by the monitoring script and have the monitored script remove that token, like a baton.
call the script using a blocking call. The script executes as long as that blocking call does not return.
create a singleton strategy on process level and simply try starting it periodically.
make the monitoring script act as a monitor deamon the executing script connects to. If the connection is terminated the scipt obviously has stopped executing.
...
Sorry, this starts getting boring...
I have a script that pulls some data from a web service and populates a mysql database. The idea is that this runs every minute, so I added a cron job to execute the script.
However, I would like the ability to occasionally suspend and re-start the job without modifying my crontab.
What is the best practice for achieving this? Or should I not really be using crontab to schedule something that I want to occasionally suspend?
I am considering an implementation where a global variable is set, and checked inside the script. But I thought I would canvas for more apt solutions first. The simpler the better - I am new to both scripting and ruby.
If I were you my script would look at a static switch, like you said with your global variable, but test for a file existence instead of a global variable. This seems clean to me.
Another solution is to have a service not using crontab but calling your script every minute. This service would be like other services in /etc/init.d or (/etc/rc.d depending on your distribution) and have start, stop and restart commands as other services.
These 2 solutions can be mixed:
the service only create or delete the switching file, and the crontab line is always active.
Or your service directly edits the crontab like this, but
I prefer not editing the crontab via a script and the described technique in the article is not atomic (if you change your crontab between the reading and the writting by the script your change is lost).
So at your place I would go for 1.
Is there way to invoke a CakePHP console shell on server without shell access? I have written a shell for performing some once off (and hence not a cron task) post DB upgrade tasks.
I could always just copy the logic into a temporary controller, call its actions via http and then delete it, but was wondering if there was a better way to go about it.
It seems that this is a one off script you might want to typically be running after DB updates right?
If that's the case, you can make it part of your "DB update script"
If you use anything like capistrano, you can include there too.
In all cases, if you don't want to touch the shell, I agree that having a controller to call the console code (or any php file running exec() as mentioned previously) would do the trick.
Also, if you want to run it just once and have it scheduled - don't forget that you have the "at" command (instead of cron) which will run it at that scheduled date (see http://linux.about.com/library/cmd/blcmdl1_at.htm)
Hope it helps,
Cheers,
p.s: if its a console shell and you don't want to run it from the console, then just don't make it a console shell.
I have to agree with elvy. Since this is something that you need to do once in a while after other events have happened, why not just create an 'admin' area for your application and stick code for that update in there?
you may be able to use php's exec function to call it from any old php script.
http://www.php.net/exec
I'm using an AutoIt script to start and automate a GUI application. I need to activate the script each hour.
Will AutoIt scripts (which perform actions on a GUI) work when used as a service? The script will be run as a service (not scheduled task).
You can easily make an autoit script run as a service using service.au3 written by archer of the autoit forums. Unfortunately or fortunately since it is a security measure. A service needs to start independent of the current user session (before login). It cant access send APIs for input manipulation of the current user session from there. It does sound much more like you need a scheduled task and not a service.
As mentioned above, a scheduled task is what you're looking for. To run a script as a service read this:
Q4. How can I run my script as a service?
This is also a question with multiple answers, and none of them are the only way to do it. The first question to ask yourself is whether or not you wish to install the service on other computers besides your own.
A1. If you only wish to install the service on your own computer, The easiest way to do this is to use Pirmasoft RunAsSvc. This program makes services easy to install and easy to remove when necessary.
A2. If you wish to make the service available to anyone running your script, you can use SRVANY.EXE and ServiceControl.au3. You can then use this code to install your script as a service:
#include "ServiceControl.au3"
$servicename = "MyServiceName"
_CreateService("", $servicename, "My AutoIt Script", "C:\Path_to_srvany.exe", "LocalSystem", "", 0x110)
RegWrite("HKLM\SYSTEM\CurrentControlSet\Services\" & $servicename & "\Parameters", "Application", "REG_SZ", #ScriptFullPath)
or use the following code to delete this service:
#include "ServiceControl.au3"
$servicename = "MyServiceName"
_DeleteService("", $servicename)
There is one caveat to setting up AutoIt as a service. If the service is not installed using the above code, it must have the "allow service to interact with the desktop" setting or else automation functions such as Control* or Win* functions will not function. To assure the service does indeed have this setting, use the following code:
RegWrite("HKLM\SYSTEM\CurrentControlSet\Services[ServiceName]", "Type", "REG_DWORD", 0x110)
Taken from the FAQ topic on the AutoIt Forums. www.autoitscript.com/forum/index.php?showtopic=37289)
It sounds like you're want to use a scheduled task instead of a service. Scheduled tasks can execute every hour, while you're logged in, and should also be able to interact with your desktop. Just remember that a task run as a normal user can not interact (send input) to a elevated program if you're using Vista/Windows Server 2008 with User Account Control enabled.
I'm using a build script that calls Wise to create some install files. The problem is that the Wise license only allows it to be run under one particular user account, which is not the same account that my build script will run under. I know Windows has the runas command but this won't work for an automated script as there is no way to enter the password via the command line.
This might help: Why doesn't the RunAs program accept a password on the command line?
I recommend taking a look at CPAU.
Command line tool for starting process
in alternate security context.
Basically this is a runas replacement.
Also allows you to create job files
and encode the id, password, and
command line in a file so it can be
used by normal users.
You can use it like this (examples):
CPAU -u user [-p password] -ex "WhatToRun" [switches]
Or you can create a ".job" file which will have the user and password encoded inside of it. This way you can avoid having to put the password for the user inside your build script.
It's a bit of a workaround solution, but you can create a scheduled task that runs as your user account, and have it run regularly, maybe once every minute. Yes, you'll have to wait for it to run then.
This task can then look for some data files to process, and do the real work only if they are there.
This might help, it's a class I've used in another project to let people make their own accounts; everyone had to have access to the program, but the same account couldn't be allowed to have access to the LDAP stuff, so the program uses this class to run it as a different user.
http://www.codeproject.com/KB/dotnet/UserImpersonationInNET.aspx