diff --git a/docs/cluster/appendix.asciidoc b/docs/cluster/appendix.asciidoc index c722c473e074..980eb315b93e 100644 --- a/docs/cluster/appendix.asciidoc +++ b/docs/cluster/appendix.asciidoc @@ -323,7 +323,7 @@ mysql -u root -p pf -h localhost ---- If its not, make sure you check the MariaDB log -([filename]`/usr/local/pf/logs/mariadb_error.log`) +([filename]`/usr/local/pf/logs/mariadb.log`) ===== Sync nodes A and B @@ -337,7 +337,7 @@ rm -fr /var/lib/mysql/* systemctl start packetfence-mariadb ---- -Should there be any issues during the sync, make sure you look into the MariaDB log ([filename]`/usr/local/pf/logs/mariadb_error.log`) +Should there be any issues during the sync, make sure you look into the MariaDB log ([filename]`/usr/local/pf/logs/mariadb.log`) Once both nodes have completely synced (try connecting to it using the MariaDB command line), then you can break the cluster election command you have diff --git a/docs/cluster/troubleshooting_a_cluster.asciidoc b/docs/cluster/troubleshooting_a_cluster.asciidoc index 8fb9ab05dded..22851ddccff4 100644 --- a/docs/cluster/troubleshooting_a_cluster.asciidoc +++ b/docs/cluster/troubleshooting_a_cluster.asciidoc @@ -33,7 +33,7 @@ Important variables: * `wsrep_last_committed`: Sequence number of the most recently committed transaction. You can identify the most advanced node with this value. * `wsrep_local_state_comment`: Current sync state of the cluster. A healthy state is 'Synced'. Refer to the Galera cluster documentation for the meaning of the other values this can have. -In order for the cluster to be considered healthy, all nodes must be listed under `wsrep_incoming_addresses` and `wsrep_local_state_comment` must be `Synced`. Otherwise look in the MariaDB log ([filename]`/usr/local/pf/logs/mariadb_error.log`) +In order for the cluster to be considered healthy, all nodes must be listed under `wsrep_incoming_addresses` and `wsrep_local_state_comment` must be `Synced`. Otherwise look in the MariaDB log ([filename]`/usr/local/pf/logs/mariadb.log`) === Automatic clustering resolution service: galera-autofix @@ -123,7 +123,7 @@ systemctl start packetfence-mariadb You should then see `/var/lib/mysql` be populated again with the data and once MariaDB becomes available again on the server, it means the sync has completed. In case of issues, look in the MariaDB log file -(`/usr/local/pf/logs/mariadb_error.log`) +(`/usr/local/pf/logs/mariadb.log`) WARNING: After stopping the `packetfence-mariadb` service, be sure there is no more `mysql` process running. diff --git a/docs/cluster/understanding_the_galera_cluster_synchronization.asciidoc b/docs/cluster/understanding_the_galera_cluster_synchronization.asciidoc index 9f470f535da6..814474b45d5e 100644 --- a/docs/cluster/understanding_the_galera_cluster_synchronization.asciidoc +++ b/docs/cluster/understanding_the_galera_cluster_synchronization.asciidoc @@ -18,7 +18,7 @@ endif::[] The Galera cluster stack used by PacketFence resembles a lot to how a normal MariaDB Galera cluster behaves but it contains hooks to auto-correct some issues that can occur. -NOTE: A lot of useful information is logged in the MariaDB log which can be found in `/usr/local/pf/logs/mariadb_error.log` +NOTE: A lot of useful information is logged in the MariaDB log which can be found in `/usr/local/pf/logs/mariadb.log` === Quorum behavior diff --git a/docs/installation/appendix.asciidoc b/docs/installation/appendix.asciidoc index 321e0a00067b..53cb41cdbfe4 100644 --- a/docs/installation/appendix.asciidoc +++ b/docs/installation/appendix.asciidoc @@ -93,7 +93,7 @@ For Mariabackup: # chown -R mysql: /var/lib/mysql # service packetfence-mariadb start -Should the service fail to start, make sure you look into the MariaDB error logs. +Should the service fail to start, make sure you look into the MariaDB logs. [appendix] === How to restore a standalone PacketFence server ? diff --git a/docs/installation/best_practices.asciidoc b/docs/installation/best_practices.asciidoc index b46a7bc24305..46b0e345e555 100644 --- a/docs/installation/best_practices.asciidoc +++ b/docs/installation/best_practices.asciidoc @@ -24,7 +24,7 @@ IPTables is now entirely managed by PacketFence. However, if you need to perform === Log Rotations -PacketFence can generate a lot of log entries in huge production environments. This is why we recommend to use `logrotate` to periodically rotate your logs. A working logrotate script is provided with the PacketFence package. This script is located under the `/usr/local/pf/packetfence.logrotate` file, and it's configured to do a daily log rotation and keeping old logs with compression. It has been added during PacketFence initial installation. +PacketFence can generate a lot of log entries in huge production environments. This is why we recommend to use `logrotate` to periodically rotate your logs. A working logrotate script is provided with the PacketFence package. This script is located inside logrotate directory, and it's configured to do a daily log rotation and keeping old logs with compression. It has been added during PacketFence initial installation. === Large Registration Network diff --git a/docs/installation/troubleshooting_packetfence.asciidoc b/docs/installation/troubleshooting_packetfence.asciidoc index 876358369a12..9965edb706d0 100644 --- a/docs/installation/troubleshooting_packetfence.asciidoc +++ b/docs/installation/troubleshooting_packetfence.asciidoc @@ -24,20 +24,9 @@ PacketFence provides a RADIUS auditing module which allows you to be aware of al === Log files -Here are the most important PacketFence log files: - -[options="compact"] -* `/usr/local/pf/logs/packetfence.log` — PacketFence Core Log -* `/usr/local/pf/logs/httpd.portal.access` — Apache – Captive Portal Access Log -* `/usr/local/pf/logs/httpd.portal.error` — Apache – Captive Portal Error Log -* `/usr/local/pf/logs/httpd.admin.access` — Apache – Web Admin/Services Access Log -* `/usr/local/pf/logs/httpd.admin.error` — Apache – Web Admin/Services Error Log -* `/usr/local/pf/logs/httpd.webservices.access` — Apache – Webservices Access Log -* `/usr/local/pf/logs/httpd.webservices.error` — Apache – Webservices Error Log -* `/usr/local/pf/logs/httpd.aaa.access` — Apache – AAA Access Log -* `/usr/local/pf/logs/httpd.aaa.error` — Apache – AAA Error Log - -There are other log files in [filename]`/usr/local/pf/logs/` that could be relevant depending on what issue you are experiencing. Make sure you take a look at them. +Log files are located under [filename]`/usr/local/pf/logs`. Except +[filename]`packetfence.log` which contains logs from different services, each +service has its own log file. You can see full list of log files available when using _Audit -> Live logs_ menu in web admin. The main logging configuration file is [filename]`/usr/local/pf/conf/log.conf`. It contains the configuration for the `packetfence.log` file (`Log::Log4Perl`) and you normally don't need to modify it. The logging configuration files for every service are located under [filename]`/usr/local/pf/conf/log.conf.d/`.