سرور را می‌توان با نام میزبان یا نشانی IP آن مشخص کرد. اگر نام میزبان در هنگام راه‌اندازی قابل تفکیک نباشد، chronyd در فواصل زمانی افزایشی مجدداً تلاش خواهد کرد، و همچنین زمانی که دستور online در chronyc صادر شود.

رکورد DNS ممکن است در طول زمان تغییر کند. نشانی استفاده‌شده با یک نشانی تازه تفکیک‌شده جایگزین خواهد شد، هنگامی که سرور غیرقابل دسترس شود (یعنی هیچ پاسخ معتبری به ۸ درخواست آخر دریافت نشود)، از حالت همگام خارج شود، یک falseticker شود (یعنی با اکثریت منابع دیگر همخوانی نداشته باشد)، یا فاصله ریشه بیش از حد بزرگ باشد (حد آن می‌تواند با دستورالعمل maxdistance پیکربندی شود). جایگزینی خودکار حداکثر یک بار در هر ۳۰ دقیقه رخ می‌دهد و در هر زمان فقط یک سرور می‌تواند جایگزین شود. همچنین هنگامی که سرور به طور عادی کار می‌کند، نشانی به صورت دوره‌ای تازه‌سازی می‌شود (این فاصله زمانی را می‌توان با دستورالعمل refresh پیکربندی کرد).

این دستورالعمل می‌تواند چندین بار برای مشخص کردن چندین سرور استفاده شود. هر سرور باید نشانی IP متفاوتی داشته باشد تا برای chronyd قابل استفاده باشد. اگر سروری با نام میزبانی مشخص شود که تنها به نشانی‌هایی تفکیک می‌شود که قبلاً توسط سرورهای دیگر استفاده شده‌اند، با آن سرور به عنوان سروری با نشانی ناشناخته رفتار خواهد شد (مثلاً توسط دستور activity در chronyc گزارش می‌شود).

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

minpoll poll

maxpoll poll

iburst

burst

key ID

nts

certset ID

maxdelay delay

maxdelayratio ratio

maxdelaydevratio ratio

maxdelayquant p

mindelay delay

asymmetry ratio

offset offset

minsamples samples

maxsamples samples

maxunreach polls

filter polls

offline

auto_offline

prefer

noselect

trust

require

xleave

polltarget target

port port

ntsport port

presend poll

presend 9

minstratum stratum

version version

copy

extfield type

ipv4, ipv6

این دستورالعمل می‌تواند چندین بار برای تعیین چندین استخر استفاده شود.

تمام گزینه‌های معتبر در دستورالعمل server می‌توانند در این دستورالعمل نیز استفاده شوند. یک گزینه مخصوص دستورالعمل pool وجود دارد:

maxsources sources

pool pool.ntp.org iburst maxsources 3

این دستورالعمل می‌تواند چندین بار برای تعیین چندین همتا استفاده شود.

گزینه‌های زیر از دستورالعمل server در دستورالعمل peer کار نمی‌کنند: iburst، burst، nts، presend، copy.

هنگام استفاده از گزینه xleave، هر دو همتا باید از حالت درهم‌تنیده (interleaved mode) پشتیبانی کرده و آن را فعال داشته باشند؛ در غیر این صورت همگام‌سازی فقط در یک جهت کار خواهد کرد. هنگامی که کلیدی توسط گزینه key برای فعال‌سازی احراز هویت مشخص می‌شود، هر دو همتا باید از همان کلید و همان شماره کلید استفاده کنند.

توجه داشته باشید که حالت متقارن امنیت کمتری نسبت به حالت کلاینت/سرور دارد. یک حمله منع سرویس (denial-of-service) روی ارتباطات متقارن احراز‌نشده امکان‌پذیر است، یعنی زمانی که همتا بدون گزینه key مشخص شده باشد. مهاجمی که ترافیک شبکه بین دو میزبان را نمی‌بیند، اما می‌داند که آن‌ها با یکدیگر ارتباط همتا دارند، می‌تواند به طور دوره‌ای بسته‌های احرازشده‌نشده با آدرس‌های مبدا جعلی برای آن‌ها ارسال کند تا وضعیت NTP آن‌ها را مختل کرده و از همگام‌سازی آن‌ها با یکدیگر جلوگیری کند. هنگامی که ارتباط احراز هویت شده باشد، مهاجمی که ترافیک شبکه را می‌بیند، اما نمی‌تواند مانع رسیدن بسته‌ها به میزبان دیگر شود، همچنان می‌تواند با بازپخش بسته‌های قدیمی وضعیت را مختل کند. مهاجم عملاً همان قدرت یک مهاجم مرد میانی (man-in-the-middle) را دارد. یک حفاظت جزئی در برابر این حمله در chronyd پیاده‌سازی شده است که می‌تواند از همتاها محافظت کند اگر آن‌ها از بازه زمانی پرسش (polling interval) یکسانی استفاده کنند و هرگز بسته‌ای احرازشده با برچسب زمانی از آینده ارسال نکرده باشند، اما نباید به آن تکیه کرد زیرا اطمینان از برآورده شدن این شرایط دشوار است. اگر دو میزبان باید بتوانند در هر دو جهت با یکدیگر همگام شوند، توصیه می‌شود به جای آن از دو ارتباط کلاینت/سرور مجزا (مشخص‌شده توسط دستورالعمل server در هر دو میزبان) استفاده شود.

هدف از دستورالعمل initstepslew این است که به chronyd اجازه دهد اندازه‌گیری سریعی از خطای ساعت سیستم در زمان بوت انجام دهد و ساعت سیستم را با جهش (stepping) قبل از شروع کارکرد عادی تصحیح کند. از آنجا که این کار معمولاً فقط در یک نقطه مناسب در توالی بوت سیستم انجام می‌شود، هیچ نرم‌افزار دیگری نباید تحت تأثیر منفی این جهش قرار گیرد.

اگر تصحیح مورد نیاز کمتر از آستانه مشخص‌شده باشد، به جای آن از تغییر تدریجی (slew) استفاده می‌شود. این امر راه‌اندازی مجدد chronyd را در حین کارکرد عادی سیستم ایمن‌تر می‌کند.

دستورالعمل initstepslew یک آستانه و فهرستی از سرورهای NTP را به عنوان آرگومان می‌پذیرد. هر یک از سرورها به سرعت چندین بار مورد پرسش قرار می‌گیرند و از یک سازوکار رأی‌گیری اکثریت برای یافتن محتمل‌ترین محدوده خطای ساعت سیستم استفاده می‌شود. یک جهش یا تغییر تدریجی برای تصحیح این خطا بر روی ساعت سیستم اعمال می‌گردد. سپس chronyd وارد حالت کارکرد عادی خود می‌شود.

یک مثال از استفاده از این دستورالعمل:

initstepslew 30 ntp1.example.net ntp2.example.net ntp3.example.net

جایی که ۳ سرور NTP برای انجام اندازه‌گیری استفاده می‌شوند. مقدار 30 نشان می‌دهد که اگر خطای سیستم ۳۰ ثانیه یا کمتر تشخیص داده شود، برای تصحیح آن از تغییر تدریجی (slew) استفاده می‌شود؛ اگر خطا بیش از ۳۰ ثانیه باشد، از یک جهش (step) استفاده خواهد شد.

دستورالعمل initstepslew همچنین می‌تواند در یک محیط LAN ایزوله، جایی که ساعت‌ها به صورت دستی تنظیم می‌شوند، استفاده شود. پایدارترین رایانه به عنوان سرور اصلی انتخاب می‌شود و سایر رایانه‌ها کلاینت‌های آن هستند. اگر هر یک از کلاینت‌ها با دستورالعمل local پیکربندی شده باشد، سرور را می‌توان با یک دستورالعمل initstepslew راه‌اندازی کرد که به برخی یا همه کلاینت‌ها اشاره دارد. سپس، اگر دستگاه سرور مجبور به راه‌اندازی مجدد شود، می‌توان به کلاینت‌ها اعتماد کرد که به طور مشابه با یک چرخ طیار (flywheel) عمل کنند و زمان را برای یک دوره کوتاه در حالی که سرور راه‌اندازی مجدد خود را کامل می‌کند، حفظ نمایند.

دستورالعمل initstepslew از نظر عملکردی مشابه ترکیبی از دستورالعمل‌های makestep و server همراه با گزینه iburst است. تفاوت اصلی این است که سرورهای initstepslew تنها پیش از آغاز عملکرد عادی استفاده می‌شوند و فرایند پیش‌زمینه chronyd تا پایان یافتن initstepslew پیش از خروج منتظر می‌ماند. این امر مانع از آن می‌شود که برنامه‌های اجرا شده در توالی راه‌اندازی سیستم پس از chronyd، ساعت را پیش از تنظیم پله‌ای بخوانند. با دستورالعمل makestep، می‌توان به‌جای آن از فرمان waitsync در chronyc استفاده کرد.

این دستورالعمل می‌تواند چندین بار برای تعیین چندین ساعت مرجع استفاده شود.

پنج راه‌انداز در chronyd گنجانده شده است:

PPS

refclock PPS /dev/pps0 lock NMEA refid GPS1
refclock SOCK /var/run/chrony.clk.ttyS0.sock offset 0.5 delay 0.2 refid NMEA noselect
refclock PPS /dev/pps1:clear refid GPS2

SOCK

refclock SOCK /var/run/chrony.ttyS0.sock refid GPS1 poll 2 filter 4
refclock SOCK /var/run/chrony.clk.ttyUSB0.sock refid GPS2 offset 0.2 delay 0.1

SHM

refclock SHM 0 poll 3 refid GPS1
refclock SHM 1:perm=0644 refid GPS2

PHC

refclock PHC /dev/ptp0 poll 0 dpoll -2 offset -37
refclock PHC /dev/ptp1:nocrossts poll 3 pps
refclock PHC /dev/ptp2:extpps:pin=1 width 0.2 poll 2

RTC

refclock RTC /dev/rtc0:utc

poll poll

dpoll dpoll

refid refid

lock refid

rate rate

maxlockage pulses

width width

pps

offset offset

delay delay

stratum stratum

precision precision

maxdispersion dispersion

filter samples

prefer

noselect

trust

require

tai

local

minsamples samples

maxsamples samples

maxunreach polls

توجه داشته باشید که دستور settime می‌تواند در زمان اجرا با استفاده از دستور manual در chronyc فعال شود. (ایده این دو دستور این است که دستور manual رفتار راه‌انداز ساعت دستی را کنترل می‌کند، در حالی که دستور settime اجازه می‌دهد نمونه‌های زمان واردشده به‌صورت دستی ارائه شوند.)

می‌توان آن را روی همان پورتی که توسط سرور NTP استفاده می‌شود (که می‌تواند با دستورالعمل port پیکربندی شود) تنظیم کرد تا فقط از یک سوکت برای تمام بسته‌های NTP استفاده شود.

نمونه‌ای از دستورالعمل acquisitionport:

acquisitionport 1123

این کار پورت مبدأ استفاده‌شده برای درخواست‌های کلاینت را به پورت UDP 1123 تغییر می‌دهد. سپس می‌توانید از مدیر فایروال بخواهید که آن پورت را باز کند.

برای هر یک از پروتکل‌های IPv4 و IPv6، تنها یک دستورالعمل bindacqaddress می‌تواند مشخص شود.

نمونه‌ای از این دستورالعمل:

bindacqdevice eth0

نمونه‌ای از این دستورالعمل (تنظیم کلاس Expedited Forwarding):

dscp 46

تمام سیستم‌های پشتیبانی‌شده، به استثنای macOS 10.12 و پیش از آن، دارای پشتیبانی سیستم‌عامل برای تنظیم نرخ جلو یا عقب افتادن جهت جبران خطاهای شناخته‌شده هستند. (در macOS 10.12 و پیش از آن، chronyd باید چنین قابلیتی را با تغییر تدریجی (slew) دوره‌ای ساعت سیستم به جلو یا عقب به میزان مناسب برای جبران خطای انباشته‌شده از زمان تغییر قبلی شبیه‌سازی کند.)

برای چنین سیستم‌هایی، ذخیره تاریخچه اندازه‌گیری در میان راه‌اندازی‌های مجدد chronyd امکان‌پذیر است (با فرض اینکه هیچ تغییری در رفتار ساعت سیستم در زمان عدم اجرای آن ایجاد نشود). دستورالعمل dumpdir شاخه‌ای را تعریف می‌کند که تاریخچه‌های اندازه‌گیری هنگام خروج chronyd یا اجرای دستور dump در chronyc در آن ذخیره می‌شوند.

اگر شاخه وجود نداشته باشد، به‌طور خودکار ایجاد می‌شود.

گزینه -r در chronyd بارگیری پرونده‌های dump را هنگام شروع فعال می‌کند. تمام پرونده‌های dump یافت‌شده در شاخه پس از شروع حذف خواهند شد، حتی اگر گزینه -r وجود نداشته باشد.

نمونه‌ای از این دستورالعمل:

dumpdir /var/run/chrony

منبعی که آدرس IP آن 1.2.3.4 باشد، تاریخچه اندازه‌گیری‌اش در پرونده /var/run/chrony/1.2.3.4.dat ذخیره می‌شود. تاریخچه ساعت‌های مرجع در پرونده‌هایی با نام شناسه مرجع آن‌ها به صورت refid:XXXXXXXX.dat ذخیره می‌شود.

به‌عنوان یک حالت خاص، تنظیم maxsamples روی 1 ردیابی فرکانس را غیرفعال می‌کند تا منابع بلافاصله و تنها با یک نمونه قابل انتخاب باشند. این می‌تواند زمانی که chronyd با گزینه -q یا -Q شروع می‌شود مفید باشد.

مجبور کردن chronyd به نگهداری نمونه‌های بیشتر از حد معمول، نویز را در فرکانس و آفست برآوردشده کاهش می‌دهد، اما پاسخ‌دهی به تغییرات در فرکانس و آفست ساعت را کُند می‌کند. آفست‌ها در گزارش‌های tracking و sourcestats (و پرونده‌های tracking.log و statistics.log) ممکن است کوچک‌تر از آفست‌های واقعی باشند.

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

فهرست پیش‌فرض شناسه‌ها 30 15 است. AES-128-GCM-SIV به دلیل کلیدهای کوتاه‌تر نسبت به AES-SIV-CMAC-256 ارجحیت دارد، که باعث کوتاه‌تر شدن کوکی‌های NTS می‌شود و قابلیت اطمینان NTS را در شبکه‌هایی که پیام‌های NTP طولانی‌تر را مسدود یا محدود می‌کنند، بهبود می‌بخشد.

شناسه الگوریتم استفاده‌شده برای هر کارساز توسط فرمان authdata گزارش می‌شود.

یک مثال از این دستورالعمل:

ntsaeads 15

این فهرست توسط کارساز NTS نیز استفاده می‌شود.

اگر دایرکتوری وجود نداشته باشد، به صورت خودکار ایجاد خواهد شد.

یک مثال از این دستورالعمل:

ntsdumpdir /var/lib/chrony

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

این بازه باید طولانی‌تر از بازه‌های نظرسنجی تمام منابع NTP پیکربندی‌شده با استفاده از NTS باشد، در غیر این صورت منبع با بازه نظرسنجی طولانی‌تر در هر نظرسنجی کلیدها را تازه‌سازی می‌کند و هیچ بسته NTP مبادله نخواهد شد.

آرگومان اختیاری set-ID عددی در محدوده 0 تا 2^32-1 است که مجموعه گواهی‌هایی را انتخاب می‌کند که گواهی‌های پرونده یا دایرکتوری مشخص‌شده به آن اضافه می‌شوند. شناسه پیش‌فرض 0 است، که مجموعه‌ای حاوی CAهای مورد اعتماد پیش‌فرض سیستم است (مگر اینکه دستورالعمل nosystemcert موجود باشد). تمام مجموعه‌های دیگر به طور پیش‌فرض خالی هستند. یک مجموعه گواهی می‌تواند برای اعتبارسنجی یک کارساز NTS با گزینه certset در دستورالعمل server یا pool انتخاب شود.

این دستورالعمل می‌تواند چندین بار برای تعیین یک یا چند مجموعه از گواهی‌های مورد اعتماد، که هرکدام شامل گواهی‌هایی از یک یا چند پرونده و/یا دایرکتوری هستند، استفاده شود.

در صورت تغییر گواهی‌ها (مثلاً پس از تمدید)، راه‌اندازی مجدد chronyd برای بارگذاری مجدد آن‌ها لازم نیست.

یک مثال:

ntstrustedcerts /etc/pki/nts/ca1.example.net.crt
ntstrustedcerts 1 /etc/pki/nts/ca2.example.net.crt
ntstrustedcerts 1 /etc/pki/nts/ca3.example.net.crt
ntstrustedcerts 2 /etc/pki/nts/ntp2.example.net.crt

یک مثال از این دستورالعمل:

nocerttimecheck 1

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

فرمان refresh می‌تواند برای تازه‌سازی فوری تمام منابع استفاده شود.

هنگامی که اصالت‌سنجی برای یک منبع NTP فعال است، مهم است که منابع NTP بدون اصالت‌سنجی که ممکن است در حمله مورد سوءاستفاده قرار گیرند غیرفعال شوند، مثلاً اگر فقط از طریق یک شبکه مورد اعتماد در دسترس نباشند. به عنوان جایگزین، انتخاب منبع می‌تواند با گزینه‌های require و trust پیکربندی شود تا همگام‌سازی با منابع غیراصالت‌سنجی‌شده تنها در صورتی انجام شود که آن‌ها با منابع اصالت‌سنجی‌شده هم‌نظر باشند و احتمالاً اثر مثبتی بر دقت ساعت داشته باشند. توجه داشته باشید که در این حالت اثر حمله بیشتر است. مهاجمان نمی‌توانند پرش یا انحراف دلخواه بزرگی ایجاد کنند، اما کنترل بیشتری روی بسامد ساعت دارند و می‌توانند باعث شوند chronyd اطلاعات نادرست گزارش دهد، مانند root delay و پراکندگی (dispersion) به مراتب کمتر.

این دستورالعمل گزینه‌های انتخاب پیش‌فرض را برای منابع اصالت‌سنجی‌شده و غیراصالت‌سنجی‌شده تعیین می‌کند تا پیکربندی با پرونده پیکربندی و فرمان‌های chronyc ساده‌تر شود. این دستورالعمل یک خط‌مشی برای اصالت‌سنجی تنظیم می‌کند.

منابع مشخص‌شده با گزینه noselect نادیده گرفته می‌شوند (نه به عنوان اصالت‌سنجی‌شده و نه غیراصالت‌سنجی‌شده شمرده می‌شوند)، و آن‌ها همیشه فقط گزینه‌های انتخاب مشخص‌شده در پیکربندی را دارند.

چهار حالت وجود دارد:

require

prefer

mix

ignore

به عنوان مثال، پیکربندی زیر با استفاده از حالت پیش‌فرض mix:

server ntp1.example.net nts
server ntp2.example.net nts
server ntp3.example.net
refclock SOCK /var/run/chrony.ttyS0.sock

معادل پیکربندی زیر با استفاده از حالت ignore است:

authselectmode ignore
server ntp1.example.net nts require trust
server ntp2.example.net nts require trust
server ntp3.example.net
refclock /var/run/chrony.ttyS0.sock require trust

دستورالعمل combinelimit تعیین می‌کند کدام منابع در الگوریتم ترکیب گنجانده شوند. فاصله همگام‌سازی آن‌ها باید کوتاه‌تر از فاصله منبع انتخاب‌شده ضرب در مقدار حد (limit) باشد. همچنین، فرکانس‌های اندازه‌گیری‌شده آن‌ها باید نزدیک به فرکانس منبع انتخاب‌شده باشد. اگر منبع انتخاب‌شده با گزینه prefer مشخص شده باشد، تنها می‌تواند با سایر منابع مشخص‌شده با این گزینه ترکیب شود.

به‌طور پیش‌فرض، مقدار حد 3 است. تنظیم حد روی 0 الگوریتم ترکیب منابع را عملاً غیرفعال می‌کند و تنها از منبع انتخاب‌شده برای کنترل ساعت سیستم استفاده خواهد شد.

به‌طور پیش‌فرض، حداکثر فاصله ریشه ۳ ثانیه است.

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

به‌طور پیش‌فرض، حداکثر ژیتر ۱ ثانیه است.

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

به‌طور پیش‌فرض، این وزن 0.001 ثانیه است. این بدان معناست که stratum منابع در فرآیند انتخاب تنها زمانی اهمیت دارد که تفاوت بین فاصله‌ها در حد میلی‌ثانیه باشد.

مقدار اندازه‌گیری‌شده در اکثر موارد به خوبی کار می‌کند. با این حال، معمولاً دقت را بیش از حد برآورد می‌کند و می‌تواند به سرعت CPU حساس باشد که ممکن است برای صرفه‌جویی در مصرف انرژی در طول زمان تغییر کند. در برخی موارد با یک منبع ساعت با دقت بالا (مانند Time Stamp Counter مربوط به CPU) و برچسب‌گذاری زمانی سخت‌افزاری، تنظیم دقت روی سرور با یک مقدار کوچک‌تر می‌تواند پایداری اندازه‌گیری‌های NTP کلاینت‌ها را بهبود بخشد. دقت سرور در کلاینت‌ها توسط دستور ntpdata گزارش می‌شود.

یک مثال برای تنظیم دقت روی ۸ نانوثانیه:

clockprecision 8e-9

دستورالعمل corrtimeratio نسبت بین مدت زمانی که ساعت برای یک تصحیح میانگین طبق تاریخچه منبع شیب‌دهی می‌شود و بازه‌ای که در آن تصحیحات انجام می‌شود (معمولاً بازه نظرسنجی NTP) را تعیین می‌کند. تصحیحات بزرگ‌تر از میانگین زمان کمتری می‌برند و تصحیحات کوچک‌تر زمان بیشتری نیاز دارند؛ مقدار تصحیح و زمان تصحیح نسبت معکوس دارند.

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

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

حداکثر نرخ شیب‌دهی مجاز را می‌توان با دستورالعمل maxslewrate تعیین کرد. تصحیح باقی‌مانده فعلی در گزارش tracking به صورت مقدار System time نشان داده می‌شود.

هر زمان که chronyd مقدار جدیدی از نرخ پیشی‌گرفتن یا عقب‌ماندن را محاسبه می‌کند، مطلوب است که آن را در جایی ثبت کند. این کار به chronyd اجازه می‌دهد تا هر زمان که بازراه‌اندازی می‌شود، جبران ساعت سیستم را با همان نرخ آغاز کند، حتی قبل از اینکه فرصت پیدا کند در طول اجرای جدید به تخمین به همان اندازه خوبی از نرخ دست یابد. (این فرآیند می‌تواند حداقل چندین دقیقه طول بکشد.)

دستورالعمل driftfile اجازه می‌دهد پرونده‌ای مشخص شود که chronyd می‌تواند اطلاعات نرخ را در آن ذخیره کند. دو پارامتر در پرونده ثبت می‌شود. اولی نرخی است که ساعت سیستم زمان کسب می‌کند یا از دست می‌دهد، که بر حسب قسمت در میلیون (ppm) بیان می‌شود و مقادیر مثبت نشان‌دهنده جلو افتادن هستند. بنابراین، مقدار 100.0 نشان می‌دهد که وقتی ساعت سیستم یک ثانیه جلو رفته است، در واقعیت ۱۰۰ میکروثانیه جلو افتاده است (بنابراین زمان واقعی تنها ۹۹۹۹۰۰ میکروثانیه پیش رفته است). دومین پارامتر تخمینی از کران خطای اطراف مقدار اول است که نرخ واقعی در آن قرار دارد.

گزینه interval حداقل بازه بین به‌روزرسانی‌های پرونده را به ثانیه مشخص می‌کند. پرونده تنها هنگام به‌روزرسانی ساعت محلی نوشته می‌شود. بازه پیش‌فرض ۳۶۰۰ ثانیه است.

یک مثال از دستورالعمل driftfile:

driftfile /var/lib/chrony/drift

این دستورالعمل کمینه و بیشینه بازه زمانی پس از آخرین به‌روزرسانی ساعت را برای تغییر بین مقادیر انحراف پشتیبان مشخص می‌کند. این مقادیر به‌صورت توانی از ۲ (به ثانیه) تعریف می‌شوند. نحو دستور به شرح زیر است:

fallbackdrift 16 19

در این مثال، کمینه بازه ۱۶ (۱۸ ساعت) و بیشینه بازه ۱۹ (۶ روز) است. بسامد ساعت سیستم ۱۸ ساعت پس از آخرین به‌روزرسانی ساعت روی اولین مقدار پشتیبان، پس از ۳۶ ساعت روی دومین مقدار و به همین ترتیب تنظیم خواهد شد. این ممکن است تنظیم مناسبی برای پوشش تغییرات بسامد ناشی از نوسانات دمایی روزانه و هفتگی باشد. هنگامی که بسامد روی یک مقدار پشتیبان تنظیم شود، وضعیت ساعت به ‘Not synchronised’ تغییر خواهد کرد.

به‌طور پیش‌فرض (یا اگر بیشینه یا کمینه مشخص‌شده ۰ باشد)، هیچ مقدار پشتیبانی استفاده نمی‌شود و بسامد ساعت تنها با اندازه‌گیری‌های جدید از منابع NTP، ساعت‌های مرجع، یا ورودی دستی تغییر می‌کند.

برای ساعت‌های رایانه‌ای این یک مشکل است. زمان Unix به‌صورت تعداد ثانیه‌های سپری‌شده از 00:00:00 UTC در ۱ ژانویه ۱۹۷۰ بدون ثانیه‌های کبیسه تعریف شده است. ساعت سیستم نمی‌تواند زمان 23:59:60 داشته باشد، بر اساس تعریف هر دقیقه ۶۰ ثانیه و هر روز ۸۶۴۰۰ ثانیه دارد. ثانیه کبیسه درج‌شده نادیده گرفته می‌شود و ساعت ناگهان یک ثانیه از UTC جلو می‌افتد. دستورالعمل leapsecmode نحوه تصحیح این خطا را مشخص می‌کند. چهار گزینه وجود دارد:

system

step

slew

ignore

هنگام ارائه زمان به کارخواهان NTP که امکان پیکربندی آن‌ها برای تصحیح ساعت با تنظیم تدریجی در ثانیه کبیسه وجود ندارد، یا کارخواهانی که با نرخ‌های متفاوتی تصحیح می‌کنند در حالی که نزدیک نگه‌داشتن زمان آن‌ها به یکدیگر ضروری است، حالت slew می‌تواند با دستورالعمل smoothtime ترکیب شود تا leap smear سرور فعال گردد.

هنگام پخش تدریجی ثانیه کبیسه (leap smear)، وضعیت کبیسه روی سرور پنهان می‌شود و زمان ارائه‌شده به جای پرش، با تنظیم تدریجی به‌آرامی تصحیح می‌گردد. کارخواهان به هیچ پیکربندی خاصی نیاز ندارند زیرا از وجود ثانیه کبیسه مطلع نمی‌شوند و از زمان سرور پیروی می‌کنند که در نهایت آن‌ها را به UTC بازمی‌گرداند. باید دقت شود که آن‌ها برای همگام‌سازی فقط از سرورهای NTP استفاده کنند که ثانیه کبیسه را دقیقاً به همان روش پخش تدریجی می‌کنند.

این ویژگی باید با احتیاط استفاده شود، زیرا سرور عمداً بهترین برآورد خود از زمان واقعی را ارائه نمی‌دهد.

پیکربندی توصیه‌شده برای فعال‌سازی leap smear سرور عبارت است از:

leapsecmode slew
maxslewrate 1000
smoothtime 400 0.001024 leaponly

