LISTSERV 17.0 Install Manual for Unix

3.1 Creating the "LISTSERV" Username

LISTSERV requires exclusive access to the mail sent to one username. Unless you have a very good reason to do otherwise, the "listserv" username should be used for that purpose. Many people around the world are already familiar with LISTSERV, and will assume that mail sent to <listserv@your.host.name> will reach the server. The LISTSERV account is just an ordinary user, it doesn’t need privileges, doesn’t require access to restricted directories, and it doesn’t need to have any particular UID or GID.

3.1.1 Running LISTSERV under a userid other than ‘listserv’

If you do change the username under which LISTSERV runs, you must make sure that the following points are observed as you work through the installation:

1. You must set the LSVNAME macro in the Makefile to the username you have selected.
2. If you have a compiler, you must edit lsv_amin.c and change the line

#define LISTSERV "LISTSERV"

to

#define LISTSERV "USERNAME"

where USERNAME is the username you have selected.

3. You must ensure that the lsv_amin mailer, when run, is invoked suid userid, where "userid" is the username LISTSERV is running under. Otherwise mail sent to LISTSERV will be treated as if it were being sent to a list with the name "userid".
4. If you do not have a compiler and must use the precompiled lsv_amin executable, you will have to modify the aliases in /etc/aliases that are normally made by the ‘make aliases’ stage of the Makefile.  For instance if you have decided to run LISTSERV under the username ‘listmanager’, you would have to make the aliases

listmanager: "|/usr/local/bin/lsv_amin -t listserv"

owner-listmanager: "|/usr/local/bin/lsv_amin -t owner-listserv"

In other words, lsv_amin will be invoked suid listmanager but will feed the userid ‘listserv’ to LISTSERV. Since you cannot change the name used internally by LISTSERV unless you have a compiler, this is required to keep mail to ‘listmanager’ and ‘owner-listmanager’ from being treated as list mail rather than administrative mail.

3.1.2 Where Should I Install LISTSERV?

L-Soft STRONGLY RECOMMENDS that LISTSERV be installed in the 'listserv' user's normal user space.  Typically (and it depends on the operating system) this is something like /home/listserv or /export/home/listserv, but the bottom line is that it is usually a directory found in a partition reserved for user accounts.

Why do we strongly recommend this location?  The user filesystem is usually a fairly good-sized partition, sometimes the largest on the machine.  This will be important if your LISTSERV server is going to handle a large volume of mail and will be keeping good-sized list archive notebooks on hand.  While we have customers who have successfully installed and run LISTSERV from what they consider more secure areas (typically under the root partition, e.g., in /opt/listserv or suchlike), often they find that they run out of space as the LISTSERV archives and logs increase in size.  The root partition is usually not as large as the /home (or /export, depending on your OS) partition, because it isn't intended for storage of large files that don't tend to be rotated out over time (like console logs).

