 Daniel Nashed | Daniel Nashed 21 April 2024 18:31:51 I have been looking for a simple way to send messages to a messaging application.
In Discord it is pretty simple to create a simple webhook.
You just go to your channel and create the hook.
The webhook URL contains the authentication and the target.
Here is how the result looks like. Below you find the simple bash script and the configuration.
-- Daniel
#!/bin/bash
discord_url="https://discord.com/api/webhooks/1231669332577350000/6nmsJWzTmkpiq1n4vyQVmlOCsdZolkA6TZJAjhUYxRrvpAv9SZ91Vu26amxxxx"
send_discord_msg()
{
curl -H "Content-Type: application/json" -X POST -d "{\"content\": \"$1\"}" $discord_url
}
send_discord_msg "Hello, World!"
 Daniel Nashed 21 April 2024 16:47:44 How long does it take to update a Domino server?
The answer is as always: "It depends".
In my case it depends how long it takes to shutdown Domino --> That's around 30-60 seconds for a normal server.
So the answer could be close to "42" ... LOL
I am usually building a container image, which I push to a private registry. On a server I just have to pull the new image and run "dominoctl update".
That's all it takes to go to a new FP or release. In this case 14.0 FP1.
---
Building an image is a different story, but also is super easy.
Once I updated the GitHub repository, you just have to run the build.sh script.
The new menu can remember the add-on images installed and also finds out what the latest version is.
Depending on the add-on software and your infrastructure it takes like 10 minutes to build an image
But building the image does not cause any down time of your server.
Only the stop and restart of your server needs a downtime of usually less than 1 minute.
-- Daniel
dominoctl update
-----------------------------------------
/etc/sysconfig/domino_container
Info: New Image Version available!
Updating Container [pluto] ...
Stopping Container ...
pluto
Removing Container ...
pluto
Creating & starting new Container [pluto] ...
c3fe7a3d5160bf8b4a2abf8786ea0e22fb811c350c969621fbc793095ca799ff
Successfully updated Container [pluto] Daniel Nashed 21 April 2024 09:45:42 Last preparations are done. For the first time I might do my presentation on an iPad including the demo with Nomad Mobile.
Beside the key note and roadmap sessions, here are my session highlights for the conference in order of their appearance...
(see the full agenda --> https://engage.ug/engage2.nsf/Pages/sessionagenda2024) Please stop by with questions about Domino CertStore/CertMgr, Domino Backup Restore, Domino Containers, Domino CScan/ICAP, Domino One Touch Setup (OTS), Admin Central, Domino AutoUpdate and related topics ... Safe travels to Antwerp! I am looking forward to see many of you.
-- Daniel Ad12. What's New in Domino Administration Tuesday, April 23 | 13:30 - 14:15 | E. Joseph Schaddezaal / Thomas Hampel Ad02. Deep Dive Domino 14.0 AutoUpdate Tuesday, April 23 | 16:30 - 17:15 | E. Joseph Schaddezaal / Daniel Nashed Ad10. Domino Containers - The Next Step Wednesday, April 24 | 08:00 - 08:45 | D. Schilderskamer / Martijn de Jong Ro01. The Ultimate HCL on Linux Round Table Wednesday, April 24 | 09:00 - 10:00 | B. Sigarenkamer / Bill Malchisky, Stephan Wissel, Thomas Hampel, Daniel Nashed Ro03. Domino Family Roundtable (incl. Sametime) Wednesday, April 24 | 11:30 - 12:30 | B. Sigarenkamer
Daniel Nashed 20 April 2024 13:57:37 This is still a preview and not listed as an official Raspberry Pi image. I was just curious and needed a new demo machine for Engage conference next week. It's running a Docker host, which can run Grafana, Prometheus, Loki and NGINX in a compose stack on ARM. -- Daniel  Daniel Nashed 19 April 2024 16:41:12  |
Kernel : 6.8.0-22
glibc : 2.39
OpenSSL : 3.0.13 30 Jan 2024
Curl : libcurl/8.5.0 2023-12-06
NGINX : nginx/1.24.0
OpenZFS : zfs-2.2.2 |
The new Ubuntu long term release is about to be available next week while we are at Engage.
A customer asked about Ubuntu LTS versions today and I noticed it is about to be released.
The release notes are already public https://discourse.ubuntu.com/t/noble-numbat-release-notes/39890
There is also a container image on Docker Hub ( ubuntu:24.04) and there is a daily ISO image available.
I took a quick look and addressed two smaller but fatal issues: - Domino start script not detecting systemd
- Domino Container failed because Canonical added the "ubuntu" user as 1000:1000 in the container --> I needed to move their user to 1001:1001
Beside that Domino runs on Ubuntu 24.04 LTS. But is not officially supported.
The kernel version is too new and has not been tested by HCL. We can expect HCL to look into 6.x kernels for supporting the next SUSE Enterprise service pack. But right now it is untested !!
I can't advice you to run Domino on Ubuntu 24.04 at this point. I would stay with Ubuntu 22.04 LTS until 22.04.1 and a statement from HCL!
There is no need to move right now. And you can in place migrate to newer versions later for server you install today.
Let's discuss at Engage next week at the Linux round table
That statement is not true for early adopters who want to test it out and provide feedback.
For me it is essential to be ahead of the curve and solve problems early on before others hit them.
And for sure this would be a good discussion topic for the Linux session at Engage next week...
I hope to see many of you there!
-- Daniel
Test Results from a container build on a Ubuntu 24.04 LTS host with the matching container image
"testResults": {
"harness": "DominoCommunityImage",
"suite": "Regression",
"testClient": "testing.notes.lab",
"testServer": "testing.notes.lab",
"platform": "Ubuntu Noble Numbat (development branch)",
"platformVersion": "24.04 LTS (Noble Numbat)",
"hostVersion": "24.04 LTS (Noble Numbat)",
"hostPlatform": "Ubuntu Noble Numbat (development branch)",
"testBuild": "14.0FP1",
"imageSize": "3854944019",
"containerPlatform": "docker",
"containerPlatformVersion": "24.0.7",
"kernelVersion": "6.8.0-22-generic",
"kernelBuildTime": "#22-Ubuntu SMP PREEMPT_DYNAMIC Thu Apr 4 22:30:32 UTC 2024",
"glibcVersion": "2.39",
"timezone": "Etc/UTC",
"javaVersion": "17.0.10 2024-01-16",
"tikaVersion": "2.9.2",
"dominoAddons": "ontime=11.1.1,languagepackÞ,verse=3.2.1if1,nomad=1.0.11-14.0,traveler=14.0,domrestapi=1.0.11-14,capi=14.0,leap=1.1.3",
...
Daniel Nashed 17 April 2024 22:52:58 The new fit & finish work and the new autcat.nsf integration requires template changes. Please make sure you are getting the template version 14.0 from 08.03.2024 and not the earlier version from 03.11.2023 shipped with Domino 14. When deploying the container image I noticed an issue with the folder permissions where the container image is getting template updates for Fixpacks.
The directory /opt/hcl/domino/notes/latest/linux/data1_bck/140FP1/localnotesdata contains updated templates. But the directory can be only accessed by "root" and the container runs with the "notes" user. This is not new to 14.0 FP1. Also 12.0.2 fixpacks had the same permissions, but nobody noticed the missing updates. I fixed it in the HCL Community container build. But the HCL container image does have the file permissions which prevent the deployment.
For hte HCL image you can remove /local/notesdata/domino_ver.txt, stop and remove the container and run it again.
This will initiate a full release template update - which also contains the FP templates.
In general if you are not using a container image, please make sure design refresh is running on autoupdate.nsf to get the latest functionality. Daniel Nashed 17 April 2024 22:02:53 When the new integration is enabled, client web-kits are just pushed to AUT Catalog.
The push will also happen for existing web-kits once the document is updated with data containing the Metadata XML.
No manual steps needed. The documents and the new view have a button to directly jump into AUT Catalog.
The button on top only shows up for software pushed to AUT Catalog.
AUT Catalog sometimes has multiple documents for the same web-kit.
For example the Standard and All Client (Admin/Design client) needs the same FP.
Or the 32bit to 64bit client packages are also a separate file and product document in autocat.nsf
Domino AutoUpdate knows all of the web-kits and dependencies and pushes documents accordingly.
It will also correct missing documents. It uses the AUT Catalog hash to ensure software is only pushed once.
And also knows about the language versions of web-kits.
-- Daniel
Daniel Nashed 16 April 2024 20:53:23
The What's New section of AutoNotify doesn't show up until you update to Domino 14.0 FP1.
This is actually one of the improvements in the AutoNotifiy back end code in 14.0 FP1
There are a couple of fit & finish changes in AutoUpdate as well.
The software.json data has been improved to use dynamic categories and can distinct different client types.
Beside that there is a brand new AUT Catalog integration to automatically push client web-kits directly to autocat.nsf.
No more Metadata XML to download or manual attach. Configure it once to get web-kits automatically pushed to autcat.nsf.
Along with those autoupdate enhancements, there are also DAOS improvements.
This is the first time HCL added features in a Fixpack.
If you want to hear about details about AutoUpdate including Domino 14.0 FP1 enhancements join me at Engage in my session next week.
If you can't wait for Engage, here is a link to the documentation --> https://help.hcltechsw.com/domino/14.0.0/admin/wn_140FP1.html.
My session will go into much more detail and explain the new functionality.
-- Daniel
 Daniel Nashed 15 April 2024 08:32:07
The oathtool is the standard tool on Linux. It comes as a command-line tool or a dynamic and static link lib to be used in your own applications.
You can statically link the code into your application and generate TOTP codes and also validate them.
The homepage contains information about the command line tool "oathtool" and also the lib "liboath".
https://www.nongnu.org/oath-toolkit/
Example how to use it on command-line.
The example used the base32 encoded secret for "test".
oathtool --totp -b ORSXG5AK
Key URI Format
When importing TOTP secrets into a TOTP client it is very conventient to use a QR code.
Some clients don't even let you specify parameters like signing algorithm manually.
There is a URI format documented here:
https://docs.yubico.com/yesdk/users-manual/application-oath/uri-string-format.html
https://github.com/google/google-authenticator/wiki/Key-Uri-Format
To create a QR code you can use the qrencode Linux tool, which can generate an ASCII graphics QR code.
Example code to generate a QR code for TOTP setup
echo "otpauth://totp/NashCom:nsh@acme.com?secret=$(echo test | base32)&issuer=NashCom&algorithm=SHA1&digits=6&period=30" | qrencode -tANSI256 -o -
Example C code
Without error checking the C code to generate a TOTP code drills down to this:
oath_init();
oath_base32_decode (SecretB32, strlen (SecretB32), &pSecret, &len);
oath_totp_generate2 (pSecret, len, now, OATH_TOTP_DEFAULT_TIME_STEP_SIZE, OATH_TOTP_DEFAULT_START_TIME , 6, flags, szOTP);
oath_done();
It took me a moment to bring all those pieces together.
Specially on the C code side the important part is to that you want the Base32 encoded secret to be stored and use the conversion routine to convert it back as an imput.
Don't try to store the decoded string and pass it manually.
Conclusion
Now you have all your pieces to generate and verify TOTP digits either on command line or in your own application.
For security reasons I would not invoke the command-line tool from an application and instead statically link the lib into your application as show in my simple example.
My first use case will be my own sudo su - implementation to use TOTP to switch to root instead of using a password.
The tricky part will be now to store the secret in a way, that nobody can read it. But that's a different story.
Daniel Nashed 11 April 2024 20:05:14 The standard configuration for Domino backup is a file back-end. This makes mostly sense with de-duplicating storage.
This could be for example a NetApp appliance or any other de-duplicating storage device.
Also an appliance or Linux machine running ZFS as the file-system with compression enabled, is a good backup target.
Just a plain backup to normal storage does not make much sense, because it would be add the amount of your NSF files for every backup to the backup storage.
When Domino Backup was introduced in Domino 12.0 the the native Domino file copy operations used a quite small block size, which lead to low thruput rates on Windows and Linux depending on the back-end.
Therefore Domino Backup increased the buffer to 128 KB by default with the option to increase it further up to 1 MB.
Depending on your storage back-end and file-system, the following parameter can be a true RunFaster=1 parameter for you.
notes.ini FILE_COPY_BUFFER_SIZE=1048576
If you are using Domino Backup with a file back-end, you should really try this out and report the difference back here including your OS version and type of storage (disk, NFS mound, Windows share etc).
See my recent Proxmox ZFS de-duplication blog for ZFS de-dup performance.
The parameter was also listed there. But maybe wasn't sufficient highlighted.
-- Daniel | |
![[HCL Domino]](../lotus-domino.gif){kind=small}
![[Domino on Linux]](../domino-linux.gif){kind=small}
![[Nash!Com]](../nashcom.gif){kind=small}
![[Daniel Nashed]](../daniel-nsh.gif){kind=small}