Introduction

This walkthrough is for (K)Ubuntu Lucid 10.04 (32-bit or 64-bit) because the BigBlueButton teleconferencing server requires either Lucid 10.04 (32-bit or 64-bit) or Jaunty 9.04 (32-bit only).

The software updater may prompt you to upgrade the distribution to a newer release (e.g. to Maverick 10.10). This is not recommended because BigBlueButton may then stop functioning properly.

All variables that can be (and usually ought to be) changed are noted in italics. Do not attempt to use any italicized variable exactly as written; all of them are fictitious and will not work (especially for web services)! Create your own variable in place of the italicized one.

Furthermore, this website is viewed by over 20,000 users per month. Don't attempt to use any of the example passwords used here (that would be highly insecure). Create your own passwords.

Install Ubuntu Lucid Server (32-bit or 64-bit) into its own partition. If you followed the Multiple OS Installation scheme, then the Windows OS will be in partition 1 (and possibly 2, if you have a recovery partition), the /boot partition will be in partition 3, and partition 4 will be an extended partition. The extended partition ought to have been divided into a 2 Gb swap logical partition and 2 equally sized logical partitions for Linux (one for a production partition and one as a test/upgrade partition).

For installation it is best if the computer is connected to the Internet by a wired ethernet connection.

Hostname: Lucid64Server00

Partitioning: Manual

Choose the partition created for the new Lucid operating system (e.g. /dev/sda6). Use as: Ext4 journaling file system -> Format the partition: yes, format it -> Mount point: / - the root file system -> Done setting up the partition -> Finish partitioning and write changes to disk -> Write changes to disk?: Yes

During the Ubuntu Server installation, install the LAMP server and OpenSSH servers and the PostgreSQL database. Record the system administrator ID/password and the MySQL root (superuser) password. Note the partition name and number (e.g. /dev/sda6).

Full name for the new user: Lucidadmin00 -> Username for your account: lucidadmin00 -> Choose a password for the new user: lucidword00

(Note: You could also generate a random password and use it here. Just be sure to record it in an accessible location.)

Note: You could also install the LAMP server stack, the OpenSSH server, or the PostgreSQL database at a later time using the menu-driven installation system:

sudo tasksel

