על Core Boot, Thunderbolt ו..אינטל

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

הטכנולוגיה שרציתי להכניס לשרת היא Thunderbolt. למי שלא מכיר, זהו פתרון של חיבור סריאלי חיצוני שעליו עובר ממשק PCI Express, ובתרגום לעברית: Thunderbolt הוא ממשק סריאלי המאפשר חיבור ציודים שצורכים המון נתונים בחיבור טורי. מהירות החיבור היא 10 ג’יגהביט וכל ציוד שמחובר הוא בעצם PCI Express רק עם תמיכה לחיבור “חם” (לא צריך להפעיל את המחשב מחדש), ואפשר לחבר ציודים שונים בחיבור טורי: המחשב שלך מתחבר למסך עם Thunderbold ומשם באותו חיבור אפשר לחבר דיסקים קשיחים, או כל ציוד אחר (ש”מדבר” Thunderbolt). חיבור פופולרי ב-מק עם Thunderbolt זו קופסא שמחברים למחשב הנייד ואליה מכניסים כרטיסים גרפיים או כל ציוד אחר.

לאחרונה אינטל החלה להוציא צ’יפים עם Thunderbolt, שזה דבר מעולה, אך אם תחפש דרך גוגל כרטיס PCI Express להוסיף למחשב שלך כדי להשתמש בחיבור הזה, סביר להניח שתעבוד קשה כדי למצוא כרטיס כזה, וגם כשתמצא זה לא יפעל על המחשב שלך עם רוב הציודים (לדוגמא: מוניטור של אפל עם חיבור כזה).

מדוע? כי חסר לך משהו ב-BIOS. חסר טבלאות ACPI, הגדרות ודברים נוספים כדי שכרטיס כזה ירוץ בצורה טובה. ב-BIOS יש תמיכה בכך שאתה מכניס כרטיס גרפי, אבל לא בצורה של חיבור “חם” דרך ממשק Thunderbolt, כלומר גם אם קנית מחשב חדש ואתה מוציא אותו מהניילונים ברגעים אלו, לא תהיה לו תמיכה גם אם תוסיף את הכרטיס.

מישהו צריך לכתוב את התמיכה ל-BIOS, ומי עושה זאת? יצרני ה-BIOS כמו Award וכו’, אולם בשלב זה עדיין אין עדכון מאסיבי לרוב ה-BIOSים שמותקנים במחשבים וגם לא יהיה. מבחינתם, זה יקח זמן וכשזה יצא – זה יצא רק למחשבים חדשים.

מי שמכיר לינוקס טוב, יודע שלינוקס יכול להסתדר כמעט עם כל דבר (כמובן שצריך להגדיר ולעבוד על הלינוקס עצמו), החל מקומודור 64 (לא צוחק) ועד המפלצות System Z של IBM, מערכות HPC ועוד, ולינוקס יודע להסתדר על חלופה ל-BIOS שנקראת CoreBoot, זו תוכנה בקוד פתוח שאפשר להריץ אותה על לינוקס, לבחור פרמטרים שונים ובסופו של דבר יוצא לך קובץ אשר אפשר לצרוב אותו על ה-BIOS שלך כתחליף (זה קצת יותר מסובך מזה ואפשר למצוא את ההוראות שם).

הבעיה עם דברים כמו Thunderbolt ו-CoreBoot, היא שצריך לכתוב תמיכה לכך ב-Core Boot, ולמי יש את התיעוד, הנסיון והידע בכתיבת דברים כאלו? אינטל. מי גוררת רגליים בתמיכה ופיתוח של CoreBoot? ניחשתם נכון.. אינטל.

