Webbynode Howtos: Recent Posts

haseeb on "CentOS 5 - Remote Desktop"

Thu, 29 Jul 2010 05:22:36 +0000

awesome guide ....everything was installed....thank you very much...

J on "Ubuntu Hardy - Multiple Rails Apps with Passenger"

Tue, 01 Jun 2010 20:23:03 +0000

Very helpful article! Managed to get Ruby and RoR up and running in an evening. Thank you!

د.عبدالمجيد الحجي on "CentOS 5 - Remote Desktop"

Sat, 15 May 2010 00:21:24 +0000

Thanks! The trial was successful and the program being developed for the better ... Best greeting me to you dr.Abdo AL-Mjed AL-Hejje <a href="mailto:admin@ar-sa.net">admin@ar-sa.net</a>

G on "CentOS 5 - Remote Desktop"

Sun, 28 Feb 2010 07:55:53 +0000

<a href="http://i50.tinypic.com/91b5ti.png" rel="nofollow">http://i50.tinypic.com/91b5ti.png</a> Getting this error while installing GNOME :/ I tried installing KDE, everything went fine. But when i connect using TightVNC it doesnt shows any desktop. I used kde-session & for KDE. ?

Nevo on "CentOS 5 - Remote Desktop"

Nevo — Thu, 18 Feb 2010 12:48:38 +0000

Thanks for writing this Article. It guided me in the right direction. Everything works super and i was able to connect to my CentOs without any problems! :D

John Sullivan on "Ruby on Rails - Ubuntu Hardy"

Sat, 06 Feb 2010 10:01:51 +0000

Excellent :) I'm just a regular Goof blogger bored so I wanted to take a more serious look at learning Rails so I will tease my friends and say Oh Hey you wanted to set up Rails ? There you go :) Now let me re read this about 5 times Thanks

Chris on "CentOS 5 - Remote Desktop"

Chris — Sat, 28 Nov 2009 02:26:52 +0000

Thanks dude This looks sweet <a href="http://i46.tinypic.com/35ji39f.jpg" rel="nofollow">http://i46.tinypic.com/35ji39f.jpg</a>

James Hambleton on "CentOS 5 - Remote Desktop"

Mon, 23 Nov 2009 05:31:44 +0000

Everything worked like a charm except I can not click in to or key into the VNC session open desktop. I can see the desktop, but I can not do anything with it ? I have the firewall turn off on my Windows workstation (source) as well as my CentOS 5.4 server (destination) Any idea's ? Thanks inadvance

London escorts on "Debian Etch - LAMP Server"

Sat, 21 Nov 2009 14:23:43 +0000

Where can I get the info concerning php scripts? In the Internet such docs are VERY large, I need something smaller. Is there any book you can recommend me to read?

Luca on "CentOS 5 - Remote Desktop"

Luca — Wed, 18 Nov 2009 22:44:34 +0000

Interesting

astocks on "ReadyStack Deployment with GitHub Integration"

astocks — Tue, 28 Jul 2009 02:47:18 +0000

So you'd like to be up and running FAST? Choose a ReadyStack Deployment for quick installation of your base Linux OS, webserver, appserver, Ruby, Rails, and your very own app via GitHub. First, let's login to your Webbynode account. Once logged in you should see the below Webby page that displays your Webbies. Click on the Dashboard link to get started. Once in the Dashboard view you should see the Redeploy link on the left side. Keep in mind that you may not see all of the info that you see in the below screenshot if your Webby isn't up and running with an OS. Click the Redeploy link. Click the ReadyStack image as shown below. Here you can select the type of ReadyStack deployment you'd like to install. We're going to use the Rails ReadyStack for this tutorial. Select the Rails radio button and click Install. Next we'll select what type of apps we want to install. I've selected Passenger w/ Nginx, MySQL, PHPMyAdmin, My GitHub Repo, and New Relic. Now we'll specifiy what application we want to deploy from GitHub. I've selected Redmine which is a nice Project Management webapp. I've forked the Redmine project on GitHub to my GitHub repo and added a webby_config.sh script file. The webby_config.sh file tells ReadyStack how to provision your application. You can see the one I've used at <a href="http://bit.ly/PoTpk">webby_config example</a>. I've chosen to go with the default path for the app deployment to /var/rails. Next we can modify our webserver Document Root and Port if needed. Choose a password for the root MySQL account. Remember this password as you'll need it for MySQL administration in the future. I've selected Ruby 1.8.6 Enterprise Edition and Rails 2.2.2 based on the requirements for Redmine. I've also chosen to not install RI and RDoc to save space in the install. If you've already set up the New Relic integration from the Dashboard page your API key will be automatically populated. If you haven't done this and want to use New Relic to monitor your Rails app you can set up New Relic integration and get your own account/API key by using the link New Relic RPM from the Dashboard page where we selected Redeploy. Now that we have our options and configuration submitted you'll see the Redeploy Summary as shown below. This lists all of your selections for your review. If everything is correct go ahead and click Deploy. This screen is YOUR LAST CHANCE TO CHANGE YOUR MIND. If you're happy and ready to deploy go ahead and click OK. Your ReadyStack Deployment will begin, and you'll be able to watch the progress of the installation as seen below. Once the installation is complete you'll see the below pop-up. Next you'll see a summary screen outlining the actions performed in your ReadyStack Deployment. You'll also see links to the URL of your webapp you deployed from GitHub. If you've included a complete webby_config.sh script file in your GitHub repo then you can now open up a browser and navigate to your Webby. You should be greeted with your fully operational web application. ReadyStacks are a fast and efficient way to get your Rails apps deployed to your Webby. Less manual installation, and more FUN! Check out the <a href="http://webbynode.com/railsgithubrpm">ReadyStack Screencast with Rails and GitHub Integration</a> for a great video on this same topic.

ATS on "Getting Started With Your New Webby"

ATS — Wed, 22 Jul 2009 02:44:23 +0000

So you've just received your email with your login information for your brand new Webby! Below are some things you should do after your first login. You'll find the login button at the top right of the Webbynode homepage. After you're logged in you'll see your Webby displayed in the Webby Manager as shown below. Click on the Dashboard link shown with the red circle. Now you are looking at the Dashboard for your Webby. Here you will see lots of critical information including the IP address of your Webby. On the left side find the link called Root Password. This link allows you to reset the root password for your Webby. The root account is THE superuser account so you'll want to choose a complex password. Now that you're changed your root password it's time to SSH into your new Webby and add a username for yourself. We strongly discourage the use of the root account for everyday use for security reasons. To SSH into your Webby just open up your favorite terminal. If you're using a Mac you'd open up Terminal and type: <pre>ssh <a href="mailto:root@xxx.xxx.xxx.xxx">root@xxx.xxx.xxx.xxx</a></pre> ...where xxx.xxx.xxx.xxx is the IP address of your Webby. This will open an SSH session to your Webby and you'll be prompted for the password for the root account that you just set above. Now it's time to add your user. In the terminal type the below replacing 'webbyuser' with the username you want to add: <pre>adduser webbyuser</pre> ...you should see something similar to the below. It may vary a little depending on which OS you've deployed, but they'll all be similar. Now you have a new user that you can use for your everyday activities on your Webby. Of course many things will require you to have root privileges so let's get your new user added to the sudoers file. This will let you use the sudo command to temporarily run commands as root under your normal username. We're going to edit the sudoers file by typing: <pre>nano /etc/sudoers</pre> ...you're going to want to add your new username to the end of the file as in the picture below. ...now just save and exit nano. You're all set to start using your new Webby! If you'd like to take security a step further please see the Howto docs on Security and Hardening posted by cartab.

almonteb on "Webby DNS Manager"

almonteb — Mon, 20 Jul 2009 23:58:59 +0000

WebbyDNS Manager This guide will walk you through setting up your DNS records and reverse DNS via the Webby Manager. To begin, select the DNS tab after logging into <a href="https://manager.webbynode.com/">https://manager.webbynode.com/</a> From here, you can add domains, records and reverse dns information. Adding a domain To add a domain, select New zone from the main DNS page in your account. Enter your domain name, in this tutorial, we’ll use example.com. When completed, select Save zone and your domain will be added to the Webbynode name servers. You will then be taken back to the main dns management page. NOTE: In order for you to use our DNS management interface, you must add our name servers to your domain via your registrar. (ns1.dnswebby.com / ns2.dnswebby.com) Adding records Select your domain from the DNS manager by choosing records. If you just added your domain, you will have no records currently setup. If you’re using Google Apps Mail feature, you can simply click Add Gmail records and your dns will automatically be configured for you. To add other records simply choose New record. From there, you may add the following types of records: • A – Address • AAAA – IPV6 Address • CNAME – Canonical name record (alias) • HINFO – System information • MX – Mail exchange • NS – Name server • PTR - Pointer • RP – Responsible person • SRV – Service locator • TXT - Text Here is an example of an Address record for the root of your domain. You may add as many DNS records as you like to each domain. NOTE: When adding an MX record, the auxiliary data field is the MX priority. Reverse DNS Select the Reverse DNS option from the Webby DNS manager. Each of your public IPs will be able to have a record. Just put the name you would like under RDNS Entry. NOTE: Each RDNS Entry must have a corresponding “A” (Address) record set on the domain pointing to the IP address it links to.

carlos on "New Relic RPM - Manual Installation"

carlos — Sat, 04 Jul 2009 08:45:29 +0000

In order to manually install the New Relic RPM plugin, follow these instructions. Typing the following command from your Rails application's home directory: <pre>script/plugin install <a href="http://svn.newrelic.com/rpm/agent/newrelic_rpm" rel="nofollow">http://svn.newrelic.com/rpm/agent/newrelic_rpm</a></pre> The newrelic agent plugin creates a default copy of newrelic.yml in your config directory, you MUST edit this file and add your actual RPM account's activation key code. Restart your Rails application. Visit your Webby's RPM section to see your app's performance data. Your data should be visible in 2 minutes.

fcoury on "Webbynode API Guide (PDF)"

fcoury — Thu, 18 Jun 2009 17:14:04 +0000

Webbynode API Guide This guide is based on the Release Candidate 2 version of our API. During this guide we will discuss three different areas that this version provides: * Basic Client information access; * My Webbies list [new]; * Webby actions and status; * DNS Zones and Records maintenance. Please download the attached PDF.

carlos on "Pimping out your command prompt"

carlos — Mon, 15 Jun 2009 04:34:26 +0000

If you’ve worked with the Linux shell, you are no doubt familiar with the command prompt. By default, most Linux distros display a bland and boring command prompt with hostname and current directory, such as <blockquote>root: ~ #</blockquote> Customizing the command prompt is easier than most people think. You can change the output to display time, shell version, and even color. In this article we’ll be covering how to make your prompt pimped out and different, as well as useful for day-to-day tasks. Understanding Prompt The command prompt is set using special variables in the shell. The shell may have up to four different set variables, but the default one for the prompt is usually PS1. To display the default value of PS1, enter: <blockquote>echo $PS1</blockquote> The output may look something like: <blockquote>\u@\h:\w\$</blockquote> These special characters can be roughly translated as <a href="mailto:user@hostname:workingdir.">user@hostname:workingdir.</a> Modifying the prompt is an easy task of assigning a new value to the PS1 variable. <blockquote>PS1=”changeme:#”</blockquote> Now your command prompt should change to reflect the value you gave to the PS1 variable. Let’s set a value that make more sense and serves a bit more purpose. For example, this will display today’s date and hostname: <blockquote>PS1="\d \h: #"</blockquote> Or another common prompt, displays time in 24-hr format, user, hostname, and working folder: <blockquote>PS1="[\t \u@\h \W]$ "</blockquote> You might notice that if you log out of your webby you lose the prompted you assigned to the PS1 variable. To make the changes permanent, you will need to add some code to the end of your shell startup file. In Debian this file is either .bashrc or .bash_profile in the home folder. I have seen it work for both. <blockquote>nano ~/.bash_profile</blockquote> Add the following code to the end of the file: <blockquote>export PS1='[\t \u@\h \W]\$ '</blockquote> The new command prompt will now be retained after a logoff or reboot. The following is a list of characters that can be used to make your own shell prompt. <blockquote>\a : an ASCII bell character (07) \d : the date in "Weekday Month Date" format (e.g., "Tue May 26") \D{format} : the format is passed to strftime(3) and the result is inserted into the prompt string; an empty format results in a locale-specific time representation. The braces are required \e : an ASCII escape character (033) \h : the hostname up to the first '.' \H : the hostname \j : the number of jobs currently managed by the shell \l : the basename of the shell’s terminal device name \n : newline \r : carriage return \s : the name of the shell, the basename of $0 (the portion following the final slash) \t : the current time in 24-hour HH:MM:SS format \T : the current time in 12-hour HH:MM:SS format \@ : the current time in 12-hour am/pm format \A : the current time in 24-hour HH:MM format \u : the username of the current user \v : the version of bash (e.g., 2.00) \V : the release of bash, version + patch level (e.g., 2.00.0) \w : the current working directory, with $HOME abbreviated with a tilde \W : the basename of the current working directory, with $HOME abbreviated with a tilde \! : the history number of this command \# : the command number of this command \$ : if the effective UID is 0, a #, otherwise a $ \nnn : the character corresponding to the octal number nnn \\ : a backslash \[ : begin a sequence of non-printing characters, which could be used to embed a terminal control sequence into the prompt \] : end a sequence of non-printing characters</blockquote> Adding some color The last step is to add some colors to the prompt to make it stand out better. To add colors, use the following syntax: <blockquote>\e[x;ym \e[m</blockquote> Where \e[ begins the color scheme, x;y is the code for the color pair, and \e[m stops the color scheme. So for example, if you wanted to set a red color prompt you would type: <blockquote>export PS1=”\e[0;31m[\u@\h \W]\$ \e[m “</blockquote> You can mix and match different colors, but I will leave it to you to figure out the format. Don’t forget to append this line of code to your .bash_profile if you want to save the changes. Here is a short list of colors that may be used: <blockquote>Color Code Black 0;30 Red 0;31 Green 0;32 Brown 0;33 Blue 0;34 Purple 0;35 Cyan 0;36</blockquote> Replace digit 0 with 1 to get light color version. Play around with different a different combination of color codes and characters to get a good feel for it. I hope this guide will help you make a command prompt that will look cool as well as allow you to be more productive.

carlos on "Arch Linux - Yaourt (A Pacman Frontend)"

carlos — Mon, 15 Jun 2009 04:31:58 +0000

The traditional way to install Yaourt is through the actual AUR. In learning how to install yaourt this way, you will have the opportunity to learn how the AUR (and PKGBUILD)works. Open a web browser and head to the yaourt AUR page Under package details download the tarball Unpack the tarball <blockquote>tar zxvf yaourt.tar.gz</blockquote> Navigate into the new directory <blockquote>cd yaourt</blockquote> At this point; Make sure that you check the contents of the PKGBUILD and the yaourt.install files! This cannot be stressed enough, don't worry, they aren't too complicated. Just take a look, if you see anything suspicious, get on irc or the forum and ask about it. <blockquote>more yaourt.install more PKGBUILD</blockquote> If everything looks good. We are ready to build the packages. <blockquote>makepkg PKGBUILD</blockquote> After this process is complete, you will see several new files and directories. You should be interested in the file that ends with *.pkg.tar.gz (in this case mine is named; yaourt-0.9.2-i686.pkg.tar.gz) Now it's time to use pacman to install yaourt. Be sure to change the package name to the actual name of your package, don't just copy and paste this line <blockquote>pacman -U yaourt-0.9.2-i686.pkg.tar.gz</blockquote> Congratulations! You're done! Remember, this is the SAME process for almost all AUR PKGBUILDs. See the yaourt man page for more. Easy Install The easiest way to install Yaourt is to add the yaourt repository to your /etc/pacman.conf: For i686: [archlinuxfr] Server = <a href="http://repo.archlinux.fr/i686" rel="nofollow">http://repo.archlinux.fr/i686</a> For x86-64: [archlinuxfr] Server = <a href="http://repo.archlinux.fr/x86_64" rel="nofollow">http://repo.archlinux.fr/x86_64</a> Sync and install: <blockquote>pacman -Sy yaourt</blockquote> If you wish, you may then create your own command aliases in ~/.bashrc to save typing: <blockquote> nano ~/.bashrc</blockquote> <blockquote>alias p='pacman' alias y='yaourt'</blockquote> Save and then source: <blockquote>source ~/.bashrc</blockquote>

carlos on "CentOS 5.2 - Security and Hardening"

carlos — Mon, 15 Jun 2009 04:30:15 +0000

