Installing SER 2.0

There are two ways to get your own installation of SER. If you are lucky and there are binary packets for your system available, you can simply download them and install them with your system's packet manager. Otherwise you can always compile your very own SER from the sources.

Both options are explained below.

Binary packages are only available for a small number of systems. If you are interested in providing and maintaining packages for your favorite system, feel free to do so. The serdev mailing list will be a good place to announce your interest and co-ordinate efforts.

Packages are available for the following systems:

• XXX which exactly?

Once the packet is installed successfully, you will most likely need to do some configuration. To learn which, continue reading with Initializing Database below.

Before you can start compiling, you need a set of the sources. The safest way is to download the tarball of the latest stable release. For SER 2.0 series, the stable release is numbered 2.0.x.

• XXX Where do we have releases now?

If you prefer to live on the bleeding edge, we also provide daily snapshots. You can choose from three different versions: "stable" will provide you with the snapshot of the current stable series 2.0. A bit more dangerous still is the "testing" snapshot which contains the upcoming stable series 2.1. And finally, there is "unstable" which provides you with a snapshot of the current development series. Neither of those snapshots are guaranteed to work. But a "stable" snapshot is quite likely to actually turn out okay since only bug fixes will go into that series.

• XXX Where do we have releases now?

Alternatively you can also check out the sources directly from our revision control system.

• XXX Wait here until we finally agree on something. And then explain:
• from repository
• versions/branches

Before you can start compiling, you need to make sure, you have all the required tools and libraries. The file INSTALL in the source tarball contains details on versions and also lists the packets to install on various systems.

You will need the following tools:

• a C compiler; gcc (2.95 will work, but for better performance, you should have at least the 3.1 series) or icc;
• bison or Berkley yacc;
• flex;
• GNU make (at least version 3.79); on GNU systems such as Linux this is your default make, on other sytems it is usually called gmake;
• sed and tr;
• install.

SER itself doesn't need any libraries, apart from the obvious ones, such as a libc. However, some modules need additional libraries. Remember that you need the development versions of the libraries.

• libmysqlclient and libz (zlib) if you want mysql support (the mysql module)
• libexpat if you want the jabber gateway support (the jabber module)
• libxml2 if you want to compile the cpl-c (CPL support) or pa (presence) modules
• libradiusclient-ng (> 5.0) if you need radius support (the acc_radius, auth_radius, avp_radius and uri_radius modules)
• libpq if you want postgres support (the postgres module)

Check the [ref_man|Reference Manual] if you are not sure whether you want all these modules.

After you have all the prerequisites you can next build the core of SER. You do this by typing

$ make

If you are on BSD or Solaris you will have to say `gmake` to invoke GNU make instead of the system's own version.

The build system is trying to be smart, but there may be some things it can't guess. It honors the usual variables, such as CC for the C compiler to use. Some hard coded values can be found in the file `config.h`. They are set to sane values, but may need tweaking for some special setups.

* XXX Do we want all -D options listed here or rather update INSTALL and point there? Same for mode=debug.

Next, you need to build the modules you need. This is done by issuing

$ make modules

By default, SER doesn't build all modules. It limits itself to those modules that are in widespread use and that do not require any extra libraries. If you want more or less modules, you need to provide them as an option.

For convenience, all modules are put into groups that you can easily include. The groups are:

• standard: all modules in widespread use that do not depend on external libraries (this group is included by default);
• standard-dep: standard modules, that do need extra libraries (these are: acc_db, acc_radius, auth_db, auth_radius, avp_db, avp_radius, db_ops, domain, lcr, msilo, mysql, dialog, pa, postgres, presence_b2b, rls, speeddial, uri_db, xcap, xmlrpc);
• mysql: all modules that use MySQL (acc_db, auth_db, avp_db, db_ops, uri_db, domain, lcr, msilo, mysql, speeddial);
• radius: all modules for Radius support (acc_radius, auth_radius, avp_radius);
• presence: all modules for presence support (dialog, pa, presence_b2b, rls, xcap);
• stable: modules that satisfy specific or niche applications, but are considered stable for production use and may have additional external dependencies (cpl-c, dbtext, jabber, osp, sms);
• experimental: modules that are not yet enough tested to be considered stable or standard (tls).

In order to include any of these groups, you add them to the option include_groups like so:

$ make include_groups="mysql experimental" modules

• XXX do we need to explicitly state standard in this case?

Don't forget the double quotes around the group names lest some confusion will ensue.

Alternatively or additionally, you can give individual modules to make by means of the option include_modules. If you don't want some modules from a group, you can use skip_modules for those.

If you use this a lot, you may get confused which modules will be build and which want. The target print-modules will simply print a list of the modules that would be built and that would be excluded.

• what goes where
• sercmd, ser_ctl

• ser_mysql.sh, users and permissions, SQL files

• cmd line options
• process overview
• database connections

• all by yourself
• init scripts

• additional utilities (ser_ctl, serweb, rtpproxy)