Domino on Linux/Unix, Troubleshooting, Best Practices, Tips and more ...

Sametime 10 Limited use for Windows 32bit has been released

Daniel Nashed  15 June 2019 00:41:01
Samtime 10 Limited has been released. It's the first new version that we see for a long time. And there is already planning for Sametime 11 and 12.

But the next step will be to finish the Sametime 10 64bit Support which will run on Domino 10 for Windows and Linux.
For now you have to install Sametime 10 Limited use on Domino 9.0.1 32bit.

See all details in the following blog post which answers many of the open questions:

https://www.ibm.com/blogs/collaboration-solutions/2019/06/14/what-is-sametime-limited-use/


-- Daniel

New Start Script version 3.2.2 with a Tika Stop server work-around

Daniel Nashed  14 June 2019 06:39:09

There are a couple of new features to the start script and fixed one issue with restartcompact for systemd.
And there is also an addition for the Docker environment. I have a separate blog post about the current Tika issues -->
http://blog.nashcom.de/nashcomblog.nsf/dx/domino-10-attachment-indexing-with-apache-tika.htm

There is shutdown control I added into the start script, because the external Java process does currently not terminate.

By default without any config parameter the shutdown check will be 30 seconds.
The default in the config in the configuration file is 20 seconds. So if you don't deploy the new config settings, the script will wait 10 seconds longer before killing the Tika process.


Beside that hard coded logic for the Tika process, I added another delayed shutdown command that is invoked during the shutdown after some time.

And there is also a new tika process stop/kill command, which I added.


When you kill the tika server process, it will be restarted when the next process tries to index an attachment.


The new version is available by mail request (-->
http://www.nashcom.de/nshweb/pages/startscript.htm).

I am still planning for the next major release. It might not have many new features but will have changed default locations (probably /opt/nashcom), maybe will move to github (not sure because than I am loosing a bit of control but make the feedback process and download easier).

And I might move to a new documentation format. So probably the documentation will be online only in MD format. Still experimenting in converting MD files back to txt.

Also I sort of like the old text file better than the new MD format for the purpose of the start script documentation. Maybe I will just bring it up in two formats and get feedback.


-- Daniel


New Features


New Commands:


"systemlog" shows the last log lines from systemd service.

This is helpful to see output of the start script.



"tika" stop|kill


Shows the Tika server status and can be used to terminate the process.


Without additional parameters this command shows the status of the Tiker server process.

tika stop --> stops the process.

tik kill  --> kills the process.


Added "locale" output to server start logging.

This can help to troubleshoot issues with locale setting on your server.



New configuration options:



DOMINO_TIKA_SHUTDOWN_TERM_SECONDS


Tries to shutdown the Tika index server during shutdown.

IT happens that the Tika server does not terminate, which prevents the Domino server from shutting down properly.

Default 30 seconds.


DOMINO_SHUTDOWN_DELAYED_SCRIPT


Script which can be executed delayed during shutdown.

DOMINO_SHUTDOWN_DELAYED_SECONDS
specifies the number of seconds after shutdown start.


DOMINO_SHUTDOWN_DELAYED_SECONDS
(default 20 seconds)


Shutdown Delay for delayed shutdown command.

Default is 20 seconds if script is defined.


Docker Support:


Now the entry point script checks if the script is already started with the right user and will not switch to the user.

There are configuration options on the Docker side to run the entry point script directly with the right user.

When you switch the user to "notes" at the end of your dockerfile, the container is started with "notes".

This provides better security.


Problems Solved


restartcompact and restartfixup did not work correctly with systemd.

For systemd the rc_domino script needs to stop the service run compact/fixup and restart the service.

Domino 10 Attachment Indexing with Apache Tika

Daniel Nashed  14 June 2019 06:38:17

Tika is the new engine used to extract text from attachments for fulltext indexing in Notes/Domino 10 (client and server).
It replaces the previous key view package which had a different integration (it was leveraging the kvoop binary).

The Tika server is a stand alone Java based open source server component (
http://tika.apache.org/) which is accessed by the server processes via curl requests (you can see it when looking into a NSD ;-)

Tika is just a single jar file which is started in a separate JVM instance. It is loosely coupled with Domino.

So it is living in it's own "stand box" with communication over TCP/IP. It's not based on any Domino code and doesn't share memory nor other resources like MQs etc.


Because it is quite new in Domino there are some open issues. Some of them have been already addressed in FP2 but there are some fixes that had to wait for FP3.

The good news is that those limitations can be worked around.


I hope this helps you in your deployments. The parameters are just needed on server side but they would also work on the Notes client if really needed.

It's the same back-end code which is executed on the client and the indexing works in the same way on the client.


-- Daniel


Tika Shutdown Issues on Linux


One of the issues we ran into is a server shutdown hang. On Linux currently the Tika process does not terminate, which will cause my start script to wait for this process to terminate.

 
I have added new logic to my start script , which is automatically killing the process at shutdown (default without any parameter after 30 seconds, default in the config file 20 seconds).

This ensures that your server shutdown will continue to work in time and this logic stays active also for newer versions just in case.

So we give the Tika process time to terminate before stopping it on OS level.


In addition the start script has an option to stop/kill the process during run-time. In normal cases killing a Domino process isn't a good idea.

But because Tika is loosely coupled, you can kill it without having any Domino server impact. Also the child died signal is not causing the server to panic in this case.


See version 3.2.2 update in a separate post for details of the new start script version -->
http://blog.nashcom.de/nashcomblog.nsf/dx/new-start-script-version-3.2.2-with-a-tika-stop-server-work-around.htm

Here are the details from HCL support for this issue. This fix is planned for FP3 and Domino 11.


SPR - JPAIB6ZLKG reports Java Tika Process not terminating when Domino Shutdowns cleaning (NON-WINDOWS Platforms Only)



Tuning Tika


Beside that there is a performance issue one customer with very large attachments (mostly PDF) did run into.

By default the memory for the Tika process might be too small. And the server is not honoring the JVM size parameter.


But there is a general JVM Options Override parameter, which can be used to pass options to the Tika server.

There is more control planned without this generic parameter for the next fixpack. But for now this option can be used to increase the memory.


In addition there is a newer Tika server version 1.20 which might give you better results from performance side as well.

Domino is using version 1.18 but because it is a single jar and the server is loosely coupled, you could replace the jar file with the current version from the Tika project website.


It's not fully supported by IBM/HCL today but works in our test. They are looking into updating the Tika server version for Domino 11 and maybe also for Domino 10 FP3. But that isn't committed.


In addition to this change, you might want to increase the Tika server timeout to give the server more time to respond for larger attachments and higher load on the server.


Here are the parameters that could help you. Note this examples use the newer Tika version. The existing version is the same name without the additional version number.


Windows:

TIKA_JVM_OPTIONS_OVERRIDE= -Xmx1536m -jar "C:\Program Files\IBM\Domino\tika-server-1.20.jar"


Linux:

TIKA_JVM_OPTIONS_OVERRIDE= -Xmx1536m -jar "/opt/ibm/domino/notes/latest/linux/tika-server-1.20.jar"


DEBUG_TIKA_TIMEOUT=60000


More strict Server Certificate handling in iOS 13 macOS 10.15

Daniel Nashed  5 June 2019 08:12:23

Beginning with iOS13 and macOS 10.15 the more stricter handling could have quite high impact and lead to untrusted certificates specially for internal certificates.

An official CA should have taken care of this already and certificates should be correctly issued.

But this can impact internal certificate authorities (CAs). Existing certificates are not impacted by the stricter key usage checking and the existing expiration will not change.

For new certificates you have to have a careful check of the following Apple statement which I commented in blue.


I know certificate stuff can be kind of boring and complicated. But you have to look into those changes!!


-- Daniel


https://support.apple.com/en-us/HT210176

Let me comment the new announcement
in green.

-- snip --


All TLS server certificates must comply with these new security requirements in iOS 13 and macOS 10.15:

TLS server certificates and issuing CAs using RSA keys must use key sizes greater than or equal to 2048 bits. Certificates using RSA key sizes smaller than 2048 bits are no longer trusted for TLS.


This isn't new and nobody should use have a key size below 2048.


TLS server certificates and issuing CAs must use a hash algorithm from the SHA-2 family in the signature algorithm. SHA-1 signed certificates are no longer trusted for TLS.


Certificates and intermediate CA certs already needed to be SHA-2 before.
The root CA's certificate is verified in a different way and should still not be effected. Even the statement isn't that clear about it.

But if that would not be OK any more, many CAs would be in trouble.


TLS server certificates must present the DNS name of the server in the Subject Alternative Name extension of the certificate. DNS names in the CommonName of a certificate are longer trusted.


The SAN name (Subject Alternate Name - DNS name)  is something that is already required by browsers etc. And I don't see this as a big surprise.


Additionally, all TLS server certificates issued after July 1, 2019 (as indicated in the NotBefore field of the certificate) must follow these guidelines:


TLS server certificates must contain an ExtendedKeyUsage (EKU) extension containing the id-kp-serverAuth OID.


This is a big deal for you own CAs. EKU isn't used by all private CAs. And for openssl it's not simple to configure the extended key usage.

The OID and name is the following: TLS Web Server Authentication (1.3.6.1.5.5.7.3.1).

To check your certificate you can look into what your browser tells you about it. Or you use openssl to dump your certificate.


Here is a command-line example and the result should look like this:


openssl x509 -text -noout -in domino.crt

...

 X509v3 extensions:

          X509v3 Extended Key Usage:

              TLS Web Server Authentication

          X509v3 Subject Alternative Name:

              DNS:domino.nashcom.loc

...


The name and the OID are the following:

TLS Web Server Authentication (1.3.6.1.5.5.7.3.1)

To create a certificate properly your openssl command-line gets more complicated or you need a configuration file.

But in combination with a SAN you want to write the file dynamically...


Here is an example command-line from one of my scripts:


-- snip --

openssl x509 -passin pass:$CA_PASSWORD -req -days $CLIENT_VALID_DAYS -in $CSR_FILE -CA $CA_CRT_FILE -CAkey $CA_KEY_FILE \

        -out $CRT_FILE -CAcreateserial -CAserial $CA_DIR/ca.seq  -extfile <(printf "extendedKeyUsage = serverAuth \n subjectAltName=DNS:$SANS") > /dev/null


-- snip --


TLS server certificates must have a validity period of 825 days or fewer (as expressed in the NotBefore and NotAfter fields of the certificate).


Wow this is a big deal! That's a bit more than two years and two month! So this will impact customers getting 3 year certificates and also long vaild internal certificates.

In some cases customers generate internal certificates for much longer periods which would not work any more when you issue them after July, 1st, 2019!


So you might want to create those certificates before 1. July 2019 ;-)


Connections to TLS servers violating these new requirements will fail and may cause network failures, apps to fail, and websites to not load in Safari in iOS 13 and macOS 10.15.


-- snip --


So the two biggest surprises are the reduced certificate expiration days! Two years and two month is not really much!

And I am curious how the certificate vendors react on it.


-- Daniel

sudo for Domino start script

Daniel Nashed  31 May 2019 14:20:47

I wasn't aware that so many people are using "sudo" in combination with my start script.
On my machine I am using it for quite a while long before systemd support.
SLES allowed to start the server without root permissions but for CentOS/RHEL we always needed root also with init.d to start or restart a service.

With systemd we need root permissions on RHEL, CentOS and SLES.

I am currently invoking the rc_domino script wth sudo. But that means the rc_domino is running technically as root.

The better idea sounds like we allow the notes user to just use systemctl to start/stop/restart the domino.service.

The rc_domino script could be configured to use sudo. But that means we have to still make it configurable, because not everyone is using sudo.

IMHO allowing notes to use systemctl is the cleaner way.  The rc_domino script will figure out which operation is requested and invoke just the systemctl related commands via sudo.
rc_domino currently doesn't read the config file. But I could source it and check a parameter to check if sudo should be used.

Based on the feedback I tend to enable it by defaut.

But configuring sudo to allow systemctl should be a manual step (I can print what to do when the install script ran).

So here would be what I would allow by sudo if I implement it that way:


-- snip --

%notes ALL=/bin/systemctl start domino
%notes ALL=/bin/systemctl stop domino
%notes ALL=/bin/systemctl status domino
%notes ALL=/bin/systemctl enable domino
%notes ALL=/bin/systemctl disable domino

-- snip --

What do you think?

-- Daniel

Domino Start Script Survey Results

Daniel Nashed  31 May 2019 14:19:19


Thanks for everyone who responded to the Linux Start Script Survey!
This was really helpful. Let me share the results.

I am not sure if this is completely representative. I will be at DNUG conference next week and I will ask for feedback there as well in my sessions.


But I am not really wrong in what I thought. I was surprised by CentOS used that much!
And also how many would prefer to have the start script in a git repository.


-- Daniel


From the feedback I get the following results in short. See the screen prints for the detailed responses.


1. Most of you are using the default locations


/opt/ibm/domino and /local/notesdata.


2. For a new location the preference seems to be /opt/nashcom.

That would be very straight forward and clean and I could put also the extra files and sample configuration into the same location.


3. CentOS as a distribution is very popular for all who replied!
That wasn't expected since we have official support just for a year!


4. Many of you are using "sudo". That means I can think about how to better integrate with sudo and make it easier.

I will have a separate post about that.


5. Most of you are using VMware ESX(i) virtualization. Hardware is almost zero.


6. In consequence almost nobody is using partitioning.

That's what I expected. I keep the support for partition servers anyway. But I will not put effort into making the configuration easier.


7. Almost nobody tried to use SELinux on a Domino server.


8. Many want to have the start script in a git repository but there are still many who want to download a tar.

So I will probably do both in a way.




Image:Domino Start Script Survey Results




Image:Domino Start Script Survey Results



Image:Domino Start Script Survey Results


Image:Domino Start Script Survey Results


Image:Domino Start Script Survey Results



Image:Domino Start Script Survey Results


Image:Domino Start Script Survey Results



Image:Domino Start Script Survey Results



Image:Domino Start Script Survey Results

IBM Docker Script Support for 10.0.1 FP2

Daniel Nashed  30 May 2019 16:01:52
As discussed yesterday, the fixpack downloads from Passport Advantage and FixCentral look a bit different.
The actual files have the same hash. But the filename is different.

Because finding updates in FixCentral is easier and also because they are available earlier, we decided to add functionality to use both downloads with their default filenames.
The software.txt file just contains both filenames and the install script checks for both names.


The internal software.txt file software list looks like this:

--snip--
Product|Version|Download Name|PartNumber|SHA256 Hash
domino|10.0.1|DOM_SVR_V10.0.1_64_BIT_Lnx.tar|CNXL9EN|57a19f56da492740d50457bcb3eec6f2b5410e8e122608c19e1886cf3fb36515
domino|10.0.1FP1|DOM_SVR_V10.0.1_FP1_64B_LINUX_EN.tar,domino10001FP1_linux64.tar|CNZ9IEN|6f6209bd14814001d52cc3b0af734a3ead119e9f4e97341bf2ebaa3505550aa8
domino|10.0.1FP2|domino10001FP2_linux64.tar|CC1XREN|f3573d3f084836a923271967c07a402ce3f3d1f3830dc7a029fa6db6d70c9135
--snip--

For major versions and for Traveler you still have to use the Passport Advantage downloads.

The update is already checked into the develop branch if someone wants to give it a try --> https://github.com/IBM/domino-docker/tree/develop

-- Daniel

Notes Domino 10.0.1 Fixpack 2 available

Daniel Nashed  28 May 2019 23:25:43
Notes / Domino 10.0.1 Fixpack 2 is available.

I wasn't able to find it on Passport Advantage but I found it on Fixcentral.

Here is the fixlist:

http://www.lotus.com/ldd/fixlist.nsf/da28c739cc5024e9852583da006659a7/3501674bb1c8f1e0852584080063188b?OpenDocument

If someone has the product codes for FP2 and/or a download link for PA, please let me know...  I really need the PA versions for Docker..

-- Daniel

AppDevPack Security Setup explained

Daniel Nashed  26 May 2019 08:30:22

AppDevPack Security Setup explained


Configuration of the AppDevPack with all components -- specially the new IAM component -- isn't that straight forward when you are not used to juggle with certificates often.
I had a deeper look into it, because we want to automate the configuration process for Docker deployment.


My ultimate goal would be to completely automate deployment. But not all components are scriptable today.
But let me explain the components and how they need to be glued together to make it easier for your to install and configure it.


I also have built a script that can help you to create the right certificates, described at the end of this blog post.
It is part of the IBM Docker script. But could also be used for normal deployments.

Currently you can find the script here -> https://github.com/IBM/domino-docker/blob/develop/management/manage_certs.sh.
It's still in the develop branch of the project. That link will change once we merged the last changes to the master branch.

The steps that you have to do to install and configure are well documented here -->
https://doc.cwpcollaboration.com/appdevpack.
But the documentation doesn't explain in detail how all components play together from security point of view.

I hope the following description complements the official documentation and helps you setting up Proton with IAM.
You should read the official documentation first, before looking into those additional information.

-- Daniel


Overview of Components

The AppDevPack consists for the following main parts:

Proton Servertask


This is the heart of the AppDevPack and implements the new GRPC protocol.
Access to this task can be either anonymous, by client certificate or new with the IAM service with an OAUTH2 token.
Proton is a servertask which needs a keyring file with a proper certificate. The certificate needs to be issued to the DNS name of the server (for example proton.nashcom.loc).

The communication with the GRPC protocol (e.g. DQL queries) are handed by this servertask.
Proton hasn't got a well known port today. Choose any port above 1024 (the ports below are restricted ports on Linux).

I have chosen 1353 on my server. There are also examples using port 3002.

Notes Database "iam-store"


The database is used to store IAM data on the server. This database has to be created from iam-store.ntf which isn't in the Proton package but in the IAM server package.

During installation you have to copy it from the IAM server package.
The IAM Client user.id needs to have editor access to the database, because the IAM server will use the client certificate to authenticate on the Proton server and access the database  via Proton.

DSAPI Filter liboauth-dsapi.so


The DSAPI filter is an extension to the HTTP task and is needed to allow authentication for additional services implemented via HTTPS ( e.g. Calendar services)
If you want to use those services you have to properly configure HTTPS (with another keyring file) to allow secure communication.
This is really a separate component which is independent from Proton.

The DSAPI filter confused me, when first looking into this. But it is a separate part of the setup with a separate access to Domino via HTTPS beside Proton access.
This DSAPI will communicate with the IAM server to verify tickets and stores tickets also in the Web credential store.

Helper Servertask oauthcfg


This servertask is needed to configure the trust store for the DSAPI filter and is just invoked for configuration.
It is executed once to configure an additional configuration and writes the credential store configuration for the DSAPI Filter.

Before you can do that, you need to configure the credential store first.

IAM Server (Node.js application)


IAM stands for  Identity and Access Management. This is a standard term which is also used by different products

(see for example: https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html).

It is used to log in users and also to control access to applications.
This service is used for GRPC and also for HTTPS requests.

IAM leverages LDAPS communication for authenticating users and speaks on it's own with the Proton servertask for example to safely store the user tickets in a central Notes database iam-store.

Im most cases the user data is either in Domino Directory or in Active Directory in most of the cases. And we need a LDAPS with a proper certificate and matching name for the LDAP Server (it could be the Proton server).

IAM Client User ID


The IAM server stores it's data securely in iam-store.nsf.
Beside a client certificate for communicating with Proton, the IAM server needs a person document and Notes.ID which is stored in ID-Vault to be able to encrypt IAM data on the server.
The certificate is read from ID Vault and used for encryption.



Overview of Certificates and Keys

For secure communication all those components need to be able to communicate over SSL/TLS.
This requires Server and Client X.509 certificates. Let me describe the required certificates below.

The overview should help you to understand how all components work together from the security side.

Notes.ID for IAM Client / X.509 Client Certificate/Key


First of all you need a Notes.ID for the IAM Service. The IAM Client component of the IAM server uses a client certificate to communicate with the Proton server.
Beside the client certificate this user needs to a Notes.ID which is also stored in an ID-Vault!

The Notes.ID is used for encryption. The client certificate is used for authentication with the Proton server.
You need to import the client certificate (X.509) into the person document.

On the other side it is stored on the IAM server. The certificate is stored in PEM format and needs a password, which needs to be configured on the IAM server.

Server Certificate for Domino Server


Any Domino server accessed via HTTPS needs a proper Web Server Certificate which is stored in a keyring file.
Encrypted communication is required for HTTPS (port 443) access and also for LDAPS (Secure LDAP communication over port 636).
This could be on the same server or two different servers. In that case you would need two separate Domino keyring files with different hostnames.

Server Certificate for Proton


Proton uses the keyring file format to store the server key and certificate. It also needs a Web Server Certificate for secure communication.
The keyring file needs to contain the trusted root for their own certificates and also for the IAM Client certificate.
In the best case all your certificates are issued by the same CA. That would not require to add trusted roots and intermediate certificates into the keyring file.

Server Certificate for the IAM Server


Also the IAM server needs a Web Server certificate for secure communication.
This is a standard Web Server certificate and stored in PEM files instead of a keyring file on the Domino server side.

Client Certificate IAM Client


The IAM server needs to communicate with the Proton Servertaks.
Client certificate based authentication needs a X.509 certificate which is trusted by the Proton keyring file for the issuing CA.
The person document for the IAM Client needs to contain the Internet (X.509)Certificate.

You can manually import the file into the person document.


Summary: List of Certificates used

- Web Server Certificate (keyring) for Domino HTTPS and LDAPS

- Web Server Certificate for Proton (keyring)

- Web Server Certificate for IAM Server (PEM file)

- IAM Client Certificate (PEM password protected)

- IAM Notes ID with X.509 Client cert added to the person doc. Notes.ID must be available in ID Vault!



X.509 Certificates


In an enterprise/production environment or a internet facing service, you will have to use official certificates at least for the directly accessed components like IAM or your webserver.
The client certificate used by the IAM service only needs to be trusted by the Proton server.


For all certificates used, the corresponding other side need the CA Root and intermediate certificates from the connecting counter part in it's "local key store".

For example when the IAM server connects to Proton it has to verify the certificate of the host it connects to.
The Proton Server needs the CA's certificates to verify the √ćAM Client access.


In the best case all your certificates are coming from the same CA. This simplifies the configuration and is a best practice.
For a production environment you should consult the colleagues responsible for certificates and the internal CA.


For a test environment or a very small scale deployment, you can use your own created CA which will than be used to issue certificates for all the different components mentioned above.
The key here is that you create one CA and generate all certificates for all server and client components in IAM/Proton.

You cannot just use "self signed certificates" because there will not be a trusted root. But with openssl you can create your own local CA and issue certificates on your own.

IBM/HCL provides a simple script that generates a CA key and certificate, which is used to certify all your certificates.
The CA certificate will be your trusted root which should be stored in all your trust stores (keyring files, IAM server key-store).

Creating Certificates

There is a very basic script in AppDevPack 1.0.1. But it's not really configurable and you have to actually go into the code and change different places.

Therefore I wrote my own script to create all mentioned certificates in one step from the same CA.

The script also generates the required PEM files which can be directly imported into a keyring file via "kyrtool import all ..".
It also provides the needed CA trust certificates in the PEM file directory "ca_all.pem" which need to be imported into the IAM service.
You can also use the CA's root cert file directly to import them into your browser to void security warnings when accessing the HTTPS connections protected by those certificates.


The script will be part of the Docker deployment routines for AppDevPack later. But I want to share this script to simplify your deployments.
You just have to specify the right names and invoke the script. It will automatically create all the keys, certs and the final PEM files.
This script could also work with an external CA. In that case the script generates the keys, CSRs (certificate signing requests) and afterwards will add the certificate to the PEM file.

The PEM files generated could be imported into a keyring file in the following way.
I have not added it to the script directly, because this needs to be performed on a machine which has Notes or Domino and the kyrtool installed.
But the steps are very simple. On Linux you have to be the "notes" user and switch into the data directory.
The first command creates the keyring file. The second commant imports the key, cert and trusted roots into the keyring file.

Example: Create keyring file and import key & certs

su - notes
cd /local/notesdata

/opt/ibm/domino/bin/kyrtool create -k keyfile.kyr -p mysecretpassword
/opt/ibm/domino/bin/kyrtool import all -k keyfile.kyr -i domino_all.pem


Keys and Certificate Management Script

Let me describe the standard procedure with the automatically generated local CA.
The script can be used either stand-alone or with a configuration file. Here is the main configuration, which should be mostly self-explanatory.

There are more configuration parameters below. But those are more for special cases.

You just need to change the following settings and run the script.

It will automatically generated the needed files (see below).


# -------------------------- #

#  BEGIN MAIN CONFIGURATION  #

# -------------------------- #


DOMIMO_ORG="Acme"


DOMINO_SERVER="domino"

DOMINO_DNS="domino.acme.com"


PROTON_SERVER="proton"

PROTON_DNS="proton.acme.com"


IAM_SERVER="iam_server"

IAM_SERVER_DNS="iam.acme.com"


IAM_CLIENT="iam_client"

IAM_CLIENT_NAME="/O=$DOMIMO_ORG/CN=$IAM_CLIENT"


# You can choose between two different configurations


# a.) a local, simple CA should be used

# b.) a public or corporate CA should be used


USE_LOCAL_CA=yes


CA_ORG=Acme

CA_PASSWORD=domino4ever


CERTMGR_CONFIG_FILE="/local/cfg/certmgr_config"

CERTMGR_DIR=`dirname $0`/certs


# -------------------------- #

#   END MAIN CONFIGURATION   #

# -------------------------- #



Running the script will generate all the keys, certs and PEM files configured above.
You could also create additional certificates. But let's stay with the certs we need for Proton/IAM for this example.
The tool generates the following directories and stores all the files with corresponding names.


-- [ca
] --
All CA related files (private key, certificate, serial number)


-- [key] --

All created keys for all type of certificates


-- [csr] --

Generated Certificate Signing Requests (CSR). Should be empty, because our CA automatically signs the requests and deletes them afterwards.


-- [crt] --

Certificates for all generated keys


-- [pem] --

Complete PEM files with key, certificate and Root CA cert copied into one file in the right order to be used with the kyrtool to import certificates into a keyring file.
Those files can be directly imported via "kyrtool import all"
.
There is one special file ca_all.pem contains the certificate either of our own Root CA or for external CAs you should copy the Root CA and intermediated certs in the right order into this file (ordered from specific to unspecific -- Root CA's at the end).

This file is added to the other PEM files automatically for your convenience if you copy it before you run the script.

-- [txt] --

Lists detailed information about the certificates.

Now that you have all the certificates you can use them in the right step of the AppDevPack documentation.
With this overview it should be a lot easier to understand the AppDevPack documentation.

Below you see the sample output from the script. The certificate expiration is configured to 10 years for the CA and also for the certificates.
This is can be configured in the configuration file or script.


--------------------------------------------

ca -> OK

--------------------------------------------

KeyLen       :  4096 bit

Subject      :  /O=NashCom/CNÊ

Valid Until  :  May 15 12:12:47 2029 GMT

--------------------------------------------


--------------------------------------------

domino -> OK

--------------------------------------------

KeyLen       :  4096 bit

Subject      :  /O=Nashcom/CN=domino

DNS NAME     :  domino.nashcom.loc

Valid Until  :  May 15 12:12:47 2029 GMT

--------------------------------------------


--------------------------------------------

iam_client -> OK

--------------------------------------------

KeyLen       :  4096 bit

Subject      :  /O=Nashcom/CN=iam_client

Valid Until  :  May 15 12:12:52 2029 GMT

--------------------------------------------


--------------------------------------------

iam_server -> OK

--------------------------------------------

KeyLen       :  4096 bit

Subject      :  /O=Nashcom/CN=iam_server

DNS NAME     :  iam.nashcom.loc

Valid Until  :  May 15 12:12:51 2029 GMT

--------------------------------------------


--------------------------------------------

proton -> OK

--------------------------------------------

KeyLen       :  4096 bit

Subject      :  /O=Nashcom/CN=proton

DNS NAME     :  proton.nashcom.loc

Valid Until  :  May 15 12:12:50 2029 GMT

--------------------------------------------


Complete PEM files including trusted roots -> /local/certmgr/pem

Certificates issues by CA locationed here  -> /local/certmgr/crt

    Domino Linux Start Script Feedback Request

    Daniel Nashed  23 May 2019 17:41:53
    This week I had a couple of discussions about start script management and deployment.
    I have been at a customer who wanted to keep their existing none-standard locations for the Domino data directory and also the binary location.

    Now with systemd environments we have another file that contains the path to the main script logic which is located by default in /opt/ibm/domino/rc_domino-script.


    New Start Script Location (/opt/nashcom, /usr/bin)?


    I have introduced simple install script which installs and updates the start script -- if you are using the default locations.

    But the location might change again with Domino 11 because the binary path contains "ibm".


    I thought about how to make the Domino binary directory and the data directory configurable in an easier way, without a complicated install routine that replaces text in configuration files.

    Taking this all together this sounds like I should move the start script main script "rc_domino_script" into a location which isn't depending on the Domino binary directory name.


    This would allow me to easier implement automatic configuration and be more flexible for the future.

    Of course the install script would take care of the current location for your rc_domino_script. It would read your current configuration and create a link to the new location to ensure existing configurations would continue to work.


    It's still quite a change which could impact the way you install and run the start script.


    Start Script New Home on Git?


    In addition I am thinking about other ways to maintain the start script. What would you think about having the start script and the documentation located on github?

    I would need to move the documentation to MD format and it would look good on-line. But I would keep a tar file in the project to allow to download it as a single tar for anyone not using git software today.


    Those changes would be quite big. So I thought about asking for feedback before implementing them.


    Your feedback via simple 10 question survey


    I have created a simple survey which doesn't ask for very specific information like number of servers and users etc. It also will not ask for a name. It's only for me to understand where you are and what you need.


    You can comment here or fill out the survey which I have created. This is the first survey I am doing at all. And I am really curios of the results.


    Of course you can also comment here or send me private emails. But I would really appreciate your feedback on the survey.


    Some of the questions are needed for new functionality and I have been discussing with another BP for example how many admins are using "sudo".


    Here is the link -->
    https://www.surveymonkey.de/r/PMT3RQF

    Update: Just noticed the website was in German, when I started.
    I thought they will translate the text " Sonstiges (bitte angeben)" automatically into other languages.
    But it took my language on the website... I changed the text but the change did not show for me.
    So it means "Other (please specify). Next time I will switch the website to English first.


    And of course I will share the results.


    Thanks


    Daniel

    Archives


    • [IBM Lotus Domino]
    • [Domino on Linux]
    • [Nash!Com]
    • [Daniel Nashed]