آموزش بروزرسانی سرور MTA در لینوکس

بروزرسانی سرور MTA در لینوکس فقط به معنی جایگزین‌کردن فایل اجرایی نیست. اگر این کار بدون بکاپ و برنامه انجام شود، ممکن است تنظیمات سرور، ACL، حساب‌های کاربران، Resourceهای اختصاصی یا دیتابیس داخلی پروژه از بین بروند.

روش امن این است که ابتدا از اطلاعات مهم نسخه پشتیبان تهیه کنیم، نسخه جدید MTA Server را در یک پوشه جداگانه نصب کنیم و سپس فقط اطلاعات موردنیاز سرور فعلی را به نسخه جدید منتقل کنیم.

در این آموزش روش بررسی نسخه فعلی، دانلود آخرین نسخه رسمی، تهیه بکاپ، انتقال تنظیمات و Resourceها، حفظ دیتابیس‌ها و تست نهایی سرور را مرحله‌به‌مرحله بررسی می‌کنیم.

چرا باید سرور MTA را بروزرسانی کنیم؟

اجرای نسخه قدیمی برای مدت طولانی می‌تواند باعث ناسازگاری با نسخه‌های جدید کلاینت، باقی‌ماندن باگ‌های برطرف‌شده و مشکلات امنیتی یا عملکردی شود.

دریافت اصلاحات نسخه جدید MTA Server
بهبود سازگاری با کلاینت‌های جدید
رفع برخی Crashها و مشکلات شناخته‌شده
استفاده از قابلیت‌های جدید Server و Lua
بروزرسانی بخش‌های شبکه و سرور
کاهش مشکلات ناشی از نسخه‌های بسیار قدیمی

بروزرسانی را مستقیماً روی نسخه فعال و بدون بکاپ انجام ندهید. ابتدا نسخه جدید را در پوشه جداگانه آماده و آزمایش کنید.

مرحله اول: بررسی نسخه فعلی MTA Server

ابتدا وارد پوشه نصب سرور شوید.

cd /home/mta/multitheftauto_linux_x64

مسیر بالا نمونه است و باید با مسیر واقعی سرور خود جایگزین شود.

در نسخه 64 بیتی دستور زیر را اجرا کنید:

./mta-server64 --version

برای نسخه 32 بیتی:

./mta-server --version

شماره نسخه و Build نمایش‌داده‌شده را یادداشت کنید تا بعد از بروزرسانی بتوانید نتیجه را مقایسه کنید.

بررسی نسخه از داخل کنسول سرور

اگر سرور در حال اجرا است، می‌توانید در کنسول اصلی MTA دستور زیر را نیز وارد کنید:

sver

این دستور نسخه MTA Server را نمایش می‌دهد.

مرحله دوم: مشخص‌کردن معماری سرور

قبل از دانلود فایل جدید، معماری سیستم را بررسی کنید:

uname -m

خروجی رایج در VPSهای امروزی:

x86_64

در این حالت باید نسخه 64 بیتی x86_64 سرور MTA را دانلود کنید.

برای سرورهای ARM ممکن است خروجی مشابه زیر باشد:

aarch64

در این حالت باید بسته ARM64 مناسب دانلود شود.

مرحله سوم: متوقف‌کردن صحیح سرور

قبل از بکاپ و بروزرسانی، سرور باید به‌صورت صحیح متوقف شود تا اطلاعات دیتابیس و فایل‌های تنظیمات در وضعیت پایدار قرار داشته باشند.

در کنسول MTA:

shutdown Server update

سپس مطمئن شوید Process سرور بسته شده است:

ps aux | grep mta-server

اگر MTA را با systemd اجرا می‌کنید، سرویس مربوط را متوقف کنید:

sudo systemctl stop mtaserver

نام Service ممکن است در سرور شما متفاوت باشد.

مرحله چهارم: بکاپ کامل سرور

امن‌ترین کار تهیه نسخه کامل از پوشه سرور قبل از هرگونه تغییر است.

به پوشه والد بروید:

cd /home/mta

