Tutorials
Showing 1 - 5 of 8 Results | Page 1 of 2 | 12 Next >
Enable Apache Rewrite For Your Wordpress or Modx CMS Site
02-Jul-10 10:55
Web applications often involve an .htaccess file with directives to rewrite URL's. Content Management Systems (CMS) like WordPress use rewrites to render pages optimized for SEO searches, using names like http://www.mysite.com/the-name-of-my-article.html. I use a different CMS, Modx. Like Wordpress, it provides a ready-made .htaccess file.
However, creating the .htaccess file in your web application's directory is only half the battle. You still have to configure your web server to allow URL rewrites. It's difficult to find concise instructions on these steps, because they vary with the server and the location of your application.
Activating Apache Rewrite
Fortunately, Apache2 is highly modular. You can reconfigure it to allow rewrites for your application by making a couple of quick changes. The following steps have been tested in Ubuntu 10.04. (If you are a shared hosting customer, Apache is probably already configured for you, and you can skip this section.)
1. Enable the rewrite module in Apache:
sudo a2enmod rewrite
2. Edit Apache's custom config file for your site. Unless you're running multiple/virtual sites from the same server, the file you're looking for is /etc/apache2/sites-available/default. If your web server allows access by SSL (https://), the file is default-ssl. Find the stanza for the top-level directory, which looks like this:
<Directory /var/www/>
Options Indexes FollowSymLinks MultiViews
AllowOverride None
Order allow,deny
allow from all
</Directory>
Note that the default setting is AllowOverride None. Below it, add some new lines to define an exception for the directory hosting your web application:
<Directory /var/www/modx>
AllowOverride All
</Directory>
3. Restart the web server:
sudo /etc/init.d/apache2 restart
Correcting Htaccess Mistakes
Should you still have problems, the issue could be in your .htaccess files. A common problem is that you installed your application in a directory different from the DocumentRoot (typically /var/www). For example, say you installed WordPress in /var/www/wp, but you want everyone who goes to your domain to be redirected there. You'll need two .htaccess files: one in the DocumentRoot; the other in your WordPresss subdirectory. First, in the root file, /var/www/.htaccess, you'd add the RewriteCond RewriteRule lines to rewrite requests by tacking on the "/wp" part:
RewriteCond %{HTTP_HOST} ^mydomain.com$ [OR]
RewriteCond %{HTTP_HOST} ^www.mydomain.com$
RewriteRule ^/?$ "http\:\/\/mydomain\.com\/wp" [R=301,L]
Then, in the subdirectory file /var/www/wp/.htaccess, you need a RewriteBase and other rules using that subdirectory:
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
Similarly, if you're using the Modx CMS, you'd create subdirectory /var/www/wp/.htaccess conditions and rules like the following
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ /modx/index.php?q=$1 [L,QSA]
Resources
- Ubuntu, Apache, and .htaccess (illustrates WordPress example)
- Giving WordPress its Own Directory (official Wordpress documentation)
- Modx official documentations for configuring friendly URL's
View comments for this article
Firefly: A Music Server For Mixed Marriages
12-Jun-10 12:40
For sharing your family's music collection, it's hard to beat the simplicity of the Firefly music server. It uses the DAAP protocol, allowing others to access it from iTunes or Rhythmbox. With Firefly, your spouse can happily use their Mac or Windows PC for playback while you do the same with Linux.
1. Get Firefly running on Debian/Ubuntu by installing a single package:
sudo apt-get install mt-daapd
2. Then edit the file /etc/mt-daapd.conf, changing these lines to define your password and the directory where you'll store your music:
admin_pw = mypassword mp3_dir = /home/paul/Music/MyCdRips
3. If your server is on another computer, copy or upload your music files to the directory you defined. My collection is all in MP3 format, and Firefly serves it flawlessly. The server should also be able to handle other formats (.mp3,.m4a,.m4p,.ogg,.flac,.mpc).
4. Restart the server:
sudo /etc/init.d/mt-daapd restart
5. Point your web browser to port 3689 (http://localhost:3689, if running on your local PC) to verify that the server is working. You should see a status screen like the one shown below. Click on the Configuration tab if you want to customize further. The defaults are probably adequate.
6. Connect from iTunes or Rhythmbox. In either application, your server will appear under the Shared directory.
For more information, visit the Firefly website and its forums.
View comments for this article
Installing a Local DNS Server Behind a Hardware Router
25-May-10 15:12
There's not much work to installing and using a typical hardware router. Just plug it in, attach cables from your non-wireless computers, and it will automatically connect them to the internet without any special configuration. That's because the out-of-the-box router/firewall acts as both a DHCP server and DNS relay. The DHCP server assigns a unique private IP address like "192.168.0.101" to each device on your local network (which is often called a "subnet", but here I'll call it the "LAN"); the DNS relay forwards requests for any internet address like "mail.google.com" to your ISP's nameserver(s) and receives back its answer -- the IP for that name -- which it passes in turn to your computer.
This hand-off works perfectly well as long as you only need to resolve names on the public internet. No special coniguration is necessary on either the router or its clients. Whether you're running Windows, OSX or Linux, your computer's default configuration will reach out to the DHCP server. The router will tell your computers to use its IP as the gateway for all traffic beyond your LAN, and also assign itself as the DNS. Your computer doesn't know or care that the router is just a middleman for the DNS requests.
The problems begin when you need to resolve names between the computers on your LAN. Say that you want to connect to another computer using VNC or another remote desktop, or one running a web server or SSH daemon. Unless you use the remote computer's exact IP address (e.g., "http://192.168.0.103", not "http://mywebserver.mydomain.net"), you won't succeed. That's because your router is designed to gets all its DNS information from your ISP's nameservers, through the cable or DSL modem connected to its WAN port. Your ISP's nameservers don't know anything about the computers connected to the router's LAN ports.
Static DNS to the Rescue
The solution is to set up a local DNS on one computer on the LAN, then configure the router with static DNS entries. The local DNS will be the primary nameserver; the secondary nameserver will be your ISP's DNS. We will disable DNS relay on the router. Once the process is complete, the flow of DNS requests will look like this:
The router will assign the DNS entries to the client computers, but after that it will not be involved in DNS requests. Regardless of which nameserver is used, all requests for addresses beyond your LAN/subnet will be forwarded to your ISP's DNS. The rest of this article explains how I did that using Debian/Ubuntu Linux on a home network. Although the nameserver installation steps are specific to Linux, the rest of the configuration should be similar regardless of which router or operating system you're using.
Before you begin, understand that this solution also depends on your computers having fixed IP addresses. You can ensure that your router's DHCP server always assigns the same IP number to a particular device by browsing to its admin screen and looking for a way to convert a currently dynamic lease into a fixed lease. You specify the hardware (MAC) address and couple it to an IP address.
Installing the DNS Server
In this example, my...
- local domain is "softpoint.int" (this is made-up, not a real registered domain); all IP addresses on this local subnet begin with 192.168.0
- personal computer is pauldev.softpoint.int, IP is 192.168.0.122
- computer on which the nameserver is installed is services.softpoint.int, IP is 192.168.0.139
- router's IP on the LAN is 192.168.0.1
- ISP's DNS is 66.90.139.210 (you can discover yours by checking the router's status page)
We're going to install the "bind" nameserver. My server runs Debian 5.0. The steps in Ubuntu should be almost identical. You could also install bind in a virtual machine, so long as that VM has a fixed IP and is visible to other computers on your network.
sudo apt-get install bind9
Next, we need to edit a number of files. Add these lines to the end of /etc/named.conf.local, replacing "softpoint.int" and "db.softpoint.int" with your own domain:
zone "softpoint.int" {
type master;
file "db.softpoint.int";
};
zone "0.168.192.in-addr.arpa" {
type master;
file "db.192.168.0";
Add these allow-recursion and forwarders sections near the bottom of /etc/named.conf.options, above the line beginning "auth-nxdomain". Replace "66.90.139.210" with your ISP's nameserver. Note that we are forwarding DNS requests direct to the ISP nameserver (66.90.139.210), not to the router (192.168.0.1):
allow-recursion {
localhost;
192.168.0.0/24;
};
forwarders {
66.90.139.210;
};
Change your current directory from /etc/bind to /var/cache/bind and create a pair of files there (unlike the ones in /etc/bind, these files don't yet exist). The first file to create is /var/cache/bind/db.softpoint.int. It does a lookup from a name to locate the IP address. Replace "softpoint.int" and "services" respectively with your domain and the machine running this nameserver. Enter the computers on your network below the line that begins "www".
$TTL 604800
@ IN SOA services.softpoint.int. admin.softpoint.int. (
2008080101 ;serial
04800 ;refresh
86400 ;retry
2419200 ;expire
604800 ;negative cache TTL
)
@ IN NS services.softpoint.int.
@ IN A 192.168.0.169
@ IN MX 10 services.softpoint.int.
services IN A 192.168.0.169
www IN CNAME main
router IN A 192.168.0.1
lanserv IN A 192.168.0.100
vonage IN A 192.168.0.102
pauldev IN A 192.168.0.122
mediawin IN A 192.168.0.123
The second file to create is /var/cache/bind/db.192.168.0. It does the reverse lookup, from IP number to name. Enter the computers below the line that reads "@ IN A 192.168.0.1":
$TTL 604800
@ IN SOA services.softpoint.int. admin.softpoint.int. (
2008080101 ;serial
604800 ;refresh
86400 ;retry
2419200 ;expire
604800 ;negative cache TTL
)
@ IN NS services.softpoint.int.
@ IN A 192.168.0.1
1 IN PTR router.softpoint.int.
100 IN PTR lanserv.softpoint.int.
102 IN PTR vonage.softpoint.int.
122 IN PTR pauldev.softpoint.int.
123 IN PTR mediawin.softpoint.int.
We're ready to restart the nameserver with this new configuration:
sudo /etc/init.d/bind9 restart
Before we change anything on the router, let's make sure that the new local nameserver is doing its job. On any computer (including the one on which you installed the nameserver), check the file /etc/resolv.conf. In Ubuntu, it should look like this, still using your router as its nameserver:
# Generated by NetworkManager domain grandenetworks.net search grandenetworks.net nameserver 192.168.0.1
Temporarily edit that file and replace the nameserver IP with that of your new local DNS server:
# Generated by NetworkManager domain grandenetworks.net search grandenetworks.net nameserver 192.168.0.139
Try a lookup of an internet domain:
dig google.com
Try a lookup of one of the hostnames you defined in your local domain:
dig mediawin.softpoint.int
If the lookups worked, the response you receive should contain an answer section reporting the IP for that domain or hostname, e.g.:
;; ANSWER SECTION: mediawin.softpoint.int. 604800 IN A 192.168.0.123
Don't skip over these tests. There's no point in messing with the router until both of these lookups pass. Othewise, you're likely to replace your working DNS setup with one that's worse.
Reconfiguring the Router
Browse through the admin pages for your router and find the one where you can manually edit the DNS addresses. These may currently be set as blanks or as "0.0.0.0", meaning they will be dynamically assigned by your ISP. Replace them with static IP numbers. For the Primary DNS address, use the IP of your local nameserver; for the Secondary DNS address, use the IP of your ISP's nameserver:
One more very important thing: we need to disable the router's DNS relay feature. On my router, this setting was on entirely different conguration screen. Also, as we'll soon see, it's worth entering the "Local Domain Name" you invented for your LAN.
Save the settings and allow the router time to reboot, if necessary.
We're ready to test name resolution once again. Instead of manually jury-rigging /etc/resolv.conf this time, we're going to check if our new router settings will enable our computer to auto-configure itself. Try restarting your network connection on your computer, or releasing and renewing your DHCP lease. In Windows, you can force this by the commands "ipconfig /release" and "ipconfig /renew". In Ubuntu, clicking on "Auto eth0" in the Network Manager icon of the top panel will take care of it.
Your /etc/resolv.conf file should now look like this (in Windows, "ipconfig /all" will show you your current DNS servers:
# Generated by NetworkManager domain softpoint.int search softpoint.int nameserver 192.168.0.139 nameserver 66.90.139.210
Note that the router passed on to us the two DNS servers we defined in it, and that the router itself is no longer a nameserver.
Try some more digs or pings or web browsing to confirm that your new configuration is working. You should also be able to connect to local computers without appending their domain names, e.g. "ping mediawin" should work just as well as "ping mediawin.softpoint.int".
Questions and Answers
Some readers may be puzzled by this setup, and wonder about other options.
1) Q: Most of my traffic is going to the public internet, so shouldn't my ISP's nameserver be the primary nameserver? A: No, because the first working nameserver our computer can contact will be used for the lookup, and your ISP's nameserver knows nothing about your private domain. It can only hand off lookups further upstream to more authoritative nameservers. The secondary DNS will be used only if the primary nameserver is unavailable. Thus, if you list your ISP's DNS first, the connection will succeed, but every lookup concerning a device on your LAN will fail. By putting your local DNS first, your local lookups will work. Also, you can shut down or take your local DNS server offline and still surf the web without interruption. In that case, your computer will fail to connect to it as the primary nameserver, so it will contact the secondary nameserver (your ISP's DNS) as a fallback.
2) Q: Wouldn't it be easier to avoid all this work and just use a local hosts file on each computer? A: Yes, if you have a very simple network with a couple of computers and don't mind manually configuring them for every operating system you boot. You can create an /etc/hosts file and add lines like:
192.168.0.1 router mediawin.softpoint.int 192.168.0.101 lanserver lanserv.softpoint.int 192.168.0.123 mediawin mediawin.softpoint.int
You'll have to remember, however, to update those individual files whenever you add a device to the LAN, or change its IP address.
3) Q: Do I need a local DNS server if I only want to share files and printers using Windows Networking (SMB, often called "Samba" in Linux)? A: No, you can find and connect to one another without installing a local DNS. Computers using the SMB protocol announce their availability by broadcasting themselves on the LAN. They don't need a nameserver.
View comments for this article
JIRA Part 1: Installation with Postgresql
07-Mar-10 17:20
JIRA is a mature issue tracking system with advanced workflow features. While there are free options for maintaining bug and feature lists, JIRA is practically free: its parent company offers a non-crippled 10-user version for only $10 (and donates the proceeds to charity). JIRA also provides free licenses to some open source projects.
I use the the Netbeans development platform, which has a JIRA plugin that lets you manage your list within the IDE. The plugin officially supports the JIRA 3.x series, not the latest JIRA release 4. Therefore, this how-to addresses installation of JIRA 3.13 on a Debian 5.x (Lenny) server and assumes you've already downloaded JIRA . Aside from the repositories, the steps are the same in Ubuntu.
Get Java
Edit your repository list (/etc/apt/sources.list) to include the non-free repository:
deb http://ftp.debian.org/debian lenny main contrib non-free
Install the Java6 Software Development Kit:
sudo apt-get install sun-java6-jdk
Create Jira User and Database
sudo apt-get install postgresql
Add these lines to the end of /etc/profile (they tell Tomcat server where Java is installed):
JAVA_HOME=/usr/lib/jvm/java-6-sun export JAVA_HOME
Create a user with a home directory of /usr/local/jira:
sudo /usr/sbin/useradd --create-home --home-dir /usr/local/jira --shell /bin/bash jira
Become the jira user and verify that you set up the home directory properly:
paul@track:~$ sudo su - jira jira@track:~$ pwd /usr/local/jira
So far, we have created a jira system user. Now we also need to create a jira postgresql user. We'll create the account by becoming the postgresql user:
paul@track:~$ sudo su - postgres postgres@track:~$ createuser -P jira Enter password for new role: Enter it again: Shall the new role be a superuser? (y/n) n Shall the new role be allowed to create databases? (y/n) y Shall the new role be allowed to create more new roles? (y/n) n
Next, we need a postgresql database for JIRA:
paul@track:~$ sudo su - jira jira@track:~$ createdb jira_313
Install JIRA, JDBC, and Pre-Startup Configuration
We're going to unpack JIRA in the jira user's home directory we created earlier (/usr/local/jira), and create a symlink to shorten the path to it:
sudo su - jira tar xvzf atlassian-jira-enterprise-3.13.3-standalone.tar.gz ln -s atlassian-jira-enterprise-3.13.3-standalone jira-3.13
JIRA needs the JDBC driver to connect itself to the postgresql database. Download it from here, and place it in the lib subdirectory:
cd /usr/local/jira/jira-3.13/common/lib wget http://jdbc.postgresql.org/download/postgresql-8.4-701.jdbc4.jar
Go to the conf subdirectory and edit the file server.xml. Replace the username, password, driverClassName and url lines and delete the lines defining minEvictableIdleTimeMillis and timeBetweenEvictionRunsMillis:
cd /usr/local/jira/jira-3.13/conf
jira@track:~/jira-3.13/conf$ diff server.xml.000 server.xml
14,19c14,17
< username="sa"
< password=""
< driverClassName="org.hsqldb.jdbcDriver"
< url="jdbc:hsqldb:${catalina.home}/database/jiradb"
< minEvictableIdleTimeMillis="4000"
< timeBetweenEvictionRunsMillis="5000"
---
> username="jira"
> password="jira"
> driverClassName="org.postgresql.Driver"
> url="jdbc:postgresql://localhost/jira_313"
Finally, go to the classes subdirectory and edit these two lines:
jira@track:~/jira-3.13/atlassian-jira/WEB-INF/classes$ diff entityengine.xml.000 entityengine.xml 100,101c100,101 < <datasource name="defaultDS" field-type-name="hsql" < schema-name="PUBLIC" --- > <datasource name="defaultDS" field-type-name="postgres72" > schema-name="public"
Note that the field-type name is "postgres72", even though we're using the postgresql 8.4 driver.
Start JIRA
jira@track:~/jira-3.13$ ./bin/startup.sh
If problems, check the log for errors:
jira@track:~/jira-3.13$ tail logs/catalina.out
Login and begin setting up JIRA:
http://<your server IP address>:8080/
The next article in this series will cover setting up JIRA features like e-mail, and extensions such as Subversion integration.
Resources
- Atlassian JIRA $10 license offer
- Setting up JIRA Standalone and PostgreSQL on Linux (Atlassian wiki)
- Installing Java on Ubuntu or Debian (Atlassian wiki)
- Running the Setup Wizard (Atlassian wiki)
View comments for this article
Virtualbox as a Remote Desktop Server
14-Feb-10 22:14
VirtualBox has gained a following as an alternative to VMware. Although the binaries are proprietary, they're free for non-commercial use. VirtualBox has some compelling features for desktop users:
- Automated installer that runs under Windows, Linux, and OSX. For Linux users, there are official versions for Ubuntu, Debian, openSUSE, Fedora, Red Hat Enterprise. A 64-bit CPU with hardware virtualization support helps, but isn't required.
- User interface that's easy to grasp. The documentation is well-organized. If you get stuck, there's a large community forum.
- Desktop integration with video and mouse. VirtualBox runs your virtual machine in a seamless window, just like normal applications. By installing Guest Additions, you can run your VM in high resolution with video acceleration.
- File exchange. VirtualBox's Shared Folders let your VM read and write files on your local drive. Of course, you can also use networking to access file shares outside the VM's virtual drive.
Remote Connections
There's one VirtualBox feature, however, that makes it stand out for me: you can access a VM from another computer -- not just the host machine -- using any client software compatible with Micosoft's Remote Desktop Protocol (RDP). When you run the Remote Desktop Connection software in Windows (from the Start | Accessories menu), you're using RDP.
What's so great about an RDP connection to a virtual machine? Say you have an older computer without enough raw speed or RAM to run the latest operating systems and applications. Using RDP, you can turn that machine into a graphic terminal, with access to any operating system you can install in VirtualBox on your more powerful computer. Or maybe you just want to have instant access to a VM running a different operating system, from anywhere on your network.
Server Configuration in Ubuntu
Authentication is the main hurdle to sharing a VirtualBox VM with RDP. VirtualBox's RDP server needs to know what port to listen on, and what authentication method to use. Even if you don't care about security, you may need to configure it anyway: In Ubuntu, I could not get RDP to work with the default "Null" setting. So the first step is to open your VM's Display settings, click on the Remote Display tab, checkmark the "Enable Server" box, and change the Authentication Method to "External".
You can leave the Port set to the standard (3389) unless you need to run multiple RDP sessions simultaneously. In that case, each VM must use a different port number.
Next, you'll need to to create an external authentication service. This is just a matter of changing some settings. Go to the /etc/pam.d directory and create a file called vrdpauth with these lines:
auth required pam_unix.so account required pam_unix.so broken_shadow
Execute the export command to set the VRDP_AUTH_PAM_SERVICE environment variable. Add it to ~/.bashrc so that it's automatically set the next time you log in:
export VRDP_AUTH_PAM_SERVICE=vrdpauth
Last, start the VM -- either normally, or from the command line. The latter method runs the VM "headless" (no display), and waits for a connection. This makes it perfect for automated startup and especially if you're running VirtualBox on a pure server that doesn't run X-Windows or a GUI desktop. The command to start a headless VM is:
VBoxHeadless --startvm <uuid|name>
Client Configuration: Rdesktop
If your client PC runs Linux, rdesktop is probably your best option. Most GUI apps in Linux like "Terminal Services Client" are just wrappers around rdesktop. It's worth getting familiar with the rdesktop parameters, particularly if you need to troubleshoot your connection. Test it first on the same machine hosting the VM, with a command like the following:
rdesktop -a 16 -u john -p - localhost:3389
In this example, "16" is the bits per pixel, "john" is the username, "localhost" is the machine serving the VM, and "3389" is the port number. The username must exist on the host. Also, note the hyphen after "-p", which will prompt for the password.
If your test works, run the same command from your client PC, replacing "localhost" with the hostname or IP of the server. Now, you can enjoy the latest applications, even on underpowered computers. I've used RDP to connect from my aging Thinkpad A20 laptop (Pentium III, 700 mhz CPU). Aside from streaming video, it runs with suitable speed.
The main limitation is the screen resolution on the client. If 1024x768 is the most it can do, then set your VM's resolution to the same. Use Ctrl-Alt-Enter to toggle fullscreen mode and get rid of the scroll bars.
For more about RDP in Virtualbox, download the VirtualBox PDF user manual or read it online.
View comments for this article
