יום שני, דצמבר 01, 2014

ISP is blocking port forwarding

הסאגה שלי עם ספק האינטרנט 
אני : שלום אני מנוי שלכם לפני מספר חודשים שידרגתי ל  XX מסל"ש ומזה זמן מה אני רואה שport forwarding לא עובד.
ISP: השירות שרכשת אינו כולל אפשרות לביצוע port forwarding עליך לשלם תוספת תשלום של 35% למחיר החבילה שאתה משלם עבור השירות הזה.
אני: אבל לפני השדרוג ששילמתי פחות היתה לי אפשרות לביצוע pf/
ISP: זו היתה חבילה אחרת.
מספר דברים העציבו אותי בשיחה הזאת :

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

עובר לו חודש ועוד מספר ימים, אני מנצל את ממשק הניהול בשביל להחליף לחבילה ה"מקצועית" מנוי פרטי באינטרנט XX Mb - מקצועי.
מנסה שוב , ונאדה. אני מתקשר לתמיכה הטכנית בה נאמר לי שאני מקבל כתובת מאחורי NAT (כאשר הכתובת אינה נמצאת ב rfc 1918) - אני יודע שיש מחסור בכתובת ipv4 אבל זה כבר מפחיד כי קיימת האפשרות שאני באמת משתף את הכתובת וכל פעם שאישרתי בנתב חיבור מהכתובת הזאת פתחתי פתח לצרות (גילוי נאות חיבור לשרת בדר"כ מתבצע ע"גipsec  /openvpn מרשימת כתובת מותרת).

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

בתקופה זו ניסיתי את מספר פתרונות חלופיים -

עבודה עם  pwnat נכשלה (מה שאומר שדברים מבוססי ICMP גם יכולים להפסיק לעבוד) , שזה די עצוב כי זה הפתרון שאמור להציל כשיש צורך ב p2p מאחורי NAT וזה נכשל כישלון חרוץ.

revese tunnel ב ssh עובד ללא שום בעיה.

openvpn עובד ללא שום בעיה (דורש הגדרה מיוחדת בשביל לחבר רשת מאחורי לקוח לרשת בצד השרת).

עריכה: שאלו אותי בשביל מה כבר צריך p/f מופעל בבית - יש לי ownclowd שעובד מצויין ונותן לי פתרון שקוף לכל הכלים שאני צריך.


אז אם פתאום ה p/f  הפסיק  לעבוד , לא בטוח שזה באג שלכם יכול להיות שזה ספק מאוד נחמד...

יום רביעי, נובמבר 12, 2014

GNOME מגייסת כוחות בשביל להלחם

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


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

עריכה: יש טענה כי התאגיד החליט לחוס על GNOME
"Update: Thank you for all the support that you have given us. Groupon has confirmed with the GNOME Foundation that they are going to abandon all of their 28 pending trademark applications and will proceed with a name change for their product. We could not have done this without your help!" -- http://www.gnome.org/groupon/

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

לדעתי  כל הסיפור הזה הזוי -

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

איך  הרשם בכלל קיבל את הבקשה לרשום את השם ?



יום ראשון, אוקטובר 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