سپس یک فایل فشرده از کل سرور بسازید:

tar -czf mta-backup-before-update.tar.gz \
multitheftauto_linux_x64

حجم فایل بکاپ را بررسی کنید:

ls -lh mta-backup-before-update.tar.gz

تا زمانی که نسخه جدید به‌طور کامل تست نشده است، این فایل را حذف نکنید.

فایل‌های مهمی که باید حفظ شوند

مهم‌ترین اطلاعات یک سرور MTA معمولاً در مسیر mods/deathmatch قرار دارند.

فایل یا پوشه	کاربرد	اهمیت
mtaserver.conf	تنظیمات اصلی سرور	بسیار مهم
acl.xml	دسترسی کاربران و Resourceها	بسیار مهم
internal.db	حساب‌های داخلی و Account Data	بسیار مهم
registry.db	دیتابیس داخلی MTA	مهم
resources/	گیم‌مود و Resourceهای سرور	بسیار مهم
logs/	Logهای قبلی	اختیاری

اگر پروژه از MySQL استفاده می‌کند، دیتابیس MySQL داخل پوشه MTA قرار ندارد و باید جداگانه از آن بکاپ تهیه شود.

بکاپ جداگانه از تنظیمات و دیتابیس MTA

علاوه بر بکاپ کامل، می‌توان فایل‌های حساس را جداگانه نیز نگهداری کرد:

mkdir -p /home/mta/mta-important-backup

cp multitheftauto_linux_x64/mods/deathmatch/mtaserver.conf \
/home/mta/mta-important-backup/

cp multitheftauto_linux_x64/mods/deathmatch/acl.xml \
/home/mta/mta-important-backup/

cp multitheftauto_linux_x64/mods/deathmatch/internal.db \
/home/mta/mta-important-backup/

cp multitheftauto_linux_x64/mods/deathmatch/registry.db \
/home/mta/mta-important-backup/

اگر یکی از فایل‌های دیتابیس در سرور شما وجود ندارد، دستور cp همان فایل خطا می‌دهد و می‌توانید آن خط را نادیده بگیرید.

بکاپ Resourceهای اختصاصی

tar -czf /home/mta/mta-resources-backup.tar.gz \
multitheftauto_linux_x64/mods/deathmatch/resources

این بکاپ مخصوصاً برای سرورهایی که گیم‌مود اختصاصی یا Resourceهای ویرایش‌شده دارند اهمیت زیادی دارد.

بکاپ MySQL قبل از بروزرسانی

اگر گیم‌مود از MySQL یا MariaDB استفاده می‌کند، قبل از بروزرسانی از دیتابیس نیز خروجی بگیرید.

mysqldump -u DATABASE_USER -p DATABASE_NAME \
> /home/mta/mysql-before-mta-update.sql

به‌جای DATABASE_USER و DATABASE_NAME اطلاعات واقعی پروژه را قرار دهید.

مرحله پنجم: دانلود آخرین نسخه رسمی MTA Server

برای نسخه 64 بیتی x86_64 می‌توان از آدرس رسمی MTA استفاده کرد:

cd /home/mta

wget \
https://linux.multitheftauto.com/dl/multitheftauto_linux_x64.tar.gz

اگر فایل قدیمی با همین نام وجود دارد، ابتدا آن را حذف یا تغییرنام دهید.

rm -f multitheftauto_linux_x64.tar.gz

سپس دانلود را دوباره انجام دهید:

wget \
https://linux.multitheftauto.com/dl/multitheftauto_linux_x64.tar.gz

فایل baseconfig را روی سرور فعال کپی نکنید

یکی از مهم‌ترین اشتباهات هنگام بروزرسانی، دانلود baseconfig و کپی مستقیم آن روی mods/deathmatch سرور قبلی است.

baseconfig شامل فایل‌های تنظیمات پیش‌فرض مانند mtaserver.conf است و برای نصب تازه استفاده می‌شود.

در بروزرسانی سرور موجود، baseconfig را روی تنظیمات فعلی Extract یا Move نکنید؛ در غیر این صورت ممکن است تنظیمات قبلی بازنویسی شوند.

