Programa y datos

Primero que nada necesitamos instalar GPredict, el programa que hace todo esto. Se puede bajar desde el sitio oficial: http://gpredict.oz9aec.net/

Para quienes estén en Ubuntu, pueden instalarlo desde los repositorios:

sudo apt install gpredict

Lo abrimos y por primera vez vamos a ver un dashboard un poco diferente al que mostré, con datos de satélites y la estación espacial internacional. Vamos a decirle que se baje datos actualizados, así las órbitas que vemos tienen menos error: vamos al menú "Edit" > "Update TLE" > "From network". Eso nos va a mostrar una ventana con el progreso de la actualización, solamente tenemos que esperar a que termine (unos segundos) y luego cerrar la ventana.

Configurar qué queremos ver

Ahora solo tenemos que decirle al programa dos cosas: qué queremos ver, y dónde estamos.

Vamos al menú "File" > "New module", lo que nos va a mostrar una ventana como esta:

Rellenamos:

• "Module Name": nombre de nuestro dashboard.

• "Selected Satellites": los satélites que queremos ver, que agregamos haciendo doble click en la lista de la izquierda ("Available Satellites"). Por suerte permite buscar :) Los satélites argentinos actuales son los CUBEBUG, NUSAT y ARSAT (hay varios de cada tipo, NUSAT-3 por ejemplo es el Milanesat de Satellogic!).

Guardamos, y terminamos con algo como esta imagen:

Todavía no se ve muy lindo, y falta nuestra posición. Pero ya podemos ver la posición actual de los satélites que nos interesaban!

Agreguemos nuestra posición. Para ello hay que editar el módulo (dashboard), lo hacemos desplegando el menú que se abre con este botón (arriba a la derecha, en la esquina del mapa) y eligiendo la opción "Configure":

En la ventana que se nos abre (que es la misma que cuando creamos el dashboard), hacemos click en el botón con un signo "+" que está al lado de "Ground Station". Ello nos abre una ventana donde rellenar nuestra posición:

Lo importante a rellenar es "Name", "Latitude" y "Longitude" (datos que podemos obtener con el gps del celular, usando aplicaciones como esta). "Altitud" también es útil, pero no super importante.

Guardamos la ubicación, y ahora en la misma pantalla de edición del dashboard, vamos a hacer un último paso para que se vea un poco más lindo (al menos a mi gusto, jeje). Hacemos click en el botón "Properties". Esto nos despliega una ventana, en la que solo nos interesa cambiar el valor de "Select layout":

Elegimos "Map, table, polar and single sat (wide)". Guardamos todo, y listo! Ya tenemos nuestro super dashboard satelital :)

Podés dejar de leer en este punto, o si te interesa saber un poco más, debajo explico qué son las cosas más importantes que se ven en el dashboard.

Qué estamos viendo en el mapa?

En el mapa se ven las posiciones de los satélites, y el área de la tierra que ellos "cubren". Imaginate una pelota muy grande (o un planeta, jeje): si estás muy cerca ves poco, pero si te alejás, ves mucho más. Cuánto ves? Ves una zona de la pelota que tiene forma de círculo. Un radio de X distancia alrededor tuyo.

Con los sates pasa esto mismo: si están muy cerca de la tierra (como los NUSAT), ven menos de ella al mismo tiempo. Si están más lejos (como los ARSAT), ven más. Dependiendo de qué función tenga el satélite, conviene estar más lejos o más cerca, y no hay una "mejor". Por ejemplo, no sirve estar super lejos y cubrir un montón si lo que interesa es sacar fotos detalladas de ciudades. Y no sirve estar re cerca y cubrir poco si lo que interesa es transmitir señales de comunicaciones.

Si dije que el area que cubre tiene forma de círculo, por qué no se ven como círculos en en mapa? Los ARSAT parecieran cubrir un cuadrado, mientras que los NUSAT ven círculos o cosas más deformes dependiendo del momento!

Eso es culpa de la proyección que usamos en el mapa. El mapa deforma mucho la imagen, la estira más cuanto más cerca estemos del polo. Si lo viésemos en un globo terraqueo, se verían como círculos.

Cosa extra que se puede ver: si hacemos click derecho en el punto de un satélite, podemos tildar la opción "Ground Track", y eso nos muestra el camino que el satélite va a recorrer durante las próximas horas. Si lo hacemos para un ARSAT no se va a ver ningún camino, porque son sates que están siempre en el mismo lugar en el cielo! (geoestacionarios).

Qué estamos viendo alrededor?

Al costado hay dos cosas: un gráfico con forma de mira ("vista polar"), y un grupito de datos de un satélite.

