What owner:group & permissions do we end up with for /var/log/apache2 — with fl.yml no longer (attempting) to set this to www-data:www-data '0770' ?

Is this OS-dependent?

(Are we Ok with that?)

Is it possible PR #2149 "Fix for Admin Console login popup loop: install NGINX after Apache & MySQL" might no longer be necessary, after this PR #2171 is merged?

What owner:group & permissions do we end up with for /var/log/apache2 — with fl.yml no longer (attempting) to set this to www-data:www-data '0770' ?

Is this OS-dependent?

(Are we Ok with that?)

would be set by logrotate

Is it possible PR #2149 "Fix for Admin Console login popup loop: install NGINX after Apache & MySQL" might no longer be necessary, after this PR #2171 is merged?

I'd like to see nginx after httpd due to the ports.conf file being installed but either should work.

What owner:group & permissions do we end up with for /var/log/apache2 — with fl.yml no longer (attempting) to set this to www-data:www-data '0770' ?
Is this OS-dependent?
(Are we Ok with that?)

would be set by logrotate

Finding out on Raspbian + Ubuntu 19.10 + Debian 10.2...what owner:group and permissions result...is a really good idea in the coming days!

Everybody loves to trash-talk documentation, but as this converges we should verify @georgejhunt's excellent start (https://github.com/iiab/iiab/blob/master/roles/captiveportal/README.md) for new devs & new implementers in coming days...

Ref: #1182

What owner:group & permissions do we end up with for /var/log/apache2 — with fl.yml no longer (attempting) to set this to www-data:www-data '0770' ?
Is this OS-dependent?
(Are we Ok with that?)

would be set by logrotate

Finding out on Raspbian + Ubuntu 19.10 + Debian 10.2...what owner:group and permissions result...is a really good idea in the coming days!

I pretty sure the distros have a handle on the correct routines for rotating the log files.

I'm hoping @georgejhunt has time to review this in the coming 48h, but if he's travelling and that's not possible I'll try to call him (unfort not possible this morning in the end!)

This PR started dealing with a permissions problem. Then enlarged into a concern for how uwsgi is initiated by captive portal (for a log permissions problem, or not). At this point there are 9 files changed. Perhaps line 52 in roles/awstats tasks/install.yml should be added to the list.

I vote to merge and then test the result. It's unfortunate that we need to worry about interactions between awstats, uwsgi, captive-portal, and admin-console -- but that seems to be the nature of our steps forward.

At this point, using each distro's logrotate seems like the first thing to try.

At this point there are 9 files changed. Perhaps line 52 in roles/awstats tasks/install.yml should be added to the list.

What specifically about https://github.com/iiab/iiab/blob/master/roles/awstats/tasks/install.yml#L52-L56 ? Pasted in here...is there a reason to remove this stanza now?

- name: Symlink /usr/lib/cgi-bin/awstats/awstats.pl -> /usr/lib/cgi-bin/awstats.pl so old Apache links to awstats will work after change to NGINX
  file:
    src: /usr/lib/cgi-bin/awstats.pl
    path: /usr/lib/cgi-bin/awstats/awstats.pl
    state: link

Is this still compatible with admin-console.ini installed in iiab-admin-console including that it runs as the {{ apache_user }} ?

Both captiveportal.ini and admin-console.ini use {{ apache_user }} in their templates while /usr/share/uwsgi/conf/default.ini contains:

uid = www-data
gid = www-data

Just a thought, after our call a few minutes ago:
It's possible that the startup problems I experienced with uwsgi may have been permissions problems which moving the log files is fixing.

Not to mention that if this is a real user setting it should be declared in local_vars.yml but nothing uses 'admin_console_install' in iiab-admin-console

Perhaps both variables default_vars.yml#L233-L235 should be used in local_vars.yml after all? Certainly it's a common request.among the Raspberry Pi Zero W crowd!

