Categories
Site Technology

Starting up the Blog Again

Hey everyone – I know that very few people are following this, but I wanted to let you all know that I'm going to be posting with a weekly cadence starting again now.

The posts will be almost entirely tech-related, since that's what I do now. I've got a couple of posts in the pipeline already, I just need to flesh them out and provide good examples.

I may throw in a photography-related post once in awhile, since that's one of my biggest hobbies, and I have a lot of fun with it.

Anyway, I just wanted to get this out there publicly so that I will be forced to be more accountable to it.

Categories
Automation Site Technology

HTTPS for free with Let’s Encrypt

If you’re anything like me, you’ve probably wanted to add HTTPS to your personal sites or apps, without having to shell out the money to get a certificate from a certificate authority. Of course, self-signed certificates were always an option, but it really kind of sucked to have to always either bypass warnings or install the certificate everywhere. Oh, that and the fact that my Android phone would warn me every time I booted that someone could be eavesdropping on me.

For that reason, I haven’t ever used an SSL certificate on my sites, except for the occasional self-signed cert. Luckily, finally, Let’s Encrypt has come along to save the day (well, they’ve just entered public beta). They’re an automated and free certificate authority, and they make getting a certificate a breeze. Heck, if you have a matching configuration, the whole process is already automated.

Installing Let’s Encrypt

Installation is super easy – the official (and almost assuredly up-to-date) instructions can be found on the Let’s Encrypt website, but it’s definitely quite simple. In most cases, the easiest method is to clone the letsencrypt repository from github:

git clone https://github.com/letsencrypt/letsencrypt
cd letsencrypt

You can see if it’s available via your distro’s package manager and install it that way, too. I haven’t found it in either yum or apt-get yet, so your mileage may vary.

Getting a certificate

If you happen to be running a supported configuration (as of right now, just Apache running on Debian or Ubuntu), then you can let it take care of all the dirty work for you: ./letsencrypt-auto --apache (though probably with sudo). That should take care of everything for you. I haven’t tried it personally, but I’d imagine it’s pretty sweet. If you try it and it works, then you can feel free to skip the rest of this article, because it probably won’t help you much.

Otherwise, you’ll want to go the certonly route to obtain your certificates. It’s still super easy, and the configuration itself isn’t super difficult.

To obtain your certificate, first ensure that your DNS A record is pointing to the correct server. If you don’t, well, then this certainly isn’t going to work.

Webserver Considerations

In order for Let’s Encrypt to verify that the DNS record in fact points to the server that you’re using, it needs to temporarily place a file in your webroot. This allows it to prove that you really do have control over the DNS records for that domain. You can do this one of two ways:

  1. By specifying the --webroot flag when you run letsencrypt
  2. By temporarily stopping your web server so that letsencrypt can spin up its own

Depending on your site’s configuration, one may be easier (or less disruptive) than the other. In my case, the servers I’ve configured thus far haven’t had an easily accessible webroot, so I just shutdown my webserver (sudo systemctl stop nginx.service in my case, on CentOS 7) while I obtained the certificate.

Get Your Certificate

Once you’ve taken care of that, run ./letsencrypt-auto certonly -d example.com to obtain a certificate for your domain. Or, if you’re using the webroot flag, execute ./letsencrypt-auto certonly --webroot -w /var/www/example / -d example.com without shutting down your webserver. For more details, see the ‘How it works’ page on Let’s Encrypt’s site.

Your certificate files will be placed in /etc/letsencrypt/live/example.com/ (naturally, replacing example.com with your address).

Configuring your webserver

I’ve gradually been configuring a new server with Ansible (which is a whole story in itself), and in the process, I’ve switched over to using Nginx as the primary web server with a reverse proxy setup to direct other requests where necessary. As a result, my direct experience with Let’s Encrypt is limited to Nginx, but I know it’s similar with Apache or whatever else you might be using.

For me, setting up https for my sites just involved the following:

  1. Adding a redirect from the insecure HTTP site to the HTTPS site
  2. Adding a second directive in the server configuration for port 443
  3. Enabling SSL on that configuration
  4. Specifying the location of the certificate files

In Nginx, the redirect looks like this:

server {
    listen 0.0.0.0:80;
    server_name example.com;
    server_tokens off;
    return 301 https://$server_name$request_uri;
}

This tells Nginx to listen on port 80 for requests to example.com, then return a 301 code saying that the requested resource has moved permanently to the same address, but with https:// instead of http://.

