Once we download the archive of the latest release, we extract the files. We can locate the following two files that contain the detailed logging of individual project files:
ChangeLog-ocsreports
ChangeLog-server
Please check out the screenshot below to see what we are talking about.
The ocsrepcorts file deals with the web-based user interface of OCS-NG. Basically, it contains the changes that are made to the administration interface. As their names suggest, the server file is the log file of the changes suffered by the server backend of OCS-NG. By this, we mean the MySQL related queries, fixing security vulnerabilities, adding support for new functions, and so on. As expected, the server changelog is ten times larger.
Let's see what the changelog looks like from the inside by taking a look at an example of the following excerpt of the ChangeLog-ocsreports file:
The syntax of the log is quite simple. It starts with the date when the change occurred. It then continues with the name of the developer that introduced the change along with their contact information. Next, the change is described. The previously mentioned example is quite self-explanatory. Sometimes, the descriptions of these changes are understandable for the public as well, but that is not always the case.
Here's another important change that is relevant to the public, and it's documented as shown in the following screenshot:
Especially in case of bug fixes or issues, only the developers know what that specific part applies to, why they phrased that description like that, and what exactly that change deals with. In those cases, we should leave them alone. They are not meant for the general public, unless we are planning to get involved in development as volunteers. Thus, do not worry if you are reading the changelogs and find something you do not understand!
Alright, but then why are we explaining how to analyze changelogs, and why are we bothered about them? Answering that question is simple. Major changes that either directly or indirectly affect the public and the community of users are detailed and explained—always! This means that when new features are introduced, they are documented. In case of fixes or additions that alter the behavior of the software, we can find these to be mentioned.
The previously mentioned description of changelogs is pretty general to every open source project. The developers of OCS-NG are doing a great job of explaining each modification, even if it's just in a few words. The descriptions make sense and when there's a major one, it can get few sentences long.
It is important to understand how to read changelogs as their use is quite preponderant, especially as more and more open source projects are gaining popularity.
As a conclusion to this appendix, this new version did not bring anything new to the table that would alter the behavior of OCS-NG. Everything we learned about OCS-NG up to now during the entire course of this book still applies to this new version, and we could pretty much say that it's going to be valid for the entire course of the project.
Good luck with your OCS Inventory NG setup. This book should be used as a reference material along with the official documentation, even after the inventory is up and running.
I'm sure that you won't regret going on the path of OCS-NG. It sports one of the most flexible and modular platforms for inventorying and a simple agent-querying mechanism that works for all kinds of IT-related assets. Eventually, when integrated with GLPI, it becomes a powerful all-in-one suite that brings to the table out of the box solutions for most inventory necessities.
Let me hand out a few final goodbye points:
Visit the forums, and don't hesitate to ask for help
Check at least once a month whether there's a new release on the official site
Do not skimp on the scheduling of automated backups stored somewhere else
Whenever you face errors, check the logs and locate the cause of the trouble
Once found—try search engines for the exact phrase