מבחינת לינוקס עצמו, יש כבר תמיכה בכל ה”מסביב”. יש בלינוקס דבר שנקרא ACPIPHP עוד ממזמן (מ-2001 בערך) שיודע לתמוך בהכנסת ציודים בחיבור חם, אבל צריך להוסיף דברים ב-BIOS ובליבת לינוקס עצמה. ב-ליבה יש לא מעט כאלו שמוכנים כבר היום לבצע את זה, אך כל עוד אין תמיכה לא ב-BIOS ולא ב-Coreboot, הם לא יכולים לעשות מאומה. המצב, אגב, ב-Windows קצת יותר מסובך: ב-Windows צריך להוסיף מערכת שלמה לתמיכה ב-Thunderbolt וגם לוודא שב-BIOS יש את כל מה שצריך (שוב, בעיה בגלל יצרני ה-BIOS), כך שהמשימה שם יותר מסובכת.

מדוע אינטל גוררת רגליים? שאלה מעולה. AMD לדוגמא בהחלט תומכים בצ’יפים שלהם ב-Coreboot וניתן לראות את המהנדסים משתתפים ברשימות התפוצה לעיתים מאוד קרובות.

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

ביעוס.

למעוניינים: הפוסט הבא יהיה פוסט יותר מפורט על Coreboot, אולי תרצו לקרוא.

תכירו, חבילה חדשה: VPS Mini

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

