Fix permission denied when removing existing borg binary during system installation

- Add sudo prefix to rm command when installing system-wide
- Clean up outdated README files
This commit is contained in:
kdusek
2025-12-02 23:05:24 +01:00
parent c727d8e1f2
commit 97f224746c
8 changed files with 24 additions and 1260 deletions

View File

@@ -1,192 +0,0 @@
# Borg CLI Installer
A comprehensive installer script for Borg CLI that supports multiple Linux distributions and installation methods.
## Features
- **Version Checking**: Only downloads and installs if newer version is available
- **Multiple Installation Methods**:
- Package manager (apt, yum, dnf, pacman, zypper)
- Binary download from GitHub releases
- **Cross-Platform Support**: Debian, Ubuntu, RHEL, CentOS, Fedora, Arch, openSUSE
- **Architecture Support**: x86_64 (amd64), ARM64, ARM
- **Automatic Updates**: Fetches latest version from GitHub API
- **Force Reinstall**: Option to force reinstall even if up-to-date
## Usage
### Basic Usage
```bash
# Install latest version (only if newer than current)
./install-borg-cli.sh
# Install specific version
./install-borg-cli.sh -v 1.4.2
# Force reinstall even if up-to-date
./install-borg-cli.sh --force
```
### Installation Methods
```bash
# Force installation from package manager
./install-borg-cli.sh --package
# Force installation from binary
./install-borg-cli.sh --binary
```
### Help
```bash
./install-borg-cli.sh --help
```
## Installation Logic
### Version Checking
1. **Check Current Version**: Detects installed Borg CLI version
2. **Fetch Latest**: Gets latest version from GitHub API
3. **Compare Versions**: Only proceeds if newer version available
4. **Force Override**: `--force` flag bypasses version check
### Installation Priority
1. **Package Manager** (preferred):
- Debian/Ubuntu: Checks for official borgbackup package
- RHEL/CentOS/Fedora: Checks for available borgbackup package
- Arch Linux: Available in pacman repositories
- openSUSE: Checks for available borgbackup package
2. **Binary Download** (fallback):
- Downloads platform-specific binary from GitHub releases
- Supports x86_64, ARM64, ARM architectures
- Installs to `/usr/local/bin/borg` or `~/bin/borg`
## File Locations
### Installation Directory
- Binary: `/usr/local/bin/borg` (system) or `~/bin/borg` (user)
- Symlink: `borg -> borg-1.4.2` (version-specific)
## Version Comparison
The installer uses semantic version comparison:
- **Format**: `X.Y.Z` (e.g., `1.4.2`)
- **Logic**: Compares major, minor, patch versions
- **Build Info**: Ignores build hashes/identifiers
### Examples
```bash
# Current: 1.4.0, Latest: 1.4.2 → Update needed
# Current: 1.4.2, Latest: 1.4.2 → No update needed
# Current: 1.4.3, Latest: 1.4.2 → No update needed (newer installed)
```
## System Requirements
### Required
- `curl` or `wget` (for downloading)
- `sudo` access (for system-wide installation)
### Optional
- Package manager access (for package installations)
- Internet connection (for downloading releases)
## Supported Distributions
### Package Manager Support
- **Debian/Ubuntu**: `borgbackup` package
- **RHEL/CentOS/Fedora**: `borgbackup` package
- **Arch Linux**: `borg` package
- **openSUSE**: `borgbackup` package
### Binary Support
- **Linux x86_64**: `borg-linux-glibc231-x86_64`
- **Linux ARM64**: `borg-linux-glibc231-aarch64`
- **Linux ARM**: `borg-linux-glibc231-armv7`
## Troubleshooting
### Version Detection Issues
```bash
# Check current version manually
borg --version
# Force reinstall if version detection fails
./install-borg-cli.sh --force
```
### Permission Issues
```bash
# For system installation
sudo ./install-borg-cli.sh --binary
```
### PATH Issues
```bash
# Check if user bin is in PATH
echo $PATH | grep -q "$HOME/bin" && echo "OK" || echo "Add to PATH"
# Test borg command
which borg
borg --version
```
## Examples
### Typical Workflow
```bash
# Check if update needed
./install-borg-cli.sh
# Output if up-to-date:
# [SUCCESS] You already have latest version (1.4.2)
# [SUCCESS] No installation needed. Exiting.
# Output if update available:
# [INFO] Current version: 1.4.0 (user)
# [INFO] Latest version: 1.4.2
# [INFO] Newer version available: 1.4.2 > 1.4.0
# [SUCCESS] Installation completed successfully!
```
### Force Binary Installation
```bash
# Force binary installation
./install-borg-cli.sh --force --binary
# Output:
# [SUCCESS] Borg CLI binary installed successfully
# Next steps:
# 1. Test installation: borg --version
# 2. Initialize repository: borg init --encryption=repokey /path/to/repo
# 3. Create backup: borg create /path/to/repo::backup-name /path/to/backup
# 4. Use Borg CLI: borg --help
```
## Integration with Setup Script
The Borg CLI installer can be integrated with backup setup scripts:
- Automatically called when Borg CLI is needed
- Respects user preferences for installation location
- Provides clear feedback on installation strategy
- Handles both new installations and updates
## Security Features
- **Official Releases**: Downloads from official GitHub releases
- **Package Verification**: Uses official package repositories
- **Proper Permissions**: Sets appropriate file ownership and permissions
## Contributing
To add support for new distributions or architectures:
1. Update `detect_os()` function for new package managers
2. Add architecture detection in `get_arch()` function
3. Update installation methods in `install_borg_from_*()` functions
4. Test with target distribution
5. Update documentation
## License
This installer script follows the same license as Borg (BSD-3-Clause).

