0%

If you are using HCL’s appdevpack you might probably use the function bulkReadDocuments in your code. If this is the case and you are using this function with the parameter count you should check whether your application really displays all data. The count parameter is optional and is used to define the maximum number of results returned:

count {number}: An optional count of the maximum number of documents to read.
Note: If you don’t specify the optional count, the default value is 100. The “DOCUMENT LIMITS” configuration setting determines the maximum number of documents that can be read, up to 1000.

Source: appdevpack documentation

In one of our rest services, which are using appdevpack, the function bulkReadDocuments is used and a value of 1000 is set using the count parameter - paging is not used, because the expected result set will never exceed the set value. The problem now was that the count parameter is ignored under certain circumstances since appdevpack v1.0.9 at the latest, because with this version the value maximum note count was introduced in the central Proton configuration, whose default value is 200:

Controls the maximum number of documents Proton processes in a query found set. By default, Proton processes a maximum of 200 documents per request. A domino-db application may request more than the limit, but Proton caps the result size to this limit.

Source: appdevpack documentation

If the value of the count parameter of bulkReadDocuments is greater than the maximum note count parameter in the Proton configuration, you will still only get a maximum of 200 results delivered by bulkReadDocuments - there will be no warning in the log and no other hint. As a solution you can either increase the value of maximum note count or you always use paging when using bulkReadDocuments (this is imo the best solution).

Wenn man eine Node.js Anwendung schreibt, möchte man nicht immer eine Loglösung wie Morgan oder Winston verwenden, sondern einfach ein paar Ausgaben auf der Konsole, angereicht um die Informationen Datum und Uhrzeit. Dies kann man mit wenigen Zeilen Code erreichen:

console.logCopy = console.log.bind(console);
console.log = function(data){
      var tt = ‘[‘ + new Date().toLocaleDateString(‘de-DE’) + “_” +new Date().toISOString().slice(11,-5) + ‘] ‘;
      this.logCopy(tt, data);
};

Anschließend produziert console.log("Text 123") eine Ausgabe mit vorangestellter Uhrzeit und Datum.

Wenn die Anwendung über einen längeren Zeitraum läuft, ist eine Logrotation außerdem sinnvoll. Anstatt dies in jeder Anwendung einzeln zu implementieren, die auf dem Server läuft, kann man auch einfach das pm2-Modul pm2-logrotate verwenden. PM2 ist ein schlankes Tool aus der Kategorie Prozess-Monitoring: leichtgewichtig, schnell eingerichtet und insgesamt sehr zu empfehlen, insbesondere wenn man mehrere nodebasierte Anwendungen in Betrieb hat. Die Einrichtung ist hier beschrieben: https://www.npmjs.com/package/pm2
PM2 schreibt pro überwachter Node-Anwendung zwei Logdateien, err.log und out.log. Diese sind unter Linux unter /home/username/.pm2/logs zu finden. Wenn eine andere Lokation gewünscht ist, kann dies PM2 bei Start der Anwendung über den --log Parameter entsprechend mitgeteilt werden: pm2 start anwendung.js --log /lokation/meiner/wahl/logs
Das Modul pm2-logrotate wird wie folgt installiert und startet nach der Installation automatisch: pm2 install pm2-logrotate (Achtung: pm2 install nicht npm install!)
Nach einer Eingabe von pm2 status wird das Modul in der Modulübersicht gesondert aufgeführt, inkl. Statusinformation. Als Default verwendet pm2-logrotate für Logdateien bzgl. der Dateigröße ein Limit von 10MB und rotiert täglich 30 Tage lang. Die Konfiguration lässt sich beliebig anpassen und auf Wunsch können ältere Logs auch komprimiert werden - wie das geht ist auf der Projektseite dokumentiert: https://github.com/keymetrics/pm2-logrotate

Happy coding!

Ein Kunde verwendet für die Suchfunktion seines Webportals Apache Nutch zur Indizierung der Inhalte. Es fiel auf, dass plötzlich keine neuen Inhalte mehr erfasst wurden und im Log des entsprechenden Cores /apache-nutch/coreconf/core-xy/log/hadoop.log fand sich folgende Meldung:

2021-02-20 00:11:54,923 INFO api.HttpRobotRulesParser - Couldn’t get robots.txt for https://domainDesKunden/: java.net.SocketException: Socket is closed
2021-02-22 00:11:54,930 ERROR http.Http - Failed to get protocol output

Als Ursache des Problems stellte sich heraus, dass nach einer Aktualisierung der Webserver-Konfiguration der Webserver andere Ciphers für TLS Verbindungen verwendete. Apache Nutch konnte beim Crawlen das Webportal nicht mehr erreichen, weil keine Einigung auf einen gemeinsamen Cipher mehr möglich war. Eine Anpassung der Cipher in der Webserver-Konfiguration beseitigte das Problem. Die Fehlermeldung von Nutch ist an dieser Stelle etwas irreführend, ich hätte hier eine TLSException oder zumindest etwas aussagekräftigeres erwartet.

An dieser Stelle möchte ich den SSL-Konfigurator von Mozilla empfehlen, der oft eine große Hilfe ist: https://ssl-config.mozilla.org

Beim Versuch den IAM-Server per IAM-Client zu kontaktieren kommt folgende Fehlermeldung nach dem Aufruf von

1
const iamClient = await IAMClient.createInstance(clientOptions);

Fehler:

1
2
3
4
5
6
7
{ AggregateError:
RequestError: unable to get local issuer certificate
at ClientRequest.req.once.err (/home/notes/Documents/node-api/DLRWebsucheRestAPI/node_modules/openid-client/node_modules/got/index.js:182:22)
RequestError: unable to get local issuer certificate
at ClientRequest.req.once.err (/home/notes/Documents/node-api/DLRWebsucheRestAPI/node_modules/openid-client/node_modules/got/index.js:182:22)
at rejected (/home/notes/Documents/node-api/DLRWebsucheRestAPI/node_modules/p-some/index.js:49:11)
at process._tickCallback (internal/process/next_tick.js:68:7) name: 'AggregateError' }

Da ich in meiner Anwendung mehrere Schnittstellen zu verschiedenen Services verwende und damit auch mehrere Zertifikate, hat es etwas gedauert, bis die Ursache gefunden war. Da wäre dann eine etwas aussagekräftigere Fehlermeldung (welches cert-file?) hilfreich.

Ursache:

Das verwendete Zertifikat des IAM-Service (in der config.js: iam_server_ca_cert ) enthält keine certificate chain sondern nur das Zertifikat.

Lösung:

Die in der config.js unter iam_server_ca_cert angegebene Datei durch ein File ersetzen, das neben dem Zertifikat auch die certificate chain enthält.

Wenn auf der Domino Konsole Fehler diesert Art

1
2
3
4
[011269:000013-00007F06S339F700] 14.07.2020 16:26:06,53 nti_CipherSpecStringToMask> Ignoring invalid SSLCipherSpec value C014
[011269:000013-00007F06S339F700] 14.07.2020 16:26:06,53 nti_CipherSpecStringToMask> Ignoring invalid SSLCipherSpec value 39
[011269:000013-00007F06S339F700] 14.07.2020 16:26:06,53 nti_CipherSpecStringToMask> Ignoring invalid SSLCipherSpec value C013
[011269:000013-00007F06S339F700] 14.07.2020 16:26:06,53 nti_CipherSpecStringToMask> Ignoring invalid SSLCipherSpec value 35

erscheinen, dann hilft es, wie auf hcltech.com geschrieben, die Cipher-Konfiguration im Serverdokument anzupassen. Das funktioniert wunderbar, wenn die Konfiguration im Serverdokument erfolgt.

Heute hatte ich den Fall, dass der Server Internet-Site Dokumente für die Konfiguration nutzte:

ServerDoc

Also passt ich in allen Internet-Site Dokumenten die Ciphers entsprechend der Anleitung von hcltech an und startet den http task neu in der Erwartung, dass die Meldungen ‘Ignoring invalid SSLCipher..’ nicht mehr angezeigt würden. Dies war jedoch nicht der Fall, die Meldungen erschienen weiterhin.