Encrypt your home directory: No (this is optional, but on this system the primary user's home directory is not used much so there is little need to encrypt it.)

HTTP proxy information -- this is used if your organization has a firewall or other gateway to the outside Internet. A network administrator will have the information for this. Most small businesses will not have such a gateway and it can be left blank, in this case.

How do you want to install updates...? No automatic updates

This is, of course, user preference. However, updates are sometimes sent out before they are completely tested with all hardware, which can cause problems with very new or very old hardware. Some systems can be brought to a halt by automatic updates, especially updates of the Linux kernel.

For this reason, complete manual control of updates is highly recommended (on production systems). In fact, many users routinely run two parallel systems (a test system and a production system) and install updates on the test system first (in order to make sure all updates work properly) prior to installing the updates on the production system. This practice is extremely important to ensuring stability on critical systems and servers.

Note: this assumes a /boot partition and multiple partitions. Under the general scheme above, the first free partition will usually be /dev/sda6, but if you already have other OSs or other peculiarities, take extra care during this step.

This is the trickiest step of the installation. It is important to set up the Master Boot Loader to recognize the new partition. Re-read the Multiple OS Installation tutorial very carefully and completely. In short, the bootloader needs to be copied to the /boot partition (usually /dev/sda3) and customized there so that it chainloads the bootloader installed locally in your new OS partition (e.g. /dev/sda6). Once this is set up correctly, reboot and the menu will allow booting into the new OS.

Note: This step was also previously required after every kernel upgrade (as is done automatically if you have enabled automatic updates). If graphics aren't working for any reason, try making sure the headers are installed correctly and updating again.

Install the password generator for use with the remainder of the installation.

sudo apt-get install pwgen

Many users also generate a password for the root superuser at this time:

sudo passwd root

Add an Ubuntu desktop

Install an Ubuntu desktop.

sudo apt-get install ubuntu-desktop

Note: The end user can also install the restricted extras:

sudo apt-get install ubuntu-restricted-extras

Reboot the system:

sudo reboot

Once the Ubuntu desktop has been installed, all commands can then be entered into the command-line terminal Terminal:

Menu -> System -> Terminal

Note: Ubuntu Jaunty included an (automatic) kernel upgrade that at some point disabled the Nvidia graphics drivers (on computers with Nvidia graphics). If this happens for your system, the desktop will be unable to start at bootup and only the command-line will be presented. To correct this problem, merely install the linux-headers again:

sudo apt-get install linux-headers-$(uname -r)
sudo reboot

then the Nvidia graphics drivers should install correctly and the desktop will start normally.

Enable BIOS power-up

Power failures happen. It is possible to change the BIOS settings so that after a power failure the computer will automatically powerup and restart to the default OS (as set in the bootloader configuration). This is a critical function for servers. At bootup, enter the BIOS menu using whichevever key is appropriate for your computer's BIOS:

Obtain an Internet URL

If a static Internet URL is not available, obtain a dynamic DNS URL. (This must be changed for each OS installation, as it is specific to that installation).

Create an email account for administrative use with this server, such as at mail.com, mail.google.com, or mail.yahoo.com. (mylucid.userid00@mail.com / mylucidword000 / 1/1/01 / securityquestionanswer)

Create a DynDNS account for use with this server, at DynDNS.org. (myluciddnsid / myluciddnsword / mylucid.userid00@mail.com)

In this walkthrough, several URLs are used. It is possible to create all of them at once at this stage:

mylucid00.dyndns.org

mylucidbbb00.dyndns.org

mylucidwiki00.dyndns.org

mylucidweb00.dyndns.org

DynDNS allows 5 free URLs. After installation has been completed, I generally remove mylucidweb00.dyndns.org and create mylucidcalendar00.dyndns.org (for use with DAViCal) instead.

Adjust SSH for remote connections

If the OpenSSH server was not installed on your server at initial installation, it can be installed now.

sudo tasksel install openssh-server

The default SSH port is 22, but this may conflict with other SSH servers on your network. Change the SSH port to a custom port. Also disallow password-based logins, for now, to prevent unauthorized logins. See this tutorial.

sudo gedit /etc/ssh/sshd_config

change the listening port:

Port 22199

and disallow Password-based authentication by changing the line::

#PasswordAuthentication yes

to

PasswordAuthentication no

Make sure the OpenSSH server knows that it must look for the authorized_keys file. Uncomment the line:

#AuthorizedKeysFile %h/.ssh/authorized_keys

so that it resembles:

AuthorizedKeysFile %h/.ssh/authorized_keys

then restart the OpenSSH server:

sudo /etc/init.d/ssh restart

Make sure the router forwards the selected listening port (e.g. 22199) to the IP address (e.g. 192.168.0.99) of the server.

Make sure that a file named authorized_keys (with write privileges) is in that folder. If not, create such a file (using the touch command to create an empty file) while logged into the server as serveruser (i.e. lucidadmin00):

cd ~/.ssh
touch authorized_keys

Concatenate the newly-generated id_rsa.pub key to the authorized_keys file:

(Note: It is pointed out to me repeatedly that Firestarter is not being currently updated. However, Firestarter is not the actual firewall. iptables is, and iptables is continually updated as part of the Linux kernel. Firestarter is merely an easy-to-use front-end for editing the iptables rules that has been stable for a long time. Other choices for this task include ufw/gufw (which is markedly more difficult to use, IMO). This is completely an area of user preference. The instructions above for Firestarter are not easily transferable to ufw/gufw.)

-> Input the IP address/URL of your BigBlueButton server (mylucidbbb00.dyndns.org:81). Do not enter the leading http:// .

-> Input the Security Salt from your BigBlueButton server. This is in a file called “bigbluebutton.properties” on the BigBlueButton server. On my Ubuntu server I found it at /var/lib/tomcat6/webapps/bigbluebutton/WEB-INF/classes/bigbluebutton.properties:

-> Put a star in the Meeting IDs field. That will allow an unlimited number of rooms to be created. You can also put any number here to restrict how many rooms on your BigBlueButton server you want running at any one time. (This can eventually become important for performance reasons.)

In addition, a private wiki page should only be able to be read by registered users, so add these lines to LocalSettings.php for any private subwiki:

#This example will disable viewing of all pages not listed in $wgWhitelistRead, then re-enable for registered users only:
$wgGroupPermissions['*']['read'] = false;
# The following line is not actually necessary, since it's in the defaults. Setting
# '*' to false doesn't disable rights for groups that have the right separately set
# to true!
$wgGroupPermissions['user']['read'] = true;

This is a complex rule that means that as long as the REQUEST_URI (which is the part after the server name, i.e. http://mylucidwiki00.dyndns.org/REQUEST_URI) does not match private or public (the symbol ! means not), then use public as the default directory.

Remember that your virtual host configuration file won't be active until you make a symbolic link:

-> Change the Security Salt (found in a file called “bigbluebutton.properties” on the BigBlueButton server). On my Ubuntu server I found it at /var/lib/tomcat6/webapps/bigbluebutton/WEB-INF/classes/bigbluebutton.properties:

Note: There are companies on the Internet other than DynDNS.com that provide Dynamic DNS services as well (but several of them are very unreliable, in my experience). DynDNS.com is one of the oldest and most stable. I have found it convenient to forward my URLs (that I already had at other DNS providers) to the DynDNS URLs created in this walkthrough. However, if your original DNS provider supports reliable Dynamic DNS services, you may be able to get it to work with ddclient as well. See the instructions in the tutorial.

Using the Menu Editor, create a menu item to Shoutcast Internet Radio with the command:

firefox http://classic.shoutcast.com

Start Shoutcast Internet Radio and click on a radio station. When prompted for the file association, choose Audacious:

"You have chose to open shoutcast-playlist.pls which is a: PLS file. What should Firefox want do with this file?" -> Open with ... -> Browse -> File system... -> usr -> bin -> audacious -> Open -> Do this automatically for files like this from now on: (ticked) -> OK

Install DAViCal group calendar server

If a full groupware server (Kolab, eGroupware, or Zimbra) is to be installed, there is no need for DaviCal. As a standalone group calendar server, though, it can't be beat.

Allow Reverse proxies

If you have one LAN router that forwards all port 80 traffic to a single server yet you have multiple physical servers on the LAN (each using their own set of URLs), then the primary server (to which all port 80 traffic is sent) will have to act as a reverse proxy for the other servers. This is accomplished through Apache2 reverse proxies. See this tutorial.

Adding new SSH users

On the server, create a second user account (that guest users can use for SSH purposes) with a password dissimilar to any other passwords (such as mylucidguestpassword):

Note: this new /home/lucidadmin00/.ssh/authorized_keys file should also be copied to /home/client9260/.ssh/authorized_keys and /home/text9260/.ssh/authorized_keys as detailed in the subsequent OpenVistA EHR section.

If Windows-based PuTTY SSH users are to be added to the system, then see this tutorial. The SSH keys must be tweaked to be used with OpenSSH, copied to the server, and then concatenated to the authorized_keys file in a similar fashion.

Add security scanners

Don't believe the hype about Linux being free from viruses, trojans, and rootkits. They happen (although less common than in other operating systems). The biggest risk comes from installing software from repositories other than official Ubuntu repositories. Be careful. Here are some recommended security utilities:

Install an EHR (Electronic Health Record) system

Although these instructions are for OpenVistA EHR, other VistA EHR derivatives can be installed in a somewhat similar fashion.

The OpenSSH server was set to listen on port 22199. Make sure the router forwards port 22199 to this computer's LAN IP address. The OpenSSH server will be reached by tunneling to myjaunty00.dyndns.org using port 22199.

Note: When running from a menu item shortcut, make sure you set the directory as the workpath. I place the menu items in a separate submenu named EHR. Although the OpenVistA-CIS client uses port 9201 by default, the Astronaut OpenVistA server uses port 9260 by default.

Note: If you wish to connect directly through the network (without using an SSH tunnel), merely replace --server=127.0.0.1 with --server=myjaunty00.dyndns.org and make sure the LAN's router forwards port 9260 to the LAN IP address of the server (and make sure that all firewalls allow port 9260 to be open).

Use your Access Code / Verify Code as the LoginID / Password ( default at installation for Astronaut systems is sys.admin / vista!123 ). This should be changed at the initial connection, e.g. to vista!456.

Connecting through an SSH tunnel

This method is necessary to connect remote clients to the server through a secure, encrypted tunnel. It is worthwhile to test this connection method by setting it up on the server, as well. Make sure your router is forwarding (to your server) the SSH port you selected (in these examples port 22199).

In order to maintain the Astronaut structure, copy the (previously created) SSH authorized_keys file to the .ssh folders for client9260 and text9260 (where serveruser = jauntyadmin00 on this server):

Create Menu shortcuts for the Text9260 Server Admin client (a text-based SSH tunnel). This will be the method used to logon (in text mode) directly to the OpenVistA Server for administrative functions:

When logging on, the ACCESS CODE / VERIFY CODE are the same as at the initial logon (sys.admin and vista!123 (or vista!456 if changed as in the above section)). The exit key for the OpenVistA server functions is ^ .

Note: While the text9260 SSH tunnel is open, it is also possible to simultaneously run the OpenVistA-CIS Client (using the menu shortcut created above which contains the command: mono OpenVistaCIS.exe --server=127.0.0.1 --port=9201).

To access the OpenVistA Server from a Windows machine, use the Astronaut Clients (and the Windows OpenVistA-CIS clients). See here and here.

Adjust Login Manager IDs

The two IDs text9260 and client9260 are meant to act as interfaces to the GT.M (MUMPS) database and not as login IDs for the GUI desktop. In fact, a user that logs into them can alter their settings accidentally. It is therefore better to exclude these two IDs from the Login Manager. It is also not necessary to have the openvistaEHR login ID enabled (although there is no harm in logging into this account).