View File

@@ -1,247 +0,0 @@
# Git Credential Manager Installer
A comprehensive installer script for Git Credential Manager (GCM) that supports multiple Linux distributions and installation methods.
## Features
- **Version Checking**: Only downloads and installs if newer version is available
- **Multiple Installation Methods**:
- Package manager (apt, yum, dnf, pacman, zypper)
- DEB packages (Debian/Ubuntu)
- Tar.gz archives (universal)
- **Cross-Platform Support**: Debian, Ubuntu, RHEL, CentOS, Fedora, Arch, openSUSE
- **Architecture Support**: x86_64 (amd64), ARM64 (arm64), ARM (armv7l)
- **Automatic Updates**: Fetches latest version from GitHub releases
- **Force Reinstall**: Option to force reinstallation even if up-to-date
## Usage
### Basic Usage
```bash
# Install latest version (only if newer than current)
./install-git-credential-manager.sh
# Install specific version
./install-git-credential-manager.sh -v v2.6.0
# Force reinstall even if up-to-date
./install-git-credential-manager.sh --force
```
### Installation Methods
```bash
# Force installation from package manager
./install-git-credential-manager.sh --package
# Force installation from DEB package
./install-git-credential-manager.sh --deb
# Force installation from tarball
./install-git-credential-manager.sh --tarball
```
### Check Configuration Only
```bash
# Check current Git credential configuration without installing
./install-git-credential-manager.sh --checks
# Example output:
# ✓ Global credential helper: manager
# ✓ GitHub credential helper configured
# ✗ GitLab credential helper not configured
# ✗ Azure DevOps useHttpPath not configured
# ✗ Bitbucket credential helper not configured
# ✓ Gitea credential helpers configured (1 found)
#
# Run these commands to complete the configuration:
# git config --global credential.https://gitlab.com.helper manager
# git config --global credential.https://dev.azure.com.useHttpPath true
# git config --global credential.https://bitbucket.org.helper manager
```
### Help
```bash
./install-git-credential-manager.sh --help
```
## Installation Logic
### Version Checking
1. **Check Current Version**: Detects installed GCM version
2. **Fetch Latest**: Gets latest version from GitHub API
3. **Compare Versions**: Only proceeds if newer version available
4. **Force Override**: `--force` flag bypasses version check
### Installation Priority
1. **Package Manager** (preferred):
- Debian/Ubuntu: `apt install git-credential-manager`
- Arch Linux: `pacman -S git-credential-manager`
- Others: Falls back to manual installation
2. **Distribution-Specific**:
- Debian/Ubuntu: Downloads `.deb` package
- Other Linux: Downloads `.tar.gz` archive
3. **Universal Fallback**:
- Downloads tarball for any architecture
- Extracts and installs binary to `/usr/local/bin`
## System Requirements
### Required
- `curl` or `wget` (for downloading)
- `sudo` access (for system-wide installation)
- Git (for configuration)
### Optional
- Package manager access (for package installations)
- Internet connection (for downloading releases)
## File Locations
### Installation Directory
- Binary: `/usr/local/bin/git-credential-manager`
- Symlink: `/usr/local/bin/git-credential-manager-core`
- Libraries: `/usr/local/bin/lib*.so`
### Configuration
- Git config: `~/.gitconfig`
- Credential storage: Platform-specific secure storage
## Version Comparison
The installer uses semantic version comparison:
- **Format**: `vX.Y.Z` (e.g., `v2.6.1`)
- **Logic**: Compares major, minor, patch versions
- **Build Info**: Ignores build hashes/identifiers
### Examples
```bash
# Current: v2.6.1, Latest: v2.6.1 → No update needed
# Current: v2.6.0, Latest: v2.6.1 → Update needed
# Current: v2.6.1, Latest: v2.6.0 → No update needed (newer installed)
```
## Integration with Setup Script
The installer is automatically integrated with the main Git repository setup script:
1. **Detection**: Checks for existing credential managers
2. **Offer Installation**: Prompts to install GCM if none found
3. **Configuration**: Sets up Git to use the credential manager
4. **Domain-Specific**: Configures for specific Gitea instances
## Security Features
- **Official Releases**: Downloads from official GitHub releases
- **Checksum Verification**: Can verify package integrity (future enhancement)
- **Secure Storage**: Uses OS keyring for credential storage
- **No Plain Text**: Never stores credentials in plain text
## Troubleshooting
### Version Detection Issues
```bash
# Check current version manually
git-credential-manager --version
# Force reinstall if version detection fails
./install-git-credential-manager.sh --force
```
### Permission Issues
```bash
# Ensure proper permissions
sudo chown root:root /usr/local/bin/git-credential-manager
sudo chmod 755 /usr/local/bin/git-credential-manager
```
### Network Issues
```bash
# Use specific version if network blocks GitHub API
./install-git-credential-manager.sh -v v2.6.1
```
## Examples
### Typical Workflow
```bash
# Check if update needed
./install-git-credential-manager.sh
# Output if up-to-date:
# [SUCCESS] You already have the latest version (v2.6.1)
# [SUCCESS] No installation needed. Exiting.
# Output if update available:
# [INFO] Current version: v2.6.0
# [INFO] Latest version: v2.6.1
# [INFO] Newer version available: v2.6.1 > v2.6.0
# [SUCCESS] Installation completed successfully!
```
### Automated Installation
```bash
# Script for automated setup
#!/bin/bash
./install-git-credential-manager.sh --force --package
git config --global credential.helper manager
```
## Post-Installation Configuration Check
After successful installation, the installer automatically checks and configures all required Git presets:
### ✅ Preset Verification
The installer checks these configurations:
- **Global credential helper**: `credential.helper manager`
- **GitHub**: `credential.https://github.com.helper manager`
- **GitLab**: `credential.https://gitlab.com.helper manager`
- **Bitbucket**: `credential.https://bitbucket.org.helper manager`
- **Azure DevOps**: `credential.https://dev.azure.com.useHttpPath true`
- **Gitea servers**: Domain-specific credential helpers
### 📋 Configuration Report
The installer provides:
- **Status summary**: Shows which presets are configured (✓) or missing (✗)
- **Exact commands**: Lists the exact `git config` commands needed
- **Testing guidance**: Commands to verify the configuration
- **Service-specific advice**: Tailored guidance for different Git hosting services
### 🔧 Manual Configuration
If presets are missing, the installer shows exactly what to run:
```bash
# Example output for missing presets:
Run these commands to complete the configuration:
git config --global credential.https://gitlab.com.helper manager
git config --global credential.https://dev.azure.com.useHttpPath true
git config --global credential.https://bitbucket.org.helper manager
# For Gitea servers, configure domain-specific helper:
git config --global credential.https://go-gitea.mywire.org.helper manager
After configuring, test with:
git config --global --list | grep credential
```
## Integration with Setup Script
The installer integrates seamlessly with the main setup script:
- Automatically called when Git Credential Manager is needed
- Respects user preferences for installation location
- Provides clear feedback on installation strategy
- Handles both new installations and updates
- **Performs comprehensive preset checking and configuration**
## Contributing
To add support for new distributions or architectures:
1. Update `detect_os()` function for new package managers
2. Add architecture detection in `get_arch()` function
3. Update installation methods in `install_from_*()` functions
4. Test with target distribution
## License
This installer script follows the same license as Git Credential Manager (MIT).

