פונקציונליות של סוכן אורח

במאמר הזה נתאר את הארכיטקטורה ואת הפונקציונליות העיקרית של סוכן האורח. המידע הזה עוזר להבין איך הסוכן מנהל את הגדרת המופע, את ממשקי הרשת, את סקריפטים של מטא-נתונים ואת חשבונות המשתמשים, כדי לשמור על תקינות ועל ביצועים של מופעי Compute Engine. סוכן האורח הוא רכיב ליבה של סביבת האורח, שמכילה את הסקריפטים, תוכנות הדימון והקבצים הבינאריים שמכונות Compute צריכות כדי לפעול ב-Compute Engine.

איך סוכן האורח עובד

החל מגרסה 20250901.00, סוכן האורח משתמש בארכיטקטורה מבוססת-תוספים. העיצוב הזה משפר את האמינות והגמישות על ידי הפרדת הפונקציות של הנציג לרכיבים נפרדים.

הארכיטקטורה של סוכן האורח מורכבת מכמה רכיבים עיקריים:

  • Guest agent manager: התהליך המרכזי במופע שמתחיל, מפסיק ועוקב אחרי כל הפלאגינים.
  • פלאגין ליבה: הפלאגין הזה מטפל בשירותים החיוניים שהמכונה צריכה כדי לפעול ב- Google Cloud. אי אפשר להשבית את הפונקציונליות שלו.
  • תוספים (פלאגינים אופציונליים): פלאגינים שמשלבים את המכונה עם שירותים אחרים של Google Cloud , כמו Cloud Monitoring. אפשר לקבוע אילו מהתוספים האלה יפעלו במופע באמצעות VM Extension Manager.
  • ‫VM Extension Manager: שירות מנוהל של Google Cloud שפועל בתשתית הקצה העורפי של Google ומנהל את מחזור החיים של פלאגינים אופציונליים, כולל ההתקנה והעדכונים שלהם.

למידע נוסף על הארכיטקטורה של סוכן האורח, קראו את המאמר מידע על סוכן האורח.

רצף ההפעלה ויחסי התלות

מנהל סוכן האורח פועל לפי רצף הפעלה ספציפי כדי לוודא שהמופע מוגדר בצורה נכונה להפעלה ב-Compute Engine. מיד אחרי שהתהליך מתחיל, מנהל הסוכן מפעיל את הפלאגין הראשי – רכיב ייעודי שמטפל במשימות בסיסיות בסביבת האורח.

Linux

במכונות Linux, סוכן האורח פועל כשירות systemd בשם google-guest-agent-manager.service. רצף ההפעלה כולל את השלבים הבאים:

  1. הגדרת תלות ברשת: google-guest-agent-manager.serviceמתחיל אחרי יעד המערכת network-online.target. כך אפשר לוודא שיש קישוריות בסיסית לרשת לפני שה-agent מתקשר עם שרת המטא-נתונים או מבצע שלבי הגדרה אחרים. פרטים על ההטמעה מופיעים בקובץ התצורה של יחידת השירות google-guest-agent-manager.service.
  2. שליחת הודעה על מוכנות: הסוכן האורח מריץ את שלבי ההגדרה המינימליים הנדרשים, ואז משתמש ב-systemd-notify --ready כדי להודיע למערכת שהוא פועל באופן מלא ומוכן לשרת רכיבים אחרים. הסוכן מבצע את השלבים המינימליים הבאים שנדרשים להגדרה:

Windows

במופעי Windows, סוכן האורח פועל כשירות Windows בשם GCEAgentManager. רצף ההפעלה כולל את השלבים הבאים:

  1. הפעלה מושהית: סוג ההפעלה של השירות מוגדר כאוטומטי (הפעלה מושהית). כך שירותי הליבה של מערכת ההפעלה יכולים להתחיל לפעול קודם, וזה מפחית את התחרות על המשאבים בשלב ההפעלה הראשוני. פרטים על ההטמעה זמינים בסקריפט להתקנת השירות.
  2. הגדרת סטטוס השירות: הסוכן מפעיל את ההגדרה המינימלית הנדרשת ואז מגדיר את סטטוס השירות SERVICE_RUNNING כדי להודיע למערכת שהוא פועל באופן מלא ומוכן לשרת רכיבים אחרים. הסוכן מבצע את פעולות ההגדרה המינימליות הבאות:

שיטות מומלצות לתהליכים תלויים

אם יש לכם שירותים או סקריפטים בהתאמה אישית שתלויים בתכונות של סוכן האורח, כמו אתחול פרטי הכניסה של MDS, אתם צריכים להגדיר תלות מפורשת בהפעלה כדי לוודא שהם יופעלו רק אחרי שהסוכן פעיל.

Linux

מוסיפים תלות בשירות systemd של סוכן האורח בקובץ היחידה, למשל:

[Unit]
After=google-guest-agent-manager.service

Windows

מוסיפים תלות בשירות של Windows של הסוכן האורח באמצעות בקרת שירות, למשל:

sc config "CustomService" depend= "GCEAgentManager"

פונקציונליות עיקרית

הפלאגין הראשי אחראי לשירותים הבסיסיים שהמכונה צריכה כדי לפעול ב-Compute Engine. בקטע הבא מפורטות הפונקציות שהפלאגין הראשי מספק. אפשר להתאים אישית הרבה מהתכונות האלה באמצעות קובץ התצורה של סוכן האורח.

הגדרה ראשונית של מופע ואופטימיזציות

סוכן האורח מבצע כמה משימות הגדרה כדי להכין את המכונה להפעלה ב-Compute Engine. כפי שמוצג בטבלה הבאה, חלק מהמשימות מופעלות רק באתחול הראשון, ואחרות מופעלות בכל הפעלה.

משימה נתיב ברירת המחדל תדירות
יצירת מפתחות מארח SSH ‫/etc/ssh/ssh_host_type_key וגם .pub סוגי ברירת המחדל כוללים ecdsa,‏ ed25519 ו-rsa. בהפעלה הראשונה (Linux בלבד)
יצירת קובץ ההגדרות boto לשימוש ב-Cloud Storage /etc/boto.cfg בהפעלה הראשונה (Linux בלבד)
מזהה מכונה ייחודי של החנות ‫Linux: ‏ /etc/google_instance_id
‫Windows: ‏ C:\ProgramData\Google\Compute Engine\google-guest-agent\google_instance_id 		באתחול הראשון
אופטימיזציה ל-SSD מקומי ההגדרה מתבצעת באמצעות הגדרות מתזמן קלט/פלט של המערכת ב-/sys/block/dev/queue/scheduler, כאשר dev הוא שם המכשיר (לדוגמה, nvme0n1 או sdb). בכל הפעלה (Linux בלבד)
הפעלת תורים מרובים בכל מכשירי virtionet ללא בכל הפעלה

אפשר לשלוט במשימות ההגדרה האלה על ידי הגדרת האפשרויות של InstanceSetup קובץ ההגדרה של סוכן האורח. לדוגמה, אפשר להשבית את האופטימיזציה של Local SSD על ידי הגדרת optimize_local_ssd = false.

איסוף נתוני טלמטריה של המערכת

סוכן האורח מתעד מידע טלמטרי בסיסי של המערכת בזמן האתחול ואחר כך במרווחי זמן קבועים, לפחות כל 24 שעות. המידע שמתועד כולל:

  • גרסה וארכיטקטורה של סוכן אורח
  • השם והגרסה של מערכת ההפעלה
  • הגרסה והמהדורה של ליבת מערכת ההפעלה

  • אפליקציה נתמכת של יצרן תוכנה בלתי תלוי (ISV) שפועלת במופע של מחשוב וגרסת האפליקציה המוכרת

    אפליקציות נתמכות של ISV

    • Apache Cassandra
    • Apache Hadoop
    • Apache Spark
    • שרת אינטרנט של Apache
    • Citrix Cloud Connector
    • Citrix Delivery Controller
    • Citrix StoreFront
    • Citrix Virtual Delivery Agent
    • EDB Postgres
    • ‫EDB Postgres Advanced Server‏ (EPAS)
    • ‏Kubernetes
    • MariaDB
    • Memcached
    • Microsoft Active Directory
    • Microsoft Message Queuing (MSMQ)
    • Microsoft SQL Server
    • MongoDB
    • MySQL
    • Oracle Data Guard
    • Oracle Database
    • Oracle E-Business Suite
    • Oracle GoldenGate
    • Oracle JD Edwards EnterpriseOne
    • Oracle PeopleSoft
    • Oracle WebLogic Server
    • PostgreSQL
    • Red Hat OpenShift
    • Redis
    • SAP Gateway
    • SAP HANA
    • ‫SAP HANA Studio
    • SAP IQ
    • SAP NetWeaver ABAP
    • ‫SAP NetWeaver ASCS
    • ‫SAP NetWeaver Enqueue Replicator
    • ‫SAP NetWeaver Java
    • SAP Web Dispatcher
    • SUSE Pacemaker

