127 lines
4.8 KiB
Markdown

# Atlas AI Development Server
Atlas is a dedicated AI development server used as the primary Linux host for source code, automation, development tooling, operational scripts, and future application deployment work.
This repository is the authoritative infrastructure and operations source for Atlas. Its long-term purpose is to make the server rebuildable from a clean Ubuntu installation using documented, version-controlled, idempotent automation.
## Current Server Summary
The following facts are established for the current server:
- Hostname: `atlas`
- Operating system: Ubuntu 26.04 LTS
- Static IP address: `192.168.10.10`
- CPU: AMD Ryzen 7 2700
- Memory: 16 GB RAM
- OS storage: SSD using full-disk LVM, mounted at `/`
- SQL data volume: SSD mounted at `/sql`
- Development volume: SSD mounted at `/srv`
- Repository location: `/srv/repos/AI-Development-Server`
- Git remote: `git@git.catherinelynwood.com:atlas-bot/AI-Development-Server.git`
Do not add unverified server details to this repository. Use `TODO: Confirm during the relevant implementation phase.` where information is not yet established.
## Repository Purpose
This repository will contain:
- Atlas architecture and operating documentation.
- Server standards for scripts, services, configuration, deployment, and change control.
- Installation automation.
- Configuration templates.
- Operational scripts.
- Smoke tests and validation checks.
- Recovery and rebuild runbooks.
- Architecture Decision Records.
- Build history.
It must not contain secrets, passwords, tokens, private keys, live credentials, database backups, generated deployment artefacts, or local machine state.
## Design Principles
- Git is the source of truth for infrastructure and operational intent.
- Changes should be documented before they are automated.
- Installation scripts must be idempotent and safe to rerun.
- Manual server changes should be reduced over time and recorded when they occur.
- Source, build artefacts, deployed applications, data, backups, and temporary files must remain separate.
- Secrets must live outside the repository.
- Planned components must not be documented as installed until verified.
## Repository Layout
```text
.
├── README.md
├── SERVER-STANDARDS.md
├── docs/
│ ├── ARCHITECTURE.md
│ ├── BUILD-LOG.md
│ ├── REBUILD-GUIDE.md
│ ├── DISASTER-RECOVERY.md
│ ├── OPERATING-MODEL.md
│ └── adr/
├── install/
├── config/
├── scripts/
├── tests/
├── templates/
└── .gitignore
```
Directory-level README files explain what belongs in each working area.
## Installation Model
Installation framework files live under `install/`. Phase 2A adds shared Bash libraries and a bootstrap scaffold, but component installation has not begun.
Current commands:
```bash
install/bootstrap.sh --help
scripts/system/discover-system.sh
scripts/system/validate-host.sh
```
Future component installation scripts will live under `install/phases/`. They will be ordered, idempotent Bash scripts, for example:
```text
install/phases/10-dotnet.sh
install/phases/20-sql-server.sh
install/phases/30-nginx.sh
install/phases/40-docker.sh
```
These component scripts do not exist yet. Until they do, rebuild steps remain manual and are documented in [docs/REBUILD-GUIDE.md](docs/REBUILD-GUIDE.md).
Generated logs and reports belong outside the repository:
- Installer logs: `/var/log/atlas/install/`
- Discovery and validation reports: `/var/log/atlas/reports/`
- Future installer state and markers: `/var/lib/atlas/`
## Change Control
- Plan architecture and standards changes before implementation.
- Review diffs before committing.
- Run relevant validation before commit.
- Do not commit without explicit approval.
- Keep commits focused on one infrastructure outcome.
- Record meaningful operational changes in [docs/BUILD-LOG.md](docs/BUILD-LOG.md).
## Roadmap Summary
- Phase 1: Establish repository structure, standards, architecture documentation, rebuild guidance, disaster recovery guidance, operating model, and ADR process.
- Phase 2A: Add shared installer framework, system discovery, host validation, runtime directory conventions, and validation thresholds.
- Future phases: Add component installation scripts, configuration templates, operational scripts, smoke tests, backup automation, restore automation, deployment automation, and monitoring.
## Security Warning
Never commit secrets or credentials. This includes `.env` files, passwords, tokens, private keys, certificates, SQL backups, Codex authentication material, deployment credentials, and backup encryption keys.
Use templates, examples, placeholder names, and documented environment variable names instead.
## Rebuild and Recovery
- Rebuild procedure: [docs/REBUILD-GUIDE.md](docs/REBUILD-GUIDE.md)
- Disaster recovery: [docs/DISASTER-RECOVERY.md](docs/DISASTER-RECOVERY.md)