פלאנט תוכנה חופשית בישראל (Planet FOSS-IL)

31 אוקטובר, 2014

Shlomi Noach

Percona Live 2015: Call for Papers is open

And not for long!

The Call for Papers for Percona Live MySQL Conference and Expo, to be held at Santa Clara in April 2015, is open. The dead line for submissions is Nov. 16th; that's just around the corner.

As with previous years, we will hold a 4 day conference, the first being a tutorials day and three days for sessions, BoF and lightning talks, as well as community events. The committee is expecting to review at about 250-300 submissions, out of which it will pick at about 100 talks to schedule or reserve.

We will be using these tracks:

This year we will roughly pre-define the desired number of sessions we wish to have per track. This is not set in stone and everything is fluid. Yet, this will give us better guidelines at choosing and pursuing content for this conference.

Submitting a proposal

We encourage all members of the community to submit their tutorial/session/BoF proposals as soon as possible. Please register/login at the conference home page.

The guidelines for submitting a proposal are generally unchanged; please review past recommendations: [1], [2], [3], [4]. To add to all these:

The committee

This year's committee includes:

Looking forward to reviewing your papers!

 

31 אוקטובר, 2014 06:25 AM

30 אוקטובר, 2014

Yosef Or Boczko

עד כמה משתמשים בוויקיפדיה ?

ערב טוב.

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

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

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

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

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

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

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

סטטיסטיקת צפייה

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

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

כמובן, מתבקש מכך, שיר לכבודו – „שירו של אבא” של נעמי שמר.

בברכה,

יוסף אור

לא לשווא אחי חצבת לבנין חדש
כי מן האבנים האלה יבנה מקדש

 

30 אוקטובר, 2014 04:53 PM

29 אוקטובר, 2014

Shachar Shemesh

עידן ה–SSL

לאחרונה נודע לי על חברה (דווקא ישראלית) שמנפיקה אישורי הצפנה (signed certificates) בחינם עבור שימוש לא מסחרי. מדובר באישורים הזולים ביותר (רק שם המתחם חתום, לא זהות המפעיל), אבל זה מספיק בשביל לקבל התחברויות ללא אזהרות מעצבנות. לאור עידן post Snowden, אני חושב שזה ראוי.

לאור זאת, אני גאה להכריז שהבלוג שלי עכשיו זמין גם בכתובת https://blog.shemesh.biz! יפי!

עכשיו לבעיות…

הבעיה הראשונה היא שה-CA,‏ StartSSL, לא מוכר ע״י חלונות XP ועל ידי אנדרואיד. זה אומר שמי שגולש אל הכתובת הזו משתי המערכות האלו יקבל את אותה הודעת האבטחה שהייתם מקבלים אם הייתי מצפין ללא CA בכלל.

הבעיה השניה היא שמי שגולש עם Internet Explorer על חלונות XP עלול לא לקבל את האתר בכלל. הדינוזאור הזה לא תומך ב-SNI, ועל כן לא ניתן להפעיל מספר אתרים על אותה הכתובת ולהצפין אותם. אני לא סגור מה הוא כן יקבל: או דף שאומר "No site configured at this address", או תעודה שלא מתאימה לאתר שלי (שאז זה לא כל כך נורא – ממילא המערכת לא מכירה את ה–CA). כמו כן, אין לי מושג מה המצב על מערכות Apple למיניהן.

סטטיסטית, כ–10% מהגולשים לאתר מזדהים כגולשים מאנדרואיד, וכ–8% גולשים מחלונות XP, וכ–3% גולשים באינטרנט אקספלודר גרסה 7 או 6 (מה שזמין ל–XP). צריך לקחת בחשבון שחלק מהגולשים שציינתי הם, סביר להניח, רובוטים שמנסים להסתיר את עצמם. לצורך ההשוואה, בחודש אוקטובר קיבלתי כניסה אחת מחלונות ME, שתי כניסות מחלונות 3‎.xx, שלוש כניסות מחלונות 95 ו–98 (כל אחד), 180 כניסות מחלונות NT ו–830 כניסות מחלונות Vista. לאור זה שברור לגמרי שאף אחר לא באמת משתמש באף אחת מהמערכות האלו, סביר להניח שמדובר ברובוטים.

הבעיה היא שלא כל כך כדאי להחזיק את שני האתרים באוויר. כל מיני מנועי חיפוש עלולים לחשוב שמדובר בהעתקים לצרכי Page rank stuffing, ולתת קנס. מצד שני, אם אני שם redirect, אז אני מכריח אנשים להגיע לאתר מוצפן שאין בו, באמת, שום דבר סודי, או מצדיק הצפנה (למעט אם עושים log in, מה שאני מניח שרובכם לא עושים).

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

שחר

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

The post עידן ה–SSL appeared first on לינוקס ותוכנה חופשית.

29 אוקטובר, 2014 04:25 AM

27 אוקטובר, 2014

Shlomi Noach

Refactoring replication topologies with Pseudo GTID: a visual tour