כדי להשבית את איסוף נתוני הטלמטריה, צריך להגדיר את מפתח המטא-נתונים disable-guest-telemetry לערך true. במאמר הגדרת מטא-נתונים מותאמים אישית והסרתם מוסבר איך מגדירים מטא-נתונים.

סנכרון השעון (ב-Linux בלבד)

כדי להבטיח תזמון מדויק, סוכן האורח משתמש ברכיב clock_skew_daemon כדי לתקן מעת לעת את השעון במופע כך שיתאים לשרת הפיזי שבו הוא פועל. התהליך הזה מונע בעיה שנקראת הטיה בשעון, ויוצר הודעה system time has changed ביומני המופע, שמאשרת שהשעה סונכרנה בהצלחה.

אם ההגדרה הזו מופעלת, הסוכן מסנכרן את השעון בדרך כלל אחרי אירוע עצירה או התחלה, או אחרי העברה. עם זאת, אם השעון בזמן אמת (RTC) במכונה מוגדר להשתמש באזור הזמן המקומי במקום ב-UTC, הנציג מזהה באופן אוטומטי את ההגדרה הזו ומשבית את סנכרון השעון כדי למנוע חוסר עקביות.

הסוכן מבצע את הסנכרון מחדש על ידי הרצת הפקודה הבאה: /sbin/hwclock --hctosys -u --noadjfile.

כדי להשבית את הרכיב clock_skew_daemon, צריך להגדיר את clock_skew_daemon = false בקובץ התצורה של סוכן האורח.

הפעלת סקריפט של מטא-נתונים

אתם יכולים להשתמש בסקריפטים לטעינה בזמן ההפעלה ובסקריפטים לכיבוי כדי לבצע משימות אוטומטיות בכל פעם שהמופע מופעל או מושבת.

הסוכן האורח עוזר להריץ את הסקריפטים האלה באופן הבא:

  • מריץ סקריפטים במעטפת.
  • אם מציינים כמה סקריפטים (לדוגמה, אם משתמשים גם ב-startup-script וגם ב-startup-script-url), הסוכן מריץ את שניהם.
  • אם מספקים כמה סקריפטים לאותו אירוע, הסוכן מריץ קודם את הסקריפט מכתובת ה-URL.
  • אחרי שסקריפט מסתיים, הסוכן מתעד את סטטוס היציאה שלו.

כדי להגדיר את ההפעלה של סקריפטים של מטא-נתונים, משנים את האפשרויות של MetadataScripts בקובץ התצורה של הסוכן האורח.

ניהול חשבונות משתמשים ומפתחות SSH

הסוכן האורח משתמש ב-accounts_daemon כדי לנהל חשבונות משתמשים מקומיים ומפתחות SSH, ששולטים בגישה למופע. ההתנהגות הספציפית משתנה בין מערכות הפעלה של Linux ו-Windows.

אפשר לשנות את אפשרויות ניהול החשבונות על ידי הגדרת האפשרויות Accounts בקובץ התצורה של סוכן האורח.

Linux

שירות OS Login משמש לניהול גישת SSH למכונות באמצעות IAM, בלי שתצטרכו ליצור ולנהל מפתחות SSH נפרדים. מידע נוסף על OS Login זמין במאמר OS Login. במקרים של מכונות וירטואליות ב-Linux שבהן לא מופעל OS Login, הסוכן יוצר ומנהל חשבונות משתמשים מקומיים ואת מפתחות ה-SSH שלהם באמצעות הגדרות מטא-נתונים.

