Y2K+10

Πέρασαν 10 χρόνια και σχεδόν το έχουμε ξεχάσει. 10 χρόνια πριν κόσμος και κοσμάκης έκανε πρωτοχρονιά στα terminal room ή on-call (π.χ. ο Δημήτρης) περιμένοντας αν θα “πέσουν” τα συστήματα ή όχι.

Η (κατά τα ΜΜΕ) καταστροφή του κόσμου δεν ήρθε. Όχι γιατί δεν υπήρχε πρόβλημα, αλλά γιατί πολύς κόσμος (και για πολλά χρήματα) δούλεψε για αυτό: Το απόλυτο deadline.

Ελπίζω τουλάχιστον τόσο τα προβλήματα που σχετίζονταν με το Y2K, όσο και τα μέσα αντιμετώπισής του να έχουν “μπει” στην εκπαιδευτική διαδικασία. Να κάνουν λάθη και οι επόμενες γενιές, αλλά όχι τα ίδια.

Καλή Χρονιά σε όλους.

RSS feeds

Με μια μικρή καθυστέρηση (σε σχέση με το πότε είχα υποσχεθεί) μια σταχυολόγηση από τα RSS feeds που παρακολουθώ. Δίνω τα blog URLs και όχι τα feeds:

Μερικές παρατηρήσεις: Η παραπάνω λίστα δεν είναι πλήρης. Λείπουν τα ελληνικά blog (π.χ. το πλέον προφανές). Δεν υπάρχουν blog εξαιρετικών sysadmins όπως π.χ. του Σωτήρη και του Άγγελου. Φίλων για πάνω από 15 χρόνια: past, chstath, dsin, ktroulos. Το κεραμίδι :) Τα blog των κουμπάρων μου: Δημήτρης, Χρήστος, UrBaN και Ποντικός.

Το εύκολο θα ήταν να “σηκώσω” το αρχείο OPML. Αλλά με την ευκαιρία έριξα και ένα μικρό συγίρισμα.

mailing lists

“Τι λες για ένα post με θέμα τι mailing lists, και rss feeds παρακολουθείς; :)”

Πρότεινε πριν κάτι εβδομάδες ένας φίλος. Οι mailing lists δεν είναι και πολλές:

  • Interesting People. Η λίστα που τρέχει ο David Farber. Ενδιαφέρουσες συζητήσεις που αφορούν το Δίκτυο σε τεχνικό και πολιτικό επίπεδο, όπως και την ιστορία του. Σχεδόν όλοι όσοι “έγραψαν” διαδικτυακή ιστορία συμμετέχουν σε αυτή.
  • sage-members. Η λίστα που τρέχει το SAGE group του USENIX. Εάν είσαι system administrator, επιβάλλεται να είσαι γραμμένος στο SAGE (και κατ’επέκταση και στη λίστα). Πραγματική πηγή γνώσης και επίλυσης αποριών.
  • SOCNET. Mailing list για social networks. Το βασικό forum της INSNA.

Με μικρότερη συχνότητα:

  • cisca-l. Για αυτούς που ενδιαφέρονται για πράγματα όπως το CISA certification και τις αντίστοιχες περιοχές της ασφάλειας των Πληροφοριακών Συστημάτων.
  • cryptography. Για τους νοσταλγούς των cypherpunks.
  • securitymetrics. ” Πως μπορώ να μετρήσω την ασφάλεια;” Αυτό το αφηρημένο ερώτημα που μπορεί να κάνει ο “από πάνω” ή ο πελάτης και που δεν μπορεί να απαντηθεί “με ζυγαριά”.
  • imap-protocol. Οτιδήποτε σχετικό με το πρωτόκολλο IMAP.
  • imap-use. Ότι δε χωράει από πάνω και από κάτω :)
  • imap-uw. Ότι αφορά το UW-IMAP toolkit.
  • anti-spam-wg / anti-abuse-wg. Το anti-spam-wg μετασχηματίστηκε στο anti-abuse-wg ώστε να είναι ένα forum συζήτησης και για άλλου τύπου online abuse και όχι μόνο (email) spam.
  • dns-wg. Για οποιοδήποτε ερώτημα σχετικά με το DNS μέσα στο RIPE community.
  • ipv6-wg. Θέματα IPv6, όπως υλοποίηση, routing και migration.

