Getting a Tor hidden service running doesn't have to be hard. I've just published an example Sinatra application demonstrating how to deploy a hidden service to Heroku (or Dokku, etc) in just a few lines. The app uses my ruby-hidden-service library with the multi and apt Heroku buildpacks to install and configure Tor. A deployed example is running at sinatra-hidden-service.herokuapp.com.
Here are the complete steps required to deploy the sample app:
I've just released Rack::DetectTor, Rack middleware for detecting Tor users. It adds an environment varliable
tor_exit_user with a value of
false to the Rack
request object. I've previously blogged about detecting Tor users in nginx using iptables, however Rack::DetectTor is a much neater and more self contained solution for Ruby/Rack based web apps (built on Ruby on Rails, Sinatra, Padrino, etc).
More info on the Github project page: https://github.com/warrenguy/rack-detect-tor
I've just launched BTC Watch. It's a simple service that monitors the Bitcoin network in realtime, allowing you to subscribe to real-time e-mail updates of transactions occuring on addresses you wish to monitor. You can opt to receive notification immediately when the transaction first appears on the network, and/or when the transaction has been confirmed between 1 and 120 times and at several steps inbetween.
You might find this useful for monitoring addresses you publish for receiving funds or donations, or for keeping track of your own addresses and transactions. No sign up is required. Just enter your email address, and the Bitcoin address you want to monitor, and you're set. Check it out at https://btc-watch.warrenguy.me. Some screenshots of sample email notifications are below. The emails have both text and HTML parts, and also include an attached file with a JSON object containing the complete transaction information.
After a few months of downtime (sorry!), the DNS tester is back.
It no longer uses the full list of nameservers from public-dns.tk, as it appears that someone is zmapping the entire IPv4 submitting every DNS server they find to the database (this was the cause of the downtime - my importer couldn't handle the large volume). Consequently the quality of data is now relatively poor and includes many dynamic addresses etc. For now I'm just using a subset of the servers (those that have been up reliably for at least several months), which should be good enough.
I currently manage around 15 Linux servers in my personal capacity, all now virtualised "in the cloud", with the majority currently at either Linode or Digital Ocean. Recently I began sending email for the first time from a server at Digital Ocean, and noticed consistent delays in delivery. I'm sending email via a smarthost on another server for delivery, and on inspection, it appeared that the Digital Ocean machine is unable to connect to the smarthost via IPv6, and so times out and retries on IPv4. On further inspection, I discovered I was unable to connect to any IPv6 address on the Internet on either port 25 or 587.
On raising a support ticket with Digital Ocean, I learned that this is a deliberate practice by Digital Ocean. In fact, all common email related ports are blocked: 25 (SMTP); 109 (POP2); 110 (POP3); 143 (IMAP); 465 (SMTPS); 587 (SMTP submission); 993 (IMAPS); and 995 (POP3S). I've reproduced my communication with Digital Ocean support here verbatim: