mirror of
https://github.com/stylersnico/librenms.git
synced 2026-07-27 08:02:51 +02:00
Fixed some typos and formatting issues in docs
This commit is contained in:
@@ -399,8 +399,8 @@ $config['alert']['transports']['clickatell']['to'][] = '+1234567892';
|
||||
|
||||
## <a name="transports-playsms">PlaySMS</a>
|
||||
|
||||
PlaySMS is an OpenSource SMS-Gateway that can be used via their HTTP-API using a Username and WebService-Token.
|
||||
Please consult PlaySMS's documentation regarding number formating.
|
||||
PlaySMS is an open source SMS-Gateway that can be used via their HTTP-API using a Username and WebService-Token.
|
||||
Please consult PlaySMS's documentation regarding number formatting.
|
||||
Here an example using 3 numbers, any amount of numbers is supported:
|
||||
|
||||
~~
|
||||
@@ -529,7 +529,7 @@ And in the Rule:
|
||||
This Example-macro is a Boolean-macro, it applies a form of filter to the set of results defined by the rule.
|
||||
All macros that are not unary should return Boolean.
|
||||
|
||||
You can only apply _Equal_ or _Not-Equal_ Operations on Bollean-macros where `True` is represented by `"1"` and `False` by `"0"`.
|
||||
You can only apply _Equal_ or _Not-Equal_ Operations on Boolean-macros where `True` is represented by `"1"` and `False` by `"0"`.
|
||||
|
||||
|
||||
## <a name="macros-device">Device</a> (Boolean)
|
||||
|
||||
@@ -67,7 +67,7 @@ Config option: `ldap`
|
||||
|
||||
This one is a little more complicated :)
|
||||
|
||||
First of all, install ___php-ldap___ forCentOS/RHEL or ___php5-ldap___ for Ubuntu/Debian.
|
||||
First of all, install ___php-ldap___ for CentOS/RHEL or ___php5-ldap___ for Ubuntu/Debian.
|
||||
|
||||
```php
|
||||
$config['auth_ldap_version'] = 3; # v2 or v3
|
||||
|
||||
@@ -3,19 +3,19 @@ LibreNMS has the ability to distribute polling of devices to other machines.
|
||||
|
||||
These machines can be in a different physical location and therefore minimize network latencies for colocations.
|
||||
|
||||
Devices can also be groupped together into a `poller_group` to pin these devices to a single or a group of designated pollers.
|
||||
Devices can also be grouped together into a `poller_group` to pin these devices to a single or a group of designated pollers.
|
||||
|
||||
~~All pollers need to share their RRD-folder, for example via NFS or a combination of NFS and rrdcached.~~
|
||||
|
||||
> This is no longer a strict requirement with the use of rrdtool 1.5 and above. If you are NOT running 1.5 then you will still
|
||||
need to share the RRD-folder.
|
||||
|
||||
It is also required that all pollers can access the central memcached to communicate with eachother.
|
||||
It is also required that all pollers can access the central memcached to communicate with each other.
|
||||
|
||||
In order to enable distributed polling, set `$config['distributed_poller'] = true` and your memcached details into `$config['distributed_poller_memcached_host']` and `$config['distributed_poller_memcached_port']`.
|
||||
By default, all hosts are shared and have the `poller_group = 0`. To pin a device to a poller, set it to a value greater than 0 and set the same value in the poller's config with `$config['distributed_poller_group']`.
|
||||
Usually the poller's name is equal to the machine's hostname, if you want to change it set `$config['distributed_poller_name']`.
|
||||
One can also specify a comma seperated string of poller groups in $config['distributed_poller_group']. The poller will then poll devices from any of the groups listed. If new devices get added from the poller they will be assigned to the first poller group in the list unless the group is specified when adding the device.
|
||||
One can also specify a comma separated string of poller groups in $config['distributed_poller_group']. The poller will then poll devices from any of the groups listed. If new devices get added from the poller they will be assigned to the first poller group in the list unless the group is specified when adding the device.
|
||||
|
||||
## Configuration
|
||||
```php
|
||||
@@ -28,8 +28,7 @@ $config['distributed_poller_memcached_port'] = '11211';
|
||||
```
|
||||
|
||||
## Example Setup
|
||||
Below is an example setup based on a real deployment which at the time of writing covers over 2,500 devices and 50,000 ports. The setup is running within an Openstack environment with some commodity ha
|
||||
rdware for remote pollers. Here's a diagram of how you can scale LibreNMS out:
|
||||
Below is an example setup based on a real deployment which at the time of writing covers over 2,500 devices and 50,000 ports. The setup is running within an OpenStack environment with some commodity hardware for remote pollers. Here's a diagram of how you can scale LibreNMS out:
|
||||
|
||||

|
||||
|
||||
@@ -53,7 +52,7 @@ The pollers, web and API layers should all be able to access the database server
|
||||
####RRD Storage
|
||||
Central storage should be provided so all RRD files can be read from and written to in one location. As suggested above, it's recommended that RRD Cached is configured and used.
|
||||
|
||||
For this example, we are running RRDCached to allow all pollers and web/api servers to read/write to the rrd iles ~~with the rrd directory also exported by NFS for simple access and maintenance.~~
|
||||
For this example, we are running RRDCached to allow all pollers and web/api servers to read/write to the rrd files ~~with the rrd directory also exported by NFS for simple access and maintenance.~~
|
||||
|
||||
Sharing rrd files via something like NFS is no longer required if you run rrdtool 1.5 or greater. If you don't - please share your rrd folder as before. If you run rrdtool
|
||||
1.5 or greater then add this config to your pollers:
|
||||
@@ -81,7 +80,7 @@ Another benefit to this is that you can provide N+x pollers, i.e if you know tha
|
||||
It is extremely advisable to either run a central recursive dns server such as pdns-recursor and have all of your pollers use this or install a recursive dns server on each poller - the volume of DNS requests on large installs can be significant.
|
||||
|
||||
####Discovery
|
||||
It's not necessary to run discovery services on all pollers. In fact, you should only run one discovery process per poller group. Designate a single poller to run discovery (or a seperate server if required).
|
||||
It's not necessary to run discovery services on all pollers. In fact, you should only run one discovery process per poller group. Designate a single poller to run discovery (or a separate server if required).
|
||||
|
||||
####Config sample
|
||||
Memcache:
|
||||
|
||||
@@ -51,7 +51,7 @@ Attribute | Type | Description
|
||||
`$this->external` | `Array` | Contains loaded extra `commands`.
|
||||
`$this->nick` | `String` | Bot's `nick` on the IRC.
|
||||
`$this->pass` | `String` | IRC-Server's passphrase.
|
||||
`$this->port` | `Int` | IRC-Sever's port-number.
|
||||
`$this->port` | `Int` | IRC-Server's port-number.
|
||||
`$this->server` | `String` | IRC-Server's hostname.
|
||||
`$this->ssl` | `Boolean` | SSL-Flag.
|
||||
`$this->tick` | `Int` | Interval to check buffers in microseconds.
|
||||
|
||||
@@ -48,7 +48,7 @@ Command | Description
|
||||
`.port <hostname> <ifname>` | Prints Port-related information from `ifname` on given `hostname`.
|
||||
`.quit` | Disconnect from IRC and exit.
|
||||
`.reload` | Reload configuration.
|
||||
`.status <type>` | Prints status informations for given `type`. Type can be `devices`, `services`, `ports`. Shorthands are: `dev`,`srv`,`prt`
|
||||
`.status <type>` | Prints status information for given `type`. Type can be `devices`, `services`, `ports`. Shorthands are: `dev`,`srv`,`prt`
|
||||
`.version` | Prints `$this->config['project_name_version']`.
|
||||
|
||||
( __/!\__ All commands are case-_insensitive_ but their arguments are case-_sensitive_)
|
||||
|
||||
@@ -11,7 +11,7 @@ $config['memcached']['port'] = 11211;
|
||||
```
|
||||
|
||||
By default values are kept for 4 Minutes inside the memcached, you can adjust this retention time by modifying the `$config['memcached']['ttl']` value to any desired amount of seconds.
|
||||
It's strongly discouraged to set this above `300` (5 Minutes) to avoid interferences with the polling, discovery and alerting processes.
|
||||
It's strongly discouraged to set this above `300` (5 Minutes) to avoid interference with the polling, discovery and alerting processes.
|
||||
|
||||
If you use the Distributed Poller, you can point this to the same memcached instance. However a local memcached will perform better in any case.
|
||||
|
||||
|
||||
@@ -16,7 +16,7 @@ Either remove mac or xdp depending on which you want.
|
||||
A global map will be drawn from the information in the database, it is worth noting that this could lead to a large network map.
|
||||
Network maps for individual devices are available showing the relationship with other devices.
|
||||
|
||||
One can also specicify the parameters to be used for drawing and updating the network map.
|
||||
One can also specify the parameters to be used for drawing and updating the network map.
|
||||
Please see http://visjs.org/docs/network/ for details on the configuration parameters.
|
||||
```php
|
||||
$config['network_map_vis_options'] = '{
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
|
||||
This documentation will hopefully give you a basis for how to write a plugin for LibreNMS.
|
||||
|
||||
A test plugin is available on GitHib: https://github.com/laf/Test
|
||||
A test plugin is available on GitHub: https://github.com/laf/Test
|
||||
|
||||
Plugins need to be installed into html/plugins
|
||||
|
||||
@@ -45,7 +45,7 @@ PluginName.inc.php - This file is the main included file when browsing to the pl
|
||||
|
||||
### System Hooks ###
|
||||
|
||||
System hooks are called as functions within your plugin class, so for example to create a menu entry within the PLugin dropdown you would do:
|
||||
System hooks are called as functions within your plugin class, so for example to create a menu entry within the Plugin dropdown you would do:
|
||||
|
||||
```
|
||||
public function menu() {
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# Configuring interface descriptions for parsing.
|
||||
|
||||
LibreNMS includes the ability to parse your interface descriptions for set information to diplay and segment in the WebUI.
|
||||
LibreNMS includes the ability to parse your interface descriptions for set information to display and segment in the WebUI.
|
||||
|
||||
The following information is used from interface descriptions:
|
||||
|
||||
@@ -57,7 +57,7 @@ description Cust: Customer A (This customer is gold)
|
||||
[]
|
||||
|
||||
i.e:
|
||||
description Cust: Customer A [100Mbs]
|
||||
description Cust: Customer A [100Mbps]
|
||||
|
||||
You can use any of these additional options like:
|
||||
|
||||
@@ -66,10 +66,10 @@ description Cust: Customer A {ID4321} [1Gbps]
|
||||
|
||||
This information is then held within the ports table within the database, as an example:
|
||||
|
||||
description Core: Nas bond [1Gbps]
|
||||
description Core: NAS bond [1Gbps]
|
||||
```sh
|
||||
port_descr_type: core
|
||||
port_descr_descr: Nas bond
|
||||
port_descr_descr: NAS bond
|
||||
port_descr_circuit: NULL
|
||||
port_descr_speed: 1Gbps
|
||||
port_descr_notes: NULL
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
# Proxmox graphing
|
||||
It is possible to create graphs of the Proxmox **VMs** that run on your monitored machines. Currently, only trafficgraphs are created. One for each interface on each VM. Possibly, IO grahps will be added later on.
|
||||
It is possible to create graphs of the Proxmox **VMs** that run on your monitored machines. Currently, only traffic graphs are created. One for each interface on each VM. Possibly, IO graphs will be added later on.
|
||||
|
||||
The ultimate goal is to be able to create traffic bills for VMs, no matter on which physical machine that VM runs.
|
||||
|
||||
|
||||
@@ -45,7 +45,7 @@ service rrdcached start
|
||||
$config['rrdcached'] = "unix:/var/run/rrdcached/rrdcached.sock";
|
||||
```
|
||||
### RRDCached installation CentOS 7
|
||||
This example is based on a fresh LibreNMS install, on a minimimal CentOS 7.x installation.
|
||||
This example is based on a fresh LibreNMS install, on a minimal CentOS 7.x installation.
|
||||
We'll use the epel-release and setup a RRDCached as a service.
|
||||
It is recommended that you monitor your LibreNMS server with LibreNMS so you can view the disk I/O usage delta.
|
||||
See [Installation (RHEL CentOS)][1] for localhost monitoring.
|
||||
|
||||
@@ -9,7 +9,7 @@ To enable this you can do so in three ways!
|
||||
- For the actual device, Edit Device -> Misc
|
||||
- For each port, Edit Device -> Port Settings
|
||||
|
||||
Now when a port interface speed changes (this can happen because of a physical change or just because the device has mis-reported) the max value is set. If you don't want to wait until
|
||||
Now when a port interface speed changes (this can happen because of a physical change or just because the device has misreported) the max value is set. If you don't want to wait until
|
||||
a port speed changes then you can run the included script:
|
||||
|
||||
script/tune_port.php -h <hostname> -p <ifName>
|
||||
|
||||
@@ -28,14 +28,14 @@ The underlying HMAC-SHA1 remains the same for both types, security advantages or
|
||||
Like the name suggests, this type uses the current Time or a subset of it to generate the passcodes.
|
||||
These passcodes solely rely on the secrecy of their Secretkey in order to provide passcodes.
|
||||
An attacker only needs to guess that Secretkey and the other variable part is any given time, presumably the time upon login.
|
||||
RFC4226 suggests a resynchronization attempt in case the passcode mismatches, providing the attacker a range of upto +/- 3 Minutes to create passcodes.
|
||||
RFC4226 suggests a resynchronization attempt in case the passcode mismatches, providing the attacker a range of up to +/- 3 Minutes to create passcodes.
|
||||
|
||||
|
||||
## <a name="hotp">Counterbased One-Time-Password (TOTP)</a>
|
||||
|
||||
This type uses an internal counter that needs to be in sync with the server's counter to successfully authenticate the passcodes.
|
||||
The main advantage over timebased OTP is the attacker doesn't only need to know the Secretkey but also the server's Counter in order to create valid passcodes.
|
||||
RFC4226 suggests a resynchronization attempt in case the passcode mismatches, providing the attacker a range of upto +4 increments from the actual counter to create passcodes.
|
||||
RFC4226 suggests a resynchronization attempt in case the passcode mismatches, providing the attacker a range of up to +4 increments from the actual counter to create passcodes.
|
||||
|
||||
# <a name="config">Configuration</a>
|
||||
|
||||
|
||||
@@ -209,7 +209,7 @@ sub vcl_backend_response {
|
||||
# that match the file extensions that are between the quotes, and cache the files for 24 hours.
|
||||
# This assumes you update LibreNMS once a day, otherwise restart Varnish to clear cache.
|
||||
# Second function 'if (bereq.url ~ "^/' removes the Pragma no-cache statements and sets the age
|
||||
# of how long the client brower will cache the matching urls.
|
||||
# of how long the client browser will cache the matching urls.
|
||||
# LibreNMS graphs are updated every 300 seconds, 'max-age=300' is set to match this behavior.
|
||||
# We could cache these URLs in Varnish but it would add to the complexity of the config.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user