79 lines
5.1 KiB
Markdown
79 lines
5.1 KiB
Markdown
# Network resurrector
|
|
|
|
Everything must be able to be managed remotely. Even the powered off servers. That's how Network resurrector appeared, the tool I wrote specifically to be able to wake up my machines that I don't need to be powered on all the time.
|
|
|
|
Network Resurrector is a system that comprises of five essential services which allow for the execution of its core functionality. To enable various additional features, such as the notification mechanism, supplementary components may be added to the system as an option.
|
|
|
|
## Main components
|
|
|
|
### Frontend
|
|
* The frontend component is a web application written in React JS that has the role of providing the user with a friendly visual interface through which to interact with the system.
|
|
|
|
### API
|
|
* The API component is a .NET 6 REST API that has the role of mediating the exchange of data and commands between the frontend component and the database or server component.
|
|
|
|
### Server
|
|
* The server component is a .NET 6 service specialized in executing 'WakeOnLAN', 'Ping' and 'Shutdown' actions for the machines in its network.
|
|
|
|
### Agent
|
|
* The agent is a .NET 6 service specialized in executing 'Shutdown', 'Restart', 'Sleep', 'Logout' and 'Lock' actions on the host machine on which it is installed. Each action can be executed at the time of launch or with a certain delay. If an action is requested with a delay and later the user changes his mind, he can cancel the action by executing the separate 'Cancel' type action.
|
|
* The need for the agent appeared after I realized that the server cannot perform any action on a machine, being outside of it.
|
|
* The agent solves this problem because it is installed directly on the targeted machine. Later, the API component can delegate the resolution of an action directly to the agent.
|
|
* Most of the time, the execution flow of an action is realized in the following way:
|
|
* The user initiates an action, such as starting or stopping a machine, by pressing the corresponding button in the user interface.
|
|
* The frontend component sends the command to the API.
|
|
* The API checks who is configured as performer for the respective action for the machine and sends the command to it.
|
|
* The performer of the action (Agent or Server) executes the command and responds on the flow with status.
|
|
* In most cases, the Server component handles the machine startup action while the Agent component manages the machine shutdown action.
|
|
* As is probably already obvious, the agent can be installed on as many machines as desired.
|
|
|
|
### Tuitio
|
|
* Tuitio is my personal identity server. It manages user authentication within the application and authorizes requests made by it. Further information about Gundo can be found on its dedicated page.
|
|
|
|
All communication between the five main components is done exclusively through HTTP.
|
|
|
|
## Secondary components
|
|
|
|
* NATS Streaming - Used to publish notifications about executed actions.
|
|
* Correo - Used to send by email the notifications generated by the system.
|
|
* Seq - Used to collect and view system logs.
|
|
|
|
## Notification system
|
|
|
|
The notification system is focused on system actions (Wake, Shutdown, etc), and the configuration of notifications is done in structures of the following form:
|
|
|
|
```
|
|
{
|
|
"To": [ "user@homelab.com" ],
|
|
"Subject": "Network resurrector: Machine {MACHINE_NAME} has been waked. Status: {ACTION_STATUS}",
|
|
"Body": "Hello,{NEWLINE:2}Network resurrector processed a command to start machine {MACHINE_FULLNAME} with IP {MACHINE_IP} at {SYSTEM_DATETIME}.{NEWLINE}The performer who was delegated for this action was {ACTION_PERFORMER}.{NEWLINE}Action status: {ACTION_STATUS}{NEWLINE:2}Have a nice day,{NEWLINE}Network resurrector notification system."
|
|
}
|
|
```
|
|
|
|
The texts can be written at the user's free choice, and the following placeholders can be used in their composition: ```{MACHINE_NAME}```, ```{MACHINE_FULLNAME}```, ```{MACHINE_IP}```, ```{ACTION_STATUS}```, ```{ACTION_PERFORMER}```, ```{SYSTEM_DATETIME}```, ```{ERROR_MESSGE}```, ```{NEWLINE}```, ```{NEWLINE:2}```
|
|
|
|
```{NEWLINE:x}``` is a dynamic placeholder. Any number can be written in place of the 'x' character and the notification system will add that many new lines.
|
|
|
|
## Database
|
|
Currently, the database server supported by the system is only Microsoft SQL Server. In the following versions, the system will also be compatible with PostgreSQL and SQLite.
|
|
|
|
## Logging
|
|
The logging functionality is managed with Serilog, and its configuration is done in the ```appsettings.json``` file. In addition to its standard configuration, Network resurrector also has a preconfigured area where two destinations for logs are available: SqlServer database and Seq. Each of the destinations can be activated or not. If logging in the console is sufficient, all additional logging destinations can be disabled.
|
|
This configuration area is:
|
|
|
|
```
|
|
"Logs": {
|
|
"SqlServer": {
|
|
"Enabled": false,
|
|
"Connection": "Server=<server>;Database=<database>;User Id=<user>;Password=<password>;"
|
|
},
|
|
"Seq": {
|
|
"Enabled": false,
|
|
"Url": "",
|
|
"ApiKey": ""
|
|
}
|
|
}
|
|
```
|
|
|
|
## Hosting
|
|
All the components of the system are written in cross-platform technologies, so its host can be any environment. |