Pablo Hoffman

At first, Privnote looked like an ideal application for porting to Google App Engine because:

• it's already written in the "official" App Engine platform (Python+Django)
• it's entirely based on a request/response mechanism
• we would forget about scalability problems forever

So we give it a try and implemented a prototype, just to see how it goes, but, in the end, GAE didn't work because:

• it doesn't have support for SSL, which is mandatory for Privnote
• it doesn't support third-party Python C extensions (which we use in Privnote) unless they're pure-python modules

As for scaling Privnote, we''ll have to try other alternatives, but it was a good experience to gain some knowledge about Google App Engine and cloud computing, which are very hot topic these days.

When I launched Insophia, about a year ago, I wanted it to have a blog, right from the beginning. So I chose Wordpress as the platform for the site. However, in many occasions, when going to write something, I faced the question of where to post it. Should I post it in the Insophia (corporate) blog or here, at my (personal) blog?. And, even thought it may not seem that important at first, several articles never saw the light because that uncertainty prevented me from going on.

So I'm happy that I finally made a choice. From now on, I'll write everything here. I can always aggregate the articles in the Insophia blog, if I see the need. My original idea with the Insophia blog was to be written by all Insophia people but, after a year, there are only 3 articles and all of them written by myself. Why did this happened?. Not much bloggers at Insophia, I guess. In any case, the "new" Insophia blog will be more like a "News" section (with quick short posts) and all articles (well, at least mine) will be published here.

In the future, if some people at Insophia become interested in blogging (blogging should be encouraged, but never -ever- enforced) we could aggregate all their blogs into the Insophia blog.

Have you ever wanted to send some highly confidential information (like credit card information or root passwords) over the Internet and were afraid others could be sniffing your traffic?. Well, I have, all the time. I've always being paranoid about this, so that's why we, at Insophia, came up with Privnote, a tool for sending private notes over the net in a very easy and secure way.

All you have to do is enter the site, write the note and click Post. Then you get a link that you can send to the only person you want to read it.

What makes it so secure then?.

Two things mostly:

• SSL encryption makes sure the note contents never leaves your browser (neither arrives at the recipient browser) in plain text
• When the note is read (by clicking the link) it automatically self-destructs so no one else who clicks the link could read it. If the note was not read by the intended recipient, at least he/she will known that someone else did it and that the content was compromised

What about the site administrators, you may ask, those ones who always seem to have "full power" over your data. Well, with Privnote, those cannot read your note either. The explanation is a bit more technical, but here it goes: When the note is received by the server, a note ID is created (the same ID you see in the link to read the note). The note contents is then encrypted and saved in the database but (and here's the magic) the salt to encrypt the note is not the note ID but a hash of the note ID. Hashes "one way" so you cannot go back to the note ID from the hash. So the note gets stored in the DB encrypted with a token that only the person which has the note link can read it. Oh, and we also have web server access logs disabled which makes impossible for any administrator to decrypt the note contents. So, as you can see, the only person who has the key to decrypt it is the one who has the link to the note.

As an additional feature, you can get notified when your note gets read, something that (even today) is not possible with any email or instant messaging software.

Also, I want to mention that the application is available in English and Spanish. By default, it works in the language of your browser, but you can change it using the language selector in the top right corner.

I would like to hear your thoughts about it, feel free to post any comment, criticisms and suggestions.

Yo sabía que de algún lado me sonaba el "look" del nuevo favicon de Google...

favicon de pablohoffman.com (desde 2004)

nuevo favicon google.com

Voy a contar los pixeles iguales y si superan el 50% los demando! :)

I needed a virtual machine for debugging some Python memory leaking software without risking the health of my Ubuntu system. VirtualBox was my first choice because of its ease of install (just "apt-get install virtualbox"). Since I wanted to access the VM via ssh (instead of using the VirtualBox console) I found a bit annoying not being able to access the guest PC from my host PC. This is because VirtualBox does user-level NATing for providing connectivity to the guest PC. Although you can change the default virtual networking method, and use bridging instead of NAT, that requires installing bridge-utils and some networking configuration changes). I wanted something simpler, which didn't involve installing additional software or modifying my network settings. After all, that's the reason why I installed VirtualBox in the first place: to leave my system untouched. So after peaking at the manual, I found VirtualBox supports port forwarding between the host and guest PCs.

You have to run the following commands with the guest PC turned off:

VBoxManage setextradata "Guest PC" "VBoxInternal/Devices/pcnet/0/LUN#0/Config/ssh/Protocol" TCP
VBoxManage setextradata "Guest PC" "VBoxInternal/Devices/pcnet/0/LUN#0/Config/ssh/GuestPort" 22
VBoxManage setextradata "Guest PC" "VBoxInternal/Devices/pcnet/0/LUN#0/Config/ssh/HostPort" 2222

Where "Guest PC" is the virtual machine name, the same name you see in the machines list (in the VirtualBox main window). Those commands add a local forward from TCP port 2222 (on the host) to TCP port 22 on the guest.

