sermoni

"Service monitor" / cronjob status service
Log | Files | Refs

readme.md (2967B)


      1 # sermoni
      2 
      3 `sermoni` is a service monitor that is intended to solve the following problems 
      4 in the simplest way possible:
      5 
      6 1. _No control of service health on different servers_   
      7   Backups, certificate renewals, and other cronjobs have no way of reporting
      8   their status to a centralized server - their status must be checked with the
      9   `mail` command on each server individually.
     10 
     11 2. There's no central log of SSH logins to servers
     12 
     13 ## Usage
     14 On first startup, specify a passphrase and optionally a website title:
     15 
     16     sermoni -pass <passphrase> -title "Service monitor"
     17 
     18 Log in to the website using said passphrase and click the eye symbol to add
     19 services.
     20 
     21 ### API
     22 
     23 #### Report 
     24 `POST /events` is a special case used by reports. Authentication is done here
     25 with the service token. To report status from a service, specify the server in 
     26 `report.sh` and run
     27 
     28     ./report.sh <service token> <status> [<title>] [<details>]
     29 
     30 where `status` is `ok`, `error`, or `info`.
     31 
     32 For the remaining endpoints authentication is done by including a `Pass-Hash`
     33 header. See `get-events.sh`, for example. There's no reason for the client to
     34 perform the hashing, of course. Instead just hash once and store the hash 
     35 directly on the client.
     36 
     37 ```
     38 GET /events
     39 DELETE /events/<id>
     40 
     41 GET /services
     42 POST /services
     43 DELETE /services (TODO)
     44 PUT /services (TODO)
     45 ```
     46 
     47 ### Suggested use of services
     48 
     49 Tokens can be set to whatever you want, but the suggested approach is to
     50 
     51 - generate a random token for each _server_, using a cryptosecure generator
     52 - put this secure token in a file, for instance `/root/.sermoni`
     53 - make a new token for each _service_ by appending an identifier, so that the
     54   format is `<service_token>:<identifier>`
     55 
     56 Example of a script using this approach:
     57 
     58 ```bash
     59 #!/bin/bash
     60 
     61 service_token=$(cat /root/.sermoni):backup
     62 
     63 <backup logic...> 
     64 
     65 if [ -z "$ERR" ]; then
     66     ./report.sh $service_token ok "Backup completed successfully"
     67 else 
     68     ./report.sh $service_token error "Backup error" "$ERR"
     69 fi
     70 
     71 ```
     72 
     73 ## Building
     74 
     75 ### Dev mode
     76 For building development version, run `./dockerdev.sh` to start a docker
     77 container that builds the Vue application (dev version) automatically upon
     78 updates. The web. In summary, run these from the repo root:
     79 
     80 - Build UI: `cd ui/ ; ./dockerdev.sh`
     81 - Build and run backend: `go run ./cmd/sermoni`
     82 
     83 ### Production
     84 
     85 (might make a script for this too, eventually)
     86 
     87 - Build UI: `npm install && npm run build` in `ui/` directory, assuming `npm`
     88   is installed. Can also execute it in an already running dev container:
     89   `docker exec -it <container> npm run build`
     90 
     91 - Copy the generated go file to the right directory:
     92   `cp ui/dist/html.go internal/http/`
     93 
     94 - Build static binary: 
     95 
     96   ```
     97   CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go get -d ./... ; \
     98   go build \
     99       -ldflags="-w -s" \
    100       -o ./sermoni \
    101       -tags PRODUCTION \
    102       ./cmd/sermoni/
    103   ```
    104 
    105 **The production build will not work without HTTPS**, because it uses secure
    106 cookies.