יום ראשון, אוקטובר 19, 2014

תודה לידידינו ברדמונד על הודעות שגיאה

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

אני מכניס את הסיסמא ומקבל : "
Your pc is offline pls sign in with the last password used on this pc"
רק שהבעיה היא בשביל לחבר את המכשיר לאינטרנט אני צריך הגדיר את החייגן המקומי (HSDPA).
התקן הרשת היחידי שנתן DHCP שהיה ברשותי היה התקן שמתחבר ב USB, אבל לצערי windows נכשל בשימוש.

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

ניסיתי לנסות לעבור למשתמש אחר, אבל לא מצאתי שום דרך להחליף למשתמש מקומי (לא alt-ctrl-del  , לא בחירה באחד התפריטים כלום נאדה).

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

 

פיטצ'ר מגניב בfetchmail

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


לשם ההדגמה.

שרת הדוא"ל:mailserver.myrtfm.blogspot.com
כתובת פנימית:192.168.1.7
כתובת חיצונית:173.194.112.108
שם משתמש להזדהות: username

מתחברים לרשת האירגונית ומתחילים:
חיבור והזדהות ברשת הפנימית :
kinit username@MYRTFM.BLOGSPOT.COM


בדיקת הכתובת  של שרת הדוא"ל :
ping ping mailserver.myrtfm.blogspot.com
mailserver.myrtfm.blogspot.com  (192.168.1.7) 56(84) bytes of data.
64 bytes from mailserver.myrtfm.blogspot.com  (192.168.1.7): icmp_seq=1 ttl=50 time=87.8 ms


הפעלה של fetchmail -v בשביל לגרום להזדהות gssapi ע"י fetchmail.

בדיקת קיום התעודה החדשה:
klist
Ticket cache: FILE:/tmp/krb5cc_1000
Default principal: username@MYRTFM.BLOGSPOT.COM

Valid starting       Expires              Service principal
10/19/2014 10:44:31  10/19/2014 20:44:31  krbtgt/MYRTFM.BLOGSPOT.COM@MYRTFM.BLOGSPOT.COM
        renew until 10/20/2014 10:44:29
10/19/2014 10:48:04  10/19/2014 20:44:31  imap/mailserver.myrtfm.blogspot.com@MYRTFM.BLOGSPOT.COM
        renew until 10/20/2014 10:44:29
הפלת fetchmail.

יצאה מהרשת הפנימית.

בדיקת הכתובת החדשה של שרת הדואל
ping mailserver.myrtfm.blogspot.com 
PING mailserver.myrtfm.blogspot.com  (173.194.112.108) 56(84) bytes of data.
64 bytes from mailserver.myrtfm.blogspot.com  (173.194.112.108): icmp_seq=1 ttl=50 time=87.8 ms

הפעלה מחדש של fetchmail.

יום שבת, אוקטובר 18, 2014

העברת groupware

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

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

לשם הבדיקה לקחתי שרת  Exchange ובדקתי מה זה אומר בשבילי כלקוח כשיש מיגרציה כזו.
אני משתמש בKDE  .

יומן:


בגלל שאני משתשמש ביומן מקומי (לא סומך על ה"ענן") אין לי שום בעייה,

אנשי קשר:

יש לי מספר רשימות, הרשימות מהשרתים תמיד מגובה.

דוא"ל:

פה גיליתי שנושא תיבת הדואר לא יעבור חלק , את זה רואים  בתוך תוכנת הדואל של  KDE

 
    if (messageCount == 0) {
        //Shortcut:
        //If no messages are present on the server, clear local cash and finish
        m_incremental = false;
        if (realMessageCount > 0) {
            kDebug( 5327 ) << "No messages present so we are done, deleting local messages.";
            itemsRetrieved(Akonadi::Item::List());
        } else {
            kDebug( 5327 ) << "No messages present so we are done";
        }
        taskComplete();

משמעות הפעולה   itemsRetrieved(Akonadi::Item::List()); היא שכל המידע השמור מקומית עבור התיבה יאופס(כל המיילים ימחקו).

התחלתי לחפש פתרון לביצוע גיבוי/העלאה ועצרתי על שימוש ב fetchmail.

לצערי fetchmail נכשל בהזדהות NTLM אבל השרת תומך בGSSAPI ולאחר ביצוע kinit הצלחתי לעבוד מול השרת.

את fetchmail הגדרתי בתוך ~/.fetchmailrc:

poll mailserver.myrtfm.blogspot.com 
protocol IMAP 
port 143
username "username@myrtfm.blogspot.com " 
password "secretpassword" 
is "boris" 
mda "/usr/bin/procmail -d %T"
mimedecode
keep

את procmail הגדרתי כך ~/procmailrc.:
SHELL=/bin/bash
PATH=/usr/sbin:/usr/bin
MAILDIR=$HOME/MailDir/
DEFAULT=$MAILDIR
LOGFILE=$HOME/.procmail.log
LOG=""
VERBOSE=yes

:0:
*^To:.*\@myrtfm.blogspot.com
$MAILDIR/.myrtfm.blogspot.com/

אני מקווה שלא עשיתי שום טעות בהגדרות אבל נראה שהמיילים יורדים, לאט לאט

יום שישי, אוקטובר 17, 2014

systemd הולך לעוף ?

בסלאדשוט דיווחו שבדביאן בוחנים בוחנים מחדש את systemd.

הופתעתי לטובה שבדביאן systemd עדיין לא הדביק יותר מדי חבילות לא קשורות (החבילות שפה יחסית קשורות למערכת).


apt-cache rdepends systemd | grep -vvv systemd
Reverse Depends:
  tuxonice-userui:i386
  udev:i386
  tuxonice-userui
  udev
  solaar
  sogo
  pcscd
 |mate-power-manager
  lighttpd
  libvirt-daemon-system
 |libguestfs0
  init-system-helpers
  gummiboot

יום ראשון, אוקטובר 12, 2014

SEARCH fail on Exchange (NO Server Unavailable. 15)

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

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


From 7189cf7664e354402e5093bba9e623d4fd4670ad Mon Sep 17 00:00:00 2001
From: me 
Date: Mon, 13 Oct 2014 11:22:23 +0300
Subject: [PATCH] [IMAP resource] Split large UID Search commands to multiple
 smaller ones

On exchange 2007 a long request may trigger "NO Server Unavailable. 15", when splitting to lower amount the error is avoided
---
 resources/imap/batchfetcher.cpp | 37 +++++++++++++++++++++++++++++++------
 1 file changed, 31 insertions(+), 6 deletions(-)

diff --git a/resources/imap/batchfetcher.cpp b/resources/imap/batchfetcher.cpp
index 7419bbd..200521a 100644
--- a/resources/imap/batchfetcher.cpp
+++ b/resources/imap/batchfetcher.cpp
@@ -63,12 +63,37 @@ void BatchFetcher::setGmailExtensionsEnabled(bool enable)
 void BatchFetcher::start()
 {
     if (!m_searchTerm.isNull()) {
-        //Resolve the uid to sequence numbers
-        KIMAP::SearchJob *search = new KIMAP::SearchJob(m_session);
-        search->setUidBased(true);
-        search->setTerm(m_searchTerm);
-        connect(search, &KIMAP::SearchJob::result, this, &BatchFetcher::onUidSearchDone);
-        search->start();
+        //I take the idea of using 2K chunks from 6cc5af5b150628a250e67, it solve Exchange disconnecting on too long SearchJob
+        const qint64 maxAmountOfUidToSearchInOneTime = 2000;
+        KIMAP::ImapSet workingSet=KIMAP::ImapSet(m_currentSet);//not passing to Q_FOREACH as it may be modified 
+        Q_FOREACH (const KIMAP::ImapInterval &interval, workingSet.intervals()) {
+            //in case we are dealing with a single bellow threshold interval or end is undefined we fallback to old code
+            if ((! interval.hasDefinedEnd()) || (maxAmountOfUidToSearchInOneTime >  interval.size())) {
+                qCDebug(RESOURCE_IMAP_LOG) << " Search on all elements in one attempt " ;
+                KIMAP::SearchJob * search = new KIMAP::SearchJob(m_session);
+                search->setUidBased(true);
+                search->setTerm(m_searchTerm);
+                connect(search, SIGNAL(result(KJob*)), this, SLOT(onUidSearchDone(KJob*)));
+                search->start();
+            } else {
+               qCDebug(RESOURCE_IMAP_LOG) << "Interval has # " << interval.size() << " elements, will try to search using multiple search sessions";
+               //this is purly for exchange 2007 that get disconnected on too long SearchJob, brake the SearchJob to 2K pieces each one will trigger smaller fetches 
+               qint64 firstUidToSearch = interval.begin();
+               qint64 lastUidToSearch  = qMin ( firstUidToSearch + maxAmountOfUidToSearchInOneTime, interval.end());
+
+               while (firstUidToSearch < interval.end()) {
+                 lastUidToSearch  = qMin ( firstUidToSearch + maxAmountOfUidToSearchInOneTime, interval.end());
+
+                 KIMAP::SearchJob *search = new KIMAP::SearchJob(m_session);
+                 search->setUidBased(true);
+                 search->setTerm(KIMAP::Term(KIMAP::Term::Uid, KIMAP::ImapSet(firstUidToSearch,lastUidToSearch)));
+                 connect(search, SIGNAL(result(KJob*)), this, SLOT(onUidSearchDone(KJob*)));
+                 search->start();
+ 
+                 firstUidToSearch = lastUidToSearch + 1;
+               }
+            }
+        }
     } else {
         fetchNextBatch();
     }
-- 
2.1.0

למה לקויי ?  יש הרבה קוד מועתק וזה נראה מכוער.

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

לצערי גם אני חוטף את הניתוק המעצבן (יכול להיות הבאג הזה)

akonadi_imap_resource_15(16371)/kdepimlibs (kimap) KIMAP::LoginJob::~LoginJob: KIMAP::LoginJob(0xd20d20)
akonadi_imap_resource_15(16371)/kdepimlibs (kimap) BatchFetcher::fetchNextBatch: Fetching  39  intervals
akonadi_imap_resource_15(16371)/kdepimlibs (kimap) BatchFetcher::fetchNextBatch: Fetching  27  intervals
akonadi_imap_resource_15(16371)/kdepimlibs (kimap) BatchFetcher::fetchNextBatch: Fetching  39  intervals
akonadi_imap_resource_15(16371)/kdepimlibs (kimap) BatchFetcher::fetchNextBatch: Fetching  36  intervals
akonadi_imap_resource_15(16371)/kdepimlibs (kimap) BatchFetcher::fetchNextBatch: Fetching  35  intervals
akonadi_imap_resource_15(16371)/kdepimlibs (kimap) BatchFetcher::fetchNextBatch: Fetching  23  intervals
akonadi_imap_resource_15(16371)/kdepimlibs (kimap) KIMAP::SessionPrivate::onSocketTimeout: Socket timeout!
The stream parser raised an exception: Unable to read more data 
akonadi_imap_resource_15(16371)/kdepimlibs (kimap) KIMAP::SessionThread::doCloseSocket: close
akonadi_imap_resource_15(16371)/kdepimlibs (kimap) KIMAP::SessionThread::doCloseSocket: close
akonadi_imap_resource_15(16371) BatchFetcher::onHeadersFetchDone: Fetch job failed  "Connection to server lost." 
akonadi_imap_resource_15(16371) RetrieveItemsTask::onRetrievalDone: "" 
akonadi_imap_resource_15(16371)/kdepimlibs (kimap) KIMAP::LoginJob::Logi

אבל זה עדיין מושך , לאט בקפיצות של 100 עם ניתוקים. 

עריכה : זה רק עשה קולות של עובד, זה לא באמת פותר את הבעיה.

יום שישי, אוקטובר 10, 2014

עד כמה אתה סומך על מערכת ההפעלה שלך ?

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

אם נסתכל על שולחן העבודה הסמנטי רעיון שנראה תמים ומועיל בהתחלה שהביא לנו את nepomunk ו Zeitgest (שני כלים שיכלת פשוט לא להתקין (או לחסום) ), שהם פרצת פרטיות לדעתי בפני עצמם אבל ניתן היה לברוח מזה. אולם אחר שינוי מסויים ב KMail ביצוע חסימה/הסרה היה שובר את היכולת לחפש בתוך מיילים ומקשה את החיים עם PIM.

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

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

לאחר שnepomunk נרצח, קם לו יורש חדש בשם baloo שכברירת מחדל תייג כמה שיותר ומאנדקס כמה שאפשר (ואם רוצים לבטל את ה,תיוג והאינדוקס צריך לערוך את ~/.kde4/share/config/baloo-filerc ולהוסיף Indexing- Enabled=false בשביל למנוע אינדוקס של המערכת, מידע נוסף).

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

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

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

זה נראה שמבחינת הפרטיות בשבילי לא יהיה הרבה הבדל בין אנדרויד win10 ו KDE.

עריכה : הדמיון שאני רואה בהפרת הפרטיות היא שמותקנות תוכנות שלומדות את אופן השימוש במערכת ללא ידעתי (משהוא בchangelog לדעתי כמו משהוא ב EULA), והסרה של פיטצר הלימוד פוגעת בשימושיות המערכת.

אז עד כמה אתה באמת סומך על מערכת ההפעלה שלך ?