Visit sillysky.net, home of nyssr.net!

I am currently developing an application that displays alerts from the log system.
A local service reports all error messages to the application's address.

Since multiple instances of the Log Alert application can run on different nodes,
the application must announce itself via broadcast.
Additionally, it subscribes to notifications for new nodes,
as newly started nodes cannot receive the broadcast if it was sent before their startup.
These nodes receive a separate notification instead.

The application displays all error messages from the logs of various nodes in a list,
focusing on the most recent message.
Clicking on an error message reveals a context excerpt, showing the five preceding log entries,
which are retrieved from the respective node via a message request.

A button allows switching to the full log view of a node.
This log is displayed in a separate browser tab, using message-based communication.

Since logs can become very large, they are fetched from the node in chunks.
Each log entry has an index number, enabling selective retrieval of missing entries.
The question remains whether all entries should be loaded or only those currently visible.
I will favor the latter approach.

The service on the node stores logs not only as formatted text
but also as structured records with different fields.
For this purpose, I will use an H2 database.

A search function will be available within the log view.
Various search terms can be used, each highlighted in a different color.

Additionally, search terms can be sent to the nodes.
Whenever one of these terms appears in the log, an alert is triggered,
and the corresponding log entry is sent to the application.

Log levels can be adjusted via the Node Manager in the general configuration dialog.
However, it would be beneficial to provide additional specialized dialogs
for fine-tuned log level configuration.

Can't wait to hear what you think—let me know your thoughts!

Michael

This version primarily includes bug fixes and minor enhancements.

nyssr.net now supports Java language level 23, which is suitable for standalone nodes.
With this node, you can run plugins compiled with the same or a lower language level.

For embedding the library into existing applications, the version with Language Level 8 is recommended.

If you need versions between 8 and 23, please contact us in the forum.

What's new?

In addition to the usual bug fixes, the following features have been implemented:

Session Handling

The SessionManager has been expanded with a second type of session token.
This token is significantly longer than the previously introduced 16-byte token,
as it contains data about the current session.
Embedded data includes the user ID, user permissions, an expiration timestamp,
and the previously known short token type.
The data is compressed and signed with the SessionManager's private RSA key.

For local verification, a "SessionVerifier" service has been added to the kernel.
This service requires the public RSA key to verify the token.
The key can be stored in the configuration of individual nodes.
If not, the SessionManager automatically retrieves the key when the node starts.

The local SessionVerifier checks the token and extracts the necessary data, saving a request to the SessionManager.

The previous method of token usage remains supported.
It is now also possible to pass a message with a short session token to the verifier.
The service retrieves the long token from a cache or sends a request to the SessionManager.
In case of an error (e.g., session expired or unknown), the submitted message is returned to the sender with an error code.
If successful, the message is resent, this time with the long token.

NodeManager

The NodeManager web application has been enhanced with additional dialogs for
configuring remote nodes, allowing nodes that are not accessible via SSH to be configured.


Have a great time!

Welcome to the Sillysky Software Laboratories Forum!

Hello, my name is Michael Hoppe, and I'm excited to introduce you to my work at Sillysky Software Laboratories. For over 30 years, I have been developing software for a wide range of companies, driven by a passion for distributed systems and event processing.

The roots of nyssr.net stretch back to the early 90s when I first started working on its foundations as part of a catalog software project. The initial versions laid a foundation that I later adapted successfully in large enterprises. Over the years, nyssr.net has continued to grow: it has been restructured, refined, and modernized to meet today's demands. The result is a system that not only performs exceptionally well but is also enjoyable to work with.

I'm often struck by how many complex systems are still built with outdated and often inadequate technologies and protocols like HTTP – as if there were no alternatives. Nyssr.net is my contribution to offering a different perspective on the design of modern, connected systems.

In this first step, I've decided to make nyssr.net publicly accessible. For now, it is not open source, as I want to maintain control over its development and ensure quality. Non-commercial use is free, while commercial applications require a license fee to allow me to sustainably provide support and future enhancements.

If you have any questions about nyssr.net or RemoteSkin, please feel free to ask in this thread. I look forward to engaging with you and hope this forum will become a valuable platform for discussions and ideas around my software!

Looking forward to connecting with you – welcome aboard!
You can find us here: https://sillysky.net