In similar fashion, configuring the SSL portion of the site is quite simple, and goes something like this:

server {
    listen 0.0.0.0:443 ssl;

    server_name example.com;
    server_tokens off;

    ssl on;
    ssl_certificate /etc/letsencrypt/live/example.com/cert.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    root /var/www/example;
}

If you’re using Apache, you’ll probably need to use another one of the certificate files, but I’m not entirely sure which at this point. However, if you need more info about that, I’d recommend checking out Apache’s documentation on SSL.

Final Notes

There are a few more considerations with these certificates. Though they’re supported by all major browsers, which is awesome, there are a few places that are lacking – for example, I’ve noticed that GitHub’s web hooks don’t realize that the certificates are valid. It seems like this might be something related to OpenSSL, but I haven’t had time to investigate it yet.

Also, these certificates expire after 90 days, so they need to be refreshed fairly often. However, since obtaining the certificates is so easy and it’d be super easy to script, it’s something that you could easily add as a cron job. It’s what I’m planning to do in the near future.

Hopefully this was helpful. Feel free to chime in if you’ve got any questions or comments!

Categories
Life Site

A Refresh

I was going to title this post A New Beginning, but then I realized that all beginnings are really new, aren’t they? It just seemed a bit repetitive. That said, I’m writing this to inform you of my intention to update this blog on a more regular basis. Initially, I intend to write at least once a month, perhaps increasing that to once a week soon thereafter.

I’ve also realized that, since this is my personal blog, I shouldn’t restrict what I post here to just one topic. While I don’t intend to just write about my life, I also shouldn’t just make this about technology.

So, I guess what I’m getting at is that I’ll be posting here more often, sometimes about tech discoveries or thoughts, sometimes about things that I’ve developed, and sometimes just about thoughts I have about random topics. After all, why restrict yourself to just one thing? We all have varied interests, and I want my space on the web to reflect that.

Categories
Automation Configuration Site Technology

Automatic Deployment with Gitolite

About Gitolite

About a year and a half ago, I came across a great open-source git repository management tool called Gitolite. It’s a great tool for hosting and managing git repositories. It worked especially well for me because I run my own web server where I could set it up. If you’d like to give it a try or read up on it, I suggest you visit the Gitolite documentation.

Why Automatic Deployment?

Now, having worked in web development for at least a few years, I wanted a simpler way to automatically deploy my sites. Ideally, this should use Git. I’ve become quite fond of Git, so I’ve been using it for all my projects lately. Before I even open a text editor to start a new project, I’ve usually already typed git init (or, as it is with Gitolite, git clone).

There’s something to be said for entering git push and having your commits reflected live on the web. It’s not something you want for every site, but it can certainly be useful when you want it.

Getting it Set Up

If you’ve managed to get Gitolite set up, you probably won’t have much trouble with getting the rest figured out. If you do happen to have some questions, I’ll do my best to answer them.

In order to set up your automatic deployment, you’ll need direct access to the gitolite account on your server. As a matter of fact, having root access would probably be helpful. Because unfortunately, the autodeployment isn’t something you can just set up using the gitolite-admin repository (for some very good security reasons, I might add). With that in mind, follow along with the steps below.

  1. Add your web server user and your gitolite user to the same group. While this probably isn’t strictly necessary, it’s what I decided to do to make it work. Mainly, you just need your web server to be able to properly access the files that your gitolite user will be checking out.

    In my case, I simply created a new group and added both users to that group using usermod (check out usermod’s man page for more info). However, as I said, you can handle this however you’d like to, especially if your UNIX knowledge surpasses mine (which certainly wouldn’t surprise me).

  2. Create your repository and deployment directory.

  3. Change your deployment directory to allow the gitolite user access. This will depend on exactly how you handled things in step 1, but if you followed my pattern, I’d suggest changing the group of the directory to the group you added in step 1. In case you aren’t completely familiar with how you do this, you can try chown user:group directory -R on your target directory (More info here).

  4. Add the following to your /home/{gitolite_user}/.gitolite/hooks/common/post-receive script:

    if [ "$GL_REPO" == "gitolite/path/to/repo" ]; 
        git --work-tree /path/to/webroot --git-dir ./ 
        find /path/to/webroot -type f -print | xargs chmod 664 
        find /path/to/webroot -type d -print | xargs chmod 775
    fi
    
  5. Modify the script (from above) as needed. Basically, this script will run any time a repo is pushed to the server. If the repo matches the path you put in, it’ll execute the script within the if statement. That simply checks the repo out to the directory you specify, then adjusts the permissions on the files and subdirectories. You can modify the script as needed, because your specific case may need some special treatment.

  6. Push to your repo!

