blog.sahal.info

While you might be tempted to test connectivity using the ping utility, I do not find that it's worth it most of the time.

You see, the ping utility sends ICMP packets to the host and expects them to be returned. This can be useful to deterimine the stability of your network connection to another host. Unfortunately, lots of sysadmins block ICMP packets at their firewall (using iptables or otherwise.) This practice is probably controversial.

The reason I don't like to use the ping utility to test if I can connect to a particular host is that, in the "real world" you will encounter hosts that have ports open but ICMP is blocked.

tl;dr: It's easy to test connectivity without using the unreliable ping utility. I'll show you how.

Telnet

telnet might be available on the system and you should be able to test ports using it. Here's an example:

$ telnet 192.168.1.1 80 Trying 192.168.1.1... Connected to 192.168.1.1. Escape character is '^]'. ^CConnection closed by foreign host.

Hint: Break out of telnet using CTRL+C

Netcat

The netcat package varies depending on the type of system you're on. Although, all versions of netcat can be used to test connectivity, some might have different command line options. For example, on a BSD system, you'll probably have a BSD compiled version or maybe OpenBSD netcat man page. On Linux you might have GNU netcat or nmap netcat.

You can use netcat just like telnet. I recommend using the -v (verbose flag,) at least, as its available on all netcat versions:

$ nc -v 192.168.1.1 80 pfsense.localdomain [192.168.1.1] 80 (http) open $ ncat -v 192.168.1.1 80 Ncat: Version 7.40 ( https://nmap.org/ncat ) Ncat: Connected to 192.168.1.1:80. ^C

Bash

A lot of the time your sysadmin might not have installed netcat or telnet because they can potentially be used for fun by an attacker if he/she ever gains access to a system.

There are some interesting bash built-in commands, one of which is /dev/tcp/. Use /dev/tcp if nc and telnet are not available:

# test results for an open port $ timeout 1 bash -c 'cat /dev/tcp/192.168.1.1/80' && echo success || echo failure success # test results for a closed port $ timeout 1 bash -c 'cat /dev/tcp/192.168.1.1/123' && echo success || echo failure failure

Nmap

Sometimes you are the sysadmin of a system (If only temporarily... ;))! If so, Congrats! In this case, install nmap on the system and have a lot of fun.

If you have access to install packages using the package manager, or if gcc and gmake are installed on the system), you're golden!

Here's a basic example of a connectivity test using nmap:

$ nmap 192.168.1.1 -p 80 Starting Nmap 7.40 ( https://nmap.org ) at 2017-04-30 17:03 CDT Nmap scan report for pfsense.localdomain (192.168.1.1) Host is up (0.00044s latency). PORT STATE SERVICE 80/tcp open http Nmap done: 1 IP address (1 host up) scanned in 0.10 seconds

Looking back at my site slowfruit.net over the past weekend has really left a bad taste in my mouth.

Holy snap, I never realized that 2014 me was an idiot.

I kind of want to resurrect that website in a more modern format that relies more on cloud technologies, actual testing/development environments, as well as a sane deployment process.

The first thing I need to do is take backup of the server. Now depending on the type of infrastructure you're using you might be able to do this from your web host's UI.

Luckily, this machine was setup to take regular backups of itself using a tool I wrote back in 2015 callled royal_bk. The bash script will output gzipped "tarballs" inside directories with dates.

Bringing backups to the present

If I were doing this again, I probably would not write a backup script myself. There are plenty of backup scripts that already exist. Also, I would definitely make sure that my backups were regularly shipped offsite AND tested.

A new backup strategy is something to consider as I resurrect this old project.

I'm making this up as I go along. Here are some ideas I have for future posts:

Build a development environment using vagrant and ansible

How to write infrastructure into the cloud using terraform

Deploy ansible configuration to your new infrastructure

Iterate on your site with ease using your previously setup development environment

Modern offsite backups with testing

So I have a Ubuntu 16.04 LTS machine and I wanted to configure L2TP/IPSec VPN on it.

It turns out the package networkmanager-strongswan had* a bug in it that made it not show up in the GUI.

Like many things software related, this was patched [1] in a new version but not backported (to LTS -- as of yet). The only Ubuntu version with this fix (for now) included in the repos is Zesty Zapus (Ugh, ubuntu).

In the past I've created franken Debian boxes with packages from sid, and/or testing repos. I wanted to see if I could do this in Ubuntu too.

It turns out you can! After following the directions in [3], I was able to install a single package from Zesty Zapus's universal repo. [4]

Here are the exact changes I made:

# cat /etc/apt/preferences Package: * Pin: release a=zesty Pin-Priority: 50 # cat /etc/apt/sources.list.d/zesty.list deb http://us.archive.ubuntu.com/ubuntu/ zesty universe deb-src http://us.archive.ubuntu.com/ubuntu/ zesty universe # apt-get -t zesty install network-manager-strongswan

1: https://wiki.strongswan.org/issues/1429

2: https://launchpad.net/ubuntu/+source/network-manager-strongswan

3: https://linuxaria.com/howto/how-to-install-a-single-package-from-debian-sid-or-debian-testing

I use a few privacy protecting Firefox extensions and the websites that I normally visit work fine. Unfortunately, sometimes a web site comes along that doesn't appreciate one of my favorite privacy extensions: Canvas Blocker, No Script, Better Privacy, HTTPS Everywhere, Request Policy Continued, and/or Cookie Time.

Rather than try and debug the issue, I normally will use an Chromium Incognito shortcut to access the site. This is great, except Chromium doesn't have flash player. I could just install regular Chrome, but I'd rather not deal with having Chromium and Chrome installed at the same time.

One website that I couldn't get working recently is Spotify. It has worked in the past and I'm sure I could get it to work with my privacy extensions again, but I'm too lazy to debug it! I just want to listen to music!

Instead, I wrote this bash script that creates a new blank Firefox profile on launch and (as long its still running when you close the browser) deletes the profile from the disk as well as from profiles.ini.

https://gist.github.com/sahal/e21c7b8e2fba2a27350d

git clone https://gist.github.com/e21c7b8e2fba2a27350d.git cd e21c7b8e2fba2a27350d chmod +x tempprof.sh ./tempprof.sh

I wanted to transfer some files to my phone using bluetooth today. I usually keep bluetooth disabled for security and battery reasons on my Chromebook running Arch Linux.

I can never remember the name of the bluetooth service or how to enable/disable it using systemd's systemctl. So, I just wrote a quick toggle-bluetooth alias for my ~/.bashrc

alias toggle-bluetooth='if ! systemctl status bluetooth.service ; then systemctl start bluetooth.service; else systemctl stop bluetooth.service; fi '

Of course, you might need to prepend sudo depending on your sudoer settings. But you should generally be able to toggle bluetooth like so:

source .bashrc # to bring in the new aliasses from ~/.bashrc toggle-bluetooth

About a year ago Demian provided us a list of whois servers for a bunch of new gTLDs. That list can be directly imported into /etc/whois.conf.

What if you need to add new whois servers? Unfortunately, he didn't provide us with the source code he used to generate his whois.conf. Fortunately, this superuser.com post lists a method to find whois servers for any gTLD.

To find the whois server for the .club gTLD, type this in your shell:

whois .club -h whois.iana.org| grep whois\:| sed -e s/whois\:\\s*//

That got me thinking that there has to be a better way to add whois servers than editing /etc/whois.conf. It looks like the whois command (on Debian and Ubuntu -- maybe others) can be set to use an environmental variable WHOIS_SERVER. I just wrote this quick bash script to automatically find whois servers when they're not listed in /etc/whois.conf.

Check out my new script ./whois-test.sh

Now, just add this as an alias in your .bashrc file for the whois command:

alias whois="$HOME/path/to/whois-test.sh "$1""

You should be able to query whois servers in the future for gTLDs that do not exist yet. If the iana decides sometime in the future that .fartsalot is a new gTLD you should potentally be able to run the following.

whois donaldtrump.fartsalot

The whois command would, hopefully, return the correct whois data after querying the correct whois server.

UPDATE: As of October 17, 2015, I can no longer recommend running your WRT54G as a repeater bridge. It fails just as often as when I was using it for a NAT router (i.e. at least daily). Get some new hardware folks!

So, I decommissioned our WRT54Gv5.x about a year ago and replaced it with a pfSense box, a Cisco wireless card, and a netgear switch. I love my pfSense box.

Unlike the WRT54G running DDWRT, the new pfSense box doesn't need to be restarted every day. In fact, it has a 152 day uptime at the moment. Actually, the pfSense machine isn't a new box at all, its an old PC that wasn't being used. Because the pfSense machine is an old PC, I have 64 times more ram than our old WRT54G, hundreds of GBs of space for logs, and plenty of processing power. I'm planning on building a new router machine that uses less power, and actually has gigabit ethernet, but for now almost everything working really well.

The one issue that I'm facing is that the wireless card that I bought doesn't have much of a range. Without the WRT54G, I don't have dual antennas that are easy to point in different directions. I looked into some ubiquity devices but I'd rather not spend any money extending my wireless network until my router is rebuilt.

Phishing as a service is an intersting concept that CuttlePhish provides for US$20. It allows anyone to send emails pretending to be from various services including Github, AWS, Heroku, Twitter, Facebook, and Rackspace. These emails will request various information from the victim (e.g. reset password, enable two factor authentication). Luckily, CuttlePhish isn't actually collecting passwords, instead it only alerts you if the victim(s) clicked on the links.

Reddit comments indicate that some companies are testing their employees with similar fake phishing emails.

In The Past

Check out some of the other articles I've written about the subject:

Part 1: Questions that you should ask yourself

Part 2: Questions to ask your web host

In Part 3

Today, I'm going to go over the different types of web hosts and suggest a few that I've used.

The types of web hosts, or web hosting plans, that I’m going to go over are:

Cloud,

Shared,

Dedicated/ Co-located,

and Content Distribution Networks (or CDNs).

Cloud Hosting

In the past few years, cloud providers have garnered a lot of attention. They operate on a “pay for what you use” and “easy to upgrade” model, which makes them very attractive to small and big businesses alike.

A web host that offers cloud hosting has many servers with a lot of processing power, disk space, memory, and high speed internet links. These servers (and their resources) are then split up and sold to customers. If the cloud provider is good at allocating resources and adequately loading the server then this can be a great affordable choice.

Types of Cloud Hosting Providers

There are two tiers of cloud providers. On the first tier there's Amazon’s AWS service (and Rackspace's OpenStack,) which is by far the biggest and most well known cloud provider. The other tier includes all the remaining cloud providers.

