The lone entrepreneur

Thoughts, stories and ideas from a lone entrepreneur.

[theloneentrepreneur]

Get real IP from HTTP request headers

This is a small snippet needed to work with a small elixir package I’ve coded some months ago called FreeGeoIP.

I’ve used this package to get the web visitor country and city origin in a phoenix framework web application:

def get_country_code(conn) do ip = Enum.into(conn.req_headers, %{})["x-forwarded-for"] || conn.remote_ip case FreeGeoIP.Search.search(ip) do {:ok, %{"country_code" => code}} -> code {:error, _} -> nil end end

[theloneentrepreneur]

Get free HTTPS certificates for your own domains with Let’s Encrypt

Let’s Encrypt is a free, automated, and open Certificate Authority.

This is big news (not so new, but big anyway). This is like you can read, you can have your own fully supported SSL certificates to power up your domains with HTTPS instead HTTP!

Not to mention the big benefits of having your websites served with HTTPS instead HTTP, higher security, better thrust from your users, benefits on SEO ranks, etc.

You can have more info on Let's Encrypt website https://letsencrypt.org/

Installation

Based on your system this may vary, this example is based on Ubuntu 14.04 system:

$ sudo apt-get install git bc $ sudo git clone https://github.com/letsencrypt/letsencrypt /opt/letsencrypt

Create certificates

Before creating the certificates you will need to have correctly configured your domain DNS to point to your server where the certificates will be installed.

Now you need now to stop any service listening on port 443 (nginx in my case):

$ sudo service nginx stop

I normally use standalone certificates, I find them more manageable:

$ cd /opt/letsencrypt $ ./letsencrypt-auto certonly --standalone -d yourdomain.com

Now a text window will appear showing the generation process.

If there was errors on the process, they are usually caused by not being able to connect to your domain IP on 443 port, so make sure you have internet access to your domain pointing to the correct IP and 443 port.

If all went fine, you now will have your new certificate files located at:

/etc/letsencrypt/live/yourdomain.com/*.pem

Redirecting from/to HTTPS domain urls

You might need to get another SSL certificate for some subdomains. For example if you want to redirect users from https://www.yourdomain.com to https://yourdomain.com you will need to create another certificate:

$ ./letsencrypt-auto certonly --standalone -d www.yourdomain.com

This way the user will not be warned about any missing SSL certificates or other similar warnings on the browser when entering https://www.yourdomain.com

Autorenew certificates

This certificates have 3-month period validity, so you will be responsible of renewing the certificates. With this small script you can renew it automatically:

Put this in any location you want, for example in ~/letsencrypt-renew.sh

#!/bin/sh echo "Renewing certificates..." service nginx stop /opt/letsencrypt/letsencrypt-auto renew -nvv --standalone > /var/log/letsencrypt/renew.log 2>&1 LE_STATUS=$? service nginx start echo "Done" if [ "$LE_STATUS" != 0 ]; then echo Automated renewal failed: cat /var/log/letsencrypt/renew.log exit 1 fi

Now just put this line at the end of your crontab for running each day for example:

0 3 * * * /home/<user>/letsencrypt-renew.sh

And that's all. Easy isn't it?

Update

As you can see, nginx should be stopped before renewing certs. Let's add a new way to renew certificates without stopping webservers.

Follow steps in https://github.com/kappataumu/letsencrypt-cloudflare-hook

Work in progress...

[theloneentrepreneur]

13 tips for entrepreneurs

From Paul Graham blog

Pick good cofounders.

Launch fast.

Let your idea evolve.

Understand your users.

Better to make a few users love you than a lot ambivalent.

Offer surprisingly good customer service.

You make what you measure.

Spend little.

Get ramen profitable.

Avoid distractions.

Don't get demoralized.

Don't give up.

Deals fall through.

[theloneentrepreneur]

How to generate high security SSH keys

In linux environments the SSH related user keys, config, etc. are normally stored in the ~/.ssh directory.

There you can find some files:

config: this file contains some aliases and other configuration options. You can set an alias to your server and once setup, you will be able to login that server with simply ssh {server_alias} (nice!).

authorized_keys: this file is normally stored on servers, is where the public keys of authorized users (or other servers) are. If your key is not included in this server file, when you SSH the server, it will ask you for a conventional user/password login.

{keyname}.pub files: this is a PUBLIC KEY, this is the only file you must share when authenticating, or uploading to a system who used SSH for authentication

{keyname} files. Normally is the same name as the above with without the .pub. This is your PRIVATE KEY, do not share or upload it anywhere, protect with the most restrictive file premissions possible (500).

Generate your own SSH key

Open a linux terminal and create a .ssh directory if it doesn't exist yet:

mkdir ~/.ssh cd ~/.ssh

You can now just do a ssh-keygen command to get your key, but lest do with the most secure mode at this moment:

ssh-keygen -t ed25519

Now you have a pair of keys, default names should be id_ed25519 (private) and id_ed25519.pub (public).

For detailed info about using ed25519 encryption you can visit this nice article from Sven Vermeulen

Note: this type of encryption may be incompatible with some websites or old servers. In case of problems, just generate your keys just with ssh-keygen command.

[theloneentrepreneur]

How to contribute to open source

I think contibuting to the open source community is the most rewarding action you can do as a developer. Several years thinking I couldn't post anything important or useful, one day just crossed the line and made my first pull request.

Don't think so much, if you can give back some of your work, (even small patches) to the open source community, just do it!

How?

This are the steps I follow using git and Github. There are other source version control software and other repository sites out there, so this of course will vary on those.

Let's start:

Create a Github account (if needed of course)

Generate your SSH key and upload it to github

Navigate to the repository you want to contribute

Fork into your account

Clone your account recently in your local machine

So you will work on your machine and onto your forked copy of the repository.

Add a new origin called, for example, upstream with the original repository (not the forked one)

git remote add upstream https://github.com/{author_name}/{repo_name}

This is needed to syncing the original repo with your forked copy

Now if you are contributing a small patch or is a low activity repo, you can commit directly in the master branch. If not is the case, just create a new feature branch and work there. This will help the original author of the repository when merging with the master branch.

git checkout -b {your_feature_branch_name}

Work in your locally cloned repo, on master or your feature_branch

Don't forget to add tests and ensure all is working properly!

Once your work is done, before commiting your work to origin, lets check if the original repository master branch has been updated while we were working on local.

git fetch upstream master

Here you can do a rebase (only if you havn't uploaded any commit yet)

git rebase upstream master

Or if you already uploaded something just do a pull:

git pull upstream master

Update your code if needed, resolve conflicts, pass tests, etc.

Push your commits

git push origin master

or if you are working on a feature branch

git push origin {your_feature_branch_name}

Go to your Github repo and make a pull request against the branch you were working on, normally master. Put a description of your work as detailed as you can to making the life easier to the original repository author.

Tips

Make small commits one for each logical group changes in the code.

Give commits small and descriptive messages.

As said before, create a branch if there is a major upgrade over the original repo.

If make sense, use Travis CI

Push code as clean as possible, order and orgnaize your commits in a logical way before uploading.

Rebase only if the code not uploaded, after that, just merge updates with pull.

Continuing your work after some time

Maybe you commited some changes to one project, and after some months you will want to push new changes. Simply update your local repo with the latest changes:

git pull upstream master

Then resolve conflics if any (if your old work was finally merged you may not have any conflict), work as usual into your local code and then follow the steps above to make another pull request.

Why not resetting or deleting local repo? Sure you can do a fresh start deleting and forking again your repo, or simply doing a git reset --hard upstream master but please don't do that because your cloned repository is public and may be already being used by someone.