Cara Betulkan Jam VPS Tidak Tepat dan Masa Lari

Mengapa jam VPS anda tidak tepat

Jam VPS tidak tepat kerana tiada proses yang membetulkannya. Kernel mengira masa berdasarkan pembilang perkakasan yang berjalan sedikit laju atau sedikit perlahan, dan tanpa klien penyelarasan masa yang berjalan, ralat kecil tersebut akan terkumpul setiap jam. Di dalam mesin maya, terdapat punca kedua: tetamu anda berkongsi CPU fizikal dengan tetamu lain, jadi detik apabila ia tidak dijadualkan adalah detik ia tidak dapat mengira masa.

Pada tetamu KVM semasa, pembilang itu sendiri jarang menjadi masalah sebenar. Sumber kvm-clock paravirtual membaca nilai yang diselenggara oleh hos, jadi tetamu yang sihat akan menjejaki hosnya dengan rapat. Jam yang jelas salah biasanya disebabkan oleh punca yang lebih mudah. Tiada daemon penyelarasan yang berjalan, atau dua daemon berjalan dan saling bercanggah, atau port UDP 123 keluar tidak pernah meninggalkan rangkaian pembekal anda. Tetamu mengambil disiplin masanya daripada hos atau daripada NTP (network time protocol), bukan daripada pengayunnya sendiri.

Kesan sebenar jam yang tidak tepat

• Kod pengesahan dua faktor TOTP (time-based one-time password) tidak lagi sepadan, menyebabkan anda terkunci daripada pelayan walaupun kata laluan dan kunci adalah betul.
• Sijil yang dikeluarkan seminit yang lalu ditolak, dan curl memaparkan SSL certificate problem: certificate is not yet valid.
• apt update menolak repositori dengan E: Release file for ... is not valid yet (invalid for another 1d 2h 3min 4s).
• Tugasan berjadual berjalan pada waktu yang salah, dan jam yang melompat boleh menyebabkan satu tugasan berjalan dua kali manakala yang lain dilangkau.
• Log daripada dua pelayan tidak dapat diselaraskan, menyebabkan garis masa insiden perlu dibina berdasarkan andaian.

Toleransi adalah lebih kecil daripada jangkaan kebanyakan orang. Angka di bawah adalah nilai lalai yang didokumentasikan, bukan ukuran daripada ujian.

[
  {
    "label": "TLS certificate boundary",
    "tolerance_seconds": 0,
    "documented_in": "RFC 5280"
  },
  {
    "label": "chrony steps instead of slewing",
    "tolerance_seconds": 1,
    "documented_in": "Debian and Ubuntu chrony.conf"
  },
  {
    "label": "TOTP code, one time step",
    "tolerance_seconds": 30,
    "documented_in": "RFC 6238"
  },
  {
    "label": "Kerberos clock skew",
    "tolerance_seconds": 300,
    "documented_in": "MIT krb5 default"
  }
]

Kod TOTP dikira daripada pembilang yang bertambah setiap 30 saat, dan kebanyakan pengesah menerima satu langkah di kedua-dua belah pihak. Ralat setengah minit bagi setiap arah adalah jumlah keseluruhan bajet yang dibenarkan. Kerberos jauh lebih bertoleransi, dengan elaun sisihan lalai sebanyak 300 saat. Sijil tidak mempunyai sebarang toleransi: ia disemak berdasarkan detik tetap dengan tempoh tangguh selama 0 saat, jadi jam yang mendahului satu saat akan menolak sijil yang sebenarnya sah sepenuhnya.

Tiga jenis jam, dan jam mana yang penting

Jam sistem adalah jam yang penting. Ia merupakan CLOCK_REALTIME kernel: kiraan saat sejak 1 Januari 1970 UTC, yang disimpan dalam memori dan dibaca oleh semua proses yang memerlukan cap masa. Baris log, semakan sijil, kod TOTP dan masa pengubahsuaian fail semuanya berpunca daripada jam ini. Apabila seseorang menyatakan masa pelayan tidak tepat, jam inilah yang dimaksudkan.