Even though I've no idea who introduced these 2 vars...

admin_console_install: True
admin_console_enabled: True

Do you know?

cffb6af part of the initial PR

1. @georgejhunt @jvonau can you confirm output of 'systemctl status uwsgi' looks good below?

   10.8.0.70 = 161-u1804-srv-BIG-0120-PR2171 shows...
   http://paste.ubuntu.com/p/5c55MgWy4J/

   10.8.0.74 = 162-deb102-srv-BIG-0120-PR2171 shows...
   http://paste.debian.net/1126851/

   i.e. both OS's above show 3 lines of...
   /usr/bin/uwsgi --ini /usr/share/uwsgi/conf/default.ini --ini /etc/uwsgi/apps-enabled/admin-console.ini --daemonize /var/log/uwsgi/app/admin-console.log
   ...and both OS's also shows 3 lines of...
   /usr/bin/uwsgi --ini /usr/share/uwsgi/conf/default.ini --ini /etc/uwsgi/apps-enabled/captiveportal.ini --daemonize /var/log/uwsgi/app/captiveportal.log

2. Admin Console quick test: http://10.8.0.70/admin or http://10.8.0.74/admin -> Configure -> Save Configuration works on both above VM's (after the 2nd reboot anyway...it seems 10.8.0.74 is a slow enough VM that it needed that 2nd reboot for both services 'nginx' & 'uwsgi' etc to start properly!)

root@box:~# systemctl status iiab-cmdsrv
● iiab-cmdsrv.service - Provides the IIAB Command Server
   Loaded: loaded (/etc/systemd/system/iiab-cmdsrv.service; enabled; vendor preset: enabled)
   Active: failed (Result: timeout) since Mon 2020-01-20 12:44:58 EST; 43min ago
  Process: 530 ExecStart=/opt/admin/cmdsrv/iiab-cmdsrv3.py --daemon (code=killed, signal=TERM)

Jan 20 12:43:23 box.lan systemd[1]: Starting Provides the IIAB Command Server...
Jan 20 12:44:54 box.lan systemd[1]: iiab-cmdsrv.service: Start operation timed out. Terminating.
Jan 20 12:44:58 box.lan systemd[1]: iiab-cmdsrv.service: Control process exited, code=killed, status=15/TERM
Jan 20 12:44:58 box.lan systemd[1]: iiab-cmdsrv.service: Failed with result 'timeout'.
Jan 20 12:44:58 box.lan systemd[1]: Failed to start Provides the IIAB Command Server.

Captive Portal is not working before & after reboot of fresh install [of this PR] on RPi 4, when testing with Android 8.1 that worked with CP during prior tests over the last week.

@jvonau: anything I should check here, on 10.8.0.78 = 181-rpi4-1g-lite-BIG-0120-PR2171 ?

Traceback (most recent call last): File "capture-wsgi.py", line 49, in logging.basicConfig(filename='/var/log/uwsgi/app/captiveportal.log',format='%(asctime)s.%(msecs)03d:%(name)s:%(message)s', datefmt='%M:%S',level=loggingLevel) File "/usr/lib/python3.7/logging/init.py", line 1900, in basicConfig h = FileHandler(filename, mode) File "/usr/lib/python3.7/logging/init.py", line 1092, in init StreamHandler.init(self, self._open()) File "/usr/lib/python3.7/logging/init.py", line 1121, in _open return open(self.baseFilename, self.mode, encoding=self.encoding) PermissionError: [Errno 13] Permission denied: '/var/log/uwsgi/app/captiveportal.log'

Last commit moved the log directory outside of uwsgi to avoid having to fiddle with permissions in /var/log/uwsgi/app which would of needed altering uwsgi's logroate file.

@georgejhunt nothing is being logged to /var/log/captiveportal/captiveportal.log -- is that the expected behavior ??

Aside/FYI: several things are being logged the /var/log/uwsgi/app/captiveportal.log