Agent signiert mit gesperrter ID

[adminnaddel]

Hallo liebe Gemeinde,

ein agent rotierte jede nacht über docs und verschickte doclinks!
Doch nun ist der Signierer weg und seine ID gesperrt! Seitdem werden keine links mehr verschickt!

Soll ich nun die Db mit meiner ID signieren und ist dann das Problem behoben?

Grüße

[koehlerbv]

Jo. Dann funkt es wieder (wenn Deine Rechte in der DB ausreichen).

Bernhard

[adminnaddel]

okay ... und was hälst du davon ... die server.id zu nehmen, um solche Umstände auszumertzen?

Macht es nicht Grundsätzlich Sinn, Applikationen mit der Server.id signieren zu lassen???

Grüße

[koehlerbv]

Das ist der gängige Weg 

Bernhard

[Semeaphoros]

Was immer "ewig" laufen soll oder als "Systemfunktion" allen Usern zur Verfügung stehen sollte, sollte man mit der ServerID signieren.

[byte]

Im Normalfall  benutzt man  sog. signing ID´s...
High,  Low -  je nach Kriterium für den Verwendungszweck.

Signierungen mit ServerID ist zwar Mode aber  nicht ohne Fehler und Risiko !

Mails die mit einem Agent versendet werden, welcher  mit der ServerID signiert wurd, ist auch  der Absender,  der Server.
Wenn der Server diese Mail aufgrund von Quotas oder anderen Umständen nicht abliefern kann oder der Anwender keinen Platz schaft -  bleibt sie  im nirvana  DEAD liegen.

Drum  sollte man  für versendende  Applikationen   ID´s nehmen, die auch Rückadressierbar sind, wenn  sie Mails versenden. ( Reply - Antworten an )
Sonst könnte mal ein Projektplan oder anderes, was tierisch wichtig ist, viel  Arbeit verursachen, um zu  beweisen, daß sie nicht ankam...

Drum -   eigene Signing ID´S  für Agenten  die auch   Mailinfunktionen haben :

Low für restricted und High für unrestricted Agents

Dann könnte  z.b.  die Signierung für eine Appl folgendermaßen aussehen:
Posterversand Management/Agent/High/Blab/BLa
Posterversand Management/Agent/Low/Blab/BLa

run restr-  Agents:  */Agent/Low/Blab/BLa
run unrestr-  Agents:  */Agent/High/Blab/BLa

Aber Server ID zur Signierung -  davon würde ich  pers. gesehen  schon aus sicherheitstechnischen Gründen absehen, wenn die Server.id im Data Dir  liegt - wie es zu 95 %  immer der Fall ist ;-)