I’m setting up an experimental standalone server for Ludum Dare’s static content.
Archive for July, 2015
KVM Server Setup Notes – Ubuntu 14.04 LARP (Redis)
Thursday, July 23rd, 2015OpenVZ Server Setup Notes – Ubuntu 14.04 LAMP (w/o M)
Friday, July 3rd, 2015For a side project, I’m using cheap server from these guys:
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.
Git Notes on SSH Keys
Friday, July 3rd, 2015Dealing 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.
1 |
ls -al ~/.ssh |
The default names are “id_rsa
” and “id_rsa.pub
“.
To generate a key, use ssh-keygen
:
1 |
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:
1 2 3 |
cd ~/.ssh mkdir backup cp id_rsa* backup |
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.
1 |
sudo apt-get install xclip |
SSH Keys need to be copied exactly, so xclip handles your clipboard for you.
Copy your Public Key with this command:
1 |
xclip -sel clip < ~/.ssh/id_rsa.pub |
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:
1 |
git remote -v |
- 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.
1 |
git clone git@github.com:povrazor/dairybox.git |
Since you probably didn’t do that, here’s how we can change the remote:
1 |
git remote set-url origin git@github.com:povrazor/dairybox.git |
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:
1 |
ssh-agent bash |
Then to add the SSH key.
1 |
ssh-add ~/.ssh/id_rsa |
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.
1 2 3 4 5 6 7 8 |
Host github.com HostName github.com User git IdentityFile ~/.ssh/id_rsa Host bitbucket.org HostName bitbucket.org User git IdentityFile ~/.ssh/id_rsa |
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:
1 2 3 4 |
Host github-custom HostName github.com User git IdentityFile ~/.ssh/id_rsa_customkey |
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.
1 |
git clone git@github-custom:povrazor/dairybox.git |
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:
1 2 3 4 5 |
sudo chmod 600 ~/.ssh/id_rsa sudo chmod 644 ~/.ssh/id_rsa.pub sudo chmod 644 ~/.ssh/known_hosts sudo chmod 664 ~/.ssh/config sudo chmod 700 ~/.ssh |
Details: http://www.howtogeek.com/168119/fixing-warning-unprotected-private-key-file-on-linux/
Git Notes on Combining Repositories
Friday, July 3rd, 2015Just 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
1 2 3 4 |
cd path/to/project-b git remote add project-a path/to/project-a git fetch project-a git merge project-a/master # or whichever branch you want to merge |
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:
1 |
git push --set-upstream origin master |
(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.
1 2 3 |
git checkout --ours -- <paths> # or git checkout --theirs -- <paths> |
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
1 2 |
git checkout --orphan NEW_BRANCH_NAME git rm -rf . |
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.
1 2 |
git revert --no-commit 0766c053..HEAD git commit |
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.
1 |
git checkout path/to/file/to/revert |
Source: http://stackoverflow.com/a/52713
For ‘all unstaged files’ (everything??).
1 |
git checkout -- . |
*shrug*