Jam perkakasan, juga dikenali sebagai RTC (real time clock), ialah pembilang berasingan yang terus berjalan semasa mesin dimatikan. Pada mesin fizikal, ia merupakan cip yang disokong oleh bateri. Di dalam tetamu (guest), ia diemulasikan oleh hypervisor, jadi ia sebahagian besarnya adalah artifak hos. Linux membacanya sekali semasa but untuk mendapatkan nilai permulaan, kemudian ia menyimpan kiraannya sendiri. timedatectl mencetaknya pada baris RTC time. Jangan lakukan penyahpepijatan (debug) berdasarkan baris tersebut pada VPS, kerana ia menunjukkan persepsi masa hos dan bukannya status penyelarasan jam sistem anda. Di dalam kontena, biasanya tiada /dev/rtc langsung, jadi hwclock --show akan gagal dengan hwclock: Cannot access the Hardware Clock via any known method..

Clocksource ialah mekanisme yang digunakan oleh kernel untuk mengira masa di antara bacaan tersebut. Tanya kernel anda yang mana satu telah dipilihnya:

cat /sys/devices/system/clocksource/clocksource0/current_clocksource
cat /sys/devices/system/clocksource/clocksource0/available_clocksource

Pada KVM, anda biasanya akan melihat kvm-clock. Ia membaca nilai yang diselenggara oleh hos, itulah sebabnya tetamu KVM tanpa klien NTP masih kekal tepat untuk tempoh masa tertentu. tsc ialah pembilang CPU itu sendiri. Tetamu Xen melaporkan xen, dan tetamu Hyper-V melaporkan sumber hyperv. Jangan ubah tetapan ini melainkan anda mempunyai alasan yang terukur untuk berbuat demikian, kerana kernel sudah memilih sumber terbaik yang dipercayainya pada perkakasan tersebut.

Sesetengah hos juga memberikan peranti PTP (precision time protocol) kepada tetamu, yang membolehkan chrony membaca jam hos secara terus dan bukannya melalui rangkaian. Ia berbaloi untuk disemak, dan ia sering tidak tersedia pada VPS kongsi:

sudo modprobe ptp_kvm
ls /dev/ptp*
cat /sys/class/ptp/ptp0/clock_name

Jika modprobe gagal atau tiada peranti muncul, hos anda tidak menawarkannya dan NTP rangkaian adalah jawapan anda. Jika clock_name menamakan jam maya KVM, chrony boleh menggunakannya dengan baris refclock PHC /dev/ptp0 poll 2 dalam konfigurasinya.

Baca status masa pada mesin anda sendiri

Mulakan dengan satu arahan. Ia menjawab soalan "adakah sesuatu yang memastikan jam ini tepat" dalam satu skrin.

timedatectl

Baca baris-baris ini daripada mempercayai nombor yang anda ingat:

• Local time dan Universal time adalah detik yang sama yang dicetak dalam zon anda dan dalam UTC. Jika ia serupa, mesin tersebut sudah berada pada waktu UTC.
• RTC time ialah jam perkakasan yang diterangkan di atas. Pada VPS, abaikan perkara ini.
• Time zone ialah apa yang digunakan oleh sistem untuk memformat waktu tempatan.
• System clock synchronized ialah flag kernel itu sendiri. Daemon masa menetapkannya sebaik sahaja ia mempercayai sumbernya, jadi no bermakna tiada apa yang telah menyelaraskan jam ini sejak but.
• NTP service melaporkan tentang systemd-timesyncd secara khusus. n/a adalah normal pada mesin yang menjalankan chrony, kerana timesyncd tidak dipasang di sana. System clock synchronized: yes bersama-sama dengan NTP service: n/a bermakna chrony sedang melakukan tugasnya dan kernel bersetuju dengannya.

Seterusnya, tanya sejauh mana ralat masa anda. Jangan bandingkan secara kasar dengan telefon anda. Jika chrony sedang berjalan:

chronyc tracking
chronyc sources -v