El gráfico con forma de mira es el cielo que vemos desde nuestra casa, con las posiciones de los satélites que lleguemos a ver (si es que hay alguno arriba nuestro). Si por ejemplo vivís en Argentina y pusiste tus coordenadas, deberías siempre poder ver a los dos ARSAT, y de a ratos algún otro.

Los datos que se ven abajo del gráfico son el detalle de algún satélite en particular. Con el menú que tiene esa sección (botoncito con flecha hacia abajo), podemos elegir qué satélite ver. Cosa que sorprende a la mayoría de la gente: velocidad de los NUSAT o CUBEBUG, de 7 km/s. O sea, más o menos 23000 km/h. Un poquito rápido, suficiente como para dar la vuelta al mundo 16 veces por día (lo hacen!).

Otra cosa útil: podemos ver cuándo es la próxima pasada del satélite por encima nuestro (o cuánto tiempo le falta antes de irse de nuestro cielo, si justo está pasando por arriba). Eso se ve en el campo "Next Event".

Y finalmente, la tabla de abajo es similar al detalle del costado. Solo que muestra datos de varios sates a la vez.

Espero que lo disfruten tanto como yo :)

0. The example

We will need a Keras example to check if things are working well. Use the code from this repo.

In that repo you will find a keras experiment (in one of the ipython notebooks), and a small script to check for gpu usage from Theano. Both will be useful.

Remember to create a virtualenv and install its dependencies (from the requirements.txt). You can use wheels to speed up the process. And it requires python 3.

1. Nvidia gpu drivers

We need Ubuntu to be able to use our gpu. To achieve that, we need both the gpu drivers and the Optimus drivers. Thing is, Optimus drivers are kind of broken right now under Ubuntu 16.04.

But we can get things working, with some small annoyances:

1. Disconnect any external/secondary monitors.

2. Install video and optimus drivers: sudo apt install nvidia-361 nvidia-prime

3. Reboot your machine and login.

4. Open the "Nvidia X Server Settings" app, go to the "PRIME Profiles" section and choose "NVIDIA".

5. Close the settings app.

6. Logout and login again, so the profile change can take effect.

A small annoyance: while the "NVIDIA" profile is active you cannot (at the moment) use a secondary screen. It will crash your X server.

Important: remember to go back to the "Intel" profile whenever you don't want to use your gpu anymore, logout and login back for it to take effect. Otherwise, your gpu will be using lots of power for nothing.

2. CUDA

We need to be able to do general purpose computation on our Nvidia gpu. To achieve that, we need the CUDA toolkit. Thing is, CUDA has no Ubuntu 16.04 package at the moment.