Amazon AWS and Rackspace OpenStack are excellent web hosts and offer great Service Level Agreements. Unfortunately, they can become expensive.

The other tier commonly offer what are known as Virtual Private Servers (or VPSes, VPSs.) The software that runs these cloud providers is open source and easy to deploy so there is a lot of competition. Two of the most popular types of VPSes you will see sold are Xen and OpenVZ. There are a lot of differences between Xen and OpenVZ, but for this article you only need to know that it is easier to oversell OpenVZ containers, and because of that they’re generally more affordable.

Pros:

Affordable

Easy to upgrade when you need more resources (e.g. memory, disk space, processing power, bandwidth)

Cons:

Can be oversold (i.e. more users are allocated than can be comfortably supported by the host server,)

Are not usually managed,

Requires advanced knowledge of the underlying operating system (usually Linux).

Recommendations

I recomend looking at Low End Box for affordable web hosting deals on Cloud Servers or Virutal Private Servers. I use Digital Ocean for most of my web hosting needs. Digital Ocean offers VPSes starting at US$5/Month.

Shared Hosting

Just as in cloud hosting, in shared hosting a web host is essentially sharing a very powerful computer among its clients. The way that this sharing is done, however, is different and leads to overselling on a greater scale.

Cons:

You will run across some issues with this type of web host if they offer plans that are “too good to be true.” Even though every resource (e.g. memory, disk space, processing power, bandwidth) will be sold as “unlimited,” these types of web hosts will most probably not live up to your expectations.

Pros:

Why then would anyone, let alone most websites, choose to use shared hosting? One reason, is that it’s by far the most affordable option in web hosting. They also require very little know-how, offer one-click installs of popular software (e.g. Wordpress,) and are usually managed (meaning that the web hosts makes sure that all software is up-to-date, deals with outages, and acts as support -- kinda like your in-house IT person.)

Recommendations