Orchestrator 1.2.1-beta supports Pseudo GTID (read announcement): a means to refactor the replication topology and connect slaves even without direct relationship; even across failed servers. This post illustrates two such scenarios and shows the visual way of mathcing/re-synching slaves.

Of course, orchestrator is not just a GUI tool; anything done with drag-and-drop is also done via web API (in fact, the drag-and-drop invoke the web API) as well as via command line. I'm mentioning this as this is the grounds for failover automation planned for the future.

Scenario 1: the master unexpectedly dies

The master crashes and cannot be contacted. All slaves are stopped as effect, but each in a different position. Some managed to salvage relay logs just before the master dies, some didn't. In our scenario, all three slaves are at least caught up with the relay log (that is, whatever they managed to pull through the network, they already managed to execute). So they're otherwise sitting idle waiting for something to happen. Well, something's about to happen.

orchestrator-pseudo-gtid-dead-master

Note the green "Safe mode" button to the right. This means operation is through calculation of binary log files & positions with relation to one's master. But the master is now dead, so let's switch to adventurous mode; in this mode we can drag and drop slaves onto instances normally forbidden. At this stage the web interface allows us to drop a slave onto its sibling or any of its ancestors (including its very own parent, which is a means of reconnecting a slave with its parent). Anyhow:

orchestrator-pseudo-gtid-dead-master-pseudo-gtid-mode

We notice that orchestrator is already kind enough to say which slave is best candidate to be the new master (127.0.0.1:22990): this is the slave (or one of the slaves) with most up-to-date data. So we choose to take another server and make it a slave of 127.0.0.1:22990:

orchestrator-pseudo-gtid-dead-master-begin-drag

And drop:

orchestrator-pseudo-gtid-dead-master-drop

There we have it: although their shared master is inaccessible, and the two slave's binary log file names & position mean nothing to each other, we are able to correctly match the two and make one child of the other:

orchestrator-pseudo-gtid-dead-master-refactored-1

Likewise, we do the same with 127.0.0.1:22988:

orchestrator-pseudo-gtid-dead-master-begin-drag-2

And end up with our (almost) final topology:

orchestrator-pseudo-gtid-dead-master-refactored-2

Notice how the two slaves 22988, 22989 are happily replicating from 22990. As far as they're concerned, there is no problem in the topology any more. Now it's your decision: do you decommission the old master? You will need to RESET SLAVE on 22990 (can do via orchestrator), turn off 22990's read_only (can do via orchestrator) and change DNS entries (or what have you).

Scenario 2: a local master ("relay-master") unexpectedly dies

In this scenario we have a deep nested topology, and a local master died. What of its slaves?

 orchestrator-pseudo-gtid-dead-relay-master

We choose one of the children and drag it over onto the master, which is up and healthy:

orchestrator-pseudo-gtid-dead-relay-master-begin-drag

As you can see we are allowed (green instances are allowed drop places) to drop 22989 on its sibling and on its grandparent, the latter bypassing a broken connection. There is no connection between the two!

orchestrator-pseudo-gtid-dead-relay-master-drop

And we get a new topology:

orchestrator-pseudo-gtid-dead-relay-master-refactored-1

22989 is now lagging, but on the right path! Let's do the same for 22988:

orchestrator-pseudo-gtid-dead-relay-master-begin-drag-2

And finally:

orchestrator-pseudo-gtid-dead-relay-master-refactored-2

Great success! 22989 already caught up, 22988 on the way, victory is ours!

The real fun, of course, is to execute with --debug and review the DEBUG messages as orchestrator seeks, finds, matches and follows up on Pseudo GTID entries in the binary logs. We each have our pleasures.

27 אוקטובר, 2014 02:33 PM

Orchestrator 1.2.1 BETA: Pseudo GTID support, reconnect slaves even after master failure

orchestrator 1.2.1 BETA is released. This version supports Pseudo GTID, and provides one with powerful refactoring of one's replication topologies, even across failed instances.

orchestrator-pseudo-gtid-dead-relay-master-begin-drag

Depicted: moving a slave up the topology even though its local master is inaccessible

Enabling Pseudo-GTID

You will need to:

  1. Inject a periodic unique entry onto your binary logs
  2. Configure orchestrator to recognize said entry.

Pseudo GTID injection example

We will use the event scheduler (must be enabled) to inject an entry every 10 seconds, recognized both in statement-based and row-based replication.

create database if not exists meta;

drop event if exists meta.create_pseudo_gtid_view_event;

delimiter ;;
create event if not exists
  meta.create_pseudo_gtid_view_event
  on schedule every 10 second starts current_timestamp
  on completion preserve
  enable
  do
    begin
      set @pseudo_gtid := uuid();
      set @_create_statement := concat('create or replace view meta.pseudo_gtid_view as select \'', @pseudo_gtid, '\' as pseudo_gtid_unique_val from dual');
      PREPARE st FROM @_create_statement;
      EXECUTE st;
      DEALLOCATE PREPARE st;
    end
;;

delimiter ;

set global event_scheduler := 1;

Make sure to enable event_scheduler in your my.cnf config file.

An entry in the binary logs would look like this:

mysql [localhost] {msandbox} (meta) > show binlog events in 'mysql-bin.000002' LIMIT 2,1;
+------------------+-----+------------+-----------+-------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Log_name         | Pos | Event_type | Server_id | End_log_pos | Info                                                                                                                                                                                                               |
+------------------+-----+------------+-----------+-------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| mysql-bin.000002 | 388 | Query      |         1 |         669 | use `meta`; CREATE OR REPLACE ALGORITHM=UNDEFINED DEFINER=`msandbox`@`localhost` SQL SECURITY DEFINER VIEW `pseudo_gtid_view` AS select '2f6ad653-5db3-11e4-b91d-3c970ea31ea8' as pseudo_gtid_unique_val from dual |
+------------------+-----+------------+-----------+-------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+

The above entry will be unique, and orchestrator will be able to find it in the binary log if configured with:

{
    ...
    "PseudoGTIDPattern": "CREATE OR REPLACE .*? VIEW `pseudo_gtid_view` AS select"
}

The value of "PseudoGTIDPattern" is a regular expression which must match the Pseudo GTID entries in the binary log, and nothing but those entries.

Pre-release

This is BETA quality; though I have high confidence in its safety: the process of matching the binary log entries makes for a self-validating mechanism. The process will abort on any mismatch or uncertainty.

Still there can be use cases I haven't encountered yet. You input is appreciated!

27 אוקטובר, 2014 09:51 AM

24 אוקטובר, 2014

Oz Nahum

salt quick tip - changing passwords on multiple clusters

Using salt stack to manage your own private cloud on clusters can ease your life. Here is how you can allow users to update their passwords on multiple Linux hosts. ... continue reading...

24 אוקטובר, 2014 06:15 PM

Ilan Shavit

Docker – חלק ראשון

Docker הוא מוצר שכובש לאחרונה את סביבות השרתים ומערכות הענן השונות. אז מהו Docker ובמה הוא שונה מתחום ה- VM?

container_vs_vm

אסביר את האיור:

VM ‏ (Virtual Machine)

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

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

Docker:

נתבונן עכשיו בחלק הימני של השרטוט. השכבה התחתונה זהה ("הברזל"), בשכבה מעליה רצה מערכת ההפעלה שתריץ את שירות ה- Docker, מעליה מותקן מנוע לטיפול ב- "מיכלים" (Containers). שלוש שכבות אלו מהוות את תשתית המוצר.

בפתרון זה כל אפליקציה תרוץ במיכל יעודי משלה: יהיו שלושה מיכלים שיריצו כל אחד (באופן עצמאי ומבודד) בסיס נתונים, ועוד שלושה מיכלים שיריצו אפליקציות (כל אפליקציה במיכל מבודד משלה). בפתרון זה (להבדיל מפתרון הוירטואליזציה) אין צורך בהתקנה של מערכת הפעלה שלמה (על תקורותיה) בשביל להריץ בה את האפליקציה: יש מערכת הפעלה אחת (משותפת לכל המיכלים) קרנל אחד וכל אפליקציה תרוץ במיכל היעודי לה. חשוב להבין שהמיכלים עובדים מול הקרנל של מערכת ההפעלה הראשית של Docker. כלומר, גם אם אתה מריץ במיכל אחד Image של CentOS 6.5, במיכל שני Image של דביאן Wheezy, כל מיכל אכן יכיל ספריות usr/ ו- lib/ היעודיות למערכות הפעלה זאת, אך שניהם "יראו" את הקרנל של מוצר ה- Docker (נניח Ubuntu 14.04).

אז היתרון של Docker מובן: אתה "מתפטר" מ- 99.9% תקורה (זכרון, מעבד, דיסק ועוד…) הנובעים מהצורך להתקין ולהריץ מערכת הפעלה שלמה עבור האפליקציה שלך. בדיקות שונות העלו שעל אותה החומרה ניתן להתקין פי 4-6 אפליקציות מאשר יכולת להתקין בסביבת VM.

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

הדוגמא הבאה ממחישה את יכולות Docker: אתה יכול לטעון Image של מערכת הפעלה (המערכת תקבל IP בצורה אוטומטית), להריץ בה פקודה מסויימת, לאחריה לבצע Snapshot ל- Container ואז לסגור אותו, וכל זה בצורה אוטומטית לחלוטין!

באתר הבית של התוכנה סיכמו את יכולותיה כך: Build, Ship and Run Any App, Anywhere

docker_logo

הלוגו של Docker: הישומים מובלים במיכלים במהירות ובביטחה ליעדם

 

רעיון חדש וגאוני? לא כ"כ… המונח מיכל (Container) הוא מושג ותיק. כבר בשנת 2000 נעשה בו שימוש ב- FreeBSD. גם ב- Solaris המושג היה קיים ונקרא Zones, אבל הסטנדרטיזציה של ה- Containers, היכולת לבצע Snapshot, לחזור אחורה (לבטל פעולות שנעשו ב- Container) כל זה הופך את Docker למוצר מאוד מבטיח.

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

בחלק הבא: התנסות מעשית עם Docker

My Signature

24 אוקטובר, 2014 11:00 AM