# FootChain روی AlmaLinux 9 و cPanel 138 با Podman

این مسیر مخصوص VPS دارای سایت‌های وردپرسی و Apache موجود است. وضعیت فعلی: فایل‌های استقرار و محدودیت‌های ساختاری به‌صورت محلی بررسی شده‌اند؛ اجرای واقعی روی Podman مقصد هنوز انجام نشده است. نصب ea-podman و گزارش `podman version 5.8.2` توسط مالک سرور تأیید شده‌اند. این گزارش، تأیید اجرای rootless یا وجود Compose provider نیست.

## معماری

Apache سی‌پنل همچنان TLS و ورودی عمومی 80/443 را مدیریت می‌کند. فقط VirtualHost مربوط به footchain.sbs به `http://127.0.0.1:18080` پروکسی خواهد شد. Caddy داخلی روی پورت 8080 بدون TLS گوش می‌کند و فرانت، static و API را ارائه می‌کند. فقط Caddy داخلی پورت 18080 روی loopback دارد. PostgreSQL، Redis، Workerها و اسکنر پورت منتشرشده ندارند. Prometheus اختیاری روی loopback:19090 است.

فایل `compose.cpanel.yaml` مستقل است؛ آن را با `compose.yaml` ترکیب نکن. نام پروژه `footchain-cpanel-staging` است تا volumeها و شبکهٔ اختصاصی داشته باشد. bind mountهای تنظیمات SELinux label اختصاصی دارند؛ هیچ مسیر سی‌پنل، WordPress، home کامل کاربر، socket میزبان یا مسیر MySQL به کانتینرها mount نمی‌شود. named volumeها شامل دادهٔ خصوصی، فرانت و static هستند.

برای هر کانتینر سقف حافظه و CPU تعریف شده است؛ این سقف‌ها تضمین ظرفیت بازی یا عدم فشار روی سایت‌ها نیستند. ClamAV تا ۳ گیگابایت حافظه دارد. ساخت فرانت و backend هم می‌تواند بار CPU و دیسک ایجاد کند؛ زمان ساخت باید با توجه به بار واقعی وردپرس‌ها انتخاب شود. فضای رشد PostgreSQL، media، imageها و بکاپ‌ها باید پایش شود.

## بررسی‌های بعدی، بدون نصب یا تغییر تنظیمات

با root:

```bash
getent passwd footchain
grep -H '^footchain:' /etc/subuid /etc/subgid
loginctl show-user footchain -p Linger -p State
getenforce
/usr/sbin/httpd -M 2>/dev/null | grep -E 'proxy_module|proxy_http_module|headers_module'
ss -ltnp | grep -E ':(18080|19090)\b'
command -v podman-compose
command -v docker-compose
```

نبود خروجی برای پورت‌ها یعنی هنگام بررسی listener مشاهده نشده است. خطای loginctl می‌تواند به معنی نبود نشست فعال کاربر باشد. اگر shell کاربر jailshell/nologin است یا محدوده UID/GID وجود ندارد، پیش از ایجاد کانتینر باید توسط مدیر بررسی شود؛ این راهنما آن‌ها را خودکار تغییر نمی‌دهد.

سپس باید در یک نشست SSH واقعی کاربر footchain (Normal Shell) وضعیت rootless، systemd کاربر و provider بررسی شود. صرف نصب Podman به معنی نصب Compose نیست؛ `podman compose` یک wrapper برای provider خارجی است. بستهٔ Docker Engine را برای فراهم‌کردن Compose نصب نکن. انتخاب و نصب provider پس از بررسی مخازن و وابستگی‌ها انجام می‌شود.

```bash
id
podman --version
podman compose version
systemctl --user is-system-running
```

`podman info` و ایجاد اولین کانتینر می‌توانند storage حساب را مقداردهی اولیه کنند؛ آن مراحل پس از پایان بررسی فقط‌خواندنی انجام می‌شوند. ابزار ea-podman نیازمند نشست مناسب کاربر است و استفاده از `su -` جای آن را نمی‌گیرد.