Δύο newsgroups που παρακολουθούσα, αλλά τώρα επισκέπτομαι μόνο περιστασιακά:

Εχω γραφτεί και σε αρκετά groups στο LinkedIn, αλλά δε μπορώ να πω πως τα παρακολουθώ.

Ξεχνάω μερικά; Μπορεί. Όποιος έχει κέφι ας προσθέσει στα σχόλια.

(Τα RSS feeds αύριο αργότερα)

3/3

Αυτό που έχει περισσότερη σημασία είναι πως η Super League για τρίτη συνεχόμενη χρονιά έχει ομάδα στους 16.

(ref)

Πυροσβεστικό Μουσείο

Μια και ο Θ. δείχνει ένα ιδιαίτερο ενδιαφέρον για τα “πυροσβεστικά” σήμερα πήγαμε οικογενειακώς στο Πυροσβεστικό Μουσείο. Επειδή είμασταν και οι μοναδικοί επισκέπτες εκείνη την ώρα, είχαμε την τύχη να έχουμε πλήρη ξενάγηση από τον πυροσβέστη που είχε βάρδια στο μουσείο εκείνη την ώρα.

Το μουσείο είναι εντυπωσιακό, ειδικά εάν σκεφτεί κανείς πως προσπαθεί να καλύψει το έργο της Πυροσβεστικής από την ίδρυση του Ελληνικού Κράτους μέχρι και σήμερα. Έχει οχήματα και εξοπλισμό πριν από το 1900, μερικά μάλλιστα είναι πιστοποιημένο ακόμα και σε ποιες φωτιές έχουν χρησιμοποιηθεί. Επειδή ο Θ. έδειξε μεγαλύτερο ενδιαφέρον για τον πιο σύγχρονο (και οικείο σε αυτόν) εξοπλισμό, θα πρέπει να ξαναπάμε, γιατί υπάρχουν αντλίες και άλλοι μηχανισμοί που αξίζουν περισσότερης προσοχής.

Το Πυροσβεστικό Μουσείο είναι ανοιχτό για το κοινό Τετάρτη και Κυριακή, οπότε καλό είναι να κάνετε ένα τηλέφωνο πριν πάτε.

weird dns problems are routing problems

This is a story we dealt with some months ago. After a major upgrade of the pipes that connect us with one of our upstreams (lets call them O) our support lines started getting complaints that certain sites could not be reached (RapidShare was a notable example). At first this was thought to be a temporary routing problem, but as calls started to amass within the hour, we looked further into it.

Since we already had a list of sites that were not reachable, we used the first tool one uses at such situations: traceroute. What I immediately observed was that prior to failing, traceroute took sometime to execute. Could it be that the DNS servers and not the web sites were not reachable?

Since we run a separate setup that forwards queries to OpenDNS, I used that DNS server, and traceroute worked! So it indeed was a routing problem, only it was not a routing problem to the web site itself, rather to its name servers who were unreachable by our DNS servers. Tracerouting by hand to the IP addresses of the DNS servers of the “problematic” domains verified that. Luckily we could reach OpenDNS, who in turn could reach (and cached) the DNS servers we could not.

While in fact a very small part of the Internet was not reachable at the time, due to the fact that lots of DNS servers serving other domains lived there, a significantly larger part of the web was invisible. Such issues do occur when your DNS and your hosting provider are networks appart.

We opened a ticket with O and tried to resolve the situation. It seemed that the problem was a case of asymmetric routing, since answers to our packets were returning via our other upstream (lets call them F). The weirdness of describing the problem confused at first the routing engineers at F who could not believe that we were using DNS servers that were not forwarding to theirs. Luckily their DNS master is a good friend and helped get past that quickly. They (F) located the problem to the configuration of one of their upstreams (lets call them L). They opened a ticket and we all waited. In the mean time they (F) devised a backup plan, in case L did not want to cooperate. But they did.

So when you think (or are told) that a web site is unreachable, always check whether its DNS servers are reachable first.