I recommend NearlyFreeSpeech, which works great for static sites and only charges for resources (e.g. memory, disk space, processing power, bandwidth) that are actually used. Unfortunately, they do not offer a free support line, and do not offer one-click installs of popular software, like WordPress.

Also, check out the Web Hosting Talk forums, where you can learn a lot more about web hosting, in general, as well as check out advertisements for services offered by web hosts, in particular.

Dedicated and Colocated Servers

Prior to the advent of cloud hosting, dedicated and co-located web hosting was very popular for large enterprises. Both dedicated and colocated hosting options offer a fully customizable experience, like cloud hosting. Unlike cloud hosting, with these options the customer retains full control over server hardware. Therefore, the server is not shared with anyone.

One of the main differences between dedicated and co-located hosting is that with dedicated hosting the customer will usually lease a server along with paying for bandwidth. With co-located hosting, however, the customer usually sends the web host (via snail mail/ other means) a server of their own and pays to rent units in a server rack (e.g. 1U, 2U, etc.)

Pros:

The main benefit of these types of web hosts is the fact that customers retain full control over their servers.

Cons:

Of course, the customer would need a lot of knowledge (or hire someone with a lot of knowledge) on setting up and deploying all software as well as all hardware related to the server.

Also, because these servers are paid for upfront (or rented) from the web host, they will be more expensive than other alternatives listed in this article.

Recommendation

If you chose to go this route, I suggest you call local web hosting providers in your area.

Content Distribution Networks

A Content Distribution Network (or CDN,) is not a web host, per se. Instead, it's an additional service that you might choose to purchase.

A CDN basically provides a mirror of your website that is geographically distributed. This helps reduce load on your web server and speeds up delivery of content.

Pros:

Usually results in a faster website - I'm sure none of your users wants to wait for your site to load,

Protection from malicious users through behavioral analysis over the CDN providers entire client base,

Distributed Denial of Service (DDoS) protection - a very common attack that can criple your web site / web hosting provider,

Obscurity - nobody knows who your true web host is,

Greater potential reach - usually a CDN will mirror your website all around the world resulting in faster load times.

Cons:

Depending on the size of your site, number of users, types of content you're sending to the CDN it can be really expensive

Recommendations

Recently, I've been using Cloudflare's free tier and not only is it easy to set up, it works very well, and has lots of great stats on the types of malicious content it has protected me from.

Conclusion

I just finished finalizing my backup script, which is written in Bash. It helps you create tarball (gzipped) backups of your Linux boxen.

Some of the unique features include:

Portability: ability to specify files to backup or exclude using a CSV *

Customization: getopts support allows you to specify parameters independent of hard coded values

Security: Allows you to chown the backup directory to an arbitrary user/group after the backups have completed

Safe: I used "set -e" at the top so the script quits when any statement returns a non-true value

Reputation Management: Stops your co-workers from laughing at you if you accidently back up "/" without excluding "/mnt/", "/media/", "/run/", or "/proc/"! +

Check out the source at royal_bk at Github! It's licensed under a MIT License so feel free to do with it what you wish.

royal_bk.sh

The CSV format I use is pretty easy to understand:

All lines that begin with a hash or "#" are ignored

Uses semicolons ";" as delimiters

The first column specifies the archive name

The second column specifies the directory name to back up

The third column (and any column following it) specifies a directory or file to exclude from the backup

If you specify a directory, include the trailing slash (but not an asterisk)

The script automagically creates a CSV with some defaults on the first run. This file is named "to-backup" and is stored in the same directory that the script is stored in.

Here's what the default to-backup CSV looks like:

# backup csv with semicolon delimters # home directories home.tar.gz;/home/;/home/kropotkin/;/home/aspies/;/home/sacco/;/home/bakunin/ # root backups #root_home.tar.gz;/root/ #etc.tar.gz;/etc/

On first launch the script will back up the "/home/" directory as home.tar.gz inside the $backup/$prefix$d directory. It will exclude the following users's home directories: kropotkin, aspies, sacco, and bakunin.

If you need help, consult the built in documentation:

# ./royal_bk.sh -h

trim_bk.sh

royak_bk also comes with trim_bk.sh, which I wrote about earlier this month. trim_bk.sh generates a list of backups that you can delete manually. This is useful if/when you decide to roll backups in the future.

Your Opinions