כשמוסיפים או מסירים מפתחות SSH מהמטא-נתונים של המכונה או הפרויקט, סוכן האורח יוצר או מוחק חשבון משתמש מקומי. הסוכן האורח גם מבצע את הפעולות הבאות כדי לנהל את חשבונות המשתמשים המקומיים האלה:

  • שומר את הקובץ authorized_keys (~/.ssh/authorized_keys) לכל חשבון משתמש שהוא מנהל באופן הבא:
    • כשמוסיפים מפתחות SSH למטא-נתונים, הסוכן יוצר קובץ authorized_keys עבור חשבון המשתמש.
    • כשמסירים את כל מפתחות ה-SSH של משתמש מהמטא-נתונים, הנציג מוחק את הקובץ authorized_keys של חשבון המשתמש הזה.
  • ניהול הרשאות אדמין באמצעות קבוצת Linux‏ google-sudoers. כל חבר בקבוצה הזו מקבל הרשאות sudo במופע. הגדרת מדיניות Sudo מתבצעת ב-/etc/sudoers.d/google_sudoers.
  • כל חשבונות המשתמשים שהוא מקצה יתווספו לקבוצה google-sudoers.
  • מוסיף חשבונות משתמשים לכל קבוצת Linux נוספת שציינתם באפשרות groups של קובץ התצורה של סוכן האורח.

Windows

במכונות של Windows, הסוכן יוצר באופן אוטומטי חשבונות משתמשים מקומיים לכל חשבון משתמש SSH שצוין במפתחות ה-SSH של המטא-נתונים ברמת המכונה או הפרויקט. הסוכן האורח גם מטפל ביצירת חשבונות משתמשים ובקביעת סיסמאות או באיפוס שלהן. צריך את חשבונות המשתמשים המקומיים האלה כדי להתחבר למופעי Windows באמצעות SSH.

כדי למנוע הקצאת משתמשים לא מכוונת ב-AD, אפשר להשבית את ניהול החשבונות במופע של בקר AD. מידע נוסף על הגדרת AD ב-Compute Engine זמין במאמר בנושא פריסת בקרי דומיין.

הגדרת OS Login (ל-Linux בלבד)

שירות OS Login משמש לניהול גישת SSH למכונות באמצעות IAM, בלי שתצטרכו ליצור ולנהל מפתחות SSH נפרדים. מידע נוסף על OS Login זמין במסמכי התיעוד של OS Login.

כשמפעילים את OS Login, הסוכן האורח אחראי להגדיר את המכונה לשימוש ב-OS Login.

הסוכן האורח מגדיר את OS Login על ידי ביצוע המשימות הבאות:

אם משביתים את OS Login, השינויים בהגדרות מוסרים. האפשרויות בקטע Accounts של קובץ התצורה SSHD לא חלות על משתמשים ב-OS Login.

ניהול רשתות

סוכן האורח מגדיר אוטומטית את ממשקי הרשת של המופע בזמן האתחול. הוא קורא את הגדרת הרשת משרת המטא-נתונים כדי לוודא שהמופע מתחבר לרשת בצורה נכונה ויכול לגשת לשירותים אחרים. Google Cloud

כדי לשלוט בהתנהגות של ניהול הרשת של הסוכן, אפשר להגדיר את האפשרויות של NetworkInterfaces בקובץ התצורה של סוכן האורח. לדוגמה, אפשר להגדיר את האפשרות manage_primary_nic = true כדי שהסוכן ינהל את כרטיס הרשת (NIC) הראשי בנוסף לכרטיסי הרשת המשניים.

בכל הפעלה, סוכן האורח מבצע את המשימות העיקריות הבאות:

  • הפעלת ממשקי רשת: הנציג מזהה את מנהל הרשת הפעיל במערכת ההפעלה ומשתמש בו כדי להפעיל את כל כרטיסי הרשת המשניים.
  • הגדרת נתיבי IP: הסוכן מגדיר את נתיבי ה-IP (IPv4 בלבד) הנדרשים לתכונות כמו העברת IP וטווחי IP של כינויים באופן הבא:
    • הגדרת מסלולים בממשק הראשי של ה-Ethernet.
    • הגדרת מסלולים של Google כברירת מחדל, עם מזהה הפרוטוקול לתקשורת בין נתבים 66. המזהה הזה הוא מרחב שמות לכתובות IP שהוגדרו לסוכן האורח. אפשר לשנות את המזהה הזה באמצעות האפשרות ethernet_proto_id בקובץ התצורה של סוכן האורח.
  • יצירת נתיב לשרת המטא-נתונים: הסוכן מוודא שכרטיס ה-NIC הראשי יכול תמיד לתקשר עם שרת המטא-נתונים כדי לקבל מידע על המופע.
  • הגדרת VLAN: אם המכונה מוגדרת להתחבר ל-Virtual Local Area Network (VLAN)‎, סוכן האורח מטפל בהגדרה באופן אוטומטי. הוא קורא את הגדרת ה-VLAN משרת המטא-נתונים ומגדיר את ממשק הרשת בתוך המכונה כך שישתמש בתג ה-VLAN הנכון. כך מוודאים שהמופע מתקשר ברשת הלוגית המיועדת. חשוב לדעת: אם ה-VLAN מחובר ל-NIC הראשי, ה-guest agent מגדיר אותו גם אם manage_primary_nic מושבת.

