From ff36da7ac8c6824b3953fba5e899c1cb7be8bb48 Mon Sep 17 00:00:00 2001 From: Thomas Vincent Date: Wed, 11 Mar 2026 13:39:14 -0700 Subject: [PATCH] fix: resolve content issues in spine.c, configure.ac, spine.conf.dist, and Copilot instructions (#437) Fixes #438 Four targeted content fixes: 1. **spine.c**: replace `[WHERE?]` placeholder in doxygen comment and expand `--help` output to list the actual spine.conf search order: current directory, /etc/, /etc/cacti/, ../etc/. 2. **configure.ac**: raise AC_PREREQ from 2.63 to 2.69; remove obsolete macros no longer needed in C99 builds (AC_C_CONST, AC_HEADER_TIME, AC_STRUCT_TM, RETSIGTYPE block). 3. **spine.conf.dist**: document SNMP_Clientaddr, DB_SSL_Verify, and RDB_SSL_Verify in the header comment block and add them as commented example lines in the settings section. 4. **.github/instructions/instructions.md**: replace generic blueprint template with spine-specific Copilot instructions (C99/POSIX, pthreads, net-snmp, libmariadb, autotools, CI, commit conventions). No behaviour changes. man page content improves automatically via help2man. Signed-off-by: Thomas Vincent Co-authored-by: netniV --- .github/instructions/instructions.md | 334 +++++---------------------- CHANGELOG | 1 + configure.ac | 20 +- spine.c | 7 +- spine.conf.dist | 1 + 5 files changed, 66 insertions(+), 297 deletions(-) diff --git a/.github/instructions/instructions.md b/.github/instructions/instructions.md index 7dd6bd4..51923bd 100644 --- a/.github/instructions/instructions.md +++ b/.github/instructions/instructions.md @@ -1,294 +1,74 @@ ---- -description: 'Technology-agnostic blueprint generator for creating comprehensive copilot-instructions.md files that guide GitHub Copilot to produce code consistent with project standards, architecture patterns, and exact technology versions by analyzing existing codebase patterns and avoiding assumptions.' -agent: 'agent' ---- +# GitHub Copilot Instructions for spine -# Copilot Instructions Blueprint Generator +spine is the high-performance C poller for Cacti. It is a multi-threaded +POSIX C99 program using pthreads, net-snmp, and libmariadb, built with +GNU autotools. -## Configuration Variables -${PROJECT_TYPE="Auto-detect|.NET|Java|JavaScript|TypeScript|React|Angular|Python|Multiple|Other"} -${ARCHITECTURE_STYLE="Layered|Microservices|Monolithic|Domain-Driven|Event-Driven|Serverless|Mixed"} -${CODE_QUALITY_FOCUS="Maintainability|Performance|Security|Accessibility|Testability|All"} -${DOCUMENTATION_LEVEL="Minimal|Standard|Comprehensive"} -${TESTING_REQUIREMENTS="Unit|Integration|E2E|TDD|BDD|All"} -${VERSIONING="Semantic|CalVer|Custom"} +## Language and standard -## Generated Prompt +- C99. Mixed declarations and statements are allowed. No VLAs. +- POSIX.1-2008 is the baseline. Do not use glibc extensions unless they + already appear in the codebase. +- All new files must include the LGPL-2.1 header block found in `spine.c`. -"Generate a comprehensive copilot-instructions.md file that will guide GitHub Copilot to produce code consistent with our project's standards, architecture, and technology versions. The instructions must be strictly based on actual code patterns in our codebase and avoid making any assumptions. Follow this approach: +## Build system -### 1. Core Instruction Structure +- `configure.ac` + `Makefile.am`. Run `./bootstrap` to regenerate. +- AC_PREREQ is 2.69. Do not add macros deprecated before autoconf 2.69 + (AC_C_CONST, AC_STRUCT_TM, RETSIGTYPE, etc.). AC_HEADER_TIME is used + and must be kept because common.h guards with TIME_WITH_SYS_TIME. +- `make -j$(nproc) CFLAGS="-Wall -Wextra"` must produce zero warnings. -```markdown -# GitHub Copilot Instructions +## Code conventions -## Priority Guidelines +- Indentation: tabs (match existing files exactly). +- Function names: `snake_case`. Type names: `snake_case_t` for typedefs. +- Error paths: print to `SPINE_LOG` or `cacti_log`, then `return` or + `exit`. Never silently swallow errors. +- Locking: acquire mutexes in a consistent order to avoid deadlock. + Document the lock order in comments where it is not obvious. +- Memory: every `malloc` / `calloc` return must be checked immediately. + Use `snprintf`, never `sprintf`. Use `strncat`/`strncpy` with explicit + bounds. +- String buffers: declare length constants; do not use magic numbers for + buffer sizes. -When generating code for this repository: +## SNMP -1. **Version Compatibility**: Always detect and respect the exact versions of languages, frameworks, and libraries used in this project -2. **Context Files**: Prioritize patterns and standards defined in the .github/copilot directory -3. **Codebase Patterns**: When context files don't provide specific guidance, scan the codebase for established patterns -4. **Architectural Consistency**: Maintain our ${ARCHITECTURE_STYLE} architectural style and established boundaries -5. **Code Quality**: Prioritize ${CODE_QUALITY_FOCUS == "All" ? "maintainability, performance, security, accessibility, and testability" : CODE_QUALITY_FOCUS} in all generated code +- Use net-snmp session API. Initialize with `snmp_sess_init` and always + call `snmp_sess_close` on the session pointer. +- `SNMP_Clientaddr` binds the outgoing interface; respect it when + opening sessions. +- OID arrays: always check `snmp_parse_oid` return value. -## Technology Version Detection +## Database -Before generating code, scan the codebase to identify: +- All SQL must use parameterized queries via the db_* wrappers in + `sql.c`. No raw `mysql_query` calls in poller code. +- Connection flags: respect `DB_UseSSL` and the SSL key/cert/CA + settings parsed from `spine.conf`. -1. **Language Versions**: Detect the exact versions of programming languages in use - - Examine project files, configuration files, and package managers - - Look for language-specific version indicators (e.g., in .NET projects) - - Never use language features beyond the detected version +## Configuration file -2. **Framework Versions**: Identify the exact versions of all frameworks - - Check package.json, .csproj, pom.xml, requirements.txt, etc. - - Respect version constraints when generating code - - Never suggest features not available in the detected framework versions +- `spine.conf.dist` is the authoritative reference. When adding a new + setting, add it to the header comment block AND as a commented example + line in the settings section. +- Parse new keys in `util.c:read_spine_config()`. Add the field to + `config_struct` in `spine.h`. -3. **Library Versions**: Note the exact versions of key libraries and dependencies - - Generate code compatible with these specific versions - - Never use APIs or features not available in the detected versions +## Testing and CI -## Context Files +- When configuring CI, it SHOULD run at least: build (gcc+clang), cppcheck, flawfinder, and CodeQL. +- Before opening a PR, run `cppcheck --enable=all --std=c11 *.c *.h` + locally and fix all errors (warnings are informational). +- flawfinder level-5 hits fail CI; lower levels are informational. -Prioritize the following files in .github/copilot directory (if they exist): +## Commits and PRs -- **architecture.md**: System architecture guidelines -- **tech-stack.md**: Technology versions and framework details -- **coding-standards.md**: Code style and formatting standards -- **folder-structure.md**: Project organization guidelines -- **exemplars.md**: Exemplary code patterns to follow - -## Codebase Scanning Instructions - -When context files don't provide specific guidance: - -1. Identify similar files to the one being modified or created -2. Analyze patterns for: - - Naming conventions - - Code organization - - Error handling - - Logging approaches - - Documentation style - - Testing patterns - -3. Follow the most consistent patterns found in the codebase -4. When conflicting patterns exist, prioritize patterns in newer files or files with higher test coverage -5. Never introduce patterns not found in the existing codebase - -## Code Quality Standards - -${CODE_QUALITY_FOCUS.includes("Maintainability") || CODE_QUALITY_FOCUS == "All" ? `### Maintainability -- Write self-documenting code with clear naming -- Follow the naming and organization conventions evident in the codebase -- Follow established patterns for consistency -- Keep functions focused on single responsibilities -- Limit function complexity and length to match existing patterns` : ""} - -${CODE_QUALITY_FOCUS.includes("Performance") || CODE_QUALITY_FOCUS == "All" ? `### Performance -- Follow existing patterns for memory and resource management -- Match existing patterns for handling computationally expensive operations -- Follow established patterns for asynchronous operations -- Apply caching consistently with existing patterns -- Optimize according to patterns evident in the codebase` : ""} - -${CODE_QUALITY_FOCUS.includes("Security") || CODE_QUALITY_FOCUS == "All" ? `### Security -- Follow existing patterns for input validation -- Apply the same sanitization techniques used in the codebase -- Use parameterized queries matching existing patterns -- Follow established authentication and authorization patterns -- Handle sensitive data according to existing patterns` : ""} - -${CODE_QUALITY_FOCUS.includes("Accessibility") || CODE_QUALITY_FOCUS == "All" ? `### Accessibility -- Follow existing accessibility patterns in the codebase -- Match ARIA attribute usage with existing components -- Maintain keyboard navigation support consistent with existing code -- Follow established patterns for color and contrast -- Apply text alternative patterns consistent with the codebase` : ""} - -${CODE_QUALITY_FOCUS.includes("Testability") || CODE_QUALITY_FOCUS == "All" ? `### Testability -- Follow established patterns for testable code -- Match dependency injection approaches used in the codebase -- Apply the same patterns for managing dependencies -- Follow established mocking and test double patterns -- Match the testing style used in existing tests` : ""} - -## Documentation Requirements - -${DOCUMENTATION_LEVEL == "Minimal" ? -`- Match the level and style of comments found in existing code -- Document according to patterns observed in the codebase -- Follow existing patterns for documenting non-obvious behavior -- Use the same format for parameter descriptions as existing code` : ""} - -${DOCUMENTATION_LEVEL == "Standard" ? -`- Follow the exact documentation format found in the codebase -- Match the XML/JSDoc style and completeness of existing comments -- Document parameters, returns, and exceptions in the same style -- Follow existing patterns for usage examples -- Match class-level documentation style and content` : ""} - -${DOCUMENTATION_LEVEL == "Comprehensive" ? -`- Follow the most detailed documentation patterns found in the codebase -- Match the style and completeness of the best-documented code -- Document exactly as the most thoroughly documented files do -- Follow existing patterns for linking documentation -- Match the level of detail in explanations of design decisions` : ""} - -## Testing Approach - -${TESTING_REQUIREMENTS.includes("Unit") || TESTING_REQUIREMENTS == "All" ? -`### Unit Testing -- Match the exact structure and style of existing unit tests -- Follow the same naming conventions for test classes and methods -- Use the same assertion patterns found in existing tests -- Apply the same mocking approach used in the codebase -- Follow existing patterns for test isolation` : ""} - -${TESTING_REQUIREMENTS.includes("Integration") || TESTING_REQUIREMENTS == "All" ? -`### Integration Testing -- Follow the same integration test patterns found in the codebase -- Match existing patterns for test data setup and teardown -- Use the same approach for testing component interactions -- Follow existing patterns for verifying system behavior` : ""} - -${TESTING_REQUIREMENTS.includes("E2E") || TESTING_REQUIREMENTS == "All" ? -`### End-to-End Testing -- Match the existing E2E test structure and patterns -- Follow established patterns for UI testing -- Apply the same approach for verifying user journeys` : ""} - -${TESTING_REQUIREMENTS.includes("TDD") || TESTING_REQUIREMENTS == "All" ? -`### Test-Driven Development -- Follow TDD patterns evident in the codebase -- Match the progression of test cases seen in existing code -- Apply the same refactoring patterns after tests pass` : ""} - -${TESTING_REQUIREMENTS.includes("BDD") || TESTING_REQUIREMENTS == "All" ? -`### Behavior-Driven Development -- Match the existing Given-When-Then structure in tests -- Follow the same patterns for behavior descriptions -- Apply the same level of business focus in test cases` : ""} - -## Technology-Specific Guidelines - -${PROJECT_TYPE == ".NET" || PROJECT_TYPE == "Auto-detect" || PROJECT_TYPE == "Multiple" ? `### .NET Guidelines -- Detect and strictly adhere to the specific .NET version in use -- Use only C# language features compatible with the detected version -- Follow LINQ usage patterns exactly as they appear in the codebase -- Match async/await usage patterns from existing code -- Apply the same dependency injection approach used in the codebase -- Use the same collection types and patterns found in existing code` : ""} - -${PROJECT_TYPE == "Java" || PROJECT_TYPE == "Auto-detect" || PROJECT_TYPE == "Multiple" ? `### Java Guidelines -- Detect and adhere to the specific Java version in use -- Follow the exact same design patterns found in the codebase -- Match exception handling patterns from existing code -- Use the same collection types and approaches found in the codebase -- Apply the dependency injection patterns evident in existing code` : ""} - -${PROJECT_TYPE == "JavaScript" || PROJECT_TYPE == "TypeScript" || PROJECT_TYPE == "Auto-detect" || PROJECT_TYPE == "Multiple" ? `### JavaScript/TypeScript Guidelines -- Detect and adhere to the specific ECMAScript/TypeScript version in use -- Follow the same module import/export patterns found in the codebase -- Match TypeScript type definitions with existing patterns -- Use the same async patterns (promises, async/await) as existing code -- Follow error handling patterns from similar files` : ""} - -${PROJECT_TYPE == "React" || PROJECT_TYPE == "Auto-detect" || PROJECT_TYPE == "Multiple" ? `### React Guidelines -- Detect and adhere to the specific React version in use -- Match component structure patterns from existing components -- Follow the same hooks and lifecycle patterns found in the codebase -- Apply the same state management approach used in existing components -- Match prop typing and validation patterns from existing code` : ""} - -${PROJECT_TYPE == "Angular" || PROJECT_TYPE == "Auto-detect" || PROJECT_TYPE == "Multiple" ? `### Angular Guidelines -- Detect and adhere to the specific Angular version in use -- Follow the same component and module patterns found in the codebase -- Match decorator usage exactly as seen in existing code -- Apply the same RxJS patterns found in the codebase -- Follow existing patterns for component communication` : ""} - -${PROJECT_TYPE == "Python" || PROJECT_TYPE == "Auto-detect" || PROJECT_TYPE == "Multiple" ? `### Python Guidelines -- Detect and adhere to the specific Python version in use -- Follow the same import organization found in existing modules -- Match type hinting approaches if used in the codebase -- Apply the same error handling patterns found in existing code -- Follow the same module organization patterns` : ""} - -## Version Control Guidelines - -${VERSIONING == "Semantic" ? -`- Follow Semantic Versioning patterns as applied in the codebase -- Match existing patterns for documenting breaking changes -- Follow the same approach for deprecation notices` : ""} - -${VERSIONING == "CalVer" ? -`- Follow Calendar Versioning patterns as applied in the codebase -- Match existing patterns for documenting changes -- Follow the same approach for highlighting significant changes` : ""} - -${VERSIONING == "Custom" ? -`- Match the exact versioning pattern observed in the codebase -- Follow the same changelog format used in existing documentation -- Apply the same tagging conventions used in the project` : ""} - -## General Best Practices - -- Follow naming conventions exactly as they appear in existing code -- Match code organization patterns from similar files -- Apply error handling consistent with existing patterns -- Follow the same approach to testing as seen in the codebase -- Match logging patterns from existing code -- Use the same approach to configuration as seen in the codebase - -## Project-Specific Guidance - -- Scan the codebase thoroughly before generating any code -- Respect existing architectural boundaries without exception -- Match the style and patterns of surrounding code -- When in doubt, prioritize consistency with existing code over external best practices -``` - -### 2. Codebase Analysis Instructions - -To create the copilot-instructions.md file, first analyze the codebase to: - -1. **Identify Exact Technology Versions**: - - ${PROJECT_TYPE == "Auto-detect" ? "Detect all programming languages, frameworks, and libraries by scanning file extensions and configuration files" : `Focus on ${PROJECT_TYPE} technologies`} - - Extract precise version information from project files, package.json, .csproj, etc. - - Document version constraints and compatibility requirements - -2. **Understand Architecture**: - - Analyze folder structure and module organization - - Identify clear layer boundaries and component relationships - - Document communication patterns between components - -3. **Document Code Patterns**: - - Catalog naming conventions for different code elements - - Note documentation styles and completeness - - Document error handling patterns - - Map testing approaches and coverage - -4. **Note Quality Standards**: - - Identify performance optimization techniques actually used - - Document security practices implemented in the code - - Note accessibility features present (if applicable) - - Document code quality patterns evident in the codebase - -### 3. Implementation Notes - -The final copilot-instructions.md should: -- Be placed in the .github/copilot directory -- Reference only patterns and standards that exist in the codebase -- Include explicit version compatibility requirements -- Avoid prescribing any practices not evident in the code -- Provide concrete examples from the codebase -- Be comprehensive yet concise enough for Copilot to effectively use - -Important: Only include guidance based on patterns actually observed in the codebase. Explicitly instruct Copilot to prioritize consistency with existing code over external best practices or newer language features. -" - -## Expected Output - -A comprehensive copilot-instructions.md file that will guide GitHub Copilot to produce code that is perfectly compatible with your existing technology versions and follows your established patterns and architecture. \ No newline at end of file +- Conventional Commits: `fix(scope):`, `feat(scope):`, `build:`, + `docs:`, `chore:`. +- DCO sign-off is required: `git commit -s`. +- One logical change per commit. Do not mix build fixes with logic + changes. +- PR descriptions: state what changed, why, and what was tested. + No AI-generated boilerplate. diff --git a/CHANGELOG b/CHANGELOG index 625240c..b28a618 100644 --- a/CHANGELOG +++ b/CHANGELOG @@ -6,6 +6,7 @@ The Cacti Group | spine -issue#424: Correct inverted spike_kill condition for PHP script server (IS_UNDEFINED -> !IS_UNDEFINED) -issue#425: Mark all OIDs undefined when snmp_get_multi() receives errindex==0 from agent -issue#426: Add NULL check after malloc in host_errors insert path to prevent UB on memory pressure +-issue#438: Resolve stale content in spine.c (--help search path), configure.ac (AC_PREREQ, obsolete macros), spine.conf.dist (missing settings), and Copilot instructions -feature#362: Report the number of data collection errors during data collection in host table -feature#439: Add idiomatic RPM spec for cacti-spine (%autosetup, %config(noreplace), man1) -feature#442: Add GitHub Actions CI: build matrix (gcc/clang), cppcheck, flawfinder, CodeQL diff --git a/configure.ac b/configure.ac index c4ef692..efa5e73 100644 --- a/configure.ac +++ b/configure.ac @@ -19,7 +19,7 @@ # | http://www.cacti.net/ | # +-------------------------------------------------------------------------+ -AC_PREREQ([2.63]) +AC_PREREQ([2.69]) AC_INIT([Spine Poller],[1.3.0],[http://www.cacti.net/issues.php]) AC_CONFIG_AUX_DIR(config) @@ -140,25 +140,11 @@ AC_CHECK_HEADERS( ) # Checks for typedefs, structures, and compiler characteristics. -AC_CHECK_TYPES([unsigned long long, long long]) -AC_C_CONST -AC_TYPE_SIZE_T AC_HEADER_TIME -AC_STRUCT_TM +AC_CHECK_TYPES([unsigned long long, long long]) +AC_TYPE_SIZE_T # Checks for library functions. -AC_DIAGNOSE([obsolete],[your code may safely assume C89 semantics that RETSIGTYPE is void. -Remove this warning and the `AC_CACHE_CHECK' when you adjust the code.])dnl -AC_CACHE_CHECK([return type of signal handlers],[ac_cv_type_signal],[AC_COMPILE_IFELSE( -[AC_LANG_PROGRAM([#include -#include -], - [return *(signal (0, 0)) (0) == 1;])], - [ac_cv_type_signal=int], - [ac_cv_type_signal=void])]) -AC_DEFINE_UNQUOTED([RETSIGTYPE],[$ac_cv_type_signal],[Define as the return type of signal handlers - (`int' or `void').]) - AC_CHECK_FUNCS(malloc calloc gettimeofday strerror strtoll) # ****************** Solaris Privileges Check *********************** diff --git a/spine.c b/spine.c index befdfc9..bbd6ff3 100644 --- a/spine.c +++ b/spine.c @@ -41,7 +41,8 @@ * * Provide the name of the Spine configuration file, which contains * the parameters for connecting to the database. In the absence of - * this, it looks [WHERE?] + * this, it searches in order: the current directory, /etc/, + * /etc/cacti/, and ../etc/ for a file named spine.conf. * * -f | --first=ID * @@ -1149,8 +1150,8 @@ static void display_help(int only_version) { "Either both of --first/--last must be provided, a valid hostlist must be provided.", "In their absence, all hosts are processed.", "", - "Without the --conf parameter, spine searches for its spine.conf", - "file in the usual places.", + "Without the --conf parameter, spine searches in order:", + " current directory, /etc/, /etc/cacti/, ../etc/ for spine.conf.", "", "Verbosity is one of NONE/LOW/MEDIUM/HIGH/DEBUG or 1..5", "", diff --git a/spine.conf.dist b/spine.conf.dist index a251e37..1c90b68 100644 --- a/spine.conf.dist +++ b/spine.conf.dist @@ -49,6 +49,7 @@ DB_Port 3306 #DB_SSL_Key #DB_SSL_Cert #DB_SSL_CA +#SNMP_Clientaddr #Cacti_Log /var/www/html/cacti/log/cacti.log #RDB_Host localhost