Tag: Internet

newsletters that I value

Let’s break this blog’s hiatus with an uninteresting post.

I am still a heavy email user. I am subscribed to more mailing lists and newsletters than most can handle, and even I, after almost 30 years of email usage, am feeling INBOX fatigue. I unsubscribe and delete unread mail without remorse. However there are a handful of newsletters that I think I am going to keep around for as long as they are around. These are:

  • Fermat’s Library. I won’t claim that I understand either every paper, or commentary on paper of the week. But I get interesting, yet never pursued, ideas sometimes.
  • The morning paper. More CS centric and also I won’t claim to always grasp the subject (or even like it). But still, good things to consider here.
  • Quanta magazine. Science concepts delivered in a way they can be understood.
  • The porcupine newsletter. Because if I had time, I’d want to post a newsletter and follow its style.

So what are yours?

 

Sometimes n2n is good enough

You are not always in a position to use one of the big five cloud providers (BTW, I think Watson’s prediction was kind of true; serverless is making sure of that).

So when you’re working in different than usual public cloud environments, sometimes you miss features that are a given, like a VPC. A VPC is a pretty cool abstraction that allows you to have an isolated network of machines (and sometimes services) within your cloud provider and allows for easier management of things like security groups, routing traffic between machines and the like.

So what do you do when you do not have a VPC available? You need some kind of overlay networking. When deploying Kubernetes for example, you need to deploy an overlay network (there are many solutions to choose from) and you let it deal with iptables and routing hell. But, you may need to temporarily scale services that are not container orchestrated for whatever the reason (I, for example abhor running databases with Kubernetes). Still you may need an autoscaling solution like EC2 does. IPSec would be a cool solution, but deploying it in my current workplace would be too complex. Something simpler was needed. And I found it here, despite the shortcomings reported: N2N from ntop.org.

N2N was in a development hiatus, but now is back on active development. It utilizes TUN/TAP and allows you to build a VPC over the interface that the client you run on your machine creates. It comprises of two components: a supernode, which is actually a directory server that informs the members of the (let’s call it) VPC of the actual IP addresses of the members, and a client program (called edge) that creates the interface on each VM and contacts the supernode to register with it and query for needed routing information. The supernode itself is not routing any packets. It was a single point of failure, but current versions of N2N/edge support two supernodes, so your network is in a better position.

In my case I needed to autoscale a certain service for a limited amount of time, but did not have any prior knowledge of the IP addresses of the VMs that were to be created. So I had them spun off using an image that was starting edge, registering to the supernode and then routing a certain kind of traffic through a node that was also registered in the same network and acting as a NAT server. Hence, I simplified some of the iptables hell that I was dealing with until we deploy a better solution.

N2N supports encrypted traffic, and requires the equivalent of a username / password combination (common to all machines that are members of the VPC, but not known to supernode apriori).

So where else might you want to use N2N? Maybe you need a common IP address space between two cloud providers? You may be in a cloud provider that allows for VPCs but does not make it easy to route traffic from a VPC in one region to a VPC in another region? Or in cases when solutions like DMVPN are expensive and your own BGP solution an overkill? Stuff like that.

So how do the machines acquire an address in that VPC? You have two choices (a) DHCP and if that is not working (b) a static address. In the second case with you need to implement a poor man’s DHCP by having the machine assign an IP address to itself with a low probability of collision. To this end, let’s assign a /16 to that VPC and have the following entry in /etc/rc.local (yes I am still a fun of rc.local for limited usage) like:

edge -l supernode:port -c community-string -k password-string -s 255.255.0.0 -a static:172.31.$(shuf -i 1-251 -n 1).$(shuf -i 1-251 -n 1).

The probability of a collision is (1/63001) so you get to decide at how many temporary instances you need to have a better hack at that. Plus you get to use 172.31.1.0-255 for static machinery within the VPC (like a NAT gateway for example).

Not a perfect solution, but definitely an easy, fast one.

“Worry if the new generation is less familiar with technology internals than we were”

I’ve posted this in 2014, but a friend’s comment on facebook makes me want to repost this:

“I think we’ve had a reduction from, say, if you think about 1995, which was when I went to college, you could typically rely on an undergraduate having done a substantial amount of real programming, often quite a deep level of technical work on one or more platforms. Many of us could program in one or more assembly languages. And yeah, within 10 years of that point, we were getting to a point where your average applicant was maybe somebody who’d done, as you say, a little bit of Web design, maybe a little bit of Web programming—you know, we saw quite a bit of people who‘d maybe done some PHP but not that kind of deep technical understanding of how machines work.”