chronyc tracking mencetak nombor yang menjawab soalan tersebut. System time ialah offset semasa daripada waktu NTP, diikuti dengan perkataan fast atau slow. Last offset ialah saiz pembetulan terkini. Frequency ialah ralat kadar yang telah diukur oleh chrony pada jam anda dan sedang dikompensasikan. Leap status sepatutnya membaca Normal. Jika ia membaca Not synchronised dan Reference ID ialah 00000000 (), chrony belum menetapkan sumber lagi.

chronyc sources -v mencetak legenda di atas senarai, supaya anda tidak perlu mengingati simbol-simbol tersebut. Dua lajur membawa kebanyakan maksud. Aksara status pada permulaan setiap baris ialah cara chrony menilai sumber tersebut, di mana * menandakan sumber yang sedang digunakannya dan ? pada setiap baris bermakna tiada apa yang menjawab. Reach ialah sejarah balasan bagi lapan poll terakhir yang dicetak dalam oktal: 377 bermakna kesemua lapan telah dijawab, 0 bermakna tiada satu pun yang dijawab.

Jika systemd-timesyncd yang bertanggungjawab:

timedatectl timesync-status
timedatectl show-timesync --all

timesync-status mencetak pelayan yang dihubungi, selang poll dan nilai Offset. Jika arahan mengembalikan ralat tentang servis dan bukannya mencetak status, timesyncd bukanlah daemon yang bertanggungjawab pada kotak ini, yang dengan sendirinya merupakan jawapan kepada soalan anda.

Untuk pemeriksaan kasar terhadap dunia luar tanpa alat tambahan, bandingkan jam anda dengan header HTTP Date awam, yang dihidangkan dalam GMT dengan resolusi satu saat:

date -u
curl -sI https://www.cloudflare.com | grep -i '^date:'

Perbezaan satu atau dua saat di sini adalah normal dan tidak bermakna apa-apa. Perbezaan satu minit adalah ralat anda.

chrony atau systemd-timesyncd pada VPS

Ubuntu dan Debian menyertakan systemd-timesyncd secara lalai. Ia merupakan klien SNTP (simple network time protocol): ia menyoal satu pelayan pada satu masa dan melaraskan jam ke arah pelayan tersebut. Bagi mesin yang sentiasa dalam talian dan bermula dengan masa yang hampir tepat, ini sudah memadai dan kos sumbernya hampir sifar.

chrony ialah implementasi NTP penuh dan merupakan pilihan lalai yang lebih baik pada mesin maya, atas sebab yang boleh dilihat pada outputnya sendiri. Ia meninjau beberapa sumber serentak dan membuang sumber yang tidak selari. Ia mengukur ralat kadar jam anda dan menulisnya ke dalam fail drift, jadi ia membetulkan kecenderungan jam tersebut dan bukannya mengejar setiap sampel. Ia juga pulih dengan pantas daripada dua perkara yang dilakukan oleh VM tetapi tidak oleh mesin fizikal: ia boleh dihentikan sementara oleh hosnya, dan ia boleh dipindahkan ke hos lain semasa sedang berjalan. Apabila peranti PTP hos ditawarkan, chrony adalah perisian yang membacanya.

sudo apt update && sudo apt install -y chrony
systemctl status chrony --no-pager
chronyc sources -v
chronyc tracking

Baca output apt semasa ia berjalan. Pada Debian dan Ubuntu, pakej chrony dan systemd-timesyncd kedua-duanya menyediakan time-daemon, jadi apt akan membuang timesyncd apabila ia memasang chrony. Ini adalah betul dan diingini. Jangan sekali-kali menjalankan kedua-duanya, kerana dua daemon yang menetapkan jam yang sama akan bercanggah dan offset yang dilaporkan oleh mana-mana satu daripadanya tidak boleh dipercayai semasa ia berlaku. Pada Rocky dan AlmaLinux, pasang dengan sudo dnf install -y chrony, di mana unitnya dipanggil chronyd dan bukannya chrony.

