Captive Portal: Fails to start wit sqlite3.OperationalError

[awerner]

Describe the bug
The captiveportal-service fails to start after creation of the first Zone. The error reported by configd is:

configd.py: [585ab444-eaed-4b6c-8949-b051b8844575] Script action  failed with Command  '/usr/local/opnsense/scripts/OPNsense/CaptivePortal/listClients.py  /zoneid '0' /output_type 'json'' returned non-zero exit status 1 at  Traceback (most recent call last): File  "/usr/local/opnsense/service/modules/processhandler.py", line 481, in  execute stdout=output_stream, stderr=error_stream) File  "/usr/local/lib/python2.7/subprocess.py", line 190, in check_call raise  CalledProcessError(retcode, cmd) CalledProcessError: Command  '/usr/local/opnsense/scripts/OPNsense/CaptivePortal/listClients.py  /zoneid '0' /output_type 'json'' returned non-zero exit status 1

Manually calling the offending script to get a full stack trace:

# /usr/local/opnsense/scripts/OPNsense/CaptivePortal/listClients.py /zoneid '0' /output_type 'json'
Traceback (most recent call last):
  File "/usr/local/opnsense/scripts/OPNsense/CaptivePortal/listClients.py", line 48, in <module>
    cpDB = DB()
  File "/usr/local/opnsense/scripts/OPNsense/CaptivePortal/lib/db.py", line 41, in __init__
    self.open()
  File "/usr/local/opnsense/scripts/OPNsense/CaptivePortal/lib/db.py", line 57, in open
    self._connection = sqlite3.connect(self.database_filename)
sqlite3.OperationalError: unable to open database file
Exception AttributeError: "'NoneType' object has no attribute 'close'" in <bound method DB.__del__ of <lib.db.DB object at 0x5b267fb6550>> ignored

The database_filename is /var/captiveportal/captiveportal.sqlite, but:

# ls -l /var/
total 108
drwxr-xr-x   2 root     wheel     512 Mar 10 03:41 account
drwxr-xr-x   4 root     wheel     512 Apr 11 23:04 at
drwxr-x---   4 root     audit     512 Apr 11 23:04 audit
drwxrwx---   2 root     authpf    512 Mar 10 03:41 authpf
drwxr-x---   2 root     wheel     512 Apr 17 03:33 backups
drwxr-xr-x   6 root     wheel     512 Apr 11 23:04 cache
drwxr-x---   2 root     wheel     512 Apr 17 07:53 crash
drwxr-x---   3 root     wheel     512 Apr 11 23:04 cron
drwxr-xr-x  19 root     wheel    1024 Apr 17 07:39 db
drwxr-xr-x   8 dhcpd    dhcpd     512 Apr 11 23:05 dhcpd
dr-xr-xr-x   2 root     wheel     512 Apr 11 23:08 empty
drwxr-xr-x   5 root     wheel     512 Apr 17 08:03 etc
drwxrwxr-x   2 root     games     512 Mar 10 03:41 games
drwx------   2 root     wheel     512 Mar 10 03:41 heimdal
drwxr-xr-x   3 root     wheel     512 Apr 11 23:04 lib
drwxr-xr-x  10 root     wheel    1024 Apr 17 03:01 log
drwxrwxr-x   2 root     mail      512 Apr 12 00:11 mail
drwxr-xr-x   2 daemon   wheel     512 Mar 10 03:41 msgs
drwxr-x---   2 root     wheel     512 Apr 17 08:03 netflow
drwxr-xr-x   2 root     wheel     512 Mar 10 03:41 preserve
drwxr-xr-x  10 root     wheel    1024 Apr 17 03:33 run
drwxrwxr-x   2 root     daemon    512 Mar 10 03:41 rwho
drwxr-xr-x   8 root     wheel     512 Apr 11 23:04 spool
drwxr-xr-x   3 squid    squid     512 Apr 11 23:04 squid
drwxrwxrwt   3 root     wheel     512 Apr 11 23:04 tmp
drwxr-xr-x   9 unbound  unbound   512 Apr 17 07:40 unbound
drwxr-xr-x   2 root     wheel     512 Mar 10 03:41 yp

To Reproduce
Steps to reproduce the behavior:

• Installed the Freeradius Plugin, created Radius User and Client 127.0.0.1
• Added the local Radius as Auth Server
• Added new Captive Portal Zone, with both "Local Database" and the local Radius as Authentication sources
• Apply
• The directory /var/captiveportal is not created, the service captiveportal fails to start.

Expected behavior

• The directory /var/captiveportal is also created with the configuration described above, so the service captiveportal starts as designed.

Workaround
Changing the Authentication source in the Captive Portal zone to "Local Database" only creates the directory, then the Radius server as authentication source can be added afterwards.

Environment

OPNsense 19.1.6-amd64
FreeBSD 11.2-RELEASE-p9-HBSD
OpenSSL 1.0.2r 26 Feb 2019
AMD G-T40E Processor (2 cores)
APU1D4

[AdSchellevis]

ok, that's odd, the rc scripts should create the directories.

core/src/etc/rc.d/captiveportal

Line 88 in ac6a1ef

mkdir -p $CPWORKDIR/$zonedirname

Are you sure its enabled and applied?

We should fix the list clients to not crash when the directory doesn't exist, but that probably won't fix your issue.

[awerner]

Looks like the order during the first startup of captiveportal is wrong:

configd.log:Apr 17 07:47:51 leo configd.py: [7d4f2ef2-f10e-47fc-adec-d2f24dcea1b9] Script action failed with Command '/usr/local/opnsense/scripts/OPNsense/CaptivePortal/listClients.py /zoneid '0' /output_type 'json'' returned non-zero exit status 1 at Traceback (most recent call last):   File "/usr/local/opnsense/service/modules/processhandler.py", line 481, in execute     stdout=output_stream, stderr=error_stream)   File "/usr/local/lib/python2.7/subprocess.py", line 190, in check_call     raise CalledProcessError(retcode, cmd) CalledProcessError: Command '/usr/local/opnsense/scripts/OPNsense/CaptivePortal/listClients.py /zoneid '0' /output_type 'json'' returned non-zero exit status 1
...
configd.log:Apr 17 07:48:21 leo configd.py: [fbf647a8-3bd1-4a7a-ac67-7dcb8674f731] startup captiveportal services

Interestingly, the ls -l /var/ occurred right after 07:48, but the captiveportal directory was not existent at that time.
Seems as the workaround is also just "change some captive portal setting and apply", as only the first start seems to be affected.

[AdSchellevis]

then a193e1e will probably fix the issue

[awerner]

Applied the patch in a vm for testing, looks good, thank you :)

[AdSchellevis]

thanks for confirming!