View File

@@ -1,217 +0,0 @@
# Gitea Server Installer
A comprehensive installer script for Gitea server that supports multiple Linux distributions and installation methods.
## Features
- **Version Checking**: Only downloads and installs if newer version is available
- **Multiple Installation Methods**:
- Package manager (apt, yum, dnf, zypper)
- Binary download from GitHub releases
- **Cross-Platform Support**: Debian, Ubuntu, RHEL, CentOS, Fedora, Arch, openSUSE
- **Architecture Support**: x86_64 (amd64), ARM64, ARM
- **Automatic Updates**: Fetches latest version from GitHub releases
- **Force Reinstall**: Option to force reinstall even if up-to-date
- **Service Setup**: Optional systemd service creation and configuration
## Usage
### Basic Usage
```bash
# Install latest version (only if newer than current)
./install-gitea-server.sh
# Install specific version
./install-gitea-server.sh -v v1.25.0
# Force reinstall even if up-to-date
./install-gitea-server.sh --force
```
### Installation Methods
```bash
# Force installation from package manager
./install-gitea-server.sh --package
# Force installation from binary
./install-gitea-server.sh --binary
# Install and set up as systemd service
./install-gitea-server.sh --service
```
### Help
```bash
./install-gitea-server.sh --help
```
## Installation Logic
### Version Checking
1. **Check Current Version**: Detects installed Gitea version
2. **Fetch Latest**: Gets latest version from GitHub API
3. **Compare Versions**: Only proceeds if newer version available
4. **Force Override**: `--force` flag bypasses version check
### Installation Priority
1. **Package Manager** (preferred):
- Debian/Ubuntu: Uses official Gitea repository
- RHEL/CentOS/Fedora: Uses official Gitea repository
- Arch Linux: Available in AUR
- openSUSE: Uses official Gitea repository
2. **Binary Download** (fallback):
- Downloads platform-specific binary from GitHub releases
- Supports x86_64, ARM64, ARM architectures
- Installs to `/usr/local/bin/gitea`
### Service Setup
When `--service` is used:
- Creates systemd service file
- Sets up proper user/group permissions
- Creates configuration directories
- Generates basic configuration
- Enables and starts the service
## File Locations
### Installation Directory
- Binary: `/usr/local/bin/gitea`
- Service: `/etc/systemd/system/gitea.service`
- Configuration: `/etc/gitea/app.ini`
- Data: `/var/lib/gitea/data`
- Repositories: `/var/lib/gitea/data/repositories`
- Logs: `/var/lib/gitea/log`
- Attachments: `/var/lib/gitea/data/attachments`
### Configuration
The installer creates a basic configuration with:
- SQLite database (suitable for small installations)
- Security settings with generated secret key
- Local file storage
- Console logging
- Service user/group permissions
## Version Comparison
The installer uses semantic version comparison:
- **Format**: `vX.Y.Z` (e.g., `v1.25.1`)
- **Logic**: Compares major, minor, patch versions
- **Build Info**: Ignores build hashes/identifiers
### Examples
### Typical Workflow
```bash
# Check if update needed
./install-gitea-server.sh
# Output if up-to-date:
# [SUCCESS] You already have latest version (v1.25.1)
# [SUCCESS] No installation needed. Exiting.
# Output if update available:
# [INFO] Current version: v1.25.0
# [INFO] Latest version: v1.25.1
# [INFO] Newer version available: v1.25.1 > v1.25.0
# [SUCCESS] Installation completed successfully!
```
### Service Setup
```bash
# Install and set up as service
./install-gitea-server.sh --service
# Output:
# [SUCCESS] Gitea service setup completed!
# Next steps:
# 1. Start service: sudo systemctl start gitea
# 2. Check status: sudo systemctl status gitea
# 3. View logs: sudo journalctl -u gitea -f
# 4. Configure at: /etc/gitea/app.ini
```
## System Requirements
### Required
- `curl` or `wget` (for downloading)
- `sudo` access (for system-wide installation)
- Systemd (for service setup)
### Optional
- Package manager access (for package installations)
- Internet connection (for downloading releases)
## Security Features
- **Official Releases**: Downloads from official GitHub releases
- **Package Verification**: Uses GPG keys for package manager installations
- **Proper Permissions**: Sets appropriate file ownership and permissions
- **Service Isolation**: Runs as dedicated service user/group
## Supported Distributions
### Package Manager Support
- **Debian/Ubuntu**: Official Gitea repository with GPG verification
- **RHEL/CentOS/Fedora**: Official Gitea RPM repository
- **Arch Linux**: Available in AUR (pacman)
- **openSUSE**: Official Gitea repository
### Binary Support
- **Linux x86_64**: `gitea-1.25.1-linux-amd64`
- **Linux ARM64**: `gitea-1.25.1-linux-arm64`
- **Linux ARM**: `gitea-1.25.1-linux-arm-5`
## Troubleshooting
### Version Detection Issues
```bash
# Check current version manually
gitea --version
# Force reinstall if version detection fails
./install-gitea-server.sh --force
```
### Permission Issues
```bash
# Ensure proper permissions
sudo chown root:root /usr/local/bin/gitea
sudo chmod 755 /usr/local/bin/gitea
```
### Service Issues
```bash
# Check service status
sudo systemctl status gitea
# View service logs
sudo journalctl -u gitea -f
# Restart service
sudo systemctl restart gitea
```
## Production Considerations
For production use, consider:
- Using PostgreSQL/MySQL instead of SQLite
- Configuring reverse proxy (nginx/apache)
- Setting up SSL certificates
- Adjusting firewall settings
- Regular backups
- Monitoring and log rotation
## Contributing
To add support for new distributions or architectures:
1. Update `detect_os()` function for new package managers
2. Add architecture detection in `get_arch()` function
3. Update installation methods in `install_from_*()` functions
4. Test with target distribution
5. Update documentation
## License
This installer script follows the same license as Gitea (MIT).

