Installation Methods

Introduction

FreeNAC is available as a Virtual Machine, a 'tarball'', from Subversion (SVN) and a Ubuntu/Debian package. There are also 'stable' and development versions.

This page explains each of these options below. If you are in a hurry and don't want to read the whole page, we recommend:

1. If you have a fast Internet connection, or are not used to administering Linux, the Virtual Machine is probably the easiest way to get up and running.
2. If you are a Ubuntu system administrator, try the package.
3. If you are used to linux, install using the latest stable branch sources from the Subversion respository.

Next step:

• to install the VM, follow the instructions Quick install using a Virtual Machine .
• For all other methods, follow the Installation Guide, starting with Step1: Linux platform Installation .

Which Operating System?

FreeNAC runs on Linux, this installation guides explains how to get it up and running on Linux. It could also run on UNIX systems, for example earlier versions ran on Solaris, but this Installation Guide does not cover these.

FreeNAC does not run under windows. In theory it is possible since PHP and Apache also run on Windows, but for example "vmpsd" would have to be ported.

Virtual machine

FreeNAC is quite complex, and needs a machine with GNU/Linux and many OpenSource source tools installed.

To get you started quickly with FreeNAC, we have built a Virtual Appliance (also called a Virtual Machine, VM) with Linux, the modules needed, and FreeNAC installed in a 'demo mode'.

The VM is ideal if you just want to test FreeNAC, or feel daunted by the length installation documentation for FreeNAC.

On the other hand, the VM is only updated every few months, and its slow to download.

Tarball

A tarball is a slang name for  a compressed archive (see also wikipedia)  containing source code, that is typically compiled and can be installed on many platforms.

Analysis: Tarballs require more knowledge, are not subject to version control (its difficult to see what you have changed, or to update to new bug fix releases) and are not integrated into the Linux package management. No internet access is required on the target server either. But for the same reasons its an ideal format for advanced system admisistrators.

Tarballs are also easy to generate, so the FreeNAC team often announce new releases in this format first.

Subversion (SVN) repository

The FreeNAC team use SVN (see also wikipedia) to manage the source code. Work on the source code usually takes place in parallel in two copies:

• The development release (also called unstable or trunk), where new features are added and tested.
• The stable releases (also called branches, e.g. V2.1, v2.2). When new features are addes, have been well tested, a 'branch' is created corresponding to a new version.  

Analysis: Subversion can be difficult to learn at first, it is not integrated into the Linux packagement and required internet access (direct or via a proxy). The advantages are significant though: it allows the source code to be pulled directly from the FreeNAC respository and allows easy, regular updates to the latest version of a branch (via the svn update command). 

It is recommended that you use the latest 'stable' release, unless you are involved in testing or development.

Package

Much production software is usually provided as a package, that is easy to install or deinstall and pre-destined for an exact operating system. Tthe operating system 'knows' what packages have been installed, on what other packages it depends, and how to remove those packages.

Packages are a very good way to distribute software since installation time is quicker (easier for the user), and dependancies between packages is taken care of. The difficulties lie in the generation of packages (the many different vriants of Linux/UNIX methods, the dependancies between versions), and the necessity to make appropriate installation/deinstallation scripts.

For resource reasons, the FreeNAC team has not generated packages until recently (Oct'07). The initial focus has been on creating Ubuntu (debian compatible) packages, since this is the preferred platform used by many of the FreeNAC core team. 

Packages take time to generate and test, and so will often be behind Subversion and tarball software. However its a good choice for Ubtunu system administrators running production servers.

We welcome community contributions for other distrubutions (RedHhat or Suse rpm, gentoo sources etc. :-) 

Hardware Requirements

To run FreeNAC, you'll need

• a Linux server (or VM) with FreeNAC installed
• a Cisco Switch
• a Windows PC to run the Windows Administration User Interface
  (this software can also run from a Windows share, and does not need to be actually 'installed').

FreeNAC server hardware requirements

Example: a site running with ~2'000 active end-devices. The server is rarely loaded (CPU or I/O). The slowest part is the Windows GUI with its complex SQL queries - not the VMPS back-end.

• A PC server which is compatible with the brand of Linux you choose.
  The FreeNAC core team use Ubuntu now (so we recommend the latest ubuntu stable server release), but Suse, Fedora, Gentoo, Rehat/CentOS have been used too. Solaris has also been used. Ironically, it can be more difficult to get the non-free, Commercial Enterprise versions of Linux working (RedHat, Suse) since the software is older and not all graphics libraries may be available.
• Disk
  • A hard-disk of at least 20G, recommended 100G: the more the better for backups.
  • Have a second disk for backups or RAID, for additional data security. Ensure the RAID system is Linux compatible.
  • IDE is fine, but SCSI or SATA are often more reliable, faster and you can boot from each disk without changing cables.
• Network Interfaces: Have two if possible.
  The second interface is useful for a dedicated switch management, or backup network. 100Mb speed is fine (Gb is not necessary).
• CPU is not a bottleneck, 2GHz should be fine.
• Memory is always good for databases. 1GB will work fine, but the more the better.
• A dual, hot plug power supply improves reliability.
• A dual, hot plug fan also improves reliability.
• Remote console management should be included in the Server Bios (e.g. HP Lights out, Sun LOM, Dell DRAC5), for easier remote installation, troubleshooting and monitoring of hardware status.

Its recommended to have at least 2, and perhaps 3 servers. If you are used to Virtual Machines, do the Master as a VM, and one or more replicas as 'real' machines. Point the switches at the replicas, and use the master for serving GUI requests, scanning and polling switches/routers and processing syslogs.

By doing the master as a VM, snapshots can be used before system upgrades, and roll backs are easier.