But we can make things work. This is Linux, after all (thanks to Martin Thoma's answer):

1. Download CUDA from the Nvidia website. Choose the Ubuntu 15.04 "runfile (local)" version.

2. Check the md5 sum with: md5sum cuda_7.5.18_linux.run. Only continue if it is correct.

3. Run the installer and follow the instructions: sudo sh cuda_7.5.18_linux.run --override. Make sure that you say y for the symbolic link, and n to the video drivers installation.

Don't worry about the warning related to the non-installation of the video drivers. The script is somewhat dumb and doesn't detect the drivers we installed on the previous section.

3. Gcc and G++ versions

Guess what? Yes, more problems.

CUDA requires gcc to be a version up to 4.9. Later versions won't work. Ubuntu 16.04 ships with gcc 5.4.

But we can have both versions side by side, and trick CUDA to use the older versions with just some simple symlinks (thanks to charlie for the tip, the old solution was far more complicated).

sudo apt-get install gcc-4.9 g++-4.9
sudo ln -s /usr/bin/gcc-4.9  /usr/local/cuda/bin/gcc
sudo ln -s /usr/bin/g++-4.9  /usr/local/cuda/bin/g++

# Work around a glibc bug (according to the theano docs)
echo -e "\n[nvcc]\nflags=-D_FORCE_INLINES\n" >> ~/.theanorc

4. Testing

Done! You should be able to run Theano things (including Keras neural networks) using your gpu.

A simple way to check if that's true, is to run the test_gpu.py script from the example repo. But don't just "run" it. You need to tell Theano "hey, I want you to use my shiny cuda gpu". To achieve that, run the script like this (inside your virtualenv):

THEANO_FLAGS="mode=FAST_RUN,device=gpu,floatX=float32,cuda.root=/usr/local/cuda/" python test_gpu.py

If everything is working, it should quickly run and output something which ends with: Used the gpu. If instead it takes a long time (~1 minute) and ends with Used the cpu, then something is not working.

If that worked, then you can try the full example and play a little with it (should be able to run all lines without errors):

THEANO_FLAGS="mode=FAST_RUN,device=gpu,floatX=float32,cuda.root=/usr/local/cuda/" ipython notebook

The "interesting" story

Imagine having a main gmail account, and a handfull of extra accounts (to reserve names, to test some api stuff, etc).

Imagine not having used those extra accounts in years. And even more: not having used them ever. Not a single email sent, not a single external app connected to them, not any login to other sites, etc.

One day you decide to start using a password manager. And an open source one, which stores the data encrypted using gpg. You even create a new gpg key to encrypt them, to be sure it's safe. You sync your encrypted data into an online private git repo, because nobody could decrypt the data anyway.

Two days later, you receive an email from google:

PANIC

(worth mentioning: I'm from Argentina, the access was from the US)

After some investigation, you discover:

• You were reusing the password from that account.

• The way you were using the password manager, the account names weren't encrypted (the passwords were, of course).

• By reusing it, the encrypted data is the same in all encrypted files.

• You never used the account, but it has your name on it, easily guessable account name.

Conclussion: someone who has your password from another (unsafe?) service, could have either guessed your secondary account name, or gained access to the encrypted data, which has the account names in clear text. By just comparing encrypted contents, not even decrypting them, that person could have known in which other sites the leaked password could work.

Ok, you now think you know, you just need to change passwords on all those sites, and never ever reuse passwords again. But oh no, you know nothing. After doing it, a few days later...

Email: Someone has your password.

Again! But this time from a different account: not that one which was easily guessable and which shared the password with other sites. No. This time? An account you didn't even write down the name, not in your password manager, nor anywhere outside google itself. The password was written down in your password manager, in clear text, because you were a little clumsy and confused "user" with "password". But then again, you never wrote down the account name outside google, ever.

How could someone have gained access to that account? How in hell can someone know you own that account, and he can use that "username" as password for it?

You start to recall... There is only one place were you have references to that account: old emails you received in your inbox, when you created the account. Your inbox.

Think about it: Google is telling you "hey, someone knows your account and password", and you know that the account name was only present in old emails at your inbox, while the password was only written down in your trusty new password manager.

NSA, is that you? Or a random hacker who really wants to steal my data? What valuable data can I have? Hell, I need to get everyone to revoke my credentials everywhere, now.

The "boring" story

But no. There is always a boring explanation, something simpler, that doesn't look like a CSI Cyber episode. In this case? something that looks like a bug on some internal Google services.

I discovered this almost by chance, while writting down a super comprehensive explanation of the things I was seeing (a 5x longer version of the interesting story). I realized I had both accounts added to my main email account, using gmail's feature to access emails from multiple sources. This feature:

I thought: "oh! I forgot to update those settings after changing the passwords". And so I opened gmail, went to the settings, and saw the big red errors telling me that gmail wasn't able to connect to those accounts. Which was to be expected, as I changed the passwords. But something clicked inside my head: since when is gmail unable to check those accounts? what was the error?...

And there it was, the boring truth in all its boringness: gmail wasn't able to access the accounts from the exact same moment the "suspicious logins" happened.

Some might think "oh, that's to be expected as well. Google must have blocked the account as soon as the security incident was detected". But no. This feature doesn't check email every second. For my accounts, it's doing it once every day, more or less. And the failed attempt was at the exact same time the "suspicious login" happened. In both accounts. Different times each one. Too much coincidence.

I wasn't able to see the original error for one of the accounts, too many login errors since it because of the password change, and it only stores the last 5 of them. But for the other account the first error was still there, and it was different to the password related ones.

The errors after the password changes were:

Authentication error.
Server returned error "[AUTH] Username and password not accepted."

But the error at the same time than the suspicious login was:

Authentication error.
Server returned error "[AUTH] Web login required: https://support.google.com/mail/answer/78754"

The linked support page isn't very helpful, but if you google the error you will find some people having the same issue: after years of not using an account, the login on their pop3 client starts to fail. Maybe something changed in google's security policies, maybe it's related to new terms of service, or required security checkups. But the thing is: logins fail until you login from a browser and tweak some stuff (enabling less secure apps, etc).

That itself isn't the bug. The bug is flagging those pop3 logins which came from inside google (it's a gmail feature, running on their servers), as if they were "suspicious logins". They are not suspicious, they are comming from inside google, they are being made from a google server trying to execute a gmail feature.

Finally, how sure am I that the logins came from inside google? Well, a traceroute to the login ip took me to this host: mail-pa0-x218.google.com.

So yes, I'm pretty sure this was a bug. But by Cthulhu's beard, I'm happy this was a bug.

In short

A gmail server tries to login to a gmail account for a gmail feature to work, and the user gets a big red email: "someone has your password". Yes, google, someone has my password. It's you.