دستورالعمل اول برای غیرفعال‌سازی پرش ساعت ضروری است که می‌توانست فرایند هموارسازی را بازنشانی کند. دستورالعمل دوم نرخ تنظیم تدریجی ساعت محلی را به 1000 ppm محدود می‌کند که پایداری فرایند هموارسازی را در زمان شروع و پایان تصحیح محلی بهبود می‌بخشد. دستورالعمل سوم فرایند هموارسازی زمان سرور را فعال می‌کند. این فرایند با رسیدن ساعت به 00:00:00 UTC آغاز شده و تکمیل آن ۶۲۵۰۰ ثانیه (حدود ۱۷.۳۶ ساعت) طول خواهد کشید. آفست بسامد به میزان 0.001024 ppm بر ثانیه تغییر خواهد کرد و پس از ۳۱۲۵۰ ثانیه به بیشینه 32 ppm می‌رسد. گزینه leaponly مدت زمان leap smear را ثابت می‌کند و به کارخواهان اجازه می‌دهد با چند سرور leap smear با پیکربندی یکسان به‌طور ایمن همگام شوند.

مدت زمان leap smear را می‌توان از مقدار wander مشخص‌شده محاسبه کرد:

duration = sqrt(4 / wander)

هنگام اعلام ثانیه کبیسه، منطقه زمانی باید حداقل ۱۲ ساعت پیش از ثانیه کبیسه به‌روزرسانی شود. نیازی به راه‌اندازی مجدد chronyd نیست.

این دستورالعمل برای ساعت‌های مرجع و سایر منابع زمانی مفید است که ثانیه‌های کبیسه را اعلام نمی‌کنند، یا آن را دیرتر از موعدی اعلام می‌کنند که سرور NTP بتواند به کارخواهان خود فوروارد کند. کارخواهان سرورهای leap smear نباید از این دستورالعمل استفاده کنند.

همچنین زمانی کاربرد دارد که ساعت سیستم نیازمند آفست صحیح TAI-UTC باشد. توجه داشته باشید که آفست تنها زمانی تنظیم می‌شود که ثانیه‌های کبیسه توسط کرنل مدیریت شوند، یعنی leapsecmode روی system تنظیم شده باشد.

منطقه زمانی مشخص‌شده به عنوان منبع انحصاری اطلاعات درباره ثانیه‌های کبیسه استفاده نمی‌شود. اگر اکثریت منابع زمانی در آخرین روز ژوئن یا دسامبر اعلام کنند که یک ثانیه کبیسه باید درج یا حذف شود، حتی اگر در منطقه زمانی گنجانده نشده باشد نیز پذیرفته خواهد شد.

نمونه‌ای از این دستورالعمل:

leapsectz right/UTC

دستور شل زیر بررسی می‌کند که آیا منطقه زمانی حاوی ثانیه‌های کبیسه است و می‌تواند با این دستورالعمل استفاده شود:

$ TZ=right/UTC date -d 'Dec 31 2008 23:59:60'
Wed Dec 31 23:59:60 UTC 2008

نمونه‌ای از این دستورالعمل:

leapseclist /usr/share/zoneinfo/leap-seconds.list

این دستورالعمل chronyd را مجبور می‌کند که در صورت بزرگ‌تر بودن میزان تنظیم از مقدار آستانه، ساعت سیستم را جهش (step) دهد، اما تنها در صورتی که تعداد به‌روزرسانی‌های ساعت از زمان شروع chronyd از حد مشخص‌شده بیشتر نباشد. یک مقدار منفی این محدودیت را غیرفعال می‌کند.

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

نمونه‌ای از استفاده این دستورالعمل:

makestep 0.1 3

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

توجه داشته باشید که اگر کنترل ساعت سیستم توسط گزینهٔ -x در chronyd غیرفعال شده باشد، این دستورالعمل کار نمی‌کند و نباید استفاده شود.

این بررسی پس از تعداد مشخص‌شده به‌روزرسانی ساعت فعال می‌شود تا امکان اصلاح انحراف اولیهٔ بزرگ هنگام شروع فراهم باشد. انحراف‌های بزرگ‌تر از حداکثر مشخص‌شده به تعداد دفعات تعیین‌شده نادیده گرفته خواهند شد. یک انحراف بزرگ دیگر باعث تسلیم شدن و خروج chronyd می‌شود. از یک مقدار منفی می‌توان برای غیرفعال کردن محدودیت جهت نادیده گرفتن تمام انحراف‌های بزرگ استفاده کرد. هنگام نادیده گرفته شدن یک انحراف یا خروج ناشی از آن، یک پیام syslog تولید خواهد شد.

نمونه‌ای از استفاده این دستورالعمل:

maxchange 1000 1 2

پس از نخستین به‌روزرسانی ساعت، chronyd آفست را در هر به‌روزرسانی ساعت بررسی خواهد کرد، دو تنظیم بزرگ‌تر از 1000 ثانیه را نادیده می‌گیرد و با بروز انحراف بعدی خارج می‌شود.

به‌طور پیش‌فرض، حداکثر خطا 1 ppm است.

مقادیر معمول برای error-in-ppm ممکن است 10 برای یک ساعت با کیفیت پایین و 0.1 برای یک ساعت با کیفیت بالا با استفاده از نوسان‌ساز کریستالی با جبران دما باشد.

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

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

دستورالعمل maxupdateskew آستانه را برای تشخیص اینکه آیا یک برآورد ممکن است آن‌قدر غیرقابل اعتماد باشد که نباید استفاده شود، تنظیم می‌کند. به‌طور پیش‌فرض، آستانه 1000 ppm است.

مقادیر معمول برای skew-in-ppm ممکن است 100 برای منابع NTP نظرسنجی‌شده از طریق شبکهٔ بی‌سیم، و 10 یا کمتر برای منابع روی یک شبکهٔ سیمی محلی باشد.

باید توجه داشت که این تنها ابزار محافظت در برابر استفاده از برآوردهای غیرقابل اعتماد نیست. در تمام زمان‌ها، chronyd هم نرخ افزایش یا کاهش برآوردشده و هم حد خطای برآورد را ردیابی می‌کند. هنگامی که یک برآورد جدید پس از اندازه‌گیری دیگری از یکی از منابع ایجاد می‌شود، از یک الگوریتم ترکیب وزنی برای به‌روزرسانی برآورد موجود استفاده می‌شود. اگر حدود خطای آن به‌طور قابل توجهی کوچک‌تر از برآورد جدید باشد، برآورد موجود بر مقدار ترکیبی جدید غالب خواهد بود.

برای هر سیستم حداکثر آفست فرکانسی ساعتی وجود دارد که می‌تواند توسط درایور تنظیم شود. در Linux این مقدار 100000 ppm است، در FreeBSD، NetBSD و macOS 10.13+ برابر 5000 ppm است، و در illumos برابر 32500 ppm است. همچنین، به دلیل محدودیت هسته، تنظیم maxslewrate در FreeBSD، NetBSD، macOS 10.13+ روی مقداری بین 500 ppm و 5000 ppm عملاً آن را روی 500 ppm تنظیم می‌کند.

به‌طور پیش‌فرض، حداکثر نرخ تغییر تدریجی روی 83333.333 ppm (یک دوازدهم) تنظیم شده است.

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

نتیجه به عوامل زیادی از جمله دقت حسگر، میزان نویز در اندازه‌گیری‌ها، بازهٔ زمانی پرس‌وجو از منبع زمان، بازهٔ زمانی به‌روزرسانی جبران، نحوهٔ مشخص شدن مشخصات جبران، و میزان نزدیکی حسگر به نوسان‌ساز بستگی دارد. هنگامی که به‌خوبی کار کند، فرکانس گزارش‌شده در پروندهٔ tracking.log پایدارتر و حداکثر آفست به‌دست‌آمده کوچک‌تر است.

دو شکل از این دستورالعمل وجود دارد. شکل اول شش پارامتر دارد: یک مسیر به پروندهٔ حاوی دمای فعلی از حسگر (در قالب متنی)، بازهٔ زمانی به‌روزرسانی جبران (به ثانیه)، و ضرایب دمایی T0، k0، k1، k2.

جبران فرکانس (به ppm) به صورت زیر محاسبه می‌شود:

comp = k0 + (T - T0) * k1 + (T - T0)^2 * k2

نتیجه باید بین -10 ppm و 10 ppm باشد، در غیر این صورت اندازه‌گیری نامعتبر تلقی شده و نادیده گرفته خواهد شد. ضریب k0 را می‌توان طوری تنظیم کرد که جبران در آن محدوده باقی بماند.

نمونه‌ای از استفاده:

tempcomp /sys/class/hwmon/hwmon0/temp2_input 30 26000 0.0 0.000183 0.0

دمای اندازه‌گیری‌شده هر 30 ثانیه از پرونده در سیستم‌پروندهٔ sysfs در Linux خوانده می‌شود. هنگامی که دما 26000 (26 درجهٔ سلسیوس) باشد، تصحیح فرکانس صفر خواهد بود. هنگامی که 27000 (27 درجهٔ سلسیوس) باشد، ساعت تنظیم می‌شود تا 0.183 ppm سریع‌تر کار کند، و غیره.

شکل دوم سه پارامتر دارد: مسیر پروندهٔ حسگر، بازهٔ به‌روزرسانی، و مسیری به پرونده‌ای حاوی فهرستی از نقاط (دما، جبران)، که جبران از روی آن‌ها به‌صورت خطی درون‌یابی یا برون‌یابی می‌شود.

