What’s the point of using a web interface to run scripts when you’re a terminal master?
Well, among other things:
To delegate the execution of certain scripts to business users securely, by limiting the available options to prevent any unpleasant surprises and keeping a record of executions:
Exemple: Generate a report for a given date range and send it by emailOr to easily execute predefined tasks in case of emergency (a terminal is not always at hand, unlike a smartphone):
Exemple: Check the status or restart/stop a Linux service
I propose addressing these two use cases using the newly added parameterizable tasks in the latest release of Ctfreak.
Prerequisites
We need:
A Unix server: Linux, Mac OS X, FreeBSD, … (see end of article to adapt to a Windows server) accessible via SSH where your scripts will be executed. We’ll call it scriptsrv.
An instance of Ctfreak with an admin account (the Free Edition will suffice if you adapt the examples in this article by limiting to one parameter per task).
Configuration of the scriptsrv server
Connect to your Ctfreak instance with an admin account.
Start by adding the SSH key to connect to the server via SSH Credential → New SSH Credential:
Then add the server itself via Nodes → Internal Nodes → New node:
Make sure that the SSH Key for scriptsrv is selected as the Credential, then validate to create the scriptsrv node.
Ctfreak can now connect to the server with the specified SSH key to execute various tasks.
1st case: Generate a report for a given date range and send it by email
For our example, let’s assume that you have an executable generatereport on the scriptsrv server, allowing you to generate and send a sales report by email for a given period, recipient, and format. If we were to run this executable directly in a terminal, it might look something like this:
generatereport --from 2024-03-04 --to 2024-03-10 --recipient nigel@mycompany.zzz --format pdf
So, we’ll create a task in Ctfreak that, when executed, will dynamically generate a web form to enter these 4 parameters before launching the generatereport executable.
Creating the Reporting project
Let’s start by creating a project dedicated to reporting tasks.
Go to Projects → New Project
Validate to create the project.
Creating the task Generate and send sales report
Go to Projects → Reporting → New task
Choose Bash Script as the task type.
Fill in the Name, Script, and Node filter fields as indicated.
In the content of our script, the 4 expected values are provided through environment variables, all prefixed by CTP_:
#!/bin/bash
generatereport --from $CTP_FROM --to $CTP_TO --recipient $CTP_RECIPIENT --format $CTP_FORMAT
These variables correspond to the parameters that we will create by clicking the Add parameter button.
Let’s start with the start and end dates of our period:
The parameter type Date ensures that a valid date will be entered in our execution form.
The Default date type field allows us to take the previous week as the default period.
The Name field will be used to define the name of the environment variable (
CTP_FROMin our script thus refers to the parameter namedFROM).When the Label field is filled, it replaces the Name field to reference the variable during the execution form generation.
During task execution, the entered date will be converted to the
YYYY-MM-DDformat to populate the corresponding environment variable.
Regarding the emails of authorized recipients to receive the report, we will limit the possible choices to 2 emails via the Selector parameter type:
For each option, when the Label field is filled, it substitutes Value during the execution form generation. We could have used it here to display Nigel and John in the form instead of their respective emails.
Finally, another Selector parameter type will allow choosing the format of the generated file (here PDF or Excel, but it’s pdf or xlsx that will be passed to our script):
With all the necessary information filled in, all that’s left is to validate to create the task.
Executing the task
Go to Projects → Reporting → Generate and send sales report → Execute to bring up the execution form.
As you can see, our 4 parameters are well taken into account in the form generation.
Adding a business user
With our task operational, the next step is to hand it over to a business user for execution.
Go to Users → New User
Validate to create the user.
By default, a non-admin user has no access to anything (except for logging in), so you need to give them the necessary rights.
Go to Projects → Reporting → Access → Edit
Add Jack by giving him the Executor role.
Jack now has access to the Reporting project, but only to execute the tasks it contains.
2nd case: Check the status or restart / stop a Linux service
Creating the Sysadmin project
Let’s create a project dedicated to system administration tasks.
Go to Projects → New Project
Validate to create the project.
Creating the task Systemctl
Go to Projects → Sysadmin → New task and like our previous case, choose Bash Script as the task type.
Fill in the Name, Script, and Node filter fields as indicated.
Click the Add parameter button to add the list of services concerned (here Postgresql and Apache)
As well as the commands to check the status, restart, or stop the service.
Validate to create the task.
Executing the task
Go to Projects → Sysadmin → Systemctl → Execute to bring up the execution form.
Execute the task and check the logs by clicking on the eye icon.
Running Powershell scripts instead of Bash
If your scriptsrv server is running Windows, you just need to make a few adjustments to run Powershell scripts instead of Bash:
- Activate the internal SSH server in Windows.
- When creating the scriptsrv node, set the OS Family property to
Windowsinstead ofUnix. - Create tasks of type Powershell Script instead of Bash Script and write the content of your scripts in Powershell instead of Bash.
The principle of injecting parameters as environment variables remains exactly the same. If we adapted the script from our first case, it would look like this:
generatereport --from $env:CTP_FROM --to $env:CTP_TO --recipient $env:CTP_RECIPIENT --format $env:CTP_FORMAT
Conclusion
As you have noticed, simply adding a web interface to a script offers many possibilities.
Start by adapting the examples presented in this article to your needs; they will already allow you to offer greater autonomy to your users.