שאלות נפוצות

שאלות נפוצות

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

> כיצד פועלת מערכת הקרדיט של Cli>_?

יתרה משותפת אחת בתשלום מראש מממנת את כל השירותים הזכאים ונצרכת רק כשהם פעילים.
faq/prepaid-credit-how-it-works

לחשבון Cli>_ יש יתרת קרדיט משותפת אחת בתשלום מראש. לקוחות חדשים זכאים יכולים לדרוש Starter Credit רק לאחר השלמת אימות החשבון והאימות למניעת ניצול לרעה הנדרשים. שירותים פעילים וזכאים צורכים את היתרה לאורך זמן. ההערכה החודשית מבוססת על 31 ימים, ושירות חדש יכול להתחיל רק אם היתרה מכסה לפחות 7 ימים. אזהרה אדומה מוצגת כאשר זמן הפעילות המשוער יורד מתחת ל-7 ימים; אחרת מוצגת אזהרה כתומה כאשר הוא יורד מתחת ל-14 ימים.

לאחר שהיתרה מתרוקנת, השירות מושעה לאחר 7 ימים, מפסיק לצרוך קרדיט ומתחילה ספירה לאחור של 7 ימים לשמירה ולמחיקה. לפני המועד המוצג אפשר להפעילו מחדש עם קרדיט מספיק. ביטול שירות שהוקצה גם משעה אותו ומתחיל את אותה ספירה לאחור. שירות ממתין שטרם הוקצה עשוי להיות מושבת מיד. לאחר המועד מתחילות השבתת השירות שהוקצה והסרתו. Force delete משבית את השירות מיד, מדלג על השמירה ומתחיל את הסרתו מה-runtime הפעיל; ההשלמה מתבצעת לאחר עיבוד deployment ו-GitOps. לגיבויים ול-Offsite Archive יש מדיניות שמירה נפרדת.

דוגמת OpenCode במחיר 9.90 EUR: ‏9.90 / 31 ≈ ‏0.319 EUR ליום. לאחר 10 ימים מלאים נצרכים כ-3.19 EUR. אם היתרה ההתחלתית הייתה בדיוק 9.90 EUR ולא היו שירותים אחרים, נשארים כ-6.71 EUR. הצריכה נעצרת לאחר השבתה.

הדוגמה להמחשה בלבד. המחירים העדכניים המוצגים ב-Cli>_ הם הקובעים תמיד.

> כיצד ליצור מפתח SSH ציבורי באמצעות שורת הפקודה

צור מפתח SSH ציבורי לגישה מאובטחת ל-VPS. שתף עם Cli>_ רק את המפתח הציבורי; שמור את המפתח הפרטי במכשיר שלך.
faq/generate-public-ssh-key-he

השתמשו רק במפתח הציבורי

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

שלבים

  1. פתח טרמינל במחשב שלך.
  2. הרץ את הפקודה הבאה: ssh-keygen -t ed25519 -C "your-email@example.com".
  3. אשר את מיקום הקובץ או בחר נתיב מותאם אישית. לעולם אל תשלח את המפתח הפרטי שלך.
  4. הצג מפתח ציבורי באמצעות הפקודה: `cat ~/.ssh/id_ed25519.pub`.
  5. העתק את השורה כולה המתחילה ב-`ssh-ed25519` והדבק אותה בשדה 'מפתח ציבורי של SSH' במהלך ההזמנה או הגדרת השירות.
  6. העתק את כל שורת `ssh-ed25519` והדבק אותה בשדה 'SSH public key'.

PowerShell עבור Windows 10/11

  1. פתח את PowerShell או את Windows Terminal.
  2. הפעל את הפקודה הבאה: ssh-keygen -t ed25519 -C "your-email@example.com".
  3. לחץ על Enter כדי לשמור את המפתח בנתיב C:\Users\your-user\.ssh\id_ed25519, או הזן נתיב מותאם אישית.
  4. אם Windows מבקשת סיסמה, השתמש בסיסמה שתוכל לאחסן בצורה מאובטחת, או לחץ על Enter כדי לדלג עליה עבור הגדרה פשוטה.
  5. הצגת המפתח הציבורי באמצעות הפקודה: Get-Content $env:USERPROFILE\.ssh\id_ed25519.pub.
  6. העתקת השורה המתחילה ב-ssh-ed25519 בלבד. אין להעתיק או לטעון את קובץ המפתח הפרטי.
