oxidized 0.32.1 → 0.34.0

data/docs/Docker.md

@@ -0,0 +1,245 @@
+# 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 use 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 directory `~/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 don't store the keys, 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, or this will not work!

data/docs/Issues.md

@@ -7,10 +7,28 @@ This guide provides tips on writing your issue to make it easier for the
 community and developers to understand and respond effectively.
 
 Why write good issues?
-- A clear and detailed issue improves the chances of getting your problem resolved.
+- A clear and detailed issue improves the chances of getting your problem
+  resolved.
 - 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 request 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:
 
@@ -24,6 +42,13 @@ Choose the appropriate GitHub project based on your issue:
 - For issues with Oxidized itself, go to
   [oxidized](https://github.com/ytti/oxidized).
 
+## Use the latest version
+If you are using an old version of oxidized, you may encounter issues that have
+been solved. No support will be provided for older versions of oxidized.
+
+If you can, please also test against the latest git version, or at least read
+[CHANGELOG.md](/CHANGELOG.md) to see if your problem has been solved on master.
+
 ## Format your issue
 - Use [GitHub Markdown](https://docs.github.com/en/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax) to format your issue.
 - Preview your text before submitting to ensure it renders correctly.
@@ -36,6 +61,7 @@ Keep the title brief yet descriptive. Aim to summarize the main issue or request
 Include as many relevant details as possible. At a minimum, specify:
 
 - Oxidized version and operating system.
+- Which model (oxidized name AND Manufacturer name) is the issue about.
 - Relevant parts of your Oxidized configuration and a brief explanation of your setup.
 - Output of the error, if relevant.
 - For issues related to specific devices, consider creating a YAML Simulation file (instructions below).

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/ModelUnitTests.md

@@ -21,7 +21,7 @@ See the link for instructions on how to produce it.
 
 The YAML simulation files are stored under
 [/spec/model/data/](/spec/model/data/), with the naming convention
-`<model>:<description>:simulation.yaml`, where `<model>` is the lowercase name
+`<model>#<description>#simulation.yaml`, where `<model>` is the lowercase name
 of the Oxidized model and `<description>` is the name of the test case.
 `<description>` is generally formatted as `<hardware>_<software>` or
 `<hardware>_<software>_<information>`.
@@ -31,17 +31,17 @@ automatic model unit tests.
 
 ### Expected Output
 You need a second file that contains the expected output, which has the same
-name as the YAML simulation file but ends with `:output.txt` instead of
-`:simulation.yaml`.
+name as the YAML simulation file but ends with `#output.txt` instead of
+`#simulation.yaml`.
 
 You can automatically produce an output file based on the current model for all
-YAML simulation files missing an `:output.txt`:
+YAML simulation files missing an `#output.txt`:
 ```shell
 bundle exec ruby spec/model/atoms_generate.rb
 ```
 
 In the following example,
-`spec/model/data/aoscx:R8N85A-C6000-48G-CL4_PL.10.08.1010:output.txt` (the
+`spec/model/data/aoscx#R8N85A-C6000-48G-CL4_PL.10.08.1010#output.txt` (the
 second file in the list) was missing:
 
 ```shell
@@ -50,21 +50,21 @@ Run options: --seed 57811
 
 # Running:
 
-Generating output file for aoscx:R0X25A-6410_FL.10.10.1100:simulation... SKIP, output already exists
-Generating output file for aoscx:R8N85A-C6000-48G-CL4_PL.10.08.1010:simulation... OK
-Generating output file for arubainstant:IAP515_8.10.0.6_VWLC:simulation... SKIP, output already exists
-Generating output file for asa:5512_9.12-4-67_single-context:simulation... SKIP, output already exists
-Generating output file for garderos:R7709_003_006_068:simulation... SKIP, output already exists
-Generating output file for ios:C8200L_16.12.1:simulation... FAIL, no simulation file
-Generating output file for ios:C9200L-24P-4G_17.09.04a:simulation... SKIP, output already exists
-Generating output file for ios:C9800-L-F-K9_17.06.05:simulation... SKIP, output already exists
-Generating output file for ios:asr920_16.8.1b:simulation... SKIP, output already exists
-Generating output file for junos:srx300_22.4:simulation... SKIP, output already exists
-Generating output file for opnsense:nano_23.7:simulation... SKIP, output already exists
-Generating output file for pfsense:CE_2.7.2:simulation... SKIP, output already exists
-Generating output file for routeros:CHR_7.10.1:simulation... SKIP, output already exists
-Generating output file for routeros:CHR_7.16:simulation... SKIP, output already exists
-Generating output file for routeros:L009UiGS_7.15.2:simulation... SKIP, output already exists
+Generating output file for aoscx#R0X25A-6410_FL.10.10.1100#simulation... SKIP, output already exists
+Generating output file for aoscx#R8N85A-C6000-48G-CL4_PL.10.08.1010#simulation... OK
+Generating output file for arubainstant#IAP515_8.10.0.6_VWLC#simulation... SKIP, output already exists
+Generating output file for asa#5512_9.12-4-67_single-context#simulation... SKIP, output already exists
+Generating output file for garderos#R7709_003_006_068#simulation... SKIP, output already exists
+Generating output file for ios#C8200L_16.12.1#simulation... FAIL, no simulation file
+Generating output file for ios#C9200L-24P-4G_17.09.04a#simulation... SKIP, output already exists
+Generating output file for ios#C9800-L-F-K9_17.06.05#simulation... SKIP, output already exists
+Generating output file for ios#asr920_16.8.1b#simulation... SKIP, output already exists
+Generating output file for junos#srx300_22.4#simulation... SKIP, output already exists
+Generating output file for opnsense#nano_23.7#simulation... SKIP, output already exists
+Generating output file for pfsense#CE_2.7.2#simulation... SKIP, output already exists
+Generating output file for routeros#CHR_7.10.1#simulation... SKIP, output already exists
+Generating output file for routeros#CHR_7.16#simulation... SKIP, output already exists
+Generating output file for routeros#L009UiGS_7.15.2#simulation... SKIP, output already exists
 .
 
 Finished in 0.904792s, 1.1052 runs/s, 0.0000 assertions/s.
@@ -76,7 +76,7 @@ Line Coverage: 58.02% (651 / 1122)
 ```
 
 ### Running the Tests
-You can modify the `:output.txt` file to match your expectations and modify the
+You can modify the `#output.txt` file to match your expectations and modify the
 model accordingly. Run `bundle exec rake` to run the tests.
 
 Here is an example when the output of the VTP command is missing in the expected
@@ -94,7 +94,7 @@ Run options: --seed 31447
 Finished in 7.963602s, 14.6918 runs/s, 48.7217 assertions/s.
 
   1) Failure:
-ATOMS tests#test_0006_ios:C9200L-24P-4G_17.09.04a:output has expected output [spec/model/model_atoms_spec.rb:12]:
+ATOMS tests#test_0006_ios#C9200L-24P-4G_17.09.04a#output has expected output [spec/model/model_atoms_spec.rb:12]:
 --- expected
 +++ actual
 @@ -9,6 +9,21 @@
@@ -138,9 +138,19 @@ If you want to be sure that your model has been tested, run
 `bundle exec rake test TESTOPTS="--verbose"` and search for your models unter
 `ATOMS tests`
 
+### Running only one test
+If you want to run only one test while debuging your model, you can select it
+with the option `--name=/regexp/`:
+```
+bundle exec rake test TESTOPTS="--verbose --name=/ios#C9800.*output/"
+```
+
+You can also set `Oxidized.asetus.cfg.debug = true` in
+`spec/model/model_helper.rb` to activate debug logs.
+
 ## Device Prompt
 You can specify device prompts to test in a YAML file named
-`spec/model/data/<model>:generic:prompt.yaml`.
+`spec/model/data/<model>#generic#prompt.yaml`.
 
 The YAML file has three sections containing a list of prompts to test:
 - pass: these prompts will pass the prompt regexp.
@@ -162,7 +172,7 @@ fail:
 ## Secrets
 You can test if the model effectively removes secrets from your YAML simulation
 file with a YAML file named like the YAML simulation, but with the suffix
-`:secret.yaml`.
+`#secret.yaml`.
 
 The YAML file has two sections containing a list of strings to test:
 - fail: the test will fail if the output contains these strings.
@@ -180,7 +190,7 @@ pass:
 ## Custom tests
 When you write custom tests for your models, please do not use the filenames
 mentioned above, as it will interfere with the standard tests. If you need to
-store a custom simulation file, use `model:description:custom_simulation.yaml`.
+store a custom simulation file, use `model#description#custom_simulation.yaml`.
 
 The [cumulus test](/spec/model/cumulus_spec.rb) is an example of a custom
 test.

data/docs/Outputs.md

@@ -10,9 +10,48 @@ output:
     directory: /var/lib/oxidized/configs
 ```
 
+### Groups
+If you use groups, the nodes will be stored in directories named after the
+groups. The directories are stored one level above the directory for configurations
+without groups.
+
+Example:
+```
+/var/lib/oxidized/
++ configs/     # Configurations of groupless nodes
++ group1/      # Configurations of nodes in group1
++ group2/      # Configurations of nodes in group2
+```
+
+### Clean obsolete nodes
+The `file` output can automatically remove the configuration of nodes no
+longer present in the [source](Sources.md).
+
+> :warning: **Warning:** this might be a dangerous operation: oxidized
+> will remove **any** file not matching the hostname of the nodes configured
+> in the source.
+
+When using groups, it will remove any files not matching the hostnames of the
+nodes from the groups directories (which are on the same level as the default
+directory). As a safety measure, oxidized will only clean configuration out of
+active groups. If the group `example` isn't used anymore, oxidized won't clean
+the configurations out of the directory `../example/`.
+
+Configuration:
+
+```yaml
+output:
+  default: file
+  clean_obsolete_nodes: true
+  file:
+    directory: "~/.config/oxidized/configs/default"
+```
+
+
 ## Output: Git
 
-This uses the rugged/libgit2 interface. So you should remember that normal Git hooks will not be executed.
+This uses the rugged/libgit2 interface. So you should remember that normal Git
+hooks will not be executed.
 
 For a single repository containing all devices:
 
@@ -63,7 +102,49 @@ output:
 
 ```
 
-Over time, your Git repository will expand, potentially leading to performance issues. For instructions on how to address this, see [git performance issues with large device counts](Troubleshooting.md#git-performance-issues-with-large-device-counts).
+### 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 may lead to performance issues. If you encounter
+such issues, you should perform a Git garbage collection on your repository.
+
+Follow these steps to do so:
+
+1. Stop oxidized (no one should access the git repository while running garbage
+   collection)
+2. Make a backup of your oxidized data, especially the Git repository
+3. Change directory your oxidized git repository (as configured in oxidized
+   configuration file)
+4. Execute the command `git gc` to run the garbage collection
+5. Restart oxidized - you're done!
+
+
+### Clean obsolete nodes
+The `git` output can automatically remove the configuration of nodes no
+longer present in the [source](Sources.md).
+
+> :warning: **Limitations**
+> - this currently only works with `single_repo: true`
+> - it will ignore configurations saved as [output types](#output-types) in
+>   a separate repository.
+> - oxidized will refuse to remove old configurations
+>   when saving  [output types](#output-types) in a subdirectory of the git
+>   repository (`type_as_directory: true`), or it would remove the output
+>   type directories
+
+Oxidized will remove **any** file within the git repository not matching the
+group and hostname of the nodes configured in the source and will then commit
+the change into git.
+
+Configuration:
+
+```yaml
+output:
+  default: git
+  clean_obsolete_nodes: true
+  git:
+    single_repo: true
+    repo: "~/.config/oxidized/devices.git"
+```
 
 ## Output: Git-Crypt
 

data/docs/Release.md

@@ -1,6 +1,12 @@
 # How to release a new version of Oxidized?
 This document is targeted at oxidized maintainers. It describes the release process.
 
+## Version numbering
+Oxidized versions are nummered like major.minor.patch
+- currently, the major version is 0.
+- minor is incremented when releasing new features.
+- patch is incremented when releasing fixes only.
+
 ## Review changes
 Run `git diff 0.30.0..master` (where `0.30.0` is to be changed to the last release) and review
 all the changes that have been done. Have a specific look at changes you don't understand.
@@ -23,43 +29,47 @@ 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.
+## Create a release branch
+Name the release branch `release/0.xx.yy`
 
-Do not integrate late PRs into master if they do not fix issues for the release. The must wait for the next release.
+Update CHANGELOG.md:
+- review it
+- add release notes
+- set the new version (replace `[Unreleased]` with `[0.xx.yy – 202Y-MM-DD]`)
 
-## Version numbering
-Oxidized versions are nummered like major.minor.patch
-- currently, the major version is 0.
-- minor is incremented when releasing new features.
-- patch is incremented when releasing fixes only.
+Change the version in `lib/oxidized/version.rb`
+
+Upload the branch to github, make a Pull Request for it.
+
+## Make sure you pass all GitHub CI
+They test different ruby versions, the docker build process and codeql.
+
+## Test !
+Test the git code and the container against as much device types and
+environments as you can.
 
 ## Prepare the release in your working repository
-1. Checkout the master branch of oxidized. Make sure you are up to date with origin.
-2. Change the version in lib/oxidized/version.rb
-3. Change CHANGELOG.md to replace [Unreleased] with [0.xx.yy – 202Y-MM-DD]
-4. Run `git diff` to check your changes
-5. Commit the changes to the local git repository with a commit message “chore(release): release version 0.xx.yy”
-6. Tag the commit with `git tag -a 0.xx.yy -m "Release 0.xx.yy"`
-7. Build the gem with ‘rake build’
-8. Run `git diff` to check if there have been more changes (there shouldn't)
-9. Install an test the gem locally
-```
-gem install --user-install pkg/oxidized-0.30.0.gem
+1. Merge the Pull Request into master
+2. `git pull` master
+3. Tag the commit with `git tag -a 0.xx.yy -m "Release 0.xx.yy"`
+4. Build the gem with ‘rake build’
+5. Run `git diff` to check if there have been more changes (there shouldn't)
+6. Install an test the gem locally
+```shell
+gem install --user-install pkg/oxidized-0.xx.yy.gem
 ~/.local/share/gem/ruby/3.1.0/bin/oxidized
 ```
 
 ## Release in github
-Push the change and the tag to github:
+Push the tag to github:
 ```
-git push
 git push origin 0.xx.yy
 ```
 
-Make a release from the tag in github
-- Thank the contributors
-- Only describe major changes, and refer to CHANGELOG.md
+Make a release from the tag in github.
+- Take the release notes frm CHANGELOG.md
 - List new contributors (generated automatically)
+- Keep the Full Changelog (generated automatically)
 
 ## Release in rubygems
 Push the gem with ‘rake push’