Lösung:
Wenn im Serverdokument zuvor irgendwann einmal SSL-Ciphers konfiguriert waren, dann stehen diese Werte trotz verwendung von Internet-Site Dokumenten noch immer im Dokument. In meinem Fall habe ich die Werte dann einfach mit dem SIT Dexplorer gelöscht und das Dokument neu gespeichert. Nach einem Neustart des http-task wurden die Meldungen nicht mehr angezeigt.

ServerDoc

Wenn man Nginx als Reverse-Proxy einsetzt, schadet es nicht hin und wieder die Konfiguration zu prüfen und ggfs. zu aktualisieren. Gerade der Reverse-Proxy ist ein Kandidat, der eher gerne übersehen wird, weil er i.d.R. unauffällig und transparent seinen Dienst verrichtet. Während Updates aus dem Softwarerepository regelmäßig installiert werden, muss man die Konfiguration selbst prüfen und ggfs. aktualisieren.
Bei einem von mir geprüften Test-Server, der eher selten genutzt wurde, habe ich die folgenden Punkte in der Konfiguration ergänzt. Die Auflistung erhebt natürlich keinen Anspruch auf Vollständigkeit - wie lange ist es her, dass Sie Ihren Reverse-Proxy überprüft haben?

  1. Prüfen, ob http 2 verwendet wird und wenn nicht http2 ergänzen:

    1
    listen 443 ssl http2;

    Über die Entwicklertools im Browser kann geprüft werden, ob http2 tatsächlich verwendet wird:

    DevTools


2. Hinsichtlich der Sicherheit empfiehlt es sich, seine Website regelmäßig z.B. mit dem SSL Server Test der [SSL-Labs](https://www.ssllabs.com/ssltest) zu prüfen. Nach Eingabe der zu prüfenden Domain erhält man hier nach einer kurzen Wartezeit ein Rating inkl. möglicher Optimierungspunkte.
Wer anstatt eines Ratings einen Fehler erhält bzgl. eines nicht gültigen max-age Wertes, der hat vermutlich HSTS nicht konfiguriert. Eine einfache HSTS Konfiguration kann z.B. so aussehen:

1
2
# Security headers
add_header Strict-Transport-Security "max-age=63072000; includeSubdomains; preload";
Weitere Informationen zur HSTS finden sich u.a. in Mozillas [MDN web docs](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Strict-Transport-Security])

 
3. Als Wert für ssl_protocols verwende ich TLSv1.2 mit den im Folgenden aufgeführten Ciphers.
Vor Poodle und Heartbleed ist man damit sicher, ebenfalls wird weitestgehend auf schwache Ciphers verzichtet. SSL-Labs vergibt hierfür ein A-Rating:

1
2
ssl_protocols TLSv1.2;
ssl_ciphers 'ECDHE-RSA-AES256-GCM-SHA512:DHE-RSA-AES256-GCM-SHA512:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384';

 
4. Um die TLS-Performance von Nginx zu verbessern, kann ein SSL-Session-Cache verwendet werden. Diesen aktiviert man in der Nginx-konfiguration wie folgt:

1
2
3
#SSL-Sessions Cache verwenden
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 1h; # Sessions können 1 Stunde lang wiederverwendet werden

 
5. Zur Reduktion der TTFB (Time to first byte) kann die Buffergröße reduziert werden. Der default beträgt 16k.

1
ssl_buffer_size 4k;

Beim Einrichten der IAMAccessor-ID für das Identity and Access Management (IAM) von HCL Domino 11 bin ich in der Anleitung beim Punkt ‘Create functional ID for IAM’ auf folgendes Problem gestoßen: Beim Anlegen der ID via ‘Register’ im Domino Administrator erschien die Meldung:

ID upload of the Notes ID Vault failed

