Regrets of the dying

Came across this post on Hacker News today. The link to the article was dead so found a cached copy.

There is a short piece from Paul Graham on the same topic.

What powerful thoughts. It boils down to the following things people who were dying regretted not doing in this lives:

  • Don’t ignore your dreams
  • Don’t work too much
  • Say what you think
  • Cultivate friendships
  • Be happy

As Paul Graham writes in his article, these should be on the top of your TODO list.

The unfortunate realisation I’m struck with is: I am missing on ALL of these things.

Ignoring my dreams. Working too much. Unable to say what I think from fear of reprisal, upsetting people, and/or hurting them. Missing out on friendships. Not being happy, blaming it on being inherently unhappy.

I will die one day with all of these regrets.

Tech Sabbath: Week #2

Last Sunday I set a challenge for myself. I also decided to write about the progress I will make every weekend. The following is a passing account of how I fared during my second Tech Sabbath.

This Sunday, in terms of the challenge, wasn’t very different from the last. For the most part I managed to stay away from my devices. Successfully. I didn’t turn off Internet on any of them, though, as I did last time, but refrained from using them. It also helped that nobody attempted to contact me via my devices. Let’s keep it that way.

I read several pages of Shutter Island. After putting it down last Sunday, I didn’t pick it up again until today. Because of being in the early stages, the book is moving along very slowly. I can only hope that it is just as riveting and mysterious as the movie.

A good part of my day was consumed by physical chores, and by the end of which, I was happy I got around to dealing with them. Procrastination has become the sad order of the day, and more so when it comes to household chores. It is easier to put them off with an excuse.

It was the Roland Garros final between Novak Djokovic and Stanislas Wawrinka. I cannot imagine how I completely forgot about it. Instead, I played Far Cry 4 on my XBox for a couple of hours. For someone who is obsessively involved with playing as well as watching tennis, I should think that it is a sign of the times.

About the XBox though, you may rightly complain that I cheated. I don’t think I did. For me, Tech Sabbath is about breaking my device-addiction. If I was addicted to playing games on my XBox, I would safely include it into the list. The way life has shaped itself for me over the last couple of years, I rarely if ever get time to play games–it is important to mention this, because I used to be an ardent, hardcore gamer. In other words, by not wiling time away glued to my devices, I played an immersive game on a big screen. The Far Cry franchise has always been renowned for its immersive gaming experience as well as the breathtaking free world environment it offers to its players. It’s immersive because when you play it, you feel less like playing a game than living through one. It’s an open world, and everything in it is as true to real life as can be.

I will confess though that I did, near the end of the day, pull up my laptop in bed not only to write this but also to read a foreboding article on how climate change is drastically going to afflict further the country in which I live. I have long, in my dreams as well as in my waking hours, worried over the state of growing natural calamities of late, the increasing lack of balance in nature and the ultimate impact it will all have on our world. It is macabre, judging from the way things are headed. The sign of the times that is hiding round the bend ahead. But that is a solemn topic for another day.

The small lifestyle change I’ve made.

Two years ago I made a lifestyle change by quitting my work-from home job, after committing four years of my life to it, and joining a full-time position at a physical office a half an hour drive away from where I live. I wrote about it, as well as other changes I brought about and embraced in my life, earlier here. For me, it was undoubtedly a big change.

Over the two years since, I felt that my lifestyle took on a downward bend. I was sleeping late, sleeping badly, waking up multiple times through the night. I was, as a result, getting out of bed late. With working parents leaving for work early, I was having the entire house to myself. I was lazing around the house, making my own breakfast–not quite the big deal everybody makes it, something I’ve been doing for a long while–watching TV in between, and getting ready to leave for work. I was coming to work late–which because of flexible timings at work was never a deterrent–and therefore leaving work late. Consequently, the lifestyle I had quietly slipped into was leaving me with no time to do anything else.

I accepted it as the way life was. Routine is just that. Once you settle into a routine, you accept it and refuse to believe there may be something wrong. That is how a major portion of your life is spent, following a routine day in, day out, unfalteringly. I accepted I had become a zombie and didn’t find any reason to complain. I saw no meaning in life. Ultimately, a zombielike routine for a life that held no meaning sounded perfectly alright to me.

I had the power to change it, but inertia lulled me to the dull satisfaction of that life. Why bother adjusting the cogs when they were moving mechanically in stride. Why bother risking bringing chaos into the otherwise imagined order and comfort of the system.