مرحله ششم: استخراج نسخه جدید در پوشه جداگانه

به‌جای Extract روی سرور فعلی، ابتدا یک پوشه موقت بسازید:

mkdir -p /home/mta/update-temp
cd /home/mta/update-temp

فایل دانلودشده را در همین مسیر Extract کنید:

tar -xf \
/home/mta/multitheftauto_linux_x64.tar.gz

محتویات را مشاهده کنید:

ls -la

در این مرحله هنوز هیچ فایل نسخه قبلی تغییر نکرده است.

مرحله هفتم: ساخت پوشه نسخه جدید

برای اینکه Rollback ساده باشد، بهتر است نسخه قدیمی و جدید مدتی کنار هم باقی بمانند.

برای نمونه:

cd /home/mta

mv update-temp/multitheftauto_linux_x64 \
multitheftauto_linux_x64_new

اکنون دو پوشه داریم:

multitheftauto_linux_x64
multitheftauto_linux_x64_new

پوشه اول نسخه فعلی و پوشه دوم نسخه جدید است.

مرحله هشتم: انتقال تنظیمات اصلی به نسخه جدید

ابتدا مطمئن شوید مسیر مقصد mods/deathmatch وجود دارد.

mkdir -p \
/home/mta/multitheftauto_linux_x64_new/mods/deathmatch

سپس تنظیمات فعلی را منتقل کنید:

cp \
/home/mta/multitheftauto_linux_x64/mods/deathmatch/mtaserver.conf \
/home/mta/multitheftauto_linux_x64_new/mods/deathmatch/

cp \
/home/mta/multitheftauto_linux_x64/mods/deathmatch/acl.xml \
/home/mta/multitheftauto_linux_x64_new/mods/deathmatch/

انتقال دیتابیس‌های داخلی MTA

برای حفظ حساب‌ها و اطلاعات دیتابیس داخلی، فایل‌های موجود را نیز منتقل کنید:

cp \
/home/mta/multitheftauto_linux_x64/mods/deathmatch/internal.db \
/home/mta/multitheftauto_linux_x64_new/mods/deathmatch/

cp \
/home/mta/multitheftauto_linux_x64/mods/deathmatch/registry.db \
/home/mta/multitheftauto_linux_x64_new/mods/deathmatch/

internal.db را بدون دلیل حذف نکنید. حساب‌های داخلی سرور و Account Data در این فایل قرار دارند.

مرحله نهم: انتقال Resourceهای فعلی

برای انتقال Resourceهای فعلی:

cp -a \
/home/mta/multitheftauto_linux_x64/mods/deathmatch/resources \
/home/mta/multitheftauto_linux_x64_new/mods/deathmatch/

گزینه -a باعث می‌شود ساختار فایل‌ها و Permissionها تا حد امکان حفظ شوند.

آیا باید Default Resourceها را نیز بروزرسانی کنیم؟

MTA بسته جداگانه‌ای برای Resourceهای پیش‌فرض ارائه می‌کند. این بسته شامل Resourceهایی مانند admin، webadmin، scoreboard و سایر Resourceهای استاندارد است.

اما اگر این Resourceها را ویرایش کرده‌اید، Extract مستقیم بسته جدید روی پوشه فعلی ممکن است تغییرات اختصاصی شما را از بین ببرد.

برای سرورهای Production بهتر است ابتدا بسته جدید را در یک مسیر جداگانه Extract و تفاوت‌ها را بررسی کنید.

دانلود آخرین Default Resourceها

cd /home/mta

wget \
https://mirror.multitheftauto.com/mtasa/resources/mtasa-resources-latest.zip

یک پوشه موقت بسازید:

mkdir -p /home/mta/resources-latest

unzip \
mtasa-resources-latest.zip \
-d /home/mta/resources-latest

Resourceهای جدید را قبل از جایگزینی با نسخه فعلی مقایسه کنید.

مقایسه Resourceهای جدید و قدیمی

برای مشاهده تفاوت کلی دو پوشه می‌توان از diff استفاده کرد:

diff -qr \
/home/mta/multitheftauto_linux_x64/mods/deathmatch/resources \
/home/mta/resources-latest

اگر Resourceهای استاندارد را شخصی‌سازی کرده‌اید، تغییرات جدید را دستی Merge کنید.

Resource اختصاصی را با نسخه Default جایگزین نکنید

فرض کنید Resource admin یا scoreboard را برای پروژه خود ویرایش کرده‌اید. Extract مستقیم نسخه جدید ممکن است فایل‌های ویرایش‌شده را حذف یا جایگزین کند.

ابتدا بکاپ بگیرید.
نسخه جدید را در پوشه جداگانه Extract کنید.
فایل‌ها را با diff مقایسه کنید.
تغییرات موردنیاز را Merge کنید.
Resource را روی سرور تست آزمایشی اجرا کنید.

مرحله دهم: بررسی Moduleهای سرور

اگر سرور از Module خارجی استفاده می‌کند، معماری آن باید با نسخه MTA Server مطابقت داشته باشد.

در نسخه x86_64 ماژول‌ها ممکن است در مسیر زیر قرار داشته باشند:

x64/modules/

در نسخه 32 بیتی ممکن است مسیر زیر استفاده شود:

mods/deathmatch/modules/

Module قدیمی را کورکورانه روی نسخه جدید کپی نکنید. ابتدا سازگاری نسخه، معماری CPU و مستندات سازنده Module را بررسی کنید.

بررسی Moduleهای فعال در mtaserver.conf

در فایل mtaserver.conf بخش Moduleها را بررسی کنید.

اگر Module خارجی استفاده نمی‌کنید، این مرحله نیاز به تغییری ندارد.

مرحله یازدهم: بررسی Permission فایل اجرایی

در نسخه 64 بیتی بررسی کنید فایل mta-server64 قابلیت اجرا داشته باشد:

cd /home/mta/multitheftauto_linux_x64_new

chmod +x mta-server64

سپس Version را بررسی کنید:

./mta-server64 --version

شماره Build باید با نسخه جدید دانلودشده مطابقت داشته باشد.

مرحله دوازدهم: اجرای آزمایشی نسخه جدید

نسخه جدید را ابتدا مستقیم از Terminal اجرا کنید:

cd /home/mta/multitheftauto_linux_x64_new

./mta-server64

در کنسول به خطاهای هنگام Startup توجه کنید.

خطای XML در mtaserver.conf
خطای ACL
Resourceهای اجرا نشده
Module ناسازگار
خطای اتصال MySQL
خطای Bind شدن پورت‌ها
مشکل کتابخانه‌های Linux

مشکل Address already in use هنگام تست

اگر نسخه قبلی هنوز روی همان پورت اجرا باشد، نسخه جدید نمی‌تواند روی همان serverport شروع شود.

ابتدا Process قبلی را بررسی کنید:

ps aux | grep mta-server

همچنین پورت اصلی را بررسی کنید:

sudo ss -lunp | grep 22003

برای اجرای Production فقط یک نسخه باید روی پورت اصلی فعال باشد.

مرحله سیزدهم: بررسی Resourceها

پس از اجرای نسخه جدید، فهرست Resourceها را Refresh کنید:

refresh

سپس Resourceهای اصلی پروژه را بررسی کنید.

start admin
start webadmin

نام Resourceهای گیم‌مود شما متفاوت خواهد بود.

بررسی خطاهای Lua پس از بروزرسانی

در هنگام تست Debug را بررسی کنید.

همچنین فایل Log اصلی سرور را بررسی کنید:

tail -f \
mods/deathmatch/logs/server.log

به Error و Warningهای جدید توجه کنید.

بررسی حساب‌های کاربری بعد از بروزرسانی

پس از انتقال internal.db، با یکی از حساب‌های مدیریتی موجود وارد سرور شوید.

login USERNAME PASSWORD

اگر حساب‌های قبلی وجود ندارند، انتقال internal.db را دوباره بررسی کنید.

بررسی ACL

پس از Login بررسی کنید پنل ادمین و دسترسی‌های قبلی همچنان کار می‌کنند.

اگر حساب وجود دارد اما Admin نیست، فایل acl.xml نسخه جدید را با نسخه بکاپ مقایسه کنید.

بررسی اتصال MySQL

اگر گیم‌مود از MySQL استفاده می‌کند، پس از شروع Resource دیتابیس Log اتصال را بررسی کنید.

debugdb 2

سپس فایل زیر را بررسی کنید:

mods/deathmatch/logs/db.log

بعد از پایان عیب‌یابی، Logging کامل دیتابیس را غیرفعال یا کاهش دهید تا فایل Log بیش‌ازحد بزرگ نشود.

مرحله چهاردهم: بررسی پورت‌های سرور

در کنسول MTA دستور زیر را اجرا کنید:

openports

همچنین در Linux بررسی کنید Server روی پورت اصلی Listen می‌کند:

sudo ss -lntup | grep -E '22003|22005|22126'

اگر قبلاً پورت‌های دیگری تنظیم کرده‌اید، شماره‌های واقعی پروژه را جایگزین کنید.

مرحله پانزدهم: تست واقعی با یک Client

قبل از جایگزینی نهایی نسخه قبلی، حداقل این موارد را با MTA Client بررسی کنید:

اتصال به سرور
دانلود Resourceها
Login حساب کاربری
پنل ادمین
گیم‌مود اصلی
ثبت و خواندن اطلاعات MySQL
ساخت یا Load خودرو و Player Data
سیستم‌های اقتصادی و Inventory
Chat و Commandها
Restart Resourceهای اصلی

مرحله شانزدهم: جایگزینی نسخه جدید

فقط زمانی که تمام تست‌ها موفق بودند، نسخه قبلی را تغییرنام دهید:

cd /home/mta

mv multitheftauto_linux_x64 \
multitheftauto_linux_x64_old

نسخه جدید را با نام اصلی قرار دهید:

mv multitheftauto_linux_x64_new \
multitheftauto_linux_x64

اکنون مسیر اصلی سرور به نسخه جدید اشاره می‌کند.

راه‌اندازی مجدد سرویس systemd

اگر Service شما از همان مسیر اصلی استفاده می‌کند، آن را دوباره اجرا کنید:

sudo systemctl start mtaserver

و وضعیت سرویس را بررسی کنید:

sudo systemctl status mtaserver

اگر نام Service متفاوت است، نام واقعی آن را جایگزین کنید.

روش Rollback در صورت بروز مشکل

مزیت روش نصب در پوشه جداگانه این است که بازگشت به نسخه قبلی بسیار ساده خواهد بود.

نسخه جدید را متوقف کنید و نام آن را تغییر دهید:

cd /home/mta

mv multitheftauto_linux_x64 \
multitheftauto_linux_x64_failed

نسخه قبلی را برگردانید:

mv multitheftauto_linux_x64_old \
multitheftauto_linux_x64

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

چرا روش نصب جداگانه بهتر از Overwrite مستقیم است؟

روش	مزیت	ریسک
Overwrite مستقیم	سریع	احتمال بازنویسی یا ترکیب فایل‌های قدیمی و جدید
نصب در پوشه جداگانه	تست و Rollback آسان	نیاز به چند مرحله بیشتر

برای سرور Production، روش دوم کنترل و امنیت بیشتری ایجاد می‌کند.

اشتباهات رایج هنگام بروزرسانی MTA

بروزرسانی بدون بکاپ
Extract مستقیم روی سرور فعال
استفاده از baseconfig روی نصب قبلی
حذف internal.db
فراموش‌کردن acl.xml
از بین بردن Resourceهای اختصاصی
جایگزینی Default Resourceهای ویرایش‌شده
فراموش‌کردن بکاپ MySQL
کپی Module ناسازگار
انتخاب معماری اشتباه
تست نکردن نسخه جدید قبل از Production
حذف فوری نسخه قدیمی
بررسی نکردن Logها
بررسی نکردن پورت‌ها پس از بروزرسانی

