A web form to launch your bash and powershell scripts

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 email

• Or 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 [e-mail] --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_FROM in our script thus refers to the parameter named FROM).

• 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-DD format 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 Windows instead of Unix.
• 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.