Fail konfigurasi ialah /etc/chrony/chrony.conf pada Debian dan Ubuntu, dan /etc/chrony.conf pada Rocky dan Alma. Lalai pengedaran sudah memadai untuk VPS, jadi ubah ia hanya jika perlu. Dua arahan yang perlu difahami:

• Baris pool dan server menamakan sumber masa. Menambah iburst memberitahu chrony untuk menghantar burst pantas semasa permulaan, supaya penyelarasan pertama berlaku dalam beberapa saat dan bukannya beberapa minit.
• makestep menentukan bila chrony melompatkan jam dan bukannya melaraskannya secara perlahan. Semak tetapan anda dengan grep -n makestep /etc/chrony/chrony.conf. Lalai Debian dan Ubuntu, makestep 1 3, bermaksud: semasa tiga kemas kini pertama selepas chronyd bermula, lompatkan jam jika ia tersasar lebih daripada satu saat, dan selepas itu buat pembetulan secara perlahan (slewing) sahaja.

Jika anda mahukan trafik masa disahkan bagi mengelakkan gangguan pada laluan, chrony 4 dan versi lebih baharu menyokong NTS (network time security). Sahkan versi anda dengan chronyd -v terlebih dahulu, dan ambil perhatian bahawa NTS memerlukan port TCP keluar 4460 dibuka selain daripada UDP 123:

server time.cloudflare.com iburst nts

Mulakan semula dan sahkan sebelum anda mempercayainya. Konfigurasi yang gagal dihuraikan akan menyebabkan anda tidak mempunyai daemon masa langsung, dan jam tidak akan memberitahu anda tentang perkara itu.

sudo systemctl restart chrony
chronyc sources -v
chronyc tracking

Mengapa jam yang tersalah beberapa minit kekal salah

Daemon masa mempunyai dua cara untuk membetulkan offset. Slewing mempercepatkan atau memperlahankan jam sehingga ralat hilang, yang memastikan masa terus bergerak ke hadapan dan tidak pernah mengulang atau melangkau cap masa. Stepping melompat terus ke nilai yang betul, yang pantas dan boleh menggerakkan jam ke belakang. Pergerakan ke belakang adalah berbahaya bagi apa-apa yang mengukur masa berlalu daripada jam dinding, jadi kedua-dua daemon lebih mengutamakan slewing.

Keutamaan itulah sebabnya jam yang sangat salah boleh kekal salah untuk tempoh yang lama. chrony hanya melakukan stepping di dalam tetingkap yang dibenarkan oleh makestep, yang secara lalai adalah beberapa kemas kini pertama selepas daemon bermula. chronyd yang telah berjalan selama seminggu dan kemudian menemui ralat empat puluh saat akan melakukan slewing, dan slewing selama empat puluh saat mengambil masa yang jauh lebih lama daripada yang anda mahukan. Paksa ia sekali, secara sengaja, pada waktu yang tenang:

sudo chronyc makestep
chronyc tracking

chronyc tracking kini sepatutnya melaporkan offset System time yang hampir kepada sifar, dan Last offset sepatutnya menunjukkan saiz apa yang baru sahaja dibetulkan. Fikirkan dahulu sebelum menjalankan ini pada hos pangkalan data yang sibuk, kerana jam yang melompat ke belakang boleh mengelirukan perisian yang menganggap masa hanya bergerak ke hadapan. Memulakan semula daemon adalah versi yang lebih lembut bagi pembetulan yang sama, kerana tetingkap makestep dibuka semula semasa permulaan.

Kontena berkongsi jam hos

Kontena tidak mempunyai jam dinding sendiri, jadi tiada apa yang perlu diselaraskan di dalamnya. Namespace masa Linux hanya memvirtualisasikan jam monotonik dan jam masa but. CLOCK_REALTIME tidak divirtualisasikan, yang bermaksud kontena membaca jam sistem yang sama dengan hos tempat ia dijalankan. Betulkan jam pada hos dan setiap kontena pada hos tersebut akan dibetulkan pada saat yang sama.