Hopefully I’ve covered everything. If you try this tutorial and run into problems, let me know in the comments and I’ll do what I can to get you sorted out.

Categories
Site

Yet Another Site Redesign

Hey there! So, I know that I don’t really have any readers. However, I’m going to be increasing the frequency of my writing on the blog. Most of the information here will be related to my work and school, so it’ll be rather, well, technological in nature. I’ve got a couple of planned posts coming up that will relate specifically to site development and version control.

I’m also working (albeit slowly) on a new site design. I’ll be launching that in awhile, though that might take some time. Either way, there will be some changes coming. For those of you interested less in technology and more in what’s going on in my life, I’ve got some other news coming in regard to that, hopefully this weekend.

Categories
Design Life Site

My Portfolio

As you will have noticed, if you actually visit this site, I recently made some changes. If you follow this via a feed reader (such as Google Reader), you wouldn’t have. If that’s the case, I suggest you visit http://russ-taylor.com. There, you’ll see my new, updated portfolio.

Categories
Design Site

My Latest Project

I’ve finally come to a conclusion. Some of you know that I have, for a time, wanted to make another blog. One that’s not personal. One that could be of assistance to someone, more than just informing them of how my life is going. In light of that, I will soon be launching another blog. And I’m dang excited about it.

Web Application Development

I’m going to write this new blog about my efforts to create a custom web application. I know most of you that read this won’t be super-interested in that, but I realized that it could provide an interesting amount of insight to others who may be interested in similar things.

For the past year or so, I’ve been slowly working on developing a new web-based application for swim teams. You see, I’m a coach for a swim team, and the software that’s out there right now for team and meet management really isn’t so good.

Because I know that there are many people out there interested in developing their own web applications (once again, probably not most of you…) I realized that documenting my experiences may be helpful to others who pursue the same path. At least, I’m hoping they will be.

And so, pending the termination of finals, I will be starting work on the new site.

Categories
Life Site

Finally Launching the New Design

new-layoutI know that it’s been many months since I said that I was working on and getting close to implementing a redesign and restructuring of the site. Well, the day has finally come.

Categories
Site

The Importance of Themes

bloggingLately, I haven’t been posting much here. And believe me, there is a pretty decent reason for that. You see, lately I’ve realized that in order for a blog to have a following (and therefore make an difference, be it for better or worse), it must be focused on one subject or another. In my experience (which is far from perfect), people follow blogs, websites, etc. because they are interested in the content thereof.

When a blog randomly jumps from one subject to another, it becomes drastically less likely that a person will be interested in all content posted there. This means interesting things for bloggers, namely that they have to focus on one subject or another. If they ignore this, it’s very likely that the only people interested in that blogger’s site will be his or her immediate family and close friends. But this poses another problem: if a blogger focuses solely on other content, he risks alienating his family and friends that don’t share his precise interests.

I also stronly believe that is the precise reason why out of so many blogs, so few have a decent level of readership.

In order to be effective, a site must have interesting, thought-provoking articles. While many life experiences can provide that, they must be presented in a certain manner.

With the coming redesign of my site, I’m going to do my best to address some of those issues. I sincerely hope that it will work out well. If it doesn’t, my blog will simply remain a part of those with a low readership.

Categories
Reviews Site

GoDaddy.com: 1/10

Who wants to pay $90 to get applyclan.com back? Any volunteers? Because I know that I sure don’t. And guess whose fault it is? I’m blaming godaddy.

The reason that I am doing so mostly relates to Godaddy.com’s lovely assumption that no one would ever want to change services to someone else. I mean, why in the world would anyone ever rather use another registrar? The very thought is preposterous! Rather, so it seems to Godaddy.

They’ve made it awfully difficult to move a domain name registered through them to someone else. And that, my friends, is the reason that they now want me to pay $90 to get it back. But alas, I do not feel so inclined. And therefore, goodbye applyclan. That is, unless they release it to public registration soon. Then I will be able to register it again at a much more reasonable price – $8.95.

Let’s hope, shan’t we?