Consolidate 7 divisions to 3: Networking, Digital, Support
- Merge Infrastructure + Secure + Systems → SNS Networking (Business #1) - Merge Web + Software + Cloud → SNS Digital (planned) - SNS Support unchanged (planned) - Add infra/ folder with 16 FOSS-first buildable designs - Update all agent knowledge, division briefs, legal structure - Restructure businesses/ from 7 to 3 operating folders
This commit is contained in:
parent
55a80ce6e3
commit
b1a35783bb
@ -21,5 +21,5 @@ into results.
|
||||
|
||||
## Scope
|
||||
I serve the **holding company** and, through it, every operating subsidiary
|
||||
(`01-infrastructure` active; `02`–`07` as they launch). My job scales by adding
|
||||
specialists beneath me — my role and the chain of command never change.
|
||||
(`01-networking` active; `02-digital` and `03-support` as they launch). My job
|
||||
scales by adding specialists beneath me — my role and the chain of command never change.
|
||||
|
||||
@ -7,10 +7,11 @@ Durable facts and standing decisions. Daily working history lives in `memory/YYY
|
||||
James**. Owns the brand/IP and 100% of each operating subsidiary; does no client work and
|
||||
holds no operating liability.
|
||||
- **Operating subsidiaries** (one LLC each, formed as each begins real work):
|
||||
- `01-infrastructure` — **SNS Infrastructure LLC** — networking/cabling/wireless — **ACTIVE, Business #1**.
|
||||
- `02-secure`, `03-support`, `04-systems`, `05-cloud`, `06-web`, `07-software` — planned.
|
||||
- `01-networking` — **SNS Networking LLC** — physical networking, security, on-prem compute — **ACTIVE, Business #1**.
|
||||
- `02-digital` — **SNS Digital LLC** — code, cloud, web, hosting, apps — planned.
|
||||
- `03-support` — **SNS Support LLC** — managed services, RMM, SLAs — planned.
|
||||
- **Stage:** pre-revenue. Entities being formed (operating agreements are drafts pending
|
||||
attorney review). Focus is standing up SNS Infrastructure.
|
||||
attorney review). Focus is standing up SNS Networking.
|
||||
- **Brand promise:** Reliable Technology. Honest Recommendations. Professional Execution.
|
||||
- **Values:** Integrity, Excellence, Simplicity, Security, Stewardship.
|
||||
|
||||
|
||||
@ -10,8 +10,8 @@ The person I serve.
|
||||
|
||||
## What Sam is building
|
||||
A holding company that owns one operating subsidiary LLC per division. Business #1,
|
||||
**SNS Infrastructure LLC** (`01-infrastructure`), is the active focus; Secure, Support,
|
||||
Systems, Cloud, Web, and Software follow as each earns its launch. Current stage is
|
||||
**SNS Networking LLC** (`01-networking`), is the active focus; Digital and Support
|
||||
follow as each earns its launch. Current stage is
|
||||
**pre-revenue** — forming entities and standing up the first business.
|
||||
|
||||
## How Sam wants to be worked with
|
||||
@ -26,7 +26,7 @@ Systems, Cloud, Web, and Software follow as each earns its launch. Current stage
|
||||
now, AWS later) and cares what things cost.
|
||||
|
||||
## Sam's standing priorities
|
||||
1. Get SNS Infrastructure legally formed and operating self-sufficiently.
|
||||
1. Get SNS Networking legally formed and operating self-sufficiently.
|
||||
2. Keep the entity/liability structure clean (no commingling; approval gates hold).
|
||||
3. Build reproducible systems that move from `ws` to AWS unchanged.
|
||||
4. Only add capability (agents, tools, services) when the business actually needs it.
|
||||
|
||||
@ -9,29 +9,24 @@ clean. When a request or a business report comes in, I check it against these sc
|
||||
| # | Entity | Scope — what it does | Boundary — what it does NOT | Liability | Status |
|
||||
|---|--------|----------------------|-----------------------------|-----------|--------|
|
||||
| 00 | **SnS Network Solutions Holdings LLC** (parent) | Owns brand/IP + 100% of each subsidiary | No client work; no operating liability | None (by design) | — |
|
||||
| 01 | **SNS Infrastructure LLC** | Structured cabling, LAN/networking, wireless — the physical wire and foundation | Not cameras/security (Secure), not servers/OS (Systems), not cloud (Cloud) | High (physical/on-site) | **ACTIVE (Business #1)** |
|
||||
| 02 | **SNS Secure LLC** | Cameras, access control, alarms (physical security) **+** cybersecurity (audits, firewall, monitoring, incident response) | Not the base LAN (that's Infrastructure) | High (physical + cyber E&O) | Planned |
|
||||
| 03 | **SNS Support LLC** | Managed services, helpdesk, RMM, monitoring, SLAs — maintains what the others build. **ALL recurring/managed contracts live here** | Not net-new build (that's the builder division) | Med–High (SLA) | Planned |
|
||||
| 04 | **SNS Systems LLC** | On-prem servers, Linux, virtualization, on-prem compute/storage | Not the wire (Infra), not off-prem (Cloud), not ongoing management (Support) | Medium | Planned |
|
||||
| 05 | **SNS Cloud LLC** | AWS/Azure, hybrid, off-prem compute, migrations | Not on-prem (Systems); managed cloud is handed to Support | Medium | Planned |
|
||||
| 06 | **SNS Web LLC** | Websites, hosting, domains, digital presence | Managed hosting SLAs coordinate with Support | Low–Med | Planned |
|
||||
| 07 | **SNS Software LLC** | Custom apps, automation, integrations (client owns the code) | Not off-the-shelf resale | Medium | Planned |
|
||||
| 01 | **SNS Networking LLC** | Physical networking, cabling, wireless, security (cameras, access control, cyber), on-prem servers/virtualization/Linux — if it touches the network, protects it, or runs on-prem compute | Not cloud/off-prem (Digital), not recurring managed contracts (Support), not websites/apps/code (Digital) | High (physical + cyber E&O) | **ACTIVE (Business #1)** |
|
||||
| 02 | **SNS Digital LLC** | Cloud infrastructure (AWS/Azure), websites, hosting, custom software, automation, CI/CD — anything code, cloud, or web | Not physical/on-site work (Networking), not recurring managed contracts (Support) | Medium (professional E&O) | Planned |
|
||||
| 03 | **SNS Support LLC** | Managed services, helpdesk, RMM, monitoring, SLAs — maintains what Networking and Digital build. **ALL recurring/managed contracts live here** | Not net-new build (that's Networking or Digital) | Med–High (SLA) | Planned |
|
||||
|
||||
## Boundary rules (the lines I enforce)
|
||||
- **Build vs. maintain:** a division *builds*; **Support** *maintains*. Any recurring or
|
||||
managed contract belongs to Support — not the builder.
|
||||
- **Where the compute lives:** the wire = **Infrastructure** · on-prem servers = **Systems**
|
||||
· off-prem = **Cloud**.
|
||||
- **Security is its own entity:** cameras / access control / cyber = **Secure**, even on an
|
||||
Infrastructure job site.
|
||||
- **One job may touch several entities** — then it is **split**, and each part is scoped,
|
||||
- **Build vs. maintain:** Networking and Digital *build*; **Support** *maintains*. Any
|
||||
recurring or managed contract belongs to Support — not the builder.
|
||||
- **Physical vs. digital:** On-site work (wire, servers, cameras, firewalls) =
|
||||
**Networking**. Remote/code/cloud work (apps, websites, AWS) = **Digital**.
|
||||
- **One job may touch multiple entities** — then it is **split**, and each part is scoped,
|
||||
contracted, and billed under its own LLC. Never run one entity's work under another's name.
|
||||
|
||||
## Scope-bleed examples (catch and correct these)
|
||||
- A camera install being run under Infrastructure → belongs to **Secure**.
|
||||
- A "manage our network monthly" ask landing on Infrastructure → the managed part is **Support**.
|
||||
- A cloud migration filed under Systems → **Cloud**.
|
||||
- A hosting-with-SLA website job under Web → build is **Web**, the SLA/managed part is **Support**.
|
||||
- A "manage our network monthly" ask landing on Networking → the managed part is **Support**.
|
||||
- A cloud migration filed under Networking → belongs to **Digital**.
|
||||
- A hosting-with-SLA website job under Digital → build is **Digital**, the SLA/managed part is **Support**.
|
||||
- A camera install being scoped as Digital work → physical install belongs to **Networking**.
|
||||
- A client wanting a custom app + on-prem server → server is **Networking**, app is **Digital**.
|
||||
|
||||
## What each business reports on (when it reports)
|
||||
Work in progress · new requests/leads · blockers · anything crossing entity lines · anything
|
||||
|
||||
@ -15,9 +15,9 @@
|
||||
| Business Entity Report | ~$32 every 2 years, per entity |
|
||||
|
||||
## What $1,000 covers
|
||||
Comfortably: forming the **parent Holdings LLC** (~$95) and **SNS Infrastructure LLC** (~$95),
|
||||
Comfortably: forming the **parent Holdings LLC** (~$95) and **SNS Networking LLC** (~$95),
|
||||
with buffer for optional attorney review, a business bank account, and incidentals. It does
|
||||
**not** stretch to forming all seven subsidiaries at once — and it shouldn't (entities are
|
||||
**not** stretch to forming all three subsidiaries at once — and it shouldn't (entities are
|
||||
formed only as each begins real work).
|
||||
|
||||
## Rule for me (Chief)
|
||||
|
||||
@ -14,7 +14,7 @@ good ones. This is analysis for Sam's decision, not a green light.
|
||||
4. **Reality check:** who is the customer (ICP), do they actually have this problem, and
|
||||
will they pay for it?
|
||||
5. **Rough economics:** cost, effort, expected return, and **opportunity cost** vs. Sam's
|
||||
standing priority (stand up SNS Infrastructure first).
|
||||
standing priority (stand up SNS Networking first).
|
||||
6. **If pursue:** the single smallest next step — ideally a test doable inside ~7 days.
|
||||
|
||||
## Output
|
||||
|
||||
@ -8,8 +8,7 @@ Durable facts and standing standards. Working history lives in `projects/researc
|
||||
|
||||
## Business context (enough to make research relevant)
|
||||
- SnS Network Solutions is an Indiana **holding company** (South Bend / St. Joseph County)
|
||||
that owns operating subsidiaries: **Infrastructure** (active), plus Secure, Support,
|
||||
Systems, Cloud, Web, Software.
|
||||
that owns operating subsidiaries: **Networking** (active), plus Digital and Support.
|
||||
- Common research areas: Indiana business/licensing rules, vendor and pricing comparisons,
|
||||
competitors, tooling, and technology/regulatory questions relevant to those divisions.
|
||||
- Chief owns the full entity-scope detail; I just need enough context to research the right thing.
|
||||
|
||||
@ -50,7 +50,7 @@ for diagrams/tables, and a plain-language path for non-expert readers.
|
||||
alternative where needed.
|
||||
|
||||
## Entity scoping
|
||||
Documents belong to a specific SNS LLC (Infrastructure, Secure, etc.) or the Holdings parent.
|
||||
Documents belong to a specific SNS LLC (Networking, Digital, Support) or the Holdings parent.
|
||||
Chief tells me which; I keep that entity's name and details consistent and never mix entities in
|
||||
one binding document unless it's explicitly a multi-party document.
|
||||
|
||||
|
||||
@ -20,15 +20,11 @@ This is the parent company.
|
||||
|
||||
The parent company represents engineering excellence and serves as the umbrella organization for all future divisions.
|
||||
|
||||
Examples of future divisions include:
|
||||
The operating divisions are:
|
||||
|
||||
- SNS Infrastructure
|
||||
- SNS Secure
|
||||
- SNS Systems
|
||||
- SNS Software
|
||||
- SNS Web
|
||||
- SNS Cloud
|
||||
- SNS Support
|
||||
- SNS Networking — physical networking, security, on-prem compute
|
||||
- SNS Digital — code, cloud, web, hosting, apps
|
||||
- SNS Support — managed services, RMM, SLAs
|
||||
|
||||
The parent company should NEVER compete with its own divisions.
|
||||
|
||||
@ -382,26 +378,14 @@ From structured cabling and Cisco networking to Linux systems, managed services,
|
||||
|
||||
SnS Network Solutions
|
||||
|
||||
├── SNS Infrastructure
|
||||
(Networking, Cabling, Wireless)
|
||||
├── SNS Networking
|
||||
(Physical networking, cabling, wireless, security, on-prem servers/virtualization)
|
||||
|
||||
├── SNS Secure
|
||||
(Security Cameras, Access Control, Cyber Security)
|
||||
|
||||
├── SNS Systems
|
||||
(Linux, Servers, Virtualization, Managed Services)
|
||||
|
||||
├── SNS Software
|
||||
(Custom Business Applications)
|
||||
|
||||
├── SNS Web
|
||||
(Websites, Hosting, Digital Presence)
|
||||
|
||||
├── SNS Cloud
|
||||
(AWS, Azure, Hybrid Infrastructure)
|
||||
├── SNS Digital
|
||||
(Cloud infrastructure, websites, hosting, custom software, automation)
|
||||
|
||||
└── SNS Support
|
||||
(Managed Services)
|
||||
(Managed services, RMM, monitoring, SLAs)
|
||||
|
||||
---
|
||||
|
||||
|
||||
@ -11,8 +11,8 @@
|
||||
- **Isn't:** an operating business. It does **no client work**, has **no employees
|
||||
doing billable work**, and carries **no operating liability**. Keeping it that
|
||||
way (no commingling, no client contracts) is what keeps the liability shield intact.
|
||||
- **Owns:** `01-infrastructure` (SNS Infrastructure LLC, active) and — as each
|
||||
launches — `02-secure` … `07-software`.
|
||||
- **Owns:** `01-networking` (SNS Networking LLC, active) and — as each
|
||||
launches — `02-digital`, `03-support`.
|
||||
|
||||
## TODO → Form the Holding Company (do FIRST — see legal-structure.md Steps 1–3, 6)
|
||||
- [ ] Confirm name availability on INBiz: **SnS Network Solutions Holdings LLC**
|
||||
@ -24,7 +24,7 @@
|
||||
- [ ] (Optional) Assumed business name if trading publicly as "SnS Network Solutions"
|
||||
|
||||
## TODO → Own the Subsidiaries
|
||||
- [ ] For each subsidiary: record **Holdings LLC as sole member** in its operating agreement
|
||||
- [ ] For each subsidiary (Networking, Digital, Support): record **Holdings LLC as sole member** in its operating agreement
|
||||
- [ ] Keep parent and subsidiary funds strictly separate (no commingling)
|
||||
- [ ] Hold the brand, domain, and core IP at the parent level
|
||||
|
||||
|
||||
@ -3,13 +3,15 @@
|
||||
**Entity:** SnS Network Solutions Holdings LLC · **Accent:** Parent Cyan `#10C8D8`
|
||||
|
||||
The parent **holding company** — *not* an operating business. It owns the brand/IP
|
||||
and 100% of every subsidiary LLC (`01-infrastructure` … `07-software`), signs no
|
||||
client work, and carries no operating liability. That separation is what protects
|
||||
each subsidiary from the others' liability.
|
||||
and 100% of every subsidiary LLC, signs no client work, and carries no operating
|
||||
liability. That separation is what protects each subsidiary from the others' liability.
|
||||
|
||||
This is its working folder (master brand assets + holding-company setup). It sits
|
||||
**unnumbered** on purpose — it's the owner of the numbered operating subsidiaries,
|
||||
not one of them.
|
||||
**Subsidiaries owned:**
|
||||
- `01-networking` — SNS Networking LLC (active)
|
||||
- `02-digital` — SNS Digital LLC (planned)
|
||||
- `03-support` — SNS Support LLC (planned)
|
||||
|
||||
This is its working folder (master brand assets + holding-company setup).
|
||||
|
||||
- Setup checklist → [`00-sns-holding.md`](./00-sns-holding.md)
|
||||
- Master brand sheet + logo prompt → [`branding.html`](./branding.html)
|
||||
|
||||
@ -1,37 +0,0 @@
|
||||
# 01 · SNS Infrastructure — Scaffold / Research / TODO
|
||||
|
||||
**Status:** Business #1 — **ACTIVE** · **Tagline:** *The Physical Foundation*
|
||||
**Entity:** SNS Infrastructure LLC (operating subsidiary of SnS Network Solutions Holdings LLC)
|
||||
**Liability tier:** High (physical / on-site low-voltage work)
|
||||
**Signature accent:** Signal Blue `#1E6FFF` — see [`branding.html`](./branding.html)
|
||||
**Formal brief:** [`../../divisions/sns-infrastructure.md`](../../divisions/sns-infrastructure.md)
|
||||
|
||||
> This division is furthest along — its scaffold/research/todo already lives in the
|
||||
> files below. This page is the index that ties them together.
|
||||
|
||||
## Working Documents
|
||||
- [`../../divisions/sns-infrastructure.md`](../../divisions/sns-infrastructure.md) — formal brief / scope (in `divisions/`)
|
||||
- [`sns-infrastructure-hiring.md`](./sns-infrastructure-hiring.md) — operator hiring plan
|
||||
- [`operator-compensation-proposal.md`](./operator-compensation-proposal.md) — pay proposal
|
||||
- [`cash-flow-model.md`](./cash-flow-model.md) + [`cash-flow-model.csv`](./cash-flow-model.csv) — 12-month projection
|
||||
- [`branding-prompt.md`](./branding-prompt.md) — full logo prompt + variants
|
||||
- [`branding.html`](./branding.html) — color sheet + copy-ready logo prompt
|
||||
|
||||
## TODO → Launch (see [`../../divisions/legal-structure.md`](../../divisions/legal-structure.md))
|
||||
- [ ] Form SNS Infrastructure LLC on INBiz (owner: Holdings LLC)
|
||||
- [ ] EIN + subsidiary operating agreement (Holdings as sole member)
|
||||
- [ ] Business bank account (separate — protects the liability shield)
|
||||
- [ ] Insurance: general liability + workers' comp (field/low-voltage class codes)
|
||||
- [ ] Confirm South Bend / St. Joseph County low-voltage / cabling licensing
|
||||
- [ ] Secure the ~$65–80k loan runway (personal guarantee likely)
|
||||
- [ ] Hire the builder-operator; set up Field Nation / Work Market for labor
|
||||
- [ ] Vendor accounts (Graybar, ADI, Wesco/Anixter) + Fluke certifier
|
||||
- [ ] Finalize logo from the branding prompt (deliver true vector)
|
||||
|
||||
## Milestones
|
||||
Track build milestones here once the operator is onboarded and the plan is live
|
||||
(see hiring plan §11 "Standing On Its Own" for the trigger to start Business #2).
|
||||
|
||||
## Legal & Insurance
|
||||
Store formation docs, EIN letter, operating agreement, and insurance policies in a
|
||||
`legal/` folder here when this splits into its own repo.
|
||||
@ -1,3 +0,0 @@
|
||||
# SNS Infrastructure
|
||||
|
||||
See [`01-infrastructure.md`](./01-infrastructure.md) for scaffold, research, and TODO.
|
||||
77
businesses/01-networking/01-networking.md
Normal file
77
businesses/01-networking/01-networking.md
Normal file
@ -0,0 +1,77 @@
|
||||
# 01 · SNS Networking — Scaffold / Research / TODO
|
||||
|
||||
**Status:** Business #1 — **ACTIVE** · **Tagline:** *The Connected Foundation*
|
||||
**Entity:** SNS Networking LLC (operating subsidiary of SnS Network Solutions Holdings LLC)
|
||||
**Liability tier:** High (physical/on-site + cyber E&O)
|
||||
**Signature accent:** Signal Blue `#1E6FFF`
|
||||
**Formal brief:** [`../../divisions/sns-networking.md`](../../divisions/sns-networking.md)
|
||||
|
||||
> **Consolidates:** former Infrastructure + Secure + Systems divisions into one entity.
|
||||
> If it touches the network, protects the network, or runs on-prem compute — it's Networking.
|
||||
|
||||
## Scope
|
||||
|
||||
**Physical networking & cabling**
|
||||
- Structured cabling (Cat6/6A, fiber) and certification
|
||||
- Enterprise networking (Cisco, MikroTik, Ubiquiti) — routing, switching, VLANs
|
||||
- Wireless design, site surveys, Wi-Fi deployment
|
||||
- Rack build-outs, patch panels, cable management, labeling
|
||||
- Network documentation: IP schemes, rack diagrams, cable maps
|
||||
|
||||
**Security (physical + cyber)**
|
||||
- IP cameras (design, install, NVR/VMS), access control, alarms
|
||||
- Firewalls/UTM, VPN, network segmentation
|
||||
- Security audits, hardening, monitoring, incident response
|
||||
- Awareness training
|
||||
|
||||
**On-prem systems**
|
||||
- Linux server design, deployment, administration
|
||||
- Virtualization (Proxmox, KVM) and containers
|
||||
- Self-hosted infrastructure (identity, files, backups)
|
||||
- Storage, NAS/SAN, disaster-recovery design
|
||||
- Ansible automation for repeatable builds
|
||||
|
||||
## Boundary Rules
|
||||
|
||||
- **Build, don't maintain.** Project/build work lives here. Recurring managed contracts
|
||||
(SLAs, monthly monitoring, helpdesk) belong to **SNS Support**.
|
||||
- **Not cloud.** Off-prem compute (AWS, Azure, hosted) belongs to **SNS Digital**.
|
||||
- **Not software/web.** Custom apps, websites, and hosting belong to **SNS Digital**.
|
||||
|
||||
## Working Documents (carried from former Infrastructure)
|
||||
- [`sns-infrastructure-hiring.md`](./sns-infrastructure-hiring.md) — operator hiring plan
|
||||
- [`operator-compensation-proposal.md`](./operator-compensation-proposal.md) — pay proposal
|
||||
- [`cash-flow-model.md`](./cash-flow-model.md) + [`cash-flow-model.csv`](./cash-flow-model.csv) — 12-month projection
|
||||
- [`branding-prompt.md`](./branding-prompt.md) — logo prompt + variants
|
||||
|
||||
## TODO → Launch
|
||||
- [ ] Confirm name availability: **SNS Networking LLC** (or retain SNS Infrastructure LLC and file assumed name)
|
||||
- [ ] Form LLC on INBiz (owner: Holdings LLC) · EIN · operating agreement
|
||||
- [ ] Business bank account (separate from Holdings)
|
||||
- [ ] Insurance: general liability + cyber E&O + workers' comp (field/low-voltage class)
|
||||
- [ ] Confirm Indiana low-voltage / alarm / security licensing requirements
|
||||
- [ ] Secure the ~$65–80k loan runway (personal guarantee likely)
|
||||
- [ ] Hire the builder-operator; set up Field Nation / Work Market for labor
|
||||
- [ ] Vendor accounts (Graybar, ADI, Wesco/Anixter) + Fluke certifier
|
||||
- [ ] Finalize combined logo/branding for the consolidated entity
|
||||
|
||||
## TODO → Security Service Line (formerly SNS Secure)
|
||||
- [ ] Confirm Indiana alarm/security licensing — blocker for physical security work
|
||||
- [ ] Decide launch shape: physical-first, cyber-first, or both
|
||||
- [ ] Pick core product lines (cameras, access control, firewall/UTM vendors)
|
||||
- [ ] Draft pricing + service packages (project vs. monitoring handoff to Support)
|
||||
|
||||
## TODO → Systems Service Line (formerly SNS Systems)
|
||||
- [ ] Define standard reference builds (hypervisor, backup, identity, monitoring)
|
||||
- [ ] Build the Ansible baseline / IaC repo
|
||||
- [ ] Pricing: project builds vs. handoff-to-Support maintenance
|
||||
|
||||
## Milestones
|
||||
Track build milestones here once the operator is onboarded and the plan is live.
|
||||
|
||||
## Legal & Insurance
|
||||
- **Licensing flag:** Indiana may require a state license to sell/install/monitor
|
||||
burglar/fire/electronic security, access control, and CCTV — verify before physical
|
||||
security work.
|
||||
- Store formation docs, EIN letter, operating agreement, licenses, and insurance
|
||||
policies in `docs/` when this splits into its own repo.
|
||||
3
businesses/01-networking/README.md
Normal file
3
businesses/01-networking/README.md
Normal file
@ -0,0 +1,3 @@
|
||||
# SNS Networking
|
||||
|
||||
See [`01-networking.md`](./01-networking.md) for scaffold, research, and TODO.
|
||||
|
Before Width: | Height: | Size: 3.0 MiB After Width: | Height: | Size: 3.0 MiB |
|
Before Width: | Height: | Size: 2.8 MiB After Width: | Height: | Size: 2.8 MiB |
|
Before Width: | Height: | Size: 1.2 MiB After Width: | Height: | Size: 1.2 MiB |
68
businesses/02-digital/02-digital.md
Normal file
68
businesses/02-digital/02-digital.md
Normal file
@ -0,0 +1,68 @@
|
||||
# 02 · SNS Digital — Scaffold / Research / TODO
|
||||
|
||||
**Status:** Planned · **Tagline:** *Engineered for the Cloud*
|
||||
**Entity:** SNS Digital LLC (operating subsidiary of SnS Network Solutions Holdings LLC)
|
||||
**Liability tier:** Medium (professional E&O — all remote/keyboard work)
|
||||
**Signature accent:** Sky `#38BDF8`
|
||||
**Formal brief:** [`../../divisions/sns-digital.md`](../../divisions/sns-digital.md)
|
||||
|
||||
> **Consolidates:** former Web + Software + Cloud divisions into one entity.
|
||||
> If it's code, cloud, or a website — it's Digital.
|
||||
|
||||
## Scope
|
||||
|
||||
**Cloud infrastructure**
|
||||
- AWS/Azure architecture and deployment
|
||||
- Hybrid infrastructure (on-prem ↔ cloud) and migrations
|
||||
- Infrastructure-as-code, automation, CI/CD
|
||||
- Cloud networking, security, cost optimization
|
||||
- Backup, DR, business-continuity in the cloud
|
||||
|
||||
**Web & hosting**
|
||||
- Website design and development (open-source stacks)
|
||||
- Managed/self-hosted hosting and domains
|
||||
- Email and DNS setup
|
||||
- Performance, SEO fundamentals, accessibility compliance
|
||||
- Maintenance and content update workflows
|
||||
|
||||
**Custom software**
|
||||
- Custom web/business applications
|
||||
- Business process automation and internal tooling
|
||||
- API integrations between existing systems
|
||||
- Data pipelines, reporting, dashboards
|
||||
- Scripting/automation handed off with documentation
|
||||
|
||||
## Boundary Rules
|
||||
|
||||
- **Build, don't maintain.** Project/build work lives here. Recurring managed contracts
|
||||
(hosting SLAs, monitoring, helpdesk) belong to **SNS Support**.
|
||||
- **Not physical.** On-site networking, servers, cabling, security cameras belong to
|
||||
**SNS Networking**.
|
||||
- **IP terms matter.** The parent favors client code ownership (open-standards principle) —
|
||||
specify who owns delivered code in every contract.
|
||||
- **"SNS" collision.** Also = AWS Simple Notification Service — keep technical
|
||||
proposals/docs unambiguous.
|
||||
|
||||
## TODO → Plan
|
||||
- [ ] Define the standard tech stack: Hugo/static, WordPress (if forced), Docker Compose
|
||||
- [ ] Standardize IaC tooling (Terraform) + CI/CD baseline (Gitea Actions + KESTRA)
|
||||
- [ ] AWS landing-zone / account-structure templates
|
||||
- [ ] Standard contract with explicit IP/ownership + licensing terms — attorney review
|
||||
- [ ] Pricing models: project fixed-bid, time-and-materials, hosting/maintenance tiers
|
||||
- [ ] Accessibility (WCAG) baseline as standard deliverable for web work
|
||||
- [ ] Get E&O / professional liability insurance quotes
|
||||
- [ ] Finalize combined logo/branding
|
||||
|
||||
## TODO → Launch
|
||||
- [ ] Form SNS Digital LLC on INBiz (owner: Holdings LLC) · EIN · operating agreement
|
||||
- [ ] Separate business bank account
|
||||
- [ ] Bind E&O / professional liability insurance
|
||||
- [ ] Domain/DNS/email provisioning workflow
|
||||
|
||||
## Milestones
|
||||
_TBD — populate once the plan above is complete._
|
||||
|
||||
## Legal & Insurance
|
||||
- All professional/E&O liability. No physical premises risk.
|
||||
- Define cloud account ownership up front per client (client-owned preferred).
|
||||
- Store formation docs, client contracts (IP terms), and insurance in `docs/`.
|
||||
3
businesses/02-digital/README.md
Normal file
3
businesses/02-digital/README.md
Normal file
@ -0,0 +1,3 @@
|
||||
# SNS Digital
|
||||
|
||||
See [`02-digital.md`](./02-digital.md) for scaffold, research, and TODO.
|
||||
@ -1,38 +0,0 @@
|
||||
# 02 · SNS Secure — Scaffold / Research / TODO
|
||||
|
||||
**Status:** Planned · natural **Business #2** front-runner · **Tagline:** *Protected by Design*
|
||||
**Entity:** SNS Secure LLC (operating subsidiary of SnS Network Solutions Holdings LLC)
|
||||
**Liability tier:** **High** — highest combined exposure of any division (physical install + cyber E&O)
|
||||
**Signature accent:** Amber `#F5A623` — see [`branding.html`](./branding.html)
|
||||
**Formal brief:** [`../../divisions/sns-secure.md`](../../divisions/sns-secure.md)
|
||||
|
||||
## Scaffold / Research
|
||||
- **Two service lines, two risk profiles:**
|
||||
- *Physical* — IP cameras (design/install, NVR/VMS), access control, alarm/intrusion.
|
||||
- *Cyber* — audits, hardening, firewall/UTM, monitoring, incident response, training.
|
||||
- **Insurance is split:** general liability (physical install) **+** cyber errors & omissions (E&O). Different products.
|
||||
- **Licensing flag:** 2026 guidance suggests Indiana now requires a **state license to sell/install/monitor** burglar/fire/electronic security, access control, and CCTV — **verify before any physical work**.
|
||||
- **Possible future split:** *Secure (Physical)* vs. *Secure (Cyber)*.
|
||||
- Depends on **00-Infrastructure** as the network substrate; sells into the same client base.
|
||||
|
||||
## TODO → Plan (do before creating milestones)
|
||||
- [ ] Confirm Indiana alarm/security licensing requirements (state + local) — blocker for physical work
|
||||
- [ ] Decide launch shape: physical-first, cyber-first, or both
|
||||
- [ ] Get insurance quotes: GL **and** cyber E&O
|
||||
- [ ] Pick core product lines / vendor partners (cameras, access control, firewall/UTM)
|
||||
- [ ] Draft pricing + service packages (project vs. monitoring/recurring)
|
||||
- [ ] Define go-to-market (cross-sell from Infrastructure clients?)
|
||||
- [ ] Staffing: certified installer(s) + cyber skillset (or contractor model)
|
||||
- [ ] Finalize logo from [`branding.html`](./branding.html) prompt
|
||||
|
||||
## TODO → Launch (see [`../../divisions/legal-structure.md`](../../divisions/legal-structure.md))
|
||||
- [ ] Form SNS Secure LLC on INBiz (owner: Holdings LLC) · EIN · operating agreement
|
||||
- [ ] Separate business bank account
|
||||
- [ ] Bind GL + cyber E&O insurance
|
||||
- [ ] Obtain required security/alarm license(s)
|
||||
|
||||
## Milestones
|
||||
_TBD — populate once the plan above is complete._
|
||||
|
||||
## Legal & Insurance
|
||||
Store formation docs, licenses, and insurance policies in a `legal/` folder here.
|
||||
@ -1,3 +0,0 @@
|
||||
# SNS Secure
|
||||
|
||||
See [`02-secure.md`](./02-secure.md) for scaffold, research, and TODO.
|
||||
@ -1,28 +1,41 @@
|
||||
# 03 · SNS Support — Scaffold / Research / TODO
|
||||
|
||||
**Status:** Planned · natural **Business #2/#3** candidate · **Tagline:** *Always On*
|
||||
**Status:** Planned · natural **Business #2** candidate · **Tagline:** *Always On*
|
||||
**Entity:** SNS Support LLC (operating subsidiary of SnS Network Solutions Holdings LLC)
|
||||
**Liability tier:** **Medium–High** — SLA/contractual exposure + recurring revenue worth ring-fencing
|
||||
**Signature accent:** Orange `#F97316` — see [`branding.html`](./branding.html)
|
||||
**Liability tier:** Medium–High (SLA/contractual exposure + recurring revenue worth ring-fencing)
|
||||
**Signature accent:** Orange `#F97316`
|
||||
**Formal brief:** [`../../divisions/sns-support.md`](../../divisions/sns-support.md)
|
||||
|
||||
## Scaffold / Research
|
||||
- **The recurring-revenue engine** — maintains what every other division builds; where the brand's "long-term partnership" promise actually lives.
|
||||
- **Consolidation rule:** ALL managed-service contracts live here (pulling the overlaps out of Systems and Cloud). Systems/Cloud build; Support maintains.
|
||||
- **Services:** managed IT / helpdesk, RMM, patch management, backup monitoring + DR testing, SLA response/escalation, recurring health reporting.
|
||||
- **Main risks:** downtime and data-loss claims → SLA terms + E&O coverage are critical.
|
||||
- Turns one-time projects from all divisions into durable monthly relationships.
|
||||
## Scope
|
||||
|
||||
## TODO → Plan (do before creating milestones)
|
||||
The **recurring-revenue engine** — maintains what Networking and Digital build.
|
||||
Where the brand's "long-term partnership" promise actually lives.
|
||||
|
||||
**Services:**
|
||||
- Managed IT / helpdesk and remote monitoring (RMM)
|
||||
- Patch management and preventive maintenance
|
||||
- Backup monitoring and disaster-recovery testing
|
||||
- SLA-based response and escalation
|
||||
- Recurring documentation and health reporting
|
||||
- Monitoring, alerting, and uptime management
|
||||
|
||||
## Boundary Rules
|
||||
|
||||
- **Maintain, don't build.** Net-new build work (networking, cloud, apps) belongs to
|
||||
**Networking** or **Digital**. Support takes over after handoff.
|
||||
- **ALL recurring/managed contracts live here.** This is the single home for SLA-based
|
||||
work, regardless of which division built the original system.
|
||||
- Turns one-time projects from Networking and Digital into durable monthly relationships.
|
||||
|
||||
## TODO → Plan
|
||||
- [ ] Define SLA tiers (response/resolution times, coverage hours) + pricing per seat/device/site
|
||||
- [ ] Choose RMM + PSA/ticketing + backup/monitoring toolstack
|
||||
- [ ] Draft the managed-services agreement (SLA, liability caps, data handling) — attorney review
|
||||
- [ ] Choose RMM + PSA/ticketing + backup/monitoring toolstack (MeshCentral, Prometheus, PBS)
|
||||
- [ ] Draft managed-services agreement (SLA, liability caps, data handling) — attorney review
|
||||
- [ ] Decide staffing / after-hours coverage model (in-house vs. contracted NOC)
|
||||
- [ ] Map cross-sell handoff from Infrastructure/Systems/Cloud projects
|
||||
- [ ] Map cross-sell handoff from Networking and Digital projects
|
||||
- [ ] Get E&O insurance quotes
|
||||
- [ ] Finalize logo from [`branding.html`](./branding.html) prompt
|
||||
|
||||
## TODO → Launch (see [`../../divisions/legal-structure.md`](../../divisions/legal-structure.md))
|
||||
## TODO → Launch
|
||||
- [ ] Form SNS Support LLC on INBiz (owner: Holdings LLC) · EIN · operating agreement
|
||||
- [ ] Separate business bank account
|
||||
- [ ] Bind E&O + general liability insurance
|
||||
@ -31,4 +44,6 @@
|
||||
_TBD — populate once the plan above is complete._
|
||||
|
||||
## Legal & Insurance
|
||||
Store formation docs, client MSAs/SLAs, and insurance policies in a `legal/` folder here.
|
||||
- SLA commitments create contractual exposure; downtime and data-loss claims are the main risks.
|
||||
- Contracts and E&O coverage are critical.
|
||||
- Store formation docs, client MSAs/SLAs, and insurance policies in `docs/`.
|
||||
|
||||
@ -1,33 +0,0 @@
|
||||
# 04 · SNS Systems — Scaffold / Research / TODO
|
||||
|
||||
**Status:** Planned · **Tagline:** *Systems That Endure*
|
||||
**Entity:** SNS Systems LLC (operating subsidiary of SnS Network Solutions Holdings LLC)
|
||||
**Liability tier:** **Medium** — mostly configuration/professional work; E&O matters more than premises liability
|
||||
**Signature accent:** Emerald `#10B981` — see [`branding.html`](./branding.html)
|
||||
**Formal brief:** [`../../divisions/sns-systems.md`](../../divisions/sns-systems.md)
|
||||
|
||||
## Scaffold / Research
|
||||
- **The on-prem compute layer** — the clearest expression of the parent's open-source, Linux-first philosophy.
|
||||
- **Services:** Linux server design/admin, virtualization (Proxmox, KVM, VMware) + containers, self-hosted infra (mail, files, identity, backups), storage/NAS/SAN + DR design, Ansible automation for repeatable documented builds.
|
||||
- **Boundary line:** Systems = on-prem servers/OS/virtualization. Infrastructure = the wire/LAN. Cloud = off-prem compute.
|
||||
- **Managed work goes to Support**, not here — Systems builds, Support maintains.
|
||||
- Until active, can run as an assumed name of an existing operating sub or the parent.
|
||||
|
||||
## TODO → Plan (do before creating milestones)
|
||||
- [ ] Define standard reference builds (hypervisor stack, backup stack, identity, monitoring)
|
||||
- [ ] Build the Ansible baseline / IaC repo for repeatable deployments
|
||||
- [ ] Pricing: project builds vs. handoff-to-Support maintenance
|
||||
- [ ] Vendor/hardware sourcing (servers, storage) + open-source stack decisions
|
||||
- [ ] Get E&O insurance quotes
|
||||
- [ ] Finalize logo from [`branding.html`](./branding.html) prompt
|
||||
|
||||
## TODO → Launch (see [`../../divisions/legal-structure.md`](../../divisions/legal-structure.md))
|
||||
- [ ] Form SNS Systems LLC on INBiz (owner: Holdings LLC) · EIN · operating agreement
|
||||
- [ ] Separate business bank account
|
||||
- [ ] Bind E&O + general liability insurance
|
||||
|
||||
## Milestones
|
||||
_TBD — populate once the plan above is complete._
|
||||
|
||||
## Legal & Insurance
|
||||
Store formation docs and insurance policies in a `legal/` folder here.
|
||||
@ -1,3 +0,0 @@
|
||||
# SNS Systems
|
||||
|
||||
See [`04-systems.md`](./04-systems.md) for scaffold, research, and TODO.
|
||||
@ -1,78 +0,0 @@
|
||||
<!DOCTYPE html>
|
||||
<!-- SNS Systems — color scheme + logo prompt. Inherits parent brand (../../ai-core/knowledge/sns.md). -->
|
||||
<html lang="en">
|
||||
<head>
|
||||
<meta charset="UTF-8">
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1.0">
|
||||
<title>SNS Systems — Brand Sheet</title>
|
||||
<style>
|
||||
:root{--navy:#0A1628;--darkgray:#20252B;--white:#F6F7F9;--parent-cyan:#10C8D8;--accent:#10B981;/* Emerald */}
|
||||
*{box-sizing:border-box;margin:0;padding:0}
|
||||
body{background:var(--navy);color:var(--white);font-family:"IBM Plex Sans",Inter,system-ui,Arial,sans-serif;line-height:1.5;padding:48px 24px}
|
||||
.wrap{max-width:920px;margin:0 auto}
|
||||
h1{font-family:Oxanium,Sora,Rajdhani,system-ui,sans-serif;font-weight:700;font-size:2.2rem;letter-spacing:.5px}
|
||||
h1 .light{font-weight:300;color:var(--accent)}
|
||||
.tag{color:var(--parent-cyan);font-size:1.05rem;margin:4px 0}
|
||||
.accent-bar{height:6px;width:120px;background:var(--accent);border-radius:3px;margin:14px 0 32px}
|
||||
h2{font-family:Oxanium,Sora,sans-serif;font-weight:600;font-size:1.15rem;margin:34px 0 14px;text-transform:uppercase;letter-spacing:1.5px}
|
||||
.grid{display:grid;grid-template-columns:repeat(auto-fill,minmax(150px,1fr));gap:14px}
|
||||
.sw{border-radius:10px;overflow:hidden;border:1px solid rgba(255,255,255,.1)}
|
||||
.chip{height:88px}
|
||||
.meta{padding:10px 12px;background:var(--darkgray);font-size:.82rem}
|
||||
.meta b{display:block;font-size:.9rem;margin-bottom:2px}
|
||||
.hex{font-family:"IBM Plex Mono",monospace;color:var(--parent-cyan)}
|
||||
.signature{grid-column:1/-1}
|
||||
.signature .chip{height:120px;display:flex;align-items:flex-end;padding:12px}
|
||||
.signature .lbl{background:rgba(10,22,40,.55);color:#fff;padding:4px 10px;border-radius:6px;font-size:.8rem}
|
||||
.type{background:var(--darkgray);border-radius:10px;padding:18px 20px}
|
||||
.type p{margin:4px 0;font-size:.95rem}
|
||||
.promptbox{position:relative;background:#0d1a30;border:1px solid rgba(16,185,129,.4);border-radius:10px;padding:20px;margin-top:12px}
|
||||
pre{white-space:pre-wrap;font-family:"IBM Plex Mono",ui-monospace,monospace;font-size:.85rem;color:#dfe7f5}
|
||||
button{position:absolute;top:12px;right:12px;background:var(--accent);color:#06231a;border:0;padding:8px 14px;border-radius:6px;font-size:.8rem;cursor:pointer;font-weight:700}
|
||||
button:active{transform:translateY(1px)}
|
||||
</style>
|
||||
</head>
|
||||
<body>
|
||||
<div class="wrap">
|
||||
<h1>SNS <span class="light">Systems</span></h1>
|
||||
<div class="tag">Systems That Endure</div>
|
||||
<div class="accent-bar"></div>
|
||||
|
||||
<h2>Signature Accent</h2>
|
||||
<div class="grid">
|
||||
<div class="sw signature"><div class="chip" style="background:#10B981"><span class="lbl">Emerald <span class="hex">#10B981</span></span></div></div>
|
||||
</div>
|
||||
|
||||
<h2>Base Palette (constant across all SNS brands)</h2>
|
||||
<div class="grid">
|
||||
<div class="sw"><div class="chip" style="background:#0A1628"></div><div class="meta"><b>Primary Navy</b><span class="hex">#0A1628</span></div></div>
|
||||
<div class="sw"><div class="chip" style="background:#20252B"></div><div class="meta"><b>Dark Gray</b><span class="hex">#20252B</span></div></div>
|
||||
<div class="sw"><div class="chip" style="background:#F6F7F9"></div><div class="meta" style="color:#20252B;background:#F6F7F9"><b>White</b><span class="hex" style="color:#00A8C6">#F6F7F9</span></div></div>
|
||||
<div class="sw"><div class="chip" style="background:#10C8D8"></div><div class="meta"><b>Parent Cyan</b><span class="hex">#10C8D8</span></div></div>
|
||||
</div>
|
||||
|
||||
<h2>Typography</h2>
|
||||
<div class="type">
|
||||
<p><b>Display:</b> Oxanium / Sora / Rajdhani — geometric, "SNS" heavier.</p>
|
||||
<p><b>Body:</b> IBM Plex Sans / Inter — clean, highly legible.</p>
|
||||
<p><b>Rule:</b> flat, no gradients, works in 1-color, black & white, embroidery, laser, vinyl.</p>
|
||||
</div>
|
||||
|
||||
<h2>ChatGPT Logo Prompt</h2>
|
||||
<div class="promptbox">
|
||||
<button onclick="navigator.clipboard.writeText(document.getElementById('p').innerText)">Copy</button>
|
||||
<pre id="p">Design a minimal, geometric logo for "SNS Systems," a professional Linux server, virtualization, and systems-engineering company. Flat vector style, no gradients, no 3D, no shadows — clean, precise, architectural and timeless, like the mark of a serious engineering firm rather than consumer tech.
|
||||
|
||||
Symbol: an abstract geometric mark suggesting stable, enduring layered systems — precise stacked modular blocks forming a solid column or module, implying servers and durable infrastructure abstractly. Engineered, modular, and recognizable without text.
|
||||
|
||||
Color: deep navy #0A1628 as the primary, a single emerald accent #10B981, and white #F6F7F9. Two colors maximum. Must also read cleanly in solid one-color and in pure black-and-white.
|
||||
|
||||
Typography: pair the icon with a clean geometric sans-serif wordmark "SNS Systems" (in the style of Oxanium / Sora / IBM Plex Sans) — "SNS" heavier, "Systems" lighter.
|
||||
|
||||
Layout: horizontal lockup, icon left and wordmark right, on a plain flat background. High contrast, generous negative space, centered, logo-sheet presentation.
|
||||
|
||||
Avoid: literal server towers, penguins/Tux, computer monitors, terminals, gears, globes, lightning bolts, clip art, gradients, drop shadows, mascots, and generic IT imagery.</pre>
|
||||
</div>
|
||||
</div>
|
||||
</body>
|
||||
</html>
|
||||
@ -1,34 +0,0 @@
|
||||
# 05 · SNS Cloud — Scaffold / Research / TODO
|
||||
|
||||
**Status:** Planned · **Tagline:** *Infrastructure Without Limits*
|
||||
**Entity:** SNS Cloud LLC (operating subsidiary of SnS Network Solutions Holdings LLC)
|
||||
**Liability tier:** **Medium** — professional liability; client cloud spend + data handling create fiduciary/contractual responsibility
|
||||
**Signature accent:** Sky `#38BDF8` — see [`branding.html`](./branding.html)
|
||||
**Formal brief:** [`../../divisions/sns-cloud.md`](../../divisions/sns-cloud.md)
|
||||
|
||||
## Scaffold / Research
|
||||
- **The scale layer** — anything hosted off-premises; the scalable extension of SNS Systems.
|
||||
- **Services:** AWS/Azure architecture + deployment, hybrid (on-prem ↔ cloud) migration, IaC + CI/CD automation, cloud networking/security/cost optimization, backup/DR/business-continuity in the cloud.
|
||||
- **Boundary line:** Cloud = off-prem compute. Systems = on-prem. Infrastructure = the LAN/wire.
|
||||
- **Naming caution:** "SNS" also = **AWS Simple Notification Service** — keep technical proposals/docs unambiguous.
|
||||
- **Define account ownership** up front — who owns the client's cloud account (client-owned preferred, per open-standards principle).
|
||||
|
||||
## TODO → Plan (do before creating milestones)
|
||||
- [ ] Standardize IaC tooling (Terraform/CloudFormation) + CI/CD baseline
|
||||
- [ ] Define landing-zone / account-structure + security baseline templates
|
||||
- [ ] Pricing: project vs. managed cloud (coordinate managed with Support)
|
||||
- [ ] Decide primary platform focus (AWS-first per parent's stated preference)
|
||||
- [ ] Cost-optimization / billing-transparency offering
|
||||
- [ ] Get E&O insurance quotes
|
||||
- [ ] Finalize logo from [`branding.html`](./branding.html) prompt
|
||||
|
||||
## TODO → Launch (see [`../../divisions/legal-structure.md`](../../divisions/legal-structure.md))
|
||||
- [ ] Form SNS Cloud LLC on INBiz (owner: Holdings LLC) · EIN · operating agreement
|
||||
- [ ] Separate business bank account
|
||||
- [ ] Bind E&O + general liability insurance
|
||||
|
||||
## Milestones
|
||||
_TBD — populate once the plan above is complete._
|
||||
|
||||
## Legal & Insurance
|
||||
Store formation docs and insurance policies in a `legal/` folder here.
|
||||
@ -1,3 +0,0 @@
|
||||
# SNS Cloud
|
||||
|
||||
See [`05-cloud.md`](./05-cloud.md) for scaffold, research, and TODO.
|
||||
@ -1,33 +0,0 @@
|
||||
# 06 · SNS Web — Scaffold / Research / TODO
|
||||
|
||||
**Status:** Planned · **Tagline:** *Your Presence, Engineered*
|
||||
**Entity:** SNS Web LLC (operating subsidiary of SnS Network Solutions Holdings LLC)
|
||||
**Liability tier:** **Low–Medium** — mainly professional liability; uptime/SLA terms if hosting
|
||||
**Signature accent:** Magenta `#EC4899` — see [`branding.html`](./branding.html)
|
||||
**Formal brief:** [`../../divisions/sns-web.md`](../../divisions/sns-web.md)
|
||||
|
||||
## Scaffold / Research
|
||||
- **The public-facing layer** — websites/hosting/presence treated as engineered infrastructure, not disposable design work. Often the **entry-point service** that leads clients toward Infrastructure, Systems, or Support.
|
||||
- **Services:** site design/dev (favor open-source stacks), managed/self-hosted hosting + domains, email/DNS, performance + SEO fundamentals + **accessibility compliance**, maintenance/content workflows.
|
||||
- Hosting introduces recurring-revenue + data-responsibility → **coordinate managed hosting SLAs with SNS Support**.
|
||||
- Lowest liability of the divisions — a candidate for early, low-risk revenue.
|
||||
|
||||
## TODO → Plan (do before creating milestones)
|
||||
- [ ] Pick the standard open-source stack (CMS/static/framework) + hosting model
|
||||
- [ ] Define packages: build-only vs. build + managed hosting/maintenance
|
||||
- [ ] Accessibility (WCAG) baseline as a standard deliverable
|
||||
- [ ] Pricing + recurring hosting/maintenance tiers (coordinate with Support)
|
||||
- [ ] Domain/DNS/email provisioning workflow
|
||||
- [ ] Get professional liability insurance quotes
|
||||
- [ ] Finalize logo from [`branding.html`](./branding.html) prompt
|
||||
|
||||
## TODO → Launch (see [`../../divisions/legal-structure.md`](../../divisions/legal-structure.md))
|
||||
- [ ] Form SNS Web LLC on INBiz (owner: Holdings LLC) · EIN · operating agreement
|
||||
- [ ] Separate business bank account
|
||||
- [ ] Bind professional liability insurance
|
||||
|
||||
## Milestones
|
||||
_TBD — populate once the plan above is complete._
|
||||
|
||||
## Legal & Insurance
|
||||
Store formation docs and insurance policies in a `legal/` folder here.
|
||||
@ -1,3 +0,0 @@
|
||||
# SNS Web
|
||||
|
||||
See [`06-web.md`](./06-web.md) for scaffold, research, and TODO.
|
||||
@ -1,32 +0,0 @@
|
||||
# 07 · SNS Software — Scaffold / Research / TODO
|
||||
|
||||
**Status:** Planned · **Tagline:** *Software Engineered to Fit*
|
||||
**Entity:** SNS Software LLC (operating subsidiary of SnS Network Solutions Holdings LLC)
|
||||
**Liability tier:** **Medium** — professional liability / E&O; IP ownership + licensing terms matter
|
||||
**Signature accent:** Violet `#7C5CFC` — see [`branding.html`](./branding.html)
|
||||
**Formal brief:** [`../../divisions/sns-software.md`](../../divisions/sns-software.md)
|
||||
|
||||
## Scaffold / Research
|
||||
- **The problem-solving layer** — custom business applications + automation built to solve a specific client problem; not off-the-shelf products resold.
|
||||
- **Services:** custom web/business apps, business-process automation + internal tooling, API integrations between existing systems, data pipelines/reporting/dashboards, scripting/automation handed off with documentation.
|
||||
- **IP terms are the key contract issue:** the parent favors **client code ownership** (open-standards principle) — specify who owns delivered code in every contract.
|
||||
- Until active, can run as an assumed name of an existing operating sub.
|
||||
|
||||
## TODO → Plan (do before creating milestones)
|
||||
- [ ] Define the standard stack + delivery process (repos, CI/CD, handoff docs)
|
||||
- [ ] Standard contract with explicit IP/ownership + licensing terms — attorney review
|
||||
- [ ] Pricing model: fixed-bid vs. time-and-materials vs. retainer
|
||||
- [ ] Decide scope guardrails (avoid open-ended custom builds without change control)
|
||||
- [ ] Get E&O / professional liability insurance quotes
|
||||
- [ ] Finalize logo from [`branding.html`](./branding.html) prompt
|
||||
|
||||
## TODO → Launch (see [`../../divisions/legal-structure.md`](../../divisions/legal-structure.md))
|
||||
- [ ] Form SNS Software LLC on INBiz (owner: Holdings LLC) · EIN · operating agreement
|
||||
- [ ] Separate business bank account
|
||||
- [ ] Bind E&O / professional liability insurance
|
||||
|
||||
## Milestones
|
||||
_TBD — populate once the plan above is complete._
|
||||
|
||||
## Legal & Insurance
|
||||
Store formation docs, client contracts (IP terms), and insurance policies in a `legal/` folder here.
|
||||
@ -1,3 +0,0 @@
|
||||
# SNS Software
|
||||
|
||||
See [`07-software.md`](./07-software.md) for scaffold, research, and TODO.
|
||||
@ -2,8 +2,7 @@
|
||||
|
||||
The **parent holding company** plus its **operating subsidiaries**. `divisions/`
|
||||
holds the formal one-page briefs; the working scaffold, research, todo, branding,
|
||||
and (later) milestones live here. Each subsidiary is a self-contained unit that can
|
||||
lift out into its own repo (with its own `legal/` folder) when it launches.
|
||||
and (later) milestones live here.
|
||||
|
||||
## Parent (holding company — not an operating business)
|
||||
|
||||
@ -11,18 +10,26 @@ lift out into its own repo (with its own `legal/` folder) when it launches.
|
||||
|--------|--------|--------|------|
|
||||
| [`00-sns-holding/`](./00-sns-holding/) | SnS Network Solutions Holdings LLC | Parent Cyan `#10C8D8` | Owns the brand + 100% of every subsidiary; no client work, no operating liability |
|
||||
|
||||
## Operating subsidiaries (numbered by importance)
|
||||
## Operating subsidiaries
|
||||
|
||||
| # | Business | Tagline | Accent | Status |
|
||||
|---|----------|---------|--------|--------|
|
||||
| [01](./01-infrastructure/) | SNS Infrastructure | The Physical Foundation | Signal Blue `#1E6FFF` | **Active** |
|
||||
| [02](./02-secure/) | SNS Secure | Protected by Design | Amber `#F5A623` | Planned |
|
||||
| [03](./03-support/) | SNS Support | Always On | Orange `#F97316` | Planned |
|
||||
| [04](./04-systems/) | SNS Systems | Systems That Endure | Emerald `#10B981` | Planned |
|
||||
| [05](./05-cloud/) | SNS Cloud | Infrastructure Without Limits | Sky `#38BDF8` | Planned |
|
||||
| [06](./06-web/) | SNS Web | Your Presence, Engineered | Magenta `#EC4899` | Planned |
|
||||
| [07](./07-software/) | SNS Software | Software Engineered to Fit | Violet `#7C5CFC` | Planned |
|
||||
| # | Business | Tagline | Accent | Combines (former divisions) | Status |
|
||||
|---|----------|---------|--------|----------------------------|--------|
|
||||
| [01](./01-networking/) | SNS Networking | The Connected Foundation | Signal Blue `#1E6FFF` | Infrastructure + Secure + Systems | **Active** |
|
||||
| [02](./02-digital/) | SNS Digital | Engineered for the Cloud | Sky `#38BDF8` | Web + Software + Cloud | Planned |
|
||||
| [03](./03-support/) | SNS Support | Always On | Orange `#F97316` | Unchanged | Planned |
|
||||
|
||||
Each folder contains: a scaffold/todo doc, a `branding.html` color sheet + logo
|
||||
prompt, a `branding/` assets folder, and a `README.md`. Milestones get added once
|
||||
the plan is set.
|
||||
## Why 3 instead of 7
|
||||
|
||||
- **Networking** covers everything physical + on-prem: same job site, same skill set,
|
||||
same insurance pool (GL + cyber E&O). Cabling, firewalls, cameras, and servers are
|
||||
one delivery team.
|
||||
- **Digital** covers everything remote/code/cloud: same delivery model (keyboard, not
|
||||
ladder), same insurance category (professional E&O). Cloud infra, websites, and
|
||||
custom apps are one team.
|
||||
- **Support** stays separate: it's the only division with recurring-revenue SLAs and a
|
||||
different contract structure (ongoing responsibility vs. project-and-done).
|
||||
|
||||
## Folder contents
|
||||
|
||||
Each folder contains: a scaffold/todo doc, branding assets, and working documents.
|
||||
Milestones get added once the plan is set.
|
||||
|
||||
@ -13,72 +13,58 @@ real billable work** — not all at once (per-entity bookkeeping is the real cos
|
||||
|
||||
**Formal documents in this folder:**
|
||||
- [`sns-network-solutions.md`](./sns-network-solutions.md) — parent company brief
|
||||
- [`sns-infrastructure.md`](./sns-infrastructure.md) + the six division briefs below
|
||||
- [`sns-networking.md`](./sns-networking.md), [`sns-digital.md`](./sns-digital.md), [`sns-support.md`](./sns-support.md) — division briefs
|
||||
- [`legal-structure.md`](./legal-structure.md) — Indiana holding-company formation plan
|
||||
- [`investment-research.md`](./investment-research.md) — owner investment research (reference)
|
||||
|
||||
> Full brand foundation lives at [`../ai-core/knowledge/sns.md`](../ai-core/knowledge/sns.md); working scaffold, branding,
|
||||
> and milestones live under [`../businesses/`](../businesses/).
|
||||
|
||||
> **Status:** **SNS Infrastructure is Business #1 and now lives in its own folder:
|
||||
> [`../businesses/01-infrastructure/`](../businesses/01-infrastructure/).** The owner
|
||||
> will stand it up and get it running self-sufficiently — intentionally kept
|
||||
> right-sized, not scaled aggressively — before starting Business #2.
|
||||
> **Status:** **SNS Networking is Business #1 and lives in:
|
||||
> [`../businesses/01-networking/`](../businesses/01-networking/).** The owner
|
||||
> will stand it up and get it running self-sufficiently before starting Business #2.
|
||||
|
||||
---
|
||||
|
||||
## Division Index
|
||||
|
||||
**Launch order is sequential and owner-chosen — one business at a time.**
|
||||
Business #1 is **SNS Infrastructure** (active). When it stands on its own, the
|
||||
owner selects Business #2. The **liability tier** below is a *separate* signal: it
|
||||
tells you how urgently each division needs its own LLC *once launched* (and
|
||||
suggests a sensible order), but it is **not** a committed launch sequence.
|
||||
Business #1 is **SNS Networking** (active). When it stands on its own, the
|
||||
owner selects Business #2.
|
||||
|
||||
| Order | Division | Entity | Focus | Tagline | Liability Tier |
|
||||
|-------|----------|--------|-------|---------|----------------|
|
||||
| **#1 — ACTIVE** | [SNS Infrastructure](./sns-infrastructure.md) | SNS Infrastructure LLC | Networking, cabling, wireless | *The Physical Foundation* | High (physical/on-site) |
|
||||
| #2+ (TBD) | [SNS Secure](./sns-secure.md) | SNS Secure LLC | Cameras, access control, cyber | *Protected by Design* | High (physical + cyber E&O) |
|
||||
| #2+ (TBD) | [SNS Support](./sns-support.md) | SNS Support LLC | Managed services | *Always On* | Medium–High (SLA) |
|
||||
| #2+ (TBD) | [SNS Systems](./sns-systems.md) | SNS Systems LLC | Linux, servers, virtualization | *Systems That Endure* | Medium |
|
||||
| #2+ (TBD) | [SNS Cloud](./sns-cloud.md) | SNS Cloud LLC | AWS, Azure, hybrid | *Infrastructure Without Limits* | Medium |
|
||||
| #2+ (TBD) | [SNS Web](./sns-web.md) | SNS Web LLC | Sites, hosting, presence | *Your Presence, Engineered* | Low–Medium |
|
||||
| #2+ (TBD) | [SNS Software](./sns-software.md) | SNS Software LLC | Custom applications | *Software Engineered to Fit* | Medium |
|
||||
|
||||
When the owner does pick Business #2, the higher liability tiers (Secure, Support)
|
||||
are the natural front-runners — but that's a suggestion, not a commitment. Full
|
||||
rationale in [`legal-structure.md`](./legal-structure.md).
|
||||
| # | Division | Entity | Combines | Focus | Tagline | Liability |
|
||||
|---|----------|--------|----------|-------|---------|-----------|
|
||||
| **01 — ACTIVE** | [SNS Networking](./sns-networking.md) | SNS Networking LLC | Infra + Secure + Systems | Physical networking, security, on-prem compute | *The Connected Foundation* | High |
|
||||
| 02 (TBD) | [SNS Digital](./sns-digital.md) | SNS Digital LLC | Web + Software + Cloud | Code, cloud, websites, hosting, custom apps | *Engineered for the Cloud* | Medium |
|
||||
| 03 (TBD) | [SNS Support](./sns-support.md) | SNS Support LLC | — | Managed services, RMM, SLAs | *Always On* | Medium–High |
|
||||
|
||||
---
|
||||
|
||||
## Boundary Notes (resolve before launch)
|
||||
## Why 3 Divisions (Not 7)
|
||||
|
||||
These divisions overlap in the source brand doc and need clear service lines so
|
||||
they don't compete internally:
|
||||
The original 7-division model over-segmented for a pre-revenue solo operation.
|
||||
The consolidation groups by:
|
||||
|
||||
- **Managed Services** appears under *Systems*, *Support*, and *Cloud*. Consolidate
|
||||
all recurring/managed-service contracts under **SNS Support** as the single
|
||||
"always-on" revenue engine; Systems and Cloud deliver project/build work that
|
||||
Support then maintains.
|
||||
- **SNS Secure** blends physical security (cameras, access control — low-voltage
|
||||
install) and cybersecurity (audits, monitoring, hardening) — different
|
||||
insurance, licensing, and liability. Consider a future split into
|
||||
*Secure (Physical)* and *Secure (Cyber)*.
|
||||
- **Cloud vs. Systems vs. Infrastructure** — draw the line at where compute lives:
|
||||
Infrastructure = the wire and the LAN, Systems = on-prem servers/OS/virtualization,
|
||||
Cloud = anything hosted off-prem.
|
||||
- **Delivery model:** Networking = on-site/physical. Digital = remote/keyboard. Support = ongoing/recurring.
|
||||
- **Insurance pool:** Networking = GL + cyber E&O + workers' comp. Digital = professional E&O only. Support = E&O + SLA contractual.
|
||||
- **Skill set:** Each division is one team, not fragments of work that share a job site.
|
||||
|
||||
---
|
||||
|
||||
## Boundary Rules
|
||||
|
||||
- **Build vs. maintain:** Networking and Digital *build*; **Support** *maintains*.
|
||||
Any recurring/managed contract belongs to Support — not the builder.
|
||||
- **Physical vs. digital:** On-site work (wire, servers, cameras) = **Networking**.
|
||||
Remote/code/cloud work = **Digital**.
|
||||
- **One job may touch multiple entities** — split it, scope each part under its own LLC.
|
||||
|
||||
---
|
||||
|
||||
## Brand Inheritance (all divisions)
|
||||
|
||||
- **Colors:** Navy `#0A1628`, Cyan `#10C8D8`, Secondary Blue `#00A8C6`, Accent `#4CE0D2`, White `#F6F7F9`, Dark Gray `#20252B`
|
||||
- **Accent-per-division system:** one shared identity; each business keeps the navy
|
||||
base and gets a signature accent — parent = Cyan `#10C8D8`, Infrastructure =
|
||||
Signal Blue `#1E6FFF`, Secure = Amber, Systems = Emerald, Software = Violet, Web =
|
||||
Magenta, Cloud = Sky, Support = Orange. Each business's `branding.html`
|
||||
(color sheet + logo prompt) and `branding-prompt.md` carry its signature accent —
|
||||
see [`../businesses/`](../businesses/).
|
||||
- **Per-division accents:** Networking = Signal Blue `#1E6FFF`, Digital = Sky `#38BDF8`, Support = Orange `#F97316`
|
||||
- **Type:** Geometric, legible open-source fonts (IBM Plex Sans / Inter for body; Oxanium / Sora / Rajdhani for display)
|
||||
- **Voice:** Professional, clear, educational, transparent — never flashy or sales-driven
|
||||
- **Logo lockup:** `SNS` wordmark + division descriptor (endorsed sub-brand — the parent brand always shows; a subsidiary never gets a standalone logo that hides SnS)
|
||||
- **Logo lockup:** `SNS` wordmark + division descriptor (endorsed sub-brand — the parent brand always shows)
|
||||
|
||||
@ -17,33 +17,31 @@ separate operating LLC for each division.
|
||||
```
|
||||
SnS Network Solutions Holdings LLC ← parent; owns the brand + all subsidiaries,
|
||||
│ signs no client work, holds no operating liability
|
||||
├── SNS Infrastructure LLC ← Business #1 (ACTIVE — owner's chosen first business)
|
||||
├── SNS Secure LLC (High liability — physical install + cyber E&O)
|
||||
├── SNS Support LLC (Med–High — SLA/recurring-revenue)
|
||||
├── SNS Systems LLC ┐
|
||||
├── SNS Cloud LLC │ formed when each becomes an active business
|
||||
├── SNS Web LLC │ (lower liability)
|
||||
└── SNS Software LLC ┘
|
||||
├── SNS Networking LLC ← Business #1 (ACTIVE) — physical networking, security, on-prem
|
||||
├── SNS Digital LLC ← Business #2 (planned) — code, cloud, web, hosting, apps
|
||||
└── SNS Support LLC ← Business #3 (planned) — managed services, RMM, SLAs
|
||||
```
|
||||
|
||||
**Why 3 instead of 7:** The original 7-division model over-segmented for a pre-revenue
|
||||
solo operation. Consolidation groups by delivery model (physical / digital / recurring),
|
||||
insurance pool, and skill set. Each division is one team, not fragments.
|
||||
|
||||
**Launch order vs. liability tier — two different things:**
|
||||
- **Launch order** is the owner's choice, one business at a time. **Business #1 is
|
||||
SNS Infrastructure** (active); Business #2 is chosen once #1 stands on its own.
|
||||
SNS Networking** (active); Business #2 is chosen once #1 stands on its own.
|
||||
- **Liability tier** signals how urgently a division needs its own LLC *once
|
||||
launched* and suggests a sensible order for later businesses — it is **not** the
|
||||
launch sequence.
|
||||
launched* — it is **not** the launch sequence.
|
||||
|
||||
**How it protects you:** each operating LLC's liability is walled off from the
|
||||
others and from the parent. The parent owns the subsidiaries (and the brand/IP)
|
||||
but does no client work, so a lawsuit against one division can't reach the assets
|
||||
of another division or the parent.
|
||||
|
||||
### Do NOT form all 7 subsidiaries on day one
|
||||
### Do NOT form all 3 subsidiaries on day one
|
||||
Indiana's per-entity fees are cheap, but each LLC still needs its own **bank
|
||||
account, bookkeeping, and tax prep** — that's the real cost. Form the **parent +
|
||||
your first operating subsidiary now**, then add one subsidiary each time a
|
||||
division begins doing real, billable work. The holding structure is built to
|
||||
grow this way.
|
||||
division begins doing real, billable work.
|
||||
|
||||
---
|
||||
|
||||
@ -53,8 +51,7 @@ Legend: 🌐 = fully online · 🏦 = may require phone/branch · 📄 = interna
|
||||
|
||||
### 1. Pre-filing prep — 🌐
|
||||
- Search your names on INBiz to confirm availability: **SnS Network Solutions
|
||||
Holdings LLC** and your first subsidiary, **SNS Infrastructure LLC** (Business #1).
|
||||
- Decide which division launches first (that's your first operating subsidiary).
|
||||
Holdings LLC** and your first subsidiary, **SNS Networking LLC** (Business #1).
|
||||
- Decide registered agent: **yourself at your South Bend address = free**, or a
|
||||
service ($100–300/yr). One agent can cover all entities.
|
||||
- **Fee:** $0 · **Time:** ~1 hour
|
||||
@ -68,7 +65,7 @@ Legend: 🌐 = fully online · 🏦 = may require phone/branch · 📄 = interna
|
||||
- IRS online EIN Assistant (irs.gov). Free, issued immediately.
|
||||
- **Fee:** **$0** · **Time:** ~15 min
|
||||
|
||||
### 4. Form your first operating subsidiary — "SNS Infrastructure LLC" (Business #1) — 🌐
|
||||
### 4. Form your first operating subsidiary — "SNS Networking LLC" (Business #1) — 🌐
|
||||
- File Articles of Organization on INBiz.
|
||||
- **Ownership:** the member/owner is **SnS Network Solutions Holdings LLC** — this
|
||||
is what makes it a subsidiary. (Recorded in the operating agreement, Step 6.)
|
||||
@ -101,8 +98,9 @@ Legend: 🌐 = fully online · 🏦 = may require phone/branch · 📄 = interna
|
||||
- **Fee:** $0–25 · **Time:** ~1 day per account
|
||||
|
||||
### 9. Insurance — 🏦
|
||||
- General liability + professional/E&O for each operating sub; **cyber liability**
|
||||
for Secure and Support.
|
||||
- **SNS Networking:** General liability + cyber E&O + workers' comp (field/low-voltage).
|
||||
- **SNS Digital:** Professional E&O.
|
||||
- **SNS Support:** E&O + general liability (SLA contractual coverage).
|
||||
- Requires quotes (not instant/online).
|
||||
- **Fee:** varies (~$500–2,000+/yr per policy) · **Time:** a few days to quote/bind
|
||||
|
||||
@ -110,8 +108,8 @@ Legend: 🌐 = fully online · 🏦 = may require phone/branch · 📄 = interna
|
||||
- If collecting sales tax, hiring, or withholding: file **BT-1** on INBiz
|
||||
(**~$25** for a Registered Retail Merchant Certificate).
|
||||
- Check **City of South Bend** and **St. Joseph County** for any local business
|
||||
registration and **low-voltage/alarm licensing** before SNS Secure or SNS
|
||||
Infrastructure does physical work (see notes below).
|
||||
registration and **low-voltage/alarm licensing** before SNS Networking does
|
||||
physical security work.
|
||||
- **Fee:** ~$25 (BT-1 if needed) + local · **Time:** varies
|
||||
|
||||
---
|
||||
@ -134,11 +132,6 @@ Legend: 🌐 = fully online · 🏦 = may require phone/branch · 📄 = interna
|
||||
**~1–2 weeks** end-to-end including bank accounts and operating agreements
|
||||
(longer if you have an attorney draft the agreements).
|
||||
|
||||
**Can it all be done online?** **Yes for every government filing** — formation,
|
||||
EINs, assumed names, BT-1, and biennial reports all run through INBiz + IRS.
|
||||
Only the bank accounts and insurance may need a phone call or branch visit, and
|
||||
the operating agreements are internal documents you (or your attorney) prepare.
|
||||
|
||||
---
|
||||
|
||||
## Ongoing Compliance (per entity)
|
||||
@ -156,21 +149,17 @@ the operating agreements are internal documents you (or your attorney) prepare.
|
||||
## Launch Order & Liability Tiers
|
||||
|
||||
**Launch order (owner's choice — one business at a time):**
|
||||
1. **SNS Infrastructure — Business #1 (ACTIVE).** Networking/cabling/wireless; see
|
||||
[`businesses/01-infrastructure/`](../businesses/01-infrastructure/).
|
||||
1. **SNS Networking — Business #1 (ACTIVE).** Physical networking, security, on-prem;
|
||||
see [`../businesses/01-networking/`](../businesses/01-networking/).
|
||||
2. **Business #2+ — TBD.** Chosen once Business #1 stands on its own.
|
||||
|
||||
**Liability tiers (how urgently each needs its own LLC once launched — a separate
|
||||
signal from launch order, and a suggested ordering for later businesses):**
|
||||
- **High:** *SNS Secure* (physical install + cyber E&O), *SNS Infrastructure*
|
||||
(on-site/low-voltage work).
|
||||
**Liability tiers:**
|
||||
- **High:** *SNS Networking* (physical install + cyber E&O + workers' comp).
|
||||
- **Medium–High:** *SNS Support* (SLA contracts + recurring revenue worth ring-fencing).
|
||||
- **Medium / Lower:** *SNS Systems, Cloud, Web, Software* — form each when it
|
||||
becomes an active business. Until then they can run as assumed names of an
|
||||
existing operating sub or the parent.
|
||||
- **Medium:** *SNS Digital* (professional E&O only, all remote work).
|
||||
|
||||
When picking Business #2, the higher tiers (Secure, Support) are natural
|
||||
front-runners — a suggestion, not a commitment.
|
||||
When picking Business #2, Support is the natural front-runner — it's the
|
||||
recurring-revenue engine that makes the business durable.
|
||||
|
||||
---
|
||||
|
||||
@ -179,11 +168,11 @@ front-runners — a suggestion, not a commitment.
|
||||
S-corp taxation can cut self-employment tax (CPA question).
|
||||
- **Contractor licensing is local, not statewide** — no Indiana general
|
||||
contractor license; check City of South Bend & St. Joseph County for
|
||||
low-voltage/cabling/construction rules (Infrastructure & Secure).
|
||||
low-voltage/cabling/construction rules (Networking).
|
||||
- **Alarm/security licensing — verify.** Sources conflict; recent (2026) guidance
|
||||
indicates Indiana now requires a **state license to sell/install/monitor
|
||||
burglar, fire, and electronic security systems, access control, and CCTV**.
|
||||
Confirm before SNS Secure does physical work.
|
||||
Confirm before SNS Networking does physical security work.
|
||||
- **FinCEN BOI:** domestic US LLCs are **currently exempt** (interim rule since
|
||||
March 2025). No BOI filing needed now — but the rule has changed before, so
|
||||
re-check at formation.
|
||||
|
||||
@ -1,26 +0,0 @@
|
||||
# SNS Cloud
|
||||
|
||||
**Parent:** SnS Network Solutions · **Tagline:** *Infrastructure Without Limits*
|
||||
|
||||
## Scope
|
||||
Anything hosted off-premises: public cloud, hybrid, and cloud-native
|
||||
infrastructure. The scalable extension of SNS Systems.
|
||||
|
||||
## Services
|
||||
- AWS and Azure architecture and deployment
|
||||
- Hybrid infrastructure (on-prem ↔ cloud) and migration
|
||||
- Infrastructure-as-code, automation, and CI/CD
|
||||
- Cloud networking, security, and cost optimization
|
||||
- Backup, DR, and business-continuity in the cloud
|
||||
|
||||
## Positioning
|
||||
The scale layer. Line vs. neighbors: **Infrastructure** = the LAN/wire,
|
||||
**Systems** = on-prem compute, **Cloud** = off-prem compute. Naming note: "SNS"
|
||||
also = AWS Simple Notification Service — keep internal docs unambiguous.
|
||||
|
||||
## Liability & Ops Notes
|
||||
- **Medium** — professional liability; client cloud spend and data handling
|
||||
create fiduciary/contractual responsibility. Define who owns the cloud account.
|
||||
- **Entity:** operating subsidiary **SNS Cloud LLC** under SnS Network Solutions
|
||||
Holdings LLC. **Liability tier: Medium** — form its own LLC when this becomes an
|
||||
active business.
|
||||
49
divisions/sns-digital.md
Normal file
49
divisions/sns-digital.md
Normal file
@ -0,0 +1,49 @@
|
||||
# SNS Digital
|
||||
|
||||
**Parent:** SnS Network Solutions · **Tagline:** *Engineered for the Cloud*
|
||||
|
||||
## Scope
|
||||
Everything code, cloud, and web. If it runs off-prem, lives in a browser, or is
|
||||
custom software — it's Digital.
|
||||
|
||||
> **Consolidates:** former Web + Software + Cloud divisions.
|
||||
|
||||
## Services
|
||||
|
||||
**Cloud Infrastructure**
|
||||
- AWS and Azure architecture and deployment
|
||||
- Hybrid infrastructure (on-prem ↔ cloud) and migration
|
||||
- Infrastructure-as-code, automation, and CI/CD
|
||||
- Cloud networking, security, and cost optimization
|
||||
- Backup, DR, and business-continuity in the cloud
|
||||
|
||||
**Web & Hosting**
|
||||
- Website design and development (favor open-source stacks)
|
||||
- Managed/self-hosted hosting and domains
|
||||
- Email and DNS setup
|
||||
- Performance, SEO fundamentals, and accessibility compliance
|
||||
- Maintenance and content update workflows
|
||||
|
||||
**Custom Software**
|
||||
- Custom web/business applications
|
||||
- Business process automation and internal tooling
|
||||
- API integrations between existing systems
|
||||
- Data pipelines, reporting, and dashboards
|
||||
- Scripting/automation handed off with documentation
|
||||
|
||||
## Positioning
|
||||
The digital layer. Where Networking provides the physical substrate, Digital builds
|
||||
what runs on top of it — and beyond it into the cloud. Often the entry-point
|
||||
service (a website) that leads clients toward Networking or Support later.
|
||||
|
||||
## Liability & Ops Notes
|
||||
- **Medium** — professional liability / E&O across all service lines. No physical
|
||||
premises risk. IP ownership and licensing terms are the key contract issue
|
||||
(parent favors client code ownership per open-standards principle).
|
||||
- Hosting introduces recurring-revenue and data-responsibility — coordinate managed
|
||||
hosting SLAs with SNS Support.
|
||||
- **Naming caution:** "SNS" also = AWS Simple Notification Service — keep technical
|
||||
proposals/docs unambiguous.
|
||||
- **Entity:** operating subsidiary **SNS Digital LLC** under SnS Network Solutions
|
||||
Holdings LLC. **Liability tier: Medium** — form its own LLC when this becomes an
|
||||
active business.
|
||||
@ -1,26 +0,0 @@
|
||||
# SNS Infrastructure
|
||||
|
||||
**Parent:** SnS Network Solutions · **Tagline:** *The Physical Foundation*
|
||||
|
||||
## Scope
|
||||
The physical and logical backbone every other division depends on. If it carries
|
||||
a signal, SNS Infrastructure designs, installs, and documents it.
|
||||
|
||||
## Services
|
||||
- Structured cabling (Cat6/6A, fiber) and certification
|
||||
- Enterprise networking (Cisco, MikroTik, Ubiquiti) — routing, switching, VLANs
|
||||
- Wireless design, site surveys, and Wi-Fi deployment
|
||||
- Rack build-outs, patch panels, cable management, labeling
|
||||
- Network documentation: IP schemes, rack diagrams, cable maps
|
||||
|
||||
## Positioning
|
||||
The foundation layer. Projects here are the substrate that Systems, Secure,
|
||||
Cloud, and Support build on. Sells to any client with a physical premises.
|
||||
|
||||
## Liability & Ops Notes
|
||||
- **High** — on-site physical/low-voltage work, ladders, client premises.
|
||||
- Needs general liability + likely low-voltage licensing (state-dependent).
|
||||
- **Entity:** operating subsidiary **SNS Infrastructure LLC** under SnS Network
|
||||
Solutions Holdings LLC. **This is Business #1 (active)** — the owner's chosen
|
||||
first business; see [`sns-infrastructure-hiring.md`](../businesses/01-infrastructure/sns-infrastructure-hiring.md).
|
||||
**Liability tier: High** (physical/on-site work) — carries its own GL + workers' comp.
|
||||
@ -37,19 +37,16 @@ real billable work (see [`legal-structure.md`](./legal-structure.md)):
|
||||
|
||||
| Division | Entity | Focus | Status |
|
||||
|----------|--------|-------|--------|
|
||||
| [SNS Infrastructure](./sns-infrastructure.md) | SNS Infrastructure LLC | Networking, cabling, wireless | **Active (Business #1)** |
|
||||
| [SNS Secure](./sns-secure.md) | SNS Secure LLC | Cameras, access control, cyber | Planned |
|
||||
| [SNS Support](./sns-support.md) | SNS Support LLC | Managed services | Planned |
|
||||
| [SNS Systems](./sns-systems.md) | SNS Systems LLC | Linux, servers, virtualization | Planned |
|
||||
| [SNS Cloud](./sns-cloud.md) | SNS Cloud LLC | AWS, Azure, hybrid | Planned |
|
||||
| [SNS Web](./sns-web.md) | SNS Web LLC | Sites, hosting, presence | Planned |
|
||||
| [SNS Software](./sns-software.md) | SNS Software LLC | Custom applications | Planned |
|
||||
| [SNS Networking](./sns-networking.md) | SNS Networking LLC | Physical networking, security, on-prem compute | **Active (Business #1)** |
|
||||
| [SNS Digital](./sns-digital.md) | SNS Digital LLC | Code, cloud, web, hosting, custom apps | Planned |
|
||||
| [SNS Support](./sns-support.md) | SNS Support LLC | Managed services, RMM, SLAs | Planned |
|
||||
|
||||
## Brand Identity (inherited by all divisions)
|
||||
Navy `#0A1628` base + parent accent **Cyan `#10C8D8`**; each division keeps the navy
|
||||
base and takes its own signature accent. Geometric, legible open-source type
|
||||
(IBM Plex Sans / Inter; Oxanium / Sora / Rajdhani). Endorsed sub-brand lockup — the
|
||||
`SNS` parent mark always shows. Full palette, typography, and logo direction in
|
||||
base and takes its own signature accent (Networking = Signal Blue, Digital = Sky,
|
||||
Support = Orange). Geometric, legible open-source type (IBM Plex Sans / Inter;
|
||||
Oxanium / Sora / Rajdhani). Endorsed sub-brand lockup — the `SNS` parent mark always
|
||||
shows. Full palette, typography, and logo direction in
|
||||
[`../ai-core/knowledge/sns.md`](../ai-core/knowledge/sns.md).
|
||||
|
||||
## Liability & Ops Notes
|
||||
|
||||
45
divisions/sns-networking.md
Normal file
45
divisions/sns-networking.md
Normal file
@ -0,0 +1,45 @@
|
||||
# SNS Networking
|
||||
|
||||
**Parent:** SnS Network Solutions · **Tagline:** *The Connected Foundation*
|
||||
|
||||
## Scope
|
||||
Everything physical, on-prem, and security-related. If it touches the network,
|
||||
protects the network, or runs compute on-premises — it's Networking.
|
||||
|
||||
> **Consolidates:** former Infrastructure + Secure + Systems divisions.
|
||||
|
||||
## Services
|
||||
|
||||
**Physical Networking & Cabling**
|
||||
- Structured cabling (Cat6/6A, fiber) and certification
|
||||
- Enterprise networking (Cisco, MikroTik, Ubiquiti) — routing, switching, VLANs
|
||||
- Wireless design, site surveys, and Wi-Fi deployment
|
||||
- Rack build-outs, patch panels, cable management, labeling
|
||||
- Network documentation: IP schemes, rack diagrams, cable maps
|
||||
|
||||
**Security (Physical + Cyber)**
|
||||
- IP camera systems (design, install, NVR/VMS)
|
||||
- Access control (door controllers, badge/credential systems)
|
||||
- Alarm and intrusion integration
|
||||
- Firewalls/UTM deployment, VPN, network segmentation
|
||||
- Security audits, hardening, monitoring, incident response
|
||||
- Awareness training
|
||||
|
||||
**On-Prem Systems**
|
||||
- Linux server design, deployment, and administration
|
||||
- Virtualization (Proxmox, KVM) and containers
|
||||
- Self-hosted infrastructure (identity, files, backups)
|
||||
- Storage, NAS/SAN, and disaster-recovery design
|
||||
- Ansible automation for repeatable, documented builds
|
||||
|
||||
## Positioning
|
||||
The foundation layer. Projects here are the substrate that Digital builds on and
|
||||
Support maintains. Sells to any client with physical premises or on-prem compute needs.
|
||||
Same job site, same skill set, same insurance pool — one delivery team.
|
||||
|
||||
## Liability & Ops Notes
|
||||
- **High** — physical/on-site low-voltage work (GL + workers' comp) combined with
|
||||
cyber errors & omissions (E&O). Two insurance products, one entity.
|
||||
- Physical security install may require Indiana state licensing (verify before work).
|
||||
- **Entity:** operating subsidiary **SNS Networking LLC** under SnS Network Solutions
|
||||
Holdings LLC. **This is Business #1 (active).**
|
||||
@ -1,31 +0,0 @@
|
||||
# SNS Secure
|
||||
|
||||
**Parent:** SnS Network Solutions · **Tagline:** *Protected by Design*
|
||||
|
||||
## Scope
|
||||
Everything that protects the client — physically and digitally. Reflects the
|
||||
parent's "security by design" principle as a dedicated business unit.
|
||||
|
||||
## Services
|
||||
**Physical Security**
|
||||
- IP camera systems (design, install, NVR/VMS)
|
||||
- Access control (door controllers, badge/credential systems)
|
||||
- Alarm and intrusion integration
|
||||
|
||||
**Cybersecurity**
|
||||
- Security audits and hardening
|
||||
- Firewall/UTM deployment and policy
|
||||
- Monitoring, incident response, and awareness training
|
||||
|
||||
## Positioning
|
||||
The trust layer. Distinct from Infrastructure (which builds the network) by
|
||||
focusing on protecting it and the people/premises around it.
|
||||
|
||||
## Liability & Ops Notes
|
||||
- **High on both fronts** — physical install liability + cyber errors &
|
||||
omissions (E&O) exposure. These are different insurance products.
|
||||
- Physical security install may require state licensing.
|
||||
- **Entity:** operating subsidiary **SNS Secure LLC** under SnS Network Solutions
|
||||
Holdings LLC. **Liability tier: High** — highest combined exposure of any division
|
||||
(physical install + cyber E&O), so form its own LLC promptly when launched.
|
||||
Strong candidate for Business #2. Possible future split into Physical vs. Cyber.
|
||||
@ -1,26 +0,0 @@
|
||||
# SNS Software
|
||||
|
||||
**Parent:** SnS Network Solutions · **Tagline:** *Software Engineered to Fit*
|
||||
|
||||
## Scope
|
||||
Custom business applications and automation built to solve a specific client
|
||||
problem — not off-the-shelf products resold.
|
||||
|
||||
## Services
|
||||
- Custom web/business applications
|
||||
- Business process automation and internal tooling
|
||||
- API integrations between existing systems
|
||||
- Data pipelines, reporting, and dashboards
|
||||
- Scripting/automation handed off with documentation
|
||||
|
||||
## Positioning
|
||||
The problem-solving layer. Where the other divisions deploy infrastructure,
|
||||
Software makes it do something specific to the client's operation.
|
||||
|
||||
## Liability & Ops Notes
|
||||
- **Medium** — professional liability / E&O; IP ownership and licensing terms
|
||||
matter. Contracts should specify who owns delivered code (parent favors client
|
||||
ownership per the open-standards principle).
|
||||
- **Entity:** operating subsidiary **SNS Software LLC** under SnS Network Solutions
|
||||
Holdings LLC. **Liability tier: Medium** — form its own LLC when this becomes an
|
||||
active business; until then it can run as an assumed name of an existing operating sub.
|
||||
@ -3,9 +3,8 @@
|
||||
**Parent:** SnS Network Solutions · **Tagline:** *Always On*
|
||||
|
||||
## Scope
|
||||
Ongoing managed services — the recurring-revenue engine that maintains what the
|
||||
other divisions build. Recommended single home for **all** managed-service
|
||||
contracts (consolidating overlaps from Systems and Cloud).
|
||||
Ongoing managed services — the recurring-revenue engine that maintains what
|
||||
Networking and Digital build. The single home for **all** managed-service contracts.
|
||||
|
||||
## Services
|
||||
- Managed IT / helpdesk and remote monitoring (RMM)
|
||||
@ -13,10 +12,11 @@ contracts (consolidating overlaps from Systems and Cloud).
|
||||
- Backup monitoring and disaster-recovery testing
|
||||
- SLA-based response and escalation
|
||||
- Recurring documentation and health reporting
|
||||
- Monitoring, alerting, and uptime management
|
||||
|
||||
## Positioning
|
||||
The relationship layer — where "long-term partnership" (a core brand promise)
|
||||
actually lives. Turns one-time projects from every division into durable,
|
||||
actually lives. Turns one-time projects from Networking and Digital into durable,
|
||||
recurring client relationships.
|
||||
|
||||
## Liability & Ops Notes
|
||||
@ -24,5 +24,4 @@ recurring client relationships.
|
||||
data-loss claims are the main risks. Contracts and E&O coverage are critical.
|
||||
- **Entity:** operating subsidiary **SNS Support LLC** under SnS Network Solutions
|
||||
Holdings LLC. **Liability tier: Medium–High** (SLA/contractual exposure +
|
||||
recurring revenue worth ring-fencing) — form its own LLC when launched. A natural
|
||||
Business #2/#3 candidate.
|
||||
recurring revenue worth ring-fencing) — form its own LLC when launched.
|
||||
|
||||
@ -1,25 +0,0 @@
|
||||
# SNS Systems
|
||||
|
||||
**Parent:** SnS Network Solutions · **Tagline:** *Systems That Endure*
|
||||
|
||||
## Scope
|
||||
Servers, operating systems, and virtualization — the compute layer, on-premises.
|
||||
The clearest expression of the parent's open-source, Linux-first philosophy.
|
||||
|
||||
## Services
|
||||
- Linux server design, deployment, and administration
|
||||
- Virtualization (Proxmox, KVM, VMware) and containers
|
||||
- Self-hosted infrastructure (mail, files, identity, backups)
|
||||
- Storage, NAS/SAN, and disaster-recovery design
|
||||
- Automation (Ansible) for repeatable, documented builds
|
||||
|
||||
## Positioning
|
||||
The engine room. Builds the on-prem compute that Support then maintains and that
|
||||
Cloud extends off-premises. Draw the line: Systems = on-prem servers/OS.
|
||||
|
||||
## Liability & Ops Notes
|
||||
- **Medium** — mostly configuration/professional work, limited physical risk.
|
||||
- Professional liability (E&O) matters more than premises liability.
|
||||
- **Entity:** operating subsidiary **SNS Systems LLC** under SnS Network Solutions
|
||||
Holdings LLC. **Liability tier: Medium** — form its own LLC when this becomes an
|
||||
active business.
|
||||
@ -1,26 +0,0 @@
|
||||
# SNS Web
|
||||
|
||||
**Parent:** SnS Network Solutions · **Tagline:** *Your Presence, Engineered*
|
||||
|
||||
## Scope
|
||||
Websites, hosting, and digital presence — treated as engineered infrastructure,
|
||||
not disposable design work.
|
||||
|
||||
## Services
|
||||
- Website design and development (favor open-source stacks)
|
||||
- Managed/self-hosted hosting and domains
|
||||
- Email and DNS setup
|
||||
- Performance, SEO fundamentals, and accessibility compliance
|
||||
- Maintenance and content update workflows
|
||||
|
||||
## Positioning
|
||||
The public-facing layer. The client's front door. Often the entry-point service
|
||||
that leads clients toward Infrastructure, Systems, or Support later.
|
||||
|
||||
## Liability & Ops Notes
|
||||
- **Low–Medium** — mainly professional liability; uptime/SLA terms if hosting.
|
||||
- Hosting introduces recurring-revenue and data-responsibility considerations —
|
||||
coordinate managed hosting SLAs with SNS Support.
|
||||
- **Entity:** operating subsidiary **SNS Web LLC** under SnS Network Solutions
|
||||
Holdings LLC. **Liability tier: Low–Medium** — form its own LLC when this becomes
|
||||
an active business.
|
||||
52
infra/README.md
Normal file
52
infra/README.md
Normal file
@ -0,0 +1,52 @@
|
||||
# Infrastructure Builds — SnS Network Solutions
|
||||
|
||||
Actionable infrastructure designs, categorized by the SNS entity that would deliver
|
||||
each type of work to a client (or internally). Every design defaults to **FOSS** tooling
|
||||
(≥80% open-source) and uses our existing provider footprint.
|
||||
|
||||
## Principles
|
||||
|
||||
1. **FOSS-first (80%+ rule).** Prefer open-source over proprietary. Exceptions: Google
|
||||
Workspace (mail, calendar, chat, sheets) and AWS-managed services where the FOSS
|
||||
equivalent adds unacceptable ops burden.
|
||||
2. **Proxmox is the hypervisor.** All on-prem VMs and containers run on Proxmox VE.
|
||||
3. **Automation over clickops.** Ansible for config management. Gitea Actions / KESTRA
|
||||
for CI/CD. Infrastructure-as-code where possible.
|
||||
4. **Security by default.** WireGuard/Tailscale for overlay networking. Fail2ban + UFW
|
||||
at every edge. TLS everywhere. Least-privilege.
|
||||
5. **Simple until proven insufficient.** One VM beats a Kubernetes cluster when you have
|
||||
one app to run. Scale up only when the ceiling is hit.
|
||||
6. **Entity separation.** Each design is tagged to the SNS entity that owns it. Work
|
||||
doesn't bleed across entities.
|
||||
|
||||
## Provider Inventory
|
||||
|
||||
| Provider | Role | Notes |
|
||||
|----------|------|-------|
|
||||
| **Proxmox (on-prem)** | Primary hypervisor | KVM VMs + LXC containers. Home lab → client deployments |
|
||||
| **Linode (Akamai)** | Edge / jump host / light VPS | `172.238.163.85` — current bastion + Tailscale relay |
|
||||
| **Racknerd** | Cheap dedicated/VPS for non-critical workloads | `racknerd1` 172.245.72.108, `racknerd2` 192.3.165.113 |
|
||||
| **AWS** | Enterprise cloud, managed services | Use when clients require it or for services with no good FOSS equivalent |
|
||||
| **Google Workspace** | Email, calendar, chat, docs/sheets | Free tier covers current needs; upgrade to Business Starter when client-facing |
|
||||
|
||||
## Folder Structure
|
||||
|
||||
```
|
||||
infra/
|
||||
├── README.md ← you are here
|
||||
├── sns-networking/ ← physical networking, security, on-prem: Proxmox, VMs, hardening, IDS, VPN
|
||||
├── sns-digital/ ← cloud, web, code: AWS, hosting, CI/CD, dev environments
|
||||
└── sns-support/ ← managed services: monitoring, backup, RMM, patching
|
||||
```
|
||||
|
||||
## How to use these designs
|
||||
|
||||
Each subfolder contains one or more `.md` files describing a buildable design:
|
||||
- **What it is** — one-paragraph purpose
|
||||
- **Stack** — specific software, versions/sources, FOSS vs proprietary label
|
||||
- **Topology** — where it runs (which provider/VM), network diagram if needed
|
||||
- **Build steps** — enough to reproduce; points to Ansible roles or scripts when they exist
|
||||
- **Security posture** — what's hardened, what's exposed, trust boundaries
|
||||
- **Upgrade path** — what to do when this design hits its ceiling
|
||||
|
||||
Designs are intentionally simple. Complexity is added only when the simple version fails.
|
||||
70
infra/sns-digital/aws-baseline.md
Normal file
70
infra/sns-digital/aws-baseline.md
Normal file
@ -0,0 +1,70 @@
|
||||
# AWS Baseline Account — SNS Digital
|
||||
|
||||
**Entity:** SNS Digital · **Status:** Buildable now
|
||||
|
||||
## What it is
|
||||
|
||||
Minimal secure AWS account setup for internal use and future client work.
|
||||
Uses only the managed services where FOSS alternatives add unacceptable ops burden.
|
||||
|
||||
## Services Used (and why)
|
||||
|
||||
| Service | Purpose | FOSS Alternative | Why AWS wins here |
|
||||
|---------|---------|------------------|-------------------|
|
||||
| Route53 | DNS hosting | PowerDNS / self-hosted | 100% uptime SLA, $0.50/zone, not worth self-hosting |
|
||||
| S3 | Offsite backups, static assets | MinIO | Durability guarantee, lifecycle policies, no disk management |
|
||||
| SES | Transactional email | Postfix | Deliverability, IP reputation, SPF/DKIM handled |
|
||||
| IAM | Access control | N/A | Native to the platform |
|
||||
| CloudWatch (basic) | Billing alerts only | N/A | Free tier, protects against cost surprises |
|
||||
|
||||
## Account Structure
|
||||
|
||||
```
|
||||
SNS AWS Organization (future, when multi-client)
|
||||
└── sns-ops (current — single account)
|
||||
├── IAM User: sam (console + MFA, no programmatic keys on this user)
|
||||
├── IAM Role: infra-deploy (Ansible/Terraform assumes this role)
|
||||
├── IAM Role: backup-writer (PBS pushes to S3, write-only)
|
||||
└── IAM Role: ses-sender (app email, send-only)
|
||||
```
|
||||
|
||||
For now: single account `sns-ops`. Move to AWS Organizations when the first
|
||||
client needs their own isolated account.
|
||||
|
||||
## Build Steps
|
||||
|
||||
1. **Account:** Create with dedicated email (aws@snsnetlabs.com or similar). Enable MFA.
|
||||
2. **IAM:** Create `sam` user with console access + MFA. No access keys on this user.
|
||||
3. **Roles:**
|
||||
- `infra-deploy` — AdministratorAccess scoped to Terraform/Ansible (assume via CLI with MFA).
|
||||
- `backup-writer` — S3 PutObject + PutObjectTagging on backup bucket only.
|
||||
- `ses-sender` — ses:SendEmail + ses:SendRawEmail only.
|
||||
4. **S3 backup bucket:**
|
||||
```
|
||||
Name: sns-backups-<account-id>
|
||||
Versioning: enabled
|
||||
Encryption: SSE-S3 (AES-256)
|
||||
Lifecycle: transition to Glacier after 30 days, delete after 365
|
||||
Bucket policy: deny all except backup-writer role + sam
|
||||
```
|
||||
5. **Route53:** Create hosted zone for `snsnetlabs.com` (or production domain).
|
||||
Point registrar NS records here.
|
||||
6. **SES:** Verify domain, request production access, configure DKIM + SPF.
|
||||
7. **Billing alert:** CloudWatch alarm at $10, $25, $50 thresholds → email.
|
||||
|
||||
## Security Posture
|
||||
|
||||
- **No root key usage.** Root account locked with MFA, used only for billing/org changes.
|
||||
- **No long-lived access keys** on human users. Use `aws sso login` or assume-role with MFA.
|
||||
- **S3:** Block public access (account-level setting). Bucket policies explicit deny by default.
|
||||
- **CloudTrail:** Enable for API audit logging (free for management events).
|
||||
- **GuardDuty:** Enable free tier for threat detection (30-day trial then ~$4/month).
|
||||
|
||||
## Upgrade Path
|
||||
|
||||
- **AWS Organizations + SCPs:** When you onboard the first client to their own account.
|
||||
- **Terraform state in S3 + DynamoDB:** When IaC grows beyond a few resources.
|
||||
- **Control Tower:** When you manage 5+ accounts and need guardrails at scale.
|
||||
|
||||
<!-- ponytail: Single account until first client needs isolation. Ceiling: IAM
|
||||
complexity in a shared account. Upgrade: AWS Organizations + per-client accounts. -->
|
||||
110
infra/sns-digital/dev-environments.md
Normal file
110
infra/sns-digital/dev-environments.md
Normal file
@ -0,0 +1,110 @@
|
||||
# Development Environments — SNS Digital
|
||||
|
||||
**Entity:** SNS Digital · **Status:** Buildable now
|
||||
|
||||
## What it is
|
||||
|
||||
Reproducible dev environments that can be spun up on Proxmox in minutes.
|
||||
No "works on my machine" — every project gets a defined environment.
|
||||
|
||||
## Stack
|
||||
|
||||
| Component | Software | FOSS | Role |
|
||||
|-----------|----------|------|------|
|
||||
| Remote dev | SSH + VS Code Remote / Kiro CLI | Yes | Code on server, UI on laptop |
|
||||
| Environment definition | Ansible roles | Yes | Reproducible provisioning |
|
||||
| Ephemeral VMs | Proxmox cloud-init clone | Yes | Fresh VM per project/experiment |
|
||||
| Containers (app deps) | Docker Compose | Yes | Databases, caches, queues for local dev |
|
||||
| Language management | mise (formerly rtx) | Yes | Python, Node, Go version pinning per project |
|
||||
|
||||
## Patterns
|
||||
|
||||
### Pattern 1: Remote VM (primary workflow)
|
||||
|
||||
```
|
||||
Laptop (Kiro CLI / SSH) ──────► Dev VM on Proxmox
|
||||
├── Project repo (git clone)
|
||||
├── mise (.tool-versions)
|
||||
├── Docker Compose (deps)
|
||||
└── Full Linux environment
|
||||
```
|
||||
|
||||
**When:** Most development. Get a full Linux box with all tools, accessible
|
||||
from any device over Tailscale/WireGuard.
|
||||
|
||||
**Build:**
|
||||
1. Clone Debian 12 template on Proxmox.
|
||||
2. Run `dev-workstation` Ansible role:
|
||||
- Install: git, mise, docker, docker-compose, build-essential
|
||||
- Configure: user `sam`, SSH key, dotfiles
|
||||
- Set resource: 4 vCPU, 8GB RAM, 64GB disk (adjustable)
|
||||
3. SSH in, `mise install`, `docker compose up -d`, start coding.
|
||||
|
||||
### Pattern 2: Ephemeral project VM
|
||||
|
||||
**When:** Trying something risky, testing infrastructure changes, client-isolated work.
|
||||
|
||||
**Build:**
|
||||
1. `qm clone 9000 --name experiment-xyz --full`
|
||||
2. Work. Break things. Learn.
|
||||
3. `qm destroy <vmid>` — gone, no cleanup.
|
||||
|
||||
### Pattern 3: Local laptop (lightweight)
|
||||
|
||||
**When:** Quick edits, offline work, documentation.
|
||||
|
||||
Just Kiro CLI + SSH config. The heavy lifting happens on the remote VM.
|
||||
|
||||
## mise Configuration (per-project)
|
||||
|
||||
```toml
|
||||
# .mise.toml
|
||||
[tools]
|
||||
python = "3.12"
|
||||
node = "20"
|
||||
ansible = "latest"
|
||||
|
||||
[env]
|
||||
VIRTUAL_ENV = ".venv"
|
||||
```
|
||||
|
||||
Ensures every contributor (or future hire) gets the same versions without
|
||||
polluting the system.
|
||||
|
||||
## Ansible Role: dev-workstation
|
||||
|
||||
```yaml
|
||||
# roles/dev-workstation/tasks/main.yml (key tasks)
|
||||
- name: Install base packages
|
||||
apt:
|
||||
name: [git, curl, jq, tmux, htop, build-essential, unzip]
|
||||
|
||||
- name: Install Docker
|
||||
# Official Docker repo, not distro package
|
||||
|
||||
- name: Install mise
|
||||
shell: curl https://mise.run | sh
|
||||
|
||||
- name: Clone dotfiles
|
||||
git:
|
||||
repo: gitea:sam/dotfiles.git
|
||||
dest: /home/sam/.dotfiles
|
||||
|
||||
- name: Symlink dotfiles
|
||||
# .bashrc, .tmux.conf, .gitconfig
|
||||
```
|
||||
|
||||
## Security Posture
|
||||
|
||||
- **Dev VMs are not production.** They sit on the service VLAN but have no inbound
|
||||
ports open beyond SSH.
|
||||
- **No secrets in dev environments.** Use `.env.example` + Vaultwarden lookups.
|
||||
- **Ephemeral VMs destroyed after use.** No stale boxes accumulating.
|
||||
- **Docker socket access** is the one elevated privilege — acceptable for dev, not prod.
|
||||
|
||||
## Upgrade Path
|
||||
|
||||
- **Devcontainers / Codespaces-like:** If you hire devs who need browser-based IDEs,
|
||||
deploy code-server or Gitpod self-hosted on Proxmox.
|
||||
- **Nix flakes:** For truly reproducible environments beyond what mise offers
|
||||
(full system-level deps). Higher learning curve.
|
||||
70
infra/sns-digital/dns-and-domains.md
Normal file
70
infra/sns-digital/dns-and-domains.md
Normal file
@ -0,0 +1,70 @@
|
||||
# DNS & Domain Management — SNS Digital
|
||||
|
||||
**Entity:** SNS Digital · **Status:** Buildable now
|
||||
|
||||
## What it is
|
||||
|
||||
Centralized DNS management strategy. Public DNS on Route53 (cheap, reliable, API-driven).
|
||||
Internal DNS on AdGuard Home (split-horizon for private services).
|
||||
|
||||
## Architecture
|
||||
|
||||
```
|
||||
Public (internet-facing) Internal (on-prem only)
|
||||
┌─────────────────────┐ ┌─────────────────────────┐
|
||||
│ AWS Route53 │ │ AdGuard Home (LXC) │
|
||||
│ │ │ │
|
||||
│ snsnetlabs.com │ │ *.internal.sns → 192.168.122.x │
|
||||
│ client-domain.com │ │ *.wg.internal → 10.10.0.x │
|
||||
│ (delegated zones) │ │ │
|
||||
└─────────────────────┘ └─────────────────────────┘
|
||||
```
|
||||
|
||||
## Public DNS (Route53)
|
||||
|
||||
| Record | Purpose |
|
||||
|--------|---------|
|
||||
| `snsnetlabs.com` | Primary business domain |
|
||||
| `A` / `CNAME` → Caddy public IP or Cloudflare | Client sites |
|
||||
| `MX` → Google Workspace | Email |
|
||||
| `TXT` SPF/DKIM/DMARC | Email auth |
|
||||
| `CAA` | Restrict cert issuance to Let's Encrypt |
|
||||
|
||||
**Why Route53 over self-hosted DNS:** $0.50/zone/month, 100% SLA, no maintenance.
|
||||
DNS is the one thing you don't want to self-host — if it goes down, everything goes down.
|
||||
|
||||
## Internal DNS (AdGuard Home)
|
||||
|
||||
- Runs on Proxmox LXC.
|
||||
- Resolves `*.internal.sns` to local service IPs.
|
||||
- Blocks ads/telemetry for all on-prem devices.
|
||||
- Upstream: Cloudflare DoH (`https://dns.cloudflare.com/dns-query`).
|
||||
|
||||
## Domain Registration
|
||||
|
||||
- **Registrar:** Cloudflare Registrar (at-cost, no markup) or Porkbun (cheap, good UI).
|
||||
- **Rule:** All client domains registered under the client's own account. SNS never
|
||||
holds a client's domain hostage.
|
||||
- **SNS-owned domains:** registered under Sam's account, Route53 for DNS.
|
||||
|
||||
## Build Steps
|
||||
|
||||
1. Register domain at Cloudflare/Porkbun.
|
||||
2. Create Route53 hosted zone → get NS records.
|
||||
3. Point registrar NS to Route53.
|
||||
4. Add records via Ansible (`amazon.aws.route53` module) or Terraform.
|
||||
5. For internal: add entry to AdGuard Home's DNS rewrites.
|
||||
|
||||
## Security Posture
|
||||
|
||||
- **DNSSEC:** Enable on Route53 for SNS-owned zones.
|
||||
- **CAA records:** Restrict to `letsencrypt.org` only — prevents rogue cert issuance.
|
||||
- **DMARC:** `p=reject` on all owned domains once SPF/DKIM confirmed working.
|
||||
- **Registrar lock:** Transfer lock enabled on all production domains.
|
||||
- **No wildcard DNS on public zones** unless explicitly needed (reduces attack surface).
|
||||
|
||||
## Upgrade Path
|
||||
|
||||
- **Terraform-managed DNS:** When zone count exceeds 5, manage all Route53 records
|
||||
in Terraform for version control and drift detection.
|
||||
- **PowerDNS:** If Route53 cost becomes a factor at scale (unlikely at $0.50/zone).
|
||||
136
infra/sns-digital/gitea-and-cicd.md
Normal file
136
infra/sns-digital/gitea-and-cicd.md
Normal file
@ -0,0 +1,136 @@
|
||||
# Gitea & CI/CD Pipeline — SNS Digital
|
||||
|
||||
**Entity:** SNS Digital · **Status:** Active (Gitea running on 192.168.122.103)
|
||||
|
||||
## What it is
|
||||
|
||||
Self-hosted code platform (Gitea) with built-in CI/CD (Gitea Actions) and
|
||||
KESTRA for complex workflow orchestration. Replaces GitHub/GitLab SaaS entirely.
|
||||
|
||||
## Stack
|
||||
|
||||
| Component | Software | FOSS | Role |
|
||||
|-----------|----------|------|------|
|
||||
| Code hosting | Gitea | Yes | Git repos, issues, PRs, container registry |
|
||||
| CI/CD (simple) | Gitea Actions | Yes | GitHub Actions-compatible runners |
|
||||
| CI/CD (complex) | KESTRA | Yes | Orchestration, data pipelines, scheduled workflows |
|
||||
| Runner | Gitea Act Runner | Yes | Executes workflows (on 192.168.122.22) |
|
||||
| Artifacts | Gitea Packages | Yes | Built-in package/container registry |
|
||||
| Secrets | Gitea Secrets + Vaultwarden | Yes | CI secrets in Gitea, master secrets in Vaultwarden |
|
||||
|
||||
## Current Topology
|
||||
|
||||
```
|
||||
┌─────────────────────────────┐
|
||||
│ Gitea (192.168.122.103) │ ← VM on Proxmox
|
||||
│ - Git SSH (port 22) │
|
||||
│ - Web UI (port 3000) │
|
||||
│ - Container registry │
|
||||
└──────────────┬──────────────┘
|
||||
│
|
||||
▼
|
||||
┌─────────────────────────────┐
|
||||
│ Runner (192.168.122.22) │ ← Dedicated VM
|
||||
│ - Gitea Act Runner │
|
||||
│ - Docker executor │
|
||||
│ - Builds, tests, deploys │
|
||||
└─────────────────────────────┘
|
||||
│
|
||||
▼
|
||||
Deploy targets:
|
||||
- Proxmox VMs (rsync/SSH)
|
||||
- Docker hosts (docker compose pull)
|
||||
- S3 (static assets)
|
||||
```
|
||||
|
||||
## Workflow Patterns
|
||||
|
||||
### Simple: Build & Deploy (Gitea Actions)
|
||||
|
||||
```yaml
|
||||
# .gitea/workflows/deploy.yml
|
||||
name: Deploy
|
||||
on:
|
||||
push:
|
||||
branches: [main]
|
||||
|
||||
jobs:
|
||||
deploy:
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- uses: actions/checkout@v4
|
||||
- name: Build
|
||||
run: make build
|
||||
- name: Deploy
|
||||
run: rsync -avz ./dist/ sam@target:/srv/app/
|
||||
env:
|
||||
SSH_KEY: ${{ secrets.DEPLOY_KEY }}
|
||||
```
|
||||
|
||||
### Complex: Multi-step orchestration (KESTRA)
|
||||
|
||||
Use KESTRA when:
|
||||
- Workflow spans multiple systems (build → deploy → verify → notify)
|
||||
- Needs scheduling (cron-triggered)
|
||||
- Has conditional branching or retry logic
|
||||
- Involves data pipelines
|
||||
|
||||
## Git Workflow
|
||||
|
||||
- **Branching:** trunk-based for solo work. Feature branches + PR when collaborating.
|
||||
- **Protection:** `main` branch protected — no force push, require CI pass.
|
||||
- **Naming:** `feature/`, `fix/`, `infra/` prefixes.
|
||||
- **Commits:** Conventional commits (`feat:`, `fix:`, `docs:`, `infra:`).
|
||||
|
||||
## Build Steps (if setting up fresh)
|
||||
|
||||
1. **Gitea VM:**
|
||||
```bash
|
||||
# Docker Compose (already running)
|
||||
services:
|
||||
gitea:
|
||||
image: gitea/gitea:latest
|
||||
ports: ["3000:3000", "2222:22"]
|
||||
volumes: [./gitea-data:/data]
|
||||
environment:
|
||||
GITEA__database__DB_TYPE: sqlite3
|
||||
```
|
||||
|
||||
2. **Runner VM:**
|
||||
```bash
|
||||
# Install act_runner
|
||||
wget https://gitea.com/gitea/act_runner/releases/latest/act_runner-linux-amd64
|
||||
chmod +x act_runner-linux-amd64
|
||||
./act_runner-linux-amd64 register --instance https://gitea.internal.sns --token <TOKEN>
|
||||
./act_runner-linux-amd64 daemon
|
||||
```
|
||||
|
||||
3. **KESTRA (when needed):**
|
||||
```yaml
|
||||
services:
|
||||
kestra:
|
||||
image: kestra/kestra:latest
|
||||
ports: ["8080:8080"]
|
||||
volumes: [./kestra-data:/app/storage]
|
||||
```
|
||||
|
||||
4. **SSH access:** Add runner's SSH key to deploy targets' `authorized_keys`.
|
||||
|
||||
## Security Posture
|
||||
|
||||
- **Gitea access:** Behind Caddy + Authelia for web. SSH via ProxyJump only.
|
||||
- **Runner isolation:** Dedicated VM, Docker executor (each job gets a fresh container).
|
||||
- **Secrets:** Never in repos. Use Gitea Secrets for CI, Vaultwarden for everything else.
|
||||
- **Container registry:** Private by default. No public pulls without explicit config.
|
||||
- **Audit:** Gitea logs all repo events. Runner logs in Loki.
|
||||
|
||||
## Upgrade Path
|
||||
|
||||
- **Gitea cluster:** When you need HA or multiple runners for parallel builds.
|
||||
- **Woodpecker CI:** If Gitea Actions limitations appear (it's younger than the
|
||||
alternatives). Drop-in integration with Gitea.
|
||||
- **Harbor:** Enterprise container registry if Gitea's built-in registry isn't sufficient
|
||||
(vulnerability scanning, replication).
|
||||
|
||||
<!-- ponytail: SQLite for Gitea until performance degrades (~50 repos, ~5 users).
|
||||
Ceiling: SQLite write contention under concurrent CI. Upgrade: PostgreSQL. -->
|
||||
108
infra/sns-digital/hosting-stack.md
Normal file
108
infra/sns-digital/hosting-stack.md
Normal file
@ -0,0 +1,108 @@
|
||||
# Web Hosting Stack — SNS Digital
|
||||
|
||||
**Entity:** SNS Digital · **Status:** Buildable now
|
||||
|
||||
## What it is
|
||||
|
||||
A self-hosted web hosting platform for client sites and internal properties.
|
||||
Caddy as reverse proxy/TLS terminator, static sites via Hugo or plain HTML,
|
||||
dynamic sites via WordPress (when clients insist) or Ghost.
|
||||
|
||||
## Stack
|
||||
|
||||
| Component | Software | FOSS | Role |
|
||||
|-----------|----------|------|------|
|
||||
| Reverse proxy + TLS | Caddy 2 | Yes | Auto HTTPS, reverse proxy, static file server |
|
||||
| Static site generator | Hugo | Yes | Fast builds, no runtime dependencies |
|
||||
| CMS (when needed) | WordPress or Ghost | Yes | Client-managed content |
|
||||
| Database | MariaDB | Yes | WordPress backend |
|
||||
| Object storage | MinIO or S3 | Yes / Partial | Media uploads, large assets |
|
||||
| DNS | Route53 (AWS) | No | Reliable, cheap, API-driven |
|
||||
| Deployment | Git push → Gitea Actions → rsync/docker | Yes | Zero-touch deploys |
|
||||
|
||||
## Topology
|
||||
|
||||
```
|
||||
Internet
|
||||
│
|
||||
▼
|
||||
┌─────────────────────────────────┐
|
||||
│ Caddy (LXC on Proxmox) │ ← public IP via port-forward or Linode proxy
|
||||
│ - TLS termination │
|
||||
│ - Rate limiting │
|
||||
│ - Static file serving │
|
||||
│ - Reverse proxy to backends │
|
||||
└──────────┬──────────────────────┘
|
||||
│
|
||||
┌─────┼──────────┐
|
||||
▼ ▼ ▼
|
||||
Hugo WordPress Ghost
|
||||
(static) (VM/Docker) (Docker)
|
||||
```
|
||||
|
||||
### Where it runs
|
||||
|
||||
| Site type | Runs on | Why |
|
||||
|-----------|---------|-----|
|
||||
| Static (Hugo) | Caddy serves files directly | No runtime, fastest possible |
|
||||
| WordPress | Docker Compose VM on Proxmox | Isolation, easy backup/restore |
|
||||
| Ghost | Docker Compose VM on Proxmox | Cleaner than WP for blogs |
|
||||
| High-traffic / client SLA | Linode or AWS (CloudFront + S3) | Uptime guarantee > home connection |
|
||||
|
||||
## Build Steps
|
||||
|
||||
### Static site (Hugo — default choice)
|
||||
|
||||
1. Scaffold site: `hugo new site client-name`
|
||||
2. Add theme as git submodule.
|
||||
3. Push to Gitea repo.
|
||||
4. Gitea Actions workflow: build → rsync to Caddy's serve directory.
|
||||
5. Caddyfile entry:
|
||||
```
|
||||
client-name.com {
|
||||
root * /srv/sites/client-name/public
|
||||
file_server
|
||||
encode gzip
|
||||
}
|
||||
```
|
||||
|
||||
### WordPress (when client requires it)
|
||||
|
||||
1. Clone Docker Compose template:
|
||||
```yaml
|
||||
services:
|
||||
wordpress:
|
||||
image: wordpress:6-apache
|
||||
volumes: [./wp-content:/var/www/html/wp-content]
|
||||
environment:
|
||||
WORDPRESS_DB_HOST: db
|
||||
WORDPRESS_DB_NAME: wp
|
||||
db:
|
||||
image: mariadb:11
|
||||
volumes: [./data:/var/lib/mysql]
|
||||
environment:
|
||||
MARIADB_ROOT_PASSWORD_FILE: /run/secrets/db_root_pw
|
||||
```
|
||||
2. Caddy reverse proxies to `wordpress:80`.
|
||||
3. Backup: PBS snapshots VM nightly + wp-content rsync to S3.
|
||||
|
||||
## Security Posture
|
||||
|
||||
- **Caddy handles TLS** — automatic cert renewal, no manual certs to manage.
|
||||
- **No PHP on the proxy LXC.** WordPress runs isolated in its own VM/container.
|
||||
- **WordPress hardening:** disable XML-RPC, limit login attempts (Fail2ban or WP plugin),
|
||||
auto-update minor versions, restrict `wp-admin` to Tailscale IP if internal.
|
||||
- **Rate limiting** in Caddy for login pages and API endpoints.
|
||||
- **CSP headers** set per-site in Caddyfile.
|
||||
|
||||
## Upgrade Path
|
||||
|
||||
- **Cloudflare Tunnel:** If home IP isn't reliable enough for client SLAs, put Caddy
|
||||
behind a Cloudflare tunnel (free tier, no public port needed).
|
||||
- **Multi-node:** If hosting 20+ WordPress sites, move to a dedicated VM cluster with
|
||||
shared MariaDB (Galera) and NFS/Ceph for wp-content.
|
||||
- **Coolify or CapRover:** Self-hosted PaaS if you want a client-facing deploy dashboard.
|
||||
YAGNI until you have 5+ active web clients.
|
||||
|
||||
<!-- ponytail: No PaaS dashboard until 5+ web clients. Ceiling: manual Caddyfile +
|
||||
docker-compose management doesn't scale past ~20 sites. Upgrade: Coolify. -->
|
||||
104
infra/sns-digital/hybrid-networking.md
Normal file
104
infra/sns-digital/hybrid-networking.md
Normal file
@ -0,0 +1,104 @@
|
||||
# Hybrid Networking — SNS Digital
|
||||
|
||||
**Entity:** SNS Digital · **Status:** Partially built (WireGuard/Tailscale active)
|
||||
|
||||
## What it is
|
||||
|
||||
The overlay network that connects on-prem Proxmox VMs to cloud providers securely.
|
||||
Makes location transparent — a VM on Proxmox and a VPS on Linode appear on the same
|
||||
private network.
|
||||
|
||||
## Stack
|
||||
|
||||
| Component | Software | FOSS | Role |
|
||||
|-----------|----------|------|------|
|
||||
| Mesh VPN | Tailscale | Partial (client FOSS, control plane proprietary) | Zero-config mesh for management access |
|
||||
| Site-to-site | WireGuard | Yes | Persistent tunnels between sites (Proxmox ↔ Linode) |
|
||||
| DNS | AdGuard Home (on-prem) + split horizon | Yes | Internal names resolve to private IPs |
|
||||
| Bastion | Linode Nanode | N/A | Public SSH/WireGuard endpoint, ProxyJump target |
|
||||
|
||||
## Current Topology
|
||||
|
||||
```
|
||||
┌──────────────┐ WireGuard ┌──────────────────┐
|
||||
│ Proxmox │◄──────────────────────────►│ Linode Bastion │
|
||||
│ 192.168.122.x│ (always-on) │ 172.238.163.85 │
|
||||
└──────┬───────┘ └────────┬─────────┘
|
||||
│ │
|
||||
│ Tailscale mesh (management) │ Public IP
|
||||
│ │
|
||||
┌──────┴───────┐ ┌────────┴─────────┐
|
||||
│ Workstation │ │ Internet/SSH │
|
||||
│ (Sam's PC) │ │ clients │
|
||||
└──────────────┘ └──────────────────┘
|
||||
|
||||
Racknerd boxes: WireGuard peer to Linode (hub-and-spoke)
|
||||
AWS VPC: future — VPN Gateway or WireGuard on EC2 when needed
|
||||
```
|
||||
|
||||
## Design Decisions
|
||||
|
||||
1. **WireGuard for infrastructure, Tailscale for people.** WireGuard tunnels are
|
||||
persistent, config-file driven, Ansible-managed. Tailscale is for ad-hoc
|
||||
management access from laptops/phones.
|
||||
2. **Linode is the hub.** All WireGuard peers connect to Linode. On-prem and Racknerd
|
||||
boxes don't need public IPs — they reach each other through the hub.
|
||||
3. **No split tunneling for services.** Only management traffic goes over the mesh.
|
||||
Service traffic (web, API) goes through the public reverse proxy path.
|
||||
4. **ProxyJump, not port forwarding.** SSH to internal VMs uses `ProxyJump linode`
|
||||
(already in your SSH config). No ports exposed on the bastion beyond SSH + WireGuard.
|
||||
|
||||
## Build Steps (WireGuard hub-and-spoke)
|
||||
|
||||
1. **Linode (hub):**
|
||||
```ini
|
||||
# /etc/wireguard/wg0.conf
|
||||
[Interface]
|
||||
Address = 10.10.0.1/24
|
||||
ListenPort = 51820
|
||||
PrivateKey = <hub-private-key>
|
||||
|
||||
[Peer] # Proxmox
|
||||
PublicKey = <proxmox-public-key>
|
||||
AllowedIPs = 10.10.0.2/32, 192.168.122.0/24
|
||||
|
||||
[Peer] # Racknerd1
|
||||
PublicKey = <rn1-public-key>
|
||||
AllowedIPs = 10.10.0.3/32
|
||||
```
|
||||
|
||||
2. **Proxmox (spoke):**
|
||||
```ini
|
||||
[Interface]
|
||||
Address = 10.10.0.2/24
|
||||
PrivateKey = <proxmox-private-key>
|
||||
|
||||
[Peer] # Linode hub
|
||||
PublicKey = <hub-public-key>
|
||||
Endpoint = 172.238.163.85:51820
|
||||
AllowedIPs = 10.10.0.0/24
|
||||
PersistentKeepalive = 25
|
||||
```
|
||||
|
||||
3. **Enable IP forwarding** on Linode: `net.ipv4.ip_forward = 1`
|
||||
4. **Firewall:** UFW on Linode allows UDP 51820 inbound. Forward rules for inter-spoke.
|
||||
5. **DNS:** AdGuard on-prem resolves `*.wg.internal` to 10.10.0.x addresses.
|
||||
|
||||
## Security Posture
|
||||
|
||||
- **WireGuard:** Authenticated encryption (ChaCha20 + Poly1305). No pre-shared keys
|
||||
needed for this threat model, but can add for post-quantum hedge.
|
||||
- **Bastion exposure:** Only SSH (22/tcp) + WireGuard (51820/udp) on public IP.
|
||||
Everything else is default-deny.
|
||||
- **Key rotation:** WireGuard keys rotated annually (low urgency — Noise protocol
|
||||
provides forward secrecy per session).
|
||||
- **No cloud provider VPN dependencies.** Pure WireGuard means portable across providers.
|
||||
|
||||
## Upgrade Path
|
||||
|
||||
- **Headscale:** Self-hosted Tailscale control plane if the proprietary coordination
|
||||
server becomes a concern.
|
||||
- **AWS Site-to-Site VPN:** When a client VPC needs persistent connectivity and
|
||||
WireGuard-on-EC2 isn't enterprise-palatable.
|
||||
- **Multi-hub:** Add a second WireGuard hub (Racknerd or second Linode) for redundancy
|
||||
if the single Linode becomes a SPOF.
|
||||
70
infra/sns-digital/provider-roles.md
Normal file
70
infra/sns-digital/provider-roles.md
Normal file
@ -0,0 +1,70 @@
|
||||
# Provider Roles & Allocation — SNS Digital
|
||||
|
||||
**Entity:** SNS Digital · **Status:** Active (current layout)
|
||||
|
||||
## What it is
|
||||
|
||||
Defines what each cloud/VPS provider is used for, why, and when to pick one over another.
|
||||
Keeps spend intentional and prevents provider sprawl.
|
||||
|
||||
## Provider Matrix
|
||||
|
||||
| Provider | Role | Monthly Budget | Use When |
|
||||
|----------|------|---------------|----------|
|
||||
| **Linode (Akamai)** | Bastion / jump host, WireGuard relay, light public-facing services | ~$5–20 | Need a stable public IP, low-latency relay to on-prem, or a small always-on service |
|
||||
| **Racknerd** | Cheap VPS for non-critical / experimental workloads | ~$10–30 total | Disposable boxes, testing, overflow capacity, geo-diversity |
|
||||
| **AWS** | Enterprise workloads, managed services (S3, Route53, SES, Lambda) | Pay-as-you-go | Client requires AWS, need a managed service with no good self-hosted equivalent, or enterprise compliance |
|
||||
|
||||
## Current Allocation
|
||||
|
||||
```
|
||||
Linode ($5 Nanode)
|
||||
├── sam@172.238.163.85
|
||||
├── Role: SSH bastion, WireGuard endpoint, Tailscale relay
|
||||
├── ProxyJump target for all on-prem VMs (192.168.122.x)
|
||||
└── Minimal attack surface: SSH + WireGuard only
|
||||
|
||||
Racknerd1 ($?)
|
||||
├── root@172.245.72.108
|
||||
└── Role: TBD / available capacity
|
||||
|
||||
Racknerd2 ($?)
|
||||
├── root@192.3.165.113
|
||||
└── Role: TBD / available capacity
|
||||
|
||||
AWS (free tier + selective services)
|
||||
├── Route53: DNS hosting (cheap, reliable, no self-host headache)
|
||||
├── S3: offsite backup target (encrypted, lifecycle policies)
|
||||
├── SES: transactional email (when Google Workspace SMTP isn't appropriate)
|
||||
└── Future: client-facing infra when contracts require it
|
||||
```
|
||||
|
||||
## Decision: When to go cloud vs. on-prem
|
||||
|
||||
```
|
||||
Is it client-facing with an SLA you can't meet from home?
|
||||
YES → Cloud (Linode or AWS depending on complexity)
|
||||
NO →
|
||||
Does it need a public IP 24/7 with guaranteed uptime?
|
||||
YES → Linode (simple) or AWS (complex)
|
||||
NO →
|
||||
Is it throwaway / experimental?
|
||||
YES → Racknerd
|
||||
NO → On-prem Proxmox
|
||||
```
|
||||
|
||||
## Cost Rules
|
||||
|
||||
1. **No idle AWS resources.** If it's not serving traffic or storing data, shut it down.
|
||||
2. **Linode stays small.** It's a relay, not a compute platform. If workloads grow,
|
||||
they belong on-prem or on a dedicated Racknerd box.
|
||||
3. **Racknerd is disposable.** Don't put anything there that can't be rebuilt from
|
||||
Ansible in 15 minutes.
|
||||
4. **AWS reserved instances / savings plans:** Only after 3+ months of steady usage
|
||||
proves the workload is permanent.
|
||||
|
||||
## Security Notes
|
||||
|
||||
- Linode bastion: SSH key-only, UFW deny-all except 22 + WireGuard port.
|
||||
- Racknerd boxes: same hardening playbook as on-prem. No secrets stored locally.
|
||||
- AWS: IAM least-privilege, no root keys, MFA on console, service roles over user keys.
|
||||
57
infra/sns-networking/container-strategy.md
Normal file
57
infra/sns-networking/container-strategy.md
Normal file
@ -0,0 +1,57 @@
|
||||
# Container Strategy — SNS Networking
|
||||
|
||||
**Entity:** SNS Networking · **Status:** Buildable now
|
||||
|
||||
## What it is
|
||||
|
||||
Guidelines for when to use LXC containers vs VMs vs Docker on Proxmox, keeping
|
||||
things simple and predictable.
|
||||
|
||||
## Decision Tree
|
||||
|
||||
```
|
||||
Need full kernel isolation or non-Linux OS?
|
||||
YES → VM (KVM)
|
||||
NO →
|
||||
Is it a single long-running daemon (DNS, proxy, small app)?
|
||||
YES → LXC container (Proxmox-native, lowest overhead)
|
||||
NO →
|
||||
Is it a multi-container app with a compose file?
|
||||
YES → VM running Docker + Compose
|
||||
NO → LXC container
|
||||
```
|
||||
|
||||
## Rules
|
||||
|
||||
1. **LXC is default** for single-service workloads. Lower RAM, faster boot, native
|
||||
Proxmox backup/snapshot support.
|
||||
2. **Docker inside a VM** (not inside LXC) when the app ships as a compose stack.
|
||||
Avoids the nested-container headaches of Docker-in-LXC.
|
||||
3. **No Kubernetes.** Not until there are 20+ services that need orchestration and
|
||||
auto-scaling. The ceiling is named; the upgrade path is k3s on dedicated VMs.
|
||||
4. **One service per container/VM.** No multi-app VMs except dev/test throwaway boxes.
|
||||
5. **Naming:** `{service}-{env}` — e.g., `gitea-prod`, `caddy-prod`, `monitoring-dev`.
|
||||
|
||||
## LXC Template Defaults
|
||||
|
||||
- **OS:** Debian 12 (official Proxmox template)
|
||||
- **Resources:** 1 vCPU, 512MB RAM, 8GB disk (grow as needed)
|
||||
- **Network:** static IP on service VLAN, gateway to Caddy
|
||||
- **Security:** unprivileged container, nesting disabled unless Docker required
|
||||
|
||||
## VM Template Defaults
|
||||
|
||||
- **OS:** Debian 12 cloud-init (template ID 9000)
|
||||
- **Resources:** 2 vCPU, 2GB RAM, 32GB disk
|
||||
- **Network:** same as LXC
|
||||
- **Agent:** qemu-guest-agent installed for Proxmox integration
|
||||
|
||||
## Upgrade Path
|
||||
|
||||
- **k3s:** When service count exceeds ~20 or you need rolling deploys, stand up
|
||||
3 k3s nodes (VMs on Proxmox) and migrate Docker Compose apps to Helm charts.
|
||||
- **Podman:** Drop-in Docker replacement if Docker licensing ever becomes a concern
|
||||
(it won't for self-hosted, but Podman is rootless by default — security win).
|
||||
|
||||
<!-- ponytail: No k8s until 20+ services. Ceiling: manual docker-compose deploys
|
||||
don't scale past ~20 without toil. Upgrade: k3s on 3 dedicated VMs. -->
|
||||
98
infra/sns-networking/hardening-baseline.md
Normal file
98
infra/sns-networking/hardening-baseline.md
Normal file
@ -0,0 +1,98 @@
|
||||
# Host Hardening Baseline — SNS Networking
|
||||
|
||||
**Entity:** SNS Networking · **Status:** Buildable now (Ansible playbook)
|
||||
|
||||
## What it is
|
||||
|
||||
The minimum security posture applied to every Linux host — on-prem VM, LXC, or
|
||||
cloud VPS — before it does anything else. This is the Ansible "base" role that
|
||||
runs first on every new machine.
|
||||
|
||||
## Stack
|
||||
|
||||
| Component | Software | FOSS | Role |
|
||||
|-----------|----------|------|------|
|
||||
| Firewall | UFW (iptables frontend) | Yes | Default-deny inbound, explicit allow |
|
||||
| Brute-force protection | Fail2ban | Yes | SSH + web login jail |
|
||||
| SSH hardening | OpenSSH (config only) | Yes | Key-only, no root, no password |
|
||||
| Auto-updates | unattended-upgrades (Debian) | Yes | Security patches only |
|
||||
| Audit logging | auditd | Yes | File access, privilege escalation events |
|
||||
| Rootkit detection | rkhunter | Yes | Weekly scan, email on findings |
|
||||
|
||||
## The Playbook (what it does)
|
||||
|
||||
```yaml
|
||||
# roles/base-hardening/tasks/main.yml (conceptual)
|
||||
- name: SSH hardening
|
||||
# PermitRootLogin no
|
||||
# PasswordAuthentication no
|
||||
# PubkeyAuthentication yes
|
||||
# MaxAuthTries 3
|
||||
# AllowUsers sam
|
||||
|
||||
- name: UFW default deny
|
||||
# Default incoming: deny
|
||||
# Default outgoing: allow
|
||||
# Allow: SSH (22/tcp) from Tailscale/WireGuard subnet only
|
||||
|
||||
- name: Fail2ban SSH jail
|
||||
# maxretry: 3
|
||||
# bantime: 3600
|
||||
# findtime: 600
|
||||
|
||||
- name: Unattended upgrades (security only)
|
||||
# Automatic-Reboot: false (manual kernel reboots)
|
||||
|
||||
- name: Auditd rules
|
||||
# Watch /etc/passwd, /etc/shadow, /etc/sudoers
|
||||
# Log all sudo usage
|
||||
# Log failed file access attempts
|
||||
|
||||
- name: Disable unused services
|
||||
# Stop & mask: cups, avahi-daemon, bluetooth (if present)
|
||||
|
||||
- name: Sysctl hardening
|
||||
# net.ipv4.conf.all.rp_filter = 1
|
||||
# net.ipv4.icmp_echo_ignore_broadcasts = 1
|
||||
# net.ipv4.conf.all.accept_redirects = 0
|
||||
# net.ipv4.conf.all.send_redirects = 0
|
||||
# kernel.randomize_va_space = 2
|
||||
```
|
||||
|
||||
## Per-Host Firewall Rules
|
||||
|
||||
| Host type | Inbound allowed | Notes |
|
||||
|-----------|----------------|-------|
|
||||
| All hosts | SSH from 10.10.0.0/24 (WireGuard) | Management only over VPN |
|
||||
| Web-facing (Caddy) | 80, 443 from 0.0.0.0/0 | Public web traffic |
|
||||
| Bastion (Linode) | 22, 51820/udp from 0.0.0.0/0 | SSH + WireGuard |
|
||||
| Internal services | App port from service VLAN only | No direct internet access |
|
||||
| Proxmox host | 8006 from Tailscale only | Web UI never on public IP |
|
||||
|
||||
## Build Steps
|
||||
|
||||
1. Write Ansible role `roles/base-hardening/` with the above tasks.
|
||||
2. Add to `site.yml` as the first role for all host groups.
|
||||
3. Run against all existing hosts: `ansible-playbook site.yml --tags hardening`
|
||||
4. Verify: `ssh root@host` should fail. `ssh sam@host` with key should work.
|
||||
5. Verify: `nmap -sS host` from outside WireGuard should show only allowed ports.
|
||||
|
||||
## Security Posture
|
||||
|
||||
- **Default deny.** Nothing gets in unless explicitly allowed.
|
||||
- **No passwords anywhere.** SSH key-only. Service accounts use tokens or certs.
|
||||
- **Audit trail.** Every sudo, every sensitive file access logged.
|
||||
- **Automatic patching.** Security updates apply daily without manual intervention.
|
||||
Kernel updates require manual reboot (scheduled maintenance window).
|
||||
|
||||
## Upgrade Path
|
||||
|
||||
- **CIS Benchmark compliance:** Run `cis-cat` scanner and close gaps for client
|
||||
environments that require formal compliance.
|
||||
- **OSSEC/Wazuh:** When you need centralized security event management across 10+ hosts.
|
||||
- **SELinux/AppArmor:** Enforce MAC policies on high-value services (currently not
|
||||
enabled — adds complexity without proportional gain at this scale).
|
||||
|
||||
<!-- ponytail: No SELinux/AppArmor yet. Ceiling: DAC-only can't contain a compromised
|
||||
service from lateral movement on the same host. Upgrade: AppArmor profiles for
|
||||
Caddy, WordPress, Gitea when client compliance requires it. -->
|
||||
128
infra/sns-networking/ids-and-logging.md
Normal file
128
infra/sns-networking/ids-and-logging.md
Normal file
@ -0,0 +1,128 @@
|
||||
# IDS & Centralized Logging — SNS Networking
|
||||
|
||||
**Entity:** SNS Networking · **Status:** Buildable now
|
||||
|
||||
## What it is
|
||||
|
||||
Intrusion detection and centralized log aggregation so you know when something
|
||||
goes wrong before a client tells you. Lightweight — no SIEM until the scale demands it.
|
||||
|
||||
## Stack
|
||||
|
||||
| Component | Software | FOSS | Role |
|
||||
|-----------|----------|------|------|
|
||||
| Network IDS | Suricata | Yes | Packet inspection on Proxmox bridge |
|
||||
| Host IDS | AIDE | Yes | File integrity monitoring (detect unauthorized changes) |
|
||||
| Log aggregation | Loki (Grafana) | Yes | Centralized logs, queryable |
|
||||
| Log shipper | Promtail / Alloy | Yes | Ships logs from all hosts to Loki |
|
||||
| Alerting | Grafana Alerting | Yes | Fires on log patterns + IDS events |
|
||||
| Rootkit scan | rkhunter | Yes | Weekly cron, email on detection |
|
||||
|
||||
## Architecture
|
||||
|
||||
```
|
||||
┌────────────┐ ┌────────────┐ ┌────────────┐
|
||||
│ Host A │ │ Host B │ │ Host C │
|
||||
│ promtail │ │ promtail │ │ promtail │
|
||||
└─────┬──────┘ └─────┬──────┘ └─────┬──────┘
|
||||
│ │ │
|
||||
└────────────────┼────────────────┘
|
||||
▼
|
||||
┌─────────────────┐
|
||||
│ Loki (VM) │
|
||||
│ + Grafana │
|
||||
└─────────────────┘
|
||||
│
|
||||
▼
|
||||
Grafana Alerting → Email / Ntfy / Slack
|
||||
```
|
||||
|
||||
Suricata runs on the Proxmox host, tapping `vmbr1` (service bridge) in AF_PACKET mode.
|
||||
Alerts feed into Loki via promtail watching Suricata's `eve.json`.
|
||||
|
||||
## What Gets Logged
|
||||
|
||||
| Source | What | Retention |
|
||||
|--------|------|-----------|
|
||||
| SSH | All auth attempts (success + fail) | 90 days |
|
||||
| UFW | All denied packets | 30 days |
|
||||
| Fail2ban | All bans/unbans | 90 days |
|
||||
| Caddy | Access logs (all requests) | 30 days |
|
||||
| Suricata | Alerts (eve.json) | 90 days |
|
||||
| auditd | Sudo, sensitive file access | 90 days |
|
||||
| Systemd journal | Service starts/stops/crashes | 14 days |
|
||||
|
||||
## Build Steps
|
||||
|
||||
1. **Loki + Grafana:** Deploy as Docker Compose on a monitoring VM.
|
||||
```yaml
|
||||
services:
|
||||
loki:
|
||||
image: grafana/loki:latest
|
||||
volumes: [./loki-data:/loki]
|
||||
command: -config.file=/etc/loki/local-config.yaml
|
||||
grafana:
|
||||
image: grafana/grafana:latest
|
||||
volumes: [./grafana-data:/var/lib/grafana]
|
||||
```
|
||||
|
||||
2. **Promtail on each host:** Install via apt or binary. Config:
|
||||
```yaml
|
||||
clients:
|
||||
- url: http://loki.internal.sns:3100/loki/api/v1/push
|
||||
scrape_configs:
|
||||
- job_name: syslog
|
||||
static_configs:
|
||||
- targets: [localhost]
|
||||
labels:
|
||||
job: syslog
|
||||
host: ${HOSTNAME}
|
||||
journal:
|
||||
labels:
|
||||
job: journal
|
||||
```
|
||||
|
||||
3. **Suricata on Proxmox host:**
|
||||
```bash
|
||||
apt install suricata
|
||||
suricata-update # download rulesets
|
||||
# /etc/suricata/suricata.yaml: af-packet interface = vmbr1
|
||||
systemctl enable --now suricata
|
||||
```
|
||||
|
||||
4. **AIDE on critical hosts:**
|
||||
```bash
|
||||
apt install aide
|
||||
aide --init
|
||||
mv /var/lib/aide/aide.db.new /var/lib/aide/aide.db
|
||||
# Cron: daily `aide --check` → email diff
|
||||
```
|
||||
|
||||
5. **Grafana alerts:** Create alert rules for:
|
||||
- Fail2ban ban count > 10/hour
|
||||
- Suricata alert severity >= 2
|
||||
- SSH root login attempt (should never happen)
|
||||
- AIDE file change on critical paths
|
||||
|
||||
## Security Posture
|
||||
|
||||
- **Detection, not prevention** (at this layer). Prevention is UFW + Fail2ban.
|
||||
Suricata alerts tell you something got past the first layer.
|
||||
- **File integrity (AIDE)** catches rootkits, unauthorized config changes, backdoors.
|
||||
- **Log immutability:** Loki is write-once from the host perspective. Compromising a
|
||||
host doesn't let you erase your tracks from Loki (different VM, different creds).
|
||||
- **Retention is cost-bounded.** 90 days is enough for incident response without
|
||||
filling disks.
|
||||
|
||||
## Upgrade Path
|
||||
|
||||
- **Wazuh:** Full HIDS + SIEM + compliance dashboards when client contracts require
|
||||
formal security monitoring (SOC2, etc.).
|
||||
- **CrowdSec:** Collaborative IDS — share blocklists with the community. Drop-in
|
||||
alongside Suricata.
|
||||
- **Elasticsearch/OpenSearch:** If Loki's label-based querying isn't sufficient for
|
||||
complex correlation. YAGNI until you have a dedicated security analyst.
|
||||
|
||||
<!-- ponytail: No SIEM until client contracts require compliance reporting.
|
||||
Ceiling: Loki + Suricata can't do cross-host correlation or automated response.
|
||||
Upgrade: Wazuh for HIDS+SIEM or CrowdSec for collaborative blocking. -->
|
||||
78
infra/sns-networking/proxmox-base.md
Normal file
78
infra/sns-networking/proxmox-base.md
Normal file
@ -0,0 +1,78 @@
|
||||
# Proxmox Base Cluster — SNS Networking
|
||||
|
||||
**Entity:** SNS Networking · **Status:** Buildable now
|
||||
|
||||
## What it is
|
||||
|
||||
A single-node (expandable to cluster) Proxmox VE hypervisor that hosts all on-prem
|
||||
VMs and LXC containers. This is the foundation — everything else in `infra/` runs
|
||||
on top of this or connects to it.
|
||||
|
||||
## Stack
|
||||
|
||||
| Component | Software | FOSS | Notes |
|
||||
|-----------|----------|------|-------|
|
||||
| Hypervisor | Proxmox VE 8.x | Yes | Debian-based, KVM + LXC |
|
||||
| Storage | ZFS (local) | Yes | Mirror or RAIDZ1 depending on disk count |
|
||||
| Networking | Linux bridge + VLANs | Yes | `vmbr0` = management, `vmbr1` = services |
|
||||
| Backup | Proxmox Backup Server (PBS) | Yes | Separate VM or separate box |
|
||||
| Templates | Cloud-init images (Debian 12, Rocky 9, Ubuntu 24.04) | Yes | Pulled and prepped with `virt-customize` |
|
||||
| Automation | Ansible + Proxmox API | Yes | `community.general.proxmox*` modules |
|
||||
|
||||
## Topology
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────────────┐
|
||||
│ Proxmox VE Host (bare metal) │
|
||||
│ │
|
||||
│ vmbr0 (mgmt, VLAN 1) vmbr1 (services, VLAN 10+) │
|
||||
│ ├── LXC: dns (Pi-hole/AdGuard) │
|
||||
│ ├── LXC: nginx-proxy (reverse proxy) │
|
||||
│ ├── VM: gitea (code hosting) │
|
||||
│ ├── VM: monitoring (Prometheus+Grafana) │
|
||||
│ ├── VM: app-01 (general workloads) │
|
||||
│ └── VM: pbs (Proxmox Backup Server) │
|
||||
│ │
|
||||
│ ZFS pool: rpool (OS) + datapool (VMs) │
|
||||
└─────────────────────────────────────────────┘
|
||||
│
|
||||
├── WireGuard tunnel → Linode (bastion)
|
||||
└── Tailscale mesh (management access)
|
||||
```
|
||||
|
||||
## Build Steps
|
||||
|
||||
1. **Install Proxmox VE** on bare metal (Debian netinstall + Proxmox repo, or ISO).
|
||||
2. **Configure ZFS** — mirror for 2 disks, RAIDZ1 for 3+. Separate `rpool` (OS) from
|
||||
`datapool` (VM storage).
|
||||
3. **Networking** — create `vmbr0` (management) and `vmbr1` (service VLAN). Tag VLANs
|
||||
at the switch if physical segregation exists.
|
||||
4. **Disable enterprise repo, enable no-subscription repo** — remove nag popup.
|
||||
5. **Cloud-init templates** — download base images, convert to templates:
|
||||
```bash
|
||||
wget https://cloud.debian.org/images/cloud/bookworm/latest/debian-12-generic-amd64.qcow2
|
||||
qm create 9000 --memory 2048 --net0 virtio,bridge=vmbr1 --name debian12-template
|
||||
qm importdisk 9000 debian-12-generic-amd64.qcow2 datapool
|
||||
qm set 9000 --scsihw virtio-scsi-pci --scsi0 datapool:vm-9000-disk-0
|
||||
qm set 9000 --ide2 datapool:cloudinit --boot c --bootdisk scsi0
|
||||
qm template 9000
|
||||
```
|
||||
6. **PBS** — install Proxmox Backup Server (separate VM or LXC). Point PVE's storage
|
||||
config at it. Schedule nightly backups.
|
||||
7. **Ansible bootstrap** — run base hardening playbook against all new VMs (SSH keys,
|
||||
UFW, fail2ban, unattended-upgrades).
|
||||
|
||||
## Security Posture
|
||||
|
||||
- **Management access:** Tailscale or WireGuard only. Proxmox web UI not exposed to WAN.
|
||||
- **SSH:** key-only, no password auth, port 22 behind Tailscale/WireGuard.
|
||||
- **Firewall:** Proxmox host firewall enabled. Default deny inbound. Allow only
|
||||
Tailscale/WireGuard + VLAN inter-traffic as needed.
|
||||
- **Updates:** `apt` auto-security-updates on host. Manual kernel updates (reboot required).
|
||||
- **Backups:** PBS with encryption at rest. Retention: 7 daily, 4 weekly, 3 monthly.
|
||||
|
||||
## Upgrade Path
|
||||
|
||||
- **Multi-node cluster:** Add a second Proxmox host, enable HA with Ceph or shared ZFS-over-iSCSI.
|
||||
- **Ceph storage:** When local ZFS capacity or redundancy isn't enough.
|
||||
- **SDN:** Proxmox SDN module for VXLAN overlays if VLAN count gets unmanageable.
|
||||
59
infra/sns-networking/self-hosted-apps.md
Normal file
59
infra/sns-networking/self-hosted-apps.md
Normal file
@ -0,0 +1,59 @@
|
||||
# Self-Hosted Application Stack — SNS Networking
|
||||
|
||||
**Entity:** SNS Networking · **Status:** Buildable now
|
||||
|
||||
## What it is
|
||||
|
||||
A standard set of self-hosted services that replace SaaS for internal ops and
|
||||
client deployments. Each runs in its own LXC container or VM on Proxmox.
|
||||
|
||||
## Service Catalog
|
||||
|
||||
| Service | Software | Runs in | FOSS | Replaces |
|
||||
|---------|----------|---------|------|----------|
|
||||
| DNS + Ad blocking | AdGuard Home | LXC | Yes | Cloudflare DNS / Pi-hole |
|
||||
| Reverse proxy | Caddy | LXC | Yes | Nginx Proxy Manager (simpler TLS) |
|
||||
| File sync | Nextcloud | VM | Yes | Google Drive / Dropbox |
|
||||
| Passwords | Vaultwarden | LXC | Yes | Bitwarden cloud |
|
||||
| Wiki / Notes | Outline or BookStack | LXC | Yes | Notion / Confluence |
|
||||
| Identity (SSO) | Authelia | LXC | Yes | Okta / Auth0 |
|
||||
| Container registry | Gitea (built-in) | VM | Yes | Docker Hub / ECR |
|
||||
|
||||
## Topology
|
||||
|
||||
All services sit on `vmbr1` (service VLAN). Caddy is the single ingress point
|
||||
with automatic Let's Encrypt certs. Internal services use `*.internal.snsnetlabs.com`
|
||||
via split DNS (AdGuard returns local IPs).
|
||||
|
||||
```
|
||||
Internet → Linode (bastion/WireGuard) → Proxmox vmbr1
|
||||
│
|
||||
Caddy (reverse proxy)
|
||||
│
|
||||
┌──────────┬───────────┼───────────┬──────────┐
|
||||
Nextcloud Vaultwarden Outline Authelia Gitea
|
||||
```
|
||||
|
||||
## Build Pattern (per service)
|
||||
|
||||
1. Clone Debian 12 cloud-init template.
|
||||
2. Set hostname, static IP on service VLAN, SSH key.
|
||||
3. Run Ansible role for the specific app (Docker Compose or native install).
|
||||
4. Add Caddyfile entry for reverse proxy + TLS.
|
||||
5. Add DNS record in AdGuard (local) or public DNS if external.
|
||||
6. Add to PBS backup schedule.
|
||||
|
||||
## Security Posture
|
||||
|
||||
- **Authelia** gates all web UIs behind 2FA (TOTP). No service exposed without auth.
|
||||
- **Caddy** handles TLS termination — no self-signed certs internally.
|
||||
- **Vaultwarden** is the only password store; all service credentials live here.
|
||||
- **Network:** services can't reach the management VLAN. Inter-service traffic is
|
||||
explicit (e.g., Nextcloud → Authelia for SSO, nothing else).
|
||||
|
||||
## Upgrade Path
|
||||
|
||||
- **LDAP/Keycloak:** If client count grows beyond what Authelia file-based users handles,
|
||||
swap to Keycloak + LDAP backend.
|
||||
- **High availability:** Run critical services (Caddy, Vaultwarden, Authelia) as HA pairs
|
||||
behind a keepalived VIP.
|
||||
83
infra/sns-networking/vpn-and-access.md
Normal file
83
infra/sns-networking/vpn-and-access.md
Normal file
@ -0,0 +1,83 @@
|
||||
# VPN & Access Control — SNS Networking
|
||||
|
||||
**Entity:** SNS Networking · **Status:** Partially built (WireGuard + Tailscale active)
|
||||
|
||||
## What it is
|
||||
|
||||
Zero-trust-lite access model. No service is reachable from the public internet unless
|
||||
it explicitly needs to be. All management access goes through VPN. All web UIs gated
|
||||
by Authelia 2FA.
|
||||
|
||||
## Layers
|
||||
|
||||
```
|
||||
Layer 1: Network (WireGuard / Tailscale)
|
||||
└── Can you even reach the port?
|
||||
|
||||
Layer 2: Authentication (Authelia + SSH keys)
|
||||
└── Who are you?
|
||||
|
||||
Layer 3: Authorization (per-service ACLs)
|
||||
└── Are you allowed to do this?
|
||||
```
|
||||
|
||||
## Access Matrix
|
||||
|
||||
| What | Who | How they get in |
|
||||
|------|-----|-----------------|
|
||||
| Proxmox Web UI | Sam | Tailscale IP → port 8006 |
|
||||
| SSH to any host | Sam | WireGuard/Tailscale → ProxyJump |
|
||||
| Gitea web | Sam + future devs | Caddy → Authelia 2FA → Gitea |
|
||||
| Monitoring (Grafana) | Sam | Caddy → Authelia 2FA → Grafana |
|
||||
| Client websites | Public | Caddy → site (no auth) |
|
||||
| Client WordPress admin | Client | Caddy → Authelia or IP-restrict |
|
||||
| Vaultwarden | Sam | Caddy → Authelia 2FA → Vaultwarden |
|
||||
|
||||
## Authelia Configuration (key decisions)
|
||||
|
||||
- **Backend:** file-based users (YAML). Swap to LDAP when user count > 10.
|
||||
- **2FA:** TOTP (Authelia built-in). No hardware key requirement yet.
|
||||
- **Session:** 12h idle timeout, 7d absolute timeout.
|
||||
- **Policy:** two_factor for all protected domains. No single_factor exceptions.
|
||||
- **Integration:** Caddy `forward_auth` directive per-site.
|
||||
|
||||
```
|
||||
# Caddyfile pattern for Authelia-protected service
|
||||
grafana.internal.sns {
|
||||
forward_auth authelia:9091 {
|
||||
uri /api/authz/forward-auth
|
||||
copy_headers Remote-User Remote-Groups Remote-Email
|
||||
}
|
||||
reverse_proxy grafana:3000
|
||||
}
|
||||
```
|
||||
|
||||
## Certificate Management
|
||||
|
||||
| Scope | Tool | Method |
|
||||
|-------|------|--------|
|
||||
| Public sites | Caddy (built-in ACME) | Let's Encrypt, auto-renewal |
|
||||
| Internal services | Caddy (internal CA) or Step-CA | Caddy can issue self-signed internal certs automatically |
|
||||
| WireGuard | Native (Noise protocol) | No PKI needed — public key exchange |
|
||||
| SSH | OpenSSH keys | Ed25519 keys, no CA (until 20+ hosts) |
|
||||
|
||||
**Future:** SSH Certificate Authority (step-ca) when managing keys for 20+ hosts
|
||||
becomes unwieldy.
|
||||
|
||||
## Security Posture
|
||||
|
||||
- **No service exposed without auth** (except public websites by design).
|
||||
- **2FA mandatory** on every web UI — no exceptions.
|
||||
- **Session tokens short-lived** — 12h idle forces re-auth.
|
||||
- **No VPN split tunneling for management** — if you're on the mesh, you can reach
|
||||
management ports. If you're not, you can't. Binary.
|
||||
- **Key rotation:** SSH keys rotated annually. WireGuard keys annually.
|
||||
Authelia TOTP secrets only on device change.
|
||||
|
||||
## Upgrade Path
|
||||
|
||||
- **Keycloak + LDAP:** When you have employees or multiple clients needing SSO.
|
||||
- **Hardware keys (WebAuthn):** When the threat model justifies it (high-value targets).
|
||||
- **SSH CA (step-ca):** When managing individual authorized_keys files across 20+ hosts
|
||||
becomes toil.
|
||||
- **Mutual TLS (mTLS):** For service-to-service auth if zero-trust goes full-depth.
|
||||
114
infra/sns-support/backup-strategy.md
Normal file
114
infra/sns-support/backup-strategy.md
Normal file
@ -0,0 +1,114 @@
|
||||
# Backup Strategy — SNS Support
|
||||
|
||||
**Entity:** SNS Support · **Status:** Buildable now
|
||||
|
||||
## What it is
|
||||
|
||||
3-2-1 backup strategy using FOSS tools. Three copies, two media types, one offsite.
|
||||
Every VM and critical data set has a defined backup path and tested restore procedure.
|
||||
|
||||
## Stack
|
||||
|
||||
| Component | Software | FOSS | Role |
|
||||
|-----------|----------|------|------|
|
||||
| VM/container backup | Proxmox Backup Server (PBS) | Yes | Incremental, deduplicated VM backups |
|
||||
| File-level backup | restic | Yes | Encrypted, deduplicated file backups |
|
||||
| Offsite target | AWS S3 (Glacier) | No | Encrypted offsite copies |
|
||||
| Local target | PBS datastore (ZFS) | Yes | Fast restores, primary backup |
|
||||
| Scheduling | PBS built-in + cron | Yes | Nightly automated runs |
|
||||
| Verification | PBS verify + restic check | Yes | Catch corruption early |
|
||||
|
||||
## 3-2-1 Implementation
|
||||
|
||||
```
|
||||
Copy 1: Live data (Proxmox VM disks, app databases)
|
||||
Copy 2: PBS on-prem (separate ZFS pool or separate physical host)
|
||||
Copy 3: S3 Glacier (encrypted, offsite)
|
||||
```
|
||||
|
||||
| Data type | Copy 1 | Copy 2 (local) | Copy 3 (offsite) |
|
||||
|-----------|--------|----------------|-------------------|
|
||||
| VMs + LXC | Proxmox host | PBS (nightly snapshot) | PBS → S3 sync (weekly) |
|
||||
| Databases (MariaDB, SQLite) | Running instance | mysqldump → restic → local | restic → S3 |
|
||||
| Git repos (Gitea) | Gitea VM | PBS snapshot + Gitea dump | restic → S3 |
|
||||
| Config/secrets | Vaultwarden | PBS snapshot | restic → S3 (encrypted at rest) |
|
||||
| Static sites | Caddy VM | PBS snapshot | Git repo is the backup |
|
||||
|
||||
## Retention Policy
|
||||
|
||||
| Location | Daily | Weekly | Monthly | Max age |
|
||||
|----------|-------|--------|---------|---------|
|
||||
| PBS (local) | 7 | 4 | 3 | ~4 months |
|
||||
| S3 Glacier | — | 4 | 6 | ~7 months |
|
||||
| restic (local) | 7 | 4 | 6 | ~7 months |
|
||||
|
||||
## Build Steps
|
||||
|
||||
### PBS (primary — already referenced in sns-systems)
|
||||
|
||||
1. Dedicated VM or physical host with its own ZFS pool.
|
||||
2. Add as storage in Proxmox: Datacenter → Storage → Proxmox Backup Server.
|
||||
3. Create backup jobs: nightly at 02:00, all VMs/CTs in the pool.
|
||||
4. Enable verification: weekly verify job to catch bit rot.
|
||||
5. Encryption: PBS supports client-side encryption — enable for offsite copies.
|
||||
|
||||
### restic (file-level + offsite)
|
||||
|
||||
```bash
|
||||
# Initialize S3 repo (one-time)
|
||||
export AWS_ACCESS_KEY_ID=<backup-writer-key>
|
||||
export AWS_SECRET_ACCESS_KEY=<secret>
|
||||
restic -r s3:s3.amazonaws.com/sns-backups-<account>/restic init
|
||||
|
||||
# Nightly backup (cron)
|
||||
restic -r s3:... backup /srv/critical-data \
|
||||
--exclude-caches \
|
||||
--tag nightly
|
||||
|
||||
# Prune old snapshots
|
||||
restic -r s3:... forget \
|
||||
--keep-daily 7 --keep-weekly 4 --keep-monthly 6 \
|
||||
--prune
|
||||
```
|
||||
|
||||
### Database dumps (pre-backup hook)
|
||||
|
||||
```bash
|
||||
#!/bin/bash
|
||||
# /etc/cron.d/db-backup (runs before restic)
|
||||
mysqldump --all-databases | gzip > /srv/backups/mysql/all-$(date +%F).sql.gz
|
||||
# Restic picks up /srv/backups/ in its nightly run
|
||||
```
|
||||
|
||||
## Restore Testing
|
||||
|
||||
**Monthly:** Restore one random VM from PBS to a temporary ID. Boot it, verify
|
||||
services start. Destroy the test restore.
|
||||
|
||||
**Quarterly:** Restore from S3/restic to a clean VM. Verify data integrity end-to-end.
|
||||
|
||||
Document restore test results in `projects/` or a simple log file.
|
||||
|
||||
## Security Posture
|
||||
|
||||
- **Encryption at rest:** PBS supports encryption. restic encrypts by default (AES-256).
|
||||
S3 bucket has SSE-S3 enabled as a second layer.
|
||||
- **Backup credentials isolated:** `backup-writer` IAM role can only PutObject to the
|
||||
backup bucket. Cannot list, read, or delete — prevents ransomware from wiping backups.
|
||||
- **S3 Object Lock (future):** Enable when client data is stored — makes backups
|
||||
immutable for the retention period.
|
||||
- **PBS access:** Only Proxmox host can reach PBS. No other host has write access.
|
||||
- **restic repo password:** Stored in Vaultwarden, not in cron scripts (use a
|
||||
password file with 600 permissions owned by root).
|
||||
|
||||
## Upgrade Path
|
||||
|
||||
- **S3 Object Lock + Compliance mode:** When you need immutable backups for client
|
||||
contracts or compliance.
|
||||
- **PBS replication:** Second PBS at a different site for faster disaster recovery
|
||||
(instead of restoring from S3).
|
||||
- **Velero:** If/when Kubernetes enters the picture, for persistent volume backups.
|
||||
|
||||
<!-- ponytail: No immutable backups yet. Ceiling: a compromised root on the Proxmox
|
||||
host could delete PBS datastore. Upgrade: S3 Object Lock + separate PBS with
|
||||
different credentials. -->
|
||||
145
infra/sns-support/monitoring.md
Normal file
145
infra/sns-support/monitoring.md
Normal file
@ -0,0 +1,145 @@
|
||||
# Monitoring & Alerting — SNS Support
|
||||
|
||||
**Entity:** SNS Support · **Status:** Buildable now
|
||||
|
||||
## What it is
|
||||
|
||||
Centralized monitoring for all infrastructure — on-prem and cloud. Know when
|
||||
something is down before anyone reports it. This is what makes managed services
|
||||
possible.
|
||||
|
||||
## Stack
|
||||
|
||||
| Component | Software | FOSS | Role |
|
||||
|-----------|----------|------|------|
|
||||
| Metrics collection | Prometheus | Yes | Scrapes targets, stores time-series |
|
||||
| Visualization | Grafana | Yes | Dashboards, alerting UI |
|
||||
| Node metrics | node_exporter | Yes | CPU, RAM, disk, network per host |
|
||||
| Container metrics | cAdvisor | Yes | Docker/LXC resource usage |
|
||||
| Uptime / HTTP checks | Uptime Kuma | Yes | External endpoint monitoring, status pages |
|
||||
| Alerting | Grafana Alerting | Yes | Routes alerts to email/Ntfy/Slack |
|
||||
| Notifications | Ntfy | Yes | Self-hosted push notifications (phone/desktop) |
|
||||
|
||||
## Architecture
|
||||
|
||||
```
|
||||
┌────────────┐ ┌────────────┐ ┌────────────┐ ┌────────────┐
|
||||
│ Host A │ │ Host B │ │ Host C │ │ Linode │
|
||||
│ node_exp │ │ node_exp │ │ node_exp │ │ node_exp │
|
||||
└─────┬──────┘ └─────┬──────┘ └─────┬──────┘ └─────┬──────┘
|
||||
│ │ │ │
|
||||
└────────────────┼────────────────┼────────────────┘
|
||||
▼
|
||||
┌─────────────────┐
|
||||
│ Prometheus │ ← VM on Proxmox
|
||||
│ (scrapes all) │
|
||||
└────────┬────────┘
|
||||
│
|
||||
┌────────┴────────┐
|
||||
│ Grafana │
|
||||
│ - Dashboards │
|
||||
│ - Alert rules │
|
||||
└────────┬────────┘
|
||||
│
|
||||
┌────────┴────────┐
|
||||
│ Ntfy │ ← Push notifications to phone
|
||||
└─────────────────┘
|
||||
|
||||
┌─────────────────┐
|
||||
│ Uptime Kuma │ ← Separate LXC, checks from outside
|
||||
│ (HTTP checks) │
|
||||
└─────────────────┘
|
||||
```
|
||||
|
||||
## What Gets Monitored
|
||||
|
||||
| Category | Metrics | Alert threshold |
|
||||
|----------|---------|-----------------|
|
||||
| **Host health** | CPU, RAM, disk, load | Disk > 85%, RAM > 90%, load > 4x cores |
|
||||
| **Service up/down** | systemd unit status | Any critical service down > 2 min |
|
||||
| **Network** | Interface errors, bandwidth | Sustained > 80% capacity |
|
||||
| **HTTP endpoints** | Response time, status code | > 5s response or non-2xx |
|
||||
| **SSL certs** | Days until expiry | < 14 days (Caddy should auto-renew, this catches failures) |
|
||||
| **Backups** | Last successful PBS backup age | > 26 hours (missed nightly window) |
|
||||
| **Docker** | Container restarts, OOM kills | Any restart loop or OOM |
|
||||
| **WireGuard** | Peer last handshake age | > 5 minutes (tunnel down) |
|
||||
|
||||
## Build Steps
|
||||
|
||||
1. **Monitoring VM:** Clone Debian 12 template. 2 vCPU, 4GB RAM, 50GB disk.
|
||||
|
||||
2. **Prometheus + Grafana (Docker Compose):**
|
||||
```yaml
|
||||
services:
|
||||
prometheus:
|
||||
image: prom/prometheus:latest
|
||||
volumes:
|
||||
- ./prometheus.yml:/etc/prometheus/prometheus.yml
|
||||
- prom-data:/prometheus
|
||||
command: --storage.tsdb.retention.time=90d
|
||||
|
||||
grafana:
|
||||
image: grafana/grafana:latest
|
||||
volumes: [grafana-data:/var/lib/grafana]
|
||||
environment:
|
||||
GF_SECURITY_ADMIN_PASSWORD__FILE: /run/secrets/grafana_pw
|
||||
```
|
||||
|
||||
3. **node_exporter on every host:**
|
||||
```bash
|
||||
apt install prometheus-node-exporter
|
||||
# Or binary install + systemd unit
|
||||
# Listens on :9100, scraped by Prometheus
|
||||
```
|
||||
|
||||
4. **Prometheus scrape config:**
|
||||
```yaml
|
||||
# prometheus.yml
|
||||
scrape_configs:
|
||||
- job_name: nodes
|
||||
static_configs:
|
||||
- targets:
|
||||
- gitea.internal.sns:9100
|
||||
- caddy.internal.sns:9100
|
||||
- linode.wg.internal:9100
|
||||
# ... all hosts
|
||||
```
|
||||
|
||||
5. **Uptime Kuma (separate LXC):**
|
||||
```bash
|
||||
docker run -d --name uptime-kuma -p 3001:3001 \
|
||||
-v uptime-kuma:/app/data louislam/uptime-kuma
|
||||
```
|
||||
Add monitors for all public endpoints + internal services.
|
||||
|
||||
6. **Ntfy (self-hosted push):**
|
||||
```bash
|
||||
docker run -d --name ntfy -p 8080:80 \
|
||||
-v ntfy-cache:/var/cache/ntfy binwiederhier/ntfy serve
|
||||
```
|
||||
Grafana alert contact point → Ntfy webhook → phone notification.
|
||||
|
||||
7. **Grafana dashboards:** Import community dashboards:
|
||||
- Node Exporter Full (ID: 1860)
|
||||
- Docker/cAdvisor (ID: 14282)
|
||||
- Custom: SNS Overview (service status grid)
|
||||
|
||||
## Security Posture
|
||||
|
||||
- **Prometheus/Grafana:** Behind Authelia 2FA via Caddy. Not exposed publicly.
|
||||
- **node_exporter:** Binds to service VLAN IP only. No internet-facing metrics endpoints.
|
||||
- **Uptime Kuma:** Can optionally expose a public status page per-client (read-only).
|
||||
- **Ntfy:** Private topic names. No unauthenticated publish.
|
||||
- **Data retention:** 90 days for metrics. Enough for trend analysis without filling disks.
|
||||
|
||||
## Upgrade Path
|
||||
|
||||
- **Thanos / Mimir:** When Prometheus needs long-term storage or multi-cluster federation.
|
||||
YAGNI until metrics volume overwhelms a single Prometheus instance.
|
||||
- **VictoriaMetrics:** Drop-in Prometheus replacement with better compression and
|
||||
performance if retention or scrape targets grow significantly.
|
||||
- **PagerDuty / Opsgenie:** When you have SLA contracts that need formal on-call rotation.
|
||||
Until then, Ntfy to your phone is sufficient.
|
||||
|
||||
<!-- ponytail: Single Prometheus, no HA. Ceiling: single-node Prometheus handles ~1M
|
||||
active series easily. Upgrade: VictoriaMetrics or Thanos when that's exceeded. -->
|
||||
140
infra/sns-support/rmm-and-patching.md
Normal file
140
infra/sns-support/rmm-and-patching.md
Normal file
@ -0,0 +1,140 @@
|
||||
# RMM & Patch Management — SNS Support
|
||||
|
||||
**Entity:** SNS Support · **Status:** Buildable now
|
||||
|
||||
## What it is
|
||||
|
||||
Remote monitoring and management (RMM) for maintaining hosts without SSH-ing into
|
||||
each one manually. Patch management ensures security updates land promptly.
|
||||
This is the recurring-revenue engine — what you sell as "managed services."
|
||||
|
||||
## Stack
|
||||
|
||||
| Component | Software | FOSS | Role |
|
||||
|-----------|----------|------|------|
|
||||
| RMM / remote management | MeshCentral | Yes | Remote access, terminal, file transfer, inventory |
|
||||
| Patch management | unattended-upgrades + Ansible | Yes | Auto security patches + scheduled full updates |
|
||||
| Configuration drift | Ansible (periodic runs) | Yes | Detect and correct drift from desired state |
|
||||
| Inventory | MeshCentral + Ansible facts | Yes | Hardware/software inventory per host |
|
||||
| Ticketing (future) | Zammad or FreeScout | Yes | Client-facing ticket system when needed |
|
||||
|
||||
## Architecture
|
||||
|
||||
```
|
||||
┌─────────────────────────────────┐
|
||||
│ MeshCentral (VM on Proxmox) │
|
||||
│ - Web UI (Authelia-gated) │
|
||||
│ - Agent management │
|
||||
│ - Remote terminal/desktop │
|
||||
└──────────────┬──────────────────┘
|
||||
│
|
||||
┌──────────┼──────────┬──────────────┐
|
||||
▼ ▼ ▼ ▼
|
||||
Host A Host B Host C Client PC
|
||||
(agent) (agent) (agent) (agent)
|
||||
```
|
||||
|
||||
## MeshCentral
|
||||
|
||||
**Why MeshCentral over commercial RMM (ConnectWise, Datto, NinjaRMM):**
|
||||
- Fully FOSS (Apache 2.0 license)
|
||||
- Self-hosted — no per-device SaaS fees
|
||||
- Supports Linux, Windows, macOS agents
|
||||
- Web-based remote desktop/terminal
|
||||
- Device groups, user permissions, audit logging
|
||||
- Good enough for 1–50 managed endpoints
|
||||
|
||||
**Limitations (the ceiling):**
|
||||
- No built-in patch management (that's Ansible's job)
|
||||
- No PSA/ticketing integration (add Zammad when needed)
|
||||
- Single-node only (no built-in HA)
|
||||
|
||||
## Patch Strategy
|
||||
|
||||
| Patch type | Method | Timing | Approval |
|
||||
|------------|--------|--------|----------|
|
||||
| Security (critical) | unattended-upgrades | Daily, automatic | None needed |
|
||||
| Security (kernel) | Ansible playbook | Weekly maintenance window | Auto (reboot scheduled) |
|
||||
| Feature / major version | Ansible playbook | Monthly, manual trigger | Sam approves |
|
||||
| Application updates | Docker image pull + restart | Per-app schedule | CI/CD pipeline |
|
||||
|
||||
### unattended-upgrades config (every host):
|
||||
```
|
||||
Unattended-Upgrade::Allowed-Origins {
|
||||
"${distro_id}:${distro_codename}-security";
|
||||
};
|
||||
Unattended-Upgrade::Automatic-Reboot "false";
|
||||
Unattended-Upgrade::Mail "sam@snsnetlabs.com";
|
||||
```
|
||||
|
||||
### Ansible patch playbook (weekly):
|
||||
```yaml
|
||||
# playbooks/patch.yml
|
||||
- hosts: all
|
||||
become: true
|
||||
tasks:
|
||||
- name: Update all packages
|
||||
apt:
|
||||
upgrade: safe
|
||||
update_cache: yes
|
||||
|
||||
- name: Check if reboot required
|
||||
stat:
|
||||
path: /var/run/reboot-required
|
||||
register: reboot_file
|
||||
|
||||
- name: Schedule reboot (Sunday 03:00)
|
||||
command: shutdown -r 03:00
|
||||
when: reboot_file.stat.exists
|
||||
```
|
||||
|
||||
## Build Steps
|
||||
|
||||
1. **MeshCentral VM:** Clone Debian 12 template. 2 vCPU, 2GB RAM.
|
||||
```bash
|
||||
# Install
|
||||
apt install nodejs npm
|
||||
mkdir /opt/meshcentral && cd /opt/meshcentral
|
||||
npm install meshcentral
|
||||
node node_modules/meshcentral --install
|
||||
```
|
||||
|
||||
2. **Caddy reverse proxy:** `mesh.internal.sns` → MeshCentral port 443.
|
||||
Gate behind Authelia for web UI access.
|
||||
|
||||
3. **Deploy agents:** MeshCentral generates install scripts per OS.
|
||||
Add to Ansible `base-hardening` role so every new host gets an agent.
|
||||
|
||||
4. **Ansible scheduled runs:**
|
||||
```bash
|
||||
# Cron on Ansible control node (or Gitea Actions scheduled workflow)
|
||||
0 2 * * 0 ansible-playbook /srv/ansible/playbooks/patch.yml
|
||||
```
|
||||
|
||||
5. **Drift detection:**
|
||||
```bash
|
||||
# Weekly: run playbook in check mode, alert on changes
|
||||
ansible-playbook site.yml --check --diff | mail -s "Drift report" sam@snsnetlabs.com
|
||||
```
|
||||
|
||||
## Security Posture
|
||||
|
||||
- **MeshCentral:** Authelia 2FA required. Agent-to-server communication is TLS.
|
||||
No agents phone home to the internet (server is on-prem only via VPN).
|
||||
- **Ansible:** SSH key-only, no passwords. Runs from a dedicated control node.
|
||||
Playbooks in Gitea (version controlled, auditable).
|
||||
- **Patch lag:** Critical security patches land within 24h (unattended-upgrades).
|
||||
Kernel patches within 7 days (next maintenance window).
|
||||
- **Client separation:** MeshCentral device groups + Ansible inventory groups.
|
||||
Each client's hosts are isolated from others.
|
||||
|
||||
## Upgrade Path
|
||||
|
||||
- **Zammad / FreeScout:** Client-facing ticketing when you have 3+ managed clients.
|
||||
- **Rundeck:** If Ansible ad-hoc commands need a web UI for on-call staff.
|
||||
- **Commercial RMM (Tactical RMM):** FOSS alternative with built-in patching if
|
||||
MeshCentral + Ansible combo gets too manual at 50+ endpoints.
|
||||
|
||||
<!-- ponytail: MeshCentral + Ansible instead of commercial RMM. Ceiling: no
|
||||
integrated patching UI, no ticketing. Upgrade: Tactical RMM (FOSS) or
|
||||
add Zammad for tickets when client count justifies it. -->
|
||||
Loading…
Reference in New Issue
Block a user