Beberapa akibat timbul daripada perkara ini. Jangan pasang chrony atau ntpd dalam imej, kerana paling baik pun ia tidak melakukan apa-apa. Menetapkan tarikh di dalam kontena yang tidak mempunyai keistimewaan (unprivileged) akan gagal dengan date: cannot set date: Operation not permitted, kerana kernel memerlukan CAP_SYS_TIME untuk panggilan tersebut. Memberikan CAP_SYS_TIME tidak memberikan kontena jam peribadi, ia memberikan kontena keupayaan untuk menukar jam hos dan oleh itu jam setiap kontena lain juga.

Zon masa yang berbeza di dalam kontena bukanlah masalah jam. Imej yang membawa /etc/localtime sendiri mencetak detik yang sama yang diformatkan untuk zon lain, jadi date kelihatan salah sedangkan jam adalah tepat. Tetapkan TZ=UTC dalam persekitaran kontena dan kekeliruan tersebut akan hilang. Runtime yang anda pilih tidak mengubah apa-apa di sini, dan perbandingan Podman dan Docker tanpa root merangkumi perkara yang ia ubah.

Zon masa: UTC pada pelayan, waktu tempatan untuk pengguna

Tetapkan mesin kepada UTC dan kekalkan tetapan tersebut.

timedatectl list-timezones | grep -i utc
sudo timedatectl set-timezone UTC
timedatectl

UTC tidak mempunyai waktu penjimatan siang (daylight saving), dan itulah hujah utamanya. Tugasan harian pada pukul 02:30 di zon yang mematuhi waktu penjimatan siang akan berjalan dua kali pada hari jam dianjak ke belakang, dan tidak berjalan langsung pada hari jam dianjak ke hadapan. man 8 cron mendokumentasikan pengendalian khas untuk anjakan kurang daripada tiga jam: tugasan yang dilangkau oleh anjakan ke hadapan akan dijalankan sejurus selepas perubahan tersebut, dan tugasan yang terperangkap dalam jam berulang akibat anjakan ke belakang tidak akan dijalankan buat kali kedua. Kelakuan tersebut adalah munasabah, namun ia tetap kelakuan yang tidak sepatutnya perlu anda fikirkan pada pukul 03:00. Di bawah UTC, tugasan berjalan sekali sehari, setiap hari sepanjang tahun. Jika tugasan anda hilang sepenuhnya dan bukannya berjalan pada waktu yang ganjil, sebab-sebab tugasan cron tidak berjalan secara senyap adalah penjelasan yang lebih berkemungkinan.

Hujah yang sama terpakai untuk membaca log. journalctl memformat cap masa dalam zon masa sistem, dan journalctl --utc memaksa penggunaan UTC. Dua pelayan dalam dua zon masa menjadikan setiap insiden sebagai latihan penukaran, dan penukaran yang dilakukan di bawah tekanan adalah punca manusia tersalah baca garis masa. Kekalkan sistem pada UTC, simpan cap masa dalam UTC, dan lakukan penukaran hanya pada titik di mana manusia membacanya. Sesiapa yang mahukan bacaan waktu tempatan untuk satu arahan boleh memintanya tanpa perlu mengubah tetapan mesin:

TZ=Europe/Berlin date

Satu lagi baris dalam output timedatectl tergolong dalam bahagian ini. RTC in local TZ sepatutnya berbunyi no. Menetapkannya kepada yes adalah penyelesaian sementara untuk dual-boot Windows pada komputer riba, dan pada pelayan, ia hanya menambah offset yang akan menyusahkan seseorang di kemudian hari. Apabila ia ditetapkan, timedatectl akan mencetak amaran bahawa sistem dikonfigurasikan untuk membaca waktu RTC dalam zon masa tempatan.

Penyelesaian masalah mengikut simptom