This was from an Eben Upton interview. So much progress has happened that people entering the profession do so with a distance from the hardware.

twitter at 280

With twitter experimenting with 280 characters per tweet, I was reminded of something that I had read years ago (and as a result cannot locate and attribute now). It went something like this:

The main advantage with twitter is that it battles attention starvation. We’re bombarded with information all the time. But our time to focus on things is limited. By enforcing a small limit, twitter makes it possible to focus on what to transmit and what to receive in the small chunks of time available to consume what runs through the webs.

Besides the term attention starvation the reconstruction of the thesis is all mine.

Update: Dimitris argues that this works in favor of the alt-right.

A bit of ngrok to share files

I needed to share some big files with a friend / colleague who lives some hours away. Couriers were not available at this time and I felt a bit “command line happy”, so with

python -mSimpleHTTPServer

I started a web server at the directory where the files were generated. I did not feel like playing around with NAT and port forwarding, so I turned to ngrok (still faster than running localtunnel):

ngrok http –region eu 8000

Done. Ain’t this the security manager’s nightmare, or what?

Now I need to find time for my own version of localtunnel (because NIH).

Ηλεκτρονικές Εκλογές ΤΕΕ – part 2

[ Αυτό το κείμενο γράφτηκε λίγο μετά την 2006/11/26 μετά από τις πρώτες εκλογές στο ΤΕΕ με ηλεκτρονική υποβοήθηση. Δεν είχα πατήσει ποτέ το publish ως σήμερα, αλλά το σημερινό φιάσκο της ΝΔ, η χρονική απόσταση και το γεγονός πως δεν είμαι στο ΤΕΕ μου δίνουν μια ευχέρεια να το κάνω. Για όποιον ενδιαφέρεται, δεν είχα κεντρικό ρόλο στο έργο. Η ημερομηνία των εκλογών συνέπιπτε με την άφιξη του πρώτου πελαργού. ]

Ιστορία γράψαμε μια και η καταμέτρηση έγινε ηλεκτρονικά και είναι η πρώτη που έγινε στη χώρα και σε τέτοια κλίμακα. Ίσως δεν είναι τόσο πετυχημένη στα μάτια πολλών (σε καμία περίπτωση δεν ανταποκρίνεται στις προσδοκίες μου), δεν παύει όμως να είναι μια δύσκολη και heroic system administration story για εμάς που ήμασταν μέσα σε αυτή. Τα προβλήματα πάρα πολλά. Αυτό το κείμενο δεν καταπιάνεται με κανένα από τα προβλήματα που δεν άπτονται της ηλεκτρονικής διαδικασίας (π.χ. πολιτική ανάλυση των εκλογών του ΤΕΕ, ενστάσεις κ.λπ.) παρά μόνο με τα προβλήματα που διαπιστώσαμε κατά την ηλεκτρονική διαδικασία και όπως την έζησα από το γραφείο μου:

  1. Το task ήταν τιτάνιο για το μέγεθος του υποστηρικτικού μηχανισμού. Τα εκλογικά τμήματα είναι 159. Αυτό σημαίνει άμεση διαχείριση 2×159 ανθρώπων, συν τους τεχνικούς που είχε stand-by ο προμηθευτής του εξοπλισμού. Όλοι αυτοί οι άνθρωποι ήταν διαφόρων επιπέδων τεχνικών ικανοτήτων και διάθεσης.  ~318 βαθμοί ελευθερίας.
  2. Υπήρχαν διαθέσιμα 180 PC. Όλα ίδια και όλα φτιαγμένα με την ίδια μήτρα. Θα περίμενε κανείς πως θα είχαν και κοινή συμπεριφορά. Αμ δε! Οι drivers των scanners σε μερικά εκλογικά κέντρα χάνονταν ανεξήγητα κατά τη διαδικασία και έπρεπε να γίνει επανεκκίνηση.
  3. Για να παίζουν κάποια PC έπρεπε α) να αλλάξει PCI port το PSTN modem ή β) να αφαιρεθεί πλήρως. Διαφορετικά, BSOD.
  4. Παρόλο που όλα έγιναν install με το ίδιο image, μερικά ξεκίναγαν με αυθαίρετα settings για το firewall.
  5. Το OpenVPN για να παίξει εγκαθιστά ένα virtual Ethernet driver. Επίσης ανεξήγητα σε μερικά PC αυτός ήταν disabled (ενώ στις δοκιμές της προηγούμενης μέρας έπαιξε κανονικά!). Έπρεπε να γίνει enable με το χέρι.
  6. Και το τελειωτικό: Ενώ δεν υπήρχε κανένα φαινομενικό πρόβλημα με το OpenVPN, δεν είχαμε σύνδεση. Ούτε με reboot. Μετά από shutdown όμως είχαμε.
  7. Όσο συμπαγές και μικρό να είναι το documentation δεν θα το διαβάσουν όλοι.
  8. Ακόμα κι αν υπάρχει ένα δηλωμένο τηλέφωνο επικοινωνίας, όλη η Ελλάδα θα ανακαλύψει το δικό μου.
  9. Το χειρότερο από όλα: Εκτός από ερωτήσεις για την ηλεκτρονική διαδικασία μας γίνονταν και ερωτήσεις επί της εκλογικής διαδικασίας. Φανταστείτε λοιπόν κάποιον που ρωτάει τρία πράγματα μαζί και πρέπει να του πεις “Ξέρετε, αυτά είναι θέματα της Κεντρικής Εφορευτικής, πρέπει να μιλήσετε εκει”. Χαρά ε; Ειδικά αν για να λυθούν αυτά πρέπει να κάνει τρία (3) τηλέφωνα και όχι ένα.