> כיצד ליצור מפתח SSH באופן גרפי ב-Windows

הוראות מפורטות ליצירת זוג מפתחות SSH ב-Windows באמצעות ממשק גרפי, ללא שימוש בשורת הפקודה.
faq/create-ssh-key-windows-gui-he

השתמשו בכלי של Windows והדביקו רק את המפתח הציבורי

ניתן ליצור זוג מפתחות SSH בצורה גרפית באמצעות לקוח SSH של Windows כמו PuTTYgen. Cli>_ דורש רק את המפתח הציבורי. שמרו את קובץ המפתח הפרטי במחשב שלכם ואל תעלו אותו לטופס מקוון.

הוראות

  1. התקן את PuTTY או פתח את PuTTYgen אם הוא כבר מותקן.
  2. בחר EdDSA/Ed25519 אם זמין, אחרת בחר RSA 4096.
  3. לחץ על Generate והזז את העכבר מעל השטח הריק עד שהמפתח ייווצר.
  4. הוסף סיסמה אם ברצונך להוסיף שכבת הגנה מקומית נוספת למפתח הפרטי שלך.
  5. שמור את המפתח הפרטי במכשיר שלך ושמור עליו בסוד.
  6. העתק את טקסט המפתח הציבורי והדבק אותו בשדה 'מפתח ציבורי של SSH' ב-Cli>_.

אל תשתף נתונים סודיים

אל תשלוח קבצי .ppk, מפתחות פרטיים, סיסמאות או טוקנים לתמיכה או לטפסים.

> הבאת הדומיין האישי שלך

> למידע על אופן חיבור דומיין או תת-דומיין קיים לשירות CLIopen, לפני הפעלת האפשרות 'הבא את הדומיין שלך'.
faq/hibur-hadomain-shelkha

מה הגדרה זו עושה

שימוש בדומיין משלך מאפשר לשירות שלך לענות על שם הדומיין האישי שלך, לדוגמה app.example.com, במקום להשתמש בשם הדומיין שנוצר כברירת מחדל *.co.cliopen.cloud. ה-DNS שלך חייב להצביע ל-CLIopen תחילה, כדי שניתן יהיה להשתמש בשם הדומיין בצורה בטוחה על ידי השירות.

לפני שמתחילים

  1. בחרו שם מארח (hostname) מדויק לשימוש, לדוגמה app.example.com. השימוש בתת-דומיין הוא האפשרות הפשוטה ביותר.
  2. היכנסו לממשק ניהול ה-DNS של רשם הדומיין או ספק ה-DNS שלכם.
  3. הסירו כל רשומות A, AAAA, CNAME, ALIAS או הפניות (redirects) שמתנגשות עם אותו שם מארח.
  4. השאירו את שם המארח (hostname) שנוצר אוטומטית של CLIopen פעיל עד שהשם המותאם אישית שלכם יאושרו ויהיו תקינים.

הגדרות DNS מומלצות עבור תת-דומיין

צרו רשומות DNS עבור שם המארח המדויק שתזינו ב-CLIopen. לדוגמה, עבור app.example.com, התווית DNS היא app. כוונו אותה לכתובות ה-ingress של CLIopen שסופקו על ידי תמיכה של CLIopen או במסמכי השירות שלכם. אם הספק שלכם מבקש סוג רשומה, השתמשו ברשומה מסוג A עבור IPv4 וברשומה מסוג AAAA עבור IPv6 כאשר כתובות אלה מסופקות.

דוגמה:

app.example.com.  A     <כתובת IPv4 של CLIopen>
app.example.com.  AAAA  <כתובת IPv6 של CLIopen, אם זמינה>

כאשר CLIopen מספק יעד CNAME

שירותים מסוימים עשויים לספק שם מארח שנוצר, לדוגמה service.customer.co.cliopen.cloud. אם ההוראות לשירות שלך מציינות במפורש להשתמש ב-CNAME, צור רשומה כמו app.example.com CNAME service.customer.co.cliopen.cloud. השתמש ב-CNAME רק עבור תת-דומיינים, ולא עבור הדומיין הראשי, אלא אם ספק ה-DNS שלך תומך ב-ALIAS או ANAME flattening.

שימוש בדומיין הראשי