Kod dua faktor anda ditolak pada satu pelayan. Periksa jam sistem sebelum anda memeriksa perkara lain. Kod tersebut dijana daripada pembilang yang berubah setiap 30 saat, jadi pelayan yang lewat 90 saat akan mengira kod daripada langkah yang telah pun berlalu pada telefon anda. timedatectl akan memaparkan System clock synchronized: no, atau chronyc tracking akan melaporkan System time offset yang besar. Ini adalah kegagalan yang berbeza daripada kunci yang ditolak secara terus, yang mencetak mesejnya sendiri dan dibincangkan dalam panduan kegagalan pengesahan publickey.

apt update menyatakan fail Release belum sah lagi. Mesej penuh menamakan repositori dan tempoh masa ia kekal tidak sah, contohnya is not valid yet (invalid for another 1d 2h 3min 4s). Jam anda lewat daripada tarikh di dalam fail Release repositori tersebut, dan tempoh masa itu adalah ukuran tepat sejauh mana jam anda ketinggalan. Betulkan jam tersebut. Jangan nyahdayakan semakan tarikh apt untuk melangkauinya, kerana semakan itulah yang menghalang seseorang daripada memberikan anda indeks pakej yang lapuk.

Setiap baris sumber menunjukkan status tidak boleh dicapai dan Reach adalah 0. Tiada apa-apa yang memberi respons, jadi perhatikan trafik keluar (egress) dan bukannya konfigurasi anda. NTP menggunakan port UDP 123 untuk trafik keluar, dan sesetengah rangkaian menapis atau mengubah hala trafik ini. sudo chronyc ntpdata mencetak pembilang bagi setiap sumber termasuk Total TX dan Total RX. Kiraan TX yang meningkat sementara RX kekal sifar bermakna paket anda keluar tetapi tiada apa-apa yang kembali, yang menunjukkan adanya firewall antara anda dan sumber tersebut.

Jam pada mulanya tepat, kemudian berubah. Peristiwa hos menyebabkan perkara ini berlaku. Snapshot yang dipulihkan, guest yang dijeda, atau migrasi langsung (live migration) ke hos lain boleh menyebabkan waktu pada guest ketinggalan berbanding waktu sebenar. chrony akan menyedari perkara ini pada poll seterusnya dan membetulkannya; systemd-timesyncd mungkin menunggu selang poll yang panjang terlebih dahulu. Sahkan daemon bermula semasa but dengan systemctl is-enabled chrony, kerana daemon yang dimulakan secara manual akan hilang selepas but semula yang seterusnya.

Offset adalah kecil tetapi tidak pernah stabil. Periksa CPU steal. Guest yang tidak dijadualkan apabila interrupt pemasa sepatutnya berlaku akan mengalami kelewatan sampel, jadi offset akan berubah-ubah dan bukannya menumpu. top menunjukkan perkara ini sebagai angka st pada baris CPU. Membaca masa CPU steal pada hos kongsi menjelaskan maksud angka tersebut dan perkara yang boleh anda lakukan mengenainya.

Sijil yang baru anda keluarkan ditolak kerana belum sah. curl mencetak SSL certificate problem: certificate is not yet valid, dan pelayar web memaparkan mesej yang serupa. Sijil tersebut tiada masalah; jam yang menyemaknya adalah lewat. Mana-mana mesin boleh menjadi punca, jadi periksa klien dan pelayan. Jika pelayan yang mengeluarkan sijil tersebut adalah mesin yang mempunyai jam yang salah, panduan sijil certbot dan nginx meliputi bahagian pembaharuan bagi persediaan yang sama.

Tambahkannya ke dalam pemeriksaan rutin anda

Penyelarasan masa adalah tetapan waktu but yang gagal secara senyap selepas beberapa bulan. Ini adalah jenis masalah yang dapat dikesan oleh rutin pemeriksaan, tetapi tidak oleh ingatan manusia. timedatectl dan chronyc tracking hanya mengambil masa dua saat untuk dibaca. Jalankannya sebagai sebahagian daripada sepuluh minit pertama pada VPS baharu, dan sekali lagi apabila anda menyemak senarai semak penyelenggaraan pelayan Linux secara berkala. Jika anda lebih suka pemeriksaan itu berjalan sendiri dan memberi amaran apabila offset meningkat, menulis perkhidmatan dan pemasa systemd merangkumi corak untuk unit kecil yang melaporkan status mengikut jadual. Pemeriksaan seperti itu hanyalah skrip ringkas dan bukannya daemon, jadi ia memerlukan Type=oneshot dan bukannya tetapan lalai. Penjelasan mengenai jenis perkhidmatan systemd menerangkan sebab penggunaan jenis yang salah akan menyebabkan unit anda melaporkan kejayaan yang tidak pernah dicapai.