I'm always looking to improve my skill set. Please let me know what you think of this script, other scripts, or anything I write about via tumblr or by using the contact information in my portfoilo: sahal.info.

Also, feel free to file bug reports directly on the Github Repo for royal_bk.

Notes

* This script is not portable in the sense that you can use it with any version of tar. This script is written to be used with GNU tar specifically on Linux boxes. YMMV with other unixes or implementations of tar (or Windows).

In Part 1 of this series (Questions about your website and users) we discussed the different types of websites (e.g. dynamic, static,) and the important questions to ask yourself for each particular type of website.

Now that you know a little about your website's needs, let's discuss questions you might want to either ask a potential web host or, at the very least, look up on their website prior to purchasing a plan.

Today, we will be discussing two things in particular: Service Level Agreements (SLAs) and upgrading.

Service Level Agreements (SLA)

A Service Level Agreement, or SLA, is an agreement between a web host and a customer that details the service (a web hosting plan) being purchased from the service provider (or web host.)

SLAs describe the services to be delivered, legal compliance, as well as customer duties and responsibilities (and more.) For more information check out this archive of a great 2011 article by Mary E. Shacklett titled Five Key points for Every SLA

The most important things in a SLA, from a customer's perspective (i.e. yours,) is whether or not uptime is guaranteed as well as whether or not there are any guarantees with regard to how quickly any issues will be resolved.

You might be shocked to find out that many web hosts do not have a service level agreement in place! That means that if your website goes down, for a reason beyond your control, you have no recourse. You are at the mercy of your web host.

Now, if you're running a personal blog this might not be a big issue... if you're prepared. But are you prepared? Ask yourself these questions:

How quickly can you have your web site up on a different provider?

Do you have backups?

Where is your DNS hosted?

If it's at your web host then you might have to move it

How long is the TTL (Time to Live)? - This will determine how long it'll take for DNS to transfer to your new provider

If you don't have the answers to these questions (at hand) you might be screwed. Don't worry, I will cover the answers in another blog post at a later date.

If, however, your web host has a SLA in place, you have a legally binding agreement that will force them to act as quickly as possible to get your site back up. Otherwise, they might get sued. If not by you, then by one of their other customers.

How easily do you want to be able to upgrade your plan?

Upgrade paths are important for any website.

Let's face it, most websites are probably not going to be going viral any time soon. If your content does "go viral," though, you might have to deal with the "reddit hug of death," or being "Slashdotted." This occurs when a website cannot handle the traffic that is being sent to it, so it crashes.

Even if you're not producing content that is likely to go viral you will have to deal with upgrades eventually. If you produce content at a steady pace, you can assume that your users will probably also increase at a steady pace too. Hopefully, anyway.

You will want to know how quickly you can upgrade your website before you need to.

Fortunately, unlike with SLAs, most web hosts will make it easy for you to upgrade to a more robust web hosting plan fairly easily. That's because the easier it is for you to upgrade the easier web hosts can get money from your wallet into theirs.

UPDATE: 2015-02-14: The following script now keeps one backup per day during the current week, one backup per week during the current month, and one backup per month during the current year. All other backup directories are marked for deletion.

Do you keep backups?

You definitely should start backing up your website ASAP because you never know if and when you might lose everything!

I've been using a backup script for the past year. Since I'm using Linux (Debian,) I use cron to run my backup script daily by placing a symlink to it in /etc/cron.daily/. Just remember NOT to use any periods in your symlink name because of the way run-parts works in Debian. Don't ask me how long it took me to figure that out.

I might release my backup script for critique later, but today I wanted to share my new backup trimming (or pruning) script that helps me find dusty old backups that should be marked for deletion.

trimbackups.sh

Up 'till now, I had been manually deleting old backup directories. Although this got boring fast, I didn't want to spend time figuring out how to automagically trim (or prune) the redundant directories. Today, I finally got around to it!

The script might be a little rough around the edges, but it works! All I need to set is the $backup and $prefix variables in lines 26 and 27, respectively.

After it runs, the script spits out a file "to-delete" in the $backup directory. I can then manually delete each one after verification. I did this rather than automagically deleting the old directories because I wanted to be extra safe. I don't want to delete critical backups by accident.