That was worrying. I was wrong. I had to do something.

And so, I started with the little steps. You hear about people dealing with addictions and habits either gradually or by cutting them off completely in one fell swoop. I felt, for me, the patient but determined approach was more likely to yield results.

Starting last month, I have been making a concerted push to change bits and pieces of my lifestyle. I wake up, and get out of bed, without fail between seven and half past seven in the morning–which is two to two and half hours earlier than what I had spoiled myself by allowing the luxury of. Whether sleepy, tired, regardless of how late I slept, I do it. Unfailingly.

I walk out for a wee bit, taking in the crisp and sometimes damp air. Notwithstanding how sultry the weather mercilessly is, the mornings are always brisk to some extent. And quiet.

I take my breakfast early too. The want of lazing time away has now been replaced by a need for doing things with some urgency. That gets me going.

Instead of getting into work around noon, I walk in around half past nine when the office is mostly empty, quiet and calm. No din of stand-alone fans, no annoying variable pitched voices chattering about. The overwhelming feeling of emptiness of space makes itself felt strongly. And the endearing quietness. For a month I have not failed to notice them. Not failed to appreciate them.

Instead of leaving work when the world was getting ready to put an end to their day, I leave work behind early at the end of the evening. I leave when the world outside is still naturally aglow and make it a point to appreciate it every evening. It allows me ample time to do what I will with it. I am home early to spend time with family. I hit the courts early to play when I feel like. I have sufficient time to go out with family for groceries and other activities that I apathetically shrugged away before.

Reading in the morning after coming to work is pleasant and distraction free. A fresh shower and a smooth drive to work, by avoiding taking chocked routes, do wonder to the mind. I feel brisk from the mornings till late afternoons. I can read more without loss of focus–if not the dwindling absence of it. I can write without friction. My mind actively takes on the day’s array of work.

It’s not all lovely though. I feel tired and devoid of sleep. I still don’t sleep well–but I believe that has deeper roots. I fall asleep easily because I’m too tired by the end of the day. My stark stance of not finding meaning in life hasn’t been affected, although I doubt very much that such a metaphysical complication can so much as be cured by a change in lifestyle.

It’s merely the beginning of it. That I feel the fruit of this gradual process, never minding the scars and the mud sticking on the surface of it, I feel motivated to push it further.

 

Taking a Tech Sabbath every Sunday

I came across the idea of a Tech Sabbath last Sunday afternoon in bed. The realisation that I suffered from an acute addiction to the various devices and computers I had at my disposal shocked me. It had become incredibly difficult for me to tear myself away from these sources of media. Despite having spent a nine-hour day at work in front of a screen, despite having a splitting migraine, I failed to put my phones and my tablets away when I was in bed at the end of the day. There was always the irresistible desire to read, to consume more content, and the ever increasing guilt of not having enough time to do more of it. The much needed rest could wait. The disturbing headache could be braced for a little longer.

Tech Sabbath was just the sort of thing I needed. I didn’t have to apply it in my life every day. I could choose to do it on a single day of the week. And so I decided at that very moment to embrace Tech Sabbath. As soon as I finished reading the article, I disabled Internet on all my devices and put them away. I turned off data services on my phone as well, which meant that I would not receive messages on WhatsApp or Facebook or any of the myriad applications on my phone. And for much of what’s left of the Sunday, I only barely checked my phone, and only for missed calls or texts. I didn’t touch my computer or my iPad at all. What I did instead was pick and dust up a book from my small shelf of books–for the past several years, I’ve been zealously reading books on my iPad. It was Dennis Lehane’s “Shutter Island”, a book I bought a year and a half ago after having watched and liked the movie that came out of that book. I managed to read a couple of its pages.

All in all, I cannot say my day became exceptional in any way. Or that it was extremely relaxing as a result of what I did. But what I can proudly claim is the fact that I managed to control my addiction, even if for a day. And that’s something!

My goal now is to religiously stick to taking a Tech Sabbath every Sunday. I also plan to write about my progress. If you feel that you are addicted to your devices, and if you ask me I cannot say who in this age will not feel that way, perhaps you might find something likeable about the Tech Sabbath.

Securing OpenVPN against Logjam

I dearly hope that by now readers are well aware of Logjam.

Logjam affects not only SSL traffic over the web, as most of the Internet will have us believe. It affects any kind of traffic that relies on TLS. That includes SMTP traffic, SSH traffic, OpenVPN traffic, among others. There are quick guides available on how to secure several different types of traffic affected by Logjam, including this one provided by the folks who discovered the issue. Cloudfare has a nice write-up about the Logjam issue as well.