خطای Permission denied بعد از بروزرسانی

اگر هنگام اجرای سرور این خطا را مشاهده کردید:

Permission denied

Permission فایل اجرایی را اصلاح کنید:

chmod +x mta-server64

خطای کتابخانه Linux بعد از بروزرسانی

اگر Server هنگام شروع نام یک Shared Library را به‌عنوان Missing نمایش می‌دهد، ابتدا Packageهای سیستم را بروزرسانی کنید.

در Ubuntu و Debian:

sudo apt update
sudo apt upgrade

سپس پیام دقیق کتابخانه گمشده را بررسی کنید. نصب یک Symlink یا Library تصادفی بدون بررسی نسخه و معماری می‌تواند مشکل جدیدی ایجاد کند.

Resource بعد از بروزرسانی Start نمی‌شود

اگر فقط یک Resource مشکل دارد:

meta.xml را بررسی کنید.
خطاهای Lua را بررسی کنید.
Dependencyها را بررسی کنید.
ACL موردنیاز Resource را بررسی کنید.
Exportهای Resource دیگر را بررسی کنید.
تغییرات API نسخه جدید را بررسی کنید.
درصورت استفاده از Module، سازگاری آن را بررسی کنید.

حساب‌های ادمین بعد از بروزرسانی ناپدید شده‌اند

اگر Accountها وجود ندارند، ابتدا بررسی کنید فایل internal.db نسخه قبلی منتقل شده باشد.

ls -lh mods/deathmatch/internal.db

اگر Account وجود دارد ولی Admin نیست، acl.xml را بررسی کنید.

اطلاعات اسکریپت داخلی ناپدید شده است

اگر Resourceهایی که از دیتابیس داخلی MTA استفاده می‌کنند اطلاعات قبلی را پیدا نمی‌کنند، فایل registry.db را بررسی کنید.

ls -lh mods/deathmatch/registry.db

بعد از بروزرسانی چه فایل‌هایی را فوراً حذف نکنیم؟

نسخه کامل قبلی سرور
فایل بکاپ tar.gz
internal.db قبلی
registry.db قبلی
acl.xml قبلی
mtaserver.conf قبلی
بکاپ MySQL
Resourceهای قبلی

این فایل‌ها را حداقل تا زمانی نگه دارید که نسخه جدید چند روز بدون مشکل کار کرده باشد.

چک‌لیست قبل از بروزرسانی

نسخه فعلی ثبت شده است.
معماری CPU مشخص شده است.
سرور صحیح متوقف شده است.
بکاپ کامل گرفته شده است.
mtaserver.conf بکاپ دارد.
acl.xml بکاپ دارد.
internal.db بکاپ دارد.
registry.db بکاپ دارد.
Resourceها بکاپ دارند.
MySQL درصورت استفاده بکاپ دارد.
فضای آزاد دیسک کافی است.

چک‌لیست بعد از بروزرسانی

نسخه جدید با –version تأیید شده است.
Server بدون Error اجرا می‌شود.
mtaserver.conf صحیح است.
ACL و Adminها کار می‌کنند.
internal.db منتقل شده است.
registry.db منتقل شده است.
Resourceهای اصلی Start می‌شوند.
اتصال MySQL برقرار است.
بازیکنان می‌توانند متصل شوند.
Resourceها دانلود می‌شوند.
پورت‌ها باز هستند.
Server Log بررسی شده است.
گیم‌مود اصلی تست شده است.
نسخه قبلی هنوز برای Rollback موجود است.

ترتیب پیشنهادی بروزرسانی سرور MTA

نسخه فعلی را بررسی کنید.
معماری سیستم را مشخص کنید.
سرور را متوقف کنید.
از کل پوشه سرور بکاپ بگیرید.
از MySQL بکاپ تهیه کنید.
نسخه جدید را از سایت رسمی دانلود کنید.
آن را در پوشه جداگانه Extract کنید.
mtaserver.conf و acl.xml را منتقل کنید.
internal.db و registry.db را منتقل کنید.
Resourceهای فعلی را منتقل کنید.
Moduleهای خارجی را بررسی کنید.
نسخه جدید را مستقیم از Terminal اجرا کنید.
Logها را بررسی کنید.
Resourceها و دیتابیس را تست کنید.
با Client به سرور متصل شوید.
پس از تأیید کامل، نسخه جدید را Production کنید.
نسخه قدیمی را برای Rollback نگه دارید.

جمع‌بندی

برای بروزرسانی سرور MTA در لینوکس، امن‌ترین روش این است که نسخه جدید را در یک پوشه جداگانه نصب کنید و بدون دست‌زدن به نسخه فعلی آن را آماده کنید.

فایل‌های mtaserver.conf، acl.xml، internal.db، registry.db و پوشه resources مهم‌ترین اطلاعاتی هستند که باید قبل از انتقال بررسی و از آن‌ها بکاپ تهیه شود.

از کپی baseconfig روی نصب قبلی خودداری کنید و Default Resourceهای جدید را نیز بدون بررسی روی Resourceهای ویرایش‌شده جایگزین نکنید.

پس از بروزرسانی، Version، Logها، ACL، حساب‌ها، دیتابیس، Resourceها و پورت‌ها را آزمایش کنید و تا زمان اطمینان کامل نسخه قبلی را برای Rollback نگه دارید.

برای نصب اولیه سرور، راهنمای آموزش ساخت سرور MTA روی VPS لینوکس را مطالعه کنید.

برای نصب Resourceها نیز مقاله آموزش نصب Resource در MTA و رفع خطاهای اجرا را ببینید.

اگر پس از بروزرسانی بازیکنان نمی‌توانند متصل شوند، راهنمای باز کردن پورت‌های سرور MTA در لینوکس را بررسی کنید.

برای بررسی مشکلات نسخه، Resourceها و زیرساخت سرور می‌توانید از خدمات پشتیبانی فنی گیم‌سرور و راه‌اندازی و کانفیگ سرور MTA استفاده کنید.

پرسش‌های متداول

چگونه نسخه MTA Server را در لینوکس بررسی کنیم؟

در نسخه x86_64 دستور ./mta-server64 –version را در پوشه سرور اجرا کنید. از داخل کنسول سرور نیز می‌توانید از دستور sver استفاده کنید.

آیا برای بروزرسانی باید baseconfig را دوباره نصب کنیم؟

خیر. baseconfig برای نصب جدید است و کپی آن روی سرور موجود ممکن است فایل‌های تنظیمات فعلی را بازنویسی کند.

حساب‌های MTA در کدام فایل ذخیره می‌شوند؟

حساب‌های داخلی و Account Data سرور در فایل internal.db ذخیره می‌شوند؛ بنابراین این فایل باید در بکاپ و انتقال نسخه جدید حفظ شود.

آیا Resourceها با بروزرسانی MTA حذف می‌شوند؟

اگر از روش نصب در پوشه جداگانه استفاده کنید، Resourceهای فعلی دست‌نخورده باقی می‌مانند و بعداً آن‌ها را به نسخه جدید منتقل می‌کنید.

آیا Default Resourceها را هم باید بروزرسانی کنیم؟

در صورت نیاز می‌توان آخرین بسته رسمی Resourceها را دریافت کرد؛ اما Resourceهای ویرایش‌شده را نباید بدون مقایسه مستقیم جایگزین کرد.

اگر نسخه جدید مشکل داشت چه کار کنیم؟

اگر پوشه نسخه قبلی را حفظ کرده باشید، Server جدید را متوقف کنید و نسخه قبلی را دوباره روی مسیر اصلی قرار دهید.

آیا MySQL با بروزرسانی MTA حذف می‌شود؟

خیر؛ MySQL معمولاً سرویس جداگانه‌ای است. بااین‌حال قبل از هر بروزرسانی مهم بهتر است از دیتابیس پروژه نیز بکاپ تهیه شود.