View File

@@ -1,205 +0,0 @@
# Git Credential Managers for Gitea
Git credential managers provide secure storage and automatic retrieval of your Git credentials, eliminating the need to repeatedly enter usernames and passwords/tokens.
## Supported Credential Managers
### 1. Git Credential Manager (GCM) - Console & GUI
- **Cross-platform**: Windows, macOS, Linux
- **Official Microsoft project**
- **Console-First**: Works perfectly in terminal without GUI
- **Supports**: HTTPS authentication, personal access tokens, OAuth
- **Installation**:
```bash
# Linux (various distributions)
sudo apt install git-credential-manager # Ubuntu/Debian
sudo yum install git-credential-manager # RHEL/CentOS
sudo pacman -S git-credential-manager # Arch
# macOS
brew install git-credential-manager
# Windows
# Included with Git for Windows
```
- **Console Usage**: All operations are terminal-based, no GUI required
### 2. libsecret (Linux) - Console Only
- **Linux native**: Uses system keyring (GNOME Keyring, KWallet)
- **Console-Only**: No GUI components, pure terminal integration
- **Installation**:
```bash
# Ubuntu/Debian
sudo apt install libsecret-1-0 libsecret-1-dev
# RHEL/CentOS
sudo yum install libsecret-devel
# Configure Git
git config --global credential.helper /usr/share/doc/git/contrib/credential/gnome-keyring/git-credential-gnome-keyring
```
### 3. osxkeychain (macOS) - Console & GUI
- **Built-in**: Uses macOS Keychain
- **Console-First**: Works in terminal, can also access GUI keychain
- **Configuration**:
```bash
git config --global credential.helper osxkeychain
```
### 4. manager (Generic)
- **Built-in**: Simple in-memory cache
- **Configuration**:
```bash
git config --global credential.helper manager
```
## Configuration for Gitea
### Method 1: Personal Access Token
1. Generate token in Gitea: User Settings → Applications → Generate Token
2. Configure Git:
```bash
git config --global credential.helper manager
# First push will prompt for username and token
```
### Method 2: Direct Credential Storage
```bash
# Store credentials for specific Gitea instance
git config --global credential.https://go-gitea.mywire.org.helper manager
```
### Method 3: Environment Variables
```bash
export GIT_USERNAME="your_username"
export GIT_PASSWORD="your_access_token"
```
## Security Considerations
### ✅ Secure Options
- **GCM**: Encrypts credentials, integrates with OS keyring
- **libsecret/osxkeychain**: Uses system secure storage
- **Personal Access Tokens**: More secure than passwords, can be revoked
### ⚠️ Less Secure Options
- **Plain text**: Storing credentials in .netrc files
- **Environment variables**: Visible in process list
- **Cache-only**: Credentials stored in memory only
## Console-Only Operation
### How It Works Without GUI
1. **Terminal Prompts**: Git prompts for username/token in console
2. **Secure Storage**: Credentials stored in system keyring (encrypted)
3. **Automatic Retrieval**: Subsequent Git operations use stored credentials
4. **No GUI Required**: All operations happen in terminal
### Console Workflow Example
```bash
# First time - prompts in terminal
$ git push origin main
Username for 'https://go-gitea.mywire.org': kadu
Password for 'https://kadu@go-gitea.mywire.org': your_access_token
# Subsequent times - automatic
$ git push origin main
Everything up-to-date
# No more prompts!
```
## Integration with Setup Script
The setup script can:
1. Detect available credential managers
2. Configure Git to use the best available option
3. Guide users through secure credential setup
4. Test credential storage and retrieval
5. **Check all required Git presets after installation**
6. **Provide exact commands to complete configuration**
## Post-Installation Configuration Check
The installer automatically checks and configures these Git presets:
### ✅ Required Presets
- `credential.helper manager` - Global credential helper
- `credential.https://github.com.helper manager` - GitHub specific
- `credential.https://gitlab.com.helper manager` - GitLab specific
- `credential.https://bitbucket.org.helper manager` - Bitbucket specific
- `credential.https://dev.azure.com.useHttpPath true` - Azure DevOps
- Domain-specific helpers for Gitea servers
### 📋 Configuration Summary
After installation, the installer provides:
- **Status of each preset** (✓ configured, ✗ missing)
- **Exact commands** to complete configuration
- **Testing commands** to verify setup
- **Usage guidance** for different Git hosting services
5. Work entirely in console mode
## Best Practices for Gitea
1. **Use Personal Access Tokens** instead of passwords
2. **Set token expiration** and permissions appropriately
3. **Use HTTPS with credential manager** for most users (console-friendly)
4. **Use SSH keys** for automated/scripted access
5. **Regularly rotate tokens** for security
6. **Console environments**: All credential managers work perfectly in SSH/remote terminals
## Troubleshooting
### Common Issues
- **Token not working**: Ensure token has required scopes (repo, user)
- **Credential manager not found**: Install appropriate package for your OS
- **HTTPS certificate errors**: Configure Git to trust your Gitea certificate
- **Authentication prompts**: Check credential helper configuration
### Debug Commands
```bash
# Test credential storage
git credential fill
# Check current configuration
git config --global --show-origin --get credential.helper
# Clear stored credentials
git credential-cache exit
```
## Example Workflow (Console Only)
```bash
# 1. Configure credential manager
git config --global credential.helper manager
# 2. First time authentication (console prompts)
$ git clone https://go-gitea.mywire.org/username/repo.git
Username for 'https://go-gitea.mywire.org': your_username
Password for 'https://go-gitea.mywire.org': your_access_token
# 3. Subsequent operations use stored credentials automatically
$ git pull
Already up to date.
$ git push
Everything up-to-date
# No more prompts - works in any terminal/SSH session!
```
## Remote/SSH Console Usage
Credential managers work perfectly in remote SSH sessions:
```bash
# SSH into remote server
ssh user@server
# Git operations work with stored credentials
cd /project
git pull # Uses stored credentials, no prompts
git push # Automatic authentication
```