I’m here to talk about OpenVPN and how to protect VPN traffic from being affected by Logjam. I had trouble finding information about OpenVPN in relation to Logjam.

If a DHPARAM key smaller or equal to 1024 bits in size is being used, a new key of at least the size 2048 bits must be generated and used. The command openssl dhparam -out dhparams.pem 2048 generates a new key of size 2048.

OpenSSL must be updated to the latest version available. At the time this is being written, the latest version available of OpenSSL is 1.0.2a. In the 1.0.2a version of OpenSSL, the EXPORT class of cipher suites is disabled by default. It is the Achilles’ heel exploited by Logjam in particular. This means that OpenSSL will by default refuse connections which attempt to use any of the EXPORT grade cipher suites.

The configuration of the OpenVPN server must be examined. In particular, attention must be paid to the “tls-cipher” setting. If this setting is defined in the configuration, particular attention must be paid on whether any EXPORT grade cipher suites are defined. If any EXPORT grade cipher suites are defined, they must be removed. This section on OpenVPN Hardening provides a secure list of ciphers to boot. If the setting is left out from the configuration, a look at the output of the openvpn --show-tls should show whether weak, EXPORT grade ciphers are accepted by default.

According to this blog post by OpenSSL about Logjam, OpenSSL plans to release 1.0.2b which will reject connections that use a DHPARAM key <= 768 bits in size. Once available, servers and clients should be updated quickly to use it.

Disable Newrelic per-directory

This will be the tl;dr version of this post because roughly nobody gives two hoots about the story that led to my discovery of this. Note that this example considers the PHP agent for Newrelic.

If your desire is to disable Newrelic on a particular directory, you can fulfil it by dropping a .htaccess file inside that particular directory with the following contents:

&lt;IfModule php5_module&gt;
    php_value newrelic.enabled false
&lt;/IfModule&gt;

Three caveats:

  • The name of the module inside the <IfModule > tag is important. The command apachectl -t -D DUMP_MODULES | grep -i php will help you find the name of the module installed on your server.
  • You must have Newrelic enabled inside the INI file for Newrelic.
  • I may be wrong about this but you cannot be a smart aleck and only selectively enable Newrelic on directories. It only works the other way around.

GHOST vuln and Digital Ocean

Yesterday, right after I had the displeasure of dragging myself into work with a head attached to my body that hurt oh so much, I found out to my slight dismay about the GHOST vulnerability (and of course of the ops teams working to patch the servers). I scrambled to find out what in the world it was all about. This Qualys Security Advisory has a very scary rundown of the bug.

I have a Debian machine, in the cloud, with DigitalOcean, that I use for running all sorts of crazy things. I patched the box up, though there sure was a long list of updates. The thing you come to hate about Windows, if you use it, is that every update, security or feature-wise, to the OS requires a complete reboot, even on servers. Contrarily, it’s the thing you love about Linux, if you use it. But this bug was different. In a number of discussions about the GHOST vulnerability I read, it was advised, for a successful completion of the patch process, to fully reboot affected servers. It sounded ridiculous but after peeling away the veneer of absurdity, it made all the sense in the world. The GHOST vulnerability affected “glibc” which is a very important part of the Linux OS. An unnamed number of applications, services, and OS components use “glibc”, and as such, there was no surefire way of knowing that everything running on a Linux system that depended on “glibc” was restarted or reloaded in a way that caused it to use the updated version of “glibc” — except for a complete reboot.

I did that. I forgot to mention I run OpenVPN on my machine which uses the TUN/TAP interface drivers on the system. When the system got back to its feet, which was rather quick, I couldn’t get OpenVPN to start. It bailed out after coughing up this:


SIOCSIFADDR: No such device : ERROR while getting interface flags: No such device
SIOCSIFDSTADDR: No such device : ERROR while getting interface flags: No such device
SIOCSIFMTU: No such device failed!

Naturally, the “tun” interface wasn’t up. I couldn’t remember, when I first set up OpenVPN, whether I set up the “tun” interface myself. But a peek at the syslog told me something:

kernel: [ 228.358361] tun: Unknown symbol ipv6_proxy_select_ident (err 0)
kernel: [ 228.360982] Loading kernel module for a network device with CAP_SYS_MODULE (deprecated). Use CAP_NET_ADMIN and alias netdev- instead

Confused, I looked around and found this bug report. Somebody, probably the afflicted, found out that DigitalOcean was playing silly by not changing the kernel version to boot from to the one updated to. The solution was simple: Boot the server from the DigitalOcean panel with the latest kernel version selected from the settings page for the droplet. That fixed it.

In passing, I’d like to mention this article here which makes a case that WordPress can be used to exploit the vulnerability owning to the way WordPress handles ping-back comments.

My favourite Homebrew apps

I have been a die-hard Linux advocate the past 11 years. Four years ago I moved to Mac OS X because I felt increasingly frustrated over the state of the Linux desktop. I preferred using Linux on the desktop to using Windows because it beat having to use Windows every time. Mac OS X, however, presented a much better alternative, so I jumped ship. I haven’t looked back since. The fact that Unix is at the base of Mac OS X made it an attractive option for me. As I have said the past four years, it is hard not to use an operating system that offers a great UI on top of one of the best operating systems of the millennium.

I continue to use Linux to this day on servers, though. I find there is no better alternative for an operating system than Linux on a server. Having spent a good deal of time using Linux, you become accustomed to certain favourite applications and tools that sadly aren’t all readily available on Mac OS X. You can always run Linux as a virtual machine on your Mac, but it would be really splendid if you were to have natively those applications available on your Mac. For such applications, on Mac OS X there are two options:

On my first ever MacBook, I tried fink. It worked well for me that time, but it has been so long since then that I cannot really remember why I let it go. Instead, I welcomed Homebrew.

If you are coming to Mac OS X with a Linux background, Homebrew is the tool you cannot afford to miss out on. At the heart of it, it is a package manager for OS X. For me, it is more a way to get Linux applications to run natively on OS X. You can even create your own Homebrew packages if you’re savvy. I haven’t never needed to try, though.

I thought I’d share the applications I use on Homebrew regularly.

colordiff

Life without diff is unthinkable. I diff a lot. It really helps to make my diff-heavy life colourfull. On all my Linux servers colordiff is available so whenever I want to use diff, colordiff is what comes to mind.

dnscrypt-proxy

I use dnscrypt-proxy for two purposes: to of course secure my DNS traffic; and to bypass the silly restrictions imposed by my ISP which do not allow me to use any third-party DNS services, such as those offered by Google DNS or OpenDNS.

gnu-typist

I have always loved typing tutors. In fact, finding a typing tutor and learning to touch type on one was the best thing I did as a high-school student. It changed the way I used computers forever. I can’t find for the life of me the particular DOS-based typing tutor I started out with. I wish I could. But for all intents and purposes, GNU Typist is pretty good at what it does.

gnupg

If you don’t know how indispensable GnuPG (or PGP) is in this age, I feel sorry for you.

htop

I call it top that is high on weeds. Once you go htop, top looks very bland and boring.

nmap

I cannot imagine using a Linux or Unix system without nmap on it. Incidentally, I have long history of using nmap.

openssl

Sadly, the openssl application that ships with OS X isn’t as readily updated as the frequency of openssl security advisories demand.

tcpflow

I’m a big fan of tcpdump. Luckily, OS X ships with a native tcpdump implementation. Setting up Wireshark is a bit of a pain though as you first, rather ironically, need the X server running on OS X. For protocol and traffic analysis, tcpflow is great.

wget

If you show me someone who doesn’t need wget on shell, I will show you a liar. Somehow, OS X comes with curl, but not with wget. Although, you can use a combination of bash aliases and some switches to curl to achieve wget, it is not really wget until it is wget.

slurm

This is a recent discovery, though given the pliable nature of my memory, I have already forgotten where I discovered it. It is a nerdy little application that displays the real-time breakdown of statistics of network interfaces.

If you’ve got a favourite application on Homebrew, I’d like to hear from you.

Getting Wireshark to work on OS X Yosemite