עבור דומיין בסיסי כמו example.com, רוב ספקי ה-DNS אינם מאפשרים שימוש ב-CNAME סטנדרטי. השתמש ברשומות A/AAAA המצביעות על כתובות הכניסה של CLIopen, או השתמש בתכונת ALIAS/ANAME של הספק שלך אם CLIopen סיפקה לך שם מארח יעד.

העברת תחום משנה שלם

אם אתה רוצה ש-CLIopen תנהל רשומות בתוך תת-דומיין כמו apps.example.com, צור רשומות NS עבור תת-הדומיין הזה המצביעות על שרתי ה-DNS של CLIopen שקיבלת. אל תשנה את שרתי ה-DNS עבור הדומיין כולו אלא אם ברצונך ש-CLIopen (או שירות DNS אחר) ינהלו את כל הרשומות.

רשימת בדיקה

  1. הישארו מעט בסבלנות כדי לאפשר התפשטות של DNS. שינויים קטנים מופיעים לעתים קרובות תוך דקות, אך ספקי שירות מסוימים מבצעים שמירה זמנית (cache) למשך זמן רב יותר.
  2. ודאו ששם המארח מצביע על היעד של CLIopen ולא על ספק קודם.
  3. הזן את שם הדומיין המלא בשדה 'Bring your own domain', ללא `https://` וללא נתיב.
  4. לאחר העדכון, בדוק את `https://app.example.com` בדפדפן שלך.
  5. השאר רשומות DNS ישנות רק אם הן אינן סותרות את שם הדומיין החדש.
> כיצד להעביר אזור DNS ל-CLIopen

האצילו את הדומיין לכתובות ns1.cliopen.com ו-ns2.cliopen.com, כך ש-CLIopen יוכל לפרסם רשומות עבור כל האזור.
faq/haavarat-ezor-dns

מהי משמעות העברת אזור כאן

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

לפני שינוי שרתי השמות

  1. העתק את רשומות ה-DNS הקיימות שאתה עדיין צריך, כגון אתר אינטרנט, דואר אלקטרוני, אימות, SPF, DKIM, DMARC ורשומות שירות.
  2. הוסף את האזור ב-CLIopen DNS. אם ההעברה עדיין לא מוכנה, CLIopen ישמור אותה אך לא יפעיל אותה עבור לקוחות עד שהאימות יעבור.
  3. צור את הרשומות הנדרשות ב-CLIopen DNS לפני החלפת שרתי השמות, אם אפשר.
  4. שימו לב להגדרת רשומת CAA בצורה נכונה, מכיוון שערכים שגויים עלולים למנוע הפקת תעודות.

העברת אזור

  1. פתחו את הגדרות הדומיין אצל הרשם, לדוגמה example.com.
  2. חפשו שרתי Nameservers, העברת DNS או הגדרות DNS סמכותיות.
  3. החליפו את שרתי ה-Nameservers הקיימים בערכים ns1.cliopen.com ו-ns2.cliopen.com.
  4. שמור את השינוי והמתן להתפשטות במאגר ובפתרונים.

אימות

חזור ל-CLIopen DNS ולחץ על בדוק שוב העברה. כאשר רשומות NS ציבוריות מציגות ns1.cliopen.com ו-ns2.cliopen.com, האזור יתווסף לתור לסנכרון והרשומות יהיו פעילות מ-CLIopen.

> הרשמה לחשבון וכניסה ראשונה

צרו חשבון עבודה אחד, הוסיפו את פרטי החיוב ושמרו את הגישה לכתובת הדוא"ל שאליה הצוות שלכם יכול לגשת.
faq/account-registration-and-login

חשבון אחד לניהול הזמנות ושירותים

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

הכנה לפני ההזמנה הראשונה

  1. הירשמו באמצעות כתובת דואר אלקטרוני עסקית.
  2. אשר את הודעת הדוא"ל אם האתר מבקש זאת.
  3. השלם את פרטי החיוב לפני ביצוע הזמנה בתשלום.
  4. הפעילו אימות דו-שלבי כאשר הוא זמין.

גישה עבור צוות

אל תשתפו סיסמאות, מפתחות פרטיים, טוקנים, קבצי תצורה שנוצרו או פרטי תשתית פנימיים.

> הערכה חודשית, הערכה שנתית וצריכה יומית בפועל

המחירים החודשיים והשנתיים משמשים להשוואה; עבור שירותים בתשלום מראש, הצריכה היומית קובעת לאחר אישור השינוי.
faq/billing-periods-and-credit-burn

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

השתמשו בהערכה החודשית כהשוואה לתקופה של 31 ימים, ובאומדן השנתי כהשוואה לתקופה של 372 ימים. צריכת היתרה בפועל עבור שירותים בתשלום מראש מתבצעת בהתאם לזמן השימוש בשירות ולתצורה המאושרת.

מה צריך לבדוק לפני שינוי מחיר

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

בעת מחלוקת, התייחסו לתקופה הספציפית

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

> סטטוס הזמנה לאחר תשלום

ההזמנה עשויה להמתין לאישור מספק התשלומים לפני שהיא מעובדת; צור הזמנה כפולה רק כאשר ההזמנה הראשונה בוטלה או פגה באופן ברור.
faq/order-status-and-payment-confirmation

סטטוס "בהמתנה" לא בהכרח מעיד על כשל

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

כיצד לפעול לאחר התשלום

  1. חזרו לדף הראשי של Cli>_ לאחר השלמת התשלום.
  2. בדקו את סטטוס ההזמנה בחשבון שלכם.
  3. אם ההזמנה עדיין ממתינה, אנא המתינו לאישור מצד הספק.
  4. במקרה של בעיה, שלחו לתמיכה את מספר ההזמנה ומספר הפניה של ספק התשלומים, אם הוא זמין.

מה לא לשלוח

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

> מידע שיזרז את הגדרת השירות

הכינו שם שירות, דומיין, גודל אחסון, כתובת דוא"ל לגישה ומפתח SSH ציבורי; אין להזין פרטים סודיים בטפסים.
faq/service-setup-information-needed

פרטים מדויקים חוסכים זמן

השתמשו בטפסים להזמנה עבור ערכים ציבוריים או לא סודיים: שם השירות, דומיין, תוכנית DNS, גודל אחסון, מעבד (CPU), זיכרון RAM, כתובת דוא"ל של מנהל או מפתח SSH ציבורי. סיסמאות, מפתחות פרטיים וטוקנים אינם צריכים להיות מוזנים בטופס.

הכן את עצמך לפני ביצוע ההזמנה

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

אל תשלחו סודות

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

> שינוי מעבד, זיכרון, דיסק או תקופת שמירה לאחר הזמנה

יש לשנות את השירות הקיים דרך פרטי השירות שלו, ולא ליצור הזמנה כפולה; שינוי משאבים עשוי לשנות מחיר, עלות שירות, צריכת קרדיט יומית, דרישה להפעלה מחדש וסיכון להפסקת פעילות.
faq/change-service-resources-after-order

שינוי שירות קיים, ולא יצירת שירות חדש

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

לפני אישור השינוי

  1. בדוק את השימוש הנוכחי ב-CPU, זיכרון RAM, שטח אחסון, גיבויים ושמירת ארכיון מחוץ לאתר.
  2. בדוק את המחיר היומי החדש ואת ההשפעה על היתרה.
  3. קרא הודעות בנושא הפעלה מחדש, תחזוקה או השבתה.
  4. לפני ביצוע שינוי שעלול להיות מסוכן, גבו (ייצאו) נתונים חשובים.

מה לעשות אם השינוי לא מתבצע כצפוי

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

> ביטול שירות ותקופת אחסון נתונים

שירות שכבר הוגדר מושהה תחילה, מוצג מועד מחיקה גלוי וניתן להגדרה, ולאחר מכן ניתן למחוק אותו לצמיתות בהתאם ללוח זמנים.
faq/cancel-service-and-data-retention

ביטול אינו מחיקה מיידית של כל השירותים

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

לפני מחיקה, בדוק

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

ייתכן שלא ניתן יהיה לשחזר לאחר התאריך

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

> גיבויים ובקשות לשחזור

הגיבויים משמשים לשחזור תפעולי, ולא כתחליף לייצוא; פעולת שחזור עלולה לדרוס נתונים חדשים יותר.
faq/backups-and-restore-requests

גיבוי אינו ארכיון או ייצוא

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

כיצד להכין בקשת שחזור

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

חשוב על ההשלכות לפני השחזור

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

> מהו Offsite Archive?

