oxidized 0.32.1 → 0.33.0

data/docs/Configuration.md

@@ -2,9 +2,15 @@
 
 ## Debugging
 
-In case a model plugin doesn't work correctly (ios, procurve, etc.), you can enable live debugging of SSH/Telnet sessions. Just add a `debug` option containing the value true to the `input` section. The log files will be created depending on the parent directory of the logfile option.
+In case a model plugin doesn't work correctly (ios, procurve, etc.), you can
+enable live debugging of SSH/Telnet sessions. Just add a `debug` option
+containing the value true to the `input` section. The log files will be created
+depending on the parent directory of the logfile option.
 
-The following example will log an active ssh/telnet session `/home/oxidized/.config/oxidized/log/<IP-Address>-<PROTOCOL>`. The file will be truncated on each consecutive ssh/telnet session, so you need to put a `tailf` or `tail -f` on that file!
+The following example will log an active ssh/telnet session
+`/home/oxidized/.config/oxidized/log/<IP-Address>-<PROTOCOL>`. The file will be
+truncated on each consecutive ssh/telnet session, so you need to put a `tailf`
+or `tail -f` on that file!
 
 ```yaml
 log: /home/oxidized/.config/oxidized/log
@@ -22,7 +28,9 @@ input:
 
 ## Privileged mode
 
-To start privileged mode before pulling the configuration, Oxidized needs to send the enable command. You can globally enable this, by adding the following snippet to the global section of the configuration file.
+To start privileged mode before pulling the configuration, Oxidized needs to
+send the enable command. You can globally enable this, by adding the following
+snippet to the global section of the configuration file.
 
 ```yaml
 vars:
@@ -31,14 +39,17 @@ vars:
 
 ## Removing secrets
 
-To strip out secrets from configurations before storing them, Oxidized needs the `remove_secret` flag. You can globally enable this by adding the following snippet to the global section of the configuration file.
+To strip out secrets from configurations before storing them, Oxidized needs the
+`remove_secret` flag. You can globally enable this by adding the following
+snippet to the global section of the configuration file.
 
 ```yaml
 vars:
   remove_secret: true
 ```
 
-Device models that contain substitution filters to remove sensitive data will now be run on any fetched configuration.
+Device models that contain substitution filters to remove sensitive data will
+now be run on any fetched configuration.
 
 As a partial example from ios.rb:
 
@@ -56,7 +67,9 @@ The above strips out snmp community strings from your saved configs.
 
 ## Disabling SSH exec channels
 
-Oxidized uses exec channels to make information extraction simpler, but there are some situations where this doesn't work well, e.g. configuring devices. This feature can be turned off by setting the `ssh_no_exec`
+Oxidized uses exec channels to make information extraction simpler, but there
+are some situations where this doesn't work well, e.g. configuring devices. This
+feature can be turned off by setting the `ssh_no_exec`
 variable.
 
 ```yaml
@@ -66,7 +79,11 @@ vars:
 
 ## Disabling SSH keepalives
 
-Oxidized SSH input makes use of SSH keepalives to prevent timeouts from slower devices and to quickly tear down stale sessions in larger deployments. There have been reports of SSH keepalives breaking compatibility with certain OS types. They can be disabled using the `ssh_no_keepalive` variable on a per-node basis (by specifying it in the source) or configured application-wide.
+Oxidized SSH input makes use of SSH keepalives to prevent timeouts from slower
+devices and to quickly tear down stale sessions in larger deployments. There
+have been reports of SSH keepalives breaking compatibility with certain OS
+types. They can be disabled using the `ssh_no_keepalive` variable on a per-node
+basis (by specifying it in the source) or configured application-wide.
 
 ```yaml
 vars:
@@ -84,9 +101,12 @@ vars:
 
 ## Public Key Authentication with SSH
 
-Instead of password-based login, Oxidized can make use of key-based SSH authentication.
+Instead of password-based login, Oxidized can make use of key-based SSH
+authentication.
 
-You can tell Oxidized to use one or more private keys globally, or specify the key to be used on a per-node basis. The latter can be done by mapping the `ssh_keys` variable through the active source.
+You can tell Oxidized to use one or more private keys globally, or specify the
+key to be used on a per-node basis. The latter can be done by mapping the
+`ssh_keys` variable through the active source.
 
 Global:
 
