آیا cloud-init بعد از راهاندازی دوباره نام قدیمی را برمیگرداند؟

روی ایمیجهای ما نه. با hostnamectl نام تازهای گذاشتیم، سرور را دوباره راهاندازی کردیم و بعد کاری کردیم که cloud-init بوت بعدی را یک نمونهٔ کاملًا تازه بداند. نام هر دو بار ماند و تغییر ما در /etc/hosts هم ماند. نصب دوباره یک سیستم تازه با نام اصلی به شما میدهد.

چرا sudo بعد از تغییر نام میگوید «unable to resolve host»؟

hostnamectl نام را عوض میکند ولی /etc/hosts را نه، و آنجا 127.0.1.1 هنوز به نام قدیمی اشاره میکند. در Ubuntu آنوقت sudo پیش از هر فرمان «unable to resolve host» مینویسد. در سطر 127.0.1.1 نام قدیمی را با نام تازه عوض کنید تا هشدار برود.

سرورم با UTC کار کند یا با وقت محلی من؟

UTC انتخاب امنتری است: زمان لاگهای سرورهای مختلف با هم جور درمیآید و با تغییر ساعت تابستانی پرشی پیش نمیآید. اگر میخواهید کارهای cron و زمان لاگها به وقت خودتان خوانده شوند، به منطقهٔ خودتان بروید. هر دو کار میکنند و هر وقت خواستید میتوانید دوباره عوض کنید.

آیا باید NTP را تنظیم کنم؟

نه. ایمیجهای Ubuntu و Debian ما از همان بوت اول ساعت را با systemd-timesyncd همگام میکنند. timedatectl را اجرا کنید و دنبال «System clock synchronized: yes» بگردید.

آیا تغییر منطقهٔ زمانی کارهای cron مرا خراب میکند؟

cron بلافاصله از منطقهٔ تازه استفاده میکند. روی سرور Ubuntu 24.04 ما، کاری که برای 09:48 به وقت توکیو تنظیم شده بود، بدون راهاندازی دوبارهٔ cron، ساعت 09:48:01 به وقت توکیو اجرا شد. اما کارهایی را که برای UTC نوشته شدهاند بررسی کنید: حالا در آن ساعت به وقت محلی شما اجرا میشوند.

تغییر نام سرور و منطقهٔ زمانی در VPS

نام سرورتان را عوض کنید و ساعتش را روی منطقهٔ زمانی خودتان بگذارید، در Ubuntu، Debian و Windows Server، بدون هشدار sudo که بعد از hostnamectl تنها ظاهر می‌شود، و با بررسی cron، لاگ‌ها و همگام‌سازی زمان بعد از تغییر. همهٔ مراحل روی ایمیج‌های خودمان آزمایش شده‌اند.

سرور تازه همان نامی را دارد که موقع سفارش نوشتید و ساعتش روی UTC است. عوض کردن هر دو ساده است. تغییر نام یک گیر دارد: فرمان معمول یک سطر قدیمی در /etc/hosts باقی می‌گذارد و در Ubuntu، sudo پیش از هر فرمان از آن شکایت می‌کند. این راهنما هر دو را در Ubuntu و Debian درست می‌کند و فرمان‌های Windows Server را هم نشان می‌دهد. همهٔ مراحل را روی ایمیج‌های خودمان اجرا کردیم.

به یک کاربر با sudo نیاز دارید. راهنمای راه‌اندازی Ubuntu یکی می‌سازد.

1. نام و زمان فعلی را ببینید

hostnamectl
timedatectl

سرور تازهٔ Ubuntu 24.04 ما نام سفارش را به‌عنوان نام ثابت میزبان نشان داد، همراه با Time zone: Etc/UTC، System clock synchronized: yes و NTP service: active. Debian 12 و 13 هم همین‌طور بودند. همگام‌سازی ساعت از قبل کار می‌کند و لازم نیست NTP نصب کنید.

2. نام سرور را عوض کنید

یک نام کوتاه انتخاب کنید، یا اگر قرار است با رکورد DNS‌ای که در اختیار دارید جور باشد، نام کامل، مثل web1.example.com:

sudo hostnamectl set-hostname web1.example.com

نام بلافاصله عوض می‌شود، اما /etc/hosts هنوز 127.0.1.1 را به نام قدیمی وصل می‌کند. در Ubuntu این فوری خودش را نشان داد:

sudo: unable to resolve host web1.example.com: No address associated with hostname

hostname -f هم به همین شکل شکست خورد. Debian نام را از راه دیگری پیدا کرد و هشداری نشان نداد، ولی /etc/hosts آن هم به همان اندازه کهنه بود. فایل را در هر دو درست کنید:

sudo sed -i 's/^127\.0\.1\.1 .*/127.0.1.1 web1.example.com web1/' /etc/hosts
grep 127.0.1.1 /etc/hosts
hostname -f

بعد از آن sudo ساکت شد، hostname -f مقدار web1.example.com و hostname -s مقدار web1 را چاپ کرد.

توضیح بالای /etc/hosts می‌گوید این فایل را cloud-init مدیریت می‌کند و ممکن است تغییرهایتان از دست برود. روی ایمیج‌های ما cloud-init فقط در بوت اول سرور آن را می‌نویسد. سرور را دوباره راه‌اندازی کردیم و بعد کاری کردیم که cloud-init بوت بعدی را نمونه‌ای تازه بداند. نام و سطر ما در /etc/hosts هر دو بار ماندند.

نام میزبان فقط روی سرور شما وجود دارد. اگر ماشین‌های دیگر باید با این نام به آن برسند، یک رکورد DNS هم اضافه کنید: وصل کردن دامنه به VPS این را توضیح می‌دهد. برای سرور ایمیل رکورد معکوس هم مهم است: تنظیم DNS معکوس را ببینید.

3. منطقهٔ زمانی را عوض کنید

فهرست منطقه‌ها را ببینید و منطقهٔ خود را انتخاب کنید. سرور ما 497 منطقه داشت:

timedatectl list-timezones | grep -i tokyo
sudo timedatectl set-timezone Asia/Tokyo
timedatectl

خود ساعت جابه‌جا نمی‌شود. فقط نحوهٔ نمایش زمان و خوانده شدن برنامه‌های محلی تغییر می‌کند. بعد از رفتن از UTC به Asia/Tokyo این را دیدیم:

چه چیزی	بعد از تغییر
`date`، `journalctl`	فوراً وقت توکیو
cron	فوراً وقت توکیو: کاری که برای 09:48 تنظیم شده بود ساعت 09:48:01 JST اجرا شد، بدون راه‌اندازی دوباره
`/var/log/syslog` (Ubuntu)	تا راه‌اندازی دوبارهٔ rsyslog زمان UTC می‌نوشت
`/etc/timezone` (Ubuntu)	هنوز `Etc/UTC` بود

پس سرویس لاگ و هر چیزی را که مدت طولانی اجرا می‌شود و زمان چاپ می‌کند، مثل برنامهٔ خودتان، دوباره راه‌اندازی کنید:

sudo systemctl restart rsyslog

Debian 12 و 13 rsyslog نصب نمی‌کنند. لاگ‌هایشان فقط در journal است که خودش منطقهٔ تازه را دنبال می‌کند.

چند برنامهٔ قدیمی منطقه را به‌جای تنظیم سیستم از /etc/timezone می‌خوانند. اگر یکی از آن‌ها هنوز UTC نشان می‌دهد، همان نام را آنجا بنویسید و آن برنامه را دوباره راه‌اندازی کنید:

echo Asia/Tokyo | sudo tee /etc/timezone

پیش از تغییر، crontab خود را مرور کنید. سطر 0 3 * * * که برای 03:00 به وقت UTC نوشته شده بود، حالا ساعت 03:00 به وقت توکیو اجرا می‌شود، یعنی نه ساعت زودتر در زمان واقعی.

4. Windows Server

در Windows Server 2022، PowerShell را با دسترسی مدیر باز کنید. تغییر نام به راه‌اندازی دوباره نیاز دارد:

Rename-Computer -NewName web1 -Restart

نام رایانه در Windows حداکثر 15 نویسه است، پس اینجا از نام کوتاه استفاده کنید.

برای منطقهٔ زمانی شناسه را پیدا کنید و تنظیمش کنید. بی‌درنگ و بدون راه‌اندازی دوباره اعمال می‌شود:

Get-TimeZone -ListAvailable | Where-Object Id -like '*Tokyo*'
Set-TimeZone -Id 'Tokyo Standard Time'
Get-TimeZone

حالا که وارد شده‌اید، وقت خوبی است تا RDP را ایمن کنید.

کدام پلن

نام میزبان و منطقهٔ زمانی هزینه‌ای ندارند، پس هر پلنی مناسب است: Nano با ماهی $3 برای یک سرور Linux کوچک، Windows-Small با ماهی $11 برای Windows Server 2022. همهٔ پلن‌ها در صفحهٔ VPS هستند و پرداخت با USDT، USDC یا ETH روی شبکه‌های Base، Ethereum یا Polygon انجام می‌شود.