Yep - you absolutely can. (Click on the images for the full-size picture)
You configure it as a package ...
... give it an HTTP-based location ...
<I'd usually use IP, but that depends on how (un-)reliable your DNS is...>
... and that's it by and large. You just schedule it as a policy... as usual.
Now - IMPORTANT thing to note / not forget.
You WILL (probably) want to add the "Landesk" user to the SUDOERS file (we don't do so by default on account of being Nix-philosophy friendly) if we'll need root-access for any particular commands / installation of items (such as when you're trying to push an RPM package).
As a side-note -- if you "just want to run a single line" on the quick, you can also just use a remote execution (essentially "directly poke CBA & tell him to run this command") via MANAGE SCRIPTS and then creating a script like so ...
And with contents like so ... (for example)
... for instance.
Bear in mind that's NOT a policy, but can be useful if you want/need to get something out "now". I ended up using it in the past a few times to shut down runaway processes or someone having an "oh crud... we need to stop process X" type moment, for instance.
Policies are way more useful / reliable in most cases, but it's always good to have options .
Note - remember to check / test that you've got your ports open (for CBA and / or other things) ... otherwise you'll only get to run policies when the CLIENT initiates a check. That's somethig else that trips people up pretty often (because they don't let folks tell them about "these ports need to be open, otherwise the app will have issues..." ).
So ... yeah ... "absolutely doable" .
phoffmann thanks for this great write up and response.
I have a couple of follow-up questions.
1. If I need to run the script with root privileges do I need use the sudo command?
2. Is there anything special that needs to be done with the LANDesk user account when adding it to the SUDOERS file?
The Linux administrators are wanting to add restrictions to the account within the SUDOERS file.
3. When does the Linux agent check-in for policies and does the task only execute when the agent checks in for policies?
I have assigned a scheduled task with the script to the Linux box but the task moves to status waiting and policy has been made available and does not seem to go any further.
So to answer your questions ...
- Root privileges?
If you want us to run with root privileges, you need to edit / change the SUDOERS file. Then we'll automatically be able to run as elevated.
- Anything special for SUDOERS file?
Not really ... here's what my entry looks like ... nothing special to it that I can tell ...
## Allows people in group wheel to run all commands
# %wheel ALL=(ALL) ALL
## Same thing without a password
# %wheel ALL=(ALL) NOPASSWD: ALL
landesk ALL=(ALL) NOPASSWD: ALL
... I guess it depends on what kinds of restrictions they want to add.
Long story short -- "System Management tools .... kinda need to be able to MANAGE..." (usually). We don't automatically nab the permissions (to be Linux friendly) ... but to be able to do a bunch of things, we DO need them.
- The NIX agent checks in for policies either upon request (when you run the policy check binary) and/or as configured in your distro-specific option / scheduler (usually CRONTAB). We try to use native options where sensible / appropriate. So if you check / alter / set your desired policy options in your CRONTAB, there's your answer (and how you control it).
Due to historical / backwards compatibility reasons, you can check for policies by calling "/opt/landesk/bin/map-fetchpolicy" (run with "-h" for the options).
... does that sort you out?
- Root privileges?