Jeff Mikels

Ubuntu doesn’t provide the latest ffmpeg or include the modules I use all the time, so I wrote a little script to automatically compile and install my own version:

#!/bin/sh

# https://trac.ffmpeg.org/wiki/CompilationGuide/Ubuntu

# SERVER COMPILATION SKIPS ffplay AND A X11 DEPENDENCIES

echo 'THIS SCRIPT USES SUDO, SO IT MIGHT ASK FOR YOUR PASSWORD'
sudo apt-get update -qq

sudo apt-get -y install \
	autoconf \
	automake \
	build-essential \
	cmake \
	git \
	libass-dev \
	libfreetype6-dev \
	libtheora-dev \
	libtool \
	libvorbis-dev \
	mercurial \
	pkg-config \
	texinfo \
	wget \
	zlib1g-dev \
	yasm \
	libx264-dev \
	libvpx-dev \
	libfdk-aac-dev \
	libmp3lame-dev \
	libopus-dev



cd ~/src

# DO WE NEED NASM?
# wget http://www.nasm.us/pub/nasm/releasebuilds/2.13.02/nasm-2.13.02.tar.bz2
# tar xjvf nasm-2.13.02.tar.bz2
# pushd nasm-2.13.02
# ./autogen.sh
# PATH="$HOME/bin:$PATH" ./configure --prefix="/usr/local" --bindir="/usr/local/bin"
# make
# sudo make install


# DO WE NEED x265
if cd x265 2> /dev/null; then hg pull && hg update; else hg clone https://bitbucket.org/multicoreware/x265; fi
cd x265/build/linux
PATH="$HOME/bin:$PATH" cmake -G "Unix Makefiles" -DCMAKE_INSTALL_PREFIX="/usr/local/" -DENABLE_SHARED:bool=off ../../source
PATH="$HOME/bin:$PATH" make
sudo make install


# ACTUAL COMPILATION
cd ~/src
wget -O ffmpeg-snapshot.tar.bz2 https://ffmpeg.org/releases/ffmpeg-snapshot.tar.bz2
tar xjvf ffmpeg-snapshot.tar.bz2
cd ffmpeg

PATH="$HOME/bin:$PATH" PKG_CONFIG_PATH="/usr/local/lib/pkgconfig" ./configure \
  --prefix="/usr/local" \
  --pkg-config-flags="--static" \
  --extra-cflags="-I/usr/local/include" \
  --extra-ldflags="-L/usr/local/lib" \
  --extra-libs="-lpthread -lm" \
  --bindir="/usr/local/bin" \
  --enable-gpl \
  --enable-libass \
  --enable-libfdk-aac \
  --enable-libfreetype \
  --enable-libmp3lame \
  --enable-libopus \
  --enable-libtheora \
  --enable-libvorbis \
  --enable-libvpx \
  --enable-libx264 \
  --enable-libx265 \
  --enable-nonfree

make
sudo make install
hash -r

Published by: Jeff Mikels

After doing some research into how to develop a WordPress site in a “staging” area behind the scenes before going public, I have finally stumbled upon an elegant and simple solution:

• Using a plugin like simply-static, convert all wordpress-generated data to static html files.
• Tell nginx to try those files first (unless there is a logged-in user) falling back to the normal wordpress generation when they can’t be found.
• Now, public viewers will bypass wordpress entirely, grabbing all the static files while you happily do your coding in the background.
• When you are ready to go public with your modified design, either regenerate the static files for a super-fast site or delete the static files. Without the html files, nginx will simply hand the requests over to wordpress for dynamic generation.

Published by: Jeff Mikels

I use GNU Screen for everything I do in Linux… perhaps you do too, but perhaps you are annoyed that every time you log in to a terminal session on your Linux machine, you have to go through the one extra step of reconnecting to your screen session or checking to see if one is already running and then maybe creating a new session.

Here’s a way to make sure whenever you SSH into your Linux server, you always get right back where you were in your previous screen session just like you left it. The added bonus of this is that whenever you detach from your screen session, you are also automatically logged out of the server.

Simply add these lines to the bottom of your .bash_profile (watch out for word wrapping).

# start screen session if not already started
# or connect to screen session if not already in it
echo ''
echo '----------- WE LIKE SCREEN ------------------------------'
if [ ${TERM:0:6} != "screen" ]
then
    echo "Attempting to connect/create screen session."

    # We don't want to forcibly disconnect other sessions if they are
    # Attached, so we check for Detached sessions first
    HAVE_DETACHED=$(screen -list | grep Detached)
    HAVE_ATTACHED=$(screen -list | grep Attached)

    if [ -n "$HAVE_DETACHED" ]
    then
        echo "Attaching to existing screen session"
        exec screen -r

    elif [ -n "$HAVE_ATTACHED" ]
    then
        echo "Existing screen sessions are all attached"
        echo "use 'screen -rd' to detach and attach here."
    else
        echo "There are no running screen sessions."
        echo "Creating new screen session."
        exec screen
    fi
else
        echo "Already in a screen session. Cool."
fi

Published by: Jeff Mikels

Lafayette Community Church uses a couple different WordPress installations for its website.

• The first WordPress installation is the main website, and it is located at http://lafayettecc.org/news/.
• The second WordPress installation is for blogs and devotionals, and it is located at http://lafayettecc.org/blogs/.

