For a side project, I’m using cheap server from these guys:

http://buyvm.net/

I’ve decided that since it’s for development, I’d rather use Apache instead of NgineX. NgineX is much better than Apache when it comes to memory usage and performance, but Apache is a little easier to organize thanks to .htaccess files. And since Ludum Dare runs and will continue to run Apache for a while, I’ve decided to make my life working on both projects a little simpler.

For my reference, the following are my setup notes for the server.

(more…)

Dealing with SSH keys is confusing. Every machine you run should have a unique SSH key.

SSH keys typically consist of 2 files:

• id_rsa – Your Private Key. Used ONLY on your local machine.
• id_rsa.pub – Your Public Key. Give it to others (pub for public).

NEVER SHARE THE PRIVATE KEY!

The names themselves don’t matter, so feel free to rename them. It’s what the files contain that’s important.

If you ever lose or have a key compromised, generate a new one. As long as we are using them for version control, they are perfectly disposable. Don’t forget to delete old keys from your GitHub and Bitbucket accounts!

---

Steps with ** typically only ever need to be done once per computer.

Step 1: Generating an SSH key **

Once you’ve generated a key, it can be used for multiple services (GitHub, Bitbucket, etc).

You can check if you have any keys installed by looking in the ~/.ssh directory.

The default names are “id_rsa” and “id_rsa.pub“.

To generate a key, use ssh-keygen:

I’ll be keeping the default names (~/.ssh/id_rsa and ~/.ssh/id_rsa.pub).

By default, when you set a pass-phrase, you will be prompted for it every time you access the remote repository. Phrases are strongly recommended, because security. However, this behaviour can be changed (see Appendix A and B).

Source: https://help.github.com/articles/generating-ssh-keys/

Step 1b: Backup your Keys! (optional) **

This isn’t necessary, but now would be a good time to backup your keys.

Ideally you should have some real and proper way to backup your keys, but here’s my lazy way:

You’ll always be using the originals (~/.ssh/id_rsa), but in case you accidentally overwrite them, you have a copy in the /backup folder.

Step 2: Install Public Key on your services **

If you haven’t already, install xclip.

SSH Keys need to be copied exactly, so xclip handles your clipboard for you.

Copy your Public Key with this command:

Your clipboard will now contain your Public SSH key.

Next, go add the Public SSH Key to your accounts. Do this by pasting the clipboard in to the box provided.

For GitHub, you can find it under Settings/SSH Keys.

For details, see Step 4: https://help.github.com/articles/generating-ssh-keys/

For Bitbucket, you can find it under Manage Account/SSH Keys.

For details, see Step 6: https://confluence.atlassian.com/display/BITBUCKET/Set+up+SSH+for+Git

Give the keys added to your accounts good names, something about the computer they belong to. That way it’s easier to know what machines they belong to if you ever need to generate new ones.

Step 3. Change remote’s from HTTPS to SSH

To login using your SSH key, you need to change the remote from an HTTPS URL to an SSH URI.

To check your remote’s, run the following command to list them:

• HTTPS URLs typically begin with https://
• SSH URIs typically begin with [email protected] (the user), and use a colon : to separate HOST and PATH, not a slash

On GitHub, to find out your repository SSH URI, click SSH below the clone URL box.

On Bitbucket, click the drop-down box beside the URI to change it.

Once you’ve configured the SSH keys, you should always check-out using SSH URIs instead of HTTPS.

Since you probably didn’t do that, here’s how we can change the remote:

Adjust the code above accordingly if you used Bitbucket instead of GitHub.

Source: https://help.github.com/articles/changing-a-remote-s-url/

Step 4. Done…?

That’s actually it, assuming we don’t mind punching in our pass-phrase every time.

We do mind though.

Appendix A: ssh-agent (i.e. the temporary solution)

If we want to create a temporary shell that will remember the pass-phrase, use this command:

Then to add the SSH key.

Again, this is only temporary. When you invoke exit, the pass-phrase will be forgotten.

Depending on the Linux configuration, doing ssh-add outside the ssh-agent shell may actually remember the pass-phrase permanently. But if you’re like me, running current Ubuntu’s, that wont cut it anymore.

Source: http://askubuntu.com/a/362287/364657

Appendix B: SSH config (i.e. the permanent solution)

If it doesn’t already exist, create a file ~/.ssh/config

Add these lines to the file.

Now REBOOT.

The first time you attempt to SSH to either website (i.e. any time you “git push” or “git pull“), you’ll be prompted for your pass-phrase. After entering it once, you shouldn’t have to enter it again until you reboot.

Source: http://stackoverflow.com/a/4246809, http://nerderati.com/2011/03/17/simplify-your-life-with-an-ssh-config-file/

Appendix C: SSH config explained

The Host line in the SSH config is actually a unique name given to an SSH host. SSH will do a pattern match against what you have listed in your config as Hosts. The Host is not necessarily the host name, which we override using the HostName command (in fact, we’re also overriding the User name here).

If you were to add a section like this:

then you can specify a different SSH key to be used. In this case, I’m assuming I have an additional key pair named “id_rsa_customkey” and “id_rsa_customkey.pub“. I would have to add the Public Key to my GitHub account to use it.

To use the custom host, I would have to modify my URI.

Notice that my URI is github-custom and not github.com.

The original SSH URIs work correctly because we specifically gave them the same Host as as the HostName. Trickery. 🙂

Appendix D: Permissions

In case your permissions get messed up, the default settings for Ubuntu 14.04 are:

Details: http://www.howtogeek.com/168119/fixing-warning-unprotected-private-key-file-on-linux/

Just some notes. Recently, I had to merge and organize 3 repositories as one, so here are the things I ended up doing.

Merging 2 repositories in to one with full history

In my case, the local repository (source) was project-a, and the public repository (destination) was project-b.

When I was finished merging, instead of git push -u I had to push it like so:

(where master was the branch I was targeting)

Source: http://stackoverflow.com/a/10548919

Accepting all merged changes

After doing the above, my repository was filled with conflicts. I didn’t care about the the remote changes, so I was able to just blanket accept my local changes.

In the above context, project-b (destination) is --ours, and project-a is --theirs. I used --theirs, as I wanted my local repository merged in to the public one.

Source: http://stackoverflow.com/a/16826016

Adding an empty branch

Now add/commit any change to keep it.

Source: http://bitflop.com/tutorials/how-to-create-a-new-and-empty-branch-in-git.html

Adding Multiple Origins

I haven’t done this yet, but eventually I’ll need to push code in to two separate repositories on demand.

Details: http://stackoverflow.com/a/11690868

Reverting a commit

Say you make a bad commit. You can revert the changes like so.

Source: http://stackoverflow.com/a/21718540

Just look-up the version ID of the commit you want instead, and edit it in to the above command.

Discarding changes

To discard a change, re-checkout the file.

Source: http://stackoverflow.com/a/52713

For ‘all unstaged files’ (everything??).

*shrug*