Folgende Lösung hat mir in diesem Fall weitergeholfen:

  1. In der Vault-DB (zu finden unter IBM_ID_VAULT<vault-name>.nsf den User IAMAccessor löschen.
  2. Auf der Konsole im Domino Administrator folgenden Befehl absetzen:

    load updall -R IBM_ID_VAULT<vault-name>.nsf

Anschließend konnte ich den User IAMAccessor wie in der Anleitung beschrieben anlegen.

Manche kennen vielleicht noch das Human Genome Project aus den 90ern, das sich zum Ziel gesetzt hatte, mittels Distributed Computing das menschliche Genom zu entschlüsseln (das Ziel wurde 2003 erreicht). Im Jahr 2004 startete das Projekt SETI@Home, das Astrophysikern mittels Analyse der gigantischen Datenmengen, welche Teleskope weltweit liefern, bei der Suche nach außerirdischem Leben helfen soll. In etwa zeitgleich wurde damals von der Berkeley University das Projekt BOINC (Berkeley Open Infrastructure for Network Computing) ins Leben gerufen, das es für normale Anwender möglich machte, mittels Distributed Computing Projekte aus unterschiedlichen Wissenschaftsbereichen durch Spenden von Rechenleistung zu unterstützen.

Wer möchte, kann nun im Kampf gegen Sars-CoV-2 (das Coronavirus, das die Lungenkrankheit Covid-19 auslöst) helfen, indem er sich von folding@home den Client herunterlädt und installiert. Anschließend muss man nur noch unter ‘I support research fighting’ den Eintrag ‘any disease’ auswählen. Der Client kann so konfiguriert werden, dass er nur dann, wenn der PC nicht verwendet wird, Berechnungen durchführt, so dass man als Benutzer nicht beeinträchtigt wird. Folding@home ist ein Projekt der Stanford University und des Stanford University Medical Center.

foldingAtHome Screenshot

Endlich habe ich Zeit gefunden meinen Blog zu modernisieren. Viel Spaß!

Solr config

Um Duplikate aus den Suchergebnissen zu entfernen, bietet Solr eine De-Duplication Funktion. De-Duplication in Solr basiert auf der Idee pro Eintrag im Index einen Hash-Wert basierend auf definierten Feldwerten zu erzeugen und diesen dann als Indikator für Duplikate zu verwenden. Das kann sehr nützlich sein, wenn Inhalte über unterschiedliche Urls erreichbar sind - aus Solr-Perspektive sind dies dann zunächst unterschiedliche Inhalte.
Die Einrichtung von De-Duplicate ist einfach: Zunächst muss in der schema.xml des verwendeten Solr-Cores ein neues Feld definiert werden, welches später den Hash enthalten soll:

1
<field name="signatureField" type="string" stored="true" indexed="true" multiValued="false" />

In der solrconfig.xml des Solr-Cores definieren wir als nächstes eine updateRequestProcessorChain, der wir als signatureClass Lookup3Signatur übergeben (das ist ein Hash-verfahren, das performanter als MD5 ist und somit die Crawl-Vorgänge aufgrund der kürzeren Berechnungszeit beschleunigt). Die Felder, über die der Hash gebildet werden soll, definieren wir unter fields und der Hash selbst soll dann in das Feld signatureField geschrieben werden:

1
2
3
4
5
6
7
8
9
10
11
<updateRequestProcessorChain name="dedupe"> 
<processor class="solr.processor.SignatureUpdateProcessorFactory">
<bool name="enabled">true</bool>
<str name="signatureField">signatureField</str>
<bool name="overwriteDupes">false</bool>
<str name="fields">content</str>
<str name="signatureClass">solr.processor.Lookup3Signature</str>
</processor>
<processor class="solr.LogUpdateProcessorFactory" />
<processor class="solr.RunUpdateProcessorFactory" />
</updateRequestProcessorChain>

Die neue updateRequestProcessorChain wird anschließend dem update-requestHandler bekanntgemacht:

1
2
3
4
5
<requestHandler name="/update" class="solr.UpdateRequestHandler" >
<lst name="defaults">
<str name="update.chain">dedupe</str>
</lst>
</requestHandler>

Wenn das nächste mal der Index neu geschrieben oder aktualisiert wird, dann hat jeder neue Eintrag im Index ein neues Feld, welches den Hash beinhaltet, der auf dem Inhalt ‘content’ basiert.
Damit doppelte Einträge aus der Suche verschwinden, muss bei Suchanfragen Gebrauch von der Filterfunktion gemacht werden. Das geht ganz einfach indem an die Url folgender Parameter angefügt wird:

fq={!collapse field=signatureField}

Weitere Informationen finden sich in der Apache Solr Dokumentation.