Anyway, feel free to check out the script from my gist repository for trimbackups.sh on Github. I might add it to my main Github after I clean up my actual backup script.

Use trimbackups.sh

git clone https://gist.github.com/76c699f0c9a596db1677.git cd 76c699f0c9a596db1677 chmod +x trimbackups.sh

Next, you'll want to edit line 26 and 27 in trimbackups.sh to point to your $backup directory and $prefix, respectively. And finally run the script:

./trimbackups.sh

Yeet! You'll now see a list of your backup directories along with human readable dates for each. If a directory is followed by a mark (e.g., *, **, ., x) then it is marked for deletion. (See section titled "Logic" below for more information.

$ ./trimbackups.sh ./backups_201502121257: Feb 12, 2015 12:57 ./backups_201502121256: Feb 12, 2015 12:56 * ./backups_201501300607: Jan 30, 2015 06:07 ./backups_201501300137: Jan 30, 2015 01:37 **

You can find a list of directories marked for deletion in a file named "to-delete" in your $backup directory.

Optionally, you can run the script with the prompt flag. This prompts you for each backup directory.

$ ./trimbackups.sh prompt ./backups_201502121257: Feb 12, 2015 12:57 ./backups_201502121256: Feb 12, 2015 12:56 * ./backups_201501300607: Jan 30, 2015 06:07 ./backups_201501300137: Jan 30, 2015 01:37 ** ************************************************************* ./backups_201502121257: Feb 12, 2015 12:57 -- delete? 1) Yes 2) No #?

As you can see, this option forces the user to make a decision on each directory after displaying all the directories.

Again, like in the non-interactive mode, this saves a list of directories MARKED for deletion in a file called "to-delete" in the $backup directory.

Logic

The script checks each prefixed directory (with $prefix) in the $backup directory and marks one for deletion if it is:

older than 365 days (with an "x")

from the current month

and from current week

but not the most recent daily backup ("*")

and from the current week

but not the most recent backup for that week (".")

not from the current month

but not the most recent backup for that month ("**")

Todo

I still need to:

... So I read this instead: Don't Call Yourself A Programmer.

Why is an old post (Oct 2011) still seemingly relevant today? Simple.

Lots of Quotables

"Software often solves business problems despite being soul-crushingly boring and of minimal technical complexity."

"Producing beautiful software is not a goal. Solving complex technical problems is not a goal. Writing bug-free code is not a goal. Using sexy programming languages is not a goal. Add revenue. Reduce costs. Those are your only goals."

"...describe yourself by what you have accomplished for previously employers vis-a-vis increasing revenues or reducing costs. If you have not had the opportunity to do this yet, describe things which suggest you have the ability to increase revenue or reduce costs, or ideas to do so."

"...He’s now an angel investor (a polite synonym for 'rich')."

"...you probably are good enough to work at that company you think you’re not good enough for. They hire better mortals, but they still hire mortals."

"Most jobs are never available publicly, just like most worthwhile candidates are not available publicly (see here). Information about the position travels at approximately the speed of beer, sometimes lubricated by email. "

"...people routinely assume that I am among the best programmers they know entirely because a) there exists observable evidence that I can program and b) I write and speak really, really well."

"... If I were a Marxist academic or a conspiracy theorist, I might think that this bit of middle class American culture was specifically engineered to be in the interests of employers and against the interests of employees."

Are you ready to set up your own website? Don't have any idea on how to select a webhost? This is the first in a three part series about how to select a web host. The following questions will help determine what type of hosting will fit your needs.

What kind of website do you have?

Web sites are not unique snowflakes, rather they usually fit into one of the following categories:

A few pages

WordPress/ Blog

High Traffic / Shopping/ Ecommerce

Sometimes, you'll hear the terms "Dynamic" or "Static," when refering to websites. A static website is one that only serves HTML pages. A dynamic website requires support for a dynamic programming language (like PHP) as well as databases. If you need to install Wordpress, you'll need to purchase a plan with support for PHP and MySQL.

Takeaway: Each type of website requires different considerations. Remember that you can most probably change your plan if your needs change!

How many users do you serve a month/concurrently?

A lot of web hosts offer unlimited plans but just keep the following in mind:

More users per month => more bandwidth required

More users concurrently => more ram required

