As a FreeSWITCH consultant, one of the things I do regularly is set up new environments for working with clients. Yesterday I decided it would be nice to automate the process of basic management for these installations, and the freeswitch-env script was born.
Here’s the basics:
Usage: freeswitch-env <install|uninstall|list> <env-name>
env-name: The name of the envelope to create. Will be appended to
'freeswitch-' to create the final envelope name
Install goes through the standard configure/make/install steps, plus handles installing the default sounds, music on hold, and config files. If configured, it will also set up an init script for starting/stopping the install (I’ve only tested this on Redhat, but others would probably work with minor tweaking).
The script is fairly configurable, allowing you to specify a custom source code location, base install path for environments, user to run FreeSWITCH as, etc.
It’s released as part of my new freeswitch-utils package, where I’ll be adding other handy scripts, etc. that I find useful when working with FreeSWITCH.
I run CentOS for my production servers, and generally like to manage my services via proper init scripts. Over the years I’ve run into situations where I couldn’t locate a decent init script for a service I want to deploy, and end up rolling my own. I’m no shell scripting wizard, but they work well for me; it seems like something worth sharing so others don’t have to reinvent the wheel.
Today, I went hunting for an init script that I could use to manage a NodeJS application, and while I found a Debian-based one, no Redhat-style one was forthcoming. I tweaked the Debian one I found to work on a Redhat-style system. The script below should work fine for any Redhat/Redhat clone server. You’ll need to take care of a few things after you get the script:
Install the forever package so it’s in your PATH, which is easily accomplished via npm install -g forever if you have NPM installed.
Edit the variables in the APPLICATION section to suit your needs.
Put the script into /etc/init.d and name it something meaningful, I go with node-[appname].
Make sure the it’s executable.
If you want to have it automagically start/stop on startup/shutdown, activate it with chkconfig, like chkconfig --add [scriptname].
Manage it manually via the service app, eg. service [scriptname] start.
This script should be reusable to run more than one node app, provided that:
The jQuery UI documentation for autocomplete doesn’t do the greatest job of clarifying how to override the select() and focus() methods. There is mention of ‘Cancelling this event’, but they only snuck in how to do the cancelling in the search() method. This led to considerable confusion on my part, where code like this:
Would lead to the maddening result of those changes being applied, then overwritten by the default behavior of the method.
The simple solution is to add a return false; to the end of your custom implementation:
This prevents the default code for the method from running.
Update 2015-01-19: I’ve updated this post to reflect the current version of Jekyll.
This site is built using Jekyll with Jekyll Bootstrap as a starting point. One of the nice things about hosting this kind of site on GitHub is that when you push updates, they trigger a rebuild of the Jekyll site, making for super easy deployment. For various reasons I decided that I didn’t want to host my site on Github, so I needed a way to have the same convenience on my own server.
The Jekyll Wiki and some other folks offer an approach that makes a copy of the checkout on the target server, then uses that for the rebuild, all triggered via the git post-receive hook. I like the basic idea, but it seemed cleaner and faster to me to just have a non-bare repository on the server and trigger the rebuild in place, which the script below accomplishes. I also like that I can rebuild the site very easily on the server if need be, by simply running jekyll build from the root of the working tree.
There are a couple of gotchas to this strategy, check out the CAVEATS comments in the script itself for details. And now, I’m going to make use of this sucker by pushing my post. :)
Welcome to the online blog for Chad Phillips (aka hunmonk). The inspiration for this blog came from a community hangout session and a spare Scrabble dictionary. Paging through, picking out random interesting words, the term xylil leapt right off the page, and I knew that some day (domain name gods willing), I’d have a blog site with this name. :)
I doubt I’ll be a frequent blogger; I’ll mostly aim for getting stuff up relating to technical work I’m doing that might not be easy to find elsewhere. I’m one of those people who seems to run into edge cases and exceptions, which result in headbanging, which will hopefully ultimately result in a post that means you won’t have to suffer as I did. ;)