* wdclient: bound the wait for a master leader by the caller's context WithClient waited on GetMaster with context.Background(), so a caller that arrived while no master leader was known parked in a 200ms poll loop until one appeared, whatever deadline it had already set on the RPC. Each retry above it then left another goroutine in the same wait. Take the context in WithClient and WithClientCustomGetMaster and hand it to GetMaster, and stop the retry loop once it is done. The dial keeps context.Background(): fn brings its own RPC context, so a cancellation seen here cannot be attributed to the shared connection. Call sites pass whatever they hold: the request context in the filer's CollectionList, DeleteCollection and Statistics handlers and in the credential store's propagation, the operation context in the shell's s3.bucket.delete and the kafka gateway's broker and filer discovery, and context.Background() where there is none - the shell commands, the admin dashboard wrapper, and the exclusive locker's initial lease. The locker's release keeps its own uncancelled context so a slow unlock cannot turn into a ghost lock. Claude-Session: https://claude.ai/code/session_01BjDWtZsCoZY6x4pdDmGWxU * wdclient: test that WithClient gives up with the caller's context Claude-Session: https://claude.ai/code/session_01BjDWtZsCoZY6x4pdDmGWxU * wdclient: cut the master retry backoff short when the caller gives up util.Retry sleeps unconditionally between attempts, so a transient error arriving just before the caller's deadline still cost it a full backoff step. Use the context-aware util.RetryWithBackoff, the same helper the volume lookup in this file already uses. Two call sites went with it: the shell's lock-holder lookup builds its three second bound before WithClient so it also covers finding the leader, as its comment already promised, and the filer's post-delete collection cleanup goes back to an uncancelled context - the entry is already gone, so a caller that hung up must not leave the collection behind. Claude-Session: https://claude.ai/code/session_01BjDWtZsCoZY6x4pdDmGWxU * wdclient: test that a cancel during backoff ends the retry Claude-Session: https://claude.ai/code/session_01BjDWtZsCoZY6x4pdDmGWxU
Credential Store Integration
This document shows how the credential store has been integrated into SeaweedFS's S3 API and IAM API components.
Quick Start
-
Generate credential configuration:
weed scaffold -config=credential -output=. -
Edit credential.toml to enable your preferred store (filer_etc is enabled by default)
-
Start S3 API server - it will automatically load credential.toml:
weed s3 -filer=localhost:8888
Integration Overview
The credential store provides a pluggable backend for storing S3 identities and credentials, supporting:
- Filer-based storage (filer_etc) - Uses existing filer storage (default)
- PostgreSQL - Shared database for multiple servers
- Memory - In-memory storage for testing
Configuration
Using credential.toml
Generate the configuration template:
weed scaffold -config=credential
This creates a credential.toml file with all available options. The filer_etc store is enabled by default:
# Filer-based credential store (default, uses existing filer storage)
[credential.filer_etc]
enabled = true
# PostgreSQL credential store (recommended for multi-node deployments)
[credential.postgres]
enabled = false
hostname = "localhost"
port = 5432
username = "seaweedfs"
password = "your_password"
database = "seaweedfs"
# Memory credential store (for testing only, data is lost on restart)
[credential.memory]
enabled = false
The credential.toml file is automatically loaded from these locations (in priority order):
./credential.toml$HOME/.seaweedfs/credential.toml/etc/seaweedfs/credential.toml
Server Configuration
Both S3 API and IAM API servers automatically load credential.toml during startup. No additional configuration is required.
Usage Examples
Filer-based Store (Default)
[credential.filer_etc]
enabled = true
This uses the existing filer storage and is compatible with current deployments.
PostgreSQL Store
[credential.postgres]
enabled = true
hostname = "localhost"
port = 5432
username = "seaweedfs"
password = "your_password"
database = "seaweedfs"
schema = "public"
sslmode = "disable"
table_prefix = "sw_"
connection_max_idle = 10
connection_max_open = 100
connection_max_lifetime_seconds = 3600
Memory Store (Testing)
[credential.memory]
enabled = true
Environment Variables
All credential configuration can be overridden with environment variables:
# Override PostgreSQL password
export WEED_CREDENTIAL_POSTGRES_PASSWORD=secret
# Override PostgreSQL hostname
export WEED_CREDENTIAL_POSTGRES_HOSTNAME=db.example.com
# Enable/disable stores
export WEED_CREDENTIAL_FILER_ETC_ENABLED=true
Rules:
- Prefix with
WEED_CREDENTIAL_ - Convert to uppercase
- Replace
.with_
Implementation Details
Components automatically load credential configuration during startup:
// Server initialization
if credConfig, err := credential.LoadCredentialConfiguration(); err == nil && credConfig != nil {
credentialManager, err := credential.NewCredentialManager(
credConfig.Store,
credConfig.Config,
credConfig.Prefix,
)
if err != nil {
return nil, fmt.Errorf("failed to initialize credential manager: %v", err)
}
// Use credential manager for operations
}
Benefits
- Easy Configuration - Generate template with
weed scaffold -config=credential - Pluggable Storage - Switch between filer_etc, PostgreSQL without code changes
- Backward Compatibility - Filer-based storage works with existing deployments
- Scalability - Database stores support multiple concurrent servers
- Performance - Database access can be faster than file-based storage
- Testing - Memory store simplifies unit testing
- Environment Override - All settings can be overridden with environment variables
Error Handling
When a credential store is configured, it must initialize successfully or the server will fail to start:
if credConfig != nil {
credentialManager, err = credential.NewCredentialManager(...)
if err != nil {
return nil, fmt.Errorf("failed to initialize credential manager: %v", err)
}
}
This ensures explicit configuration - if you configure a credential store, it must work properly.