Hi Alex,

Unfortunately, I don’t seem to have the root password to that system, just Rob’s password … so I can’t actually make these changes for you at the moment. But you were on the right track & identified the problem:

When you have multiple domains being served up by a web server, you need to tell the web server process about it. The web server needs to be able to map each domain name to a separate directory of files.

In the case of alexandrasamuel.com, we’re running the nginx webserver.

/PATH/nginx/PATH/ is a folder that contains a repository of web server configurations for sites you may potentially serve up.

If you look in /PATH/nginx/PATH, there is a “default” and an “alexandrasamuel.com” file. You’d want to copy “alexandrasamuel.com” to a new file, ie: alexlov.es – and then edit that new file & replace all instances of the old domain with your new one – and make sure that the document root & log file directories exist (ie: /PATH/PATH/alexlov.es/htdocs and /PATH/PATH/alexlov.es/logs). You’ll also want to make sure that the ownerships are correct – the www-data user needs to be able to write to the logs directory.

Once that’s done, you need to tell nginx that it really does need to serve up that domain. That’s done by creating a symbolic link (aka an alias) to your newly created alexlov.es config file. Nginx looks for this info in /PATH/nginx/PATH/

So, you’d do something like this:

ln -s /PATH/nginx/PATH/alexlov.es /PATH/nginx/PATH/alexlov.es

and once that’s done, you restart the web server:

/PATH/PATH/nginx restart

Note that these steps would be the same if you were running Apache as opposed to nginx – just some of the directory locations would change (/PATH/apache2 instead of /PATH/nginx). If you want to switch back to Apache we could probably do that as well. You may want to think about doing that. Yourls is designed to work with Apache, although it can work with nginx as well, according to this:

http://foolrulez.org/blog/2009/08/foolz-us-make-yourls-work-on-nginx/

I just realized something though – the /PATH/nginx/PATH/alexandrasamuel.com file is set up to serve WordPress documents – copying it & using it to run Yourls may or may not work well. Your new alexlov.es config file might need to be tweaked a bit (see link above).

Finally, re: the Yourls configuration:

From what I can see, the Yourls files would be uploaded to /PATH/PATH/alexlov.es/PATH/ -> that’s the document root directory that your web server would serve content from.

As for the database table prefix, you can make it anything you want. Why? The thought behind having configurable table prefixes is so that you don’t experience conflicts if you run multiple applications out of a single MySQL database. Some hosting providers only give their customers 1 database. If you had two web applications (say WordPress and Drupal) and wanted to run them out of the same database, you’d run into trouble as both have a table named “users”. But if you give the tables a unique prefix, like wp_ and drupal_, then your wp_users and drupal_users tables would never conflict.

In your case however, you run our own virtual server. You can give yourself a separate database for every application. So it doesn’t really matter what you set the table prefix to. Go ahead and use yourls_ if you’d like.

Hope that brain dump helps. If you want me to give you a hand with the actual config/setup, let me know.

UPDATE: I edited this email to replace some key information (wherever you see “PATH”) because Mike points out there is no reason to give people (i.e. hackers) a roadmap to my server setup. Another great example of pro-active tech support done right.

Good tech support is the grease that keeps the wheels of the Internet running smoothly. If you know where to get help, or better yet, know how to help yourself, your tech experiences are likely to be positive and satisfying. If you don’t know how to troubleshoot, or feel belittled when you ask for help, you’re going to have a hard time enjoying or using computers and the Internet. And when you are able to offer help as well as receive it, you discover the appreciation and generosity that represent the very best of Internet culture.

At its best, tech support can catalyze those aha! moments in which technology mastery becomes a catalyst for increasing your confidence and your sense of agency in the world. At its worst, tech support can leave you as baffled as if you were reading Greek without an Ibycus.