This chapter details a fresh installation of DOMjudge. The first section is a Quick Installation Reference, but that should only be used by those already acquainted with the system. A detailed guide follows after that.
Note: this is not a replacement for the thorough installation instructions below, but more a cheat-sheet for those who've already installed DOMjudge before and need a few hints. When in doubt, always consult the full installation instruction.
External software:
DOMjudge:
./configure
[--enable-fhs] --prefix=<basepath>
.make domserver judgehost docs
or just those
targets you want installed on the current host.make install-{domserver,judgehost,docs}
as root to install the system.bin/dj-setup-database -u root -r
install
on the domserver host.etc/apache.conf
to your Apache configuration, edit
it to your needs, reload web server:
sudo ln -s .../domserver/etc/apache.conf /etc/apache2/conf.d/domjudge.conf &&
sudo apache2ctl graceful
useradd -d /nonexistent -g nobody -M -n -s /bin/false domjudge-run
useradd -d /nonexistent -g nogroup -s /bin/false domjudge-run
/etc/sudoers.d/
or append to /etc/sudoers
the
sudoers configuration as in etc/sudoers-domjudge
.etc/restapi.secret
on all judgehosts.bin/judgedaemon
cd tests make check
AUTH_METHOD
selected in etc/domserver-config.php
,
see
submit client configuration
for more details.
Then, in the main jury web interface, select the admin link judging verifier to automatically verify most of the test sources, except for a few with multiple possible outcomes; these have to be verified by hand. Read the test sources for a description of what should (not) happen.
Optionally:
cd bin; ./balloons
;
or use the balloon web interface.bin/dj_make_chroot <chrootdir> <architecture>
$EDITOR lib/judge/chroot-startstop.sh
chroot-startstop.sh
script in etc/judgehost-config.php
and add etc/sudoers-domjudge
to /etc/sudoers.d/
or
append it to /etc/sudoers
.For a detailed list of the hardware and software requirements, please refer to the previous chapter on contest planning.
For your convenience, the following command will install needed software on the DOMjudge server as mentioned above when using Debian GNU/Linux, or one of its derivate distributions like Ubuntu.
apt-get install gcc g++ make zip unzip mysql-server \ apache2 php5 php5-cli libapache2-mod-php5 php5-mysql php5-json \ bsdmainutils phpmyadmin ntp \ libboost-regex-dev libgmp3-dev linuxdoc-tools linuxdoc-tools-text \ groff texlive-latex-recommended texlive-latex-extra \ texlive-fonts-recommended texlive-lang-dutch
The following command can be used on RedHat Enterprise Linux, and related distributions like CentOS and Fedora.
yum install gcc gcc-c++ make zip unzip mariadb-server \ httpd php php-cli php-mbstring php-mysql \ boost-devel gmp-devel ntp linuxdoc-tools \ texlive-collection-latexrecommended texlive-wrapfig
expdlist
, moreverb
,
and svn
still have be installed manually to rebuild the team
manuals. Furthermore, phpmyadmin
is available from the
Fedora EPEL repository.
On a judgehost, the following should be sufficient. The last two lines show some example compilers to install for C, C++, Java (GNU), Java (Oracle), Haskell and Pascal; change the list as appropriate.
For Debian:
apt-get install make sudo debootstrap php5-cli php5-curl php5-json procps \ gcc g++ gcj-jre-headless gcj-jdk openjdk-7-jre-headless openjdk-7-jdk \ ghc fp-compiler
For RedHat:
yum install make sudo php-cli php-mbstring php-process procps-ng \ gcc gcc-c++ glibc-static libstdc++-static \ java-1.7.0-openjdk-headless java-1.7.0-openjdk-devel \ ghc-compiler fpc
fpc
is not available in RedHat 7.
Finally, to build the command-line submit client, install the following additional software.
apt-get install libcurl4-gnutls-dev libjsoncpp-dev libmagic-dev
yum install libcurl-devel jsoncpp-devel file-devel
jsoncpp-devel
is available in Fedora, but not in
RHEL/CentOS.
Libmagic is not strictly required, but highly recommended for
detecting binary file submissions. These libraries are statically
linked into the submit
binary so that these libraries
are not needed on the team workstations where submit
is
installed.
The DOMjudge build/install system consists of a configure
script and makefiles, but when installing it, some more care has to be
taken than simply running './configure && make &&
make install
'. DOMjudge needs to be installed both on the server
and on the judgehosts. These require different parts of the complete
system to be present and can be installed separately. Within the build
system these parts are referred to as domserver, judgehost
and additionally docs
for all documentation.
There are three different methods for installing DOMjudge:
With this method all DOMjudge related files and programs are installed in a single directory tree which is specified by the prefix option of configure, like
./configure --prefix=$HOME/domjudge
domserver, judgehost,
docs
parts in a subdirectory
$HOME/domjudge/domserver
etc. These
subdirectories can be overridden from the defaults with options
like --with-domserver_root=DIR
, see configure
--help
for a complete list. The prefix defaults to
/opt/domjudge
.
Besides the installed files, there will also be directories for logging, temporary files, submitted sources and judging data:
log
contains all log files.
tmp
contains temporary files.
submissions
(optionally) on the domserver contains all correctly submitted files: as backup only, the database is the authoritative source. Note that this directory must be writable by the web server for this feature to work.
judgings
location on judgehosts where submissions are tested, each in its own subdirectory.
This method of installation is the default and probably most practical for normal purposes as it keeps all files together, hence easily found.
This method installs DOMjudge in directories according to the
Filesystem Hierarchy Standard. It can be enabled by
passing the option --enable-fhs
to configure
and in this case the prefix defaults to /usr/local
.
Files will be placed e.g. in PREFIX/share/domjudge,
PREFIX/bin, PREFIX/var/log, PREFIX/etc/domjudge
, while
/tmp
will be used for temporary files. You may want
to pass options --sysconfdir=/etc
and
--localstatedir=/var
to configure
to disable
the prefix for these.
Meant for those wishing to do development on the DOMjudge source code. See the appendix with developer information.
After running the configure
script, the system can be built
and installed. Each of the domserver, judgehost, docs
parts
can be built and installed separately, respectively by:
make domserver && sudo make install-domserver make judgehost && sudo make install-judgehost make docs && make install-docs
runguard
. One should
not run DOMjudge programs and daemons under the root user
however, but under a normal user: runguard
is specifically
designed to be the only part invoked as root (through sudo) to make
this unnecessary and running as root
will give rise to problems, see
runguard: root privileges not dropped in the common problems
section.
For a list of basic make targets, run make
in the source root
directory without arguments.
Configuration of the judge system is mostly done by editing the
configuration variables on the page Configuration settings
available in the administrator interface, and changes take effect
immediately. The administrator interface
can be reached on http://yourhost/domjudge/jury/
and the
default username is admin
with password admin
.
Make sure to change the default password immediately.
Some settings that are tightly coupled to the filesystem can be
configured in the files in etc
: domserver-config.php,
judgehost-config.php, common-config.php
for the configuration
options of the domserver, judgehost and shared configuration options
respectively. Descriptions of settings are included in these files.
The judgedaemon must be restarted for changes to take effect, while
these are directly picked up by the webinterfaces.
Besides these settings, there are a few other places where changes can be made to the system, see other configurable scripts.
DOMjudge supports executable archives (in ZIP format) for configuration of
languages, special run and compare programs. The archive must contain an
executable file named build
. When deploying a new (or changed)
executable to a judgehost build
is executed once. Afterwards
an executable file name run
must exist (it may have existed before).
Executables may be changed via the web interface in an online editor. Changes apply immediately to all further uses of that executable.
Compilers can be configured by creating or selecting/editing an executable in
the web interface. When compiling a set of source files, the run
executable is invoked with the following arguments: destination file name,
memory limit (in KB), main (first) source file, other source files.
For more information, see for example the executables c
or
java_javac_detect
in the web interface. Note that compile scripts are
included for the most common languages already.
Interpreted languages and non-statically linked binaries can in principle also be used, but requires that all dependencies are added to the chroot environment.
Interpreted languages do not generate an executable and in principle
do not need a compilation step. However, to be able to use interpreted
languages (also Oracle's Java), a script must be generated during the
compilation step, which will function as the executable: the script
must run the interpreter on the source. See pl
and java_javac_detect
in the list of executables.
DOMjudge supports the use of Oracle Java within a chroot environment. For
this, a chroot environment which includes the Java libraries must
first be built. This can be accomplished with the included script
dj_make_chroot
: run this as root and pass as arguments
the target directory to build the chroot environment in and as second
argument the target machine architecture. Start the script without
arguments for usage information. See also sections
Installation of a judgehost
and
Problems: Java & chroot.
To allow for problems that do not fit within the standard scheme of fixed input and/or output, DOMjudge has the possibility to change the way submissions are run and checked for correctness.
The back end script testcase_run.sh
that handles
the running and checking of submissions, calls separate programs
for running submissions and comparison of the results. These can be
specialised and adapted to the requirements per problem. For this, one
has to create executable archives as described above.
Then the executable must be
selected in the special_run
and/or special_compare
fields of the problem (an empty value means that the default run and
compare scripts should be used). One can select the default compare executable
in the global configuration settings. When creating custom run and
compare programs, we recommend re-using wrapper scripts that handle the
tedious, standard part. See the boolfind example for details.
Implementing a special compare program, also called a
validator, can be done by writing a program that is run by
a wrapper script like the run
script in the boolfind example.
Copy this wrapper to your new executable archive and let the jury write a checker program which can be called as
check_<tag> <testdata.in> <program.out> <testdata.out>
check_float
, which compares floating point numbers. The name
of the check program and any parameters can also be modified in the
wrapper (i.e. run
) script.
For example, to compare output while ignoring DOS/UNIX newline differences, one
can copy the wrapper from check_float
and in that file set the variable
CHECK_PROGRAM="`which diff`"
and replace the line
"$CHECK_PROGRAM" $CHECK_OPTIONS "$TESTIN" "$PROGRAM" "$TESTOUT" > "$DIFFOUT"
sed -i 's/\r$//' "$TESTOUT" sed 's/\r$//' "$PROGRAM" | $CHECK_PROGRAM -a - "$TESTOUT" > "$DIFFOUT"
special_compare
field. You may also change the default compare script
in the global configuration settings.
As an alternative to this modified validator script, one can accept presentation errors as correct answers by adding the mapping
'presentation-error' => 'correct',
results_remap
configuration variable (to be found in
the admin web interface under configuration settings).
For more details on modifying validator scripts, see the comments at the top
of the files testcase_run.sh
and the compare wrapper (i.e.
run
in the boolfind_cmp
example).
DOMjudge supports a presentation-error
result. The default
compare
program returns this result when output only differs
by whitespace; this is counted as an incorrect submission. The script
compare_wrapper
does not support presentation error results
however. By default presentation errors are remapped to wrong answer;
this can be changed with results_remap
.
Special run programs can be used, for example, to create an interactive
problem, where the contestants' program exchanges information with a
jury program and receives data depending on its own output. The
problem boolfind
is included as an example interactive
problem, see docs/examples/boolfind.pdf
for the description.
Usage is similar to compare programs: you can either create a program
run_<tag>
yourself, or use the provided wrapper
script, which handles bi-directional communication between a
jury program and the contestants' program on stdin/stdout (see the run
file in the boolfind_run
executable).
For the first case, the calling syntax that the program must accept is
equal to the calling syntax of run_wrapper
, which is
documented in that file. When using run_wrapper
, you should
copy it to run
in your executable archive.
The jury must write a program named exactly runjury_<tag>
,
accepting the calling syntax
runjury_<tag> <testdata.in> <program.out>
<program.out>
is not important, as long as the
correctness of the contestants' program can be deduced from the
contents by the compare program.
DOMjudge includes an alerting system. This allows the administrator to receive alerts when important system events happen, e.g. an error occurs, or a submission or judging is made.
These alerts are passed to a plugin script alert
which can
easily be adapted to fit your needs. The default script emits
different beeping sounds for the different messages when the
beep
program is available, but it could for example also be
modified to send a mail on specific issues, connect to monitoring
software like Nagios, etc. For more details, see the script
lib/alert
.
There are a few more places where some configuration of the system can be made. These are sometimes needed in non-standard environments.
bin/dj_make_chroot
on a judgehost some changes to
variables can be made, most notably DEBMIRROR
to
select a Debian mirror site near you.lib/judge/chroot-startstop.sh
can be
modified to suit your local environment. See comments in that
file for more information.DOMjudge supports two submission methods: via the command line submit program and via the web interface. From experience, both methods have users that prefer the one above the other.
The command line submit client sends submissions using the API interface internally. This requires the libcURL and libjsonCPP library development files at compile time (the submit client is statically linked to avoid a runtime dependency).
The database is the authoritative version for submission source files;
file system storage is available as an easy way to access the source
files and as backup, but only when the web server has write
permissions on <domjudge_submitdir>
. File system
storage is ignored if these permissions are not set. The program
bin/restore_sources2db
is available to recover the submission
table in the database from these files.
DOMjudge uses a MySQL or MariaDB database server for information storage. Where this document talks about MySQL, it can be understood to also apply to MariaDB.
The database structure and privileges are included in MySQL
dump files in the sql subdirectory. The default database name is
domjudge
. This can be changed manually in the
etc/dbpasswords.secret
file: the database name as specified
in this file will be used when installing.
Installation of the database is done with bin/dj-setup-database
.
For this, you need an installed and configured MySQL server and
administrator access to it. Run
dj-setup-database genpass dj-setup-database [-u <admin_user>] [-p <password>|-r] install
etc/dbpasswords.secret
(optionally change the random
generated password, although it is not needed for normal operation).
Then it creates the database and user and inserts some
default/example data into the domjudge database. The option
-r
will prompt for a password for mysql; when no user is
specified, the mysql client will try to read
credentials from $HOME/.my.cnf
as usual. The command
uninstall
can be passed to dj-setup-database
to
remove the DOMjudge database and users; this deletes all data!
The domjudge database contains a number of tables, some of which need to be manually filled with data before the contest can be run. See the database section of Contest setup for details.
For Apache, there are countless documents on how to maximise performance.
Of particular importance is to ensure that the MaxClients
setting
is high enough to receive the number of parallel requests you expect, but
not higher than your amount of RAM allows.
As for PHP, the use of an opcode cache like the Alternative PHP Cache
(Debian package: php-apc
) is beneficial for performance. For
uploading large testcases, see the
section about memory limits.
It may be desirable or even necessary to fine tune some MySQL default settings:
max_connections
: The default 100 is too low, because of the
connection caching by Apache threads. 1000 is more appropriate.max_allowed_packet
: The default of 16MB might be too
low when using large testcases. This should be changed both in the
MySQL server and client configuration and be set to about twice the
maximum testcase size.The MySQL server is the central place of information storage for DOMjudge. Think well about what to do if the MySQL host fails or loses your data.
A very robust solution is to set up a replicating MySQL server on another host. This will be a hot copy of all data up to the second, and can take over immediately in the event of failure. The MySQL manual has more information about setting this up.
Alternatively, you can make regular backups of your data to another host,
for example with mysqldump
, or use a RAID based system.
Replication can also be used to improve performance, by directing all select-queries to one or more replicated slave servers, while updates will still be done to the master. This is not supported out of the box, and will require making changes to the DOMjudge source.
For the web interface, you need to have a web server (e.g. Apache) installed on the domserver and made sure that PHP correctly works with it. Refer to the documentation of your web server and PHP for details.
You should turn PHP's magic_quotes_*
options off. We
also recommend to turn off register_globals
.
To configure the web server for DOMjudge, use the Apache configuration
snippet from etc/apache.conf
. It contains examples for
configuring the DOMjudge pages with an alias directive, or as a
virtualhost, optionally with SSL; it also contains PHP and security
settings. Reload the web server for changes to take effect.
The judgehosts connect to DOMjudge via the DOMjudge API so need to be able to access at least this part of the web interface.
All DOMjudge daemons and web interface scripts support logging and
debugging in a uniform manner via functions in lib.error.*
.
There are three ways in which information is logged:
stderr
for daemons or to the web page for
web interface scripts (the latter only on serious issues).LOGFILE
, which is set
in each program. Unsetting this variable disables this method.SYSLOG
configuration variable in etc/common-config.php
. This
option gives the flexibility of syslog, such as remote logging.
See the syslog(daemon) documentation for more information.
Unsetting this variable disables this method.VERBOSE
: defaults to LOG_INFO
in
daemons and LOG_ERR
in the web interface) and for
log file/syslog (LOGLEVEL
: defaults to LOG_DEBUG
).
In case of problems, it is advisable to check the logs for clues.
Extra debugging information can be obtained by setting the config
option DEBUG
to a bitwise-or of the available
DEBUG_*
flags in etc/common-config.php
, to e.g.
generate extra SQL query and timing information in the web interface.
A few extra steps might need to be taken to completely install and configure a judgehost.
For running solution programs under a non-privileged user, a user has to be added to the system(s) that act as judgehost. This user does not need a home-directory or password, so the following command would suffice to add a user `domjudge-run' with minimal privileges.
On RedHat:
useradd -d /nonexistent -g nobody -M -n -s /bin/false domjudge-runOn Debian:
useradd -d /nonexistent -g nogroup -s /bin/false domjudge-run
For other systems check the specifics of your useradd command.
This user must also be configured as the user under which programs run
via configure --enable-runuser=USER
; the default is
domjudge-run
.
Runguard
needs to be able to become root for certain operations
like changing to the runuser and performing a chroot. Also, the default
chroot-startstop.sh
script uses sudo to gain privileges for
certain operations. There's a pregenerated /etc/sudoers.d/
snippet
in etc/sudoers-domjudge
that contains all required rules. You can
put the lines in the snippet at the end of /etc/sudoers
, or, for
modern sudo versions, place the file in /etc/sudoers.d/
. If you
change the user you run the judgehost at, or the installation paths, be
sure to update the sudoers rules accordingly.
When the chroot setting is enabled (default), a static POSIX shell has
to be available for copying it to the chroot environment. For Linux
i386, a static Dash shell is included, which works out of the box. For
other architectures or operating systems, a shell has to be added
manually. Then simply point the lib/sh-static
symlink to this
file. If you want to support languages that cannot be compiled to
statically linked binaries, e.g. byte-compiled languages such as Java,
or interpreted languages such as Python, then a complete chroot
environment must be built and configured. See the appendix on
setting up a chroot for more
details.
The judgehost connects to the domserver via a REST API. You need to
create an account for the judgedaemons to use (this may be a
shared account between all judgedaemons) with a difficult,
random password and the 'judgehost' role. On each judgedaemon,
create a file etc/restapi.secret
containing the URL,
username and password whitespace-separated on one line, for example:
http://example.edu/domjudge/api/ judgehosts MzfJYWF5agSlUfmiGEy5mgkfqU
Upon its first connection to the domserver API the judgehost will be auto-registered and will be by default enabled. If you wish to add a new judgehost but have it initially disabled, you can add it manually through the DOMjudge web interface and set it to disabled before starting the judgedaemon.
The submit client can be built with make submitclient
. There
is no make target to install the submit client, as its location will
very much depend on the environment. You might e.g. want to copy it to
all team computers or make it available on a network filesystem. Note
that if the team computers run a different (version of the) operating
system than the jury systems, then you need to build the submit
client for that OS.
The submit client needs to know the URL of the domserver. This
can be passed as a command line option or environment variable. The
latter option makes for easier usage. A sample script
submit_wrapper.sh
is included, which sets this variable.
See that script for more details on how to set this up.
The submit client authenticates to the DOMjudge API via either the
configured authentication scheme, or can use the DOMjudge internal
username and password combination for a given user account regardless
of authentication scheme. For example, when the IPADDRESS scheme is
used, no additional configuration is required because submmissions
will come from the correct IP address of the team. When another
scheme is used, it may be necessary to place username and password
combinations in the team's account so the submit client can use
those. In this case these are always the DOMjudge internal
password, so not e.g. LDAP passwords when using that scheme. The
credentials are placed in the file ~/.netrc
, with example
content:
machine domserver.example.com login user0123 password Fba^2bHzzSee the netrc(4) manual page for more details. You may want to distribute those
.netrc
files in advance
over the team accounts. Make sure they are only readable for the
user itself.
The submit client can also be built under Windows when the Cygwin environment is installed. First the Cygwin setup.exe program must be downloaded and installed with GCC, curl-devel and maybe some more packages included.
When Cygwin is correctly installed with all necessary development
tools, the submit binary can be created by running configure
followed by make submit.exe
in the submit
directory.
There are three sets of documentation available under the doc
directory in DOMjudge:
for administrators of the system (this document),
for judges, describing the jury web interface and giving some general information about this system,
for teams, explaining how to use the system and what restrictions there are.
The team manual is only available in PDF format and must be built from
the LaTeX sources in doc/team
after configuration of the
system. A prebuilt team manual is included, but note that it contains
default/example values for site-specific configuration settings such
as the team web interface URL and judging settings such as the memory
limit. We strongly recommend rebuilding the team manual to include
site-specific settings and also to revise it to reflect your contest
specific environment and rules.
Besides a standard LaTeX installation, the team manual
requires the svn
and expdlist
packages. These are
available in TeX Live in the texlive-latex-extra
package in
any modern Linux distribution. Alternatively, you can download and
install them manually from their respective subdirectories in
http://mirror.ctan.org/macros/latex/contrib.
When the docs
part of DOMjudge is installed and site-specific
configuration set, the team manual can be generated with the command
genteammanual
found under docs/team
. The PDF
document will be placed in the current
directory or a directory given as argument. The option -w WEBBASEURI
can be passed to set the base URI of the DOMjudge webinterface; it
should end with a slash and defaults to http://example.com/domjudge/
.
The following should do it on a Debian-like system:
sudo apt-get install make texlive-latex-extra texlive-latex-recommended texlive-lang-european cd .../docs/team ./genteammanual [-w http://your.location.example.com/domjudge/] [targetdir]
The team manual is currently available in two languages: English and Dutch. We welcome any translations to other languages.
The administrator's and judge's manuals are available in PDF and HTML format and prebuilt from SGML sources. Rebuilding these is not normally necessary. To rebuild them on a Debian-like system, the following commands should do it:
sudo apt-get install linuxdoc-tools make zip ghostscript groff texlive-latex-recommended make -C doc/admin docs make -C doc/judge docs
DOMjudge has experimental support for using Linux Control Groups or cgroups for process isolation in the judgedaemon. Using cgroups gives more accurate measurement of actually allocated memory, which is helpful with interpreters like Java that reserve but not actually use lots of memory. Also, the feature will restrict network access so no separate measures are necessary, and allows to run multiple judgedaemons on a multi-core machine.
The judgedaemon needs to run a recent Linux kernel (at least 3.2.0). The following steps configure cgroups on Debian wheezy. Instructions for other distributions may be different (send us your feedback!).
# apt-get install libcgroup-dev
(or # yum install libcgroup-devel
on RedHat)/etc/default/grub
and change the default commandline to GRUB_CMDLINE_LINUX_DEFAULT="quiet cgroup_enable=memory swapaccount=1"
.
Then run update-grub
and reboot../configure
and look for cgroup in the output. Then rebuild the runguard with make build
.You have now configured the system to use cgroups, but you need to create
the actual cgroups that DOMjudge will use. For that, you can use the
script under misc-tools/create_cgroups
. Edit the script to
match your situation first.
This script needs to be re-run after each boot (e.g., add it to
the judegedaemon init script).
With cgroup support set up, as per the section above, you can run multiple judgedaemons on one multi-cpu or multi-core machine, dedicating one cpu core to each judgedaemon.
To that end, set the cpuset.cpus
variable in
etc/cgroup-domjudge.conf
snippet correctly, e.g. to use all
cores on a quad-core machine set it to 0-3
, and add extra
unprivileged users to the system, i.e. add users
domjudge-run-<X>
(where X
runs through
0,1,2,3
) with useradd
as described in section
installation of a judgehost.
Finally, start each of the judgedaemons with:
$ judgedaemon -n <X>
DOMjudge can be configured to run on HTTPS, so teams and judgedaemons communicate with the domserver securely over encrypted SSL/TLS connections. Setting up SSL for Apache is documented in the Apache manual and in many tutorials around the web.
The judgedaemons must recognise the CA you're using, otherwise they will
refuse to connect over HTTPS. If your judgedaemon gives an error message
about an untrusted certificate, put your domserver's certificate in
/etc/ssl/certs/yourname.crt
of each judgehost (and on the team
machines when using the commandline submit client) and run:
# c_rehash
When loading teams from the ICPC registration system through the import feature in DOMjudge, the certificate from icpc.baylor.edu must similarily be acceped by your local installation or if not, added via the procedure above.
We advise to install an NTP-daemon (Network Time Protocol) to make sure the time between domserver and team computers is in sync.
It is recommended to configure the local desktop printing of team workstations whereever possible: this has the most simple interface and allows teams to print from within their editor.
If this is not feasible, DOMjudge includes support for printing via
the DOMjudge web interface: the DOMjudge server then needs to be
able to deliver the uploaded files to the printer. It can be
enabled via the enable_printing
configuration option in
the administrator interface. The exact command used to send the
files to a printer can be changed the function send_print()
in lib/www/printing.php
.
The following issues can be considered to improve consistency in judging.
echo 0 > /proc/sys/kernel/randomize_va_space
There is some support to upgrade DOMjudge to newer versions. Note that
this functionality is not extensively tested, so when you plan to
upgrade, you are strongly advised to backup the DOMjudge database
and other data before continuing. We also advise to check the
ChangeLog
file for important changes.
Upgrading the filesystem installation is probably best done by installing the new version of DOMjudge in a separate place and transferring the configuration settings from the old version.
There are SQL upgrade scripts to transform the database including its
data to the layout of a newer version. The scripts can be found under
sql/upgrade
and each script applies changes between two
consecutive DOMjudge versions. At the beginning of each script, a check
is performed which will let MySQL bail out with an error if it should
not be applied anymore. Note that the scripts must be applied in order
(sorted by release). These scripts can be applied by running
dj-setup-database upgrade
.