בשבועות האחרונים תחום אחסון אתרים, בין אם זה אחסון משותף, שרתים וירטואליים (VPS) או שרתים יעודיים – רועש וגועש הרבה מעבר לרגיל "תודות" ל"פורץ הסעודי". פתאום בכנסת מדברים על תקן PCI, אבטחת אתרים וכשחשבתי שהנושא יורד מסדר היום לטובת דברים אחרים, הופיעו חדשות מסעירות אחרות: הרשות המשפטית לטכנולוגיה ומידע (רמו"ט) הוציאה צו נגד אחד הספקי אינטרנט שמציע חנות וירטואלית ורצתה לנתק לא פחות מ-1700 עסקים מהאינטרנט. בסוף ההגיון נכנס לפעולה והרמו"ט ואותו ספק הגיעו להסכמות לעבוד ביחד ולפתור את בעיית האבטחה של אותה חנות.

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

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

וכאן מתחילה בעיה רציינית: כל ספק מבטיח שאצלו הכי בטוח, אצלו הכל פיקס, מוגן, מאובטח, אפילו זבוב לא יכול להיכנס לחדר שרתים בכלל! אבל מבחינת אבטחת מידע, אין שום דרך ללקוח לוודא שהספק דובר אמת. יש דברים שהוא יכול לבדוק (אם יש לו ssh באחסון השיתופי הוא יכול לבדוק גירסת קרנל, הוא יכול להריץ פקודת mysql כדי לדעת גירסה אחרונה, הוא יכול ליצור קובץ php עם הפקודה ()phpinfo כדי לדעת מה מוגדר ב-PHP), אבל הוא לא תמיד יכול לדעת גירסת הפצה איזו יש שם, איזו גירסת Apache, האם יש חומת אש רצינית או שיש איזו קופסה עם חוק אחד ANY ANY? בכל זאת, מה לעשות, אצל ספקים גדולים ובינוניים הלקוחות מדברים בפעם הראשונה באיש מכירות שמבטיח את השמיים והארץ, ולא תמיד הוא יודע על מה מדובר או האם באמת יש את הדברים שהוא מציין…עכשיו עם עניין מאגרי המידע, לקוחות צריכים להתייחס לדברים יותר ברצינות (כי בסופו של דבר אם הם לא ואם יפרצו אליהם והמידע יזלוג החוצה, לקוחותיו של אותו בעל עסק יוכלו לתבוע אותו על רשלנות). צריך לשכור איש אבטחת מידע, חובה לעדכן את התוכנות של החנות/אתר ויש עוד דברים שהרמו"ט מחייבת לעשות על מנת להגן על המידע..

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

שטר 100 שקל

תרשו לנו להציע את חבילת VPS Mini, שרת קטן (512 מגה זכרון, 10 ג'יגה דיסק, 5 מגהביט סימטרי רוחב פס, כתובת IP אחת, מריץ Linux בלבד) ש"תפור" בדיוק לאותם גורמים. הוא כמובן לא יכול לשרת קניון מבקרים וירטואליים, אבל הוא בהחלט מספיק בשביל חנות וירטואלית עם כמה עשרות כניסות סימולטניות (או בערך 1000 איש ליום) והוא גם מתאים לפורמים מבוססי PHPBB וחבריו. המחיר? 100 שקלים (לא כולל מע"מ, העסק בין כה יקבל את המע"מ בחזרה תוך חודש וחצי מהמדינה). זה, לדעתינו, פתרון שעוזר ללקוח: הוא יכול להגדיר לעצמו כל דבר בשרת, מגירסת KERNEL, תמיכת SELinux, הצפנת תיקיות או כל המכונה (עם TruCrypt לדוגמא, כך שגם אם פורצים לוירטואליזציה של השרת, לא ניתן לעשות Mount לדיסק הוירטואלי ולקרוא נתונים. אגב, הנה טיפ מצוין איך ליצור מעין "דיסק" במכונה וירטואלית ועליו לאכסן קבצים מבלי שלאף אחד תהיה גישה זולת המשתמש שיצר).

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

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

  1. שרת זה, כמו שרתים אחרים שלנו אינו נמכר לילדים ולצעירים פחות מגיל 22
  2. המכירה היא לשנה מראש בלבד (ניתן להתחרט כמובן תוך 14 יום).
  3. אנו מבקשים מלקוחות מעוניינים לראות על אלו אתרים מדובר. איננו מוכרים לבעלי אתרי הונאות (כל הטריקים לגרום ללייק בפייסבוק, כסף קל, הימורים, שיתופי קבצים, סרטים, שרתי משחקים) ואנו שומרים את הזכות לעצמנו להחליט למי למכור ולמי לסרב (בטוחני שיש מספיק ספקים בארץ שיקבלו כל אחד).
  4. אין אפשרות להתקין Windows על חבילה כזו (מה לעשות, Windows 2008 עם חצי ג'יגה זכרון עוד לפני האפליקציות בקושי יזוז).
  5. ללקוחות קיימים – לא ניתן "לשנמך" לחבילה זו.

עדכון אבטחה קריטי ל-Apache

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

לצערי "חברינו" הטורקים החלו להשתמש בטריק הזה בימים האחרונים.

לכן, מי שמנהל שרתי Apache מומלץ כי יעשה את הדברים הבאים:

  • מי שמקמפל מקוד מקור, יכול להיכנס לאתר אפאצ'י ולהוריד את גירסה 2.2.20 הכוללת תיקון לפירצה.
  • שרתי אובונטו/דביאן – יש כבר תיקון בעדכונים. הריצו עדכון.
  • משתמשי CentOS … הממ, כאן קצת נכנסת פוליטיקה. אלו שבונים את CentOS טוענים ש"העדכון כבר ב-Repository". עבדכם הנאמן בדק והוא לא שם. בדקתי ליתר בטחון גם ב-Mirror של פייסבוק, וזה גם לא שם. מה עושים?
    • לוקחים מכונת סנטוס 64 ביט (לא על שרת פרודקשן!), מורידים את הקובץ הזה, זהו קובץ SRPM הכולל את הקוד מקור + תיקונים.
    • כ-root מריצים פקודת: rpmbuild –rebuild file (שימו לב, יש 2 מינוסים לפני ה rebuild) כאשר file הוא הקובץ שהורדתם מהקישור הנ"ל.
    • סביר להניח שנסיון הבניה ישר יזעק שחסרות לו תלויות. התקינו את התלויות עם yum (עניין של העתק והדבק) והריצו לאחר מכן את הפקודה מחדש.
    • בסוף הקימפול יהיו לכם בתוך תיקיית usr/srv/redhat/RPMS/i686/ מס' קבצי RPM. הקבצים שתצטרכו להתקין הם: httpd, mod_ssl, httpd-manual (את ה-manual אפשר להעיף אם לא התקנתם אותו מלכתחילה).
    • לאחר ההתקנה, הפעילו מחדש את שרות האפאצ'י ( service httpd restart ) ובדקו אם הכל פועל כמצופה.
    • במידה והכל פועל, אפשר להעתיק את קבצי ה-RPM לשאר השרתים.
  • משתמשי WHM/CPANEL – כנסו לתוך ה-whm, הפעילו את EasyApache וודאו כי הגירסה היא 3.6.1 לפחות. הפעילו build מחדש, הוא כבר יוריד אפאצ'י 2.2.20 ויקמפל.
  • משתמשי הפצות אחרות – שרותי העדכון שלכם אמורים לתת לכם אפאצ'י מעודכן.

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

מדריך: אתרים קטנים וחסכון כספי ניכר (חלק שני)

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

נתחיל בהקמת השרת. השרת יכול להיות כמעט כל מחשב ישן, אולם לפני שאתה ניגש לנער את האבק מהמחשב הענתיקה שלך, כדאי שתיקח בחשבון את הפרט החשוב הבא: למחשבים הישנים יש גם ספקי כח שצורכים די הרבה חשמל והם יצרכו אותו באותו "שרת" 24 שעות, 7 ימים בשבוע, מה שאומר שיש סיכוי לא קטן שחשבון החשמל שלך יגדל. מה אפשרי לעשות? כדאי לחשוב אם להשקיע במחשב בתצורת Mini ITX, מחשבים מבוססים לוח ומעבד של VIA לדוגמא, או לוחות עם מעבד אינטל ATOM והכי חשוב: מארז ITX. אלו מארזים שמגיעים עם ספקי כח חיצוניים קטנטנים ושמשתמשים בהרבה פחות חשמל. מעבד ATOM לדוגמא צורך רק 7 וואט שזו צריכה ממש מזערית מול כל פנטיום 4 או כל מעבד שולחני רגיל. כדאי לשים לב גם לדבר הבא: אותו "שרת" לא הולך לקבל כמויות של מיליוני Hits כך שמעבד ATOM מספיק בהחלט לשרת קטנטן.

לאחר שהמחשב מוכן ומחובר לרשת (חיבור חוטי בלבד), נתקין עליו את הפצת הלינוקס שאנו מעוניינים, וכאן ישנה נקודה חשובה: עדיף להתקין הפצה המוגדרת מראש לעדכונים למשך זמן רב מאשר הפצה שמשתנה כל שנה. במילים אחרות: עדיף Ubuntu LTS או CentOS מאשר Ubuntu רגיל או Fedora או Open SuSE. ההתקנה עצמה צריכה לכלול חלקים שאתם צריכים, בין אם זה שרת MySQL או PostgreSQL, שרת Apache, תמיכת PHP וכו', הכל בהתאם להעדפות ולמה שתריצו על אותו שרת.

ההתקנה עצמה צריכה לכלול חלקים שאתם צריכים, בין אם זה שרת MySQL או PostgreSQL, שרת Apache, תמיכת PHP וכו', הכל בהתאם להעדפות ולמה שתריצו על אותו שרת. אחד ההגדרות הכי חשובות בשרת היא כתובת IP קבועה ולא כתובת IP מה-DHCP שייספק הנתב הביתי שלכם. דבר זה חשוב מאוד ותיכף נגיע אליו. יש להגדיר משתמש רגיל בו ניכנס למערכת על מנת לעבוד ולתחזק את השרת הקטן.

לאחר שההתקנה הסתיימה, נצטרך לבנות או להעביר את התוכן ואפליקציית ה-WEB שלנו. ישנם כאלו שישימו את האתר עצמו במחיצת ברירת המחדל (ב-Centos זה var/www/html/). מומלץ לשים את הדברים במחיצה נפרדת ושונה מההגדרות ברירת המחדל (היכן שתרצו, יש כאלו שישמו ב-opt/, אחרים ישימו ב-home/user/ שלהם, או כל מקום אחר). חשוב שבזמן העברת האפליקציה לשרת, תהיה מחיצת logs ששרת ה-Apache יכתוב לוגים של שגיאות וכניסות אליה. יש לוודא כי ההרשאות למחיצה אינן כתיבה/קריאה/הרצאה לכל העולם ואחותו (777), אלא משהו באזור ה-755 (כתיבה/קריאה/הרצאה לבעלים, השאר קריאה והרצה).

כעת נגדיר לנו שרת וירטואלי בשרת ה-Apache שהוא יהיה זה שיהיה אחראי על האפליקציית Web שלנו. קובץ הקונפיגורציה (נקרא לו לשם הדוגמא web.conf) ישב במחיצה etc/httpd/conf.d/ ב-Centos או etc/apache2/sites-available/ באובונטו). מה יהיה בתוך אותו קובץ? את הטקסט הבא

<VirtualHost *:80>
ServerAdmin [email protected]
DocumentRoot /var/web/www/myblog
ServerName mydomain.com
ServerAlias www.mydomain.com
ErrorLog /var/web/www/logs/blog-error-log
LogFormat "%h %l %u %t "%r" %>s %b "%{Referer}i" "%{User-Agent}i"" combined
CustomLog /var/web/www/logs/blog-access_log combined
</VirtualHost>

נעבור על השורות:

  • שורה ראשונה אומרת לשרת הוירטואלי של אפאצ’י להאזין לפורט 80
  • בשורה שניה אנו מגדירים בעצם מי מקבל את הדואר על האתר הזה.
  • שורש שלישית אומרת מהו בעצם מחיצת ה”שורש” שבו תשב אפליקציית ווב או הדפים שלנו
  • שורה רביעית אומרת מה שם ה-Domain שקנינו ואיתו אנו משתמשים
  • שורה חמישית נותנת לנו כינוי נוסף לשרת שלנו (אותו שם עם תוספת WWW בהתחלה)
  • שורה שישית אומרת להיכן יכתבו השגיאות, אם יש.
  • שורה שביעית אומרת איך בעצם יורכב הלוג של הגישה ומה בעצם יכתב באותו לוג מהפרטים שהדפדפנים של הגולשים נותנים בתוספת פרטים כמו שעה, כתובת IP וכו’.
  • שורה שמינית אומרת להיכן יכתב לוג הגישה ובאיזו צורה הוא יכתב
  • שורה תשיעית מסיימת את הגדרות השרת וירטואלי

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

משתמשי אובונטו, לאחר שהגדירו את הקובץ, יצטרכו להוסיף לינק לקובץ אל תוך etc/apache2/sites-enables/

לאחר שהגדרנו את הקובץ, נפעיל את שרת ה-Apache מחדש: service httpd restart ב-CentOS או service apache2 restart באובונטו. לאחר ההפעלה אם לא התקבלו שגיאות בטרמינל, נוכל לבדוק אם יש שגיאות בקובץ ה-Log הראשי של השרת שנמצא ב-var/log/httpd/error_log. סביר להניח שיופיעו שם מס’ אזהרות שונות, אולם אם יש שגיאה שהשרת לא יכל לכתוב או ליצור קבצי Log לדוגמא, יש לתקן את הבעיה ולהפעיל את שרות apache מחדש.

אם לא התקבלו כל שגיאות, הגיע הזמן לנסות לראות אם אנו מצליחים לגלוש לאתר החדש. בתחנה עצמה שאנו עובדים בה אנו צריכים “לתחמן” את התחנה כדי לגלוש: יש לשנות קובץ hosts שיכליל את השורה הבאה:

192.168.1.10         mydomain.com

השורה הזו אומרת למחשב שלנו: אל תחפש באינטרנט מהי הכתובת ל-mydomain.com. מבחינתך הכתובת 192.168.1.10 זה mydomain.com (הכתובת הזו אמורה להיות כתובת ה-IP של השרת שלכם ו-mydomain.com אמור להיות שם הדומיין שרכשתם). בלינוקס הקובץ  הוא etc/hosts/ וב-Windows הקובץ הוא: c:windowssystem32driversetchosts. שנו את הקובץ ושמרו (משתמשי Windows: יש להשתמש בעורך טקסטים כמו Notepad ולהקפיד לבחור “שמור” ולא “שמור בשם”, אחרת העורך יוסיף את הסיומת txt. והקובץ יקרא hosts.txt וזה לא יעבוד).

לאחר ששמרנו, נפתח דפדפן ונגלוש לכתובת שרכשנו וכתבנו ב-hosts לפי השם, כלומר צריך להזין את הכתובת: http://mydomain.com (רק שבמקום mydomain.com יש לרשום את שם הדומיין שרכשתם כמובן). אם הכל תקין, אתם תקבלו בדפדפן את האתר שלכם. ברכותיי, עברתם את החלק העיקרי! תנו לעצמכם טפיחה על השכם!

עכשיו הגיע הזמן להגדיר באמת שם המתחם שרכשתם שיגיע אליכם ולשם כך יש לעשות מס’ צעדים.

במאמר הקודם המלצתי לפתוח חשבון ב-zoneedit. אם לא פתחתם שם חשבון, פתחו עכשיו והזינו שם את שם המתחם שרכשתם. לאחר ההזנה תקבלו 2 שמות של ns records וכתובת ה-IP שלהם שאותם תצטרכו להזין באתר רישום שם המתחם שרכשתם: היכנסו לאתר שמשם רכשתם את שם המתחם שלכם, וחפשו הגדרות name servers. שנה את הפרטים שם לפי הפרטים שנתן לכם שרת zoneedit. השינוי אמור לחול תוך 24-48 שעות אבל כיום השינוי בד”כ נעשה תוך שעה שעתיים, אם כי יש תמיד שרתים שלוקח להם זמן להתעדכן (עד 48 שעות).

כעת ניכנס שוב ל-zoneedit ונבקש להוסיף A record. ב-zoneedit בחרו את השם מתחם שלכם ובחרו IP Address (האפשרות הראשונה משמאל. השרת מבקש שם וכתובת IP, אנחנו נוותר על השם ונכניס את כתובת ה-IP שספק האינטרנט שלנו נתן לנו. כיצד נדע מהי הכתובת שלנו? פשוט: היכנסו לאתר whatismyip ושם בגדול תופיע לנו כתובת ה-IP שלנו. העתיקו כתובת זו ל-zoneedit לשדה ה-IP ואשרו. zoneedit יבינו לבד שזו כתובת האתר שלכם ויציעו לכם הוספה של www אופציונאלית, כך שגם גלישה עם www תגיע לאתרכם. אשרו זאת. במזל טוב, מעכשיו מי שיגלוש לכתובת התחום שלכם יגיע אל אתרכם (בכפוף לעדכוני ה-DNS שעשיתם אצל רשם שם המתחם שלכם)…

כמעט..

יש מישהו שחוסם את כל העולם ואחותו להנות מזיו אתרכם המדהים, וזהו הראוטר בביתכם שבברירת המחדל שלו חוסם כניסה פנימה להכל. צריך לשנות אותו. פתחו דפדפן, ו”גלשו” לתוך כתובת הראוטר שלכם (זה יכול להיות http://10.0.0.138 או http://192.168.1.1 או http://192.168.2.1 , עיינו בחוברת הראוטר), וחפשו שם פונקציה של Port Forwarding. הפונקציה הזו אומרת לראוטר שמעתה, כל מי שינסה להגיע אל כתובת ה-IP שלכם בפורט 80, יגיע אל השרת הקטן שלכם שמארח את אתרכם. כל מה שיש לעשות הוא להגדיר שם פורט 80 ב-TCP וכתובת היעד היא כתובת ה-IP של השרת שלכם. ב-Linksys זה נראה כך:

firewall-rule לאחר שתגדירו את הפורט, שמרו את ההגדרות. אצל חלק מהראוטרים הם יבקשו להפעיל את עצמם מחדש (כמו ראוטרים של Edimax). אשרו. (עדכון: ראוטרים מסויימים שבזק מוכרים [במיוחד של סימנס] לא יאפשרו למחשבים בתוך הרשת הפנימית הביתית לגלוש לאתר עצמו ובמקום זאת הם יציגו את דף הכניסה לראוטר. במקרים כאלו יש צורך במחשבים הביתיים להגדיר את כתובת ה-IP הפנימית במחשב הגולש ל-IP הפנימי של השרת)

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

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

לשם כך נשתמש בתוכנה על השרת לינוקס הנקראת ddclient. התקינו אותה (apt-get install ddclient באובונטו, yum install ddclient ב-CentOS). לאחר ההתקנה, יש צורך כמשתמש root לערוך את הקובץ etc/ddclient/ddclient.conf/ ושם חפשו את החלק שנקרא ZoneEdit. נשנה אותו לפי הצורך. הנה דוגמא:

##
## ZoneEdit (zoneedit.com)
##
server=www.zoneedit.com,               
protocol=zoneedit1,                    
login=MyUser,          
password=Mypassword
www.mydomain.com, domain.com

נשנה את הפרמטרים בהתאם (שם משתמש, סיסמא, שם תחום) ונפעיל את השרות: service ddclient restart ולאחר מס’ שניות הסקריפט של ddclient יעדכן אוטומטית את zoneedit בכתובת החדשה שברשותנו. ddclient ימשיך לרוץ בשרת ברקע ומדי מס’ דקות הוא יבדוק האם כתובת ה-IP שלנו שונתה או לא. אם כן, הוא יעדכן שוב את zoneedit. אם לא, הוא לא יבצע כלום וימשיך לנטר את הכתובת IP שלנו.

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

עתה מגיע החלק של האזהרות (לא חשבתם שתתחמקו מזה, נכון? 🙂 )

  • לא כולם נחמדים. מהרגע שהאתר שלך פתוח לעולם, יהיו מי שיגלשו וישמחו להפיל לך את האתר, להעתיק את החומר או למחוק את השרת. אינך יודע אף פעם מי הילד המשועמם וחסר חיים שמחפש להפיל את אתרך סתם כך בשביל הכיף. מה שאתה צריך לעשות, הוא לדאוג שרישוי הקבצים הוא מספיק לצרכים של שרת ה-Web שלך ולצרכיך ותו לא. עליך לבדוק מבחינת הקוד שלך שאינך משאיר כל מיני “חורים” שדרכם אפשר להכניס משאית ולהרוס את אתרך.
  • גרפיקה כבדה – לא באתרך. זה מאוד נחמד שאתה רוצה לשתף תמונה של כל ה”משפוחה” בטיול לבניאס עם קבצים בגודל 8 מגהבייט כל תמונה, אבל כך לא רק שהאתר שלך לא יגיב, גם הגלישה שלך תהיה איטית בטירוף. הגלישה באינטרנט בארץ היא אסינכרונית, כלומר כשמישהו גולש לאתר שלך, אתה מפסיד מהירות גלישה. רוצה לשים תמונות גדולות, קבצי פלאש גדולים וכו’? ארח את הקבצים האלו באתר חיצוני (כמו Google Sites) ותן לינק קישור לקובץ שנמצא בחוץ, כך אחרים יוכלו לקבל את הקבצים הגדולים במהירות ואתה לא תסבול מאיטיות.
  • אם רוב הצופים של אתרך הם מחו”ל, הם יקבלו אתר איטי, לפעמים מאוד איטי, כי מה לעשות: שרתים שנמצאים אצל ספק האינטרנט מספקים תעבורה הרבה יותר מהירה מהשרת שלך שנמצא במרתף ושמחובר ל-ADSL. אם רוב הגולשים לאתרך הם מחוץ לישראל, אולי כדאי שתיקח לך חבילת אירוח זולה בחו”ל ותדלג על העניין של שרת בבית.
  • כדאי תמיד להשתמש בדחיסה. אם אתה מפתח את האתר שלך, כדאי לבנות או להשתמש במגנוני Cache או להשתמש בדחיסה (כל הדפדפנים המודרניים תומכים בכך כיום), כך רוחב הפס שיצטרך האתר שלך יופחת משמעותית בהשוואה לגלישה באתר ללא Cache וללא דחיסה.

בהצלחה