Offsite Archive שומר עותקים ארכיביים מרוחקים, בנפרד מגיבויים תפעוליים קצרים וממחזור החיים של השירות.
faq/offsite-archive-purpose

ארכיון מחוץ לאתר (Offsite Archive)

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

מתי להפעיל אותו

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

איך לחשוב על המחיר

הבסיס הוא MB-ימים: כמה נתונים מאוחסנים וכמה זמן הם נשמרים. התעריף מוצג ללקוח כאירו/GB/חודש, והתוצאה מעוגלת לסנטים שלמים.

> בחירת מעבד (CPU), זיכרון RAM ונפח דיסק עבור שרת VPS

בחרו את גודל השרת VPS בהתאם ליישום, מסד הנתונים, מטמון (cache), קבצי יומן (logs) וצמיחה צפויה. הודעות OOM או שימוש ב-swap מצביעים על כך שיש צורך ביותר זיכרון RAM.
faq/vps-cpu-ram-and-disk-sizing

התחילו בהתאם לעומס העבודה האמיתי, ולא לפי תחושה

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

סימנים המעידים על כך שהתכנית קטנה

  1. הגדלו את זיכרון ה-RAM כאשר מופיעות הודעות OOM (חוסר זיכרון), תהליכים שנסגרים או שימוש מוגבר ב-swap.
  2. הגדלו את מעבד ה-CPU בעת עומס חישובי מתמשך, דחיסה, בנייה או פעילות אינטנסיבית של אפליקציות.
  3. הגדילו את נפח הדיסק לפני שהמערכת קרובה להתמלא, כדי למנוע בעיות עם קבצים, יומנים או מסדי נתונים.
  4. לאחר כל שינוי, בדוק האם היישום הפסיק להתנגש בגבולות המקוריים.

מה לשלוח כששואלים לגבי גודל השרת

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

> מתי כדאי להשתמש בכתובת IP ציבורית עבור VPS

כתובת IP ציבורית ייעודית שימושית כאשר נדרש allowlist קבוע, גישה ישירה או מקור יציב לצורך שליחה (outbound) מצד ספק חיצוני או חומת אש.
faq/vps-public-ip-options

קודם כל, בדקו את כיוון התקשורת

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

שאלות לפני הזמנת כתובת IP

  1. שאלו את השותף החיצוני האם הוא מאשר כיוונים inbound, outbound או שניהם.
  2. השתמשו בשמות DNS במקום בכתובות IP מספריות בכל מקום שהמערכת החיצונית מאפשרת זאת.
  3. פתחו רק את הפורטים שהאפליקציה באמת צריכה.
  4. יש לשלוח את דרישת ה-allowlist לתמיכה לפני שינוי גישה.

מה כדאי להשאיר סגור

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

> גישה משותפת ל-SSH עבור VPS

חיבור ל-VPS מתבצע דרך נקודת SSH משותפת עם יציאה גבוהה, כאשר אין כתובת IP ציבורית. במידה וקיימת כתובת IP ציבורית, ניתן גם להתחבר ישירות באמצעות SSH.
faq/shared-ssh-access-for-vps

מדוע חיבור SSH משותף משתמש בפורט גבוה

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

כיצד להתחבר בהתאם לסוג הגישה

  1. בעת שימוש ב-SSH משותף, העתיקו את שם המשתמש, הכתובת והפורט ישירות משירות ה-SSH.
  2. התחברו באמצעות הפקודה `ssh -p <port> <username>@<public-host>` מהטרמינל המקומי שלכם.
  3. השתמשו במפתח הפרטי רק באופן מקומי ואל תדביקו אותו בצ'אט או בטיקטים.
  4. השתמשו במפתח הפרטי רק באופן מקומי באמצעות לקוח SSH או סוכן; דווחו לשירות התמיכה רק את שם המארח, הפורט, שם המשתמש ושגיאה גלויה.

כאשר רכשתם כתובת IP ציבורית

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

> בדיקה לפני חיבור דומיין מותאם אישית

לפני מעבר לדומיין, ודאו את סמכות ה-DNS, שם המארח המדויק, סוג הרשומה (דומיין או תת-דומיין) והיעדר רשומות קודמות שעלולות לגרום לקונפליקט.
faq/custom-domain-readiness-checklist

חשוב לדעת את שם הדומיין המדויק