I set it up so that users need log in only once, and their login persists across both sites. I didn’t need to use any plugins or LDAP or third party authentication systems for this.

Here’s what you need to do to make it work for your site as well:

• Both WordPress installations must be running on the same domain, even though they might reside in different subdirectories or different subdomains.
• Both installations must be running on the same database but with different table prefixes.
• If your secondary site already has users, you will need to do manual database updates, and that’s beyond the scope of this tutorial. The rest of this tutorial assumes you are okay with the fact that your secondary installation’s user table will be completely ignored and both installations will use the primary installation’s user table.
• Change the wp-config.php file on the secondary blog to tell WordPress which table to use for users.

define('CUSTOM_USER_TABLE', 'blog1_users');         // replace blog1 with the table prefix from your
define('CUSTOM_USER_META_TABLE', 'blog1_usermeta'); // main wordpress installation

• Change both wp-config.php files to unify the cookies across the two installations. I’ll go into more detail here.

Unifying Authentication Cookies across multiple WordPress Installations

WordPress uses two cookies to handle authentication, but there are a number of settings that need to be synchronized between installations so that WordPress can read and understand the cookies properly.

Authentication Keys

Your WordPress installations may or may not have custom authentication keys set up, but in order for this to work properly, you should have the same keys set up on each installation. In wp-config.php on BOTH sites, add these lines:

/**#@+
* Authentication Unique Keys and Salts.
*
* Change these to different unique phrases!
* You can generate these using the {@link https://api.wordpress.org/secret-key/1.1/salt/ WordPress.org secret-key service}
* You can change these at any point in time to invalidate all existing cookies. This will force all users to have to log in again.
*
* @since 2.6.0
*/
define('AUTH_KEY',         'custom-hash-here');
define('SECURE_AUTH_KEY',  'custom-hash-here');
define('LOGGED_IN_KEY',    'custom-hash-here');
define('NONCE_KEY',        'custom-hash-here');
define('AUTH_SALT',        'custom-hash-here');
define('SECURE_AUTH_SALT', 'custom-hash-here');
define('LOGGED_IN_SALT',   'custom-hash-here');
define('NONCE_SALT',       'custom-hash-here');

Of course, you want to replace “custom-hash-here” with different random strings, and of course, if you already have these values set in your wp-config.php files, you need to replace what’s currently there with these so that both sites are using the same exact settings.

Cookie Settings

Hash, Domain, and Path

When WordPress uses three defined constants when creating authentication cookies for the browser: COOKIEHASH, COOKIE_DOMAIN, and COOKIEPATH.

define('COOKIEHASH', 'custom-hash-here'); //define the hash
define('COOKIE_DOMAIN', '.example.org');  //remove the leading dot if you aren't using subdomains
define('COOKIEPATH', '/');                //this must be a parent directory to all WP installations

Again, these three settings must be exactly the same across your all installations, but there are additional concerns:

The COOKIE_DOMAIN and the COOKIEPATH must be parents of both installations. That means, if your installations are on separate subdomains, the COOKIE_DOMAIN must apply to both (a leading dot before the domain name will accomplish this), and if your installations are using separate subdirectories, your COOKIEPATH must be a parent to both. To be safe, you can make it ‘/’, but you actually want your cookies to be as specific as possible, so if one blog is in example.org/wordpress/blog1 and the other blog is in example.org/wordpress/blog2, you can use /wordpress as your COOKIEPATH, or if one blog is blog1.example.org/wordpress and the other is blog2.example.org/wordpress, you should also be able to use /wordpress as your COOKIEPATH.

Site and Admin

WordPress uses two defined constants to help it look for the right cookies to see if a user has been authenticated. One of those constants is SITECOOKIEPATH and it is used by the WordPress frontend. The other is ADMIN_COOKIE_PATH and it is used by the WordPress backend.

Simply set both of them to be the same as the COOKIEPATH and you should be fine.

define('SITECOOKIEPATH', COOKIEPATH);
define('ADMIN_COOKIE_PATH', COOKIEPATH);

Conclusion

So, for completeness, here are all the settings together:

In secondary wp-config.php files:

define('CUSTOM_USER_TABLE',      'blog1_users');    // replace blog1 with the table prefix from your
define('CUSTOM_USER_META_TABLE', 'blog1_usermeta'); // main wordpress installation

In all wp-config.php files

define('AUTH_KEY',           'custom-hash-here');
define('SECURE_AUTH_KEY',    'custom-hash-here');
define('LOGGED_IN_KEY',      'custom-hash-here');
define('NONCE_KEY',          'custom-hash-here');
define('AUTH_SALT',          'custom-hash-here');
define('SECURE_AUTH_SALT',   'custom-hash-here');
define('LOGGED_IN_SALT',     'custom-hash-here');
define('NONCE_SALT',         'custom-hash-here');
define('COOKIEHASH',         'custom-hash-here');
define('COOKIE_DOMAIN',      '.example.org');
define('COOKIEPATH',         '/');
define('SITECOOKIEPATH',     COOKIEPATH);
define( 'ADMIN_COOKIE_PATH', COOKIEPATH );

Post a comment if it doesn’t work for you.

Published by: Jeff Mikels