forum.opsi.org

j.schneider hat geschrieben: Die folgende Version versucht den Ordner zu kopieren, falls das Umbenennen fehlschlägt:
https://download.uib.de/opsi4.1/experim ... .14-1.opsi

Mmh, ich habe noch einige Clients, die das Update nicht gezogen haben.

Aber ein 'experimental'-Paket in produktiver Umgebung!? Zumal der Versionssprung von 11 -> 14 ja auch daraufhin deutet, dass da noch mehr Dinge außer dem copy-Fallback drin sind.

Wäre ein Paket 4.1.1.11-2 möglich, dass nur _diese_ Änderung/Erweiterung hat?

Danke und Gruß
Thomas

Vielen Dank für die Info.
Wie habt ihr denn herausgefunden, dass die betroffenen Clients nicht mehr mit dem Server kommunizieren? Bzw. die betroffenen detektiert?

Z.B. dass 'on_demand' nicht mehr funktioniert oder dass bei einem Neustart "Zuletzt gesehen" nicht aktualisiert wurde.

Hallo,

die wahrscheinlichste Ursache für den verweigerten Zugriff beim Umbenennen ist ein File-Lock in dem Verzeichnis.
Auch wenn im Log des Virenscanners nichts zu finden ist, kann er trotzdem die Ursache dafür sein.
Für weitere Hinweise oder Erklärungsansätze sind wir dankbar.

Die Version in experimental (aktuell 4.1.1.15-2) enthält einen Workaround für dieses Problem und zusätzliche Fixes für Probleme die in speziellen Kundenumgebungen aufgetreten sind.
Sobald wir die Rückmeldung haben, dass der Workaround zuverlässig funktioniert, wandert die Version nach stable.

Grüße
Jan Schneider

Moin,

ich habe nach wie vor leider keine Idee/Ansatz, warum das "rename" teilweise auf diesen Clients fehl schlägt.

Da ich aber gestern einen kleinen Fehler bzgl. meiner Rollout-Skripte gemacht habe, sind wiederum Clients heute Nacht in die Problematik reingelaufen. Bei einem habe ich das wieder manuell gefixt und jetzt mit opsi-client-agent_4.1.1.15-2.opsi erfolgreich ein Update getestet.

Laut logfile schlägt "rename" aber nicht generell fehl! Er kann danach "opsiclientd_bin" erfolgreich nach "opsiclientd_bin_old" umbenennen. Allerdings schlägt die Umbenennung von "opsiclientd_windows_x86" (war in früheren Paketen glaube ich "opsiclientd_bin_new"!?) nach "opsiclientd_bin" mit "Zugriff verweigert" fehl! Danach greift der Fallback mit "Files_copy_opsiclientd_binaries_from_temp".

Noch ein kleiner Schönheitsfehler: es bleibt jetzt "opsiclientd_bin_old" zurück.

Gruß
Thomas

Nochmal kurzes Feedback, habe oben beschriebenes Prozedere jetzt an 6 Clients wiederholt. Überall konnte immer das kopierte Verzeichnis mit dem neuen opsiclientd nicht 'renamed' werden.

Danke für das Feedback.
Wir arbeiten jetzt erst einmal mit dem Workaround weiter.
In einer späteren Version werden wir versuchen an dieser Stelle weitere Informationen über File-Locks im Verzeichnis zu ermitteln und zu loggen.
Dann kann das Problem vielleicht grundsätzlich behoben werden.