ראשית, ודאו האם אתם מחברים דומיין ראשי כמו example.com או תת-דומיין כמו app.example.com. כל אפשרות עשויה לדרוש סוג אחר של רשומת DNS, הגבלות שונות מצד ספק ה-DNS ובדיקה אצל הרשם.

לפני שינוי ה-DNS

  1. בדוק היכן מוגדרים רשומות DNS סמכותיות עבור הדומיין שלך.
  2. הסר או שנה רשומות A/AAAA, CNAME, ALIAS, ANAME או הפניות שעלולות לגרום לקונפליקטים.
  3. השתמש בסוג הרשומה המומלץ עבור השירות ושם ה-hostname הספציפי.
  4. לאחר השינוי, המתינו להתפשטות ה-DNS ואז בדקו את תקינות ה-HTTPS.

ביצוע חזרה בטוחה

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

> סוגי רשומות DNS עבור שירותים

רשומות A/AAAA מצביעות על כתובות, CNAME יוצר קישור, MX משמש לשירות דואר ו-TXT משמש לאימות, כולל SPF, DKIM או DMARC.
faq/dns-record-types-for-services

אל תשליבו רשומות DNS באופן עיוור

לכל סוג של רשומה ב-DNS יש מטרה שונה. רשומות A ו-AAAA מצביעות על כתובות IP, CNAME יוצר שם אלטרנטיבי לתת-דומיין, MX מנתב דואר אלקטרוני, TXT מכיל אישורים ומדיניות דואר אלקטרוני, ו-CAA מגביל רשויות הסמכה.

הערות לגבי העתקת רשומות

  1. העתקו במדויק את השם, הסוג והערך בהתאם להוראות השירות.
  2. אל תשתמשו ב-CNAME עבור שם מארח שכבר מכיל רשומות אחרות, אם כללי ה-DNS אוסרים זאת.
  3. הכניסו את DKIM מתחת ל-selector שספק השירות מספק, ובדרך כלל הכניסו את DMARC תחת _dmarc.
  4. הקפידו על הגדרות CAA, שכן ערכים שגויים עלולים לחסום הנפקת תעודה.

כאשר שרת ה-DNS לא עובד

שלחו לתמיכה את שם השרת (hostname), סוג הרשומה, הערך הצפוי והתוצאה הגלויה. אל תשלחו פרטי כניסה למערכת ניהול DNS או צילומי מסך המכילים מפתחות API.

> הפצת DNS ו-TTL

ערך ה-TTL קובע כמה זמן שרתי ה-resolver יכולים לשמור על תשובה ישנה; במהלך המעבר, ייתכן שתתקבלו גם תוצאות ישנות וגם חדשות במקביל.
faq/dns-propagation-and-ttl

הפצת DNS: זכירה מטמון, לא קסם

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

בעת ביצוע שינוי מתוכנן

  1. הנמיכו את ערך ה-TTL לפני ביצוע שינוי מתוכנן, אם ספק ה-DNS מאפשר זאת.
  2. בצעו את השינוי ב-DNS פעם אחת והימנעו מעריכות חוזרות עד שהזיכרון המטמון יתרוקן.
  3. בדקו מול מספר רזולברים או רשתות כאשר התוצאות שונות.
  4. רשמו את זמן השינוי, הערך הישן, הערך החדש ו-TTL.

מה לשלוח במהלך אבחון

ציינו שם מארח (hostname), מטרה צפויה, תשובה ישנה גלויה, תשובה חדשה גלויה, TTL וזמן שינוי. אל תשלחו פרטי גישה לחשבון DNS או הערות פנימיות של הספק.

> תכנון שטח אחסון עבור Workspace Suite

תכנון נפח האחסון צריך לכלול קבצי משתמשים, תיקיות משותפות, גרסאות קודמות, סל מחזור, תצוגות מקדימות, עומס סינכרון וצפי לעלייה בשימוש.
faq/nextcloud-storage-planning

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

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

לפני הזמנת שטח אחסון

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

בעיות בסנכרון

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

> העברת מאגרי קוד ל-Gitea

תכנון מעבר של מאגרי Git תוך התחשבות ב-LFS, מודולים משניים (submodules), הרשאות, מפתחות פריסה, ווייבקים ו-CI/CD.
faq/gitea-repository-migration

