GizmoLA.com

You created a new ssh key, but are you actually testing it?

I routinely have to create new ssh keys for system users and also verify that they are working correctly. One possible area of confusion is how ssh keys are found by the ssh client.

While most of this information is not specific to osx, since I typically use a macbook running osx, I'll cover a couple of things somewhat specific to osx.

SSH clients will typically default to searching for a private key that exists in the user's home directory in a subdirectory named ".ssh"

So let's assume that you create an ssh key for a new user, utilizing ssh-keygen



Should you omit the -N parameter above you will be prompted for a passphrase. In either case, you should use passphrases in almost all situations to protect your system from lost or stolen private keys!!!

So if all goes well, you will now have a new public/private ssh key pair.

On the remote system, you will typically add the public key (id_newuser.pub in this example) to the .ssh/authorized_keys file.

While not the point of this article, you will also need to understand the permission requirements of the user's home .ssh directory and files. Make sure the directory and files are private to the user, or ssh connections will fail.

Time to test

Continue reading "Testing new ssh keys"

So a few years ago I wrote this article about setting a custom shell prompt that is "Git aware" and shows you your current branch.

The question came up as to whether or not this works on a Mac under OS/X.

I have always advocated avoiding things like WAMP or MAMP because I don't like a bunch of services running on my workstation. I prefer using virtualization to run a *nix distro matching whatever target deployment server I'm going to run under. VMWare, Virtualbox etc. along with the popularity of Vagrant and Docker have tremendous advantages over something like MAMP in my experience. You start the environment when you need it, and stop it when you don't, and there's no problem having 5 different VM's with different stacks and php versions.

For this reason, I have never been all that concerned with setting a git aware shell prompt up on my macbook. But as it's a *nix-like operating system, it has the basics you need to make the shell prompt code work, albeit with 2 required tweaks.

First you have to edit the /etc/profile script so that it will look for and read scripts in an /etc/profile.d directory. sudo vi, nano or whatever you want to edit the /etc/profile script and add this at the bottom:



This is simple bourne shell code to read in scripts in the /etc/profile.d directory when you login to a shell. It is a system-wide script, so when you change this, you change it for all users on the system.

Now you just have to create the /etc/profile.d directory.



Once this is done, you can use the same simple method described in the original article.

I was cleaning up a directory of old files for addition to git, and I came across a bunch of symlinks to a completely different codebase. In this particular case it was a wordpress blog that had a series of its files linked into the webroot of the site, that existed in an entirely different directory. I didn't want these files in the git repo.

Finding all the symlink files is easy enough.



The find command gives us an easy way to get all symlink files:



But that's just a start -- we have to get these into the .gitignore file. Continue reading "How I found symbolic links for gitignore with find and cut"

At some point I found some code to get the git branch name and insert it into the shell prompt. As it was some years ago, sadly I've forgotten the original source, but it wasn't exactly the type of prompt I'm used to, so I tweaked it until I got it the way I prefer. In the first set of brackets, I display the user@host:directory.

Once I cd into a git initialized directory a colored prompt appears with the branch name displayed in gold. For my purposes, this is simple, functional and doesn't result in overly long prompts. Here's what you can expect from any terminal that supports ansi color codes.



To implement the prompt on your server or workstation, simply cut this snippet and paste it into the end of the /etc/bashrc file.

The current way to do this is to create a new file named "gitprompt.sh" in the /etc/profile.d directory, and paste the code below into it. Using vim is a good way to accomplish this task. You need to be root or sudo for this to work of course.

Once the file exists, all the system users will benefit from the prompt in their shell sessions.

Using this prompt, whenever you're in your bash shell, there will be no question of whether or not you are in a git initialized directory, or what your currently checked out branch name is.



Does this work on a Mac? Yes of course!

When I setup a new Centos or Amazon Linux server, one of the first tasks I want to accomplish is installing postfix. There used to be a package named system-switch-mail that made this easy to do from the shell. If you've tried to yum install this package recently you might have been surprised to find that it has disappeared. Instead there is a tool that lets you do essentailly the same thing which is part of the chkconfig package.


For this to work you need to have the chkconfig package installed:



If you don't see it, then yum install chkconfig!

With chkconfig installed you have access to the alternatives system. Of course to be able to switch your mta you first have to install your sendmail alternative. In my case it's typically:




Now you can switch your system to use postfix as the default MTA!



Choose Postfix and hit enter and you're done. Don't forget to remove sendmail, as you no longer need it.

I like Amazon Linux. It is basically Centos with a bit of Fedora mixed in. Thus it comes with yum, and even better yet, with amazon supported repositories preconfigured. Because amazon provides it, they support it, and answer questions about it, and fix problems with it and keep it up to date and patched so that it runs well as a paravirtualized guest inside Amazon's Xen based infrastructure. They insure that it's fairly secure, has a fairly minimal set of installed packages, and comes with the ec2 api tools already installed, which can be a daunting task to setup for people new to aws and ec2.

However one thing they don't do by default is configure their AMI's to make the ephemeral storage you are entitled to available by default. When you boot up an instance, you find yourself with a 10 GB EBS volume, and that can become pretty filled once you've installed a few packages.

What is Ephemeral storage?
Ephemeral storage is the "instance storage" that's advertised for each instance type and can range from 150 GB on up to over a terabyte depending on the instance type you're running. This storage is called "Ephemeral" by Amazon because it comes from the local hard drives in the server your instance is running on, but does not persist or survive an instance stop. If you put anything important on it, you'll need to back that data up using traditional means, and won't have the ability to snapshot it like you can with EBS volumes. Although ephemeral drives can provide excellent IO performance and a substantial storage at no extra cost, they are subject to the types of failures that you'd expect with single server disks.

In spite of these concerns, they certainly are a great place for things like temporary files, or swap files, or logs that you're going to rotate or purge anyways.

So how can you use Amazon Linux and still get access to the ephemeral disks?

You need to utilize the Amazon API and use the "-b" parameter to map one or more block devices to your ephemeral storage. Although the web interface "Launch Instance" wizard includes a tab for storage options, the instance storage tab is not accessible. I typically use the command line api to start aws instances.

For example, this command will launch a large instance based on an Amazon Linux AMI, only, while at the same time adding back mappings to the ephemeral storage that is part of the Large instance profile.



The important parameters to note, are the two "-b" parameters, which specify that ec2 should establish block device mappings to our two ephemeral drives.

When your instance starts, you'll find that you now have a formated ext3 volume ready for use:

/dev/xvdb 414G 199M 393G 1% /media/ephemeral0

You might have noticed that we specified a mapping for 2 different block devices. You'll find that /dev/sdc is configured, but you'll have to format it and mount it yourself.

If this is the first time you've seen the command line api used, amazon linux is a great way to get started. Just start up a micro instance using the recommended Amazon Linux AMI, add your certs, and you're ready to go.

In summary, Amazon Linux is an excellent choice for your EBS backed instances -- just remember that unless you override the default, you'll be missing out on the Instance storage you're paying for!