diff options
author | Scott Ullrich <sullrich@pfsense.org> | 2009-09-17 21:16:50 -0400 |
---|---|---|
committer | Scott Ullrich <sullrich@pfsense.org> | 2009-09-17 21:16:50 -0400 |
commit | 5caa648d36898a3c06e4b3fb4886d8d1e2d2b873 (patch) | |
tree | 1f6b435719d6a6afba43ef2f5e8fa88d3a436161 /etc/inc | |
parent | b95c4db290347eb7f45e217dd3641aa3f26a1ef7 (diff) | |
download | pfsense-5caa648d36898a3c06e4b3fb4886d8d1e2d2b873.zip pfsense-5caa648d36898a3c06e4b3fb4886d8d1e2d2b873.tar.gz |
It seems upon captive portal startup the captiveportal.db file is not written out until the /etc/rc.prunecaptiveportal script is run. If the Operator decides to visit status -> captive portal right after enabling the service they will be greated with some nasty nasty errors. Silence this nonsense by creating a blank captiveportal.db file right after nuking it.
Diffstat (limited to 'etc/inc')
-rw-r--r-- | etc/inc/captiveportal.inc | 3 |
1 files changed, 3 insertions, 0 deletions
diff --git a/etc/inc/captiveportal.inc b/etc/inc/captiveportal.inc index 6be6c66..d09cf82 100644 --- a/etc/inc/captiveportal.inc +++ b/etc/inc/captiveportal.inc @@ -98,6 +98,9 @@ function captiveportal_configure() { unlink_if_exists("{$g['vardb_path']}/captiveportal_ip.db"); unlink_if_exists("{$g['vardb_path']}/captiveportal_radius.db"); + /* setup new database in case someone tries to access the status -> captive portal page */ + touch("{$g['vardb_path']}/captiveportal.db"); + /* write portal page */ if ($config['captiveportal']['page']['htmltext']) $htmltext = base64_decode($config['captiveportal']['page']['htmltext']); |