Fix remote Transmission detection and config directory creation

- Fix bug where installer doesn't ask if Transmission is remote
- Fix missing configuration directory in /etc/transmission-rss-manager
- Create symlink between config locations to ensure app always finds config
- Ensure CONFIG_DIR is properly exported in the environment
- Update version to 2.0.4

🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
This commit is contained in:
2025-03-05 08:39:21 +00:00
parent c495bce21f
commit 4c68a1ac07
7 changed files with 60 additions and 71 deletions
+38 -65
View File
@@ -1,75 +1,48 @@
# Git-Based Installation and Update System
# Changes for Moving Config File to /etc/transmission-rss-manager
We've restructured the Transmission RSS Manager to use a git-based approach for installation and updates. Here's how the new system works:
## Overview
This update moves the configuration file from the application directory to `/etc/transmission-rss-manager/config.json` for better system organization, while maintaining backward compatibility by checking the original location as a fallback.
## New Architecture
## Changes Made
1. **Bootstrap Installer**
- Small, self-contained installer script
- Installs git if needed
- Clones the main repository
- Runs the main installer
### 1. Server.js Updates
- Changed default config location to `/etc/transmission-rss-manager/config.json`
- Added fallback location (`path.join(__dirname, 'config.json')`) for backward compatibility
- Enhanced `loadConfig()` function to try primary location first, then fallback location
- Updated `saveConfig()` function to try saving to primary location first, then fallback
- Added `installPath` property to configuration to store the application installation path for easier updates
2. **Main Installer**
- Modified to work with git-managed files
- Doesn't need to generate application files
- Only creates config files and sets up services
### 2. Installer Updates
- Added `CONFIG_DIR="/etc/transmission-rss-manager"` variable to config-module.sh
- Updated `create_directories()` in dependencies-module.sh to create the config directory
- Updated permission settings to ensure proper access to config directory
- Added checks for the CONFIG_DIR variable to ensure it's set
- Modified service-setup-module.sh to include CONFIG_DIR in the environment variables for the systemd service
- Updated file-creator-module.sh to write the initial config.json to the new location
3. **Update System**
- Web interface shows current version
- Checks for updates automatically
- One-click update process
- Preserves user configuration
### 3. Documentation Updates
- Updated README.md to reflect new config file location
- Added entry to the changelog for version 2.0.3
- Updated code examples in README
- Bumped version from 2.0.2 to 2.0.3 in both README.md and package.json
## Key Files
## Technical Details
1. **bootstrap-installer.sh**
- Entry point for new installations
- Minimal script that pulls everything else from git
### Config File Loading Process
1. Try to load config from primary location (`/etc/transmission-rss-manager/config.json`)
2. If not found, try fallback location (`<install_dir>/config.json`)
3. If neither exists, create a new config file at primary location
4. If primary location is not writable, fall back to application directory
2. **update.sh**
- Located in the scripts/ directory
- Handles git pull and service restart
- Preserves local configuration changes
3. **System Status UI**
- Added to the dashboard
- Shows version, uptime, and connection status
- Notifies when updates are available
4. **Server Endpoints**
- `/api/system/status` - Gets current version and system status
- `/api/system/check-updates` - Checks if updates are available
- `/api/system/update` - Triggers the update process
### Configuration Storage Logic
- Primary storage location: `/etc/transmission-rss-manager/config.json`
- Fallback location: `<install_dir>/config.json`
- Automatic migration from fallback to primary when possible
- Always try to write to primary first, then fallback if needed
## Benefits
1. **Simplified Maintenance**
- Single source of truth in the git repository
- No need to embed code in installation scripts
- Easy to make changes and publish updates
2. **Better User Experience**
- Users can see when updates are available
- One-click update process
- No need to manually download and run scripts
3. **Version Control**
- Clear versioning visible to users
- Update history preserved in git
- Easy rollback if needed
## Implementation Notes
This implementation preserves local configuration by:
1. Stashing local changes before pulling updates
2. Applying those changes back after the update
3. Handling any potential conflicts
The service automatically restarts after updates, ensuring users always have the latest version running.
## Next Steps
1. Update the GitHub repository structure to match this new approach
2. Test the installation and update process in a clean environment
3. Consider adding a changelog display in the UI to show what's new in each version
- More standard Linux configuration location in /etc
- Easier to find and edit configuration
- Clear separation between code and configuration
- Maintains backward compatibility with existing installations
- Simplified update process by storing installation path