# vim:ft=perl
# travelynx.conf must be a valid perl hash reference. String values must be
# quoted and hash items must end with a comma. You can access environment
# variables via $ENV, e.g. by writing $ENV{TRAVELYNX_DB_HOST} instead of
# 'localhost'. You can validate via 'perl -c travelynx.conf'.

{
	# Optional announcement, e.g. to indicate maintenance or backend issues.
	#announcement => 'The IRIS backend is flaky. Real-time data may not be available.',

	# Base URL of this travelynx installation, e.g. "https://travelynx.de" for
	# travelynx.de. Used to identify this travelynx instance when performing API
	# requests (so API providers know whom to contact case of issues) and for
	# imprint and other links in travelynx E-Mails. Note that this entry is
	# only used when travelynx is performing requests or sending E-mails from
	# a "work", "worker", or "maintenance" job. Otherwise, it will infer the
	# base URL from the HTTP request.  If your travelynx instance is reachable
	# via multiple URLs, use any one of them.
	base_url => Mojo::URL->new('https://FIXME.local'),

	# Cache directories for schedule and realtime data. Mandatory.  The parent
	# directory ('/var/cache/travelynx' in this case) must already exist.
	cache => {
		schedule => '/var/cache/travelynx/iris',
		realtime => '/var/cache/travelynx/iris-rt',
	},

	# Database configuration. host and port are optional
	# (defaulting to localhost:5432), the rest is mandatory.
	db => {
		host => 'localhost',
		port => 5432,
		database => 'travelynx',
		user => 'travelynx',
		password => die("Changeme!"),
	},

	# Settings specific to HAFAS backends.
	# For instance, the PKP backend is hidden behind a GeoIP filter, hence
	# travelynx only supports it if travelynx.conf either indicates that it
	# is reachable or specifies a proxy.
	hafas => {
		PKP => {
			# geoip_ok => 1,          # <- EITHER THIS
			# proxy => 'socks://...', # <- OR THIS
		},
	},

	# These settings control the amount and (re)spawn behaviour of travelynx
	# worker processes as well as IP, port, and PID file. They are suitable for
	# up to a few dozen concurrent users. If your site has more traffic, you
	# may want to increase the number of worker processes.
	# See the Mojo::Server::Hypnotoad manual for details.
	hypnotoad => {
		accepts  => 100,
		clients  => 10,
		listen   => [ 'http://127.0.0.1:8093' ],
		pid_file => '/tmp/travelynx.pid',
		workers  => 2,
		spare    => 2,
	},

	influxdb => {
		# travelynx can log statistics and performance attributes to InfluxDB.
		# To do so, create a travelynx database in your InfluxDB, and point url
		# (below) to the corresponding write URL.  The URL may use anything from
		# plain HTTP to HTTPS with password authentication.
		## url => 'https://user:password@host/write?db=travelynx',
	},

	mail => {
		# To disable outgoing mail for development purposes, uncomment the
		# following line.  Mails will instead be logged as Mojolicious "info"
		# messages, causing their content to be printed on stdout.
		## disabled => 1,

		# Otherwise, specify the sender ("From" field) for mail sent by travelynx
		# here.  E.g. 'Travelynx <mail@example.org>'
		from => die("Changeme!"),
	},

	registration => {
		# To disable registration for your instance, uncomment the following
		# line.
		## disabled => 1,

		# To block registration from certain IPs, uncomment the following line
		# and point it to a file containing one IPv4 or IPv6 address per line.
		# Blocking IP ranges is not supported.
		## denylist => "denylist.txt",
	},

	# Links to source code and issue tracker shown on the about page.
	# Please change them if you are using a fork.
	ref => {
		# Optional
		issues => 'https://github.com/derf/travelynx/issues',

		# Mandatory
		source => 'https://github.com/derf/travelynx',
	},

	# Secrets used for cookie signing and verification. Must contain at least
	# one random string. If you specify several strings, the first one will
	# be used for signing new cookies, and the remaining ones will still be
	# accepted for cookie validation.
	secrets => [
		die("Changeme!"),
	],

	# optionally, users can link travelynx and traewelling accounts, and
	# automatically synchronize check-ins.
	# To do so, you need to create a travelynx application on
	# <https://traewelling.de/settings/applications>. The application
	# must be marked as "Confidential" and have a redirect URL that matches
	# $base_url/oauth/traewelling, where $base_url refers to the URL configured
	# above. For instance, travelynx.de uses
	# 'https://travelynx.de/oauth/traewelling'. An incorrect redirect URL will
	# cause OAuth2 to fail with unsupported_grant_type.
	#
	# Note that the travelynx/traewelling OAuth2 integration does not support
	# travelynx installations that are reachable on multiple URLs at the
	# moment -- linking a traewelling account is only possible when accessing
	# travelynx via the base URL.
	traewelling => {

		# Uncomment the following block and insert the application ID and
		# secret obtained from https://traewelling.de/settings/applications
		# -> your application -> Edit.

		#oauth => {
		#	id => 1234,
		#	secret => 'mysecret',
		#}

		# By default, the "work" or "worker" command does not just update
		# real-time data of active journeys, but also performs push and pull
		# synchronization with traewelling for accounts that have configured it.
		# Traewelling pull synchronization currently relies on polling the user
		# status on traewelling.de, so large travelynx instances may want to
		# run pull synchronization less frequently than regular "work" commands
		# and traewelling push synchronization.
		#
		# To do so, uncomment "separate_worker" below and create a cronjob that
		# periodically runs "perl index.pl traewelling" (push and pull) or
		# two separate cronjobs that run "perl index.pl traewelling push" and
		# "perl index.pl traewelling pull", respectively.

		# separate_worker => 1,
	},

	version => qx{git describe --dirty} // 'experimental',
};