یک نمونه:

tempcomp /sys/class/hwmon/hwmon0/temp2_input 30 /etc/chrony.tempcomp

که در آن پروندهٔ /etc/chrony.tempcomp می‌تواند حاوی مقادیر زیر باشد:

20000 1.0
21000 0.64
22000 0.36
23000 0.16
24000 0.04
25000 0.0
26000 0.04
27000 0.16
28000 0.36
29000 0.64
30000 1.0

اندازه‌گیری‌های معتبر با جبران‌سازی‌های متناظر در صورت فعال بودن با دستورالعمل log tempcomp در پرونده tempcomp.log ثبت می‌شوند.

به طور پیش‌فرض هیچ کارخواهی مجاز به دسترسی نیست، یعنی chronyd صرفاً به عنوان یک کارخواه NTP عمل می‌کند. در صورت استفاده از دستورالعمل allow، دیمن chronyd هم کارخواه کارسازهای خود و هم کارسازی برای سایر کارخواه‌ها خواهد بود.

این دستورالعمل می‌تواند چندین بار استفاده شود.

نمونه‌های استفاده از این دستورالعمل به شرح زیر است:

allow 1.2.3.4
allow 3.4.5.0/24
allow 3.4.5
allow 2001:db8::/32
allow 0/0
allow ::/0
allow

دستورالعمل اول اجازه دسترسی از یک نشانی IPv4 را می‌دهد. دستورالعمل دوم اجازه دسترسی از تمام رایانه‌های یک زیرشبکه IPv4 مشخص‌شده در قالب CIDR را می‌دهد. دستورالعمل سوم همان زیرشبکه را با استفاده از نشانه‌گذاری ساده‌تری که در آن طول پیشوند با تعداد نقطه‌ها مشخص می‌شود تعیین می‌کند. دستورالعمل چهارم یک زیرشبکه IPv6 را مشخص می‌کند. دستورالعمل‌های پنجم و ششم به ترتیب اجازه دسترسی از تمام نشانی‌های IPv4 و IPv6 را می‌دهند. دستورالعمل هفتم اجازه دسترسی از همه نشانی‌ها (هم IPv4 و هم IPv6) را می‌دهد.

شکل دوم دستورالعمل، allow all، تأثیر بیشتری دارد که به ترتیب دستورالعمل‌ها در پرونده پیکربندی بستگی دارد. برای نشان دادن این اثر، دو مثال زیر را در نظر بگیرید:

allow 1.2.3.4
deny 1.2.3.0/24
allow 1.2.0.0/16

و

allow 1.2.3.4
deny 1.2.3.0/24
allow all 1.2.0.0/16

در مثال اول، اثر صرف‌نظر از ترتیبی که این سه دستورالعمل در آن داده شده‌اند یکسان است؛ بنابراین زیرشبکه 1.2.0.0/16 مجاز است، به جز زیرشبکه 1.2.3.0/24 که رد می‌شود، در حالی که میزبان 1.2.3.4 مجاز است.

در مثال دوم، دستورالعمل allow all 1.2.0.0/16 اثر هر دستورالعمل قبلی مربوط به یک زیرشبکه درون زیرشبکه مشخص‌شده را لغو می‌کند. درون یک پرونده پیکربندی این قابلیت شاید چندان مطرح نباشد؛ با این حال، برای بازپیکربندی در زمان اجرا از طریق chronyc با دستور allow all کاربرد بیشتری دارد.

قواعد به صورت داخلی به عنوان درختی از جدول‌ها با یک سطح به ازای هر چهار بیت از نشانی IPv4 یا IPv6 نمایش داده می‌شوند. ترتیب دستورالعمل‌های allow و deny در صورتی اهمیت دارد که رکوردهای یکسانی از یک جدول را تغییر دهند، یعنی اگر یک زیرشبکه در زیرشبکه دیگر گنجانده شده باشد و طول پیشوند آن‌ها در یک سطح باشد. برای نمونه، 1.2.3.0/28 و 1.2.3.0/29 در جدول‌های متفاوتی قرار دارند، اما 1.2.3.0/25 و 1.2.3.0/28 در یک جدول هستند. پیکربندی را می‌توان برای نشانی‌های منفرد با دستور accheck در chronyc بررسی کرد.

می‌توان به جای نشانی IP از نام میزبان در دستورالعمل‌ها استفاده کرد، اما نام باید هنگام شروع chronyd قابل تحلیل باشد، یعنی شبکه فعال بوده و DNS کار کند. اگر نام میزبان به چندین نشانی تحلیل شود، فقط نخستین نشانی (به ترتیبی که توسط تحلیل‌گر سامانه بازگردانده می‌شود) مجاز یا رد خواهد شد.

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

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

همچنین دستورالعمل deny all با رفتاری مشابه دستورالعمل allow all وجود دارد.

نمونه استفاده از این دستورالعمل:

bindaddress 192.168.1.1

در حال حاضر برای هر یک از پروتکل‌های IPv4 و IPv6 تنها یک دستورالعمل bindaddress می‌تواند مشخص شود؛ بنابراین در رایانه‌هایی که باید روی چندین رابط شبکه خدمات NTP ارائه دهند، کاربردی نیست.

نمونه این دستورالعمل:

binddevice eth0

این دستورالعمل می‌تواند چندین بار برای مشخص کردن چندین نشانی استفاده شود.

نحو به شرح زیر است:

broadcast 32 192.168.1.255
broadcast 64 192.168.2.255 12123
broadcast 64 ff02::101

در مثال اول، درگاه مقصد به طور پیش‌فرض درگاه UDP 123 (درگاه عادی NTP) است. در مثال دوم، درگاه مقصد به عنوان 12123 مشخص شده است. پارامتر اول در هر مورد (به ترتیب 32 یا 64) فاصله زمانی بر حسب ثانیه بین ارسال بسته‌های برودکست است. پارامتر دوم در هر مورد نشانی برودکست برای ارسال بسته به آن است. این باید متناظر با نشانی برودکست یکی از رابط‌های شبکه در رایانه‌ای باشد که chronyd روی آن اجرا می‌شود.

اگر بیش از یک رابط شبکه دارید که می‌خواهید بسته‌های برودکست NTP را روی آن‌ها ارسال کنید، می‌توانید بیش از یک دستورالعمل broadcast داشته باشید.

خود chronyd نمی‌تواند به عنوان یک کارخواه برودکست عمل کند؛ این برنامه همیشه باید با تعریف کارسازها و همتایان خاص NTP به عنوان یک کارخواه نقطه به نقطه پیکربندی شود. این قابلیت کارساز برودکست برای ارائه یک منبع زمان به سایر پیاده‌سازی‌های NTP در نظر گرفته شده است.

اگر از ntpd به عنوان کارخواه برودکست استفاده شود، تلاش خواهد کرد تا تأخیر رفت و برگشت بین کارساز و کارخواه را با بسته‌های حالت کارخواه معمولی اندازه بگیرد؛ بنابراین، زیرشبکه برودکست باید موضوع یک دستورالعمل allow نیز باشد.

نمونه‌ای از کاربرد این دستورالعمل:

clientloglimit 1048576

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

دستورالعمل local دارای گزینه‌های زیر است:

stratum stratum

distance distance

distance = delay / 2 + dispersion

activate distance

orphan

waitsynced interval

waitunsynced interval

نمونه‌هایی از این دستورالعمل:

local stratum 5
local stratum 10 orphan distance 0.1 activate 0.5
local stratum 10 orphan distance 0.0 waitsynced 7200 waitunsynced 300

توجه داشته باشید که درخواست‌های MS-SNTP احراز هویت نمی‌شوند و هر کلاینتی که با دستورالعمل allow یا دستور allow در chronyc مجاز به دسترسی به سرور باشد، می‌تواند پاسخی از MS-SNTP دریافت کند که با رمز عبور trust account امضا شده است و تلاش کند تا رمز عبور را با حمله brute-force بشکند. دسترسی به سرور باید با دقت کنترل شود.

نمونه‌ای از کاربرد این دستورالعمل:

ntpsigndsocket /var/lib/samba/ntp_signd

این درگاه تنها زمانی باز خواهد بود که یک گواهی و کلید توسط دستورالعمل‌های ntsservercert و ntsserverkey مشخص شده باشد.

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

پرونده‌ها فقط یک بار بارگیری می‌شوند. برای بارگیری مجدد گواهی تمدیدشده، chronyd باید راه‌اندازی مجدد شود. استفاده از دستورالعمل‌های ntsdumpdir و dumpdir همراه با گزینه -r در chronyd برای عملکرد تقریباً بدون وقفه سرور توصیه می‌شود.

از این دستورالعمل می‌توان چندین بار برای مشخص کردن چندین کلید استفاده کرد. تعداد کلیدها باید برابر با تعداد گواهی‌ها باشد و پرونده‌های مربوطه باید به همان ترتیب مشخص شوند.

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

فهرست پیش‌فرض شناسه‌ها 30 15 است. AES-128-GCM-SIV به دلیل کلیدهای کوتاه‌تر، نسبت به AES-SIV-CMAC-256 ارجحیت دارد که باعث کوتاه‌تر شدن کوکی‌های NTS و بهبود قابلیت اطمینان NTS در شبکه‌هایی می‌شود که پیام‌های طولانی‌تر NTP را مسدود کرده یا نرخ آن‌ها را محدود می‌کنند.

نمونه‌ای از این دستورالعمل:

ntsaeads 15

این فهرست توسط کلاینت NTS نیز استفاده می‌شود.

توجه داشته باشید که مشخصات NTS (RFC 8915) کارسازها را ملزم به پشتیبانی از AES-SIV-CMAC-256 می‌کند، یعنی 15 باید همیشه در فهرست مشخص‌شده گنجانده شود.

کلیدهای AES-128-GCM-SIV استفاده‌شده توسط chronyd به دلیل حفظ سازگاری با کلاینت‌های قدیمی‌تر chrony با RFC 8915 مطابقت ندارند، مگر اینکه استفاده از کلیدهای منطبق از طریق یک رکورد NTS-KE https://chrony-project.org/doc/spec/nts-compliant-128gcm.html. مذاکره شود. پشتیبانی از این رکورد در نسخه 4.6.1 افزوده شد. chronyd به عنوان کلاینت می‌تواند با کارسازی که از کلیدهای منطبق استفاده می‌کند اما از مذاکره پشتیبانی نمی‌کند تعامل داشته باشد، به شرطی که کارساز به درخواست‌های با احراز هویت نادرست با یک NTS NAK پاسخ دهد.

نمونه‌ای از این دستورالعمل:

ntsdumpdir /var/lib/chrony

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

چرخش خودکار کلیدها را می‌توان با تنظیم ntsrotate روی 0 غیرفعال کرد. در این حالت فرض می‌شود کلیدها به صورت خارجی مدیریت می‌شوند. chronyd کلیدها را در پرونده ntskeys ذخیره نخواهد کرد و هنگام صدور دستور rekey در chronyc، کلیدها را از پرونده بازخوانی می‌کند. برای داشتن یک یا چند کارساز اختصاصی برای NTS-KE، می‌توان این پرونده را به‌طور دوره‌ای از کارساز دیگری که chronyd را اجرا می‌کند (و ntsrotate در آن روی 0 تنظیم نشده) کپی کرد. این پرونده شامل کلید بعدی است که کارساز NTS-KE در چرخش بعدی به آن سوئیچ خواهد کرد؛ یعنی فرایند کپی و بازخوانی پرونده نیازی به زمان‌بندی دقیق ندارد (می‌تواند تا حداکثر یک بازه چرخش به تعویق بیفتد). کارسازهای NTS-KE باید با دستورالعمل ntsntpserver پیکربندی شوند تا کلاینت‌ها را به کارساز NTP صحیح هدایت کنند.

نمونه‌ای از این دستورالعمل:

ntsrotate 2592000

مقدار پیش‌فرض 123، درگاه استاندارد NTP است. در صورت تنظیم روی 0، chronyd هرگز درگاه کارساز را باز نخواهد کرد و صرفاً در حالت کلاینت کار خواهد کرد. درگاه مبدا مورد استفاده در درخواست‌های کلاینت NTP را می‌توان با دستورالعمل acquisitionport تعیین کرد.

دستورالعمل ratelimit از چندین گزینه پشتیبانی می‌کند (که می‌توانند به هر ترتیبی تعریف شوند):

interval interval

burst responses

leak rate

kod rate

یک نمونه استفاده از دستورالعمل:

ratelimit interval 1 burst 16

این کار نرخ پاسخ را برای آدرس‌های IP که به طور میانگین بیش از یک بار در هر ۲ ثانیه بسته ارسال می‌کنند، یا بسته‌ها را در رگبارهای بیش از ۱۶ بسته می‌فرستند، تا ۷۵٪ کاهش می‌دهد (با مقدار پیش‌فرض leak برابر با 2).

یک نمونه از استفاده از دستورالعمل:

ntsratelimit interval 3 burst 1

هشدار: سرور عمداً بهترین تخمین خود را از زمان واقعی ارائه نمی‌دهد. اگر آفست بزرگی انباشته شده باشد، هموار کردن آن ممکن است زمان بسیار زیادی ببرد. این دستورالعمل باید تنها زمانی استفاده شود که کلاینت‌ها برای نظرسنجی از سرور NTP دیگری نیز پیکربندی نشده باشند، زیرا ممکن است این سرور را به عنوان falseticker رد کنند یا به طور کامل در انتخاب منبع ناموفق باشند.

فرایند هموارسازی با یک تابع اسپلاین درجه دو با دو یا سه قطعه پیاده‌سازی می‌شود. این فرایند مستقل از هرگونه تنظیم تدریجی (slewing) اعمال‌شده بر ساعت محلی سیستم است، اما آفست و فرکانس انباشته‌شده با تصحیح ساعت از طریق گام برداشتن (stepping)، مثلاً با دستورالعمل makestep یا فرمان makestep در chronyc، بازنشانی خواهند شد. این فرایند بدون گام برداشتن ساعت می‌تواند با فرمان smoothtime reset بازنشانی شود.

دو آرگومان اول دستورالعمل عبارتند از حداکثر آفست فرکانسی زمان هموارشده نسبت به زمان NTP ردیابی‌شده (بر حسب ppm) و حداکثر نرخی که آفست فرکانس مجاز به تغییر در آن است (بر حسب ppm در ثانیه). leaponly یک آرگومان اختیاری سوم است که حالتی را فعال می‌کند که در آن فقط ثانیه‌های کبیسه هموار می‌شوند و تغییرات آفست و فرکانس عادی نادیده گرفته می‌شوند. گزینه leaponly در ترکیب با دستورالعمل leapsecmode slew برای ایجاد امکان استفاده ایمن کلاینت‌ها از چندین سرور هموارسازی زمان مفید است.

فرایند هموارسازی زمانی که ۱/۱۰۰۰۰ از انحراف (skew) تخمینی ساعت محلی به زیر حداکثر نرخ تغییر فرکانس بیفتد، به طور خودکار فعال می‌شود. این فرایند همچنین می‌تواند به صورت دستی با فرمان smoothtime activate فعال شود، که به ویژه زمانی مفید است که ساعت فقط با ورودی دستی همگام‌سازی شده باشد و انحراف همواره بزرگتر از آستانه باشد. فرمان smoothing می‌تواند برای پایش این فرایند استفاده شود.

یک نمونه مناسب برای کلاینت‌هایی که از ntpd و بازه نظرسنجی ۱۰۲۴ ثانیه استفاده می‌کنند:

smoothtime 400 0.001

یک نمونه مناسب برای کلاینت‌هایی که از chronyd در Linux استفاده می‌کنند:

smoothtime 50000 0.01

این دستورالعمل همچنین می‌تواند مسیر سوکت فرمان Unix domain را که توسط chronyc برای ارسال فرمان‌های پیکربندی استفاده می‌شود، تغییر دهد. سوکت باید در دایرکتوری‌ای باشد که فقط توسط کاربر root یا chrony قابل دسترسی باشد. در صورت عدم وجود، دایرکتوری در زمان شروع ایجاد خواهد شد. مسیر پیش‌فرض کامپایل‌شده برای سوکت /var/run/chrony/chronyd.sock است. سوکت را می‌توان با تنظیم مسیر روی / غیرفعال کرد.

به طور پیش‌فرض، chronyd سوکت‌های UDP را به آدرس‌های 127.0.0.1 و ::1 (یعنی رابط loopback) مقید می‌کند. این کار تمام دسترسی‌ها به جز دسترسی از localhost را مسدود می‌کند. برای شنود بسته‌های فرمان روی همه رابط‌ها، می‌توانید خطوط زیر را اضافه کنید:

bindcmdaddress 0.0.0.0
bindcmdaddress ::

به پرونده پیکربندی.

برای هر یک از پروتکل‌های IPv4، IPv6 و Unix domain، تنها یک دستورالعمل bindcmdaddress می‌تواند مشخص شود.

نمونه‌ای که مسیر سوکت فرمان Unix domain را تعیین می‌کند:

bindcmdaddress /var/run/chrony/chronyd.sock

یک نمونه از دستورالعمل:

bindcmddevice eth0

نحو آن دقیقاً با دستورالعمل allow یکسان است.

همچنین یک دستورالعمل cmdallow all با رفتاری مشابه دستورالعمل allow all وجود دارد (اما البته در این مورد برای دسترسی پایش اعمال می‌شود).

آدرس‌های 127.0.0.1 و ::1 (یعنی رابط loopback) همیشه مجاز هستند.

توجه داشته باشید که chronyd باید با دستورالعمل bindcmdaddress پیکربندی شود تا صرفاً روی رابط loopback شنود نکند و دسترسی از راه دور عملاً مجاز شود.

نحو آن یکسان است.

همچنین یک دستورالعمل cmddeny all با رفتاری مشابه دستورالعمل cmdallow all وجود دارد.

مثال:

cmdport 257

این دستور chronyd را وادار به استفاده از UDP 257 به‌عنوان درگاه فرمان می‌کند. (جهت تعامل درست، chronyc باید با گزینه -p 257 اجرا شود.)

مثال استفاده:

cmdratelimit interval 2

activity*, authdata, clients, manual*, ntpdata, rtcdata*, selectdata, serverstats*, smoothing*, sourcename*, sources*, sourcestats, tracking*.

دستورهای دارای علامت * به‌طور پیش‌فرض فعال هستند. پروتکل این دستورها پایدار تلقی می‌شود و بین نسخه‌های مختلف chronyc و chronyd کار می‌کند. پروتکل سایر دستورها پایدار نیست و نسخه‌های مختلف chronyc و chronyd ممکن است با یکدیگر کار نکنند. در این صورت، chronyc خطای ‘Invalid command’ یا ‘Bad reply from daemon’ را چاپ خواهد کرد.