Takeaway: bandwidth, data, ram is cheaper than it has been in the past but it is not free and any web host that offers "unlimited" plans is trying to pull wool over your eyes.

How are your users geographically distributed?

Remember:

Network Latency increases as geographic area increases.

In other words your web site will seem slower if its being served from a server in San Francisco if most of your users are in Toronto.

Takeaway: If your users are geographically diverse consider using a Content Distribution Network as well as a web host.

Part 2: Questions to ask your web host

The next step is to ask your potential web host a few questions to see whether or not they meet your needs.

I wrote this piece titled 9 Simple Ways to Defeat Filternets recently. Here's a tl;dr for tumblr.

You can bypass internet filtering in a myriad of ways but sometimes the most simple methods are the best.

use https

web caching services - like archive.org

machine translation online - like translate.google.com

rss aggregators - like feedly

open wifi points - at starbucks

cell networks

alternative URLs - check if the website has a mobile interface that isn't blocked

(re)formatting services - convert a webpage to pdf or take a screenshot of a website

Have you ever tried to access the web through email? It's possible! Recently, I wrote this piece on Email Gateways Advantages and Disadvantages for slowfruit.net.

So, I had my first ever programming interview today.

Actually, the interviewer caught me off guard a few days ago when (s)he emailed me about a profile I posted on a job website. (S)he said that my profile was impressive and even mentioned a project (s)he worked on that was similar to one of my own. It was hard to believe this was legit especially since the recruiter claimed to have had a PhD in computer science from a prestigious institution. After I thoroughly researched the company, I decided to to agree to an initial phone interview. I like to think that I'm pretty good with people and as long as I get the opportunity to impress people I will. Well, I must've said something right, 'cause I was scheduled for a round two (of three) interview today.

I didn't get any sleep last night.

This second interview was a phone coding session and it was really an eye opener. I gotta say that I'm pretty embarrassed to admit that I didn't know how little I knew until I was tested today. The programming question (YES, I ONLY GOT TO ONE, Lol) posed was very simple and it made me realize that I still need training wheels (i.e. Google) to accomplish even the simplest tasks.

Despite the fact that I failed, my interviewer was really nice and even said that I could contact him or her for advice later on. (S)he said that unlike other entry level profiles on that job website, I had both back-end and front-end experience. We decided that I needed to write more code.

It's true. I need to write more code. Of course, I decided that the best thing to do was to try to get some code into a big project... like Firefox!

So, I quickly found a page on how to begin contributing code to Firefox and it turns out the first thing you needed to do is get the source code. Duh! Ok, so far so good, right?

"I can do this," I thought, "I know how to use git."

It turns out Mozilla uses Mercurial. "Okay, No Problem! I'll just install Mercurial from the Arch Linux repos and it'll be all right, right?"

Ah yes, hg clone https://hg.mozilla.org/mozilla-central only took about forever to complete.

Next, I have to install the development tools/tool chain. Unfortunately, it turns out that Mozilla's boostrap.py does not support Arch. Okay. That's easy, what could be complicated about building a web browser? I really just need to install gcc, right?

Wrong. It turns out that I needed to enable the multilib repo in Arch, because I'm running 64bit and Firefox uses gcc-multilib to create 64bit and 32bit binaries. Okay, that's pretty straight forward. I just need to uncomment two lines in /etc/pacman.conf.

Hmm, why isn't it letting me install these 32bit libraries? Oops, I forgot to update the repo caches in pacman (pacman -Syy). Finally after a longer amount of time than I care to admit, I'm done! w00t, time to find some bugs to squash...

Oh wait, what's this? If I want to work on B2G I need to install an older version of gcc?! Wait, what's B2G? [1] Hmm, no time for research! I KNOW how to install software from the AUR, I'll use yaourt.

Eventually, yaourt failed to compile gcc for some reason or another. That's when I began to realize that maybe contributing code to Firefox isn't something I'm ready for quite yet. There are too many hurdles I have to cross before I can even begin squashing bugs. For example, setting up the build environment itself is about a four hour endeavor. Not to mention that Firefox is mostly written in C++, which I've never written or even looked at.

I really need to find a set of exercises to test/increase my knowledge of languages that I've already used and languages that I want to learn. Maybe I should start with Learn Python the Hard way as so many on /r/learnprogramming have suggested.