NETRAVE/lib/utils/first_run_init.rb

142 lines
4.5 KiB
Ruby
Raw Normal View History

Detailed Refactoring of Database Interaction 1. **Refactoring of Database Interaction Methods** - Refactored the `store_services` method in the `DatabaseManager` class to handle an array of services instead of a hash. This change was made to simplify the interaction with the database and to avoid unnecessary complexity in the data structure. - The `store_services` method now iterates over an array of services and inserts each service into the database with a default status of true. This design choice was made to ensure that all services are active by default. 2. **Modification of Database Schema** - Modified the `create_services_table` method in the `DatabaseManager` class to create a table with only two columns: `id` and `services`. This change was made to align the database schema with the new data structure used in the `store_services` method. - The `status` column was removed from the `services` table because the status of all services is now assumed to be true by default. 3. **Error Handling and Debugging** - Encountered a `Sequel::DatabaseError` with the message "Operand should contain 1 column(s)" during the execution of the `store_services` method. This error was caused by an attempt to insert a hash into a single database column. - The error was resolved by refactoring the `store_services` method to handle an array of services instead of a hash. 4. **Unorthodox Design Choices** - The decision to use an array of services instead of a hash and to assume that the status of all services is true by default may seem unorthodox. However, these design choices were made to simplify the interaction with the database and to avoid unnecessary complexity in the data structure. - These design choices also helped to resolve the `Sequel::DatabaseError` that was encountered during the execution of the `store_services` method. This commit represents a significant refactoring of the database interaction methods in the NETRAVE project. The changes made in this commit have simplified the interaction with the database and have resolved a `Sequel::DatabaseError` that was encountered during the execution of the `store_services` method.
2023-06-09 19:39:54 -06:00
# frozen_string_literal: true
require 'curses'
Detailed Refactoring of Database Interaction 1. **Refactoring of Database Interaction Methods** - Refactored the `store_services` method in the `DatabaseManager` class to handle an array of services instead of a hash. This change was made to simplify the interaction with the database and to avoid unnecessary complexity in the data structure. - The `store_services` method now iterates over an array of services and inserts each service into the database with a default status of true. This design choice was made to ensure that all services are active by default. 2. **Modification of Database Schema** - Modified the `create_services_table` method in the `DatabaseManager` class to create a table with only two columns: `id` and `services`. This change was made to align the database schema with the new data structure used in the `store_services` method. - The `status` column was removed from the `services` table because the status of all services is now assumed to be true by default. 3. **Error Handling and Debugging** - Encountered a `Sequel::DatabaseError` with the message "Operand should contain 1 column(s)" during the execution of the `store_services` method. This error was caused by an attempt to insert a hash into a single database column. - The error was resolved by refactoring the `store_services` method to handle an array of services instead of a hash. 4. **Unorthodox Design Choices** - The decision to use an array of services instead of a hash and to assume that the status of all services is true by default may seem unorthodox. However, these design choices were made to simplify the interaction with the database and to avoid unnecessary complexity in the data structure. - These design choices also helped to resolve the `Sequel::DatabaseError` that was encountered during the execution of the `store_services` method. This commit represents a significant refactoring of the database interaction methods in the NETRAVE project. The changes made in this commit have simplified the interaction with the database and have resolved a `Sequel::DatabaseError` that was encountered during the execution of the `store_services` method.
2023-06-09 19:39:54 -06:00
require 'dynamic_curses_input'
require 'dotenv'
require_relative 'database_manager'
require_relative 'system_information_gather'
require_relative 'utilities'
Implementing Thread-Safe Alert System with Ring Buffer This commit introduces a significant enhancement to our Ruby program by implementing a thread-safe alert system using a ring buffer data structure. New Classes: 1. Alert: This class is responsible for creating and displaying alerts in the Curses Text User Interface (TUI). It takes a message and severity level as arguments and uses these to display color-coded alerts to the user. 2. AlertQueueManager: This class manages the queues for alerts using a ring buffer data structure. It continuously checks the queue and displays alerts as they arrive. It uses a mutex lock to ensure thread safety when accessing the ring buffer. 3. RingBuffer: This class is a custom implementation of a ring buffer, also known as a circular buffer. It's a fixed-size buffer that effectively overwrites old data when it is full. The buffer size has been optimized to 2MB to balance memory usage and performance. Modifications to Existing Methods: The DatabaseManager class has been updated to integrate the new alert system. The methods in this class now create Alert instances and enqueue them in the AlertQueueManager instead of directly displaying alerts to the user. This change ensures that alerts are displayed in a thread-safe manner and allows for better control over the timing and order of alert displays. Thread Safety Measures: Mutex locks and condition variables have been used to synchronize access to the ring buffer and prevent race conditions. This ensures that only one thread can access the buffer at a time, preventing data corruption and ensuring the correct operation of the alert system. Testing: Rigorous testing has been conducted to validate the correct functioning of the new system and to handle edge cases. This includes tests for the correct display of alerts, the correct operation of the ring buffer, and the correct synchronization of threads. Documentation: Detailed comments have been added to the code to explain the purpose and operation of the new classes and methods. This documentation will serve as a valuable reference for future development and maintenance of the codebase. This commit represents a significant improvement in the functionality and robustness of our Ruby program's alert system.
2023-07-05 12:35:20 -06:00
require_relative 'alert_manager'
Enhancements to Command Execution and Logging Mechanisms This commit introduces several significant enhancements to the way commands are executed and logged in the application. The changes are primarily focused on improving the robustness, reliability, and transparency of the command execution process, as well as enhancing the quality and usefulness of the log output. 1. Command Execution Enhancements: The use_sudo method has been refactored to handle commands that do not return any output. Previously, the method was designed to capture and return the output of the command being executed. However, some commands (such as modprobe) do not return any output, which caused issues with the previous implementation. The method now checks the exit status of the command to determine whether it was successful or not, and returns a success or failure message accordingly. This change improves the robustness of the command execution process and ensures that it can handle a wider range of commands. 2. Error Handling Improvements: The use_sudo method now includes more comprehensive error handling. If a command fails to execute within a specified timeout period, an error message is logged and the method returns a failure message. Additionally, if a command fails to execute for any other reason, the method logs the error and returns a failure message with the command's exit status. These changes make it easier to identify and troubleshoot issues with command execution. 3. Logging Enhancements: The logging mechanism has been enhanced to provide more detailed and useful information. The use_sudo method now logs the command being executed and its outcome (success or failure). If a command fails, the method logs the command's exit status. These changes improve the transparency of the command execution process and make it easier to identify and troubleshoot issues. 4. Code Refactoring: Several methods have been refactored for improved readability and maintainability. The use_sudo method has been refactored to reduce its complexity and improve its readability. The first_run_setup method has been refactored to ensure that the main interface name and the dummy interface name are properly passed to the setup_traffic_mirroring method. 5. Bug Fixes: A bug in the create_dummy_interface method that caused it to return an array of Alert objects instead of the dummy interface name has been fixed. The method now correctly returns the dummy interface name. These changes represent a significant improvement to the command execution and logging mechanisms in the application, and lay the groundwork for further enhancements in the future.
2023-07-07 11:25:08 -06:00
require_relative 'networking_genie'
Detailed Refactoring of Database Interaction 1. **Refactoring of Database Interaction Methods** - Refactored the `store_services` method in the `DatabaseManager` class to handle an array of services instead of a hash. This change was made to simplify the interaction with the database and to avoid unnecessary complexity in the data structure. - The `store_services` method now iterates over an array of services and inserts each service into the database with a default status of true. This design choice was made to ensure that all services are active by default. 2. **Modification of Database Schema** - Modified the `create_services_table` method in the `DatabaseManager` class to create a table with only two columns: `id` and `services`. This change was made to align the database schema with the new data structure used in the `store_services` method. - The `status` column was removed from the `services` table because the status of all services is now assumed to be true by default. 3. **Error Handling and Debugging** - Encountered a `Sequel::DatabaseError` with the message "Operand should contain 1 column(s)" during the execution of the `store_services` method. This error was caused by an attempt to insert a hash into a single database column. - The error was resolved by refactoring the `store_services` method to handle an array of services instead of a hash. 4. **Unorthodox Design Choices** - The decision to use an array of services instead of a hash and to assume that the status of all services is true by default may seem unorthodox. However, these design choices were made to simplify the interaction with the database and to avoid unnecessary complexity in the data structure. - These design choices also helped to resolve the `Sequel::DatabaseError` that was encountered during the execution of the `store_services` method. This commit represents a significant refactoring of the database interaction methods in the NETRAVE project. The changes made in this commit have simplified the interaction with the database and have resolved a `Sequel::DatabaseError` that was encountered during the execution of the `store_services` method.
2023-06-09 19:39:54 -06:00
# first run class
Refactoring for Modularity, Code Reuse, and Security Considerations In this commit, we have undertaken a significant refactoring of the codebase to improve modularity, promote code reuse, and consider security aspects. Modularity and Code Reuse: We introduced classes and modules to better organize the code and facilitate code reuse. Specifically, we created a new Utilities module to hold common methods that are used across different parts of the application. This module includes methods such as convert_speed_to_mbps, services_to_hash, and calculate_total_bandwidth. By placing these methods in a module, we can include this module in any class that needs these methods, thereby promoting code reuse and reducing duplication. We also created two new classes, SystemInformationGather and DatabaseManager. The SystemInformationGather class is responsible for gathering system information, such as uplink and downlink speed, and services. The DatabaseManager class handles database operations, including testing the database connection, creating the system information table, and storing system information in the database. By encapsulating these responsibilities within their respective classes, we have made the code more organized and easier to maintain. Database Connection Details: We made a decision to store the database connection details in a config file (config.yml) instead of the database itself. This decision was made for security reasons, as storing these details in the database could expose them to potential security risks. Storing these details in a config file allows us to better control access to these details. Database Encryption: We discussed the possibility of encrypting the database for additional security. While we have not implemented this feature in this commit, we have laid the groundwork for it by discussing potential libraries/gems that could be used for this purpose. This is an area that we will revisit in the future. System Information Gathering: We wrote methods to gather system information, such as uplink and downlink speed, and services, and store this information in the database. This information will be useful for monitoring system performance and for making decisions about resource allocation. This refactoring effort has made the codebase more organized, easier to maintain, and more secure. It also aligns with our project goals and roadmap. However, it's important to note that with any refactoring effort, there may be potential issues or trade-offs. We will need to thoroughly test the refactored code to ensure that it works as expected and that there are no unintended side effects.
2023-06-04 14:41:12 -06:00
class FirstRunInit
include Utilities
Detailed Refactoring of Database Interaction 1. **Refactoring of Database Interaction Methods** - Refactored the `store_services` method in the `DatabaseManager` class to handle an array of services instead of a hash. This change was made to simplify the interaction with the database and to avoid unnecessary complexity in the data structure. - The `store_services` method now iterates over an array of services and inserts each service into the database with a default status of true. This design choice was made to ensure that all services are active by default. 2. **Modification of Database Schema** - Modified the `create_services_table` method in the `DatabaseManager` class to create a table with only two columns: `id` and `services`. This change was made to align the database schema with the new data structure used in the `store_services` method. - The `status` column was removed from the `services` table because the status of all services is now assumed to be true by default. 3. **Error Handling and Debugging** - Encountered a `Sequel::DatabaseError` with the message "Operand should contain 1 column(s)" during the execution of the `store_services` method. This error was caused by an attempt to insert a hash into a single database column. - The error was resolved by refactoring the `store_services` method to handle an array of services instead of a hash. 4. **Unorthodox Design Choices** - The decision to use an array of services instead of a hash and to assume that the status of all services is true by default may seem unorthodox. However, these design choices were made to simplify the interaction with the database and to avoid unnecessary complexity in the data structure. - These design choices also helped to resolve the `Sequel::DatabaseError` that was encountered during the execution of the `store_services` method. This commit represents a significant refactoring of the database interaction methods in the NETRAVE project. The changes made in this commit have simplified the interaction with the database and have resolved a `Sequel::DatabaseError` that was encountered during the execution of the `store_services` method.
2023-06-09 19:39:54 -06:00
include Curses
Refactoring for Modularity, Code Reuse, and Security Considerations In this commit, we have undertaken a significant refactoring of the codebase to improve modularity, promote code reuse, and consider security aspects. Modularity and Code Reuse: We introduced classes and modules to better organize the code and facilitate code reuse. Specifically, we created a new Utilities module to hold common methods that are used across different parts of the application. This module includes methods such as convert_speed_to_mbps, services_to_hash, and calculate_total_bandwidth. By placing these methods in a module, we can include this module in any class that needs these methods, thereby promoting code reuse and reducing duplication. We also created two new classes, SystemInformationGather and DatabaseManager. The SystemInformationGather class is responsible for gathering system information, such as uplink and downlink speed, and services. The DatabaseManager class handles database operations, including testing the database connection, creating the system information table, and storing system information in the database. By encapsulating these responsibilities within their respective classes, we have made the code more organized and easier to maintain. Database Connection Details: We made a decision to store the database connection details in a config file (config.yml) instead of the database itself. This decision was made for security reasons, as storing these details in the database could expose them to potential security risks. Storing these details in a config file allows us to better control access to these details. Database Encryption: We discussed the possibility of encrypting the database for additional security. While we have not implemented this feature in this commit, we have laid the groundwork for it by discussing potential libraries/gems that could be used for this purpose. This is an area that we will revisit in the future. System Information Gathering: We wrote methods to gather system information, such as uplink and downlink speed, and services, and store this information in the database. This information will be useful for monitoring system performance and for making decisions about resource allocation. This refactoring effort has made the codebase more organized, easier to maintain, and more secure. It also aligns with our project goals and roadmap. However, it's important to note that with any refactoring effort, there may be potential issues or trade-offs. We will need to thoroughly test the refactored code to ensure that it works as expected and that there are no unintended side effects.
2023-06-04 14:41:12 -06:00
def initialize(logger, alert_queue_manager, db_manager = nil)
@loggman = logger
Implementing Thread-Safe Alert System with Ring Buffer This commit introduces a significant enhancement to our Ruby program by implementing a thread-safe alert system using a ring buffer data structure. New Classes: 1. Alert: This class is responsible for creating and displaying alerts in the Curses Text User Interface (TUI). It takes a message and severity level as arguments and uses these to display color-coded alerts to the user. 2. AlertQueueManager: This class manages the queues for alerts using a ring buffer data structure. It continuously checks the queue and displays alerts as they arrive. It uses a mutex lock to ensure thread safety when accessing the ring buffer. 3. RingBuffer: This class is a custom implementation of a ring buffer, also known as a circular buffer. It's a fixed-size buffer that effectively overwrites old data when it is full. The buffer size has been optimized to 2MB to balance memory usage and performance. Modifications to Existing Methods: The DatabaseManager class has been updated to integrate the new alert system. The methods in this class now create Alert instances and enqueue them in the AlertQueueManager instead of directly displaying alerts to the user. This change ensures that alerts are displayed in a thread-safe manner and allows for better control over the timing and order of alert displays. Thread Safety Measures: Mutex locks and condition variables have been used to synchronize access to the ring buffer and prevent race conditions. This ensures that only one thread can access the buffer at a time, preventing data corruption and ensuring the correct operation of the alert system. Testing: Rigorous testing has been conducted to validate the correct functioning of the new system and to handle edge cases. This includes tests for the correct display of alerts, the correct operation of the ring buffer, and the correct synchronization of threads. Documentation: Detailed comments have been added to the code to explain the purpose and operation of the new classes and methods. This documentation will serve as a valuable reference for future development and maintenance of the codebase. This commit represents a significant improvement in the functionality and robustness of our Ruby program's alert system.
2023-07-05 12:35:20 -06:00
@db_manager = db_manager
@alert_queue_manager = alert_queue_manager
@info_gatherer = SystemInformationGather.new(@db_manager, @loggman)
Dotenv.load
Refactoring and Enhancing Database Management and System Information Gathering In this commit, we've made substantial changes to the DatabaseManager and SystemInformationGather classes to improve the functionality, efficiency, and maintainability of the system. Refactoring DatabaseManager: The DatabaseManager class was refactored to improve the separation of concerns. Initially, the DatabaseManager was responsible for creating an instance of SystemInformationGather, which was not ideal as it violated the Single Responsibility Principle. The responsibility of creating an instance of SystemInformationGather was moved to the FirstRunInit class, which is more appropriate as it is responsible for the initial setup of the system. This change improves the maintainability of the code and makes it easier to understand and modify in the future. Adding Database Connection Test: A method test_db_connection was added to the DatabaseManager to test the database connection before attempting to interact with it. This method improves the robustness of the system by ensuring that a valid connection exists before proceeding. It also provides a better user experience by providing a clear error message if the connection fails. Refactoring SystemInformationGather: The SystemInformationGather class was refactored to improve its functionality and efficiency. The methods ask_for_uplink_speed and ask_for_downlink_speed were modified to convert the user's input to Mbps immediately, reducing the need for conversion later. This change improves the efficiency of the system by reducing unnecessary conversions. Adding Services Table: A new table for services was added to the database. This table stores the services that the system should be aware of, with each service represented as a boolean value. This change improves the flexibility of the system by allowing it to handle a variable number of services. It also improves the efficiency of the system by reducing the need to parse the services from a string each time they are needed. Storing Total Bandwidth: The total bandwidth (the sum of the uplink and downlink speeds) is now calculated and stored in the system_info table. This change improves the efficiency of the system by reducing the need to calculate the total bandwidth each time it is needed. Error Handling and Debugging: Throughout the process, various bugs and errors were encountered and fixed. These included issues with method arguments, missing method calls, and incorrect method usage. Fixing these issues improved the stability and reliability of the system. In conclusion, this commit significantly improves the functionality, efficiency, and maintainability of the system. The changes made adhere to good software engineering principles, such as the Single Responsibility Principle, and make the system more robust and user-friendly.
2023-06-05 14:21:29 -06:00
end
def run
first_run_setup
end
Enhancements to Command Execution and Logging Mechanisms This commit introduces several significant enhancements to the way commands are executed and logged in the application. The changes are primarily focused on improving the robustness, reliability, and transparency of the command execution process, as well as enhancing the quality and usefulness of the log output. 1. Command Execution Enhancements: The use_sudo method has been refactored to handle commands that do not return any output. Previously, the method was designed to capture and return the output of the command being executed. However, some commands (such as modprobe) do not return any output, which caused issues with the previous implementation. The method now checks the exit status of the command to determine whether it was successful or not, and returns a success or failure message accordingly. This change improves the robustness of the command execution process and ensures that it can handle a wider range of commands. 2. Error Handling Improvements: The use_sudo method now includes more comprehensive error handling. If a command fails to execute within a specified timeout period, an error message is logged and the method returns a failure message. Additionally, if a command fails to execute for any other reason, the method logs the error and returns a failure message with the command's exit status. These changes make it easier to identify and troubleshoot issues with command execution. 3. Logging Enhancements: The logging mechanism has been enhanced to provide more detailed and useful information. The use_sudo method now logs the command being executed and its outcome (success or failure). If a command fails, the method logs the command's exit status. These changes improve the transparency of the command execution process and make it easier to identify and troubleshoot issues. 4. Code Refactoring: Several methods have been refactored for improved readability and maintainability. The use_sudo method has been refactored to reduce its complexity and improve its readability. The first_run_setup method has been refactored to ensure that the main interface name and the dummy interface name are properly passed to the setup_traffic_mirroring method. 5. Bug Fixes: A bug in the create_dummy_interface method that caused it to return an array of Alert objects instead of the dummy interface name has been fixed. The method now correctly returns the dummy interface name. These changes represent a significant improvement to the command execution and logging mechanisms in the application, and lay the groundwork for further enhancements in the future.
2023-07-07 11:25:08 -06:00
def first_run_setup # rubocop:disable Metrics/AbcSize, Metrics/MethodLength
ask_for_db_details
dec_pass = decrypt_string_chacha20(ENV['DB_PASSWORD'], ENV['DB_SECRET_KEY'])
connection_established = @db_manager.test_db_connection(ENV['DB_USERNAME'], dec_pass.to_s, ENV['DB_DATABASE'])
Detailed Refactoring of Database Interaction 1. **Refactoring of Database Interaction Methods** - Refactored the `store_services` method in the `DatabaseManager` class to handle an array of services instead of a hash. This change was made to simplify the interaction with the database and to avoid unnecessary complexity in the data structure. - The `store_services` method now iterates over an array of services and inserts each service into the database with a default status of true. This design choice was made to ensure that all services are active by default. 2. **Modification of Database Schema** - Modified the `create_services_table` method in the `DatabaseManager` class to create a table with only two columns: `id` and `services`. This change was made to align the database schema with the new data structure used in the `store_services` method. - The `status` column was removed from the `services` table because the status of all services is now assumed to be true by default. 3. **Error Handling and Debugging** - Encountered a `Sequel::DatabaseError` with the message "Operand should contain 1 column(s)" during the execution of the `store_services` method. This error was caused by an attempt to insert a hash into a single database column. - The error was resolved by refactoring the `store_services` method to handle an array of services instead of a hash. 4. **Unorthodox Design Choices** - The decision to use an array of services instead of a hash and to assume that the status of all services is true by default may seem unorthodox. However, these design choices were made to simplify the interaction with the database and to avoid unnecessary complexity in the data structure. - These design choices also helped to resolve the `Sequel::DatabaseError` that was encountered during the execution of the `store_services` method. This commit represents a significant refactoring of the database interaction methods in the NETRAVE project. The changes made in this commit have simplified the interaction with the database and have resolved a `Sequel::DatabaseError` that was encountered during the execution of the `store_services` method.
2023-06-09 19:39:54 -06:00
Enhancements to Command Execution and Logging Mechanisms This commit introduces several significant enhancements to the way commands are executed and logged in the application. The changes are primarily focused on improving the robustness, reliability, and transparency of the command execution process, as well as enhancing the quality and usefulness of the log output. 1. Command Execution Enhancements: The use_sudo method has been refactored to handle commands that do not return any output. Previously, the method was designed to capture and return the output of the command being executed. However, some commands (such as modprobe) do not return any output, which caused issues with the previous implementation. The method now checks the exit status of the command to determine whether it was successful or not, and returns a success or failure message accordingly. This change improves the robustness of the command execution process and ensures that it can handle a wider range of commands. 2. Error Handling Improvements: The use_sudo method now includes more comprehensive error handling. If a command fails to execute within a specified timeout period, an error message is logged and the method returns a failure message. Additionally, if a command fails to execute for any other reason, the method logs the error and returns a failure message with the command's exit status. These changes make it easier to identify and troubleshoot issues with command execution. 3. Logging Enhancements: The logging mechanism has been enhanced to provide more detailed and useful information. The use_sudo method now logs the command being executed and its outcome (success or failure). If a command fails, the method logs the command's exit status. These changes improve the transparency of the command execution process and make it easier to identify and troubleshoot issues. 4. Code Refactoring: Several methods have been refactored for improved readability and maintainability. The use_sudo method has been refactored to reduce its complexity and improve its readability. The first_run_setup method has been refactored to ensure that the main interface name and the dummy interface name are properly passed to the setup_traffic_mirroring method. 5. Bug Fixes: A bug in the create_dummy_interface method that caused it to return an array of Alert objects instead of the dummy interface name has been fixed. The method now correctly returns the dummy interface name. These changes represent a significant improvement to the command execution and logging mechanisms in the application, and lay the groundwork for further enhancements in the future.
2023-07-07 11:25:08 -06:00
until connection_established
Refactoring for Modularity, Code Reuse, and Security Considerations In this commit, we have undertaken a significant refactoring of the codebase to improve modularity, promote code reuse, and consider security aspects. Modularity and Code Reuse: We introduced classes and modules to better organize the code and facilitate code reuse. Specifically, we created a new Utilities module to hold common methods that are used across different parts of the application. This module includes methods such as convert_speed_to_mbps, services_to_hash, and calculate_total_bandwidth. By placing these methods in a module, we can include this module in any class that needs these methods, thereby promoting code reuse and reducing duplication. We also created two new classes, SystemInformationGather and DatabaseManager. The SystemInformationGather class is responsible for gathering system information, such as uplink and downlink speed, and services. The DatabaseManager class handles database operations, including testing the database connection, creating the system information table, and storing system information in the database. By encapsulating these responsibilities within their respective classes, we have made the code more organized and easier to maintain. Database Connection Details: We made a decision to store the database connection details in a config file (config.yml) instead of the database itself. This decision was made for security reasons, as storing these details in the database could expose them to potential security risks. Storing these details in a config file allows us to better control access to these details. Database Encryption: We discussed the possibility of encrypting the database for additional security. While we have not implemented this feature in this commit, we have laid the groundwork for it by discussing potential libraries/gems that could be used for this purpose. This is an area that we will revisit in the future. System Information Gathering: We wrote methods to gather system information, such as uplink and downlink speed, and services, and store this information in the database. This information will be useful for monitoring system performance and for making decisions about resource allocation. This refactoring effort has made the codebase more organized, easier to maintain, and more secure. It also aligns with our project goals and roadmap. However, it's important to note that with any refactoring effort, there may be potential issues or trade-offs. We will need to thoroughly test the refactored code to ensure that it works as expected and that there are no unintended side effects.
2023-06-04 14:41:12 -06:00
Curses.setpos(4, 0)
Enhancements to Command Execution and Logging Mechanisms This commit introduces several significant enhancements to the way commands are executed and logged in the application. The changes are primarily focused on improving the robustness, reliability, and transparency of the command execution process, as well as enhancing the quality and usefulness of the log output. 1. Command Execution Enhancements: The use_sudo method has been refactored to handle commands that do not return any output. Previously, the method was designed to capture and return the output of the command being executed. However, some commands (such as modprobe) do not return any output, which caused issues with the previous implementation. The method now checks the exit status of the command to determine whether it was successful or not, and returns a success or failure message accordingly. This change improves the robustness of the command execution process and ensures that it can handle a wider range of commands. 2. Error Handling Improvements: The use_sudo method now includes more comprehensive error handling. If a command fails to execute within a specified timeout period, an error message is logged and the method returns a failure message. Additionally, if a command fails to execute for any other reason, the method logs the error and returns a failure message with the command's exit status. These changes make it easier to identify and troubleshoot issues with command execution. 3. Logging Enhancements: The logging mechanism has been enhanced to provide more detailed and useful information. The use_sudo method now logs the command being executed and its outcome (success or failure). If a command fails, the method logs the command's exit status. These changes improve the transparency of the command execution process and make it easier to identify and troubleshoot issues. 4. Code Refactoring: Several methods have been refactored for improved readability and maintainability. The use_sudo method has been refactored to reduce its complexity and improve its readability. The first_run_setup method has been refactored to ensure that the main interface name and the dummy interface name are properly passed to the setup_traffic_mirroring method. 5. Bug Fixes: A bug in the create_dummy_interface method that caused it to return an array of Alert objects instead of the dummy interface name has been fixed. The method now correctly returns the dummy interface name. These changes represent a significant improvement to the command execution and logging mechanisms in the application, and lay the groundwork for further enhancements in the future.
2023-07-07 11:25:08 -06:00
alert = Alert.new("We couldn't connect to the database with the details you provided Please try again!", :warning)
@alert_queue_manager.enqueue_alert(alert)
Curses.refresh
Enhancements to Command Execution and Logging Mechanisms This commit introduces several significant enhancements to the way commands are executed and logged in the application. The changes are primarily focused on improving the robustness, reliability, and transparency of the command execution process, as well as enhancing the quality and usefulness of the log output. 1. Command Execution Enhancements: The use_sudo method has been refactored to handle commands that do not return any output. Previously, the method was designed to capture and return the output of the command being executed. However, some commands (such as modprobe) do not return any output, which caused issues with the previous implementation. The method now checks the exit status of the command to determine whether it was successful or not, and returns a success or failure message accordingly. This change improves the robustness of the command execution process and ensures that it can handle a wider range of commands. 2. Error Handling Improvements: The use_sudo method now includes more comprehensive error handling. If a command fails to execute within a specified timeout period, an error message is logged and the method returns a failure message. Additionally, if a command fails to execute for any other reason, the method logs the error and returns a failure message with the command's exit status. These changes make it easier to identify and troubleshoot issues with command execution. 3. Logging Enhancements: The logging mechanism has been enhanced to provide more detailed and useful information. The use_sudo method now logs the command being executed and its outcome (success or failure). If a command fails, the method logs the command's exit status. These changes improve the transparency of the command execution process and make it easier to identify and troubleshoot issues. 4. Code Refactoring: Several methods have been refactored for improved readability and maintainability. The use_sudo method has been refactored to reduce its complexity and improve its readability. The first_run_setup method has been refactored to ensure that the main interface name and the dummy interface name are properly passed to the setup_traffic_mirroring method. 5. Bug Fixes: A bug in the create_dummy_interface method that caused it to return an array of Alert objects instead of the dummy interface name has been fixed. The method now correctly returns the dummy interface name. These changes represent a significant improvement to the command execution and logging mechanisms in the application, and lay the groundwork for further enhancements in the future.
2023-07-07 11:25:08 -06:00
ask_for_db_details
connection_established = @db_manager.test_db_connection(ENV['DB_USERNAME'], dec_pass.to_s, ENV['DB_DATABASE'])
end
Detailed Refactoring of Database Interaction 1. **Refactoring of Database Interaction Methods** - Refactored the `store_services` method in the `DatabaseManager` class to handle an array of services instead of a hash. This change was made to simplify the interaction with the database and to avoid unnecessary complexity in the data structure. - The `store_services` method now iterates over an array of services and inserts each service into the database with a default status of true. This design choice was made to ensure that all services are active by default. 2. **Modification of Database Schema** - Modified the `create_services_table` method in the `DatabaseManager` class to create a table with only two columns: `id` and `services`. This change was made to align the database schema with the new data structure used in the `store_services` method. - The `status` column was removed from the `services` table because the status of all services is now assumed to be true by default. 3. **Error Handling and Debugging** - Encountered a `Sequel::DatabaseError` with the message "Operand should contain 1 column(s)" during the execution of the `store_services` method. This error was caused by an attempt to insert a hash into a single database column. - The error was resolved by refactoring the `store_services` method to handle an array of services instead of a hash. 4. **Unorthodox Design Choices** - The decision to use an array of services instead of a hash and to assume that the status of all services is true by default may seem unorthodox. However, these design choices were made to simplify the interaction with the database and to avoid unnecessary complexity in the data structure. - These design choices also helped to resolve the `Sequel::DatabaseError` that was encountered during the execution of the `store_services` method. This commit represents a significant refactoring of the database interaction methods in the NETRAVE project. The changes made in this commit have simplified the interaction with the database and have resolved a `Sequel::DatabaseError` that was encountered during the execution of the `store_services` method.
2023-06-09 19:39:54 -06:00
Refactoring for Modularity, Code Reuse, and Security Considerations In this commit, we have undertaken a significant refactoring of the codebase to improve modularity, promote code reuse, and consider security aspects. Modularity and Code Reuse: We introduced classes and modules to better organize the code and facilitate code reuse. Specifically, we created a new Utilities module to hold common methods that are used across different parts of the application. This module includes methods such as convert_speed_to_mbps, services_to_hash, and calculate_total_bandwidth. By placing these methods in a module, we can include this module in any class that needs these methods, thereby promoting code reuse and reducing duplication. We also created two new classes, SystemInformationGather and DatabaseManager. The SystemInformationGather class is responsible for gathering system information, such as uplink and downlink speed, and services. The DatabaseManager class handles database operations, including testing the database connection, creating the system information table, and storing system information in the database. By encapsulating these responsibilities within their respective classes, we have made the code more organized and easier to maintain. Database Connection Details: We made a decision to store the database connection details in a config file (config.yml) instead of the database itself. This decision was made for security reasons, as storing these details in the database could expose them to potential security risks. Storing these details in a config file allows us to better control access to these details. Database Encryption: We discussed the possibility of encrypting the database for additional security. While we have not implemented this feature in this commit, we have laid the groundwork for it by discussing potential libraries/gems that could be used for this purpose. This is an area that we will revisit in the future. System Information Gathering: We wrote methods to gather system information, such as uplink and downlink speed, and services, and store this information in the database. This information will be useful for monitoring system performance and for making decisions about resource allocation. This refactoring effort has made the codebase more organized, easier to maintain, and more secure. It also aligns with our project goals and roadmap. However, it's important to note that with any refactoring effort, there may be potential issues or trade-offs. We will need to thoroughly test the refactored code to ensure that it works as expected and that there are no unintended side effects.
2023-06-04 14:41:12 -06:00
@db_manager.create_system_info_table
Detailed Refactoring of Database Interaction 1. **Refactoring of Database Interaction Methods** - Refactored the `store_services` method in the `DatabaseManager` class to handle an array of services instead of a hash. This change was made to simplify the interaction with the database and to avoid unnecessary complexity in the data structure. - The `store_services` method now iterates over an array of services and inserts each service into the database with a default status of true. This design choice was made to ensure that all services are active by default. 2. **Modification of Database Schema** - Modified the `create_services_table` method in the `DatabaseManager` class to create a table with only two columns: `id` and `services`. This change was made to align the database schema with the new data structure used in the `store_services` method. - The `status` column was removed from the `services` table because the status of all services is now assumed to be true by default. 3. **Error Handling and Debugging** - Encountered a `Sequel::DatabaseError` with the message "Operand should contain 1 column(s)" during the execution of the `store_services` method. This error was caused by an attempt to insert a hash into a single database column. - The error was resolved by refactoring the `store_services` method to handle an array of services instead of a hash. 4. **Unorthodox Design Choices** - The decision to use an array of services instead of a hash and to assume that the status of all services is true by default may seem unorthodox. However, these design choices were made to simplify the interaction with the database and to avoid unnecessary complexity in the data structure. - These design choices also helped to resolve the `Sequel::DatabaseError` that was encountered during the execution of the `store_services` method. This commit represents a significant refactoring of the database interaction methods in the NETRAVE project. The changes made in this commit have simplified the interaction with the database and have resolved a `Sequel::DatabaseError` that was encountered during the execution of the `store_services` method.
2023-06-09 19:39:54 -06:00
@db_manager.create_services_table
Refactoring for Modularity, Code Reuse, and Security Considerations In this commit, we have undertaken a significant refactoring of the codebase to improve modularity, promote code reuse, and consider security aspects. Modularity and Code Reuse: We introduced classes and modules to better organize the code and facilitate code reuse. Specifically, we created a new Utilities module to hold common methods that are used across different parts of the application. This module includes methods such as convert_speed_to_mbps, services_to_hash, and calculate_total_bandwidth. By placing these methods in a module, we can include this module in any class that needs these methods, thereby promoting code reuse and reducing duplication. We also created two new classes, SystemInformationGather and DatabaseManager. The SystemInformationGather class is responsible for gathering system information, such as uplink and downlink speed, and services. The DatabaseManager class handles database operations, including testing the database connection, creating the system information table, and storing system information in the database. By encapsulating these responsibilities within their respective classes, we have made the code more organized and easier to maintain. Database Connection Details: We made a decision to store the database connection details in a config file (config.yml) instead of the database itself. This decision was made for security reasons, as storing these details in the database could expose them to potential security risks. Storing these details in a config file allows us to better control access to these details. Database Encryption: We discussed the possibility of encrypting the database for additional security. While we have not implemented this feature in this commit, we have laid the groundwork for it by discussing potential libraries/gems that could be used for this purpose. This is an area that we will revisit in the future. System Information Gathering: We wrote methods to gather system information, such as uplink and downlink speed, and services, and store this information in the database. This information will be useful for monitoring system performance and for making decisions about resource allocation. This refactoring effort has made the codebase more organized, easier to maintain, and more secure. It also aligns with our project goals and roadmap. However, it's important to note that with any refactoring effort, there may be potential issues or trade-offs. We will need to thoroughly test the refactored code to ensure that it works as expected and that there are no unintended side effects.
2023-06-04 14:41:12 -06:00
uplink_speed = @info_gatherer.ask_for_uplink_speed
downlink_speed = @info_gatherer.ask_for_downlink_speed
total_bandwidth = calculate_total_bandwidth(uplink_speed, downlink_speed)
services = @info_gatherer.ask_for_services
Detailed Refactoring of Database Interaction 1. **Refactoring of Database Interaction Methods** - Refactored the `store_services` method in the `DatabaseManager` class to handle an array of services instead of a hash. This change was made to simplify the interaction with the database and to avoid unnecessary complexity in the data structure. - The `store_services` method now iterates over an array of services and inserts each service into the database with a default status of true. This design choice was made to ensure that all services are active by default. 2. **Modification of Database Schema** - Modified the `create_services_table` method in the `DatabaseManager` class to create a table with only two columns: `id` and `services`. This change was made to align the database schema with the new data structure used in the `store_services` method. - The `status` column was removed from the `services` table because the status of all services is now assumed to be true by default. 3. **Error Handling and Debugging** - Encountered a `Sequel::DatabaseError` with the message "Operand should contain 1 column(s)" during the execution of the `store_services` method. This error was caused by an attempt to insert a hash into a single database column. - The error was resolved by refactoring the `store_services` method to handle an array of services instead of a hash. 4. **Unorthodox Design Choices** - The decision to use an array of services instead of a hash and to assume that the status of all services is true by default may seem unorthodox. However, these design choices were made to simplify the interaction with the database and to avoid unnecessary complexity in the data structure. - These design choices also helped to resolve the `Sequel::DatabaseError` that was encountered during the execution of the `store_services` method. This commit represents a significant refactoring of the database interaction methods in the NETRAVE project. The changes made in this commit have simplified the interaction with the database and have resolved a `Sequel::DatabaseError` that was encountered during the execution of the `store_services` method.
2023-06-09 19:39:54 -06:00
system_info = {
uplink_speed:,
downlink_speed:,
total_bandwidth:
}
@db_manager.store_system_info(system_info)
@db_manager.store_services(services)
Enhancements to Command Execution and Logging Mechanisms This commit introduces several significant enhancements to the way commands are executed and logged in the application. The changes are primarily focused on improving the robustness, reliability, and transparency of the command execution process, as well as enhancing the quality and usefulness of the log output. 1. Command Execution Enhancements: The use_sudo method has been refactored to handle commands that do not return any output. Previously, the method was designed to capture and return the output of the command being executed. However, some commands (such as modprobe) do not return any output, which caused issues with the previous implementation. The method now checks the exit status of the command to determine whether it was successful or not, and returns a success or failure message accordingly. This change improves the robustness of the command execution process and ensures that it can handle a wider range of commands. 2. Error Handling Improvements: The use_sudo method now includes more comprehensive error handling. If a command fails to execute within a specified timeout period, an error message is logged and the method returns a failure message. Additionally, if a command fails to execute for any other reason, the method logs the error and returns a failure message with the command's exit status. These changes make it easier to identify and troubleshoot issues with command execution. 3. Logging Enhancements: The logging mechanism has been enhanced to provide more detailed and useful information. The use_sudo method now logs the command being executed and its outcome (success or failure). If a command fails, the method logs the command's exit status. These changes improve the transparency of the command execution process and make it easier to identify and troubleshoot issues. 4. Code Refactoring: Several methods have been refactored for improved readability and maintainability. The use_sudo method has been refactored to reduce its complexity and improve its readability. The first_run_setup method has been refactored to ensure that the main interface name and the dummy interface name are properly passed to the setup_traffic_mirroring method. 5. Bug Fixes: A bug in the create_dummy_interface method that caused it to return an array of Alert objects instead of the dummy interface name has been fixed. The method now correctly returns the dummy interface name. These changes represent a significant improvement to the command execution and logging mechanisms in the application, and lay the groundwork for further enhancements in the future.
2023-07-07 11:25:08 -06:00
# ask for sudo permissions to setup the networking stuff we need
ask_for_sudo(@loggman)
# Set up networking
networking_genie = NetworkingGenie.new(@loggman, @alert_queue_manager)
main_interface = networking_genie.find_main_interface
dummy_interface = networking_genie.create_dummy_interface('netrave0')
networking_genie.setup_traffic_mirroring(main_interface, dummy_interface)
end
Detailed Refactoring of Database Interaction 1. **Refactoring of Database Interaction Methods** - Refactored the `store_services` method in the `DatabaseManager` class to handle an array of services instead of a hash. This change was made to simplify the interaction with the database and to avoid unnecessary complexity in the data structure. - The `store_services` method now iterates over an array of services and inserts each service into the database with a default status of true. This design choice was made to ensure that all services are active by default. 2. **Modification of Database Schema** - Modified the `create_services_table` method in the `DatabaseManager` class to create a table with only two columns: `id` and `services`. This change was made to align the database schema with the new data structure used in the `store_services` method. - The `status` column was removed from the `services` table because the status of all services is now assumed to be true by default. 3. **Error Handling and Debugging** - Encountered a `Sequel::DatabaseError` with the message "Operand should contain 1 column(s)" during the execution of the `store_services` method. This error was caused by an attempt to insert a hash into a single database column. - The error was resolved by refactoring the `store_services` method to handle an array of services instead of a hash. 4. **Unorthodox Design Choices** - The decision to use an array of services instead of a hash and to assume that the status of all services is true by default may seem unorthodox. However, these design choices were made to simplify the interaction with the database and to avoid unnecessary complexity in the data structure. - These design choices also helped to resolve the `Sequel::DatabaseError` that was encountered during the execution of the `store_services` method. This commit represents a significant refactoring of the database interaction methods in the NETRAVE project. The changes made in this commit have simplified the interaction with the database and have resolved a `Sequel::DatabaseError` that was encountered during the execution of the `store_services` method.
2023-06-09 19:39:54 -06:00
def ask_for_db_details # rubocop:disable Metrics/MethodLength, Metrics/AbcSize
@loggman.log_info('Asking for Database details...')
Refactoring and Enhancing Database Management and System Information Gathering In this commit, we've made substantial changes to the DatabaseManager and SystemInformationGather classes to improve the functionality, efficiency, and maintainability of the system. Refactoring DatabaseManager: The DatabaseManager class was refactored to improve the separation of concerns. Initially, the DatabaseManager was responsible for creating an instance of SystemInformationGather, which was not ideal as it violated the Single Responsibility Principle. The responsibility of creating an instance of SystemInformationGather was moved to the FirstRunInit class, which is more appropriate as it is responsible for the initial setup of the system. This change improves the maintainability of the code and makes it easier to understand and modify in the future. Adding Database Connection Test: A method test_db_connection was added to the DatabaseManager to test the database connection before attempting to interact with it. This method improves the robustness of the system by ensuring that a valid connection exists before proceeding. It also provides a better user experience by providing a clear error message if the connection fails. Refactoring SystemInformationGather: The SystemInformationGather class was refactored to improve its functionality and efficiency. The methods ask_for_uplink_speed and ask_for_downlink_speed were modified to convert the user's input to Mbps immediately, reducing the need for conversion later. This change improves the efficiency of the system by reducing unnecessary conversions. Adding Services Table: A new table for services was added to the database. This table stores the services that the system should be aware of, with each service represented as a boolean value. This change improves the flexibility of the system by allowing it to handle a variable number of services. It also improves the efficiency of the system by reducing the need to parse the services from a string each time they are needed. Storing Total Bandwidth: The total bandwidth (the sum of the uplink and downlink speeds) is now calculated and stored in the system_info table. This change improves the efficiency of the system by reducing the need to calculate the total bandwidth each time it is needed. Error Handling and Debugging: Throughout the process, various bugs and errors were encountered and fixed. These included issues with method arguments, missing method calls, and incorrect method usage. Fixing these issues improved the stability and reliability of the system. In conclusion, this commit significantly improves the functionality, efficiency, and maintainability of the system. The changes made adhere to good software engineering principles, such as the Single Responsibility Principle, and make the system more robust and user-friendly.
2023-06-05 14:21:29 -06:00
Curses.clear
Detailed Refactoring of Database Interaction 1. **Refactoring of Database Interaction Methods** - Refactored the `store_services` method in the `DatabaseManager` class to handle an array of services instead of a hash. This change was made to simplify the interaction with the database and to avoid unnecessary complexity in the data structure. - The `store_services` method now iterates over an array of services and inserts each service into the database with a default status of true. This design choice was made to ensure that all services are active by default. 2. **Modification of Database Schema** - Modified the `create_services_table` method in the `DatabaseManager` class to create a table with only two columns: `id` and `services`. This change was made to align the database schema with the new data structure used in the `store_services` method. - The `status` column was removed from the `services` table because the status of all services is now assumed to be true by default. 3. **Error Handling and Debugging** - Encountered a `Sequel::DatabaseError` with the message "Operand should contain 1 column(s)" during the execution of the `store_services` method. This error was caused by an attempt to insert a hash into a single database column. - The error was resolved by refactoring the `store_services` method to handle an array of services instead of a hash. 4. **Unorthodox Design Choices** - The decision to use an array of services instead of a hash and to assume that the status of all services is true by default may seem unorthodox. However, these design choices were made to simplify the interaction with the database and to avoid unnecessary complexity in the data structure. - These design choices also helped to resolve the `Sequel::DatabaseError` that was encountered during the execution of the `store_services` method. This commit represents a significant refactoring of the database interaction methods in the NETRAVE project. The changes made in this commit have simplified the interaction with the database and have resolved a `Sequel::DatabaseError` that was encountered during the execution of the `store_services` method.
2023-06-09 19:39:54 -06:00
Refactoring and Enhancing Database Management and System Information Gathering In this commit, we've made substantial changes to the DatabaseManager and SystemInformationGather classes to improve the functionality, efficiency, and maintainability of the system. Refactoring DatabaseManager: The DatabaseManager class was refactored to improve the separation of concerns. Initially, the DatabaseManager was responsible for creating an instance of SystemInformationGather, which was not ideal as it violated the Single Responsibility Principle. The responsibility of creating an instance of SystemInformationGather was moved to the FirstRunInit class, which is more appropriate as it is responsible for the initial setup of the system. This change improves the maintainability of the code and makes it easier to understand and modify in the future. Adding Database Connection Test: A method test_db_connection was added to the DatabaseManager to test the database connection before attempting to interact with it. This method improves the robustness of the system by ensuring that a valid connection exists before proceeding. It also provides a better user experience by providing a clear error message if the connection fails. Refactoring SystemInformationGather: The SystemInformationGather class was refactored to improve its functionality and efficiency. The methods ask_for_uplink_speed and ask_for_downlink_speed were modified to convert the user's input to Mbps immediately, reducing the need for conversion later. This change improves the efficiency of the system by reducing unnecessary conversions. Adding Services Table: A new table for services was added to the database. This table stores the services that the system should be aware of, with each service represented as a boolean value. This change improves the flexibility of the system by allowing it to handle a variable number of services. It also improves the efficiency of the system by reducing the need to parse the services from a string each time they are needed. Storing Total Bandwidth: The total bandwidth (the sum of the uplink and downlink speeds) is now calculated and stored in the system_info table. This change improves the efficiency of the system by reducing the need to calculate the total bandwidth each time it is needed. Error Handling and Debugging: Throughout the process, various bugs and errors were encountered and fixed. These included issues with method arguments, missing method calls, and incorrect method usage. Fixing these issues improved the stability and reliability of the system. In conclusion, this commit significantly improves the functionality, efficiency, and maintainability of the system. The changes made adhere to good software engineering principles, such as the Single Responsibility Principle, and make the system more robust and user-friendly.
2023-06-05 14:21:29 -06:00
Curses.setpos(1, 0)
Detailed Refactoring of Database Interaction 1. **Refactoring of Database Interaction Methods** - Refactored the `store_services` method in the `DatabaseManager` class to handle an array of services instead of a hash. This change was made to simplify the interaction with the database and to avoid unnecessary complexity in the data structure. - The `store_services` method now iterates over an array of services and inserts each service into the database with a default status of true. This design choice was made to ensure that all services are active by default. 2. **Modification of Database Schema** - Modified the `create_services_table` method in the `DatabaseManager` class to create a table with only two columns: `id` and `services`. This change was made to align the database schema with the new data structure used in the `store_services` method. - The `status` column was removed from the `services` table because the status of all services is now assumed to be true by default. 3. **Error Handling and Debugging** - Encountered a `Sequel::DatabaseError` with the message "Operand should contain 1 column(s)" during the execution of the `store_services` method. This error was caused by an attempt to insert a hash into a single database column. - The error was resolved by refactoring the `store_services` method to handle an array of services instead of a hash. 4. **Unorthodox Design Choices** - The decision to use an array of services instead of a hash and to assume that the status of all services is true by default may seem unorthodox. However, these design choices were made to simplify the interaction with the database and to avoid unnecessary complexity in the data structure. - These design choices also helped to resolve the `Sequel::DatabaseError` that was encountered during the execution of the `store_services` method. This commit represents a significant refactoring of the database interaction methods in the NETRAVE project. The changes made in this commit have simplified the interaction with the database and have resolved a `Sequel::DatabaseError` that was encountered during the execution of the `store_services` method.
2023-06-09 19:39:54 -06:00
Curses.addstr('Please enter your database username: ')
Refactoring and Enhancing Database Management and System Information Gathering In this commit, we've made substantial changes to the DatabaseManager and SystemInformationGather classes to improve the functionality, efficiency, and maintainability of the system. Refactoring DatabaseManager: The DatabaseManager class was refactored to improve the separation of concerns. Initially, the DatabaseManager was responsible for creating an instance of SystemInformationGather, which was not ideal as it violated the Single Responsibility Principle. The responsibility of creating an instance of SystemInformationGather was moved to the FirstRunInit class, which is more appropriate as it is responsible for the initial setup of the system. This change improves the maintainability of the code and makes it easier to understand and modify in the future. Adding Database Connection Test: A method test_db_connection was added to the DatabaseManager to test the database connection before attempting to interact with it. This method improves the robustness of the system by ensuring that a valid connection exists before proceeding. It also provides a better user experience by providing a clear error message if the connection fails. Refactoring SystemInformationGather: The SystemInformationGather class was refactored to improve its functionality and efficiency. The methods ask_for_uplink_speed and ask_for_downlink_speed were modified to convert the user's input to Mbps immediately, reducing the need for conversion later. This change improves the efficiency of the system by reducing unnecessary conversions. Adding Services Table: A new table for services was added to the database. This table stores the services that the system should be aware of, with each service represented as a boolean value. This change improves the flexibility of the system by allowing it to handle a variable number of services. It also improves the efficiency of the system by reducing the need to parse the services from a string each time they are needed. Storing Total Bandwidth: The total bandwidth (the sum of the uplink and downlink speeds) is now calculated and stored in the system_info table. This change improves the efficiency of the system by reducing the need to calculate the total bandwidth each time it is needed. Error Handling and Debugging: Throughout the process, various bugs and errors were encountered and fixed. These included issues with method arguments, missing method calls, and incorrect method usage. Fixing these issues improved the stability and reliability of the system. In conclusion, this commit significantly improves the functionality, efficiency, and maintainability of the system. The changes made adhere to good software engineering principles, such as the Single Responsibility Principle, and make the system more robust and user-friendly.
2023-06-05 14:21:29 -06:00
Curses.refresh
Detailed Refactoring of Database Interaction 1. **Refactoring of Database Interaction Methods** - Refactored the `store_services` method in the `DatabaseManager` class to handle an array of services instead of a hash. This change was made to simplify the interaction with the database and to avoid unnecessary complexity in the data structure. - The `store_services` method now iterates over an array of services and inserts each service into the database with a default status of true. This design choice was made to ensure that all services are active by default. 2. **Modification of Database Schema** - Modified the `create_services_table` method in the `DatabaseManager` class to create a table with only two columns: `id` and `services`. This change was made to align the database schema with the new data structure used in the `store_services` method. - The `status` column was removed from the `services` table because the status of all services is now assumed to be true by default. 3. **Error Handling and Debugging** - Encountered a `Sequel::DatabaseError` with the message "Operand should contain 1 column(s)" during the execution of the `store_services` method. This error was caused by an attempt to insert a hash into a single database column. - The error was resolved by refactoring the `store_services` method to handle an array of services instead of a hash. 4. **Unorthodox Design Choices** - The decision to use an array of services instead of a hash and to assume that the status of all services is true by default may seem unorthodox. However, these design choices were made to simplify the interaction with the database and to avoid unnecessary complexity in the data structure. - These design choices also helped to resolve the `Sequel::DatabaseError` that was encountered during the execution of the `store_services` method. This commit represents a significant refactoring of the database interaction methods in the NETRAVE project. The changes made in this commit have simplified the interaction with the database and have resolved a `Sequel::DatabaseError` that was encountered during the execution of the `store_services` method.
2023-06-09 19:39:54 -06:00
username = DCI.catch_input(true)
@loggman.log_info('Database Username entered!')
Refactoring and Enhancing Database Management and System Information Gathering In this commit, we've made substantial changes to the DatabaseManager and SystemInformationGather classes to improve the functionality, efficiency, and maintainability of the system. Refactoring DatabaseManager: The DatabaseManager class was refactored to improve the separation of concerns. Initially, the DatabaseManager was responsible for creating an instance of SystemInformationGather, which was not ideal as it violated the Single Responsibility Principle. The responsibility of creating an instance of SystemInformationGather was moved to the FirstRunInit class, which is more appropriate as it is responsible for the initial setup of the system. This change improves the maintainability of the code and makes it easier to understand and modify in the future. Adding Database Connection Test: A method test_db_connection was added to the DatabaseManager to test the database connection before attempting to interact with it. This method improves the robustness of the system by ensuring that a valid connection exists before proceeding. It also provides a better user experience by providing a clear error message if the connection fails. Refactoring SystemInformationGather: The SystemInformationGather class was refactored to improve its functionality and efficiency. The methods ask_for_uplink_speed and ask_for_downlink_speed were modified to convert the user's input to Mbps immediately, reducing the need for conversion later. This change improves the efficiency of the system by reducing unnecessary conversions. Adding Services Table: A new table for services was added to the database. This table stores the services that the system should be aware of, with each service represented as a boolean value. This change improves the flexibility of the system by allowing it to handle a variable number of services. It also improves the efficiency of the system by reducing the need to parse the services from a string each time they are needed. Storing Total Bandwidth: The total bandwidth (the sum of the uplink and downlink speeds) is now calculated and stored in the system_info table. This change improves the efficiency of the system by reducing the need to calculate the total bandwidth each time it is needed. Error Handling and Debugging: Throughout the process, various bugs and errors were encountered and fixed. These included issues with method arguments, missing method calls, and incorrect method usage. Fixing these issues improved the stability and reliability of the system. In conclusion, this commit significantly improves the functionality, efficiency, and maintainability of the system. The changes made adhere to good software engineering principles, such as the Single Responsibility Principle, and make the system more robust and user-friendly.
2023-06-05 14:21:29 -06:00
Curses.setpos(2, 0)
Detailed Refactoring of Database Interaction 1. **Refactoring of Database Interaction Methods** - Refactored the `store_services` method in the `DatabaseManager` class to handle an array of services instead of a hash. This change was made to simplify the interaction with the database and to avoid unnecessary complexity in the data structure. - The `store_services` method now iterates over an array of services and inserts each service into the database with a default status of true. This design choice was made to ensure that all services are active by default. 2. **Modification of Database Schema** - Modified the `create_services_table` method in the `DatabaseManager` class to create a table with only two columns: `id` and `services`. This change was made to align the database schema with the new data structure used in the `store_services` method. - The `status` column was removed from the `services` table because the status of all services is now assumed to be true by default. 3. **Error Handling and Debugging** - Encountered a `Sequel::DatabaseError` with the message "Operand should contain 1 column(s)" during the execution of the `store_services` method. This error was caused by an attempt to insert a hash into a single database column. - The error was resolved by refactoring the `store_services` method to handle an array of services instead of a hash. 4. **Unorthodox Design Choices** - The decision to use an array of services instead of a hash and to assume that the status of all services is true by default may seem unorthodox. However, these design choices were made to simplify the interaction with the database and to avoid unnecessary complexity in the data structure. - These design choices also helped to resolve the `Sequel::DatabaseError` that was encountered during the execution of the `store_services` method. This commit represents a significant refactoring of the database interaction methods in the NETRAVE project. The changes made in this commit have simplified the interaction with the database and have resolved a `Sequel::DatabaseError` that was encountered during the execution of the `store_services` method.
2023-06-09 19:39:54 -06:00
Curses.addstr('Please enter your database password: ')
Refactoring and Enhancing Database Management and System Information Gathering In this commit, we've made substantial changes to the DatabaseManager and SystemInformationGather classes to improve the functionality, efficiency, and maintainability of the system. Refactoring DatabaseManager: The DatabaseManager class was refactored to improve the separation of concerns. Initially, the DatabaseManager was responsible for creating an instance of SystemInformationGather, which was not ideal as it violated the Single Responsibility Principle. The responsibility of creating an instance of SystemInformationGather was moved to the FirstRunInit class, which is more appropriate as it is responsible for the initial setup of the system. This change improves the maintainability of the code and makes it easier to understand and modify in the future. Adding Database Connection Test: A method test_db_connection was added to the DatabaseManager to test the database connection before attempting to interact with it. This method improves the robustness of the system by ensuring that a valid connection exists before proceeding. It also provides a better user experience by providing a clear error message if the connection fails. Refactoring SystemInformationGather: The SystemInformationGather class was refactored to improve its functionality and efficiency. The methods ask_for_uplink_speed and ask_for_downlink_speed were modified to convert the user's input to Mbps immediately, reducing the need for conversion later. This change improves the efficiency of the system by reducing unnecessary conversions. Adding Services Table: A new table for services was added to the database. This table stores the services that the system should be aware of, with each service represented as a boolean value. This change improves the flexibility of the system by allowing it to handle a variable number of services. It also improves the efficiency of the system by reducing the need to parse the services from a string each time they are needed. Storing Total Bandwidth: The total bandwidth (the sum of the uplink and downlink speeds) is now calculated and stored in the system_info table. This change improves the efficiency of the system by reducing the need to calculate the total bandwidth each time it is needed. Error Handling and Debugging: Throughout the process, various bugs and errors were encountered and fixed. These included issues with method arguments, missing method calls, and incorrect method usage. Fixing these issues improved the stability and reliability of the system. In conclusion, this commit significantly improves the functionality, efficiency, and maintainability of the system. The changes made adhere to good software engineering principles, such as the Single Responsibility Principle, and make the system more robust and user-friendly.
2023-06-05 14:21:29 -06:00
Curses.refresh
Curses.noecho
Detailed Refactoring of Database Interaction 1. **Refactoring of Database Interaction Methods** - Refactored the `store_services` method in the `DatabaseManager` class to handle an array of services instead of a hash. This change was made to simplify the interaction with the database and to avoid unnecessary complexity in the data structure. - The `store_services` method now iterates over an array of services and inserts each service into the database with a default status of true. This design choice was made to ensure that all services are active by default. 2. **Modification of Database Schema** - Modified the `create_services_table` method in the `DatabaseManager` class to create a table with only two columns: `id` and `services`. This change was made to align the database schema with the new data structure used in the `store_services` method. - The `status` column was removed from the `services` table because the status of all services is now assumed to be true by default. 3. **Error Handling and Debugging** - Encountered a `Sequel::DatabaseError` with the message "Operand should contain 1 column(s)" during the execution of the `store_services` method. This error was caused by an attempt to insert a hash into a single database column. - The error was resolved by refactoring the `store_services` method to handle an array of services instead of a hash. 4. **Unorthodox Design Choices** - The decision to use an array of services instead of a hash and to assume that the status of all services is true by default may seem unorthodox. However, these design choices were made to simplify the interaction with the database and to avoid unnecessary complexity in the data structure. - These design choices also helped to resolve the `Sequel::DatabaseError` that was encountered during the execution of the `store_services` method. This commit represents a significant refactoring of the database interaction methods in the NETRAVE project. The changes made in this commit have simplified the interaction with the database and have resolved a `Sequel::DatabaseError` that was encountered during the execution of the `store_services` method.
2023-06-09 19:39:54 -06:00
password = DCI.catch_input(false)
@loggman.log_info('Database Password Stored Securely!')
Refactoring and Enhancing Database Management and System Information Gathering In this commit, we've made substantial changes to the DatabaseManager and SystemInformationGather classes to improve the functionality, efficiency, and maintainability of the system. Refactoring DatabaseManager: The DatabaseManager class was refactored to improve the separation of concerns. Initially, the DatabaseManager was responsible for creating an instance of SystemInformationGather, which was not ideal as it violated the Single Responsibility Principle. The responsibility of creating an instance of SystemInformationGather was moved to the FirstRunInit class, which is more appropriate as it is responsible for the initial setup of the system. This change improves the maintainability of the code and makes it easier to understand and modify in the future. Adding Database Connection Test: A method test_db_connection was added to the DatabaseManager to test the database connection before attempting to interact with it. This method improves the robustness of the system by ensuring that a valid connection exists before proceeding. It also provides a better user experience by providing a clear error message if the connection fails. Refactoring SystemInformationGather: The SystemInformationGather class was refactored to improve its functionality and efficiency. The methods ask_for_uplink_speed and ask_for_downlink_speed were modified to convert the user's input to Mbps immediately, reducing the need for conversion later. This change improves the efficiency of the system by reducing unnecessary conversions. Adding Services Table: A new table for services was added to the database. This table stores the services that the system should be aware of, with each service represented as a boolean value. This change improves the flexibility of the system by allowing it to handle a variable number of services. It also improves the efficiency of the system by reducing the need to parse the services from a string each time they are needed. Storing Total Bandwidth: The total bandwidth (the sum of the uplink and downlink speeds) is now calculated and stored in the system_info table. This change improves the efficiency of the system by reducing the need to calculate the total bandwidth each time it is needed. Error Handling and Debugging: Throughout the process, various bugs and errors were encountered and fixed. These included issues with method arguments, missing method calls, and incorrect method usage. Fixing these issues improved the stability and reliability of the system. In conclusion, this commit significantly improves the functionality, efficiency, and maintainability of the system. The changes made adhere to good software engineering principles, such as the Single Responsibility Principle, and make the system more robust and user-friendly.
2023-06-05 14:21:29 -06:00
Curses.echo
Refactoring and Enhancing Database Management and System Information Gathering In this commit, we've made substantial changes to the DatabaseManager and SystemInformationGather classes to improve the functionality, efficiency, and maintainability of the system. Refactoring DatabaseManager: The DatabaseManager class was refactored to improve the separation of concerns. Initially, the DatabaseManager was responsible for creating an instance of SystemInformationGather, which was not ideal as it violated the Single Responsibility Principle. The responsibility of creating an instance of SystemInformationGather was moved to the FirstRunInit class, which is more appropriate as it is responsible for the initial setup of the system. This change improves the maintainability of the code and makes it easier to understand and modify in the future. Adding Database Connection Test: A method test_db_connection was added to the DatabaseManager to test the database connection before attempting to interact with it. This method improves the robustness of the system by ensuring that a valid connection exists before proceeding. It also provides a better user experience by providing a clear error message if the connection fails. Refactoring SystemInformationGather: The SystemInformationGather class was refactored to improve its functionality and efficiency. The methods ask_for_uplink_speed and ask_for_downlink_speed were modified to convert the user's input to Mbps immediately, reducing the need for conversion later. This change improves the efficiency of the system by reducing unnecessary conversions. Adding Services Table: A new table for services was added to the database. This table stores the services that the system should be aware of, with each service represented as a boolean value. This change improves the flexibility of the system by allowing it to handle a variable number of services. It also improves the efficiency of the system by reducing the need to parse the services from a string each time they are needed. Storing Total Bandwidth: The total bandwidth (the sum of the uplink and downlink speeds) is now calculated and stored in the system_info table. This change improves the efficiency of the system by reducing the need to calculate the total bandwidth each time it is needed. Error Handling and Debugging: Throughout the process, various bugs and errors were encountered and fixed. These included issues with method arguments, missing method calls, and incorrect method usage. Fixing these issues improved the stability and reliability of the system. In conclusion, this commit significantly improves the functionality, efficiency, and maintainability of the system. The changes made adhere to good software engineering principles, such as the Single Responsibility Principle, and make the system more robust and user-friendly.
2023-06-05 14:21:29 -06:00
Curses.setpos(3, 0)
Detailed Refactoring of Database Interaction 1. **Refactoring of Database Interaction Methods** - Refactored the `store_services` method in the `DatabaseManager` class to handle an array of services instead of a hash. This change was made to simplify the interaction with the database and to avoid unnecessary complexity in the data structure. - The `store_services` method now iterates over an array of services and inserts each service into the database with a default status of true. This design choice was made to ensure that all services are active by default. 2. **Modification of Database Schema** - Modified the `create_services_table` method in the `DatabaseManager` class to create a table with only two columns: `id` and `services`. This change was made to align the database schema with the new data structure used in the `store_services` method. - The `status` column was removed from the `services` table because the status of all services is now assumed to be true by default. 3. **Error Handling and Debugging** - Encountered a `Sequel::DatabaseError` with the message "Operand should contain 1 column(s)" during the execution of the `store_services` method. This error was caused by an attempt to insert a hash into a single database column. - The error was resolved by refactoring the `store_services` method to handle an array of services instead of a hash. 4. **Unorthodox Design Choices** - The decision to use an array of services instead of a hash and to assume that the status of all services is true by default may seem unorthodox. However, these design choices were made to simplify the interaction with the database and to avoid unnecessary complexity in the data structure. - These design choices also helped to resolve the `Sequel::DatabaseError` that was encountered during the execution of the `store_services` method. This commit represents a significant refactoring of the database interaction methods in the NETRAVE project. The changes made in this commit have simplified the interaction with the database and have resolved a `Sequel::DatabaseError` that was encountered during the execution of the `store_services` method.
2023-06-09 19:39:54 -06:00
Curses.addstr('Please enter your database name: ')
Refactoring and Enhancing Database Management and System Information Gathering In this commit, we've made substantial changes to the DatabaseManager and SystemInformationGather classes to improve the functionality, efficiency, and maintainability of the system. Refactoring DatabaseManager: The DatabaseManager class was refactored to improve the separation of concerns. Initially, the DatabaseManager was responsible for creating an instance of SystemInformationGather, which was not ideal as it violated the Single Responsibility Principle. The responsibility of creating an instance of SystemInformationGather was moved to the FirstRunInit class, which is more appropriate as it is responsible for the initial setup of the system. This change improves the maintainability of the code and makes it easier to understand and modify in the future. Adding Database Connection Test: A method test_db_connection was added to the DatabaseManager to test the database connection before attempting to interact with it. This method improves the robustness of the system by ensuring that a valid connection exists before proceeding. It also provides a better user experience by providing a clear error message if the connection fails. Refactoring SystemInformationGather: The SystemInformationGather class was refactored to improve its functionality and efficiency. The methods ask_for_uplink_speed and ask_for_downlink_speed were modified to convert the user's input to Mbps immediately, reducing the need for conversion later. This change improves the efficiency of the system by reducing unnecessary conversions. Adding Services Table: A new table for services was added to the database. This table stores the services that the system should be aware of, with each service represented as a boolean value. This change improves the flexibility of the system by allowing it to handle a variable number of services. It also improves the efficiency of the system by reducing the need to parse the services from a string each time they are needed. Storing Total Bandwidth: The total bandwidth (the sum of the uplink and downlink speeds) is now calculated and stored in the system_info table. This change improves the efficiency of the system by reducing the need to calculate the total bandwidth each time it is needed. Error Handling and Debugging: Throughout the process, various bugs and errors were encountered and fixed. These included issues with method arguments, missing method calls, and incorrect method usage. Fixing these issues improved the stability and reliability of the system. In conclusion, this commit significantly improves the functionality, efficiency, and maintainability of the system. The changes made adhere to good software engineering principles, such as the Single Responsibility Principle, and make the system more robust and user-friendly.
2023-06-05 14:21:29 -06:00
Curses.refresh
Detailed Refactoring of Database Interaction 1. **Refactoring of Database Interaction Methods** - Refactored the `store_services` method in the `DatabaseManager` class to handle an array of services instead of a hash. This change was made to simplify the interaction with the database and to avoid unnecessary complexity in the data structure. - The `store_services` method now iterates over an array of services and inserts each service into the database with a default status of true. This design choice was made to ensure that all services are active by default. 2. **Modification of Database Schema** - Modified the `create_services_table` method in the `DatabaseManager` class to create a table with only two columns: `id` and `services`. This change was made to align the database schema with the new data structure used in the `store_services` method. - The `status` column was removed from the `services` table because the status of all services is now assumed to be true by default. 3. **Error Handling and Debugging** - Encountered a `Sequel::DatabaseError` with the message "Operand should contain 1 column(s)" during the execution of the `store_services` method. This error was caused by an attempt to insert a hash into a single database column. - The error was resolved by refactoring the `store_services` method to handle an array of services instead of a hash. 4. **Unorthodox Design Choices** - The decision to use an array of services instead of a hash and to assume that the status of all services is true by default may seem unorthodox. However, these design choices were made to simplify the interaction with the database and to avoid unnecessary complexity in the data structure. - These design choices also helped to resolve the `Sequel::DatabaseError` that was encountered during the execution of the `store_services` method. This commit represents a significant refactoring of the database interaction methods in the NETRAVE project. The changes made in this commit have simplified the interaction with the database and have resolved a `Sequel::DatabaseError` that was encountered during the execution of the `store_services` method.
2023-06-09 19:39:54 -06:00
database = DCI.catch_input(true)
@loggman.log_info('Database Name entered!')
Detailed Refactoring of Database Interaction 1. **Refactoring of Database Interaction Methods** - Refactored the `store_services` method in the `DatabaseManager` class to handle an array of services instead of a hash. This change was made to simplify the interaction with the database and to avoid unnecessary complexity in the data structure. - The `store_services` method now iterates over an array of services and inserts each service into the database with a default status of true. This design choice was made to ensure that all services are active by default. 2. **Modification of Database Schema** - Modified the `create_services_table` method in the `DatabaseManager` class to create a table with only two columns: `id` and `services`. This change was made to align the database schema with the new data structure used in the `store_services` method. - The `status` column was removed from the `services` table because the status of all services is now assumed to be true by default. 3. **Error Handling and Debugging** - Encountered a `Sequel::DatabaseError` with the message "Operand should contain 1 column(s)" during the execution of the `store_services` method. This error was caused by an attempt to insert a hash into a single database column. - The error was resolved by refactoring the `store_services` method to handle an array of services instead of a hash. 4. **Unorthodox Design Choices** - The decision to use an array of services instead of a hash and to assume that the status of all services is true by default may seem unorthodox. However, these design choices were made to simplify the interaction with the database and to avoid unnecessary complexity in the data structure. - These design choices also helped to resolve the `Sequel::DatabaseError` that was encountered during the execution of the `store_services` method. This commit represents a significant refactoring of the database interaction methods in the NETRAVE project. The changes made in this commit have simplified the interaction with the database and have resolved a `Sequel::DatabaseError` that was encountered during the execution of the `store_services` method.
2023-06-09 19:39:54 -06:00
# Generate a secret key
key = generate_key
@loggman.log_info('Secret Key Generated!')
Detailed Refactoring of Database Interaction 1. **Refactoring of Database Interaction Methods** - Refactored the `store_services` method in the `DatabaseManager` class to handle an array of services instead of a hash. This change was made to simplify the interaction with the database and to avoid unnecessary complexity in the data structure. - The `store_services` method now iterates over an array of services and inserts each service into the database with a default status of true. This design choice was made to ensure that all services are active by default. 2. **Modification of Database Schema** - Modified the `create_services_table` method in the `DatabaseManager` class to create a table with only two columns: `id` and `services`. This change was made to align the database schema with the new data structure used in the `store_services` method. - The `status` column was removed from the `services` table because the status of all services is now assumed to be true by default. 3. **Error Handling and Debugging** - Encountered a `Sequel::DatabaseError` with the message "Operand should contain 1 column(s)" during the execution of the `store_services` method. This error was caused by an attempt to insert a hash into a single database column. - The error was resolved by refactoring the `store_services` method to handle an array of services instead of a hash. 4. **Unorthodox Design Choices** - The decision to use an array of services instead of a hash and to assume that the status of all services is true by default may seem unorthodox. However, these design choices were made to simplify the interaction with the database and to avoid unnecessary complexity in the data structure. - These design choices also helped to resolve the `Sequel::DatabaseError` that was encountered during the execution of the `store_services` method. This commit represents a significant refactoring of the database interaction methods in the NETRAVE project. The changes made in this commit have simplified the interaction with the database and have resolved a `Sequel::DatabaseError` that was encountered during the execution of the `store_services` method.
2023-06-09 19:39:54 -06:00
# Encrypt the password
encrypted_password = encrypt_string_chacha20(password, key)
@loggman.log_info('Password Encrypted!')
Implement Encryption for Sensitive Data and Switch to .env for Configuration Storage This commit introduces several significant changes to improve the security and configuration management of the application. Encryption of Sensitive Data: We've introduced encryption for sensitive data such as database passwords. This is done using the Blowfish algorithm. The encryption and decryption methods are added to the Utilities module. The encryption is applied when the user enters their database password during the first run setup. The encrypted password is then stored in the .env file. When the application needs to use the password, it is decrypted using the key that was generated during encryption. Switch from YAML to .env for Configuration Storage: The application now uses a .env file for storing configuration data instead of a YAML file. This change was made to take advantage of the .env file's ability to store environment variables, which can be easily accessed by the application. The .env file stores the database username, encrypted password, encryption key, and database name. First Run Setup Changes: The FirstRunInit class has been updated to ask the user for their database details, encrypt the password, and store these details in the .env file. It also checks if any of the necessary details are missing and runs the first run setup if they are. Database Connection Testing: The DatabaseManager class now decrypts the password before using it to test the database connection. It also checks if the password or key are nil before attempting to decrypt the password. Logging: A new LoggMan class has been added to handle logging. This class provides a simple method for logging messages, which can be used throughout the application to log errors or other important information. Bug Fixes and Error Handling: Several bugs were fixed and error handling was improved. For example, a bug that caused the application to crash if the .env file was missing has been fixed. Also, the application now checks if the .env file exists and creates it if it doesn't. These changes significantly improve the security, reliability, and usability of the application.
2023-06-11 15:46:53 -06:00
db_details = { username:, password: encrypted_password, key:, database: }
write_db_details_to_config_file(db_details)
@loggman.log_info('Wiriting Database details to a file!')
Refactoring and Enhancing Database Management and System Information Gathering In this commit, we've made substantial changes to the DatabaseManager and SystemInformationGather classes to improve the functionality, efficiency, and maintainability of the system. Refactoring DatabaseManager: The DatabaseManager class was refactored to improve the separation of concerns. Initially, the DatabaseManager was responsible for creating an instance of SystemInformationGather, which was not ideal as it violated the Single Responsibility Principle. The responsibility of creating an instance of SystemInformationGather was moved to the FirstRunInit class, which is more appropriate as it is responsible for the initial setup of the system. This change improves the maintainability of the code and makes it easier to understand and modify in the future. Adding Database Connection Test: A method test_db_connection was added to the DatabaseManager to test the database connection before attempting to interact with it. This method improves the robustness of the system by ensuring that a valid connection exists before proceeding. It also provides a better user experience by providing a clear error message if the connection fails. Refactoring SystemInformationGather: The SystemInformationGather class was refactored to improve its functionality and efficiency. The methods ask_for_uplink_speed and ask_for_downlink_speed were modified to convert the user's input to Mbps immediately, reducing the need for conversion later. This change improves the efficiency of the system by reducing unnecessary conversions. Adding Services Table: A new table for services was added to the database. This table stores the services that the system should be aware of, with each service represented as a boolean value. This change improves the flexibility of the system by allowing it to handle a variable number of services. It also improves the efficiency of the system by reducing the need to parse the services from a string each time they are needed. Storing Total Bandwidth: The total bandwidth (the sum of the uplink and downlink speeds) is now calculated and stored in the system_info table. This change improves the efficiency of the system by reducing the need to calculate the total bandwidth each time it is needed. Error Handling and Debugging: Throughout the process, various bugs and errors were encountered and fixed. These included issues with method arguments, missing method calls, and incorrect method usage. Fixing these issues improved the stability and reliability of the system. In conclusion, this commit significantly improves the functionality, efficiency, and maintainability of the system. The changes made adhere to good software engineering principles, such as the Single Responsibility Principle, and make the system more robust and user-friendly.
2023-06-05 14:21:29 -06:00
end
Implementing Thread-Safe Alert System with Ring Buffer This commit introduces a significant enhancement to our Ruby program by implementing a thread-safe alert system using a ring buffer data structure. New Classes: 1. Alert: This class is responsible for creating and displaying alerts in the Curses Text User Interface (TUI). It takes a message and severity level as arguments and uses these to display color-coded alerts to the user. 2. AlertQueueManager: This class manages the queues for alerts using a ring buffer data structure. It continuously checks the queue and displays alerts as they arrive. It uses a mutex lock to ensure thread safety when accessing the ring buffer. 3. RingBuffer: This class is a custom implementation of a ring buffer, also known as a circular buffer. It's a fixed-size buffer that effectively overwrites old data when it is full. The buffer size has been optimized to 2MB to balance memory usage and performance. Modifications to Existing Methods: The DatabaseManager class has been updated to integrate the new alert system. The methods in this class now create Alert instances and enqueue them in the AlertQueueManager instead of directly displaying alerts to the user. This change ensures that alerts are displayed in a thread-safe manner and allows for better control over the timing and order of alert displays. Thread Safety Measures: Mutex locks and condition variables have been used to synchronize access to the ring buffer and prevent race conditions. This ensures that only one thread can access the buffer at a time, preventing data corruption and ensuring the correct operation of the alert system. Testing: Rigorous testing has been conducted to validate the correct functioning of the new system and to handle edge cases. This includes tests for the correct display of alerts, the correct operation of the ring buffer, and the correct synchronization of threads. Documentation: Detailed comments have been added to the code to explain the purpose and operation of the new classes and methods. This documentation will serve as a valuable reference for future development and maintenance of the codebase. This commit represents a significant improvement in the functionality and robustness of our Ruby program's alert system.
2023-07-05 12:35:20 -06:00
def write_db_details_to_config_file(db_details) # rubocop:disable Metrics/MethodLength
Detailed Refactoring of Database Interaction 1. **Refactoring of Database Interaction Methods** - Refactored the `store_services` method in the `DatabaseManager` class to handle an array of services instead of a hash. This change was made to simplify the interaction with the database and to avoid unnecessary complexity in the data structure. - The `store_services` method now iterates over an array of services and inserts each service into the database with a default status of true. This design choice was made to ensure that all services are active by default. 2. **Modification of Database Schema** - Modified the `create_services_table` method in the `DatabaseManager` class to create a table with only two columns: `id` and `services`. This change was made to align the database schema with the new data structure used in the `store_services` method. - The `status` column was removed from the `services` table because the status of all services is now assumed to be true by default. 3. **Error Handling and Debugging** - Encountered a `Sequel::DatabaseError` with the message "Operand should contain 1 column(s)" during the execution of the `store_services` method. This error was caused by an attempt to insert a hash into a single database column. - The error was resolved by refactoring the `store_services` method to handle an array of services instead of a hash. 4. **Unorthodox Design Choices** - The decision to use an array of services instead of a hash and to assume that the status of all services is true by default may seem unorthodox. However, these design choices were made to simplify the interaction with the database and to avoid unnecessary complexity in the data structure. - These design choices also helped to resolve the `Sequel::DatabaseError` that was encountered during the execution of the `store_services` method. This commit represents a significant refactoring of the database interaction methods in the NETRAVE project. The changes made in this commit have simplified the interaction with the database and have resolved a `Sequel::DatabaseError` that was encountered during the execution of the `store_services` method.
2023-06-09 19:39:54 -06:00
# Write the database details to the .env file
File.open('.env', 'w') do |file|
Implement Encryption for Sensitive Data and Switch to .env for Configuration Storage This commit introduces several significant changes to improve the security and configuration management of the application. Encryption of Sensitive Data: We've introduced encryption for sensitive data such as database passwords. This is done using the Blowfish algorithm. The encryption and decryption methods are added to the Utilities module. The encryption is applied when the user enters their database password during the first run setup. The encrypted password is then stored in the .env file. When the application needs to use the password, it is decrypted using the key that was generated during encryption. Switch from YAML to .env for Configuration Storage: The application now uses a .env file for storing configuration data instead of a YAML file. This change was made to take advantage of the .env file's ability to store environment variables, which can be easily accessed by the application. The .env file stores the database username, encrypted password, encryption key, and database name. First Run Setup Changes: The FirstRunInit class has been updated to ask the user for their database details, encrypt the password, and store these details in the .env file. It also checks if any of the necessary details are missing and runs the first run setup if they are. Database Connection Testing: The DatabaseManager class now decrypts the password before using it to test the database connection. It also checks if the password or key are nil before attempting to decrypt the password. Logging: A new LoggMan class has been added to handle logging. This class provides a simple method for logging messages, which can be used throughout the application to log errors or other important information. Bug Fixes and Error Handling: Several bugs were fixed and error handling was improved. For example, a bug that caused the application to crash if the .env file was missing has been fixed. Also, the application now checks if the .env file exists and creates it if it doesn't. These changes significantly improve the security, reliability, and usability of the application.
2023-06-11 15:46:53 -06:00
file.puts %(DB_USERNAME="#{db_details[:username]}")
file.puts %(DB_PASSWORD="#{db_details[:password]}")
file.puts %(DB_SECRET_KEY="#{db_details[:key]}")
file.puts %(DB_DATABASE="#{db_details[:database]}")
Refactoring and Enhancing Database Management and System Information Gathering In this commit, we've made substantial changes to the DatabaseManager and SystemInformationGather classes to improve the functionality, efficiency, and maintainability of the system. Refactoring DatabaseManager: The DatabaseManager class was refactored to improve the separation of concerns. Initially, the DatabaseManager was responsible for creating an instance of SystemInformationGather, which was not ideal as it violated the Single Responsibility Principle. The responsibility of creating an instance of SystemInformationGather was moved to the FirstRunInit class, which is more appropriate as it is responsible for the initial setup of the system. This change improves the maintainability of the code and makes it easier to understand and modify in the future. Adding Database Connection Test: A method test_db_connection was added to the DatabaseManager to test the database connection before attempting to interact with it. This method improves the robustness of the system by ensuring that a valid connection exists before proceeding. It also provides a better user experience by providing a clear error message if the connection fails. Refactoring SystemInformationGather: The SystemInformationGather class was refactored to improve its functionality and efficiency. The methods ask_for_uplink_speed and ask_for_downlink_speed were modified to convert the user's input to Mbps immediately, reducing the need for conversion later. This change improves the efficiency of the system by reducing unnecessary conversions. Adding Services Table: A new table for services was added to the database. This table stores the services that the system should be aware of, with each service represented as a boolean value. This change improves the flexibility of the system by allowing it to handle a variable number of services. It also improves the efficiency of the system by reducing the need to parse the services from a string each time they are needed. Storing Total Bandwidth: The total bandwidth (the sum of the uplink and downlink speeds) is now calculated and stored in the system_info table. This change improves the efficiency of the system by reducing the need to calculate the total bandwidth each time it is needed. Error Handling and Debugging: Throughout the process, various bugs and errors were encountered and fixed. These included issues with method arguments, missing method calls, and incorrect method usage. Fixing these issues improved the stability and reliability of the system. In conclusion, this commit significantly improves the functionality, efficiency, and maintainability of the system. The changes made adhere to good software engineering principles, such as the Single Responsibility Principle, and make the system more robust and user-friendly.
2023-06-05 14:21:29 -06:00
end
Implement Encryption for Sensitive Data and Switch to .env for Configuration Storage This commit introduces several significant changes to improve the security and configuration management of the application. Encryption of Sensitive Data: We've introduced encryption for sensitive data such as database passwords. This is done using the Blowfish algorithm. The encryption and decryption methods are added to the Utilities module. The encryption is applied when the user enters their database password during the first run setup. The encrypted password is then stored in the .env file. When the application needs to use the password, it is decrypted using the key that was generated during encryption. Switch from YAML to .env for Configuration Storage: The application now uses a .env file for storing configuration data instead of a YAML file. This change was made to take advantage of the .env file's ability to store environment variables, which can be easily accessed by the application. The .env file stores the database username, encrypted password, encryption key, and database name. First Run Setup Changes: The FirstRunInit class has been updated to ask the user for their database details, encrypt the password, and store these details in the .env file. It also checks if any of the necessary details are missing and runs the first run setup if they are. Database Connection Testing: The DatabaseManager class now decrypts the password before using it to test the database connection. It also checks if the password or key are nil before attempting to decrypt the password. Logging: A new LoggMan class has been added to handle logging. This class provides a simple method for logging messages, which can be used throughout the application to log errors or other important information. Bug Fixes and Error Handling: Several bugs were fixed and error handling was improved. For example, a bug that caused the application to crash if the .env file was missing has been fixed. Also, the application now checks if the .env file exists and creates it if it doesn't. These changes significantly improve the security, reliability, and usability of the application.
2023-06-11 15:46:53 -06:00
@loggman.log_info('Database details saved! Reloading environment...')
Implement Encryption for Sensitive Data and Switch to .env for Configuration Storage This commit introduces several significant changes to improve the security and configuration management of the application. Encryption of Sensitive Data: We've introduced encryption for sensitive data such as database passwords. This is done using the Blowfish algorithm. The encryption and decryption methods are added to the Utilities module. The encryption is applied when the user enters their database password during the first run setup. The encrypted password is then stored in the .env file. When the application needs to use the password, it is decrypted using the key that was generated during encryption. Switch from YAML to .env for Configuration Storage: The application now uses a .env file for storing configuration data instead of a YAML file. This change was made to take advantage of the .env file's ability to store environment variables, which can be easily accessed by the application. The .env file stores the database username, encrypted password, encryption key, and database name. First Run Setup Changes: The FirstRunInit class has been updated to ask the user for their database details, encrypt the password, and store these details in the .env file. It also checks if any of the necessary details are missing and runs the first run setup if they are. Database Connection Testing: The DatabaseManager class now decrypts the password before using it to test the database connection. It also checks if the password or key are nil before attempting to decrypt the password. Logging: A new LoggMan class has been added to handle logging. This class provides a simple method for logging messages, which can be used throughout the application to log errors or other important information. Bug Fixes and Error Handling: Several bugs were fixed and error handling was improved. For example, a bug that caused the application to crash if the .env file was missing has been fixed. Also, the application now checks if the .env file exists and creates it if it doesn't. These changes significantly improve the security, reliability, and usability of the application.
2023-06-11 15:46:53 -06:00
# Load the .env file using dotenv
Dotenv.load
@loggman.log_info('Environment restarted!')
Implement Encryption for Sensitive Data and Switch to .env for Configuration Storage This commit introduces several significant changes to improve the security and configuration management of the application. Encryption of Sensitive Data: We've introduced encryption for sensitive data such as database passwords. This is done using the Blowfish algorithm. The encryption and decryption methods are added to the Utilities module. The encryption is applied when the user enters their database password during the first run setup. The encrypted password is then stored in the .env file. When the application needs to use the password, it is decrypted using the key that was generated during encryption. Switch from YAML to .env for Configuration Storage: The application now uses a .env file for storing configuration data instead of a YAML file. This change was made to take advantage of the .env file's ability to store environment variables, which can be easily accessed by the application. The .env file stores the database username, encrypted password, encryption key, and database name. First Run Setup Changes: The FirstRunInit class has been updated to ask the user for their database details, encrypt the password, and store these details in the .env file. It also checks if any of the necessary details are missing and runs the first run setup if they are. Database Connection Testing: The DatabaseManager class now decrypts the password before using it to test the database connection. It also checks if the password or key are nil before attempting to decrypt the password. Logging: A new LoggMan class has been added to handle logging. This class provides a simple method for logging messages, which can be used throughout the application to log errors or other important information. Bug Fixes and Error Handling: Several bugs were fixed and error handling was improved. For example, a bug that caused the application to crash if the .env file was missing has been fixed. Also, the application now checks if the .env file exists and creates it if it doesn't. These changes significantly improve the security, reliability, and usability of the application.
2023-06-11 15:46:53 -06:00
rescue StandardError => e
@loggman.log_error("Failed to write to .env file: #{e.message}")
Refactoring and Enhancing Database Management and System Information Gathering In this commit, we've made substantial changes to the DatabaseManager and SystemInformationGather classes to improve the functionality, efficiency, and maintainability of the system. Refactoring DatabaseManager: The DatabaseManager class was refactored to improve the separation of concerns. Initially, the DatabaseManager was responsible for creating an instance of SystemInformationGather, which was not ideal as it violated the Single Responsibility Principle. The responsibility of creating an instance of SystemInformationGather was moved to the FirstRunInit class, which is more appropriate as it is responsible for the initial setup of the system. This change improves the maintainability of the code and makes it easier to understand and modify in the future. Adding Database Connection Test: A method test_db_connection was added to the DatabaseManager to test the database connection before attempting to interact with it. This method improves the robustness of the system by ensuring that a valid connection exists before proceeding. It also provides a better user experience by providing a clear error message if the connection fails. Refactoring SystemInformationGather: The SystemInformationGather class was refactored to improve its functionality and efficiency. The methods ask_for_uplink_speed and ask_for_downlink_speed were modified to convert the user's input to Mbps immediately, reducing the need for conversion later. This change improves the efficiency of the system by reducing unnecessary conversions. Adding Services Table: A new table for services was added to the database. This table stores the services that the system should be aware of, with each service represented as a boolean value. This change improves the flexibility of the system by allowing it to handle a variable number of services. It also improves the efficiency of the system by reducing the need to parse the services from a string each time they are needed. Storing Total Bandwidth: The total bandwidth (the sum of the uplink and downlink speeds) is now calculated and stored in the system_info table. This change improves the efficiency of the system by reducing the need to calculate the total bandwidth each time it is needed. Error Handling and Debugging: Throughout the process, various bugs and errors were encountered and fixed. These included issues with method arguments, missing method calls, and incorrect method usage. Fixing these issues improved the stability and reliability of the system. In conclusion, this commit significantly improves the functionality, efficiency, and maintainability of the system. The changes made adhere to good software engineering principles, such as the Single Responsibility Principle, and make the system more robust and user-friendly.
2023-06-05 14:21:29 -06:00
end
Refactoring for Modularity, Code Reuse, and Security Considerations In this commit, we have undertaken a significant refactoring of the codebase to improve modularity, promote code reuse, and consider security aspects. Modularity and Code Reuse: We introduced classes and modules to better organize the code and facilitate code reuse. Specifically, we created a new Utilities module to hold common methods that are used across different parts of the application. This module includes methods such as convert_speed_to_mbps, services_to_hash, and calculate_total_bandwidth. By placing these methods in a module, we can include this module in any class that needs these methods, thereby promoting code reuse and reducing duplication. We also created two new classes, SystemInformationGather and DatabaseManager. The SystemInformationGather class is responsible for gathering system information, such as uplink and downlink speed, and services. The DatabaseManager class handles database operations, including testing the database connection, creating the system information table, and storing system information in the database. By encapsulating these responsibilities within their respective classes, we have made the code more organized and easier to maintain. Database Connection Details: We made a decision to store the database connection details in a config file (config.yml) instead of the database itself. This decision was made for security reasons, as storing these details in the database could expose them to potential security risks. Storing these details in a config file allows us to better control access to these details. Database Encryption: We discussed the possibility of encrypting the database for additional security. While we have not implemented this feature in this commit, we have laid the groundwork for it by discussing potential libraries/gems that could be used for this purpose. This is an area that we will revisit in the future. System Information Gathering: We wrote methods to gather system information, such as uplink and downlink speed, and services, and store this information in the database. This information will be useful for monitoring system performance and for making decisions about resource allocation. This refactoring effort has made the codebase more organized, easier to maintain, and more secure. It also aligns with our project goals and roadmap. However, it's important to note that with any refactoring effort, there may be potential issues or trade-offs. We will need to thoroughly test the refactored code to ensure that it works as expected and that there are no unintended side effects.
2023-06-04 14:41:12 -06:00
def ask_for_default_mode
Detailed Refactoring of Database Interaction 1. **Refactoring of Database Interaction Methods** - Refactored the `store_services` method in the `DatabaseManager` class to handle an array of services instead of a hash. This change was made to simplify the interaction with the database and to avoid unnecessary complexity in the data structure. - The `store_services` method now iterates over an array of services and inserts each service into the database with a default status of true. This design choice was made to ensure that all services are active by default. 2. **Modification of Database Schema** - Modified the `create_services_table` method in the `DatabaseManager` class to create a table with only two columns: `id` and `services`. This change was made to align the database schema with the new data structure used in the `store_services` method. - The `status` column was removed from the `services` table because the status of all services is now assumed to be true by default. 3. **Error Handling and Debugging** - Encountered a `Sequel::DatabaseError` with the message "Operand should contain 1 column(s)" during the execution of the `store_services` method. This error was caused by an attempt to insert a hash into a single database column. - The error was resolved by refactoring the `store_services` method to handle an array of services instead of a hash. 4. **Unorthodox Design Choices** - The decision to use an array of services instead of a hash and to assume that the status of all services is true by default may seem unorthodox. However, these design choices were made to simplify the interaction with the database and to avoid unnecessary complexity in the data structure. - These design choices also helped to resolve the `Sequel::DatabaseError` that was encountered during the execution of the `store_services` method. This commit represents a significant refactoring of the database interaction methods in the NETRAVE project. The changes made in this commit have simplified the interaction with the database and have resolved a `Sequel::DatabaseError` that was encountered during the execution of the `store_services` method.
2023-06-09 19:39:54 -06:00
loop do
Refactoring for Modularity, Code Reuse, and Security Considerations In this commit, we have undertaken a significant refactoring of the codebase to improve modularity, promote code reuse, and consider security aspects. Modularity and Code Reuse: We introduced classes and modules to better organize the code and facilitate code reuse. Specifically, we created a new Utilities module to hold common methods that are used across different parts of the application. This module includes methods such as convert_speed_to_mbps, services_to_hash, and calculate_total_bandwidth. By placing these methods in a module, we can include this module in any class that needs these methods, thereby promoting code reuse and reducing duplication. We also created two new classes, SystemInformationGather and DatabaseManager. The SystemInformationGather class is responsible for gathering system information, such as uplink and downlink speed, and services. The DatabaseManager class handles database operations, including testing the database connection, creating the system information table, and storing system information in the database. By encapsulating these responsibilities within their respective classes, we have made the code more organized and easier to maintain. Database Connection Details: We made a decision to store the database connection details in a config file (config.yml) instead of the database itself. This decision was made for security reasons, as storing these details in the database could expose them to potential security risks. Storing these details in a config file allows us to better control access to these details. Database Encryption: We discussed the possibility of encrypting the database for additional security. While we have not implemented this feature in this commit, we have laid the groundwork for it by discussing potential libraries/gems that could be used for this purpose. This is an area that we will revisit in the future. System Information Gathering: We wrote methods to gather system information, such as uplink and downlink speed, and services, and store this information in the database. This information will be useful for monitoring system performance and for making decisions about resource allocation. This refactoring effort has made the codebase more organized, easier to maintain, and more secure. It also aligns with our project goals and roadmap. However, it's important to note that with any refactoring effort, there may be potential issues or trade-offs. We will need to thoroughly test the refactored code to ensure that it works as expected and that there are no unintended side effects.
2023-06-04 14:41:12 -06:00
Curses.setpos(8, 0)
Detailed Refactoring of Database Interaction 1. **Refactoring of Database Interaction Methods** - Refactored the `store_services` method in the `DatabaseManager` class to handle an array of services instead of a hash. This change was made to simplify the interaction with the database and to avoid unnecessary complexity in the data structure. - The `store_services` method now iterates over an array of services and inserts each service into the database with a default status of true. This design choice was made to ensure that all services are active by default. 2. **Modification of Database Schema** - Modified the `create_services_table` method in the `DatabaseManager` class to create a table with only two columns: `id` and `services`. This change was made to align the database schema with the new data structure used in the `store_services` method. - The `status` column was removed from the `services` table because the status of all services is now assumed to be true by default. 3. **Error Handling and Debugging** - Encountered a `Sequel::DatabaseError` with the message "Operand should contain 1 column(s)" during the execution of the `store_services` method. This error was caused by an attempt to insert a hash into a single database column. - The error was resolved by refactoring the `store_services` method to handle an array of services instead of a hash. 4. **Unorthodox Design Choices** - The decision to use an array of services instead of a hash and to assume that the status of all services is true by default may seem unorthodox. However, these design choices were made to simplify the interaction with the database and to avoid unnecessary complexity in the data structure. - These design choices also helped to resolve the `Sequel::DatabaseError` that was encountered during the execution of the `store_services` method. This commit represents a significant refactoring of the database interaction methods in the NETRAVE project. The changes made in this commit have simplified the interaction with the database and have resolved a `Sequel::DatabaseError` that was encountered during the execution of the `store_services` method.
2023-06-09 19:39:54 -06:00
Curses.addstr('Please enter the default mode (TUI, GUI, or WebApp): ')
Curses.refresh
Refactoring for Modularity, Code Reuse, and Security Considerations In this commit, we have undertaken a significant refactoring of the codebase to improve modularity, promote code reuse, and consider security aspects. Modularity and Code Reuse: We introduced classes and modules to better organize the code and facilitate code reuse. Specifically, we created a new Utilities module to hold common methods that are used across different parts of the application. This module includes methods such as convert_speed_to_mbps, services_to_hash, and calculate_total_bandwidth. By placing these methods in a module, we can include this module in any class that needs these methods, thereby promoting code reuse and reducing duplication. We also created two new classes, SystemInformationGather and DatabaseManager. The SystemInformationGather class is responsible for gathering system information, such as uplink and downlink speed, and services. The DatabaseManager class handles database operations, including testing the database connection, creating the system information table, and storing system information in the database. By encapsulating these responsibilities within their respective classes, we have made the code more organized and easier to maintain. Database Connection Details: We made a decision to store the database connection details in a config file (config.yml) instead of the database itself. This decision was made for security reasons, as storing these details in the database could expose them to potential security risks. Storing these details in a config file allows us to better control access to these details. Database Encryption: We discussed the possibility of encrypting the database for additional security. While we have not implemented this feature in this commit, we have laid the groundwork for it by discussing potential libraries/gems that could be used for this purpose. This is an area that we will revisit in the future. System Information Gathering: We wrote methods to gather system information, such as uplink and downlink speed, and services, and store this information in the database. This information will be useful for monitoring system performance and for making decisions about resource allocation. This refactoring effort has made the codebase more organized, easier to maintain, and more secure. It also aligns with our project goals and roadmap. However, it's important to note that with any refactoring effort, there may be potential issues or trade-offs. We will need to thoroughly test the refactored code to ensure that it works as expected and that there are no unintended side effects.
2023-06-04 14:41:12 -06:00
mode = Curses.getstr.strip.downcase
Detailed Refactoring of Database Interaction 1. **Refactoring of Database Interaction Methods** - Refactored the `store_services` method in the `DatabaseManager` class to handle an array of services instead of a hash. This change was made to simplify the interaction with the database and to avoid unnecessary complexity in the data structure. - The `store_services` method now iterates over an array of services and inserts each service into the database with a default status of true. This design choice was made to ensure that all services are active by default. 2. **Modification of Database Schema** - Modified the `create_services_table` method in the `DatabaseManager` class to create a table with only two columns: `id` and `services`. This change was made to align the database schema with the new data structure used in the `store_services` method. - The `status` column was removed from the `services` table because the status of all services is now assumed to be true by default. 3. **Error Handling and Debugging** - Encountered a `Sequel::DatabaseError` with the message "Operand should contain 1 column(s)" during the execution of the `store_services` method. This error was caused by an attempt to insert a hash into a single database column. - The error was resolved by refactoring the `store_services` method to handle an array of services instead of a hash. 4. **Unorthodox Design Choices** - The decision to use an array of services instead of a hash and to assume that the status of all services is true by default may seem unorthodox. However, these design choices were made to simplify the interaction with the database and to avoid unnecessary complexity in the data structure. - These design choices also helped to resolve the `Sequel::DatabaseError` that was encountered during the execution of the `store_services` method. This commit represents a significant refactoring of the database interaction methods in the NETRAVE project. The changes made in this commit have simplified the interaction with the database and have resolved a `Sequel::DatabaseError` that was encountered during the execution of the `store_services` method.
2023-06-09 19:39:54 -06:00
return mode if valid_mode?(mode)
Curses.setpos(9, 0)
Curses.addstr("Whoops! That didn't appear to be a valid mode. Please try again!")
Curses.refresh
end
end
Refactoring for Modularity, Code Reuse, and Security Considerations In this commit, we have undertaken a significant refactoring of the codebase to improve modularity, promote code reuse, and consider security aspects. Modularity and Code Reuse: We introduced classes and modules to better organize the code and facilitate code reuse. Specifically, we created a new Utilities module to hold common methods that are used across different parts of the application. This module includes methods such as convert_speed_to_mbps, services_to_hash, and calculate_total_bandwidth. By placing these methods in a module, we can include this module in any class that needs these methods, thereby promoting code reuse and reducing duplication. We also created two new classes, SystemInformationGather and DatabaseManager. The SystemInformationGather class is responsible for gathering system information, such as uplink and downlink speed, and services. The DatabaseManager class handles database operations, including testing the database connection, creating the system information table, and storing system information in the database. By encapsulating these responsibilities within their respective classes, we have made the code more organized and easier to maintain. Database Connection Details: We made a decision to store the database connection details in a config file (config.yml) instead of the database itself. This decision was made for security reasons, as storing these details in the database could expose them to potential security risks. Storing these details in a config file allows us to better control access to these details. Database Encryption: We discussed the possibility of encrypting the database for additional security. While we have not implemented this feature in this commit, we have laid the groundwork for it by discussing potential libraries/gems that could be used for this purpose. This is an area that we will revisit in the future. System Information Gathering: We wrote methods to gather system information, such as uplink and downlink speed, and services, and store this information in the database. This information will be useful for monitoring system performance and for making decisions about resource allocation. This refactoring effort has made the codebase more organized, easier to maintain, and more secure. It also aligns with our project goals and roadmap. However, it's important to note that with any refactoring effort, there may be potential issues or trade-offs. We will need to thoroughly test the refactored code to ensure that it works as expected and that there are no unintended side effects.
2023-06-04 14:41:12 -06:00
def valid_mode?(mode)
Detailed Refactoring of Database Interaction 1. **Refactoring of Database Interaction Methods** - Refactored the `store_services` method in the `DatabaseManager` class to handle an array of services instead of a hash. This change was made to simplify the interaction with the database and to avoid unnecessary complexity in the data structure. - The `store_services` method now iterates over an array of services and inserts each service into the database with a default status of true. This design choice was made to ensure that all services are active by default. 2. **Modification of Database Schema** - Modified the `create_services_table` method in the `DatabaseManager` class to create a table with only two columns: `id` and `services`. This change was made to align the database schema with the new data structure used in the `store_services` method. - The `status` column was removed from the `services` table because the status of all services is now assumed to be true by default. 3. **Error Handling and Debugging** - Encountered a `Sequel::DatabaseError` with the message "Operand should contain 1 column(s)" during the execution of the `store_services` method. This error was caused by an attempt to insert a hash into a single database column. - The error was resolved by refactoring the `store_services` method to handle an array of services instead of a hash. 4. **Unorthodox Design Choices** - The decision to use an array of services instead of a hash and to assume that the status of all services is true by default may seem unorthodox. However, these design choices were made to simplify the interaction with the database and to avoid unnecessary complexity in the data structure. - These design choices also helped to resolve the `Sequel::DatabaseError` that was encountered during the execution of the `store_services` method. This commit represents a significant refactoring of the database interaction methods in the NETRAVE project. The changes made in this commit have simplified the interaction with the database and have resolved a `Sequel::DatabaseError` that was encountered during the execution of the `store_services` method.
2023-06-09 19:39:54 -06:00
%w[tui gui webapp].include?(mode)
Refactoring for Modularity, Code Reuse, and Security Considerations In this commit, we have undertaken a significant refactoring of the codebase to improve modularity, promote code reuse, and consider security aspects. Modularity and Code Reuse: We introduced classes and modules to better organize the code and facilitate code reuse. Specifically, we created a new Utilities module to hold common methods that are used across different parts of the application. This module includes methods such as convert_speed_to_mbps, services_to_hash, and calculate_total_bandwidth. By placing these methods in a module, we can include this module in any class that needs these methods, thereby promoting code reuse and reducing duplication. We also created two new classes, SystemInformationGather and DatabaseManager. The SystemInformationGather class is responsible for gathering system information, such as uplink and downlink speed, and services. The DatabaseManager class handles database operations, including testing the database connection, creating the system information table, and storing system information in the database. By encapsulating these responsibilities within their respective classes, we have made the code more organized and easier to maintain. Database Connection Details: We made a decision to store the database connection details in a config file (config.yml) instead of the database itself. This decision was made for security reasons, as storing these details in the database could expose them to potential security risks. Storing these details in a config file allows us to better control access to these details. Database Encryption: We discussed the possibility of encrypting the database for additional security. While we have not implemented this feature in this commit, we have laid the groundwork for it by discussing potential libraries/gems that could be used for this purpose. This is an area that we will revisit in the future. System Information Gathering: We wrote methods to gather system information, such as uplink and downlink speed, and services, and store this information in the database. This information will be useful for monitoring system performance and for making decisions about resource allocation. This refactoring effort has made the codebase more organized, easier to maintain, and more secure. It also aligns with our project goals and roadmap. However, it's important to note that with any refactoring effort, there may be potential issues or trade-offs. We will need to thoroughly test the refactored code to ensure that it works as expected and that there are no unintended side effects.
2023-06-04 14:41:12 -06:00
end
end