בחירה של ניהול רשתות

ב-Linux, סוכן האורח מזהה באופן אוטומטי את מנהל הרשת שזמין במערכת ומשתמש בו כדי להגדיר את ממשקי הרשת. הסוכן בודק אם יש מנהלים נתמכים לפי סדר העדיפות, מ-netplan עד dhclient.

בטבלה הבאה מפורטים מנהלי הרשת הנתמכים, לפי מערכת ההפעלה שהם משויכים אליה בדרך כלל כברירת מחדל. ההגדרה הספציפית של המופע יכולה להיות שונה, אבל הטבלה הזו משקפת את מנהל הרשת שמוגדר כברירת מחדל למערכות ההפעלה שמופיעות בה.

ניהול רשתות מערכת הפעלה מיקום ההגדרה נתיב לדוגמה הערות
netplan
  • ‫Debian 12 ואילך
  • ‫Ubuntu 20.04 ואילך
 /run/netplan/ /run/netplan/20-google-guest-agent-eth0.yaml יכול להיות שהנציג ישתמש גם במיקום לשיחה מהירה בכתובת /etc/systemd/network/
wicked
  • SLES
 /etc/sysconfig/network/ /etc/sysconfig/network/ifcfg-eth0 קבצים קיימים בפורמט ifcfg לא יוחלפו, אלא המערכת תדלג עליהם.
NetworkManager
  • CentOS
  • RHEL
  • Rocky Linux
 /etc/NetworkManager/system-connections/ /etc/NetworkManager/system-connections/google-guest-agent-eth0.nmconnection
systemd-networkd
  • ‫Debian
 /usr/lib/systemd/network/ /usr/lib/systemd/network/20-eth0-google-guest-agent.network
dhclient
  • ‫Debian 11 או גרסאות קודמות
  • ‫Ubuntu 18.04 או גרסה ישנה יותר
 /run/ /run/dhclient.google-guest-agent.eth0.ipv4.pid אם לא מזוהה אף אחד ממנהלי הרשת האחרים, סוכן האורח משתמש כברירת מחדל ב-dhclient.

ניהול מאובטח של פרטי כניסה לשרת מטא-נתונים (MDS)

מכונות וירטואליות מוגנות תומכות עכשיו בתקשורת מאובטחת עם שרת המטא-נתונים באמצעות נקודת הקצה של HTTPS‏ https://metadata.google.internal/computeMetadata/v1. השיפור הזה מספק ערוץ מאובטח יותר לגישה למטא-נתונים.

כדי לאפשר את התקשורת המאובטחת הזו, סוכן האורח מאחזר ומאחסן את פרטי הכניסה הדרושים בדיסק של המופע. פרטי הכניסה האלה נשמרים במיקום רגיל, כך שכל אפליקציית לקוח שפועלת במכונה יכולה לגשת אליהם. כדי לבדוק את המיקומים האלה, אפשר לעיין במאמר איפה מאוחסנים האישורים.

אישורי HTTPS MDS מופעלים כברירת מחדל החל מגרסה 20260228.00 של סוכן האורח. בגרסאות קודמות של סוכן האורח, כדי להגדיר באופן אוטומטי אישורי HTTPS MDS במכונות וירטואליות מוגנות, צריך להגדיר את מפתח המטא-נתונים disable-https-mds-setup לערך false במופע או בפרויקט. במאמר הגדרת מטא-נתונים מותאמים אישית והסרתם מוסבר איך מגדירים מטא-נתונים.