Half a month back I upgraded two of my Macs to Yosemite. One was my relatively new MacBook Air at home, which had Mavericks on it. The other was my slightly old MacBook Pro at work, which had Mountain Lion. To my relief, the upgrade went briskly on both systems. (Here’s a little secret: I used this guy’s excellent advice to make sure the upgrade did not take too long to finish.) Not only that, to my surprise, Yosemite improved the OS X experience–both UI and performance wise–greatly. I was afraid putting Yosemite on my MacBook Pro, in particular, might slow it down, forcing me to clean the system and attempt a fresh install. I took backups of course, as should you, but cleaning up an entire system and setting it from scratch isn’t a happy thought. As a rule, I prefer not to do upgrades for major OS X (or iOS) releases. In my experience, a clean install almost always is the better option. Upgrades across major versions of the OS are risky to do. They also additionally–if they do succeed–run the risk of slowing the OS or parts of it down afterwards because of corrupted configurations and whatever mess that was created during the upgrade. The more data you have on your system that you want to upgrade, the greater the risk of a failed or botched upgrade.

Yosemite proved otherwise. For me, at least. I have friends who, unfortunately, have reported issues after upgrading to Yosemite, but they’ve all had older Macs than I do. I can only speak for myself.

Some things did break, though. Like MacVim, which I love, but which I won’t talk about right now. On my work MacBook Pro, I had Wireshark installed that I was using from time to time to dissect network traffic. It’s a great tool. On Yosemite, it stopped working. I found suggestions from strangers on the Internet about re-installing Wireshark, dejected responses from people who did only to find it didn’t make a difference. I then came across a consensus on reinstalling X11/XQuartz instead. People shouted that it worked.

Before I went ahead and reinstalled X11/XQuartz on Yosemite, I fell upon a small gem which explained why X11/XQuartz needed to be reinstalled and how reinstalling it could be avoided. It said that Wireshark was expecting X11/XQuartz to be inside /usr when in fact in Yosemite it was now under /opt. A simple solution was to create a symbolic link inside /usr with the following harmless command on Terminal:

sudo ln -s /opt/X11 /usr/X11

Sure enough, that did cause Wireshark to start. But it took an awful lot of time to show up. X11 apps are slow and crappy in terms of responsiveness on Macs, but they don’t take that long to load. When it did show up on the screen, it failed to detect any interfaces. Now that seemed rather odd. I looked at the system logs through Console.app and figured out that it was a rather silly permission issue. The easiest but not the recommended solution was to run Wireshark as root:

sudo wireshark

I needed to get real work done and couldn’t afford to spend any more time than I had trying to figure out a better way to run Wireshark, so I went ahead with running it as root. But you shouldn’t. As it happens, there are ways to a better solution that involve setting up Wireshark with privilege separation. The Wireshark wiki has an article about it. There is a section near the bottom about OS X which does not read very positively. But there’s a solution there. If you’re finicky about running apps with root privileges–and you should be–, you should go through it. I need to play with it. When I have it all pieced together, I will write again.

Enjoy dissecting packets and analysing network traces!

When pushing a big repo over Git to Assembla fails

At work, Assembla is used extensively, not only to track tasks but also to store DSCM repositories, such as Git. I don’t like Assembla for several reasons, and I don’t like hosting Git repositories on Assembla even more.

Some months back I had to initialise and push to Assembla a Git repository that was almost 800MB big. Like any Git hosting provider, Assembla supports both the Git (SSH) and the HTTPS protocol for interacting with repositories. While I always prefer Git over SSH, there are times when you don’t have your SSH key around or don’t want to use it. In those cases, I simply use the HTTPS protocol, which is rather convenient. However, while pushing this particularly big repository over HTTPS to Assembla, I encountered the familiar “The remote end hung up unexpectedly” error message from Git. My initial thoughts were to blame a flaky network for the error. However, no matter what I tried and how many times, I kept getting that dreaded error.

I went around Assembla looking for any help, but couldn’t find anything that was really relevant to my problem. Luckily, however, I did find a knowledge base article inside Altassian’s documentation, which described the exact same problem. You may read it up here:

If you would rather read a quick rundown, then carry on.

When Git encounters packed objects greater than 1MB in size, it uses “Transfer-Encoding: chunked” in POST requests. Not every web server handles transfer encoding by default, particularly not nginx, unless it is set up to do so. Assembla by co-incidence uses nginx and apparently, the nginx configuration they have to handle Git over HTTPS isn’t set up to use transfer encoding properly. That explained why in my case, where the repository was big and therefore so were the packed objects, Assembla’s Git+HTTPS protocol couldn’t handle the push.

What was the workaround?

I could use Git over SSH and avoid the problem altogether.

Or, as the Altassian article pointed out, the post buffer size for Git could be changed to match the size of the repository. When I changed the post buffer size to 800MB with:

git config --global http.postBuffer 800000000

the next push, while it took its sweet time, worked. :)