View File

@@ -1,157 +0,0 @@
# Tea CLI Installer - Advanced Version Management
## Enhanced Installation Strategy
The Tea CLI installer now implements sophisticated version management with user-specific installations:
### Installation Priority Order
1. **User Bin Directory** (`~/bin`) - Preferred
- Checks if `~/bin` exists and is in PATH
- Installs binaries with version-specific names
- Creates symlinks for easy version switching
- Allows multiple versions side-by-side
2. **System Installation** (`/usr/local/bin`) - Fallback
- Used when user bin is not available
- Requires sudo for system-wide installation
- Single version installation
### Version Management Features
#### Symlink-Based Version Control
```bash
~/bin/
├── tea -> tea-v0.11.1 # Active version symlink
├── tea-v0.11.0 # Previous version
├── tea-v0.11.1 # Current version
└── tea-v0.12.0 # Future version (when available)
```
#### Automatic Updates
- Detects current version via symlink
- Downloads newer versions with version suffix
- Updates symlink to point to latest version
- Preserves old versions for rollback
### Installation Strategies
#### `user_install` - Fresh User Installation
- When Tea CLI not found in user bin
- Creates versioned binary and symlink
- No sudo required
#### `user_update` - User Version Update
- When newer version available
- Downloads new version with suffix
- Updates symlink to new version
- Keeps old versions
#### `user_upgrade` - User Upgrade (No Symlink)
- When existing binary found but no symlink
- Creates versioned structure
- Adds symlink management
#### `system_install` - System Installation
- When user bin not available/in PATH
- Installs to `/usr/local/bin`
- Requires sudo privileges
### Usage Examples
#### Normal Usage (Auto-detects strategy)
```bash
./install-tea-cli.sh
# Detects user bin, checks versions, updates if needed
```
#### Force Binary Installation
```bash
./install-tea-cli.sh --force --binary
# Forces binary download regardless of current version
```
#### Check Current Status
```bash
./install-tea-cli.sh
# Shows current version and installation type
# Exits if no update needed
```
### Version Detection Logic
1. **Check PATH**: Finds `tea` command location
2. **Installation Type**: Determines user vs system installation
3. **Symlink Check**: Detects version-specific symlinks
4. **Version Comparison**: Compares with latest release
5. **Strategy Selection**: Chooses appropriate installation method
### Benefits
**User Isolation**: Installations don't affect other users
**Version Control**: Multiple versions can coexist
**Easy Updates**: Symlinks automatically point to latest
**Rollback Support**: Old versions preserved
**No Sudo Required**: User installations don't need root
**System Fallback**: Falls back to system installation when needed
### Directory Structure
#### User Installation
```
~/bin/
├── tea -> tea-v0.11.1
├── tea-v0.11.0
└── tea-v0.11.1
```
#### System Installation
```
/usr/local/bin/
├── tea -> tea-v0.11.1
├── tea-v0.11.0
└── tea-v0.11.1
```
### PATH Requirements
For user installations, ensure `~/bin` is in PATH:
```bash
# Add to ~/.bashrc or ~/.profile
export PATH="$HOME/bin:$PATH"
```
### Troubleshooting
#### Version Not Updating
```bash
# Check current symlink
ls -la ~/bin/tea
# Force reinstall
./install-tea-cli.sh --force
```
#### PATH Issues
```bash
# Check if user bin is in PATH
echo $PATH | grep -q "$HOME/bin" && echo "OK" || echo "Add to PATH"
# Test tea command
which tea
tea --version
```
#### Permission Issues
```bash
# For system installation
sudo ./install-tea-cli.sh --binary
```
### Integration with Setup Script
The installer integrates seamlessly with the main setup script:
- Automatically called when Tea CLI is needed
- Respects user preferences for installation location
- Provides clear feedback on installation strategy
- Handles both new installations and updates

View File

@@ -1,196 +0,0 @@
# Tea CLI Installer
A comprehensive installer script for Gitea Tea CLI that supports multiple Linux distributions and installation methods.
## Features
- **Version Checking**: Only downloads and installs if newer version is available
- **Multiple Installation Methods**:
- Package manager (apt, yum, dnf, zypper)
- Binary download from Gitea releases
- **Cross-Platform Support**: Debian, Ubuntu, RHEL, CentOS, Fedora, Arch, openSUSE
- **Architecture Support**: x86_64 (amd64), ARM64, ARM
- **Automatic Updates**: Fetches latest version from Gitea API
- **Force Reinstall**: Option to force reinstall even if up-to-date
## Usage
### Basic Usage
```bash
# Install latest version (only if newer than current)
./install-tea-cli.sh
# Install specific version
./install-tea-cli.sh -v v0.11.0
# Force reinstall even if up-to-date
./install-tea-cli.sh --force
```
### Installation Methods
```bash
# Force installation from package manager
./install-tea-cli.sh --package
# Force installation from binary
./install-tea-cli.sh --binary
```
### Help
```bash
./install-tea-cli.sh --help
```
## Installation Logic
### Version Checking
1. **Check Current Version**: Detects installed Tea CLI version
2. **Fetch Latest**: Gets latest version from Gitea API
3. **Compare Versions**: Only proceeds if newer version available
4. **Force Override**: `--force` flag bypasses version check
### Installation Priority
1. **Package Manager** (preferred):
- Debian/Ubuntu: Checks for official Tea CLI package
- RHEL/CentOS/Fedora: Checks for available Tea CLI package
- Arch Linux: Available in AUR (pacman)
- openSUSE: Checks for available Tea CLI package
2. **Binary Download** (fallback):
- Downloads platform-specific binary from Gitea releases
- Supports x86_64, ARM64, ARM architectures
- Installs to `/usr/local/bin/tea`
## File Locations
### Installation Directory
- Binary: `/usr/local/bin/tea`
- Symlink: `/usr/local/bin/tea-<version>`
## Version Comparison
The installer uses semantic version comparison:
- **Format**: `vX.Y.Z` (e.g., `v0.11.1`)
- **Logic**: Compares major, minor, patch versions
- **Build Info**: Ignores build hashes/identifiers
### Examples
```bash
# Current: 0.11.0, Latest: v0.11.1 → Update needed
# Current: 0.11.1, Latest: v0.11.1 → No update needed
# Current: 0.11.2, Latest: v0.11.1 → No update needed (newer installed)
```
## System Requirements
### Required
- `curl` or `wget` (for downloading)
- `sudo` access (for system-wide installation)
### Optional
- Package manager access (for package installations)
- Internet connection (for downloading releases)
## Supported Distributions
### Package Manager Support
- **Debian/Ubuntu**: Checks for official Tea CLI package
- **RHEL/CentOS/Fedora**: Checks for available Tea CLI package
- **Arch Linux**: Available in AUR (pacman)
- **openSUSE**: Checks for available Tea CLI package
### Binary Support
- **Linux x86_64**: `tea-0.11.1-linux-amd64`
- **Linux ARM64**: `tea-0.11.1-linux-arm64`
- **Linux ARM**: `tea-0.11.1-linux-arm-5`, `tea-0.11.1-linux-arm-6`, `tea-0.11.1-linux-arm-7`
## Troubleshooting
### Version Detection Issues
```bash
# Check current version manually
tea --version
# Force reinstall if version detection fails
./install-tea-cli.sh --force
```
### Permission Issues
```bash
# Ensure proper permissions
sudo chown root:root /usr/local/bin/tea
sudo chmod 755 /usr/local/bin/tea
```
### PATH Issues
```bash
# Check which tea is being used
which tea
# Check all tea installations
find /usr -name tea 2>/dev/null
find /home -name tea 2>/dev/null
# Update PATH if needed
export PATH="/usr/local/bin:$PATH"
```
## Examples
### Typical Workflow
```bash
# Check if update needed
./install-tea-cli.sh
# Output if up-to-date:
# [SUCCESS] You already have the latest version (0.11.1)
# [SUCCESS] No installation needed. Exiting.
# Output if update available:
# [INFO] Current version: 0.11.0
# [INFO] Latest version: v0.11.1
# [INFO] Newer version available: v0.11.1 > 0.11.0
# [SUCCESS] Installation completed successfully!
```
### Force Binary Installation
```bash
# Force binary installation
./install-tea-cli.sh --force --binary
# Output:
# [SUCCESS] Tea CLI binary installed successfully
# Next steps:
# 1. Test installation: tea --version
# 2. Configure login: tea login add
# 3. Use Tea CLI: tea --help
```
## Integration with Setup Script
The Tea CLI installer is automatically integrated with the main Git repository setup script:
1. **Detection**: Checks for existing Tea CLI installations
2. **Offer Installation**: Prompts to install Tea CLI if none found
3. **Configuration**: Guides through login setup
4. **Repository Management**: Enables Gitea repository operations
## Security Features
- **Official Releases**: Downloads from official Gitea releases
- **Package Verification**: Uses official package repositories
- **Proper Permissions**: Sets appropriate file ownership and permissions
## Contributing
To add support for new distributions or architectures:
1. Update `detect_os()` function for new package managers
2. Add architecture detection in `get_arch()` function
3. Update installation methods in `install_tea_from_*()` functions
4. Test with target distribution
5. Update documentation
## License
This installer script follows the same license as Gitea Tea CLI (MIT).