Another problem you may run into if installing LISTSERV somewhere where the 'listserv' user typically doesn't have permissions or ownership is possibly having to "fiddle" with the permissions and ownership of various files and directories to make things work.  As we said years ago when LISTSERV was first ported to unix systems, the 'listserv' account is just a standard user account; it doesn't need any special or elevated permissions or ownership of files and directories to run properly.  (This isn't as true of the web interface files, but we address that later in this document.)  If LISTSERV is installed in the correct location for files that belong to the 'listserv' user, you shouldn't need to change anything in this regard, and things will just work.

If you are running SELinux under Linux, in "enforcing" mode, you will probably find that you need to adjust the security context of LISTSERV's files and directories, as well, if they are installed somewhere other than the default location.

Frankly, we feel that there is no particular advantage to installing LISTSERV under the root file system as opposed to under the file system reserved for user accounts.  LISTSERV should be treated as a non-privileged user, albeit an automated one, and its files should be installed accordingly.

3.2 Extracting Installation Materials from the "TAR" Files

For LISTSERV Classic, the two archive files you receive will be called common.tar.gz and either AIX.tar.gz, or SunOS.tar.gz, or Linux.tar.gz, etc... depending on the version of UNIX(R) you are using. The filename is taken from the string returned by the "uname" command on each UNIX(R) platform.

Some third-party FTP sites may change the name of the files slightly to adhere to system specific naming conventions. If you’re used to dealing with gzipped tar files already, then just extract the contents using whatever commands you prefer. If you’d like the sample commands listed below to work as shown, rename the files you received to common.tar.gz and `uname`.tar.gz before continuing. For example, if the system specific file you received is called aix.tar-z, you would enter the command mv aix.tar-gz `uname`.tar.gz. Copy or move the two files to a scratch directory first. (The advantage of using a work directory for the installation is that you can easily clean up afterwards.)

Once the files have been copied, "cd" to that directory and enter, gunzip *.tar.gz to restore them to their original state. Then enter the commands tar xf common.tar and tar xf `uname`.tar to unbundle the programs, data files, etc., needed to install LISTSERV. Afterwards you should find the following files and directories have been created in your current directory:

and the ./home directory will contain the following files:

Sample commands for this step:

mkdir /tmp/scratch

cp common.tar.gz `uname`.tar.gz /tmp/scratch

cd /tmp/scratch

gunzip *.gz

tar xf common.tar

tar xf `uname`.tar

 - or -

mkdir /tmp/scratch

cp common.tar.gz `uname`.tar.gz /tmp/scratch

cd /tmp/scratch

zcat common.tar.gz | tar xf -

zcat `uname`.tar.gz | tar xf –

3.3 Customizing the Makefile to Determine LISTSERV’s Location

If you plan to use the precompiled lsv binary, you may skip this section as it uses the defaults for these locations.

Before you can continue with the installation of LISTSERV, you need to choose where you want several things to be placed. The installation process needs the full path names of three directories. All of them are defined by macros in the Makefile (which was extracted from the common.tar archive in the preceding step).

The directory where the mail interface and command line interface programs should be installed is defined by the BINDIR macro. The Makefile is distributed with BINDIR set to /usr/local/bin by default. Whether you choose to use the default directory, or redefine it, the installation procedure assumes the directory already exists. If you choose a new directory, you will need to create it before running the final "make install". This directory is referenced only during the installation of the mail interface. Neither the mail interface program, the command line interface utility, nor the LISTSERV server process requires write access to this directory afterwards.

Incoming mail is written to the directory defined by the LSVSPOOL macro in the Makefile. The default value is $(LSVROOT)/spool. Unlike the BINDIR directory, the LISTSERV spool directory is assumed to be a new directory. In fact, no other users or daemon processes should write to this directory since LISTSERV scans this directory for incoming mail. If the directory doesn’t exist when the "make install" command is executed, it will be created, and the LISTSERV account will be made the owner.

The LISTSERV executable, as well as associated directories and data files will be installed in the directory pointed to by the LSVROOT macro in the Makefile. Any directory can be used, so long as LISTSERV has write access to it. When the final "make install" is run, the LSVSPOOL directory, and several subdirectories, will be created if necessary. The LISTSERV account will be made the owner of those directories. The Makefile is distributed with the LSVROOT macro set to /home/listserv. If you choose the default setting, the directories /home/listserv, /home/listserv/home, and /home/listserv/tmp will be created as a result.

To use different directories, edit the Makefile and change the BINDIR, LSVSPOOL, and/or LSVROOT macros.

Sample command for this step:

vi Makefile

3.4 Building the Interface Utilities and LISTSERV Server

BEFORE RELINKING LISTSERV BINARIES, PLEASE READ SECTION 1.2, LDAP Support Is Required, OF THIS DOCUMENT.

3.4.1 Using the Compiler

The program that handles incoming mail is called lsv_amin and is distributed in source form. The file lsv_amin.c is a standalone program that can be modified to suit your local mail system as needed. It should work as distributed with unmodified Sendmail systems, as well as with postfix and exim systems.

If you have decided to link the lsv.o file and make your own lsv binary, there should be no need to modify anything in the Makefile to perform this step.

Sample commands for this step:

vi Makefile

vi lsv_amin.c

3.4.2 The LCMD and LCMDX utilities

The lcmd utility is also distributed in source form. Once you’ve compiled and installed lcmd, it can be used locally to send commands to the LISTSERV server rather than having to use a mail program.

Long-time users familiar with the BITNET version of LISTSERV will find lcmd works much like the VM "tell" and JNET "send" commands. The primary differences are that LISTSERV sends back mail in response to commands submitted with lcmd, and only your local LISTSERV server can be reached. In addition to providing a simple command line interface to LISTSERV, sending commands with lcmd obviates the need for password validation of protected commands. Since the origin of the command is determined by the username of the person running lcmd, not by parsing mail headers, password checking can be skipped by LISTSERV. The lcmd.c program should compile without modification. Site specific information needed by lcmd will be provided by the Makefile when building the program.

The lcmdx utility is also distributed in source form. Similar to lcmd, once you’ve compiled and installed lcmdx, users can use it to send commands to your LISTSERV server rather than having to use a mail program.  lcmdx differs from lcmd in two important ways:

lcmdx is a TCP/IP application which interfaces directly with LISTSERV’s TCPGUI API and communicates in real-time from the user’s console with the LISTSERV command processor (much as could be done on BITNET with "TELL" commands).  It can be run remotely as long as the TCPGUI port (usually 2306) is not firewalled or otherwise blocked from the remote user’s location.

lcmdx requires a full login and appropriate LISTSERV administrator permissions for the user issuing the commands.  

The lcmdx.c program should compile without modification.

If not already present in the $LSVROOT directory after installation, and assuming you have a compiler, the lcmd and lcmdx utilities can be compiled easily with the following commands:

make lcmd

make lcmdx

3.4.3 Using the precompiled binaries

If you do not have a compiler, or if you have just decided to use the precompiled binaries from the kit, you now need to rename the lsv_amin-precompiled binary to lsv_amin. This will prevent ‘make’ from trying to call ‘cc’.

Sample commands for this step:

mv lsv_amin-precompiled lsv_amin

If you do not have a compiler:

rm lcmd.c

rm jobview.c

3.4.4 Adding DBMS Support

(See the Advanced Topics Manual for LISTSERV for more information on DBMS support.)

LISTSERV for unix kits support Oracle, DB2, and MySQL (via unixODBC) in a single, universal kit.  This kit contains both a precompiled ‘lsv’ executable (which does not support any database), and a set of object files allowing you to link a new ‘lsv’ that supports any combination of databases for which you have a run-time environment on the machine running LISTSERV. The following object files are included:

If a particular database is not available for your operating system, the corresponding noxxx.o file will have been pre-linked into lsv.o and will not be included in the kit.

LISTSERV installation kits contain a Makefile that is set up to relink ‘lsv’ without any DBMS support by default. A new "OS-specific flags" section has been added where you can add or remove DBMS support simply by adding or removing the reference to the appropriate no*.o file.  For instance, if you are running Solaris, the default flags line is

CFLAGS_Solaris=nooci.o nocli.o -lsocket -lnsl

If you want to relink ‘lsv’ with Oracle support, simply change this line to

CFLAGS_Solaris=nocli.o -lsocket -lnsl

If you want to relink ‘lsv’ with DB2 support, you would change the line to

CFLAGS_Solaris=nooci.o -lsocket -lnsl

Relinking ‘lsv’ with unixODBC support is not quite as intuitive.  You would use the following flags line:

CFLAGS_Solaris=nooci.o -lsocket -lnsl -lodbc

For unixODBC, you must leave CLI support enabled because CLI and unixODBC share internal function names in LISTSERV, as noted above. In addition, you must also link explicitly to the unixODBC library (the -lodbc flag).  Please see the Advanced Topics Manual for LISTSERV for more detailed information on configuring unixODBC support.

As noted in the Makefile, Solaris requires that -lsocket and -lnsl must be linked in all cases, so don’t remove these references from CFLAGS_Solaris under any circumstances.

The other supported unixes are configured in a similar manner.

3.5 Installing the Web Interface CGI Binary

While you will still want to review the Installing the LISTSERV Web Interface section, if you want the installation procedure to properly install and set ownership/permissions on the ‘wa’ executable, you need to provide the path to your cgi-bin directory in the Makefile macro CGIDIR and uncomment that line in the Makefile.  By default this installation feature is commented out:

#CGIDIR=/var/www/cgi-bin

The example setting appears to be a common default for most current Apache versions, but it is your responsibility to ensure that you define the correct directory if you uncomment and use this feature.  L-Soft does not recommend taking this default blindly as it may differ on your server.

If you do not uncomment this line, neither ‘make install’ or ‘make update’ will try to install ‘wa’, and you will have to copy it to your cgi-bin directory manually per the instructions below.

3.6 Moving Programs and Files to their Proper Directories

The command, "make install" will copy the "lsv", "lsv_amin", and "lcmd" programs to the appropriate directories, as specified by the BINDIR and LSVROOT macros in the Makefile. In addition, several directories will be created and a number of data files copied to those directories. While there are scenarios in which you can complete this step from the LISTSERV account, in most cases you will need to become "root" to run the "make install" command.

SOLARIS SPECIFIC:  When issuing the commands below be sure to follow them exactly. If you issue "su - root" instead of "su root" LISTSERV will be installed but will fail when you attempt to start it.

Sample commands for this step:

su root

make install

exit

3.7 Configuring LISTSERV for Your System

LISTSERV needs to know a variety of things about your system, and also how to communicate with the people that will be maintaining the software. All of the settings that you are likely to want to change are defined in the "go.user" shell script, which is created in the LSVROOT directory when you enter "make install". There are a number of environment variables that you can set to reflect things like the Internet domain name of the machine that will be running LISTSERV, the email address of the LISTSERV postmaster, etc... You’ll need to edit the go.user file in the LSVROOT directory, and set each of the variables as appropriate. There are comments in the file explaining the purpose of each variable, and we will discuss the basic settings that must be made before you can start the software below.

After ‘make install’ finishes, it will tell you that you need to chdir into the ~listserv directory and edit the go.user file before you can start the server.  You will need to gather some information before you start.

What is the DNS hostname for the machine on which LISTSERV is going to be installed?  This is something like LISTSERV.YOURDOMAIN.COM . It must be a fully-qualified domain name (FQDN) and it must map to an A or MX record in your domain’s DNS service.  While it is possible to use a bracketed IP (e.g., [10.0.0.24]) for testing purposes, as noted above the use of bracketed IPs in production is not supported and not recommended.

What are the email addresses for the LISTSERV maintainers (the person or persons who are authorized to create lists and operate/maintain the server)?

To configure the server, first open LISTSERV’s go.user file with any text-based editor (emacs, vi, pico, etc.).  There are four basic settings that must be configured before LISTSERV can be run.

Sample commands for this step:

cd /home/listserv

vi go.user

NODE

# -- The fully qualified domain name for this host.
NODE="LISTSERV.EXAMPLE.COM"

The NODE setting is the fully-qualified domain name as registered in DNS for the machine LISTSERV is running on.  As noted above, it is possible to insert a square-bracketed dotted-decimal IP address in this box for testing purposes, but L-Soft neither recommends nor supports this in production. This is the host name that LISTSERV will always identify itself with when it sends mail out.

MYDOMAIN

# -- All possible domain names for this machine. SPACE SEPARATED!
MYDOMAIN=$NODE

It is usually best to leave this set to the default, ie, $NODE, but under some circumstances it may be necessary to deviate from the default.

MYDOMAIN does not refer to your corporate Internet domain.  MYDOMAIN is the space-separated list of all possible host names your machine might be known as. In many cases the value of MYDOMAIN is the same as NODE, but for instance some machines running LISTSERV also run the enterprise’s World Wide Web server, and may thus be identified in DNS as something like "WWW.EXAMPLE.COM".  If you have users who receive mail on this machine, you might also have a DNS record for "MAIL.EXAMPLE.COM" pointing to it.  And of course we’ll assume that NODE has been set above to something like LISTSERV.MYCOMPANY.COM. Using this as an example, you would set the MYDOMAIN setting to contain, in space-separated format, all of these names that mail might come in to LISTSERV under, with the NODE value coming first:

MYDOMAIN="$NODE WWW.MYCOMPANY.COM MAIL.MYCOMPANY.COM"

This way if someone accidentally writes to LISTSERV@MAIL.EXAMPLE.COM, LISTSERV will recognize MAIL.EXAMPLE.COM as equivalent to LISTSERV.EXAMPLE.COM and will process the mail as if it had been addressed to LISTSERV@LISTSERV.EXAMPLE.COM. Otherwise the mail may bounce as LISTSERV has no other way to know what other names the machine might be known by in DNS.

POSTMASTER

# -- The email address(es) of the LISTSERV maintainer(s). SPACE SEPARATED!
POSTMASTER="me@example.com"

This is a space-separated list of userid@host.domain type email addresses belonging to people who have authority to manage LISTSERV--specifically the people who are allowed to create lists, but also who have pretty much global authority on the server to look at lists, modify list headers, and so forth.  There are some advanced options for this setting but for right now you will probably just want to insert your own email address so that you can test the server.

Please note carefully that the POSTMASTER should NEVER be LISTSERV@ anywhere or POSTMASTER@ anywhere.  These userids are reserved and mean specific things to LISTSERV.  If you need to use a generic name for a postmaster account, it is recommended that you use something like "listmaster" or "lstmaint" instead.

CREATEPW

# -- The password to be used when sending "put" commands to create files
CREATEPW="luxfiat"

The password that will be used to create lists and perform certain management functions (such as administering LISTSERV’s user password feature).  Note that when using the web management features, you do not use the CREATEPW= value, but rather your own personal LISTSERV password, to validate your identity.  See the main LISTSERV documentation for information on how to create a personal LISTSERV password.

3.8 Telling Your Mail System about LISTSERV

For Sendmail, see the Telling Sendmail about LISTSERV section.

For Postfix, see both the Sendmail section and the Telling Postfix about LISTSERV section.

For qmail, see the Telling qmail about LISTSERV section.  

3.8.1 Telling Sendmail about LISTSERV

LISTSERV accepts and responds to several email addresses. Even before you setup mailing lists, mail sent to listserv and owner-listserv should be handed to LISTSERV. The link between LISTSERV and your mail system is the lsv_amin program. If you are running Sendmail, the best way to route incoming mail to lsv_amin is by adding entries to your "aliases" file. Refer to the manual pages for sendmail on your system if you are not sure where the alias file is stored. On many systems the file will be called /etc/aliases. Once you have located the file, add the following lines,

listserv: "|/BBB/lsv_amin /SSS listserv"

owner-listserv: "|/BBB/lsv_amin /SSS owner-listserv"

to the file, replacing /BBB with the directory where the lsv_amin program was installed (the BINDIR macro in the Makefile), and replacing /SSS with the LISTSERV spool directory (the LSVSPOOL macro from the Makefile). Other than that, the lines should look exactly like the examples above. The double quotes should be entered into the alias file.

For example, if you changed BINDIR to /usr/lbin, and kept the default LSVSPOOL directory, the new lines in /etc/aliases would look like the following.

listserv: "|/usr/lbin/lsv_amin /home/listserv/spool listserv"

owner-listserv: "|/usr/lbin/lsv_amin /home/listserv/spool owner-listserv"

After updating the alias file, you will need to issue two Sendmail commands. First enter "newaliases" to compile the alias file into the format the sendmail daemon expects. Then on some systems you may also need to direct the sendmail daemon currently running on your system to read the newly compiled list of aliases. Refer to the manual pages for sendmail if you are unsure of how to do so. The command, "kill -HUP `cat /etc/sendmail.pid`" will work on AIX and SunOS systems. If you are running a syslog daemon, sendmail will log the fact that it has loaded the new aliases file. You can check the syslog output after issuing the command to make sure your changes are in place.

Sample commands for this step:

su root

cd /etc

vi aliases

newaliases

exit

3.8.2 Telling Postfix about LISTSERV

LISTSERV can be used with Postfix, which was designed as an alternative to sendmail. Postfix has a number of advantages, not the least of which is that it is much simpler to configure than sendmail.

In general, the instructions for interfacing LISTSERV with sendmail are all you need to follow for Postfix.  Modern versions of Postfix typically use the same /etc/aliases file as sendmail.  If your local installation is configured differently, you will have to modify the ALIASES macro in LISTSERV’s Makefile to point to the appropriate aliases file, which can be found by issuing the command

postconf alias_maps

at the unix command line.  Otherwise, LISTSERV is happy to work with Postfix as a replacement for sendmail.

If you plan to use LISTSERV’s address probing feature with Postfix (the default is to do so when sending mail-merge jobs, for instance, or when you have configured a list for Auto-Delete), you must configure Postfix to direct all mail received for unknown recipients to LISTSERV.  This is because bouncing address probes come back to specially-formatted addresses -- for instance,

owner-mylist-l*someuser**EXAMPLE*-COM@LISTSERV.MYORG.COM

These addresses positively identify to LISTSERV:

• which list or mail-merge job originated the message that bounced; and
• which recipient is the bouncing address.

In order to direct these mails to LISTSERV, you need to modify Postfix’s master.cf and main.cf files.  Typically these are found in /etc/postfix, but your installation may vary.

In the master.cf file, add a service called "lsvamin" as follows (we are assuming a default installation of LISTSERV for our file locations):

# LISTSERV redirection
lsvamin   unix  -       n       n       -       -       pipe
 flags=F user=listserv argv=/usr/local/bin/lsv_amin /home/listserv/spool ${user}

Then, in the main.cf file, add:

fallback_transport=lsvamin
local_recipient_maps=

Stop and restart Postfix, if it is already running.  Finally, in /etc/aliases, you will also have to add at least one LISTSERV alias:

listserv: "|/usr/local/bin/lsv_amin /home/listserv/spool listserv"

and then run `newaliases’.  If you don’t do this, mail sent to the ‘listserv’ user will end up in the unix mailbox, and never get to LISTSERV’s command processor.

If you prefer to create a Postfix virtual host instead, add the lsvamin service to master.cf as outlined above, and then add the following in main.cf:

virtual_mailbox_domains = your.virtual.domain.com
virtual_transport = lsvamin

(Replace your.virtual.domain.com with the actual name of the virtual domain you will be creating.)

In either case, it should be noted that all mail addressed to unknown recipients will be shunted to LISTSERV, which can cause LISTSERV postmasters to see significantly more bounce mail than they would otherwise.

For more advanced help with postfix, please see http://www.postfix.com/documentation.html . Some large LISTSERV sites are running with postfix and you can probably get help from their admins by joining and writing to the LSTSRV-L mailing list.

3.8.3 Telling qmail about LISTSERV

LISTSERV can be used with qmail. However, L-Soft does not have any test machines running with qmail so the procedure as outlined is based on correspondence with customers who have made this combination work rather than based on tests run on our own systems.

Assuming defaults for everything else, you should include a file called

/home/listserv/.qmail

that has the following statement in it (all on one line without wrapping):

|/var/qmail/bin/preline /usr/local/bin/lsv_amin -s /home/listserv/spool -t listserv        

You must also create another file called ~alias/.qmail-default with the following line in it (again, all one line without wrapping):

|/var/qmail/bin/preline /usr/local/bin/lsv_amin -s /home/listserv/spool -t  $LOCAL        

(Note that ~alias is a link to /var/qmail/alias .) This entry "generalizes" the aliases that under sendmail would have to go into /etc/aliases .

For more advanced help with qmail you should contact the appropriate qmail support lists and newsgroups (see https://cr.yp.to/qmail.html for the current qmail home page).

It is unknown how many LISTSERV sites continue to run qmail, but it is doubtful the number is very high.  You may be able to get help from their admins by joining and writing to the LSTSRV-L mailing list.

3.9 Creating and Activating the License Key

Before you can start up LISTSERV, you will need to install a License Activation Key (LAK) for ‘LISTSERV-xxx’ (xxx = LINUX, AIX, SOLARIS, etc...). In order to offer the same range of services to all LISTSERV sites, regardless of the operating system used, we had to develop our own "license key" scheme. Using system supplied license managers where available and L-Soft LAKs elsewhere would have required us to develop multiple authorization schemes, and would also complicate the task of issuing license keys to customers.

Since the LAK manager is part of LISTSERV, installing the LAK is done last, after all the programs have been built and moved to their proper directories. The process is quite simple, you just create a file called license.merge in the $LSVROOT/home directory and start the LISTSERV server to compile the information. The instructions for doing so are described in the License Registration Form that came with your installation materials.

Note that the license.merge file you create in $LSVROOT/home MUST be owned by the ‘listserv’ user and the ‘listserv’ user MUST have full control over it.  Unless you are logged in as the ‘listserv’ user when creating the license.merge file, we recommend issuing the following commands at the unix command line after saving the file:

chown listserv:listserv license.merge

chmod 700 license.merge

3.10 Setting up LISTSERV Log Rotation and Location (optional but recommended)

LISTSERV console logging under unix is accomplished by running the server in the background.  The 'go' script contains code to redirect standard output to a file when it is executed with the 'bg' command line option (that is, 'go bg').  By default, standard output is redirected to a file in the $LSVROOT directory called 'listserv.log', which is never rotated unless LISTSERV is stopped, the file is somehow renamed (the 'go' script code doesn't do this for you), and LISTSERV is restarted and begins writing to a fresh copy of 'listserv.log'.  This is non-optimal for debugging, as the listserv.log files can grow very large if LISTSERV isn't restarted on a regular basis, and there might be days or weeks worth of log entries in the file to search through if you have a problem that needs to be debugged.

For many years, L-Soft has shipped a perl script called 'lsv-logger.pl' in the unix installation kits.  lsv-logger.pl is a log rotation script that rotates the LISTSERV log file under unix automatically at midnight, without needing to stop/restart LISTSERV.  It also makes the log file naming consistent with the Windows version of LISTSERV.  (Caveat:  Be sure the server's clock is set accurately.)

Perl must be installed on the machine.  Perl version 5.6.1 or later is recommended.

Basic support for lsv_logger is already present in LISTSERV's 'go' script.  Assuming lsv_logger.pl was installed along with LISTSERV, which it normally is by default, it should already be present in the LSVROOT directory, and the ownership and permissions should already be set for you, e.g.,

-rwx------.  1 listserv root         827 Jun 11  2019 lsv-logger.pl

Should it be preferred to keep the dated logs in the LSVROOT directory, simply uncomment the LOG_PATH variable in go.user, and specify "." as the LOG_PATH value.  However, L-Soft strongly recommends that the logs be kept in a standardized location, e.g., somewhere under /var/log, and preferably in their own directory under that path, rather than in the LSVROOT directory.

To activate log rotation and write logs to a directory other than LSVROOT, simply follow these instructions:

Create the directory where you want the logs to be written, and give 'listserv' both ownership and rwx privileges in it. Depending on where you decide to create the directory, these steps may require root (or sudo) access.  Sample unix shell commands (not LISTSERV commands) for creating the directory and setting appropriate permissions are

cd /var/log

mkdir listserv

chown listserv:listserv listserv

chmod 700 listserv

Check it with:

ls -ld /var/log/listserv

Should look like:

drwx------. 2 listserv listserv 35 Mar  3 11:28 /var/log/listserv

Next, open go.user in a text editor, find and uncomment the LOG_PATH variable, and set it to contain the path to the directory you just created, e.g.,

LOG_PATH="/var/log/listserv"

Save and close go.user .  When you next start or restart LISTSERV, it will begin writing its dated logs in the directory specified in LOG_PATH.