הבלוג של ארתיום
בלוג על לינוקס, תוכנה חופשית, מוזיקה, סלסה, ומה לא!
כיצד לא לעשות יוניקוד
הסיפורו של הניסיון להדפיס "שלום" במספר שפות במסוף של חלונות.
http://blog.cppcms.com/post/105
לבנות RPM להרבה הפצות
כשאתה מפתח הפרויקט קוד־פתוח, קל מאוד להפיץ קוד מקור, אבל כשזה מגיע לקבצים בינאריים, זה הופך לבעיה הרבה יותר משמעותית. יש עשרות הפצות, כל אחת מגיע במספר גרסאות שונות ומביא אתה חבילות טיפה שונות. לכן, לאדם אחד זה כמעט ובלתי אפשרי לבנות חבילות לכל הפצה אפשרית.
בזכות debootstrap היה לי יחסית קל לבנות חבילות deb ל־Debian ו־Ubuntu, אבל המצב הרבה יותר מורכב כשמדובר ב־rpm כי אין דרך קלה לשים את הפצת rpm בספריה ולעשות לתוכה chroot.
בהמלצת שגיא בן־עקיבא התחלתי להשתמש ב־Open Build Service של OpenSuse.
האמת, אני מאוד מרוצה! כל מה שצריך זה להעלות Source RPM או קובץ spec, כל השאר ייעשה בצורה אוטומטית: בניה למספר הפצות ופלטפורמות, הכנת מקורות מסודרים ואפילו אתה מקבל repository מסודר.
בצורה כזו הכנתי rpmים ל־3 הפצות (Fedora, Suse, CentOS) כולל מספר גרסאות וגם הכל עבור שתי ארכיטקטורות: x86 ו־x86_64.
http://download.opensuse.org/repositories/home:/artyom-beilis/
מה שנותר... להבין כיצד משתמשים בשירות עבור debים
שוחררה גרסה יציבה 1.0.0 של CppCMS המופצת תחת רישיון כפול
היום, אחרי מספר שנות פיתוח, שוחררה גרסה יציבה של CppCMS 1.0.0, אחרי תקופה ארוכה של גרסאות בטא. הגרסה הזו מהווה אבן דרך משמעותית בהתפתחות של CppCMS, הן מבחינה טכנולוגיות והן מבחינה עסקית.
החל מגרסה 1.0.0, ספריית CppCMS תהיה זמינה תחת רישיון חופשי LGPLv3 ותחת רישיון מסחרי שיאפשר פיתוח יישומים קנייניים תוך שמירה על שלמות המוצר והגנה על הסודות המסחריים שלו.
למידע נוסף על הרישוי החלופי והמחירים אנא כנסו לאתר שלנו:
http://commercial.cppcms.com
גרסה זו, עברה שכתוב יסודי ושינויים ארכיטקטוניים עמוקים שהזניקו את הפופולריות שלה מיד עם שחרור גרסאות בטא ראשונות. מבין החידושים הטכנולוגיים:
- הכנסה של API ו־ABI יציבים
- תמיכה מובנית ב־Ajax ו־Comet
- שיפורים מהותיים בלוקליזציה
- תמיכה מובנית ב־Windows
- שיפורים משמעותיים באבטחה: מסנני XSS וכלים למניעת CSRF ועוד.
- שרת HTTP מובנה לפיתוח ומערכות משובצות
הענף הישן יציב CppCMS 0.0.x לא נתמך יותר. כל משתמשיי הענף הישן מתבקשים לעבור לגרסה החדשה. יש לציין, לא ידוע לי על משתמש אחד שנשאר עם הגרסה הישנה.
על nginx ועל symbolic links
בעקבות הכתבה של עופר כהן הגעתי לטבלת השוואה מעניינת בין Apache לבין nginx. מה שהפתיע אותי זה שכדי להעביר קובץ http://example.com/site/files/images/layout/header.png השרת nginx מבצע קריאת stat בודדת. הטבלה עשתה השוואה עם apache שעשה O(n) קריאות עבור תיקיה בעומק n לעומת O(1) עבור nginx...
ברגע שראיתי את זה נדלקה לי נורת אזהרה! מה עם symbolic links?
הסבר: נניח אני איצור קישור סימבולי בשם mypicture.png שיפנה ל־/etc/passwd או לקובץ רגיש אחר, אז ע"י גישה לקובץ תמים אני אוכל לקרוא כל קובץ שיש לשרת web הרשאות לקרוא.
לכל השרתי web יש אופציה לא לעקוב אחרי קישורים כאלה מטעמי אבטחה וזאת גם אופציה מומלצת לעבודה. מה חשוב, זה שבלתי אפשרי לעשות בדיקה כזו ב־O(1) קריאות מערכת ההפעלה (לפי עומק התיקיה).
אז החלטתי לבדוק בעזרת strace, כמה קריאות stats בפועל מבצעים apache, lighttpd ו־nginx כשהאופציה כזו מופעלת וגיליתי... ש־nginx בכלל לא תומך באופציה כזו! קרי הגדרת אבטחה בסיסית שכל שרת אינטרנט החל מ־apache ועד ל־thttpd תומכים בו (אגב גם השרת הפנימי של cppcms) בכלל לא מופיעה בו!
התשובה (רוסית) של מפתח nginx היא להשתמש ב־mount -o nosymfollow עבור מערכת הקבצים כדי לעקוף את הבעיה.
חבל...
Nginx? תודה לא... Lighttpd
לאחרונה יש יותר ויותר כתבות על Nginx ועד כמה השרת הזה מעולה. נתח השוק של Nginx לפי הסקירות האחרונות של Netcraft עומד על כ־10%. אז כנראה יש סיבה לכך!
עכשיו, דברים שלא מספרים:
- רוב שרתי ה־Nginx המופיעים ב־Netcraft עובדים כ־Reverse Proxy או מטפלים בעיקר בקבצים הסטטיים. בהרבה מאוד המקרים Nginx הוא מתפקד כ־Load Balancing Frontend לפי שרתי Apache.
- התמיכה של Nginx בתוכן דינאמי היא בין מועטה עד לוקה בחסר:
- אין תמיכה ב־CGI כלל.
- אין תמיכה בניהול של שרתי FastCGI, כך שהשירות התוכן הדינאמי שלך חייב לרוץ התהליך נפרד ואתה צריך לדאוג לו (למשל להעלות אם הוא נפל מסיבר כלשהי)
- הגדרות FastCGI לא תואמות תקן -
PATH_INFOלא מוגדר כברירת מחדל. צריך לעבוד קשה כדי שהוא יעבוד נכון. מה שגורם לא מעט בעיות לאלה שמגלים שהיישום שלהם שבור בצורה לא ברור ולא מבינים למה. - תמיכה ב־SCGI שבורה לחלוטין. הוא לא מטפל ב־Status כמו שצריך, שזה אומר שרוב ההפניות תהינה שבורות אלא אם היישום שלך ישלח את התשובה כ־HTTP נקי.
להמשיך?
כן, אם אתם צריכים Reverse Proxy או לטפל בתוכן סטטי זהו שרת מעולה. אחרת, תחשבו פעמיים.
אני ממליץ בחום על Lighttpd: מהיר כמו Nginx ובנוי על אותם העקרונות, מתועד היטב, מטפל תוכן סטטי ודינאמי בצורה יוצאת מן הכלל. קל לקינפוג ועוד.
לפני שאנשים יקפצו ויגידו:
Lighttpd זולג!
אז התשובה היא, לא הוא, לא זולג.
ציטוט:
there are no memory leaks just stupid ways to use lighttpd.
e.g. it is really stupid to stream large files via a fastcgi app, when x-lighttpd-send-file could do a much more efficient job
תקראו עוד:
