* ✨🔑 feat(reset-password): Add fallback for missing user.db
This change adds a fallback mechanism to handle cases where the
`/var/lib/casaos/db/user.db` file is not found. If the file is
missing, the script attempts to check if the file exists in an
alternative location. If found, it backs up the file and restarts
the CasaOS user service to ensure the password reset functionality
works correctly.
* 🔐 feat(reset-password-for-casaos): Remove user.db existence
check and provide alternative method
The changes remove the check for the existence of the `user.db` file
and provide an alternative method to handle the case where the file is
not found. This change is intended to make the password reset process
more robust and accommodate systems where the `user.db` file may not be
present.
This commit introduces several improvements to the CasaOS password reset script:
- Adds functions to print headers, check service status, and backup the user database.
- Checks if the script is run with sudo privileges.
- Displays a welcome message with links and information about supporting the project.
- Checks if the CasaOS service is active before proceeding.
- Prompts the user for confirmation before resetting the password.
- Backs up the user database before removing the original file.
- Restarts the CasaOS user service to reflect the changes.
- Provides clear success and error messages to the user.
These changes aim to make the password reset process more robust, user-friendly, and informative.
* 🎨 feat(healthcheck): add new health checks for Docker and storage
This commit introduces two new health checks to the BigBearCasaOS
Healthcheck script:
1. `check_docker_status()`: This function checks if Docker is installed and
running on the system. It provides clear feedback based on the Docker
status.
2. `check_storage_health()`: This function checks the health of all storage
devices (disks) connected to the system using the `smartctl` tool. It
reports the health status of each disk, indicating if it has passed the
SMART health check or if there may be potential issues.
These new health checks provide a more comprehensive overview of the system's
overall health and help identify any potential issues related to Docker or
storage-related problems.
* ✨📄 feat(casaos-healthcheck): Enhance DNS resolution and add system health checks
This change enhances the DNS resolution checks in the casaos-healthcheck script and adds new system health checks for disk space, CPU load, memory usage, and system temperature.
The key changes include:
- Improve DNS resolution by trying multiple DNS servers and retrying on failure
- Add a check for basic network connectivity before attempting DNS lookups
- Implement a check for disk space usage, with a configurable threshold
- Implement a check for CPU load, with a configurable threshold based on the number of cores
- Implement a check for memory usage, with a configurable threshold based on total memory
- Implement a check for system temperature, using the `sensors` command or `/sys/class/thermal` when available
- Add a check for available system updates using `apt-get`
These new checks provide a more comprehensive health monitoring solution for the CasaOS system.
* ✨ feat: Bump healthcheck version to 3.0
Bumped the version of the BigBearCasaOS Healthcheck tool from 2.3 to 3.0.
This change reflects the latest updates and improvements made to the
healthcheck script.
This commit introduces several improvements to the Docker cleanup script:
- Adds a verbose mode to print detailed messages during the cleanup process.
- Implements a dry run mode to simulate the cleanup without actually removing any resources.
- Improves the container, image, volume, and network cleanup functions to better handle the cleanup process and provide more informative output.
- Adds a summary of the cleanup results at the end of the script.
- Includes a help message to explain the available options.
- Refactors the script to improve readability and maintainability.
The main goal of these changes is to provide a more user-friendly and robust Docker cleanup solution.
This change ensures that the new Portainer container is created with the same ports as the
current configuration. It first checks the existing Portainer container to get the
current port mappings, and then uses those values when starting the new container.
This way, clients do not need to update any of their configurations when the Portainer
version is updated.
