docs: update related to logs

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

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.
 

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
 

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 ?

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
 

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/`.