@@ -108,7 +128,8 @@ vars_map:
 # ...
 ```
 
-If you are using a non-standard path, especially when copying the private key via a secured channel, make sure that the permissions are set correctly:
+If you are using a non-standard path, especially when copying the private key
+via a secured channel, make sure that the permissions are set correctly:
 
 ```bash
 foo@bar:~$ ls -la ~/.ssh/
@@ -120,15 +141,20 @@ drwx------ 5 oxidized oxidized 4096 Mar 13 21:40 ..
 -rw-r--r-- 1 oxidized oxidized   94 Mar 13 17:02 id_ed25519.pub
 ```
 
-Finally, multiple private keys can be specified as an array of file paths, such as `["~/.ssh/id_rsa", "~/.ssh/id_another_rsa"]`.
+Finally, multiple private keys can be specified as an array of file paths, such
+as `["~/.ssh/id_rsa", "~/.ssh/id_another_rsa"]`.
 
 ## SSH Proxy Command
 
-Oxidized can `ssh` through a proxy as well. To do so we just need to set `ssh_proxy` variable with the proxy host information and optionally set the `ssh_proxy_port` with the SSH port if it is not listening on port 22.
+Oxidized can `ssh` through a proxy as well. To do so we just need to set
+`ssh_proxy` variable with the proxy host information and optionally set the
+`ssh_proxy_port` with the SSH port if it is not listening on port 22.
 
-This can be provided on a per-node basis by mapping the proper fields from your source.
+This can be provided on a per-node basis by mapping the proper fields from your
+source.
 
-An example for a `csv` input source that maps the 4th field as the `ssh_proxy` value and the 5th field as `ssh_proxy_port`.
+An example for a `csv` input source that maps the 4th field as the `ssh_proxy`
+value and the 5th field as `ssh_proxy_port`.
 
 ```yaml
 # ...
@@ -144,9 +170,12 @@ vars_map:
 
 ## SSH enabling legacy algorithms
 
-When connecting to older firmware over SSH, it is sometimes necessary to enable legacy/disabled settings like KexAlgorithms, HostKeyAlgorithms, MAC or the Encryption.
+When connecting to older firmware over SSH, it is sometimes necessary to enable
+legacy/disabled settings like KexAlgorithms, HostKeyAlgorithms, MAC or the
+Encryption.
 
-These settings can be provided on a per-node basis by mapping the ssh_kex, ssh_host_key, ssh_hmac and the ssh_encryption fields from you source.
+These settings can be provided on a per-node basis by mapping the ssh_kex,
+ssh_host_key, ssh_hmac and the ssh_encryption fields from you source.
 
 ```yaml
 # ...
@@ -164,7 +193,9 @@ vars_map:
 
 ## FTP Passive Mode
 
-Oxidized uses ftp passive mode by default. Some devices require passive mode to be disabled. To do so, we can set `input.ftp.passive` to false - this will make use of FTP active mode.
+Oxidized uses ftp passive mode by default. Some devices require passive mode to
+be disabled. To do so, we can set `input.ftp.passive` to false - this will make
+use of FTP active mode.
 
 ```yaml
 input:
@@ -207,7 +238,21 @@ crash:
 vars:
   enable: S3cr3tx
 groups: {}
-rest: 127.0.0.1:8888
+extensions:
+  oxidized-web:
+    load: true
+    # Bind to any IPv4 interface
+    listen: 0.0.0.0
+    # Bind to port 8888 (default)
+    port: 8888
+    # Prefix prod to the URL, so http://oxidized.full.domain/prod/
+    url_prefix: prod
+    # virtual hosts to listen to (others will be denied)
+    vhosts:
+      - localhost
+      - 127.0.0.1
+      - oxidized
+      - oxidized.full.domain
 pid: ~/.config/oxidized/oxidized.pid
 input:
   default: ssh, telnet
@@ -337,35 +382,99 @@ From least to most important:
 
 More important options overwrite less important ones if they are set.
 