This wiki article will cover basic security in CentOS, from securing SSH to installing and configuring a basic firewall. Since your webby is pretty bare when we activate it, it is important to implement security as soon as you can to avoid being compromised. You will learn how to restrict access to your webby to a small number of selected individuals (or PCs) and design a very simple but effective firewall solution. Superuser Account Once of the fundamentals of Linux security is to never work with a root account to avoid having your password sniffed or keylogged while working from a remote location. For that reason, we will create a new user account that will be used to administrate your webby. Lets start by creating such an account. In my example I will use the username name 'webbyadmin'. <blockquote>adduser webbyadmin</blockquote> After creating the user we have to give it a password and add some basic permissions to the account. By adding the user to the wheel group we are giving it some administrative rights. <blockquote>passwd webbyadmin</blockquote> <blockquote>usermod -a -G wheel webbyadmin</blockquote> You can now log in to your new account, but lets stay in root throughout the length of the article. Note that if you cant get a command to run for some reason (most likely because environmental variables haven't been set up for new user), you can always switch to root by giving the command <blockquote>su -</blockquote> We will not disable the root account, even though you should if you are really concerned about your security. Disabling the root account will require installing sudo and setting up some environmental variables, which will not be covered in this article. Now that we created the new account lets take a look at SSH and firewall security. SSH Let’s take a look at the default SSH configuration: <blockquote>nano /etc/ssh/sshd_config</blockquote> We want to change the port SSH uses to an ambiguous, indistinct number. Look for the line that says ‘#Port 22’ and change it. Don't forget to take out the # symbol in front of the line. For example, <blockquote>Port 12345</blockquote> The next level of security to apply to SSH is to disallowing login by the root user. This way you will only be able to log in with your new user we just created. You’ll want to search for the “#PermitRootLogin yes” line and change it to deny root login attempts, as such: <blockquote>PermitRootLogin no</blockquote> Save the configuration file and restart the SSH service. Don't forget to change the port in your SSH client when you reconnect <blockquote>service ssh restart</blockquote> You should now have a pretty tightened down machine when it comes to SSH, stopping most brute force crack attempts in their tracks. Let’s move on to the next topic. Firewall (APF) If you run a website, blog, or any other type of service that opens your webby to the internet it's a good idea to close off any services that may leave your webby vulnerable. We'll be installing a free, lightweight firewall solution to address these issues. Download the latest version of APF: <blockquote>wget <a href="http://www.r-fx.ca/downloads/apf-current.tar.gz" rel="nofollow">http://www.r-fx.ca/downloads/apf-current.tar.gz</a></blockquote> Next, unzip and install it: <blockquote>tar -xvf apf-current.tar.gz cd apf-current.tar.gz ./install.sh</blockquote> APF will now be installed to /etc/apf on CentOS. You can find the configuration file the firewall in /etc/apf/conf.apf. Now lets open and make some changes to match our SSH config. <blockquote>nano /etc/apf/conf.apf</blockquote> First look for the line that says <blockquote>DEVEL_MODE="1"</blockquote> Leaving this option as “1” will disable your firewall after 5 minutes, so make sure to change it to “0”. Next, take a look at the allowed inbound ports. You should see something like <blockquote>IG_TCP_CPORTS="22,80,443"</blockquote> Notice that port 22, the default SSH port is open. We want to change this to the port we gave SSH earlier. You can leave port 80 (HTTP) and 443 (HTTPS) open if you plan on running a website. Next, take a look out outbound filtering. By default, APF will not filter outbound traffic but if would like to change that look for the following line <blockquote>EGF="0"</blockquote> And change this value to “1”. On the line directly below it you should see the allowed outbound ports <blockquote>EG_TCP_CPORTS="21,25,80,443"</blockquote> Change these if you have enabled outbound filtering and save the firewall config. Now we should add the firewall to start when we reboot our webby and enable it <blockquote>chkconfig --add apf chkconfig --level 345 apf on service apf start</blockquote> You might get kicked out of your webby if you haven't relogged after changing the SSH config. Just log back in if you need to do any post-install stuff. Remember to use 'su -' if some of these commands aren't registering with the webby. You should not have a pretty secure box ready face the dangers of the internet.

carlos on "CentOS 5.2 - Complete Server Solution"

carlos — Mon, 15 Jun 2009 04:26:22 +0000

In this wiki article we will look at installing and configuring a complete server solution for your webby, including HTTP, Database, and DNS. This article will cover a broad base of topics in a general sense, but will not focus on one specifically. If you would like to get a better understanding of a specific topic please refer to our other aticles or use the article request form to file a request. Before we begin lets get a couple of clarifications out of the way. At the time of writing the latest release of CentOS was version 5.2, but this article should apply to any earlier versions without much modification. We will be using the yum package manager rather than installing from source for its ease of use and ability to handle dependencies. Finally, we assume you will be installing from a root-level account. We'll be installing the latest versions of the following software: HTTP: Apache with PHP Database: MySQL DNS: BIND (chrooted) Installing Apache 2 and PHP 5 Before we proceed with installing anything let's update our webby to the latest version: <blockquote>yum update</blockquote> To install Apache and PHP, run the following command <blockquote>yum install httpd httpd-devel php php-mysql php-common php-gd php-mbstring php-mcrypt php-devel php-xml</blockquote> Now configure your system to start Apache at boot time: <blockquote>chkconfig --levels 235 httpd on</blockquote> We have to start Apache by hand after installation. To do this, type <blockquote>/etc/init.d/httpd start</blockquote> You will see a warning about ServerName, so let’s go ahead and fix that now. Open the main apache config file: <blockquote>nano /etc/httpd/conf/httpd.conf</blockquote> Hit CTRL+W to bring up the search prompt and type in “ServerName”. Repeat until you find the line of code that says <blockquote>ServerName <a href="http://www.example.com:80" rel="nofollow">www.example.com:80</a></blockquote> Change this line to your hostname or FQDN and take out the pound sign (#) in front of ServerName. Now reload Apache: <blockquote>/etc/init.d/httpd reload</blockquote> Now open a web browser and type in your webby's IP address. If everything went well you should see the default Apache landing page. Installing MySQL 5 You can install MySQL server, client, and module with the following command: <blockquote>yum install mysql mysql-devel mysql-server</blockquote> MySQL should now be installed. The configuration file is located at: /etc/mysql/my.cnf Then we create the system startup links for MySQL (so that MySQL starts automatically whenever the system boots) and start the MySQL server: <blockquote>chkconfig --levels 235 mysqld on /etc/init.d/mysqld start</blockquote> Now we delegate control of MySQL to a user. By default MySQL runs on the root account with no password. Lets password protect the root account: <blockquote>mysql -u root mysql> USE mysql; mysql> UPDATE user SET Password=PASSWORD(’new-password’) WHERE user=’root’; mysql> FLUSH PRIVILEGES; mysql> quit;</blockquote> Although we have password protected the root account, you must never use it in your production environment. The best practice is to create a user to connect to MySQL. Then restart your MySQL server: <blockquote>/etc/init.d/mysqld restart</blockquote> Installing BIND DNS Server We will harden the BIND installation by installing it within a chroot jail. This is to provide increased security and prevent your DNS server from being compromised. To install a chrooted BIND9, we do this: <blockquote>yum install bind-chroot</blockquote> Then do these steps: <blockquote>chmod 755 /var/named/ chmod 775 /var/named/chroot/ chmod 775 /var/named/chroot/var/ chmod 775 /var/named/chroot/var/named/ chmod 775 /var/named/chroot/var/run/ chmod 777 /var/named/chroot/var/run/named/ cd /var/named/chroot/var/named/ ln -s ../../ chroot cp /usr/share/doc/bind-9.3.4/sample/var/named/named.local /var/named/chroot/var/named/named.local cp /usr/share/doc/bind-9.3.4/sample/var/named/named.root /var/named/chroot/var/named/named.root touch /var/named/chroot/etc/named.conf chkconfig --levels 235 named on /etc/init.d/named start</blockquote> BIND will now run in a chroot jail under /var/named/chroot/var/named/. We will cover BIND configuration for CentOS in a future wiki. You should now have a complete installation of Apache, MySQL and BIND and should be ready to serve content on the web.

carlos on "CentOS 5 - Remote Desktop"

carlos — Mon, 15 Jun 2009 04:22:53 +0000

In this wiki article we'll discuss setting up your webby as a VNC server and using a client from your Windows machine to connect. Why would you want to use your webby as a remote desktop? Well one example I can think of would be if you wanted to explore the GUI features of Linux before installing it on your box at home. Another advantage would be to install a desktop environment if you're unfamiliar or uncomfortable with the command prompt to run administrative tasks. But isn't a desktop environment a memory intensive application that will eat up my RAM and bring my webby to a crawl? Not really. We dont even need to run X Server (and couldn't because of video terminal issues with Xen), thereby eliminating much of the stress placed on the system. In our tests, VNC server with GNOME running a freshly rebuilt 256MB webby only consumed about 35MB RAM. Although this article applies to CentOS, the changes are minimal if you use any other Linux distribution we offer. Installation Lets start by logging on to our webby and installing the required packages for VNC. We'll need the X Window System and a desktop environment, which can be installed with: <blockquote>yum groupinstall "X Window System" yum groupinstall "GNOME Desktop Environment"</blockquote> You may prefer to install a different desktop environment, such as KDE, which is a little larger and resource intensive than GNOME. To get a complete list of available packages give the “yum grouplist” command. The installation of each package may take a while to finish, so go pour yourself a cup of coffee. NOTE: If you receive the error “Error: Missing Dependency: libgaim.so.0 is needed by package nautilus-sendto” while installing GNOME Desktop Environment, you will need to manually install nautilus-sendto with the following procedure: <blockquote>yum install yum-utils yumdownloader nautilus-sendto rpm -Uvh --nodeps nautilus-sendto[PRESS TAB]</blockquote> Source: <a href="http://bugs.centos.org/view.php?id=2483">http://bugs.centos.org/view.php?id=2483</a> Configure VNC Server VNC Server should have been installed along with X Window System, so we can now move on to configuration. Edit the /etc/sysconfig/vncservers file and add (or uncomment) the following two lines: <blockquote>nano /etc/sysconfig/vncservers</blockquote> <blockquote>VNCSERVERS="5:root" # display port and username VNCSERVERARGS[2]="-geometry 800x600 -nolisten tcp -nohttpd -localhost</blockquote>" Change the criteria to match your desired configuration. For example, change “5:root” to a different display port and/or username if you do not wish to use root. Likewise, change the resolution if you prefer. The other parameters can be left as they are. Save the file and exit. Now we need to assign a password to the VNC server. Do this by issuing: <blockquote>vncpasswd</blockquote> To start VNC server, type <blockquote>vncserver :5</blockquote> This will generate a local Notice that :5 is the same port we gave in the first config file. Before you log in through a VNC client there is one more file that needs to be adjusted to match our configuration. First, kill the dekstop you launched earlier with: <blockquote>vncserver -kill :5</blockquote> Now edit the local config file in the root folder: <blockquote>nano ~/.vnc/xstartup</blockquote> We want to have VNC load GNOME instead of the default twm. Look for the following line: <blockquote>twm &</blockquote> And replace it with <blockquote>gnome-session &</blockquote> Ok now save and restart the VNC instance: <blockquote>vncserver :5</blockquote> Remember the port you are using to start VNC (:5), you will need it later when connecting with a VNC client. VNC Server should be running GNOME as needed now. Notice we didn't even bother with any X Server configuration because it's not needed to give us a fully functioning remote desktop. This should do it for configuration. Let's go on to testing our setup. Connecting with VNC client Load up your favorite VNC client (I use TightVNC or RealVNC) and type your IP followed by the port number you loaded VNC server with (NOT the general VNC port). Such as: <blockquote>123.45.67.89:5</blockquote> Then click connect. You will be prompted for your password (the one you specified with vncpasswd) after which your Linux desktop should come up. If you are having problems connecting, check your firewall rules to see if the generic VNC port (5900) is open for incoming connections. That should be it, congratulations on installing VNC server and enjoy your new Linux desktop!

carlos on "CentOS 5 - Apache 2 with PHP"

carlos — Mon, 15 Jun 2009 04:19:36 +0000

In this wiki article you will learn how to install and test Apache Web Server with PHP 5. This article already assumes you have a working version of CentOS with the latest updates. We will be working with yum, the CentOS package management system. We also assume you are working with the root account, or an account with administrative privileges. Installation To install Apache and PHP, run the following command <blockquote>yum install httpd httpd-devel php php-mysql php-common php-gd php-mbstring php-mcrypt php-devel php-</blockquote>xml After you enter this command yum will connect to the CentOS repositories and download the specified packages. Notice that yum will also download and install any security updates and dependencies that might be needed by Apache and PHP. We have to start Apache by hand after installation. To do this, type <blockquote>/etc/init.d/httpd start</blockquote> You will see a warning about ServerName, so let’s go ahead and fix that now. Open the main apache config file: <blockquote>nano /etc/httpd/conf/httpd.conf</blockquote> Hit CTRL+W to bring up the search prompt and type in “ServerName”. Repeat until you find the line of code that says <blockquote>#ServerName <a href="http://www.example.com:80" rel="nofollow">www.example.com:80</a></blockquote> Change this line to your hostname or FQDN and take out the pound sign (#) in front of ServerName. Now reload Apache: <blockquote>/etc/init.d/httpd reload</blockquote> Now open a web browser and type in your webby's IP address. If everything went well you should see the default Apache landing page. To test if PHP was installed properly, create a phpinfo.php file in your web folder, as such: <blockquote>nano /var/www/html/phpinfo.php</blockquote> Place the following code inside: <blockquote># phpinfo.php <?php phpinfo(); ?></blockquote> Now point your browser to <a href="http://ip.address/phpinfo.php" rel="nofollow">http://ip.address/phpinfo.php</a> and you should see your PHP configuration. Congratulations, you just successfully set up Apache Web Server with PHP!

carlos on "Ubuntu Hardy - Installing a DNS Server with BIND"

carlos — Mon, 15 Jun 2009 04:14:54 +0000

Installing BIND DNS Server (in a chroot jail) - Ubuntu Hardy This wiki article will go over how to install and set up a DNS server with BIND on your webby. BIND has been around for 20 years and has proven to be very reliable for managing DNS. We will be using Ubuntu Hardy 8.04 as the target OS for deployment but the process for deploying on any other OS should be just about the same. You add zones and manage records in BIND through a simple configuration file. Keep in mind that we will only be setting up a master server in this article, with none of the advanced features such as DDNS and DNSSEC. Obviously, if you run a critical website you should look into setting up a secondary DNS server on a separate webby, which could be put on a separate server in a different datacenter. Also, this article assumes you have already bought a domain with a registar (I use GoDaddy) and pointed it to your IP. [b]Installing & Creating Chroot Jail Start by updating your mirror list, base system, and downloading BIND: <blockquote>apt-get update apt-get upgrade apt-get install bind9 dnsutils</blockquote> Before proceeding any further lets turn off the BIND daemon while we reconfigure it: <blockquote>/etc/init.d/bind9 stop</blockquote> Since the version of BIND from apt-get is likely to be slightly outdated, we want to create a chroot jail for our installation for security reasons. Do this by creating the following directories: <blockquote>mkdir -p /var/lib/named/etc mkdir /var/lib/named/dev mkdir -p /var/lib/named/var/cache/bind mkdir -p /var/lib/named/var/run/bind/run</blockquote> We want to tell the daemon to use these new directories next time we start it up, so let's go ahead and edit the config file that tells it where to look for BIND: <blockquote>nano /etc/default/bind9</blockquote> Modify the line starting with OPTIONS so that it reads: <blockquote>OPTIONS="-u bind -t /var/lib/named"</blockquote> Next, move the installation folder to the new location and create a symbolic link for the configuration back to old location: <blockquote>mv /etc/bind /var/lib/named/etc ln -s /var/lib/named/etc/bind /etc/bind</blockquote> Make null and random devices, and fix permissions of the directories: <blockquote>mknod /var/lib/named/dev/null c 1 3 mknod /var/lib/named/dev/random c 1 8 chmod 666 /var/lib/named/dev/null /var/lib/named/dev/random</blockquote> Lastly, we will change the owner of the BIND system directory to the 'bind' user and group: <blockquote>chown -R bind:bind /var/lib/named/var/* chown -R bind:bind /var/lib/named/etc/bind</blockquote> Configuring BIND Ubuntu pre-configures BIND, adding the 'bind' user and group to your server. Edit the BIND configuration file that is made for us: <blockquote>nano /etc/bind/named.conf.local</blockquote> Note that you will actually be editing files in the new chroot jail that are linked to the /etc/bind location. All zone definitions should be added to this file. Use the example below but change domain.com with your domain name: <blockquote>zone "domain.com" { type master; file "/etc/bind/zones/domain.com.db"; }; # This is the zone definition for reverse DNS. replace # 254.168.192 with your network address in reverse notation. zone "254.168.192.IN-ADDR.ARPA" { type master; file "/etc/bind/zones/192.168.254.rev"; };</blockquote> Now we need to edit the options file: <blockquote>nano /etc/bind/named.conf.options</blockquote> This is where we modify the forwarder, which is the DNS server yours will forward requests to that it cannot process. If you are unsure of what your forwarder is, take a look in the /etc/resolv.conf file, as this is the DNS server assigned by default to your webbt. Look for the following lines of code in /etc/bind/named.conf.options (might be commented out) and replace 123.45.65.89 with your forwarder: <blockquote>forwarders { 123.45.67.89; };</blockquote> Now lets make a zones home folder and add the definition files. Relace domain.com with your domain name: <blockquote>mkdir /etc/bind/zones nano /etc/bind/zones/domain.com.db</blockquote> This is where we put all the addresses and machine names that we want our DNS server to know. It is also where you would add multiple domain names if you host more than one website on your webby. Furthermore, sub-domains must be added here if you plan on doing stuff like ftp, mail, or virtual hosts. Dont forget to change domain.com with your domain and replace the IP addresses with yours. Add this code to the definition file: <blockquote>; BIND data file for domain.com $TTL 604800 domain.com. IN SOA ns1.domain.com. info.domain.com. ( 2008062101 ; Serial 7200 ; Refresh 120 ; Retry 2419200 ; Expire 604800 ; Default TTL ) ; Replace ns1 as necessary (ns1 = Domain Server name) domain.com. IN NS ns1.domain.com. domain.com. IN MX 10 mail.domain.com. ; Add sub-domains, mail, ftp, etc. here ns1 IN A 123.45.67.89 mail IN A 123.45.67.89 www IN A 123.45.67.89 blog IN A 123.45.67.89 </blockquote> Now let's set up the reverse DNS zone. Replace 254.168.192 with you network address in reverse notation. NOTE: This step is optional and was only added for consistency and standardization. To get RDNS set up properly for your webby please open up a ticket. <blockquote>nano /etc/bind/zones/rev.254.168.192.in-addr.arpa</blockquote> Copy and paste the following, modifying as needed: <blockquote>@ IN SOA ns1.domain.com. info.domain.com. ( 2008062101 ; 28800 ; 604800 ; 604800 ; 86400) ; The number before IN PTR is the machine address of the VPS. ; In my case, it's 89, as my IP address is 123.45.67.89 IN NS ns1.domain.com. 89 IN PTR domain.com</blockquote> Only a few more steps and we're done. We still need to edit the resolv.conf file and add our new DNS server: <blockquote>nano /etc/resolv.conf</blockquote> Add the following, relacing domain.com with your domain name and 123.45.67.89 with the IP of your new DNS server (your webby's IP): <blockquote>search domain.com nameserver 123.45.67.89</blockquote> Proceed by starting BIND: <blockquote>/etc/init.d/bind9 start</blockquote> Testing BIND Configuration[/b] First, let's test the integrity of your definition file: <blockquote>cd /etc/bind/zones named-checkzone domain.com domain.com.db</blockquote> This should return an 'OK' status. If you get some errors, go back and check your definition file (/etc/bind/zones/domain.com.db). To finish off, lets test your new DNS: <blockquote>dig domain.com</blockquote> You should get an answer similar to this: <blockquote>; <<>> DiG 9.4.2 <<>> domain.com ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6418 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;domain.com. IN A ;; AUTHORITY SECTION: domain.com. 38400 IN SOA ns1.domain.com. admin.domain.com. 2006081401 28800 3600 604800 38400 ;; Query time: 2 msec ;; SERVER: 123.45.67.89#53(123.45.67.89) ;; WHEN: Wed Jun 25 02:19:16 2008 ;; MSG SIZE rcvd: 75</blockquote> If you see something like this above, that should do it. Congratulations on successfully setting up your new BIND DNS server in a chroot jail!

carlos on "Debian Etch - DNS Caching Server Setup"

carlos — Mon, 15 Jun 2009 04:09:54 +0000

A while back a client asked me to set up an onsite DNS cache for him so that all DNS requests from his network would be sent there. This is quite different than a typical 'DNS Server' that one would use to host their website, mail, or FTP server. Users could set the server as their primary DNS on their local machines and the DNS cache would resolve domain names by querying a number of master servers on the web. It then creates it's own database for DNS requests. If you run multiple webbies or a project on a different host and don't want to rely on your hosts DNS, you can create your own. This DNS can even be used on your home computer in case your provider's DNS goes down. In this article I will show you how to set up tinydns & djbdns on Ubuntu and secure it so that outsiders cannot use your nameserver. Installation Before we dive into the details we need to update the apt sources file to allow some of the packages to install correctly. Edit the sources.list file <blockquote>nano /etc/apt/sources.list</blockquote> and make sure you have the proper sources enabled. Your file should look something like this: <blockquote>deb <a href="http://ftp.us.debian.org/debian" rel="nofollow">http://ftp.us.debian.org/debian</a> etch main contrib non-free deb <a href="http://security.debian.org/" rel="nofollow">http://security.debian.org/</a> etch/updates main</blockquote> If your sources file contains additional lines starting with 'src' just leave those in there. Next, let's update our base system and install some dependencies <blockquote>apt-get update apt-get upgrade apt-get install build-essential</blockquote> We can then start installing and building TinyDNS & djbDNS. Accept all the defaults when you perform the builds <blockquote>apt-get install ucspi-tcp-src build-ucspi-tcp apt-get install daemontools-installer build-daemontools apt-get install djbdns-installer build-djbdns</blockquote> When the installations are finished you are ready to move on to configuring. Configuration First, check that the correct user accounts were created. <blockquote>cat /etc/passwd</blockquote> On the last three lines you should see dnslog, dnscache, & tinydns. If they are there, everything's fine. If they are not, you will have to add them manually: <blockquote>adduser –no-create-home –disabled-login -shell /bin/false dnscache adduser –no-create-home –disabled-login -shell /bin/false dnslog adduser –no-create-home –disabled-login -shell /bin/false tinydns</blockquote> Next, we will configure DNScache & tinyDNS <blockquote>mkdir /var/lib/svscan dnscache-conf dnscache dnslog /var/lib/svscan/dnscache ln -sf /var/lib/svscan/dnscache /service</blockquote> For dnscache, you will need to specify your webby's public IP. This will be your nameserver's IP <blockquote>dnscache-conf dnscache dnslog /var/lib/svscan/dnscache 192.168.0.1 ln -sf /var/lib/svscan/dnscache /service</blockquote> For tinydns, you will need use the loopback IP on your box <blockquote>tinydns-conf tinydns dnslog /var/lib/svscan/tinydns 127.0.0.1 ln -sf /var/lib/svscan/tinydns /service</blockquote> This should sum up the configuration portion of the article. Next, we can move on to securing and testing your nameserver. Testing DNS First you can test this locally on the DNS server itself, modify /etc/resolv.conf and add your webby's IP. You can try both the public IP or the loopback (127.0.0.1). Either one should work. <blockquote>nano /etc/resolv.conf</blockquote> As of this point in the installation your nameserver is not open for public use. To enable remote machines to use this DNS you must add their IPs to dnscache's allow list. For example, this would allow the machine with the IP 192.168.0.2 to use the nameserver: <blockquote>cd /var/lib/svscan/dnscache/root/ip touch 192.168.0.2</blockquote> This will create an empty file in the directory that gives the users under that IP access to the DNS. You can use an exact IP or specify a range, like so <blockquote>touch 192.168.0 touch 10.0</blockquote> This would allow all machines on the 192.168.0 and 10.0 subnets to use this nameserver. To finish off, you can run some tests to make sure dnscache is functioning: <blockquote>dnsip google.com dig google.com</blockquote> If both those commands give a successful output then your DNS cache is working fine. You can now modify the /etc/resolv.conf on your remote servers to start using the nameserver. Just remember to add new users to the allowed IP list if you want them to be able to use it. Congratulations on a successful setup!

carlos on "Debian Etch - Secure VNC Server with SSH Tunnel"

carlos — Mon, 15 Jun 2009 04:03:21 +0000

Virtual Network Computing (VNC) is a system that allows you to use a graphical desktop on a remote host. This might be a useful tool for users just starting out with Linux because it essentially replaces the command line interface that might overwhelm some beginners. It's also useful for running applications with limited command line support, or as a security measure. In this article I will cover how to get VNC up and running on your webby, complete with security. I used Debian as a deployment platform, but originally I had used Ubuntu Hardy to set this up for a client. Therefore, the installation should be universal for all Debian clones. Keep in mind that you will be installing a desktop environment on your webby, which *can* use up quite a bit of memory. Therefore, if you plan on using your webby for anything other than just VNC, I wouldn't recommend this deployment on anything less than a 512 Webby. Installation Before you start using VNC you will need to connect to your webby via SSH to perform some updates and install the required software. Once you are in, upgrade your webby with the latest packages: <blockquote>apt-get update apt-get upgrade</blockquote> After the system updates we need to install a desktop environment. For this article I recommend GNOME, but KDE and others should work as well. <blockquote>apt-get install gnome-desktop-environment</blockquote> We also need to install some fonts for the GNOME session <blockquote>apt-get install xfonts-100dpi apt-get install xfonts-100dpi-transcoded apt-get install xfonts-75dpi apt-get install xfonts-75dpi-transcoded apt-get install xfonts-base</blockquote> Last of all, we are ready to install VNC Server. TightVNCServer is my choice here. <blockquote>apt-get install tightvncserver</blockquote> This will install TightVNCServer. In order to initialize it we run <blockquote>tightvncserver :1</blockquote> VNC runs on port 5900 by default, so the :1 tells TightVNCServer to run on port 5901. This is the port you will use to later connect to your webby. There are some parameters you can give to adjust resolution, for example: <blockquote>tightvncserver -geometry 1280×1024 :1</blockquote> This will create some files in ~/.vnc and it should ask you for a password. Make sure you pick a good password, even though we will be securing it with SSH later. After you initialize VNC for the first time you need stop it for further configuration. This is done with <blockquote>tightvncserver -kill :1</blockquote> Configuration We'll use an editor to configure VNC from now on. Lets open the configuration file and look at the options <blockquote>nano ~/.vnc/xstartup</blockquote> Since VNC uses the standard X Windows interface, we will need to tell it to use GNOME. Change the last line to invoke GNOME instead of X Windows, like so: <blockquote>#!/bin/sh</blockquote> <blockquote>xrdb $HOME/.Xresources xsetroot -solid grey #x-terminal-emulator -geometry 80x24+10+10 -ls -title "$VNCDESKTOP Desktop" & #x-window-manager & gnome-session &</blockquote> Save the config file and exit. You can now start VNC again <blockquote>tightvncserver :1</blockquote> Although you can now connect to your webby with a VNC client and start using the desktop, we have one more important step before we can call it finished. By default, VNC runs unencrypted so any information you transmit becomes vulnerable. It is therefore advised to set up a SSH tunnel for VNC to connect through. Since SSH is secure, we don't have to worry about someone snooping our password. In the next step we will go over how to set up an SSH tunnel just for this reason. Set up SSH Tunnel On your local machine give the following command, where 192.168.0.1 is the IP of your webby: <blockquote>ssh -f -N -L 5901:localhost:5901 <a href="mailto:root@192.168.0.1">root@192.168.0.1</a> -p 22</blockquote> This will start the SSH tunnel for por 5901, so all traffic through that port will first be encrypted by SSH. You can then start VNC server on your webby again <blockquote>tightvncserver :1</blockquote> You can then connect to your virtual desktop with a VNC client on your computer. For PC, TightVNC is my favorite. For Mac, there is Chicken of the VNC. When asked for a password, give them one you typed when installing VNC. You should now have a functional graphical desktop on your webby. I hope this article was helpful and you find your adventure into VNC land rewarding.

carlos on "Debian Etch - lighthttpd and PHP"

carlos — Mon, 15 Jun 2009 03:52:36 +0000

This wiki article will explain how to install and configure lighthttpd with PHP5 and MySQL. lighthttd is a web server designed to be fast, secure, flexible and standards-complient while being optimized for speed-critical environments. Its low memory footprint, light CPU load and speed make it the perfect web server for an environment such as a 256MB webby. Lighthttpd supports the FastCGI interface, which we will use to enable PHP5 support. This article assumes you have already updated your system with the latest fixes and DO NOT have a web server, such as Apache, already installed on your webby. We will be installing all required applications with the apt-get utility in Debian. Install MySQL We begin by installing MySQL 5.0: <blockquote>apt-get install mysql-server mysql-client </blockquote>This should install and start up the MySQL server. Let's give the MySQL root account a password, such as: <blockquote>mysqladmin -u root password yourpassword</blockquote> Now we have to check on which address MySQL is listening with netstat: <blockquote>netstat -tap | grep mysql</blockquote> The output should look similair to this: <blockquote>tcp 0 0 localhost:mysql *:* LISTEN 1695/mysqld</blockquote> Which means MySQL is listening on localhost only. But lets say you see output such as: <blockquote>tcp 0 0 *:mysql *:* LISTEN 1695/mysqld</blockquote> That means anyone can access your database and modify data, so you should set a password for your hostname. For example: <blockquote>mysqladmin -h server1.domain.com -u root password yourpassword </blockquote>Replacing sever1.domain.com with your domain name. Install lighthttpd We can install lighthttpd with apt-get, like this: <blockquote>apt-get install lighttpd</blockquote> After installation finishes, open your web browser and type in your webby's IP and you should see the placeholder page. Lighttpd's default document root is /var/www on Debian, and the configuration file is /etc/lighttpd/lighttpd.conf. Install PHP5 PHP works on lighthttpd using the FastCGI interface. Debian provides a FastCGI-enabled PHP5 package, which we can install like this: <blockquote>apt-get install php5-cgi</blockquote> To enable PHP5 in lighttpd, we must modify two files (/etc/php5/cgi/php.ini & /etc/lighttpd/lighttpd.conf). First we open /etc/php5/cgi/php.ini: <blockquote>nano /etc/php5/cgi/php.ini</blockquote> Add the following line right at the end of the file: <blockquote>cgi.fix_pathinfo = 1</blockquote> Then we open /etc/lighttpd/lighttpd.conf and add “mod_fastcgi”, to the server.modules stanza: <blockquote>nano /etc/lighttpd/lighttpd.conf</blockquote> Look for the following text: <blockquote> server.modules = ( "mod_access", "mod_alias", "mod_accesslog", "mod_fastcgi", # "mod_rewrite", # "mod_redirect", # "mod_status", # "mod_evhost", # "mod_compress", # "mod_usertrack", # "mod_rrdtool", # "mod_webdav", # "mod_expire", # "mod_flv_streaming", # "mod_evasive" )</blockquote> and then right at the end of the file, we add the following stanza: <blockquote>fastcgi.server = ( ".php" => (( "bin-path" => "/usr/bin/php5-cgi", "socket" => "/tmp/php.socket" )))</blockquote> Next, we restart lighthttpd: <blockquote>/etc/init.d/lighttpd restart</blockquote> Testing Your Installation The document root of the default web site is /var/www. To test if PHP was installed properly, create a test.php file in your web folder, as such: <blockquote>nano /var/www/phpinfo.php</blockquote> Place the following code inside: <blockquote><?php phpinfo(); ?></blockquote> Now point your browser to <a href="http://ip.address/phpinfo.php" rel="nofollow">http://ip.address/phpinfo.php</a> and you should see your PHP configuration. As you can see on the Server API line, PHP5 is working through FastCGI. If you scroll further down, you will see all modules that are already enabled in PHP5. MySQL is not listed there which means we don't have MySQL support in PHP5 yet. Enable MySQL Support in PHP5 To get MySQL working with PHP5 all we have to do is install the php5-mysql package. <blockquote>apt-get install php5-mysql</blockquote> Now restart lighthttpd: <blockquote>/etc/init.d/lighttpd restart</blockquote> Reload the phpinfo.php file in your web browser and scroll down to the modules section again. You should now find lots of new modules there, including the MySQL module. That's about it, congratulations on installing MySQL/lighthttpd/PHP5 on your webby!

carlos on "Debian Etch - LAMP Server"

carlos — Mon, 15 Jun 2009 03:45:41 +0000

In this wiki article, we are going to discuss how to get a LAMP Server up and running on Debian 4.0. The reason we picked Debian for this article is because it is by far one of the most commonly used distributions for hosting websites. In addition Debian is one of the lightest installations, with respect to memory and disk usage. LAMP, as it is commonly referred to, stands for Linux + Apache + MySQL + PHP/Perl. The instructions in this article can also be applied to any other version of Debian and also Ubuntu. There are a couple things to keep in mind before proceeding. First, we will be installing everything on a remote virtual private server using an SSH connection, but if you are installing on a local system not a whole lot should change in your procedure. Second, we will be using the apt-get package management system instead of installing from source. This is because apt-get will handle all dependencies and security updates that might be required by the server software we are installing. Installing Apache & PHP Before we start installing any server packages, let’s do a quick system update to get any last-minute fixes for Debian: <blockquote>apt-get update</blockquote> Apache and PHP can both be installed using the following command <blockquote>apt-get install apache2 php5 libapache2-mod-php5</blockquote> Notice that we can specify which version we want to make apt-get install. For example, <blockquote>apt-get install apache php4</blockquote> would install earlier versions of Apache and PHP. You might want to install older versions if you’re looking for a more stable environment, although Apache 2 has been hardened pretty well already. Now you have to add the following line to the end of your Apache configuration file to get it to stop crying about ServerName. Set ServerName to your hostname or FQDN. If you’re not sure what your hostname is look in /etc/hostname or just use localhost. Your Apache configuration file is found at /etc/apache2/apache2.conf <blockquote>ServerName localhost</blockquote> Point your web browser to your IP (http://ip.address) and if everything went well you should see the default landing page for Apache 2. To test if PHP was installed properly, create a test.php file in your web folder, as such: <blockquote>nano /var/www/phpinfo.php</blockquote> Place the following code inside: <blockquote># phpinfo.php <?php phpinfo(); ?></blockquote> Now point your browser to <a href="http://ip.address/phpinfo.php" rel="nofollow">http://ip.address/phpinfo.php</a> and you should see your PHP configuration. Installing MySQL MySQL is a database server that you will need if you plan to run an ecommerce website or a forum. There are several alternatives but MySQL is regarded as the ‘mainstream’ database solution. In addition to the server, you will also need the MySQL client to manage your database and PHP module. You can install MySQL server, client, and module with the following command: <blockquote>apt-get install mysql-server mysql-client php5-mysql</blockquote> MySQL should now be installed. The configuration file is located at: /etc/mysql/my.cnf Now we delegate control of MySQL to a user. By default MySQL runs on the root account with no password. Lets password protect the root account: <blockquote>mysql -u root mysql> USE mysql; mysql> UPDATE user SET Password=PASSWORD('new-password') WHERE user='root'; mysql> FLUSH PRIVILEGES; mysql> quit;</blockquote> Although we have password protected the root account, you must never use it in your production environment. The best practice is to create a user to connect to MySQL. Since we are finished with MySQL setup, we will now install a control panel called phpMyAdmin to do just that. Installing phpMyAdmin phpMyAdmin is a web based database management and administration control panel that makes it easy to create and assign database permissions to users. It is very ‘lightweight’ and easy to setup and configure. In addition, it makes managing databases much easier. To install phpMyAdmin run the following command: <blockquote>apt-get install phpmyadmin</blockquote> To set up phpMyAdmin under Apache you need to include the following line in the Apache configuration file found in /etc/apache2/apache2.conf <blockquote>Include /etc/phpmyadmin/apache.conf</blockquote> To finish off, restart Apache. <blockquote>/etc/init.d/apache2 restart</blockquote> Point your browser to <a href="http://ip.address/phpmyadmin" rel="nofollow">http://ip.address/phpmyadmin</a> and log in with your root account. From here you can create a user to connect to the database for your PHP scripts. Last thing we will do is check to see how much memory is being used up by our new LAMP Server. To do that run: <blockquote>free –m</blockquote> After a reboot my system indicates I’m using 58MB RAM. Not bad for a full suite of server applications. That’s it, you have successfully set up a LAMP Server on Debian. Congratulations!

carlos on "Debian Etch - Apache Virtual Hosts"

carlos — Mon, 15 Jun 2009 03:42:46 +0000

This wiki article is intended to help you set up name based virtual hosts on the Apache Web server. Apache allows you to host several different domains and subdomains on a single IP. While this is an integral part of Apache, many people seem to struggle with setting up such a scenario. We will assume you already have Apache installed and configured on your webby. Also, we will assume you are trying to host two sites; <a href="http://www.siteone.com," rel="nofollow">www.siteone.com,</a> which also hosts a blog on blog.siteone.com, and <a href="http://www.sitetwo.com" rel="nofollow">www.sitetwo.com</a> Adding Hosting Directories By default, Apache serves files that are located in the hosting root folder, usually /var/www. You can put your site files just about anywhere, just make sure to be consistent and organized. For this article we will be creating the following directories for our first domain: <blockquote>mkdir /var/www/www.siteone.com mkdir /var/www/www.siteone.com/public mkdir /var/www/www.siteone.com/private mkdir /var/www/www.siteone.com/cgi-bin mkdir /var/www/www.siteone.com/logs</blockquote> And so on… repeating the process for <a href="http://www.siteone.com" rel="nofollow">www.siteone.com</a> with blog.siteone.com and <a href="http://www.sitetwo.com." rel="nofollow">www.sitetwo.com.</a> This gives you the directories to place your publically served files in public, files you do not want to expose in private, CGI scripts in cgi-bin, logfiles in logs. Configure Virtual Hosts Next, we will add the configuration for each site to the default Apache configuration file found in /etc/apache2/apache2.conf <blockquote>NameVirtualHost *:80 <VirtualHost *:80> ServerName <a href="http://www.siteone.com" rel="nofollow">www.siteone.com</a> DocumentRoot /var/www/www.siteone.com/public/ # Logfiles ErrorLog /var/www/www.siteone.com/logs/error.log CustomLog /var/www/www.siteone.com/logs/access.log combined </VirtualHost></blockquote> Notice we added NameVirtualHost * to the beginning of the configuration. This is to enable multiple host support and only needs to be specified once in the config. Then repeat for your subdomain (blog.siteone.com) and second domain (www.sitetwo.com): <blockquote><VirtualHost *:80> ServerName blog.siteone.com DocumentRoot /var/www/blog.siteone.com/public/ # Logfiles ErrorLog /var/www/blog.siteone.com/logs/error.log CustomLog /var/www/blog.siteone.com/logs/access.log combined </VirtualHost> <VirtualHost *:80> ServerName blog.siteone.com DocumentRoot /var/www/www.sitetwo.com/public/ # Logfiles ErrorLog /var/www/www.sitetwo.com/logs/error.log CustomLog /var/www/www.sitetwo.com/logs/access.log combined </VirtualHost></blockquote> This sets up two sites, which have their docements and logfiles contained beneath /var/www/nameofsite.com. You can adjust the paths if you wish to keep the files elsewhere. Now put some content in the public folders. To finish off, just restart Apache: <blockquote>/etc/init.d/apache2 restart</blockquote> That's it. Hopefully now you should be able to surf to your new sites through unique domain names. If you run into a problem don't forget to add DNS zones for your new sites. Congratulations on setting up virtual hosts!

carlos on "Debian Etch - Security & Hardening"

carlos — Mon, 15 Jun 2009 03:40:46 +0000

This wiki article will cover basic security in Debian, from securing SSH to installing and configuring iptables. You will learn how to restrict access to your webby to a small number of selected individuals (or PCs) and design a very simple but effective firewall solution. Sudo & SSH First of all, if you are still using the root account to manage your webby you should know that this can be hazardous if your webby is ever compromised. For this reason let's create a new superuser that will have admin permissions. Obviously replace the username with something else and choose a good, long password: <blockquote>adduser newsuperuser</blockquote> We will need to add the user to sudo so that you can perform administrative tasks. This is changed in the /etc/sudoers file or by just typing 'visudo': <blockquote>nano /etc/sudoers</blockquote> If, for some reason, you do not have sudo installed you can install it with: <blockquote>apt-get install sudo</blockquote> In /etc/sudoers you want to add the privileges for the new user to the end of the file. There should already be a root user in there so copy that line: <blockquote>newsuperuser ALL=(ALL) ALL</blockquote> Let’s take a look at the default SSH configuration: <blockquote>nano /etc/ssh/sshd_config</blockquote> We want to change the port SSH uses to an ambiguous, indistinct number. Look for the line that says ‘Port 22’ and change it. For example, <blockquote>Port 12345</blockquote> The next level of security to apply to SSH is to disallowing login by the root user. You’ll want to search for the “PermitRootLogin yes” line and change it to deny root login attempts, as such: <blockquote>PermitRootLogin no</blockquote> Finally, restart the SSH service: <blockquote>/etc/init.d/ssh restart</blockquote> Now log out and log back in with your new superuser account. You should now have a pretty tightened down machine when it comes to SSH, stopping most brute force crack attempts in their tracks. Let’s move on to the next topic. iptables Iptables is defined as a “user space tool by which administrators create rules for the packet filtering”, but for simplicity iptables is just a firewall within Linux. If for some reason it’s not on your webby, iptables can be installed with apt-get, as such: <blockquote>sudo apt-get install iptables</blockquote> We’ll have iptables open and close ports that will be commonly used; ssh, http, and https. Note that changing iptables rules will require us to be logged in as root again. To switch to the root user type: <blockquote>sudo -i</blockquote> As root, lets backup existing rules to /etc/iptables.rules and check which rules are currently running <blockquote>iptables-save > /etc/iptables.old.rules iptables -L</blockquote> You will see some output that basically indicates all connects are open for incoming and outgoing traffic. Lets add some rules to iptables. First, let’s allow all outbound traffic and incoming ping requests: <blockquote>iptables -A OUTPUT -j ACCEPT iptables -A INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT</blockquote> Next, allow incoming ssh, http and https connections: <blockquote>iptables -A INPUT -p tcp --dport 80 -j ACCEPT iptables -A INPUT -p tcp --dport 443 -j ACCEPT iptables -A INPUT -p tcp -m state --state NEW --dport 12345 -j ACCEPT</blockquote> Remember that the –dport should be the same as the one you set in /etc/ssh/sshd_config. Next, lets enable denied call logging, previously established connections and allow loopback traffic : <blockquote>iptables -A INPUT -m limit --limit 15/min -j LOG --log-level 7 --log-prefix "iptables blocked: " iptables -A INPUT -s 127.0.0.1 -j ACCEPT iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT</blockquote> Last but not least, deny all other incoming traffic: <blockquote>iptables -A INPUT -j REJECT iptables -A FORWARD -j REJECT</blockquote> Pass the ‘iptables –L’ command again to make sure everything looks good. Keep in mind that these are just basic rules and I encourage you to explore iptables further if you wish to learn the more advanced features. Let’s apply the rules and permanently save them on our webby: <blockquote>iptables-save > /etc/iptables.rules</blockquote> Now we need to make sure that the iptables rules we created survive a reboot. Even though they are saved in /etc/iptables.up.rules, they are not loaded by default when the webby restarts. To make the rules load during start, edit the /etc/rc.local file <blockquote>nano /etc/rc.local</blockquote> and add the following line of code to the end of the file <blockquote>iptables-restore < /etc/iptables.rules</blockquote> Just as you would expect, this will restore the iptables rules from the /etc/iptables.rules file. Now restart your webby and give another ‘iptables –L’ command (from root) to make sure the changes were effective. If everything looks normal, congratulations on securing your webby!

carlos on "Debian Etch - Setup and Updating"

carlos — Mon, 15 Jun 2009 01:57:39 +0000

Setup & Updating This article will walk you through basic setup and updating procedures to get your webby ready for web hosting, development, or whatever else you may choose to do with it. It is meant to give you a better understanding of the Debian environment and what is happening within it. Account Management Let’s begin by setting up a few basics. Connect to your webby as root using your favorite SSH client, or optionally you may work from console, accessible from the management portal. Once you’re logged in, immediately change your root password. <blockquote>passwd</blockquote> As you may know, for security reasons it’s not recommended to log in to your webby using the root account. We only logged in with root this one time to do the initial setup. With that in mind, let’s create a user we will be using instead of root from now on. Choose your own name instead of poweruser. <blockquote>adduser poweruser</blockquote> Now we must give the poweruser account some administrative rights. Before we can do that though, it may be necessary to install sudo onto your webby. <blockquote>apt-get install sudo</blockquote> Sudo stands for super user do and it enables a regular user such as poweruser to run administrative tasks that would typically be available only to root. To enable sudo for the new user, let’s look at the /etc/sudoers file and give our new user super user privileges. <blockquote>nano /etc/sudoers</blockquote> Add to the end of file: <blockquote>poweruser ALL=(ALL) ALL</blockquote> You should now be able to log in with your new account and use sudo to perform administrative tasks. When you run a command using sudo, you will be asked for the root password. Updating the base system We are now ready to update our webby. Let’s start by updating the list of packages available to us. <blockquote>sudo apt-get update</blockquote> Updating works by looking at a list of repositories located in /etc/apt/sources.list. If you plan to install 3rd-party or non-standard software, you may wish to edit your sources.list with your favorite editor (I use nano). <blockquote>sudo nano /etc/apt/sources.list</blockquote> To install the latest security updates and bug fixes, type the full upgrade commands: <blockquote>sudo apt-get upgrade sudo apt-get dist-upgrade</blockquote> After the first command you may be asked to set your timezone. If you are not you may now set it manually for your home location. <blockquote>sudo ln -sf /usr/share/zoneinfo/America/New_York /etc/localtime</blockquote> This creates a symbolic link from /etc/localtime to a file in /usr/share/zoneinfo corresponding with what zone you are in. Have a look in the directories under /usr/share/zoneinfo to see what timezones are available. Resource Checks Before we finish, we’ll run several system utilities to verify the resources on your webby. Start by looking at the memory usage. free –m You should see a table reporting your memory usage. Focus your attention on the second line, starting with -/+ buffers/cache. Under the used column, you will see how much memory applications on your webby use. Above that you might see a higher number, but this is because it reports memory already used for buffers and cached. A more powerful command, top, shows how much processing power and memory is being used and for which running processes. <blockquote>top –bn 1</blockquote> This will run top in batch mode with one iteration, so that you get a nice and clean output of everything running. Keep in mind that running top with the -bn switches is like taking a snapshot, while running it without them would provide you an ongoing look at processor activity in real-time. Next, let’s take a look at disk usage: <blockquote>df</blockquote> Df simply shows the amount of total and available disk space on a file system. Well, now your system is up to date, you have a new user account that can perform administrative tasks, and you are aware of the resources in your working environment. Whatever your choose to use it for, you should now be aware of how to take your webby from a barebones system to something with a little more meat on it.

carlos on "Unattended Ruby / Passenger Installation"

carlos — Mon, 15 Jun 2009 01:51:01 +0000

For those who are lazy and like script try <a href="http://gist.github.com/37213">this script</a> to setup a rails stack using ruby enterprise and the marvelous passenger gem. Download and run the script, get a cup of joe and return to deploy your applications on your fresh stack. <blockquote>#!/bin/bash # Unattended REE/Passenger installation # Source: <a href="http://weblog.brightlight-ict.nl/2008/12/unattended-passenger-ruby-enterprise-installation-on-ubuntu-8/" rel="nofollow">http://weblog.brightlight-ict.nl/2008/12/unattended-passenger-ruby-enterprise-installation-on-ubuntu-8/</a> # 15/03/09 Updated to use latest r.e.e. and passenger 2.1 and rewrote bits thanks to the comments left on my blog. Thanks guys if [ "$(whoami)" != "root" ]; then echo "You need to be root to run this!" exit 2 fi VERSION="1.2" REEV="http://rubyforge.org/frs/download.php/51100/ruby-enterprise-1.8.6-20090201.tar.gz" REEF="ruby-enterprise-1.8.6-20090201.tar.gz" REEFF=${REEF%".tar.gz"} PASSENGER="2.1.2" export PASSENGER echo "#####################################" echo "Welcome, let's get this party rollin'" echo "#####################################" echo "Updating Aptitude" apt-get update echo "Installing build essentials" apt-get install build-essential zlib1g-dev libssl-dev wget libreadline5-dev -y echo "Installing GIT" apt-get install -y git-core echo "Installing apache" apt-get install -y apache2 echo "Installing apache headers" apt-get install -y apache2-prefork-dev echo "Installing Ruby Enterprise from following url" echo $REEV wget $REEV if [ -e $REEF ] then echo "File downloaded succesful" else echo "Error, file wasn't downloaded!" exit fi tar -zxvf $REEF # possible options perhaps for checker # --extra rails --no-tcmalloc if [ -d ./$REEFF ] then ./$REEFF/installer --auto /opt/ruby echo "Dir test" else echo "Dir not found, exiting.." exit fi echo "Creating ruby symlinks" ln -s /opt/ruby/bin/ruby /usr/bin/ruby ln -s /opt/ruby/bin/gem /usr/bin/gem ln -s /opt/ruby/bin/rake /usr/bin/rake ln -s /opt/ruby/bin/rails /usr/bin/rails echo "Installing other gems" gem install rails gem install will_paginate gem install shoulda gem install mysql echo "Installing passenger" gem install passenger -v=$PASSENGER echo "Config passenger" yes '' | /opt/ruby/bin/passenger-install-apache2-module echo "Copying passenger files" touch /etc/apache2/mods-available/passenger.load touch /etc/apache2/mods-available/passenger.conf echo "LoadModule passenger_module /opt/ruby/lib/ruby/gems/1.8/gems/passenger-$PASSENGER/ext/apache2/mod_passenger.so" >> /etc/apache2/mods-available/passenger.load echo "PassengerRoot /opt/ruby/lib/ruby/gems/1.8/gems/passenger-$PASSENGER PassengerRuby /opt/ruby/bin/ruby" >> /etc/apache2/mods-available/passenger.conf echo "Enabling passenger module" a2enmod passenger echo "Reloading apache" /etc/init.d/apache2 reload echo "##########################" echo "# Installation Complete" echo "##########################" sleep 2 echo "##########################" echo "# Installed Ruby Version #" echo "##########################" ruby -v echo "##########################" echo "# Installed Gems Version #" echo "##########################" gem -v /opt/ruby/bin/passenger-status</blockquote> Contributed by Maran

carlos on "Ubuntu Hardy - Creating a RubyGems Mirror With HTTP Basic Authentication"

carlos — Mon, 15 Jun 2009 01:48:00 +0000

Would you like to create your own RubyGems remote repository that bypasses the sometimes overloaded RubyForge mirrors? Here's how. In addition, you can see how to create a repository that is user/password protected, which allows you to restrict the repository for remote and internal use, preventing public Internet usage of the server and your company's bandwidth. This article also explains how to set up each user environment to access the remote repository that is created. Note: The following environment was used for the procedures in this article: Solaris 10 Operating System, Apache version 2.2.6, Ruby version 1.8.6p114, and RubyGems version 1.2.0. The Apache2 package was installed via CSK 1.2, see Optimized Open Source Software Stack (Cool Stack). Repository Access Method After Completion After using the procedures in this article, you should have two repositories that have a setup similar to the following (but with a different domain, that is, not blah.com) and a user/password combination: <li><a href="http://gems.blah.com/dev:" rel="nofollow">http://gems.blah.com/dev:</a> This gets updated from RubyForge every Sunday morning at 3 a.m.</li><li><a href="http://gems.blah.com/stable:" rel="nofollow">http://gems.blah.com/stable:</a> This is a stable list of gems used for QA, staging, and production environments. This should be used for environments that standardize on software.</li> You can then access your repository using the following authentication method: user: gems pass: password Prerequisites 1. First, upgrade your RubyGems to the latest and greatest version, if possible (at the time of this writing, 2.1.0). 2. Then download the prerequisite Cool Stack (CSKruby) package and install it. 3. Use the following command to install the gem builder (XML Builder library) that is used to create the yaml index: gem install builder Creating RubyForge Mirror 1. Set up the mirror configuration file by creating a /root/.gemmirrorrc file with the following: — - from: <a href="http://gems.rubyforge.org/" rel="nofollow">http://gems.rubyforge.org/</a> <blockquote>to: /gemrepo/dev</blockquote> This example creates an “everything” repository that's the latest and greatest within the /gemrepo/dev directory. Change this directory location to suit your needs. 2. To download gems, run the gem command to create the mirror. (You may want to run this in screen mode.) gem mirror 3. Create a yaml index file that has all the gem information. (You may want to run this in screen mode.) gem generate_index -d /gemrepo/dev Note: This command should be run in the directory that contains the gems directory. Sample output: gem generate_index -d /gemrepo/dev Loading 15132 gems from /gemrepo/dev …………………………………….. …………………………………….. …………………………………….. … Setting Up Apache Permissions Next, set up HTTP basic authentication against the gem repository, so users must authenticate to access the repository. Requiring authentication enables you to control who can use the server and prevents the repository from being publicly available. This is useful if you want to control what is distributed. For instance, here is an example based on the domain blah.com. Change the domain to match your environment settings. <blockquote><VirtualHost *:80> ServerName gems.blah.com ServerAdmin <a href="mailto:webmaster@blah.com">webmaster@blah.com</a> DocumentRoot /gemrepo <Directory /> Options Indexes FollowSymLinks MultiViews AllowOverride None </Directory></blockquote> <blockquote> <Directory /gemrepo/ > Options Indexes FollowSymLinks MultiViews AllowOverride None AuthName "Dev Access" AuthType Basic AuthBasicProvider file AuthUserFile /opt/coolstack/apache2/conf/htpasswd.users Require user gems # user: gems # pass: password Order allow,deny allow from all </Directory></blockquote> ErrorLog /var/log/httpd/error-gems.log LogLevel warn CustomLog /var/log/httpd/access-gems.log combined ServerSignature Off </VirtualHost> Configuring Ruby Client Since you're using your own repository with a password (so the public doesn't mooch off of you), you need to include a $HOME/.gemrc file by using the following: <blockquote># cat $HOME/.gemrc gem: –source <a href="http://gems:password@gems.blah.com/dev/" rel="nofollow">http://gems:password@gems.blah.com/dev/</a></blockquote> Note: The /dev/ can be changed to match your environment, for example, /stable/. Creating Other Repositories The /dev repository has every gem available and its version. You can then create a /gemrepo/stable/gems directory with all the gems you standardize for, let's say, production, staging, and QA, since these should have a similar repository setup. Once, you copy the gems, you then just create the index in the parent, for example: <blockquote>cd /gemrepo/stable gem generate_index -d /gemrepo/stable</blockquote> Change your $HOME/.gemrc file to reflect the changes. Keeping Your Repository Up to Date Create a script that will update the repositories. <blockquote># cat /root/bin/gem-mirror.sh</blockquote> <blockquote>#!/bin/ksh # Author: William D. Pool # Description: This will update the dev mirror with # The latest gems. It will also run an index on dev / stable # So, everything is clean, you still have to manually place # a gem into the /gemrepo/stable/gems directory for it to be # indexed! # # Put into Crontab # # 30 3 * * 0 /root/bin/gem-mirror.sh > /dev/null 2>&1 # gem mirror –no-verbose -q gem generate_index -d /gemrepo/dev gem generate_index -d /gemrepo/stable</blockquote> Throw it into cron! <blockquote>30 3 * * 0 /root/bin/gem-mirror.sh > /dev/null 2>&1</blockquote>

carlos on "Ruby on Rails - Ubuntu Hardy"

carlos — Mon, 15 Jun 2009 00:37:03 +0000

Ruby on Rails is a web application framework designed to make web development faster, simpler, and more efficient. This wiki article will show you how you can install Ruby on Rails and configure it to work with a web server and database on your webby. Ruby is a interpreted programming language inspired by Perl and Ada and designed over 10 years ago. Rails is a web application framework written in Ruby. Although Rails supports several different databases and web servers, we will be installing Nginx and MySQL alongside Ruby on Rails. Throughout the article we will use a mixture of different installation procedures, using apt-get in some situations and installing from source in others. Installing the Essentials We'll be hosting our RoR apps using Nginx, Mongrels and MySQL. I chose this configuration because I saw much better benchmark results while testing the different front ends and database servers. But of course you can use your own combination as you see fit. First, we will install the build-essentials package needed to make many source installations: <blockquote> apt-get install build-essential</blockquote> Now go ahead and install Nginx: <blockquote>apt-get install nginx</blockquote> Next, we install MySQL and the required Ruby API: <blockquote>apt-get install mysql-server mysql-client libmysqlclient15-dev libmysql-ruby</blockquote> You will be asked for a password during install. Give it any password you like. Later, you can change your MySQL root password with this command: <blockquote> mysqladmin -u root -p password new_password</blockquote> <blockquote>Installing Ruby, Gems and Rails</blockquote> Let's proceed with the Ruby install. We will be installing everything including documentation (RDoc and Ri): <blockquote> apt-get install ruby1.8-dev ruby1.8 ri1.8 rdoc1.8 irb1.8 libreadline-ruby1.8 libruby1.8</blockquote> After Ruby install finishes we need to create some dynamic links from the install location: <blockquote> ln -s /usr/bin/ruby1.8 /usr/local/bin/ruby ln -s /usr/bin/ri1.8 /usr/local/bin/ri ln -s /usr/bin/rdoc1.8 /usr/local/bin/rdoc ln -s /usr/bin/irb1.8 /usr/local/bin/irb</blockquote> You can varify the version with: <blockquote> ruby -v</blockquote> Now we'll need to install RubyGems, "the Ruby standard for publishing and managing third party libraries". Basically it will let us download Rails and any other framework packages later on. Head on over to <a href="http://rubyforge.org/projects/rubygems/" rel="nofollow">http://rubyforge.org/projects/rubygems/</a> and grab the latest release (v. 1.3.1 at the time of writing this). Download it right to the root of your stack and extract: <blockquote>wget <a href="http://rubyforge.org/frs/download.php/45905/rubygems-1.3.1.tgz" rel="nofollow">http://rubyforge.org/frs/download.php/45905/rubygems-1.3.1.tgz</a> tar -xvf rubygems-1.3.1 cd rubygems-1.3.1.tgz</blockquote> Now we need to compile it and create another symlink: <blockquote> ruby setup.rb ln -s /usr/bin/gem1.8 /usr/bin/gem</blockquote> Check your version of Gems with: <blockquote> gem -v</blockquote> Now install rails using RubyGems: <blockquote> gem install rails</blockquote> Rails installation might take a while, but after it is finished you can verify your installation with: <blockquote> rails -v</blockquote> Now we'll go ahead and install a the mongrel web server and mongrel cluster. Mongrel is a lightweight web server that Nginx will proxy requests to. We'll use mongrels to serve our RoR applications faster: <blockquote> gem install mongrel gem install mongrel_cluster</blockquote> Now you can create a new rails application for testing, calling it 'railsapp'. It doesn't really matter where you make it but I chose the /var/rails directory: <blockquote> mkdir /var/rails cd /var/rails rails railsapp</blockquote> You will see rails create the files needed by our first application. Great, everything is installed and we are ready to move on and do some basic configuration. Configuring Nginx and Mongrel Now that everything we need is installed there are only but a few steps left to tie it all together and make it work. Let us first take a look at the Nginx configuration and point it to our new application. Create a new config file in Nginx's sites-available directory that you would like pointing to the dummy app we made (replace domain.com with your domain): <blockquote>nano /etc/nginx/sites-available/railsapp.domain.com</blockquote> Paste the following into the new configuration and edit whatever is needed to change, such as the location of the application or your domain name: <blockquote> upstream railsapp { server 127.0.0.1:5000; server 127.0.0.1:5001; server 127.0.0.1:5002; } server { listen 80; server_name railsapp.domain.com; access_log /var/rails/railsapp/log/access.log; error_log /var/rails/railsapp/log/error.log; root /var/rails/railsapp/public/; index index.html; location / { proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header Host $http_host; proxy_redirect false; if (-f $request_filename/index.html) { rewrite (.*) $1/index.html break; } if (-f $request_filename.html) { rewrite (.*) $1.html break; } if (!-f $request_filename) { proxy_pass <a href="http://railsapp;" rel="nofollow">http://railsapp;</a> break; } } }</blockquote> The first few lines of the configuration are the proxy to mongrels, which we will configure next. But first, proceed by creating a symbolic link to the sites-enabled directory to enable our new virtual host: <blockquote> ln -s /etc/nginx/sites-available/railsapp.domain.com /etc/nginx/sites-enabled/railsapp.domain.com</blockquote> Now let's move into our new rails application and create a mongrel cluster: <blockquote> cd /var/rails/railsapp mongrel_rails cluster::configure -e production -p 5000 -N 3 -c /var/rails/railsapp -a 127.0.0.1</blockquote> This will create a mongrels configuration in YAML format in config/mongrel_cluster.yml. You can open this file any time to change the parameters mongrels uses. The last thing we need to do is start the mongrel cluster from within our railsapp directory: <blockquote> mongrel_rails cluster:start</blockquote> Also, go ahead and restart Nginx to apply the new virtual host we created <blockquote> /etc/init.d/nginx restart</blockquote> You can now browse to your site (http://railsapp.domain.com) and see your new Rails application in action. This is all you need to get started with Ruby on Rails hosted on your webby. Good luck and happy hacking!

carlos on "Ubuntu Hardy - Multiple Rails Apps with Passenger"

carlos — Mon, 15 Jun 2009 00:28:58 +0000

The installer provides exhaustive built-in documentation, describes every step and suggests solution for every unmet requirement like “please install Apache headers with apt-get install apache2-prefork-dev”. Other guys and we all can learn a lot from mod_rails about how a perfect installer looks like. At the end of the installation process it asks to put three configuration lines into apache configuration file although it does not tell how. According to online documentation the requirement is that these lines should be only executed once. So my solution (in Debian way) is to create new passenger.load file in /etc/apache2/mods-available create a symbolic link to it a2enmod passenger Then I followed the documentation. But I had to make an additional change to enable the FollowSymLinks. It was also not clear from the documentation how to set up multiple applications to the same VirtualHost and that RailsBaseURI is allowed multiple times. So I had to experiment. Here is the result (works on Ubuntu 7.10): <blockquote><VirtualHost *:80> ServerAdmin <a href="mailto:admin@example.com">admin@example.com</a> ServerName myapps.example.com DocumentRoot /home/passenger RailsBaseURI /app1 RailsBaseURI /app2 <Directory /home/passenger> AllowOverride All </Directory> </VirtualHost></blockquote> Then for every additional application you need to copy your application to some folder, e.g. /home/myprojects/app2 set owner for your project folder to www-data:www-data create a link from public folder of your rails application to /home/passenger add one line to your site configuration RailsBaseURI /app2 restart apache I did not find any way to avoid last two tasks. Hopefully the next version of passenger will offer some sort of wildcard-based mass-RailsBaseURI. Current mod_proxy advantages: no ActionController::AbstractRequest.relative_url_root requierd anymore no obscure mod_proxy_html SSL is now possible for multiple Rails applications on the same server (VirtualHosts on the same IP address do not work with SSL) TODO: did not have time yet to configure with capistrano, simply checked in the file `tmp/restart.txt’. Every time I do ‘svn update’, the application is automatically restarted.