FAQ

Bagaimanakah cara untuk menyemak sama ada jam VPS saya selari?

Jalankan timedatectl dan baca baris System clock synchronized. Itu ialah flag kernel sendiri, yang ditetapkan oleh mana-mana daemon yang mengawal jam tersebut, jadi yes bersama-sama NTP service: n/a adalah normal dan sihat pada mesin yang menggunakan chrony. Untuk saiz ralat, jalankan chronyc tracking dan baca System time, atau jalankan timedatectl timesync-status dan baca Offset jika systemd-timesyncd yang mengawal masa. Untuk semakan terhadap sesuatu di luar mesin, bandingkan date -u dengan header Date yang dikembalikan oleh mana-mana laman HTTPS.

Patutkah saya menggunakan chrony atau systemd-timesyncd pada VPS?

Gunakan chrony pada mana-mana sistem yang penting. systemd-timesyncd ialah klien SNTP yang mengikut satu pelayan, dan ia memadai pada mesin yang sentiasa dalam talian dan bermula dengan masa yang hampir tepat. chrony meninjau beberapa sumber, menolak sumber yang tidak sepadan, mempelajari ralat kadar jam anda, dan pulih dengan cepat selepas jeda hos atau migrasi langsung. Memasang chrony pada Debian atau Ubuntu akan membuang systemd-timesyncd secara automatik, kerana kedua-dua pakej menyediakan time-daemon. Jangan sekali-kali menjalankan dua daemon masa serentak.

Mengapakah kod TOTP saya gagal pada satu pelayan tetapi berfungsi di tempat lain?

Kerana kod TOTP ialah fungsi masa semasa. Kod tersebut datang daripada pembilang yang bertambah setiap 30 saat, jadi pelayan dan telefon anda perlu bersetuju tentang langkah masa yang sedang berjalan. Kebanyakan pengesah menerima satu langkah di kedua-dua belah, yang memberikan kelonggaran kira-kira setengah minit ke setiap arah. Semak timedatectl pada pelayan tersebut. Jika System clock synchronized memaparkan no, betulkan penyelarasan masa dan kod tersebut akan sepadan semula tanpa perlu menukar secret yang dikongsi.

Bolehkah saya menetapkan masa di dalam bekas Docker?

Tidak, dan anda tidak perlu berbuat demikian. Bekas berkongsi CLOCK_REALTIME hos, kerana namespace masa Linux hanya memvirtualisasikan jam monotonik dan jam masa but. Bekas tanpa keistimewaan mendapat date: cannot set date: Operation not permitted, dan menambah CAP_SYS_TIME membolehkannya menukar jam hos dan bukannya memberikan jam sendiri. Selaraskan hos sebaliknya. Masa tempatan yang berbeza di dalam bekas adalah tetapan zon masa, jadi tetapkan TZ dalam persekitaran bekas.

Patutkah pelayan menggunakan UTC atau waktu tempatan?

Gunakan UTC, dengan waktu tempatan digunakan pada titik seseorang membaca output tersebut. UTC tidak pernah berubah mengikut waktu penjimatan siang, jadi tugas harian berjalan sekali sehari sepanjang tahun dan cap masa daripada pelayan yang berbeza akan selari tanpa penukaran. Tetapkannya dengan sudo timedatectl set-timezone UTC. Sesiapa yang mahukan bacaan waktu tempatan boleh meletakkan awalan pada satu arahan, contohnya TZ=America/New_York date, yang tidak mengubah apa-apa pada jam sistem.