-## RESTful API and Web Interface
+## oxidized-web: RESTful API and web interface
+
+The RESTful API and web interface are enabled by installing the `oxidized-web`
+gem and configuring the `extensions.oxidized-web:` section in the configuration
+file. You can set the following parameter:
+- `load`: `true`/`false`: Enables or disables the `oxidized-web` extension
+  (default: `false`)
+- `listen`: Specifies the interface to bind to (default: `127.0.0.1`). Valid
+  options:
+  - `127.0.0.1`: Allows IPv4 connections from localhost only
+  - `'[::1]'`: Allows IPv6 connections from localhost only
+  - `<IPv4-Address>` or `'[<IPv6-Address>]'`: Binds to a specific interface
+  - `0.0.0.0`: Binds to any IPv4 interface
+  - `'[::]'`:  Binds to any IPv4 and IPv6 interface
+- `port`: Specifies the TCP port to listen to (default: `8888`)
+- `url_prefix`: Defines a URL prefix (default: no prefix)
+- `vhosts`: A list of virtual hosts to listen to. If not specified, it will
+  respond to any virtual host.
+
+> [!NOTE]
+> The old syntax `rest: 127.0.0.1:8888/prefix` is still supported but
+> deprecated. It produces a warning and won't be suported in future releases.
+>
+> If the `rest` configuration is used, the extensions.oxidized-web will be
+> ignored.
+
+> [!NOTE]
+> You need oxidized-web version 0.16.0 or later to use the
+> extentions.oxidized-web configuration
 
-The RESTful API and Web Interface is enabled by configuring the `rest:` parameter in the config file.  This parameter can optionally contain a relative URI.
 
 ```yaml
 # Listen on http://[::1]:8888/
-rest: "[::1]:8888"
+extensions:
+  oxidized-web:
+    load: true
+    listen: '[::1]'
+    port: 8888
 ```
 
 ```yaml
 # Listen on http://127.0.0.1:8888/
-rest: 127.0.0.1:8888
+extensions:
+  oxidized-web:
+    load: true
+    listen: 127.0.0.1
+    port: 8888
 ```
 
 ```yaml
 # Listen on http://[2001:db8:0:face:b001:0:dead:beaf]:8888/oxidized/
-rest: "[2001:db8:0:face:b001:0:dead:beaf]:8888"
+extensions:
+  oxidized-web:
+    load: true
+    listen: '[2001:db8:0:face:b001:0:dead:beaf]'
+    port: 8888
+    url_prefix: oxidized
 ```
 
 ```yaml
 # Listen on http://10.0.0.1:8000/oxidized/
-rest: 10.0.0.1:8000/oxidized
+extensions:
+  oxidized-web:
+    load: true
+    listen: 10.0.0.1
+    port: 8000
+    url_prefix: oxidized
+```
+
+```yaml
+# Listen on any interface to http://oxidized.rocks:8888 and
+# http://oxidized:8888
+extensions:
+  oxidized-web:
+    load: true
+    listen: '[::]'
+    url_prefix: oxidized
+    vhosts:
+     - oxidized.rocks
+     - oxidized
 ```
 
 ## Triggered backups
 
-A node can be moved to head-of-queue via the REST API `GET/POST /node/next/[NODE]`. This can be useful to immediately schedule a fetch of the configuration after some other event such as a syslog message indicating a configuration update on the device.
+A node can be moved to head-of-queue via the REST API `GET/PUT
+/node/next/[NODE]`. This can be useful to immediately schedule a fetch of the
+configuration after some other event such as a syslog message indicating a
+configuration update on the device.
 
