Ansible کہتا ہے شروع ہو گیا، مگر WireGuard اب بھی پرانی ترتیب پر چل رہا ہے

playbook کا رن سبز رنگ میں ختم ہوتا ہے، WireGuard unit فعال ہے، handshake کام کرتا ہے، اور نیا peer پھر بھی کہیں نہیں پہنچتا۔ سرور کو کل کی ترتیب پر چلتے دیکھنا اور playbook کو کامیابی کا اعلان کرتے دیکھنا خاصی کھِیج ہے، کیونکہ آؤٹ پٹ میں کچھ بھی غلط نہیں۔ Ansible نے ٹھیک وہی کیا جو کہا گیا تھا: اس نے یقینی بنایا کہ unit شروع ہو، اور unit پہلے ہی شروع تھا۔ دوبارہ لکھی گئی ترتیب کی فائل لاگو کرنا الگ کام ہے، اور یہ صرف تب ہوتا ہے جب کوئی چیز سروس سے کہے کہ اسے دوبارہ پڑھے۔

دیکھیں دوسرا رن دراصل کیا بتاتا ہے

بدلی ہوئی ترتیب کے ساتھ playbook دو بار چلائیں اور خلاصے کا موازنہ کریں۔ دوسرے رن میں unit کا کام changed نہیں، ok دکھنا چاہیے، کیونکہ پہلے سے چل رہی سروس کو ڈیزائن کے مطابق چھیڑا نہیں جاتا۔ یہی صحیح طور پر کام کرنے والی idempotence ہے، اور نئی فائل کے کبھی kernel تک نہ پہنچنے کی وجہ بھی یہی ہے۔

diff آؤٹ پٹ کے ساتھ جانچ کا رن شامل کریں تاکہ معلوم ہو کہ کون سے کام کسی چیز کو چھوئیں گے۔

ansible-playbook -i inventory site.yml --check --diff
systemctl show wg-quick@wg0 -p ActiveEnterTimestamp -p NRestarts
stat -c '%y %n' /etc/wireguard/wg0.conf

تین ٹائم اسٹیمپ ایک بھی لاگ لائن پڑھنے سے پہلے کہانی بتا دیتے ہیں۔ اگر ترتیب کی فائل unit کے فعال ہونے کے لمحے سے نئی ہے، تو چل رہا انٹرفیس پرانی فائل سے بنا ہے، اور آگے کے تمام علامات وہیں سے آتے ہیں۔

یہ Ansible کی خرابی نہیں۔ یہی رویہ ہر ایسے ترتیب کے انتظام کے اوزار میں دکھائی دیتا ہے جو «یقینی بنائیں کہ یہ چل رہا ہے» کو «یقینی بنائیں کہ یہ یہی چلا رہا ہے» سے الگ کرتا ہے۔ یہ فرق اس وقت تک باریک بینی لگتا ہے جب تک دوپہر ضائع نہ ہو جائے۔

شروع ہونا ایک حالت ہے، دوبارہ لوڈ کرنا نہیں

state: started unit کے بارے میں ایک شرط بیان کرتا ہے۔ یہ وعدہ نہیں کرتا کہ سروس اپنے ان پٹ دوبارہ پڑھے گی، اور یہ نہیں جان سکتا کہ جس فائل کو اس نے کبھی نہیں کھولا وہ بدل گئی ہے۔ wg-quick تعیناتی میں ان پٹ میں انٹرفیس کی ترتیب، پتے، راستے، DNS اندراجات اور کوئی بھی post-up ہک شامل ہوتے ہیں۔

اسی لیے اپ ڈیٹ شدہ فائل میں نیا peer، مختلف پتہ یا بدلا ہوا راؤٹنگ ہدایت ہو سکتا ہے جبکہ لائیو انٹرفیس پرانا مجموعہ ہی پیش کرتا رہتا ہے۔ handshake اب بھی کامیاب ہوتا ہے کیونکہ لوڈ کی گئی کلیدیں اور اینڈ پوائنٹس اب بھی درست ہیں۔ یہی ناکامی کو دیکھنا مشکل بناتا ہے، اور لوگ ٹائم اسٹیمپ جانچنے سے پہلے ایک گھنٹہ DNS کے پیچھے بھاگتے ہیں۔

ماڈیول کے دو دیگر اختیارات کو اکثر حل سمجھا جاتا ہے۔ daemon_reload systemd کو unit فائلیں دوبارہ پڑھنے پر مجبور کرتا ہے، جو WireGuard ترتیب کی فائل سے متعلق نہیں۔ state: reloaded unit سے اس کا دوبارہ لوڈ کرنے کا عمل چلانے کو کہتا ہے، اور یہ کہ وہ آپ کی ضرورت پوری کرتا ہے یا نہیں، مکمل طور پر unit پر منحصر ہے۔ کوئی بھی یہ جاننے کا متبادل نہیں کہ چلتی ہوئی پروسیس نے واقعی کون سے ان پٹ پڑھے۔

فائل نصب کریں، پھر handler کو اطلاع دیں

idempotence برقرار رکھتے ہوئے تبدیلیاں لاگو کرنے کا طریقہ عام ہے: فائل لکھنے والا کام handler کو اطلاع دیتا ہے، اور handler صرف تب چلتا ہے جب فائل واقعی بدلی ہو۔ بغیر ترمیم دوسرا رن کچھ نہیں کرتا، اور آپ یہی چاہتے ہیں۔

- name: write the interface configuration
  ansible.builtin.template:
    src: wg0.conf.j2
    dest: /etc/wireguard/wg0.conf
    owner: root
    mode: "0600"
  notify: apply wg0

- name: ensure the interface unit is enabled
  ansible.builtin.systemd_service:
    name: wg-quick@wg0
    enabled: true
    state: started

- name: apply wg0
  listen: apply wg0
  ansible.builtin.systemd_service:
    name: wg-quick@wg0
    state: restarted

handler play کے آخر میں، ان کاموں کے بعد چلتے ہیں جنہوں نے انہیں اطلاع دی، اس لیے اسی play کا بعد والا کام اب بھی پرانا انٹرفیس دیکھ سکتا ہے۔ اگر ترتیب اہم ہو، تو نئی ترتیب پر منحصر کام سے پہلے meta: flush_handlers کے ذریعے handler واضح طور پر خالی کریں۔

unit کے دوبارہ لوڈ کرنے کے عمل کی جانچ کیے بغیر reload کے بجائے restart استعمال کریں۔ اپ اسٹریم wg-quick unit ایک کی حمایت کرتا ہے اور WireGuard ترتیب ہم آہنگ کرتا ہے، مگر پتوں، راستوں، DNS یا ہک کی ترتیب دوبارہ نہیں چلاتا۔ اس لیے راستے کی ہدایت شامل کرنے کے بعد reload کامیاب دکھتا ہے اور کچھ نہیں بدلتا۔

لائیو ڈیوائس کا فائل سے موازنہ کریں

اس قسم کی خرابیوں کو بند کرنے والی جانچ kernel کے پاس موجود اور فائل کے بیان کردہ کے درمیان موازنہ ہے۔ دو کمانڈز موازنہ کے قابل آؤٹ پٹ دیتی ہیں، اور فرق ہی انحراف ہے۔

sudo wg showconf wg0
sudo wg-quick strip wg0
sudo diff <(sudo wg showconf wg0) <(sudo wg-quick strip wg0)

wg showconf نجی کلید سمیت لائیو ڈیوائس چھاپتا ہے، اس لیے اس آؤٹ پٹ کو راز سمجھیں اور ٹکٹ میں نہ چپکائیں۔ wg-quick strip فائل کو wg-quick کے مخصوص کیز کے بغیر چھاپتا ہے، اور اسی لیے دونوں کا موازنہ ممکن ہے۔

peer فہرست میں فرق کا مطلب ہے کہ فائل کبھی لاگو نہیں ہوئی۔ صرف ان کیز یا اینڈ پوائنٹس میں فرق جن کے بدلنے کی توقع تھی، کا مطلب ہے کہ کسی نے اسے جزوی طور پر لاگو کیا۔ کوئی فرق نہ ہونے کا مطلب ہے کہ ترتیب موجودہ ہے اور خرابی کہیں اور ہے، جو بذات خود مفید نتیجہ ہے۔

دوبارہ آغاز کی قیمت جان بوجھ کر ادا کریں

انٹرفیس کا دوبارہ آغاز سرنگ توڑ دیتا ہے، اور اگر وہ سرنگ آپ کا انتظامی سیشن لے کر جا رہی ہے، تو دوبارہ آغاز اسی سیشن کو ختم کر دیتا ہے جس نے اس کی درخواست کی تھی۔ handler کو تبدیلی کی ونڈو کے پیچھے رکھیں، یا playbook ایسے انتظامی راستے سے چلائیں جو انٹرفیس کے دوبارہ آغاز پر منحصر نہ ہو۔

یہی قیمت لوگوں کو reload کی طرف کھینچتی ہے۔ یہ معقول فطرت ہے، اور جب آپ جان لیں کہ reload واقعی کون سی تبدیلیاں لاگو کرتا ہے تو یہ درست ہو جاتی ہے۔ اپ اسٹریم wg-quick unit پر peer اور کلید کی تبدیلیوں کے لیے یہ کافی ہے؛ پتوں، راؤٹنگ اور ہک کے لیے نہیں۔ ایک بار اسے واضح کر لینا تبدیلی کی ونڈو میں دریافت کرنے سے سستا ہے۔

systemd_service ماڈیول کی دستاویز started، restarted اور reloaded کے درمیان فرق بیان کرتی ہے، اور سبز خلاصے سے اندازہ لگانے کے بجائے ایک بار پڑھنا بہتر ہے۔ اس پوری گفتگو کی جڑ وہی ایک فرق ہے۔