העברה היא יותר מסתם העתקת היסטוריה

בנוסף להיסטוריית הריפוזיטורי, יש להעביר או להגדיר מחדש בעלים, צוותים, ענפים מוגנים, תגיות מוגנות, Git LFS, מודולים משניים, מפתחות פריסה, ווייבקים וחיבורי CI/CD.

בדיקות לפני המעבר

  1. רשום מאגרים, בעלים, משתפי פעולה, אובייקטים של Git LFS, מודולים משניים, ענפים מוגנים ותגיות מוגנות ומשתמשי אוטומציה.
  2. בדוק אובייקטים של Git LFS, מודולים משניים, הגנה על ענפים והגנה על תגיות.
  3. לאחר ההעברה, בדוק פעולות שחזור (clone), העלאה (push), Git LFS, מודולים משניים וביצוע CI.
  4. לאחר השלמת המיגרציה, בטלו או החליפו את הטוקנים הישנים מבלי לחשוף את ערכיהם.

נתונים רגישים במהלך העברה

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

> דומיין השליחה של Listmonk

לצורך קמפיינים, הכינו דומיין שליחה או תת-דומיין, זהות 'שולח', רשומות SPF, DKIM, DMARC, טיפול בהודעות החזרה וביטולים.
faq/listmonk-sender-domain-basics

אמינות משלוח מתחילה בדומיין

Listmonk דורש זהות 'מאת' ברורה ורשומות DNS שאפשר לאמת. SPF, DKIM ו-DMARC חייבים להיות מוגדרים עבור הדומיין או תת-הדומיין ממנו אתם רוצים לשלוח קמפיינים.

לפני הקמפיין הראשון

  1. בחרו דומיין או תת-דומיין לשליחה והגדירו את זהות השולח (From).
  2. פרסמו רשומות DNS לאימות, כולל SPF, DKIM ו-DMARC, כפי שנדרש על ידי ספק הדואר שלכם.
  3. שלחו הודעות בדיקה ובדקו את התנהגות ה-bounce, את כתובת ההחזרה (Return-Path) ואת הקישורים.
  4. בדקו את אפשרויות ההסרה מרשימה (unsubscribe) ואת ה-List-Unsubscribe לפני שליחת קמפיין אמיתי.

סודות דוא"ל אינם מתאימים לפניה לתמיכה

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

> הגדרות זמן ריצה עבור Classic Hosting

Classic Hosting יכול לפעול במצב אוטומטי או ידני. מעבד, זיכרון RAM, זיכרון, אחסון, שימור גיבויים, שימור ארכיון חיצוני, העלאות, מטמון ויומנים משפיעים על המחיר והיציבות.
faq/classic-hosting-runtime-settings

מצב 'אוטו' אינו תמיד הבחירה הטובה ביותר

מצב Auto Runtime מסייע בפרויקטים מוכרים, אך מצב ידני מתאים כאשר ברצונך לבחור במדויק את Nginx, Apache, FrankenPHP או סביבת ריצה (runtime) לשונית ספציפית. השתמש בכלי בחירת PHP רק כאשר סביבת הריצה שנבחרה תומכת בו.

הגדרות לפני הטעינה

  1. בחרו מצב הפעלה אוטומטי או ידני בהתאם לאפליקציה ולמסגרת העבודה.
  2. בחרו PHP 8.2, 8.3 או 8.4 רק כאשר סביבת הריצה שבחרתם תומכת בכך.
  3. הגדירו את כמות המעבדים (CPU), הזיכרון (RAM), האחסון, מדיניות ה-backup ואחסון הנתונים החיצוניים בהתאם לצרכים.
  4. לאחר הטעינה, בדקו העלאות, מטמון, יומנים ושגיאות אפליקציה גלויות.

כאשר האפליקציה לא מופעלת

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

> אילו פרטים בטוח לשלוח לתמיכה

מומלץ לספק מספר הזמנות, שמות שירותים, דומיינים, זמנים, שרתים ציבוריים, פורטים, מדיניות שמירת גיבויים, מדיניות ארכיון חיצוני, העלאות, מטמון, לוגים, צילומי מסך ושגיאות גלויות - תוך הימנעות מחשיפת מידע רגיש.
faq/support-safe-information-to-share

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

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

תוכן הודעה בטוח

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

מה אף פעם לא לשלוח

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