توجه: برخی داده‌های ارائه‌شده می‌توانند برای مهاجمان در جهت مشاهده و پیش‌بینی وضعیت داخلی chronyd مفید باشند. توصیه می‌شود فقط دستورهای مورد نیاز فعال شده و دسترسی محدود گردد.

مقدار پیش‌فرض کامپایل‌شده '/etc/adjtime' است.

مثال:

hwclockfile /etc/adjtime

این دستورالعمل تنها همراه با rtcfile مؤثر است.

مثال استفاده:

rtcautotrim 30

این دستور خطای آستانه را روی ۳۰ ثانیه تنظیم می‌کند.

مثال:

rtcfile /var/lib/chrony/rtc

chronyd هنگام خروج و هنگام اجرای دستور writertc در chronyc، اطلاعات را در این پرونده ذخیره می‌کند. اطلاعات شامل خطای RTC در مبدأ زمانی مشخص، آن مبدأ (به ثانیه از ۱ ژانویه ۱۹۷۰)، و نرخ جلو یا عقب افتادن RTC است.

پشتیبانی از RTC محدود است؛ کد آن وابسته به سیستم است. امکانات RTC (دستورالعمل rtcfile و گزینه -s در chronyd) فقط در صورت برقراری سه شرط زیر کار می‌کنند:

در صورت تنظیم RTC روی زمان محلی و خاموش بودن رایانه هنگام تغییر ساعت تابستانی، ساعت سیستم در بوت بعدی یک ساعت خطا خواهد داشت.

راهکار دیگر، نگهداری ساعت هماهنگ جهانی (UTC) در RTC است. این روش مشکل خطای یک ساعته را ندارد.

دستورالعمل rtconutc نشان می‌دهد RTC باید زمان UTC را نگه دارد. این دستور آرگومانی ندارد و معادل سوئیچ -u در برنامه hwclock است.

این تنظیم توسط hwclockfile لغو می‌شود و برای دستورالعمل rtcsync یا استفاده از RTC به‌عنوان ساعت مرجع کاربرد ندارد.

در لینوکس، رونوشت RTC توسط کرنل هر ۱۱ دقیقه یک‌بار انجام می‌شود.

در macOS، زمانی که ساعت سیستم در وضعیت همگام‌شده باشد، chronyd رونوشت RTC را هر ۶۰ دقیقه یک‌بار انجام می‌دهد.

در سایر سیستم‌ها، این دستورالعمل هیچ کاری انجام نمی‌دهد.

rawmeasurements

2016-11-09 05:40:50 203.0.113.15    N  2 111 111 1111  10 10 1.0 \
   -4.966e-03  2.296e-01  1.577e-05  1.615e-01  7.446e-03 CB00717B 4B D K

measurements

statistics

2016-08-10 05:40:50 203.0.113.15     6.261e-03 -3.247e-03 \
     2.220e-03  1.874e-06  1.080e-06 7.8e-02  16   0   8  0.00

selection

2022-05-01 02:01:20 203.0.113.15    * -----  377  1.00  \
     4.228e+01 -1.575e-04  1.239e-04

tracking

2017-08-22 13:22:36 203.0.113.15     2     -3.541      0.075 -8.621e-06 N \
            2  2.940e-03 -2.084e-04  1.534e-02  3.472e-04  8.304e-03

rtc

2015-07-22 05:40:50     -0.037360 1       -0.037434\
          -37.948  12   5  120

refclocks

2009-11-30 14:33:27.000000 PPS2    7 N 1  4.900000e-07 -6.741777e-07  1.000e-06

tempcomp

2015-04-19 10:39:48  2.8000e+04  3.6600e-01

دستورالعمل logbanner بازه تعداد ورودی‌هایی که در پرونده گزارش نوشته می‌شوند و پس از آن بنر دوباره نوشته می‌شود را مشخص می‌کند. مقدار پیش‌فرض ۳۲ است، و برای غیرفعال کردن کامل آن می‌توان از ۰ استفاده کرد.

به طور پیش‌فرض، این آستانه ۱ ثانیه است.

یک مثال از استفاده:

logchange 0.1

که باعث می‌شود در صورت آغاز جبران‌سازی خطای ساعت سیستم بیشتر از ۰.۱ ثانیه، یک پیام syslog تولید شود.

یک مثال از استفاده از این دستورالعمل:

logdir /var/log/chrony

یک مثال از استفاده از این دستورالعمل:

mailonchange root@localhost 0.5

این دستور در صورتی که تغییری بیش از ۰.۵ ثانیه بر روی ساعت سیستم اعمال شود، یک پیام ایمیل به root ارسال می‌کند.

این دستورالعمل را نمی‌توان هنگامی که پالایه فراخوانی سیستم توسط گزینه -F فعال شده باشد استفاده کرد، زیرا به پردازش chronyd اجازه انشعاب (fork) و اجرای باینری sendmail داده نخواهد شد.

چندین شاخه (حداکثر ۱۰ مورد) را می‌توان با یک دستورالعمل confdir مشخص کرد. در این حالت، اگر چندین شاخه حاوی پرونده‌ای با نام یکسان باشند، تنها اولین پرونده به ترتیب شاخه‌های مشخص‌شده وارد خواهد شد. این کار امکان یک پیکربندی قطعه‌قطعه را فراهم می‌کند که در آن می‌توان با افزودن پرونده‌ها به شاخه‌ای دیگر، قطعات موجود را جایگزین کرد.

این دستورالعمل می‌تواند چندین بار استفاده شود.

نمونه‌ای از این دستورالعمل:

confdir /etc/chrony.d

این دستورالعمل می‌تواند چندین بار استفاده شود.

نمونه‌ای از این دستورالعمل:

sourcedir /var/run/chrony-dhcp

این دستورالعمل می‌تواند چندین بار استفاده شود.

نمونه‌ای از این دستورالعمل:

include /etc/chrony.d/*.conf

این دستورالعمل در Linux 3.19 و جدیدتر پشتیبانی می‌شود. کارت شبکه (NIC) باید از HW timestamping پشتیبانی کند، که می‌توان آن را با دستور ethtool -T بررسی کرد. فهرست قابلیت‌ها باید شامل hardware-raw-clock، hardware-transmit و hardware-receive باشد. پالایه دریافت all یا ntp برای برچسب‌گذاری زمانی بسته‌های دریافتی NTP ضروری است. برچسب‌گذاری زمانی بسته‌های دریافت‌شده روی رابط‌های bridged و bonded در Linux 4.13 و جدیدتر پشتیبانی می‌شود. اگر HW timestamping برای بسته‌های دریافتی کار نکند، chronyd در عوض از برچسب‌های زمانی دریافت هسته استفاده خواهد کرد. برچسب‌گذاری زمانی سخت‌افزاری فقط-ارسال همچنان می‌تواند برای بهبود پایداری همگام‌سازی مفید باشد.

برنامه chronyd ساعت NIC را همگام‌سازی نمی‌کند. فرض می‌کند که ساعت به‌صورت آزاد کار می‌کند. چندین نمونه از chronyd می‌توانند از یک رابط با HW timestamping فعال استفاده کنند. برنامه‌هایی که به HW timestamping با ساعت همگام‌شده نیاز دارند (مانند دیمن PTP) باید از یک ساعت مجازی که روی ساعت فیزیکی اجرا می‌شود و با نوشتن در /sys/class/ptp/ptpX/n_vclocks ایجاد شده است، استفاده کنند. این ویژگی در Linux 5.14 و جدیدتر در دسترس است.

اگر هسته از برچسب‌گذاری زمانی نرم‌افزاری پشتیبانی کند، به‌طور خودکار برای همه رابط‌ها فعال خواهد شد.

منبع برچسب‌های زمانی (یعنی سخت‌افزار، هسته یا دیمن) در سمت کلاینت در پرونده measurements.log (در صورت فعال بودن توسط دستورالعمل log) و گزارش ntpdata نشان داده می‌شود. در سمت سرور، تعداد برچسب‌های زمانی ارائه‌شده از هر منبع در گزارش serverstats ارائه می‌شود.

این دستورالعمل می‌تواند چندین بار برای فعال‌سازی HW timestamping روی چندین رابط استفاده شود. اگر رابط مشخص‌شده * باشد، chronyd تلاش خواهد کرد تا HW timestamping را روی تمام رابط‌های موجود فعال کند.

دستورالعمل hwtimestamp دارای گزینه‌های زیر است:

minpoll poll

maxpoll poll

minsamples samples

maxsamples samples

precision precision

txcomp compensation

rxcomp compensation

nocrossts

rxfilter filter

مثال‌هایی از این دستورالعمل عبارتند از:

hwtimestamp eth0
hwtimestamp eth1 txcomp 300e-9 rxcomp 645e-9
hwtimestamp *

مقدار پیش‌فرض 0.001 ثانیه است که باید برای بیشتر سخت‌افزارها کافی باشد. اگر مرتباً برچسب‌های زمانی ارسال هسته را در پرونده measurements.log یا گزارش ntpdata مشاهده می‌کنید، و این یک سرور نیست که نرخ بالایی از درخواست‌ها را در حالت interleaved روی همان رابط پردازش می‌کند (که با برچسب‌گذاری زمانی درخواست‌های خود سرور رقابت می‌کند)، افزایش مهلت زمانی به 0.01 یا احتمالاً بیشتر ممکن است کمک کند. توجه داشته باشید که حداکثر مهلت زمانی توسط بازه نظرسنجی NTP محدود می‌شود.

قالب این دستورالعمل در مثال زیر نشان داده شده است:

keyfile /etc/chrony.keys

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

10 tulip
11 hyacinth
20 MD5 ASCII:crocus
25 SHA1 HEX:933F62BE1D604E68A81B557F18CFA200483F5B70
30 AES128 HEX:7EA62AE64D190114D46D5A082F948EC1
31 AES256 HEX:37DDCBC67BB902BCB8E995977FAB4D2B5642F5B32EBCEEE421921D97E5CBFE39
 ...

هر خط شامل یک شناسه، نوع اختیاری و کلید است.

شناسه می‌تواند هر عدد صحیح مثبتی در محدوده ۱ تا 2^32-1 باشد.

نوع، نام یک تابع درهم‌سازی رمزنگاری یا سایفر است که برای تولید و تأیید MAC استفاده می‌شود. نوع پیش‌فرض MD5 است که همیشه پشتیبانی می‌شود. اگر chronyd با پشتیبانی فعال برای درهم‌سازی با استفاده از یک کتابخانه رمزنگاری (Nettle، GnuTLS، NSS یا LibTomCrypt) کامپایل شده باشد، توابع زیر در دسترس هستند: MD5، SHA1، SHA256، SHA384، SHA512. بسته به اینکه chronyd از کدام کتابخانه و نسخه استفاده می‌کند، ممکن است برخی از توابع درهم‌سازی و سایفرهای زیر نیز در دسترس باشند: SHA3-224، SHA3-256، SHA3-384، SHA3-512، TIGER، WHIRLPOOL، AES128، AES256.

کلید می‌تواند به صورت رشته‌ای از نویسه‌های ASCII بدون فاصله سفید با پیشوند اختیاری ASCII: یا به عنوان یک عدد هگزادسیمال با پیشوند HEX: مشخص شود. حداکثر طول خط 2047 نویسه است. اگر نوع یک سایفر باشد، طول کلید باید با سایفر مطابقت داشته باشد (یعنی ۱۲۸ بیت برای AES128 و ۲۵۶ بیت برای AES256).

توصیه می‌شود از کلیدهای تصادفی تولید شده در قالب هگزادسیمال استفاده کنید که حداقل ۱۲۸ بیت طول دارند (یعنی حداقل ۳۲ نویسه بعد از پیشوند HEX: دارند). اگر منبعی در پرونده پیکربندی با کلیدی کوتاه‌تر از ۸۰ بیت مشخص شده باشد، chronyd در هنگام شروع هشداری را در syslog ثبت خواهد کرد.

انواع کلید توصیه شده سایفرهای AES و توابع درهم‌سازی SHA3 هستند. از MD5 باید اجتناب شود مگر اینکه نوع دیگری در سرور و کارخواه یا همتایان پشتیبانی نشود. یک نقطه ضعف عمده MD5 برای MAC در NTP، حمله گسترش طول است که در آن یک مهاجم مرد میانی می‌تواند فیلدهای افزونه دلخواه را به پیام NTP اضافه کند و MAC را به‌روز کند تا تأیید پیام گسترش‌یافته با موفقیت انجام شود. گزینه extfield (فعال‌سازی پردازش فیلد افزونه مشخص‌شده) نباید برای منابع NTP که با کلید MD5 احراز هویت شده‌اند استفاده شود.

دستور keygen از chronyc می‌تواند برای تولید کلیدهای تصادفی برای پرونده کلید استفاده شود. به‌طور پیش‌فرض، کلیدهای ۱۶۰ بیتی MD5 یا SHA1 تولید می‌کند.

به دلایل امنیتی، پرونده فقط باید توسط root و کاربری که chronyd معمولاً تحت آن اجرا می‌شود قابل خواندن باشد (تا به chronyd اجازه دهد هنگام صدور دستور rekey توسط chronyc، پرونده را دوباره بخواند).

pidfile /run/chronyd.pid

تنظیم این دستورالعمل روی / نوشتن و بررسی پرونده PID را غیرفعال می‌کند.

پشتیبانی از NTP-over-PTP آزمایشی است. پروتکل و پیکربندی ممکن است در آینده تغییر کند. این ویژگی فقط باید در شبکه‌های محلی استفاده شود.

درگاه PTP باز خواهد بود حتی اگر chronyd برای کار به عنوان سرور یا کارخواه پیکربندی نشده باشد. این دستورالعمل پروتکل پیش‌فرض منابع NTP مشخص‌شده را تغییر نمی‌دهد. هر منبع NTP که باید از NTP-over-PTP استفاده کند باید با گزینه port تنظیم‌شده روی درگاه PTP مشخص شود. برای فعال‌سازی واقعی برچسب‌گذاری زمانی سخت‌افزاری روی NICهایی که فقط می‌توانند بسته‌های PTP را برچسب‌گذاری کنند، گزینه rxfilter از دستورالعمل hwtimestamp باید روی ptp تنظیم شود. فیلد افزونه F324 باید فعال باشد تا از اصلاحات ارائه‌شده توسط ساعت‌های شفاف PTP استفاده شود.

یک مثال از پیکربندی کارخواه:

server ntp1.example.net minpoll 0 maxpoll 0 xleave port 319 extfield F324
hwtimestamp * rxfilter ptp
ptpport 319

در سیستم‌هایی به جز macOS، این دستورالعمل از فراخوانی سیستمی pthread_setschedparam() برای هدایت هسته به استفاده از سیاست زمان‌بندی بلادرنگ خروج به ترتیب ورود (SCHED_FIFO) برای chronyd با اولویت مشخص‌شده استفاده می‌کند. این به این معنی است که هر زمان chronyd آماده اجرا باشد، اجرا می‌شود و اجرای سایر پردازه‌ها را قطع می‌کند مگر اینکه پردازه‌ای بلادرنگ با اولویت بالاتر باشد. این نباید روی کارایی تأثیر منفی بگذارد زیرا نیازمندی‌های منبع chronyd ناچیز است، اما باید منجر به تاخیر کمتر و پایدارتر شود چون chronyd نیازی به منتظر ماندن برای نوبت زمان‌بندی جهت اجرا نخواهد داشت. نباید از این دستور استفاده کنید مگر اینکه واقعاً به آن نیاز داشته باشید. صفحه راهنمای pthread_setschedparam(3) جزئیات بیشتری دارد.

در macOS، این دستورالعمل از فراخوانی هسته thread_policy_set() برای تعیین زمان‌بندی بلادرنگ استفاده می‌کند. همان‌طور که در بالا اشاره شد، نباید از این دستورالعمل استفاده کنید مگر اینکه واقعاً به آن نیاز داشته باشید.

در Linux، chronyd باید با پشتیبانی از کتابخانه libcap کامپایل شده باشد. در macOS، FreeBSD، NetBSD و illumos، دیمن chronyd به دو فرایند منشعب (fork) می‌شود. فرایند فرزند اختیارات root را حفظ می‌کند، اما فقط می‌تواند دامنه بسیار محدودی از فراخوانی‌های سیستمی ممتاز را به نمایندگی از والد انجام دهد.

مقدار پیش‌فرض کامپایل‌شده chrony است.

server ntp1.example.net
server ntp2.example.net
server ntp3.example.net

server ntp1.example.net iburst
server ntp2.example.net iburst
server ntp3.example.net iburst
driftfile /var/lib/chrony/drift
makestep 1.0 3
rtcsync

pool pool.ntp.org iburst
driftfile /var/lib/chrony/drift
makestep 1.0 3
rtcsync

server ntp1.example.net iburst nts
server ntp2.example.net iburst nts
server ntp3.example.net iburst nts
driftfile /var/lib/chrony/drift
makestep 1.0 3
rtcsync

server ntp1.example.net offline
server ntp2.example.net offline
server ntp3.example.net offline
driftfile /var/lib/chrony/drift
makestep 1.0 3
rtcsync

/usr/bin/chronyc online

/usr/bin/chronyc offline

initstepslew 1 client1 client3 client6
driftfile /var/lib/chrony/drift
local stratum 8
manual
allow 192.168.165.0/24
smoothtime 400 0.01
rtcsync

server ntp.local iburst
driftfile /var/lib/chrony/drift
allow 192.168.165.0/24
makestep 1.0 3
rtcsync

initstepslew 1 ntp2.local ntp3.local
server ntp2.local
server ntp3.local
driftfile /var/lib/chrony/drift
local stratum 8 orphan
manual
allow 192.168.165.0/24
rtcsync

server ntp1.example.net maxdelay 0.4 offline
server ntp2.example.net maxdelay 0.4 offline
server ntp3.example.net maxdelay 0.4 offline
logdir /var/log/chrony
log statistics measurements tracking
driftfile /var/lib/chrony/drift
makestep 1.0 3
maxupdateskew 100.0
dumpdir /var/lib/chrony
rtcfile /var/lib/chrony/rtc

/usr/bin/chronyc online

/usr/bin/chronyc -m offline dump writertc

server ntp1.example.net iburst
server ntp2.example.net iburst
server ntp3.example.net iburst
server ntp4.example.net iburst
makestep 1.0 3
rtcsync
allow
clientloglimit 100000000
leapsectz right/UTC
driftfile /var/lib/chrony/drift
dumpdir /var/run/chrony