ניהול פרטי הכניסה על ידי סוכן האורח כולל:

  • עדכון ראשוני: גם אישור הבסיס וגם פרטי הכניסה של הלקוח מתעדכנים בכל פעם שתהליך הסוכן האורח מתחיל.
  • רענון אוטומטי: כדי לשפר את האבטחה, סוכן האורח מרענן באופן אוטומטי את פרטי הכניסה של הלקוח כל 48 שעות.
  • תקופת חפיפה: הסוכן יוצר ושומר פרטי כניסה חדשים, בזמן שפרטי הכניסה הישנים עדיין תקפים. תקופת החפיפה מבטיחה שללקוחות יהיה מספיק זמן לעבור לפרטי הכניסה החדשים לפני שתוקף פרטי הכניסה הישנים יפוג. במהלך התקופה החופפת הזו, הסוכן יכול גם לנסות שוב לקבל פרטי כניסה במקרה של כשל, כדי לוודא שיש פרטי כניסה תקינים לפני שפרטי הכניסה הקיימים הופכים ללא תקפים.
  • הרכב: סוכן האורח מוודא שפרטי הכניסה של הלקוח מורכבים ממפתח פרטי של EC (עקומה אליפטית) שמשורשר לאישור הלקוח.
  • ייחודיות: סוכן האורח מוודא שפרטי הכניסה ייחודיים למופע ולא ניתן להשתמש בהם במקום אחר.

למידע נוסף על נקודת הקצה של שרת המטא-נתונים ב-HTTPS, קראו את המאמר מידע על נקודת הקצה של שרת המטא-נתונים ב-HTTPS.

כברירת מחדל, סוכן האורח כותב אישורים ישירות לדיסק. עם זאת, אפשר להגדיר את הסוכן כך שישלב אישורים במאגרי האישורים המובנים של מערכת ההפעלה. כדי להפעיל את השילוב הזה, מגדירים את מפתח המטא-נתונים enable-https-mds-native-cert-store לערך true. במאמר הגדרת מטא-נתונים מותאמים אישית והסרתם מוסבר איך מגדירים מטא-נתונים.

האופן שבו הנציג מוסיף אישורים למאגרי האישורים של מערכת ההפעלה משתנה בהתאם למערכת ההפעלה:

Linux

הסוכן של האורח מבצע את השלבים הבאים:

  1. הוספת אישור הבסיס של MDS למאגר האישורים של המערכת. הנתיב הספציפי תלוי בהפצת מערכת ההפעלה. כדי לבדוק את המיקומים האלה, אפשר לעיין במאמר בנושא אחסון של אישורי בסיס במאגר אישורים של מערכת ההפעלה.
  2. מעדכנים את מאגר האישורים המקומי על ידי הפעלת הפקודה המתאימה למערכת ההפעלה, כמו update-ca-certificates או update-ca-trust.

Windows

הסוכן מוסיף את פרטי הכניסה של הלקוח ל-Cert:\LocalMachine\My ואת אישור הבסיס ל-Cert:\LocalMachine\Root.

תמיכה באשכולות יתירות כשל ב-Windows (רק ב-Windows)

הסוכן האורח עוקב אחרי הצומת הפעיל ב-Windows Server Failover Cluster ומתאם עם מאזן העומסים הפנימי של Google Cloud כדי להעביר את כל התנועה של האשכול לצומת הצפוי.

כדי לשלוט בהתנהגות הזו, אפשר להשתמש בשדות הבאים במטא-נתונים של המכונה או בקובץ instance_configs.cfg:

  • ‫enable-wsfc: אם הערך מוגדר כ-true, הסוכן מתעלם מכל המידע על העברת כתובות IP ומתחיל להגיב ליציאה של בדיקת תקינות. ערך ברירת המחדל הוא false.
  • ‫wsfc-agent-port: מציין את היציאה שבה הסוכן מגיב לבדיקות תקינות. ערך ברירת המחדל הוא 59998.
  • ‫wsfc-addrs: רשימה מופרדת בפסיקים של כתובות IP. ההגדרה המתקדמת הזו מאפשרת להשתמש בכתובות IP רגילות להעברה ובכתובות IP של אשכול באותו מופע. כשמגדירים את זה, הסוכן מדלג על ההגדרה האוטומטית רק לכתובות ה-IP שברשימה הזו. כברירת מחדל, הערך הזה לא מוגדר.

המאמרים הבאים