Beiträge von RockWilder

    Weiß ich nicht, ob man über die API dran kommt. In scanEz sieht man das auch nicht, was entweder heißt, sie haben es nicht implementiert, oder man kommt wirklich nicht dran.


    Abhilfe: im QueryDocumentDelete- oder im PostDocumentDelete-Event etwas "nachbessern"

    Wenn du einen Dienstleister anheuerst, der das für dich übernehmen soll, musst du ihm auch soweit vertrauen ;)
    Und wenn der Dienstleister was taugt, kann er selbst rausfinden, ob eine DB verschlüsselt ist, oder nicht. Dafür braucht es dann aber nunmal einen Client, oder zumindest ein paar der DLLs. Das wiederum sollte für einen Dienstleister, der sich in diesem Bereich bewegt, kein Problem darstellen.


    Davon ab: wenn du dem Dienstleister eine ID rechnest, die ganz bewusst keinen Zugriff auf irgendwas hat, kann auch Weg 3 (C-API "NSFDbIsLocallyEncrypted") gegangen werden. Entweder die ID bekommt einen "ist verschlüsselt"-Fehler zurück oder einen "Du kommst hier nit rein!"-Fehler.


    Oder aber du nimmst deinem Dienstleister die Arbeit ab (lol?), prüfst selbst alle DBs und gibst ihm dann nur eine Liste der DBs, die er anfassen soll. Alle anderen lässt er in Ruhe.

    ${data_dir}/workspace/.metadata/.plugins/org.eclipse.core.runtime rekursiv nach "logviewer" (oder ähnlichem, probier es aus) grep-pen. Irgendwo müsstest du Treffer haben und mit "Hide_$deintreffer=true" oder "HIDE_PANEL_$deintreffer=true" müsstest du die Sidebar auch wieder wegbekommen können.

    Du kannst auf Umwegen dahinkommen:
    - füge deinen Dokumenten ein weiteres (hidden) Item hinzu: "is_allowed_to_modechange" (oder ähnlich). Default value: "0"
    - erstelle einen Button "Edit" (oder ähnlich)
    - binde ihn in deine View ein
    - - Inhalt: das Item wird im fraglichen Dokument auf irgendeinen Wert gesetzt, z.B.: @SetField("is_allowed_to_modechange"; "1"). Danach wird mit @Command([EditDocument]) versucht, das Dokument im Bearbeitungsmodus zu öffnen
    - Die Property notesUIDocument.InPreviewPane kann dir evtl. gute Dienste leisten.


    Das ganze kombinierst du mit dem QueryModeChange-Geraffel, das bereits besprochen wurde und erweiterst es dahingehend, dass "Continue = False" nur dann ausgeführt wird, wenn das Item "is_allowed_to_modechange" nicht auf "1" steht (oder was auch immer du dir für Mechanismen und Bezeichner ausdenkst). Gut möglich, dass du da etwas nachschärfen musst, das ist jetzt einfach nur aus der hohlen Hand skizziert.


    Unterm Strich ist das aber alles nur snake oil! In dem Augenblick, in dem ein User Bearbeiterrechte hat (ACL, Autorenfelder), kann er ein Dokument völlig losgelöst von Strg+E, einem Button oder sonstwas bearbeiten. Soll ein User nicht bearbeiten können, wirst du um eine vernünftige ACL und ggf. Autorenfelder nicht herumkommen.

    Ich hatte vergessen zu sagen, das ich das Connections 6 auf eine Windows-Server installieren möchte ... auf der Seite werden nur Informationen zu Linux-Installation angeboten ...

    Ach, ist das so?


    user@host:~> wget -q https://www.ibm.com/support/kn…l_cluster.html?view=embed -O- | grep -ci windows
    23


    Gleich zu Beginn des Artikels wird auf den Artikel "Vor der Installation" verlinkt:
    user@host:~> wget -q https://www.ibm.com/support/kn…nstalling.html?view=embed -O- | grep -ci windows
    4


    Und nach "c:\" habe ich da noch gar nicht gegrept (oder ".bat", oder ".exe")...


    Bist du sicher, dass wir a) vom selben Artikel reden und b) du diesen Artikel von A bis Z durchgelesen und ehrlich versucht hast, ihn nachzuvollziehen?

    Ich wüßte sonst nicht, wie ich es anders erklären sollte.

    Im Zweifel so, wie es auch im Bild beschrieben ist; vllt. noch ein Stück weit strukturierter.
    Das Hauptproblem scheint mir aber zu sein, dass deine F1-Taste kaputt zu sein scheint. Du schreibst, du weißt, dass das mit der Hide-When-Formel so nicht passt. Stimmt: passt nicht. Und exakt an der Stelle kommt die magische F1-Taste ins Spiel. Würde sie funktionieren und hätte man sie benutzt, hätte man durchaus @UserRoles nachschlagen und die Beispiele im Grunde 1:1 übernehmen können. Gleiches gilt für @IsNewDoc.
    Bitte behalte neben den von Torsten erwähnten Problemen mit der Auffindbarkeit zudem immer im Hinterkopf, dass ein Forum Hilfe zur Selbsthilfe ist. Du willst das Problem sicherlich nicht nur gelöst, sondern auch verstanden haben. Und das bedeutet nicht eine fertige Lösung hingestellt zu bekommen, sondern sich aus den Antworten selbst etwas zu erarbeiten. Damit das Problem zukünftig keines mehr ist.


    Ich denke nur, so kann ich es am besten verständlich machen.
    Frage mich nur, warum man dann überhaupt ein pdf hochladen kann?

    Wieso nur ein einem PDF verständlich beschreiben, und nicht hier im Forum? Was macht den Unterschied aus? Das Problem sortieren und dann verständlich und strukturiert in die Tastatur hämmern musst du in beiden Fällen.
    Man kann auch .zip hochladen. Deiner Argumentation zufolge, könnte man auch seinen Namen töpfern und das Problem tanzen, das Video davon dann zippen und hier einstellen. Wäre mal was neues....


    Du hast jetzt zwei Einsteigspunkte für die Suche nach einer Lösung, damit sollte sie sich einfach und problemlos erarbeiten lassen. Wenn dazu Fragen auftauchen: strukturiert formuliert hier einstellen (direkt ins Forum, nicht den Umweg über das gezippte Video gehen), dazu sämtliche bis dahin unternommenen Lösungsansätze beschreiben und benennen, was davon nicht funktioniert und welche Fehler an welcher Stelle geworfen werden. Danke!

    Ist im Grunde nicht weiter schwierig zu verstehen:
    - Task 1 läuft los, legt das Dokument an, setzt den Wert. Task 2 läuft irgendwann auch an, sieht das Dokument, legt sich schlafen.
    - Wenn Task 1 anläuft, das Dokument anlegt und warum auch immer nicht mehr dazu kommt, es wieder zu löschen, kann Task 2 solange nicht anlaufen, bis du dich darum gekümmert hast.
    - Da Task 2 wohl abhängig von der korrekten Ausführung und Beendigung von Task 1 ist, kann er keine Daten verhunzen.


    Den Fehler zu erkennen, ihn zu bewerten und entsprechend danach zu handeln, das ist der Job des Administrators.

    Wenn du ausschließlich die stärkeren ciphers nutzt, sollte das klappen => TLS Cipher Configuration


    Als Beispiel wird "SSLCipherSpec=9F9E6B39679D9C3D353C2F0A" genannt, das macht für den Anfang einen brauchbaren Eindruck und von da aus kann man sich weiterhangeln


    Ich würde aber davor warnen, nun in operative Hektik zu verfallen. Zum Einen ist ROBOT seit gut zwei Wochen wieder akut (am 12. oder 13. hat heise es gemeldet) und die Welt ist wider Erwarten immernoch nicht untergegangen. Zum Anderen sind solcherlei Drohgebärden ("Deinen Server halten wir nicht für sicher, deswegen blacklisten wir ihn ab Februar") mit Vorsicht zu genießen: auf der einen Seite stecken immer Interessen hinter den Anbietern und ihren mehr oder weniger fundiert geäußerten Warnungen und andererseits würde vermutlich mit einem Schlag das halbe Internet abgeklemmt werden, sollten diese Hosts in irgendeiner Form gesperrt, geblacklistet oder sonstwie mit den Fingern auf sie gezeigt werden. Also lieber erstmal in aller Ruhe den Sachverhalt analysieren und die eigene Umgebung evaluieren. Vor 19 Jahren hat es keine Katastrophen gegeben; ob es diesmal anders läuft oder ob es doch wieder nur die neueste Sau auf dem Dorfplatz ist, das wird sich erst noch zeigen müssen.


    Und wenn alle Stricke reissen: tja, dumm gelaufen! Solange IBM keine andere cipher lists einbaut, müssen wir mit dem leben, was da ist und nicht mit dem, was wir uns wüschen. Davon einmal abgesehen zeigt sich an ROBOT eigentlich sehr gut, dass es nicht ausschießlich der Algorithmus ist: vieles hängt davon ab, ob und wie sauber er implementiert ist.

    Zunächst einmal: von welchem RFC sprechen wir? 821 oder 5321? SMTP wird in verschiedenen RFCs besprochen und erweitert. Davon abhängig ist, was erlaubt ist, was empfohlen ist und was gar nicht geht.
    Ein leeres <Mail From:> ist an und für sich erstmal eine suboptimale Idee. Kann man machen, funktioniert in der Regel auch, kann und wird im Problemfalle aber auch auf die Füße fallen.


    Einer der Problemfälle ist, wenn das empfangende System sich (aus guten Gründen) weigert, solche Mails anzunehmen, da es Spam vermutet, oder auf exakt diese Information angewiesen ist, um sicherzustellen, dass die Mail auch wirklich "authentisch" ist und nicht von irgendeinem Skriptkiddie mit seinem Virenbaukasten zusammengefrickelt wurde. Das ist aus heutiger Sicht natürlich Augenwischerei, heutzutags hat man dafür zwar u.a. DKIM, SPF et al. Damals(TM) war es aber Stand der Dinge, sicherlich auch darin begründet, dass es "damals" weit weniger Skriptkiddies gab, die nichts weiter als Blödfug im Kopf haben X( geschweige denn Zugriff auf einen Rechner mit Zugang nach draußen (RFC 821 ist von Anfang der 80er Jahre, da war selbst an einen A500 noch nicht zu denken).


    Ich persönlich würde meine Systeme grundsätzlich so konfigurieren, dass es derart verhunzte Mails abweist. Wenn ein wie auch immer gearteter Mechanismus (Server oder PEBCAK) nicht in der Lage ist, korrekt formatierte Mails zu generieren, dann stimmt da mit einiger Wahrscheinlichkeit etwas nicht; da wäre ich zumindest mal skeptisch.


    Wenn eure automatisch generierten Mails (und was anderes ist eine per Agent/Regel weitergeleitete Mail im Grunde nicht) also ein Problem mit den Headern haben, würde ich lieber da ansetzen, als an den Relais rumzukonfigurieren. Diese Mails sollten in ihren Headern den Namen der ID haben, unter der der Agent läuft, oder im Falle von server mail rules sollte da der Servername drinstehen. Letzteres aber funktioniert nur zuverlässig, wenn das Config-Dokument korrekt befüllt ist.

    Ich frage mich, wie die restlichen Header des Verbindungsaufbaus aussehen.
    Wenn nämlich der Client ein EHLO an den remote Mailserver sendet mit dem FQHN des Servers, dann ist es gut möglich, dass das nicht tut: der remote Mailserver weist den Verbindungsaufbau hoffentlich ab, weil er so konfiguriert ist, dass er keine Verbindungen annimmt von Gegenstellen, die sich mit fremden Namen melden.

    //edit:
    da kam ich leicht zu spät, ein paar der folgenden Fragen hast du gerade beantwortet


    Wie sieht der notes://-Link im Detail aus?
    notes://servername/replica-id/view-id/doc-id oder notes://vollqualifizierter.host.name/replica-id/view-id/doc-id


    Auch möglich, dass zwar euer DNS tut ("neuerhost.name" wird aufgelöst), aber NetBIOS nicht (richtig), weswegen dann "neuerhost" (noch) nicht aufgelöst wird.


    Die server decommission sollte eigentlich nur der allerletzte Ausweg sein. Normal baut man auch kein neues Haus, wenn man das alte einfach neu anstreichen könnte ;-)
    Damit sollte es dann zwar auf jeden Fall tun, ist allerdings auch nicht unbedingt in 5 Minuten erledigt und kann natürlich auch noch andere Nigglichkeiten nach sich ziehen......


    Kannst du sowohl
    - NeuerServer/Org
    - NeuerServer
    - neuerhost.name
    - neuerhost
    fehlerfrei vom Client aus tracen? Was exakt sagt die client-eigene Namensauflösung?
    Für die letzteren beiden Fälle: versuch das Selbe mal in einer DOS-Box => was passiert?


    Was passiert, wenn du den notes://-Link in die Adresszeile des Client wirfst?
    Was exakt siehst du auf dem Server (ggf. Loglevel hochdrehen), und (nur für alle Fälle) kannst du den Netzwerkverkehr mitschneiden?

    Wie soll das denn funktionieren? Wenn du jemandem nach den Weg fragst und er antwortet dir, dass du gleichzeitig nach links und nach rechts gehen sollst, um wievieles schlauer bist du dann?


    Ihr habt nun mehrere Möglichkeiten:
    - ihr bekommt eure Verbindungsdokumente auf die Reihe. Und das bedeutet auch, dass ihr euch sämtliche Felder anschaut und ggf. bereinigt. Alle. Ausnahmslos.
    - ihr setzt einen zweiten Server auf, der alte behält den alten FQDN, der neue läuft unter dem neuen. Dann lest ihr euch in der Hilfe durch, wie man einen Server decommissioned.
    - ihr bekommt eure Namensauflösung und ggf. das Routing im Netzwerk auf die Reihe.

    Was meinst du mit "über -> (neuer|alter) Hostname"? Meinst du damit Passthru-Verbindungsdokumente? Wenn ja: mach direkte Verbindungsdokumente draus:
    - neuerNotesSrv/Org => 192.168.0.1
    - alterNotesSrv/Org => 192.168.0.1


    Weiters werden Verbindungsinformationen, insbesondere die IP/der DNS-Name vom Client in versteckten Feldern gecachet. Wenn ihr das alte Verbindungsdokument einfach nur umgeschrieben habt, schau dir die Felder mal an. Am einfachsten machst du einfach komplett neue.


    Habt ihr das alte Serverdokument im DD gelöscht, oder existiert es noch (solange die Transition läuft)?
    Wenn der alte Server parallel zum Neuen noch mitläuft: habt ihr die geclustert und haben sich die Clusterinformationen zu den Clients durchgefressen?