d-bis/proxmox
4
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

ops: oracle publisher LXC 3500/3501, CT migrate docs, Besu/RPC maintenance

Browse Source 
- Provision oracle-publisher on CT 3500 (quoted DATA_SOURCE URLs, dotenv).
- Host-side pct-lxc-3501-net-up for ccip-monitor eth0 after migrate.
- CoinGecko key script: avoid sed & corruption; document quoted URLs.
- Besu node list reload, fstrim/RPC scripts, storage health docs.
- Submodule smom-dbis-138: web3 v6 pin, oracle check default host r630-02.

Made-with: Cursor
This commit is contained in:
defiQUG
2026-03-28 15:22:23 -07:00
parent 56b0abe3d1
commit e0bb17eff7
16 changed files with 530 additions and 45 deletions
Download Patch File Download Diff File Expand all files Collapse all files

33
docs/03-deployment/MIGRATE_CT_R630_01_TO_R630_02.md
View File

@@ -26,7 +26,17 @@ If both show the same cluster and the other node is listed, migration is:
pct migrate <VMID> r630-02 --restart
```
Storage will be copied to the target; choose the target storage when prompted (e.g. `thin1`). Then **delete or leave stopped** the container on r630-01 so the same VMID/IP are only on r630-02.
**CLI caveat:** `pct migrate` may fail if the CT references storages that do not exist on the target (e.g. `local-lvm` on r630-02) or if the source storage ID is inactive on the target (e.g. `thin1` on r630-02 vs `thin1-r630-02`). Remove **stale** `unusedN` volumes only after verifying with `lvs` that they are not the same LV as `rootfs` (see incident note below).
**Recommended (PVE API, maps rootfs to target pool):** use `pvesh` from the source node so disks land on e.g. `thin5`:
```bash
ssh root@192.168.11.11 "pvesh create /nodes/r630-01/lxc/<VMID>/migrate --target r630-02 --target-storage thin5 --restart 1"
```
This is the path that succeeded for **3501** (ccip-monitor) on 2026-03-28.
Storage will be copied to the target. The source volume is removed after a successful migrate. **Do not** use `pct set <vmid> --delete unused0` when `unused0` and `rootfs` both name `vm-<id>-disk-0` on different storages — Proxmox can delete the **only** root LV (Oracle publisher **3500** incident, 2026-03-28).
If the nodes are **not** in a cluster, use the backup/restore method below.
@@ -124,8 +134,8 @@ Containers that free meaningful space on r630-01 and are reasonable to run on r6
| 6401 | indy-alltra-1 | 100G | ✅ Migrated (thin6) |
| 6402 | indy-hybx-1 | 100G | ✅ Migrated (thin6) |
| 5700 | dev-vm | 400G (thin) | ✅ Migrated (thin6) |
| 3500 | oracle-publisher-1 | — | Oracle publisher |
| 3501 | ccip-monitor-1 | — | CCIP monitor |
| 3500 | oracle-publisher-1 | 20G thin1 (was) | **2026-03-28:** root LV accidentally removed; CT **recreated** on r630-02 `thin5` (fresh template). **Redeploy** app + `.env`. |
| 3501 | ccip-monitor-1 | 20G | **2026-03-28:** migrated to r630-02 **`thin5`** via `pvesh … /migrate --target-storage thin5`. **Networking:** unprivileged Ubuntu image may leave **eth0 DOWN** after migrate; `unprivileged` cannot be toggled later. Mitigation: on **r630-02** install `scripts/maintenance/pct-lxc-3501-net-up.sh` to `/usr/local/sbin/` and optional **`@reboot`** cron (see script header). |
**High impact (larger disks):**
@@ -169,6 +179,23 @@ Example:
See the script for exact steps (stop, vzdump, scp, restore, start, optional destroy on source).
**Unprivileged CTs:** `vzdump` often fails with tar `Permission denied` under `lxc-usernsexec`. Prefer **section 1** `pvesh … /migrate` with `--target-storage` instead of this script for those guests.
## 5a. Reprovision Oracle Publisher (VMID 3500) on r630-02
After a fresh LXC template or data loss, from project root (LAN, secrets loaded):
```bash
source scripts/lib/load-project-env.sh # or ensure PRIVATE_KEY / smom-dbis-138/.env
./scripts/deployment/provision-oracle-publisher-lxc-3500.sh
```
Uses `web3` 6.x (POA middleware). If on-chain `updateAnswer` fails, use a `PRIVATE_KEY` for an EOA allowed on the aggregator contract.
## 5b. r630-02 disk / VG limits (cannot automate)
Each `thin1`–`thin6` VG on r630-02 is a **single ~231 GiB SSD** with **~124 MiB `vg_free`**. There is **no** space to `lvextend` pools until you **grow the partition/PV** or add hardware. Guest `fstrim` and migration to `thin5` reduce **data** usage only within existing pools.
---
## 6. References