View File

@@ -279,9 +279,6 @@ check_version_symlink() {
# Function to determine installation strategy
determine_install_strategy() {
local local_install="$1"
local current_info=$(get_current_version)
local current_version=$(echo "$current_info" | cut -d: -f1)
local install_type=$(echo "$current_info" | cut -d: -f2)
# Strategy: Check installation type preference
if [[ "$local_install" == "true" ]]; then
@@ -325,40 +322,6 @@ determine_install_strategy() {
print_status "This might take precedence if $USER_BIN_DIR is in PATH before system paths"
fi
fi
else
print_warning "Sudo not available, using user installation"
fi
# If not system install, check user bin
if [[ "$INSTALL_STRATEGY" != "system_install" ]]; then
print_status "No sudo access, checking user bin directory"
if check_user_bin_setup; then
print_status "User bin directory is available and in PATH"
# Check if borg exists in user bin
if [[ -f "$USER_BIN_DIR/borg" ]]; then
print_status "Borg CLI found in user bin directory"
# Check for version symlink
if check_version_symlink; then
print_status "Version symlink found: $CURRENT_SYMLINK_VERSION"
INSTALL_STRATEGY="user_update"
TARGET_DIR="$USER_BIN_DIR"
else
print_status "No version symlink found, will create one"
INSTALL_STRATEGY="user_upgrade"
TARGET_DIR="$USER_BIN_DIR"
fi
else
print_status "Borg CLI not found in user bin, will install there"
INSTALL_STRATEGY="user_install"
TARGET_DIR="$USER_BIN_DIR"
fi
else
print_error "Cannot install system-wide (no sudo) and user bin not available"
exit 1
fi
fi
print_status "Installation strategy: $INSTALL_STRATEGY"
print_status "Target directory: $TARGET_DIR"
@@ -418,7 +381,11 @@ install_borg_from_binary() {
fi
# Remove any existing borg symlink or file to avoid conflicts
rm -f "$TARGET_DIR/borg"
if [[ "$TARGET_DIR" == "$SYSTEM_INSTALL_DIR" ]]; then
sudo rm -f "$TARGET_DIR/borg"
else
rm -f "$TARGET_DIR/borg"
fi
# Create/update symlink to point to this version
$symlink_cmd "$TARGET_DIR/borg-$version" "$TARGET_DIR/borg"

View File

@@ -657,14 +657,21 @@ main() {
exit 1
fi
# Get latest version if not specified
if [[ -z "$target_version" ]]; then
get_latest_release
target_version="$LATEST_VERSION"
else
print_status "Using specified version: $target_version"
fi
# Create temporary directory
mkdir -p "$TEMP_DIR"
# Trap cleanup on exit
trap cleanup EXIT
# Installation logic based on method
case $install_method in
auto)
# Try package manager first
if install_from_package_manager; then
verify_installation
exit 0
fi
# Fall back to distribution-specific methods
case $OS in
ubuntu|debian|linuxmint)
@@ -687,6 +694,10 @@ main() {
tarball)
install_from_tarball "$ARCH" "$target_version"
;;
*)
print_error "Unknown install method: $install_method"
exit 1
;;
esac
# Verify installation