So now you can access the guest PC via ssh by running "ssh localhost -p 2222"

If you want to make it even simpler you can provide a quick shortcut by adding these lines to your ~/.ssh/config:

Host guestpc
    Hostname localhost
    Port 2222

After that, you can connect by just typing "ssh guestpc"

Google has just launched AppEngine, a new hosting service with "all the Google infrastructure" available for you. For now, it only supports my favorite language, but they may add more languages in the future.

A couple of things that come to my mind now:

• If you're running a hosting company, you should re-consider your business, specially if it's a python/django one
• This is a huge booster for Django and, at the same time, a big blow for Rails
• Guido joining Google was a good idea

Let's see how it goes, but I foresee a promising future for this one.

It took me some time to find out how to do this, so I'll post it here hoping that someone will find it useful.

First of all, "fidsk -l" won't show all your FreeBSD disklabels, you'll have to do "cat /proc/partitions" to find the partition you wan't to mount. If the Kernel has support for disklabels (it comes by default on modern Kernels) you will see all your BSD disklabels.

Example:

# cat /proc/partitions 
major minor  #blocks  name

8     0  195360984 sda
   8     1     104391 sda1
   8     2    1044225 sda2
   8     3  194209785 sda3
   8    16   78184008 sdb
   8    17   78180291 sdb1
   8    32  117220824 sdc
   8    33  117218241 sdc1
   8    37    1048576 sdc5
   8    38    2097152 sdc6
   8    39    3145728 sdc7
   8    40    1048576 sdc8
   8    41  109878209 sdc9

Suppose I want to mount /dev/sdc9 (it was /usr in my old FreeBSD) on /mnt. This is the command to do it:

mount -r -t ufs -o ufstype=ufs2 /dev/sdc9 /mnt

Support for UFS2 is read-only.

When you have accounts in dozens and dozens of servers, it could be hard to replicate and keep track of all your configuration files (aka. rc files). To be honest, that's the reason why I never used rc files in the past, and always tried to stick with the default behavior of programs. But, for some time now, I've been using Subversion to keep and manage my personal rc files and it has proven extremely useful. If you don't know Subversion I recommend you to read about it, even if you don't plan to use it for development. It's a great tool for keeping track of files, not necessarily source code. The Subversion book is the reference, but you can also find plenty of tutorials online.

So the idea is simple: just use Subversion (SVN) to keep track of your configuration files, like you would use it to keep track of source code.

To create a repository for your personal rc files you would do something like this:

cd ~
svn mkdir -m "adding pablo rcfiles" https://svn.insophia.com/rcfiles/pablo
svn co https://svn.insophia.com/rcfiles/pablo .

Then, when you want to add some configuration files to revision control you would do:

cd ~
svn add .vimrc
svn ci -m "added vimrc to rcfiles"

Finally, when you edit some configuration files you can commit in one server and then run "svn up" in the all rest to synchronize to the last version, so you only need to modify your configuration files once, which is great. Also, if by some reason you broke a configuration file you could always revert to any prior version of the file (SVN provides this functionality). So, this is useful even if you don't have accounts in multiple servers.

We also use this approach at Insophia to manage the configuration files of our servers, and it has proven equally useful.

Have you ever ssh'ed into a remote server and wondered if you could run a program using the connection from that remote server in a transparent and easy way?

Well, you can and it's quite simple. Here's the recipe for Linux.

1. Install tsocks using your Linux distribution package manager (preferably) or compiling from source.

2. Add a file ~/.tsocksrc with this content:

server = 127.0.0.1
server_type = 5
server_port = 9999

3. add this to your environment variables:

TSOCKS_CONF_FILE=~/.tsocksrc

4. ssh'd into the remote server by typing:

ssh -D 9999 user@server

5. launch the application using tsocks. For example, if you want to run Firefox using the remote server connection, type:

tsocks firefox

There you go. The program will run using the connection from the remote server (where you have ssh'ed) in a complete transparent way, no matter which ports the program uses. An alternative way is to run the programs with this environment variable set:

LD_PRELOAD=/usr/lib/libtsocks.so

That would use the tsocks library always, even if you don't run the program with tsocks.

If tsocks is not available you still can do this if the application can be configured to use a SOCKS5 server (localhost:9999 in this case). For example, in Firefox you would have to go to: Preferences - Advanced - Network - Connect - Settings, and enter SOCKS Host: localhost, Port: 9999.

Beware of the whois service. There's a lot of people in the world spying whois queries to steal domain names.

Back in August I was looking for a cool name for my company, and the domain name was the starting point. To tell you the truth, insophia.com was not the first one at all, although I'm now convinced it was the best ;) I started with others (arguably more or less) cool names, which some bulk DNS selling company stole from me after 4 days of making my first whois query to find out if they were free. And I didn't even use any public web page for making the queries, I just used the good ol' unix command line tool.

So my advice is: if you are looking for a cool dot-com name, register all the "not so cool" domain names you find on the way, even if you are not sure at first (you never are anyway) whether you're gonna keep them. Because, when you get to decide, it may be just too late.