## پیکربندی و بررسی بدون اجرای برنامه

پس از تأیید پیش‌نیازها، بسته در پوشهٔ خصوصی حساب مانند `/home/footchain/apps/footchain-staging` قرار می‌گیرد. `.env.server` با کلیدها و SMTP واقعی در مقصد تنظیم می‌شود؛ سورس و env داخل public_html قرار نمی‌گیرند. نمونهٔ env همان `deploy/beta/.env.server.example` است؛ تمام دامنه‌ها باید به footchain.sbs و DB به یک نام اختصاصی جدید `ftg2_beta_*` تغییر کنند.

در حساب footchain و از پوشه deploy/beta، پس از تنظیم env و نصب provider سازگار:

```bash
python3 release_audit.py
podman compose --env-file .env.server -f compose.cpanel.yaml config --quiet
```

اگر provider گزینه `--quiet` ندارد، از راهنمای همان provider استفاده کن؛ خروجی کامل `config` ممکن است رمزها را آشکار کند و نباید در گفتگو ارسال شود. موفقیت در config، آزمون runtime محسوب نمی‌شود. پیش از اجرا باید build، Compose profiles، health dependencies، init، resource limits، SELinux، نوشتن volume با کاربر برنامه و startup پس از reboot عملاً بررسی شوند.

## اعمال و راه‌اندازی، نیازمند مرحله بعد

`stage.sh`، `backup.sh` و `restore_database.sh` موجود برای Docker هستند؛ آن‌ها را در این استقرار اجرا نکن و صرفاً نام docker را با podman جایگزین نکن. روال پشتیبان‌گیری، restore و راه‌اندازی ماندگار باید برای runtime و user-session مقصد تطبیق و آزمایش شود. تا آن زمان اجرای `up` دستور آمادهٔ انتشار نیست.

نمونهٔ `apache-footchain-ssl.conf.example` فقط برای VirtualHost SSL دامنه footchain.sbs است؛ روی سرور اعمال نشده و فرمانی برای نصب آن اجرا نشده است. پیش از اعمال، باید دامنه در مالکیت اکانت footchain، گواهی AutoSSL معتبر، ماژول‌های proxy/http/headers و نبود قانون ProxyPass متعارض بررسی شوند. برای HTTP از مسیر مدیریت‌شدهٔ سی‌پنل، redirect به HTTPS برقرار می‌شود. Apache به شبکهٔ کانتینرها دسترسی مستقیم لازم ندارد.

اعمال userdata include در سی‌پنل به بازسازی تنظیم و راه‌اندازی مجدد Apache نیاز دارد؛ این کار روی سایت‌های دیگر هم اثر عملیاتی دارد و بدون تأیید مالک سرور انجام نمی‌شود. SELinux و فایروال نیز خاموش نمی‌شوند. اگر SELinux اتصال proxy به loopback را رد کرد، لاگ audit بررسی می‌شود تا راهکار محدود و قابل بازبینی تعیین شود.

بعد از تأیید عملیاتی: بکاپ، build، Migration روی DB اختصاصی، آماده‌سازی جهان، collectstatic و ساخت فرانت، Workerها و infrastructure-beat، readiness و امنیت release بررسی می‌شوند. world scheduler و token bridge طبق profile فعلاً خاموش می‌مانند. فعال‌سازی آن‌ها نیازمند پذیرش جداگانه است. بازیابی Worker، reboot، backup/restore، ایمیل و بازی واقعی هم باید در همین runtime بررسی شوند.

## منابع

- [راه‌اندازی کانتینرهای رسمی سی‌پنل](https://docs.cpanel.net/ea4/containers/easyapache-4-containers/)
- [الزامات نشست ea-podman](https://docs.cpanel.net/ea4/containers/the-ea-podman-script/)
- [Compose provider خارجی در Podman](https://docs.podman.io/en/latest/markdown/podman-compose.1.html)
- [userdata includeهای Apache در سی‌پنل](https://docs.cpanel.net/ea4/apache/modify-apache-virtual-hosts-with-include-files/)