-In the default configuration this node will be processed when the next job worker becomes available, it could take some time if existing backups are in progress. To execute moved jobs immediately a new job can be added automatically:
+In the default configuration this node will be processed when the next job
+worker becomes available, it could take some time if existing backups are in
+progress. To execute moved jobs immediately a new job can be added
+automatically:
 
 ```yaml
 next_adds_job: true
@@ -375,7 +484,10 @@ This will allow for a more timely fetch of the device configuration.
 
 ## Disabling DNS resolution
 
-In some instances it might not be desirable to attempt to resolve names of nodes. One such use case is when nodes are accessed through an SSH proxy, where the remote end resolves the names differently than the host on which Oxidized runs would.
+In some instances it might not be desirable to attempt to resolve names of
+nodes. One such use case is when nodes are accessed through an SSH proxy, where
+the remote end resolves the names differently than the host on which Oxidized
+runs would.
 
 Names can instead be passed verbatim to the input:
 

data/docs/Docker.md

@@ -0,0 +1,240 @@
+# Running oxidized within an OCI container (docker, podman...)
+
+## Docker image
+The official Docker image is automatically built and pushed to hub.docker.com
+as [oxidized/oxidized](https://hub.docker.com/r/oxidized/oxidized/) with a
+[GitHub CI](/.github/workflows/publishdocker.yml).
+
+There are three different types of tags:
+- Each commit to the master branch will be published with the tag
+  `master-(git sha oid)`
+- Each release will be published with the version as a tag
+- Latest is the latest release, either from a commit or a release tag
+
+Currently, Docker Hub automatically builds the master branch for linux/amd64 and
+linux/arm64 platforms as
+[oxidized/oxidized](https://hub.docker.com/r/oxidized/oxidized/). You can make
+use of this container or build your own.
+
+## Choose a container running environment
+There are many options to run containers. Two main options are
+[docker](https://www.docker.com/) and [podman](https://podman.io/). A main
+difference is that docker requires root rights to run, and podman can be run
+by a local user. Both work with oxidized, so the choice is up to you.
+
+Oxidized has also been reported to work with
+[Portainer](https://www.portainer.io/).
+
+## File rights in the container userspace and host userspace
+As oxidized runs under the user "oxidized" (UID: 30000) in the container
+userspace, docker and podman will map this UID in the shared volumes, producing
+weird UIDs in the host userspace.
+
+### docker
+When docker runs the container as root, the mapping to the UIDs in the host
+userspace will be the same as in the container, so the files produced by the
+oxidized user in the container will have UID 30000 in the host.
+
+If you map a volume between the host and the container and need it to be
+accessed by the oxidized user, you need to fix the UIDs:
+```
+sudo chown 30000:30000 ~/oxidized-config
+```
+
+### podman
+When podman is run as a user, the mapping of UIDs between the container and the
+linux host will depend on your UID on the host.
+
+If you map a volume between the host and the container and need it to be
+accessed by the oxidized user, you need to fix the UIDs:
+
+```
+podman unshare chown 30000:30000 ~/oxidized-config
+```
+
+If you need to access the files from the linux host, you can do this by
+prefixing `podman unshare` to your shell commands.
+
+## Build you own container image
+To build your own container image, clone the git repository:
+
+```shell
+git clone https://github.com/ytti/oxidized
+```
+
+Then, build the container locally:
+
+```shell
+sudo docker build -q -t oxidized/oxidized:latest oxidized/
+```
+
+- `-q` stands for quiet; remove it if you want to see the build process.
+- `-t oxidized/oxidized:latest` tags the image as `oxidized/oxidized:latest`
+
+You can also build with podman:
+```
+podman build -t oxidized:latest oxidized/
+```
+
+Within the oxidized repository, using `rake build_container` will automatically
+build the container (with podman or docker), name it `localhost/oxidized` and
+give it the tags `latest` and `<branchname>-<sha-tag>`, for example
+`localhost/oxidized:master-65baab9`.
+
+## Set up an environment for the container
+Once you've built the container (or chosen to make use of the automatically
+built container in Docker Hub, which will be downloaded for you by docker on the
+first `run` command had you not built it), you need to set up an environment
+for the container.
+
+First, you need a configuration directory in the host system that you can map
+in the container. You can choose any directory you want, we'll take
+`~/oxidized-config` in our example. Don't forget to adjust the permissions as
+explained above.
+
+If you already have a configuration for oxidized (`config`), you can skip this
+step. Just save it under `~/oxidized-config` and run the container (see below).
+
+If you don't have a configuration, you can make oxidized produce one for you, so
+that you just have to adapt it to your needs.
+
+```shell
+sudo docker run --rm -v ~/oxidized-config:/home/oxidized/.config/oxidized docker.io/oxidized/oxidized:latest su - oxidized -c oxidized
+```
+```shell
+podman run --rm -v ~/oxidized-config:/home/oxidized/.config/oxidized docker.io/oxidized/oxidized:latest su - oxidized -c oxidized
+```
+
+- `--rm` tells docker to automatically remove the container when he exits
+- `-v ~/oxidized-config:/home/oxidized/.config/oxidized` maps your local
+  `~/oxidized-config` into `/home/oxidized/.config/oxidized`in the container
+  environment.
+- `su - oxidized -c oxidized` runs oxidized under the user oxidized, so that it
+  can produce a configuration under `/home/oxidized/.config/oxidized`
+
+
+This will return `edit /home/oxidized/.config/oxidized/config`, which is the
+path in the container context. Now you can edit `~/oxidized-config/config` to
+fit your needs.
+
+You can reiterate this process a few times, until oxidized is happy with the
+config, an then you're finished with setting up the environment.
+
+
+You also need to create the `router.db` file under
+`~/oxidized-config/config/router.db` (see
+[CSV Source](/docs/Sources.md#source-csv) for further info) or configure another
+source to suit your needs. Don't forget to set the file permissions (owner)
+properly!
+
+
+
+## Run the container
+Now you can run the container without specifying an entry point. It will
+automatically start oxidized and every other process needed.
+```shell
+sudo docker run --rm -v ~/oxidized-config:/home/oxidized/.config/oxidized -p 8888:8888/tcp docker.io/oxidized/oxidized:latest
+```
+```shell
+podman run --rm -v ~/oxidized-config:/home/oxidized/.config/oxidized -p 8888:8888/tcp docker.io/oxidized/oxidized:latest
+```
+
+`-p 8888:8888/tcp` maps the TCP port 8888 in the container with the port
+8888 on the host, so that you can access the RESTful API and Web Interface
+from the host.
+If the RESTful API and Web Interface should be enabled, edit the
+configuration (in our example `~/oxidized-config/config`) and modify
+`rest: 127.0.0.1:8888` to `rest: 0.0.0.0:8888`. This will bind port 8888 to all
+interfaces, and expose the port so that it can be accessed externally.
+[(Issue #445)](https://github.com/ytti/oxidized/issues/445)
+
+
+## Run with with docker-compose / podman-compose
+Alternatively, you can use docker-compose or podman-compose to run the
+container:
+
+```yaml
+# docker-compose.yml
+# docker-compose file example for oxidized that will start along with docker daemon
+---
+version: "3"
+services:
+  oxidized:
+    restart: always
+    image: docker.io/oxidized/oxidized:latest
+    ports:
+      - 8888:8888/tcp
+    environment:
+      # Reload hosts list once per day
+      CONFIG_RELOAD_INTERVAL: 86400
+    volumes:
+       - ~/oxidized-config/config:/home/oxidized/.config/oxidized/
+```
+
+To start the pod, use `docker-compose up` or `podman-compose down`.
+
+## Special configurations of the official container
+### Reload the configuration
+If you want to have the config automatically reloaded (e.g. when using a http
+source that changes), you need to set the environment variable
+CONFIG_RELOAD_INTERVAL. This can be done in `docker-compose.yml` (see above) or
+on the command line:
+
+```shell
+sudo docker run -v ~/oxidized-config:/home/oxidized/.config/oxidized -p 8888:8888/tcp -e CONFIG_RELOAD_INTERVAL=3600 docker.io/oxidized/oxidized:latest
+```
+### Use an internal CA
+If you need to use an internal CA (e.g. to connect to an private github instance):
+
+```shell
+docker run -v /etc/oxidized:/home/oxidized/.config/oxidized -v /path/to/MY-CA.crt:/usr/local/share/ca-certificates/MY-CA.crt -p 8888:8888/tcp -e UPDATE_CA_CERTIFICATES=true -t oxidized/oxidized:latest
+```
+
+### Pass the ssh passphrase for a remote git
+If you don't want to authenticate with user & password but with a ssh-key, you
+can set the ssh passphrase with the environment variable
+`OXIDIZED_SSH_PASSPHRASE`
+
+## Tipps & tricks
+### podman & Debian Bookworm
+To install podman in Debian Bookwork, you need following packages:
+```shell
+sudo apt install podman containers-storage podman-compose
+```
+
+Ensure Podman is using the overlay driver for image storage.
+Without this driver, Podman may save every container layer separately rather
+than only the changes, which can quickly consume disk space.
+
+This issue can occur if podman was run before installing the
+`container-storage`  package.
+
+```shell
+podman info | grep graphDriverName
+```
+
+You should get this reply
+```shell
+  graphDriverName: overlay
+```
+
+If not, a quick way to solve it is to delete `~/.local/share/containers/`.
+Beware - this will delete **all** your containers!
+
+### Store the ssh keys a remote git repository
+When you user the githubrepo hook to upload your configs to a remote git repository, you have to store your ssh-key and the public keys of the remote server. Create a folder `~/oxidized-ssh` and map it to `/home/oxidized/.ssh`.
+
+
+To generate an ssh-key, run:
+```shell
+ssh-keygen -q -t ed25519 -C "Oxidized Push Key@`hostname`" -N "YOURPASSPHRASE" -m PEM -f ~/oxidized-ssh/oxidized-key
+```
+
+You also need to store the public keys of the remote git server in known_hosts. If you do not,
+oxidized will refuse to push to the remote Git with the error `#<Rugged::SshError: invalid or unknown remote ssh hostkey>`, see Issue #2753.
+
+```shell
+ssh-keyscan git-server.example.com > ~/oxidized-ssh/known_hosts
+```
+
+Don't forget to set the permission (owner) of the files for the user oxidized inside the container!

data/docs/Issues.md

@@ -11,6 +11,23 @@ Why write good issues?
 - By spending time to write a good issue, you save developers time, contributing
   to Oxidized’s progress without writing a line of code.
 
+## Rules
+The project receives too many incomplete issues, unnecessarily taking time that
+could be invested in new code. Therefore, issues will be worked on with the
+following rules:
+
+- Use the predefined templates for bugs, feature requests and support requests.
+- If you don't provide the necessary information (read this file, fill in the
+  questions in the templates), expect your issue to be closed without a comment.
+- Inactive issues will be marked "stale" automatically after 90 days. Issues
+  are not closed automatically; this is a manual action by a maintainer.
+- A feature requests may be closed after some time of inactivity, as obviously
+  no one has found the time to implement it. Consider contributing code in a
+  Pull Request instead.
+- While it is OK to ask for help (using the support request template), don't be
+  disappointed if no one finds the time to answer your question. Stale questions
+  (after 90 days) will be closed without a comment.
+
 ## Submit to the correct project
 Choose the appropriate GitHub project based on your issue:
 

data/docs/Model-Notes/EatonNetwork.md

@@ -0,0 +1,18 @@
+# EatonNetwork Configuration
+
+This model uses the command `save_configuration -p <passphrase>` to get the backup config. The `-p` option is a required passphrase used to encrypted sensitive parts of the config data, the encrypted data is nondeterministic and changes with each run. The passphrase used is the auth password for the node.
+
+See the [Eaton Network-M3 user's guide](https://www.eaton.com/content/dam/eaton/products/backup-power-ups-surge-it-power-distribution/power-management-software-connectivity/eaton-gigabit-network-card/network-m3/resources/eaton-network-m3-user-guide.pdf) section 7.7.14 (page 260) for more information.
+
+To not have the backup change on each for all `eatonnetwork` node run set a model var in the config for the `eatonnetwork` model to [remove secrets](../Configuration.md#removing-secrets):
+
+```yaml
+models:
+  eatonnetwork:
+    vars:
+      remove_secret: true
+```
+
+See the [Eaton Network-M3 user's guide](https://www.eaton.com/content/dam/eaton/products/backup-power-ups-surge-it-power-distribution/power-management-software-connectivity/eaton-gigabit-network-card/network-m3/resources/eaton-network-m3-user-guide.pdf) section 3.20 (page 111) for details on JSON configuration structure, and restoring without sensitive/secrets.
+
+Back to [Model-Notes](README.md)

data/docs/Model-Notes/HPEAruba.md

@@ -26,6 +26,7 @@ is the operating system for the newer CX-Series.
 The Oxidized model is [aoscx](/lib/oxidized/model/aoscx.rb).
 
 ## Older Models
-Older Devices like ProCurve or 3Com/Comware are listed under the Vendor "HP" in
-the [Supported OS Types](docs/Supported-OS-Types.md) list.
+Older Devices like [ProCurve](/lib/oxidized/model/procurve.rb) or 3Com/Comware
+are listed under the Vendor "HP" in the
+[Supported OS Types](/docs/Supported-OS-Types.md) list.
 

data/docs/Release.md

@@ -23,10 +23,12 @@ If you change some code => Restart the release process at the beginning ;-)
 ## Make sure the file permissions are correct
 Run `bundle exec rake chmod`
 
-## Test !
-Test the git code and the container against as much device types and environments as you can.
+## Make sure you pass all GitHub CI
+They test different ruby versions, the docker build process and codeql.
 
-Do not integrate late PRs into master if they do not fix issues for the release. The must wait for the next release.
+## Test !
+Test the git code and the container against as much device types and
+environments as you can.
 
 ## Version numbering
 Oxidized versions are nummered like major.minor.patch

data/docs/Supported-OS-Types.md

@@ -75,6 +75,7 @@
 |                    |Dell EMC Networking OS10      |[os10](/lib/oxidized/model/os10.rb)              |                 |[Dell EMC Networking OS10](Model-Notes/OS10.md)
 |D-Link              |D-Link                        |[dlink](/lib/oxidized/model/dlink.rb)
 |                    |D-Link cisco like CLI         |[dlinknextgen](/lib/oxidized/model/dlinknextgen.rb)
+|Eaton               |Gigabit Network Card          |[eatonnetwork](/lib/oxidized/model/eatonnetwork.rb) |@thanegill
 |ECI Telecom         |ECIapollo                     |[eciapollo](/lib/oxidized/model/eciapollo.rb)
 |EdgeCore            |ECS3510, ES3526XA-V2, ES3528M |[edgecos](/lib/oxidized/model/edgecos.rb)
 |Eltex               |Eltex                         |[eltex](/lib/oxidized/model/eltex.rb)
@@ -113,6 +114,7 @@
 |Huawei              |VRP                           |[vrp](/lib/oxidized/model/vrp.rb)                |                 |[VRP-Huawei](Model-Notes/VRP-Huawei.md)
 |                    |SmartAX series                |[smartax](/lib/oxidized/model/smartax.rb)        |                 |[SmartAX-Huawei](Model-Notes/SmartAX-Huawei.md)
 |Icotera             |6400 series                   |[icotera](/lib/oxidized/model/icotera.rb)
+|Ingate              |SIParator/Firewalls           |[ingate](/lib/oxidized/model/ingate.rb)          |@thanegill
 |IP Infusion         |OcNOS                         |[ocnos](/lib/oxidized/model/ocnos.rb)
 |Juniper             |JunOS                         |[junos](/lib/oxidized/model/junos.rb)            |                 |[MX/QFX/EX/SRX/J Series](Model-Notes/JunOS.md)
 |                    |ScreenOS (Netscreen)          |[screenos](/lib/oxidized/model/screenos.rb)
@@ -169,6 +171,7 @@
 |                    |Edgeos                        |[edgeos](/lib/oxidized/model/edgeos.rb)
 |                    |EdgeSwitch                    |[edgeswitch](/lib/oxidized/model/edgeswitch.rb)
 |                    |AirFiber                      |[airfiber](/lib/oxidized/model/airfiber.rb)
+|                    |UnifiAP                       |[unifiap](/lib/oxidized/model/unifiap.rb)              |@clifcox      |Also suports AirOS, and some Unifi switches
 |Uplink              |EP4440-DP                     |[EP4440](/lib/oxidized/model/uplinkolt.rb)             | |Might support all EP4440 series
 |VMWare              |NSX Edge (configuration)      |[nsxconfig](/lib/oxidized/model/nsxconfig.rb)
 |                    |NSX Edge (firewall rules)     |[nsxfirewall](/lib/oxidized/model/nsxfirewall.rb)

data/docs/Troubleshooting.md

@@ -87,7 +87,8 @@ find an example how to do this under [examples/podman-compose](/examples/podman-
 
 ## Git performance issues with large device counts
 When you use git to store your configurations, the size of your repository will
-grow over time. This growth can lead to performance issues. To resolve these issues, you should perform a Git garbage collection on your repository.
+grow over time. This growth can lead to performance issues. To resolve these
+issues, you should perform a Git garbage collection on your repository.
 
 Follow these steps to do so:
 
@@ -97,6 +98,10 @@ Follow these steps to do so:
 4. Execute the command `git gc` to run the garbage collection
 5. Restart oxidized - you're done!
 
+Note that slow performance in oxidized-web when listing the versions of a device
+are due to the necessity to go through the whole git log to search the
+history. See Issue #3121, the fix will come with oxidized version 0.33.0.
+
 ## Oxidized ignores the changes I made to its git repository
 First of all: you shouldn't manipulate the git repository of oxidized. Don't
 create it, don't modify it, leave it alone. You can break things. You have

data/extra/rest_client.rb

@@ -6,7 +6,7 @@ module Oxidized
     require 'asetus'
 
     class Config
-      Root = ENV['OXIDIZED_HOME'] || File.join(Dir.home, '.config', 'oxidized')
+      ROOT = ENV['OXIDIZED_HOME'] || File.join(Dir.home, '.config', 'oxidized')
     end
 
     CFGS = Asetus.new name: 'oxidized', load: false, key_to_s: true