kasimahmic / minimon

Simple system monitor

Hi, I'm Kasim Ahmic!

About

I'm an aspiring full stack developer with a focus on JavaScript (Node.js, React, etc.). I'll fill out more when I figure out how to write a proper bio :)

Stats

minimon's Issues

CI/CD pipeline

Utilize GitHub Actions to build out a CI/CD pipeline.

• Steps for Pull Requests:

  1. git clone
  2. yarn run init
  3. yarn build
  4. yarn lint
  5. yarn test

• Steps for Release builds:

  1. git clone
  2. yarn run init
  3. yarn build
  4. yarn lint
  5. yarn test
  6. yarn package:windows
  7. yarn package:linux
  8. yarn package:macos

Depends on #6 and #7.

Add code linting

Core, Client, and Server should all be linted with eslint and the code style should be verified with Prettier. If there are any issues, fail the process.

Add additional theme options

Currently, the only real theme option is light mode and dark mode.

• Create a Theme object in the Settings object
  • Theme should contain
    • backgroundColor must be a valid CSS color
    • dialColor must be a valid CSS color
    • dialBackgroundColor must be a valid CSS color
    • textColor must be a valid CSS color
    • fontSize must be valid CSS font size
• Allow users to change the background colors
• Allow users to change the color of the dials
• Allow users to change the color of the text
• Allow users to change the font size

Notes:

1. Investigate how we can use the Option object for validation. It should ideally be validated on the backend but we can validate on the front end if necessary
2. At a minimum, @IsRgbColor and @IsHexColor should be used on the backend

Investigate SSL

It would be nice to encrypt the data between the server and client. Given the app runs on localhost, I'm not sure how feasible this is.

Add Admin UI for customizing client layout

The UI is currently customizable by editing the settings.json file generated at startup. This should be extended to the Admin UI as well.

• The following settings need to be included:
  • Columns
  • Rows
  • Widgets:
    • List of length N where N is columns x rows from above
    • Should contain one text field and two drop downs
      • The text field allows the user to type in a custom label
      • First dropdown contains the Vitals type (cpu, ram, gpu, or network)
      • Second dropdown contains the properties of the selected Vital (currentLoad, powerUsage, etc)
• The Widgets type should contain an empty Widget to allow for empty spaces on the UI
  • label must be null
  • component must be null
  • property must be null
• The payload needs to be validated on the backend
  • columns must be a positive integer greater than 0
  • rows must be a positive integer greater than 0
  • widgets must be an array of Widgets
    • label must be a string
    • component must be a valid Vitals type (cpu, ram, gpu, or network)
    • property must be a valid property of the selected Vitals type
  • If an empty Widget is detected, a UUID should be generated for it's label property
  • The UI should use the existence of the component field to determine whether it is a valid Widget or an empty Widget but continue to use the label as the key

Fix code scanning alert - Prototype-polluting merge call

Likely just a matter up either upgrading lodash.merge or installing the full lodash lib

Tracking issue for:

• https://github.com/KasimAhmic/minimon/security/code-scanning/1

Add authentication

Currently, anyone on the network that knows the IP address of the device running Minimon can access the client and view the system vitals of said device. While the data streamed to the client probably isn't particularly useful for an attack, I'd like to mitigate as many security risks as possible.

---

Option 1 - Plaintext username and password in URL

Pros:

• Easy to implement

Cons:

• Easily thwarted via basic packet sniffing due to lack of SSL (see #2)

---

Option 2 - IP address allow list

Pros:

• Should block any devices not using the allowed IP addresses

Cons:

• Not sure this is possible with Nest JS
• Is IP address spoofing a thing?
• Requires the user to dig through their router settings to assign static IP address to clients
• Prevents the user from seeing their PC vitals on more than one device unless configured

Track more system vitals

In it's current state, systeminformation can't always retrieve the desired system vitals. For example, on neither my Windows 10 machine nor my M1 MacBook Pro can I see CPU temps, CPU clock frequencies, etc. This is not systeminformation's fault but rather Microsoft's and Apple's for providing limited tooling to access this information.

Searching around the internet for an alternative package yielded exactly 0 viable results so it appears that we'll need to write our own low level API for retrieving this data. Only problem is that I don't know any C, C++, Rust, etc. so this will likely need to be contributed by someone else or we'll need to wait until I get around to learning Rust.

I'm leaving this issue as an open discussion to see if anyone else has any other ideas.

Improve data type handling

Some values are stored as percentages (cpuLoad) and other are stored as their raw values (temperature) but in all cases, we're adding a % sign to the end of the value labels on the dials.

I think the solution here is to have a generic object that contains the pre-formatted value label, the raw current value, the minimum value for that vital, and the maximum value for that vital. This way, the server provides the client with all the data it needs to render the UI while the (current) UI only needs to rescale the range to fit the shortened CircularProgress component.

interface VitalDetails {
  label: string;
  currentValue: number;
  minValue: number;
  maxValue: number;
}

interface CpuVitals {
  load: VitalDetails;
  temp: VitalDetails;
  coreCount: VitalDetails;
}

const cpu: CpuVitals = {
  load: {
    label: '75.15%',
    currentValue: 75.15,
    minValue: 0,
    maxValue: 100
  },
  temp: {
    label: '52.15°C',
    currentValue: 52.15,
    minValue: 0,
    maxValue: 100
  },
  coreCount: {
    label: '24',
    currentValue: 24,
    minValue: 24,
    maxValue: 24
  },
};

Add documentation

The instructions in README.md are very developer centric and not exactly useful to the average user. The instructions should be as simple as the below but in order to get there, other tickets need to be worked first. The README should link to the Wiki where we have all the documentation stored.

1. Download the binary
2. Run it

• Add documentation for end user installation
  • Depends on #8 as we won't know the full installation instructions until we're actually shipping a binary
• Add documentation for end user customization
  • Depends on #1 as the UI is not complete yet
• Add documentation for setting Minimon up for local development
• Add project overview describing each of the packages

Add unit tests

Any serious application should have unit tests to ensure things don't go wrong during the development cycle. The Core package does not need unit tests since it's really just there to export shared types and values. The Server and Client packages should use Jest and React Testing Library respectively for their unit tests.

• 100% test coverage with 80% minimum coverage threshold
• Coverage reporting
• Checks to fail builds if coverage threshold is not met
• Will likely need to mock systeminformation so as to prevent tests failing on different systems that, for example, don't have a GPU that SI can see

Investigate using Electron as a thin wrapper around Minimon

The current idea is the following:

1. Build Minimon Core with tsc
2. Build Minimon Client with craco + esbuild
3. Build Minimon with Nest CLI
4. Move contents of Client build directory to Server dist directory using Nest CLI
5. Package the app with pkg for each OS
6. Ship the binaries

This is pretty basic and easy-ish to implement and it may actually cover most of our use cases however, it does have some drawbacks.

1. This is a mostly custom build pipeline so we're kind of on our own
2. Can't change binary icons reliably
3. Requires the user to manually copy the binary someplace safe
4. Would need a custom update checker implementation
5. Updates from the users perspective will be largely manual

All that said, one idea to remedy almost all of the above is to wrap Minimon with Electron. We won't need to utilize its' browser API since we're already hosting our own webapp via the server so there shouldn't be the usual memory concerns with using Electron.

1. I have no idea what the build pipeline would look like here as I've never wrapped a backend application (Express, Fastify, Nest, etc) with Electron before. Will need serious investigation.
2. Icons can be set easily with electron-forge
3. I believe electron-forge allows us to create an installer that handles copying files for us
4. Update checking is built into Electron (*)
5. Auto updates are built into Electron (*)

(*): Note that for us to use Electron's update services, we'll need to have our built packages singed which is likely going to cost a pretty penny... Some additional research and/or funding might need to be done here.