Δεν υπολογίζω στα παραπάνω τραβήγματα καλωδίων ή άλλους λάθος χειρισμούς, γιατί είναι αναμενόμενοι. Ακόμα και αυτά όμως ήταν αρκετά για να υπερχειλίσει το τηλεφωνικό μας κέντρο (είναι ώρα για το asterisk πια) τις πρώτες ώρες και πριν ακόμα ξεκινήσουν τα scannαρίσματα όπου:

  1. Ο DBA μας έδωσε ρεσιτάλ restore (μερικά over PSTN, άρα όχι τόσο άνετα). Είδαμε database errors που δεν είχαμε ξανασυναντήσει ποτέ. Το επόμενο βήμα είναι να κάνουμε forensic restores.
  2. Είδαμε απίστευτα κολλήματα στο scan. Δεν τα είδαμε στο software development, δεν φάνηκαν στις εκπαιδεύσεις, δεν φάνηκαν καν στο test-event και ήταν οι ίδιοι άνθρωποι (και ναι ξέρουμε να στήνουμε σενάρια) που τα έτρεξαν όλα.
  3. Αποκρυπτογράφηση του ίδιου προβλήματος με 30 διαφορετικές περιγραφές (π.χ. σε εμένα πρόβλημα στον scanner έφτανε ώς πρόβλημα σύνδεσης στο δίκτυο) σε 5 διαφορετικούς ανθρώπους.

Θα πάρω όλη την υπόλοιπη κανονική μου άδεια και θα αφοσιωθώ στον παιχταρά μου (== adamo version 2.0).

(part1)

quidquid latine dictum sit altum videtur

Δεν μπορούσα παρά να θυμηθώ την παραπάνω φράση όταν είδα τον Υπουργό Πολιτισμού να απαντά σε χρήστη στο twitter:

.@kyr_ath Wovon man nicht sprechen kann, darüber muss man schweigen (Ludwig Josef Johann Wittgenstein)

Όποιος ενδιαφέρεται για την φράση, μπορεί να ξεκινήσει από εδώ. Όποιος ενδιαφέρεται για το βιβλίο μπορεί να ξεκινήσει από εδώ. Υποψιάζομαι πως η σχέση αναφορών στις δύο διασημότερες φράσεις του βιβλίου προς τις αναγνώσεις του είναι χαώδης.

Zawinski’s Law revisited

“Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can.” —Zawinski‘s Law

I shared something with a good friend of mine at Evernote, which made us observe that this makes the Evernote platform yet another Inbox for us to check for messages daily. We got the observation a little further and one could say that:

Every software as a service platform expands until it can support messaging among its users.

Instant or not so instant does not matter that much. But it seems to me that those who do not, do get replaced by competitors who support it.

How legacy systems die

The news server that a friend was maintaining had stopped responding for a while. Leafnode complained with:

warning: HOSTNAME: cannot resolve host name: Name or service not known

So I emailed my friend and asked. It seems that the hardware of HOSTNAME had failed, and that after a month or so I was the only person who wondered about its fate. No plans to put it back online exist.

And with that I realized that the USENET is now dead for me.