Bereiche
News
Rewind
Tipps & Berichte
Forum
Galerie
Journals
Events
Umfragen
Themenwoche
Kleinanzeigen
Interaktiv
Anmelden
Registrierung
Zu allen empfangenen Nachrichten
Suche...
Zur erweiterten Suche
Push-Nachrichten von MacTechNews.de
Würden Sie gerne aktuelle Nachrichten aus der Apple-Welt direkt über Push-Nachrichten erhalten?
Forum
>
Software
>
Apples neuer XProtectUpdater und MacDefender...
Apples neuer XProtectUpdater und MacDefender...
sierkb
04.06.11
20:45
Apple scheint sich da gerade ein "Hase und Igel"-Spiel mit den Malware-Schreibern zu leisten bzw. darin verwickelt zu sein.
Apples XProtect.plist ist mittlerweile bei Version 5 angelangt (also bereits 4 Apple Updates seit Bestehen dieser neuen Funktion), alle paar Stunden gibt's da seitens Apple derzeit ein neues Update zum Abholen. Alle paar Stunden wird eine neue MacDefender-Variation geboren, eine davon treibt derzeit u.a. bei Facebook ihr Unwesen und versucht sich zu verbreiten. Mittlerweile gibt's auch schon Variationen, die manche als MacDefender.E, MacDefender.F und MacDefender.G bezeichnen. Apples XProtect hat bisher die Signaturen bis MacDefender.E.
Apple verwendet zudem etwas andere Signaturen als verschiedene AV-Software-Hersteller, muss offenbar auch öfters updaten. Die derzeit in den Netzen rumwandernden MacDefender-Variationen werden von anderen AV-Software-Herstellern zum großen Teil bereits durch frühere Signaturen erkannt, welche vorausschauenderweise ein breiteres Spektrum an Variationen pro Signatur abdecken, sodass es auf deren Seite diesbzgl. derzeit weniger Anlass gibt, ständig mit den Signatur-Updates hinterherzuhecheln, so wie Apple es grad' wohl tun muss.
Clamav z.B. deckt mit seinen bisherigen Signaturen MacDefender.A bis MacDefender.C auch die gerade kursierenden Erscheinungsformen von MacDefender ab und erkennt sie, welche andere und insbesondere Apple derzeit als MacDefender.E und MacDefender.F klassifizieren (müssen).
Wer Apples voreingestelltem 24-Update-Rythmus vertraut, der bekommt davon wohl nix mit, und der wartet im ungünstigsten Fall ewig auf Apples Updates, weil er, wenn es ungünstig läuft, genau dann, wenn das Update von launchd angestoßen werden soll, nicht online ist (z.B. beim Hochfahren des Rechners oder bei Laptops, die nicht sofort eine Internetverbindung haben, wenn sie hochfahren).
Also im Moment wohl besser mal ab und zu häufiger das Ganze
manuell
anschieben im Terminal und von einem Admin-Account aus mittels
sudo /usr/libexec/XProtectUpdater
mit ggf.
sofortigem
Ergebnis und sofortiger Änderung der XProtect-Liste, sollte Apple diesbzgl. was bereitstellen.
Bin mal gespannt, wie lange dieses Spiel noch weitergeht, das Apple Security-Team dürfte im Moment jedenfalls ganz gut zu tun haben, ständig alle paar Stunden neue Updates für die XProtect.plist raushauen zu müssen...
Vielleicht ist der in MacOSX voreingestellte Rythmus für die automatischen Updates von 24 Stunden unter diesen Umständen doch etwas zu groß und unpraktisch bemessen und sollte verkleinert bzw. auf mehrere Zeitfenster pro Tag verteilt werden, um die Chancen zu erhöhen, dass die Anwender diese Updates auch rechtzeitg und vor allem frühzeitig genug bekommen...
Hilfreich?
0
Kommentare
1
2
>|
Laphroaig
04.06.11
21:01
Sehr interessant. Danke für die Info.
Hilfreich?
0
Esprit
04.06.11
21:10
Krass...
Hilfreich?
0
sierkb
04.06.11
21:19
Laut
bzw.
:
Das Sophos-Blog "Naked Security" schreibt, dass die Schadsoftware auch über Facebook-Links zu vermeintlichen Sexvideos verteilt wird – je nach Browserkennung liefert die Zieladresse dann entweder einen Mac- oder Windows-Trojaner aus.
Allerdings ist diese Meldung auch schon etwas älter und von vorgestern (02. Juni), da sind derzeit ganz bestimmt noch ganz andere Varianten in Umlauf und in der Mache ...
Hilfreich?
0
MacMark
04.06.11
23:01
sierkb
Wer Apples voreingestelltem 24-Update-Rythmus vertraut, der bekommt davon wohl nix mit, und der wartet im ungünstigsten Fall ewig auf Apples Updates, weil er, wenn es ungünstig läuft, genau dann, wenn das Update von launchd angestoßen werden soll, nicht online ist (z.B. beim Hochfahren des Rechners oder bei Laptops, die nicht sofort eine Internetverbindung haben, wenn sie hochfahren).…
Der XProtectUpdater wird von launchd kontrolliert. In diesem konkreten Fall läuft XProtectUpdater, sobald er (mit den anderen Dämonen) nach dem Hochfahren geladen wird und alle 24 Stunden. Wird ein Termin verschlafen, wird er beim Aufwachen nachgeholt. Die Internetverbindung wird aufgebaut, falls sie noch nicht steht – genau wie eine aufgebaut wird, wenn Safari eine benötigt, aber noch keine besteht.
Um falsche Positive zu vermeiden, nutzt Apple nach meinem Kenntnisstand "straight hashes". Ihnen ist anscheinend wichtig, keinen Fehlalarm zu liefern. Im Gegensatz zur "AV-Industrie".
„@macmark_de“
Hilfreich?
0
MacMark
04.06.11
23:11
Und wenn Dir einmal täglich zu wenig ist, dann würde ich die Konfiguration des Dämons ändern auf das Intervall Deiner Wahl.
„@macmark_de“
Hilfreich?
0
sierkb
04.06.11
23:13
MacMark
Wird ein Termin verschlafen, wird er beim Aufwachen nachgeholt.
Nein, wird er eben NICHT! Darüber berichten auch inzwischen mehrfach einige Seiten im Web, und auch unter discussions.apple.com ist das auch Thema, dass einige Benutzer inzwischen KEIN Update bekommen haben, obwohl sie es ihrer Meinung nach eigentlich hätten bekommen müssen.
Abgesehen davon: eine entsprechende Einstellung in der betreffenden launchd Plist-Datei, die das bewirken könnte, fehlt.
Die Internetverbindung wird aufgebaut, falls sie noch nicht steht
Unwahr. Das kann z.B. gar nicht gehen bei Benutzern, die per UMTS-Surfstick unterwegs sind und eine Online-Verbindung beim Start dieses launchd-Skriptes noch gar nicht bestehen kann bzw. erst ein paar Sekunden oder Minuten später aufgebaut wird. Entsprechende Fehlermeldungen, die einen solchen Fehlversuch protokollieren, stehen auch dann belegbar im System-Logfile drin. Und nachgeholt wird da nix. Erst in 24 Stunden wieder -- in der Hoffnung, dann eine Online-Verbindung vorzufinden.
Um falsche Positive zu vermeiden, nutzt Apple nach meinem Kenntnisstand "straight hashes". Ihnen ist anscheinend wichtig, keinen Fehlalarm zu liefern. Im Gegensatz zur "AV-Industrie".
Fangen wir jetzt schon wieder das Schönreden und das Verklären der Tatsachen an?
Hast Dich schon mal direkt mit einem unterhalten, der u.a. zuständig ist für solche Signatur-Updates bzw. selber schon welche eingereicht hat? Ich schon.
Hilfreich?
0
sierkb
04.06.11
23:16
MacMark
Und wenn Dir einmal täglich zu wenig ist, dann würde ich die Konfiguration des Dämons ändern auf das Intervall Deiner Wahl.
Was erzählst Du das mir? Erzähl' das dem normalen Durschnitts Mac-User da draußen bzw. frag' Apple, warum die das nicht gleich von vornherein auf ein kleineres Intervall eingestellt haben! U.a. auch deshalb, weil diese Entwicklung, wie sie sich da grad' vollzieht, dieses "Hase und Igel"-Spiel schon fast nur nach gesundem Menschenverstand absehbar und erahnbar gewesen ist und schon bei Erscheinen von Apples Security-Update verschiedentlicherseits genau solche Voraussagen bzgl. eines zu erwartenden "Hase und Igel"-Spiels gemacht worden sind.
Hilfreich?
0
sierkb
04.06.11
23:31
Um falsche Positive zu vermeiden, nutzt Apple nach meinem Kenntnisstand "straight hashes". Ihnen ist anscheinend wichtig, keinen Fehlalarm zu liefern. Im Gegensatz zur "AV-Industrie".
Oder die von Dir in Tüdelchen verfasste AV-Industrie hat einfach mehr Erfahrung und Weitblick auf diesem Gebiet und richtet ihre Signatur so aus, dass sie eine solche Malware etwas besser abdeckt als Apples Signatur, indem sie gleich einkalkuliert, dass einzelne kleinere Änderungen (und seien sie auch noch so klein) an der betreffenden Malware eine zu zielgenaue Signatur obsolet machen. Gerade in Diskimages (.dmg) und Packages (.pkg) ist für sowas sehr viel Spielraum. Einmal die Info.plist eines solchen Packages ein wenig verändert, und schon ist die zu zielgenaue ausgerichtete Signatur bzw. der Hashwert hinfällig. Kann man auch schön erkennen, wenn man mal die XProtect.plist öffnet, wie Apple sich da langsam vorarbeitet und einzelne Bestandteile der Malware versucht abzutasten (und im Grunde dadurch vorführen lässt von den Malware-Schreibern): Info-plist, Bom-Datei, postinstall-Datei etc. pp. Alles bekommt von Apple eine eigene Aufmerksamkeit. Statt das gleich alles vorausschauenderweise im Verbund mit einer einzigen Signatur bzw. weniger Signaturen zu erschlagen.
Die AV-Industrie bzw. die Jungens und Mädels, die sich damit seit Jahren bereits beschäftigen, die sind geübt darin, entsprechend vorzubauen und solche Minimaländerungen einzukalkulieren und vorauszusehen. Apple betritt auf diesem Gebiet die eigene Erfahrung betreffend grad' absolutes Neuland und tabbst da eher noch etwas unbeholfen durch die Lande. Und macht sicherlich ein paar Anfängerfehler und neue Erfahrungen, die die etablierte AV-Industrie ihnen durch jahrelanges Training voraushaben.
Hilfreich?
0
Zacks
04.06.11
23:40
➜sierkb
Die Sache scheint dich ja zu wurmen wie keinen anderen
„Ware wa messiah nari!“
Hilfreich?
0
sierkb
04.06.11
23:43
Zacks
➜sierkb
Die Sache scheint dich ja zu wurmen wie keinen anderen
Mich wurmt das Schöngerede von MacMark und der Dillentantismus von Apple, insofern hast Du recht, ja.
Hilfreich?
0
Phoen
04.06.11
23:54
sierkb
+1
„Niemand regiert die Welt.“
Hilfreich?
0
Zacks
05.06.11
00:26
Wenn es nur mal mehr Leute so wurmen würde aber ich denke mal dazu muss es wohl erst richtig knallen …leider
„Ware wa messiah nari!“
Hilfreich?
0
Zacks
05.06.11
03:34
Bin grade mal über so eine lustige Seite gestolpert, die einem MacProtector andrehen möchte und das nichtmal beim suchen von irgendwas besonderem, sondern nur nach Wallpapern!
Mein erster Gedanke: ORLY?
Um einen Normaluser zu verunsichern/täuschen, reicht das aber echt aus
Naja, hier für alle Interessierten mal ein Screencap davon ➜
Die Infos hinter der IP sind auch recht interessant…
„Ware wa messiah nari!“
Hilfreich?
0
ma.
05.06.11
06:16
Das Update manuell anstoßen:
"Automatisch Liste mit sicheren Downloads aktualisieren" deaktivieren, dann wieder aktivieren.
Da findet man die XProtect.plist:
System > Library > CoreServices
Paketinhalt von CoreType.bundle zeigen
Content > Resources
Hilfreich?
0
MacMark
05.06.11
06:45
sierkb
MacMark
Wird ein Termin verschlafen, wird er beim Aufwachen nachgeholt.
Nein, wird er eben NICHT! …
Natürlich wird er das. So funktioniert launchd.
sierkb
Abgesehen davon: eine entsprechende Einstellung in der betreffenden launchd Plist-Datei, die das bewirken könnte, fehlt.
Quark. Das automatische Nachholen ist ein implizites Feature von StartInterval, was dort enthalten ist.
sierkb
MacMark
Die Internetverbindung wird aufgebaut, falls sie noch nicht steht
Unwahr. Das kann z.B. gar nicht gehen bei Benutzern, die per UMTS-Surfstick unterwegs sind…
Wenn man den Akku rausnimmt, geht es auch nicht.
sierkb
MacMark
Um falsche Positive zu vermeiden, nutzt Apple nach meinem Kenntnisstand "straight hashes". Ihnen ist anscheinend wichtig, keinen Fehlalarm zu liefern. Im Gegensatz zur "AV-Industrie".
Fangen wir jetzt schon wieder das Schönreden und das Verklären der Tatsachen an?
Ich kläre nur Deine Nebel.
sierkb
Hast Dich schon mal direkt mit einem unterhalten, der u.a. zuständig ist für solche Signatur-Updates …
Ja, über die hierfür von Apple verwendeten Signaturen vor drei Tagen mit einem, der AV-Software schreibt und damit seinen Lebensunterhalt verdient.
„@macmark_de“
Hilfreich?
0
Zauberlehrling
05.06.11
08:15
MacMark
sierkb
MacMark
Wird ein Termin verschlafen, wird er beim Aufwachen nachgeholt.
Nein, wird er eben NICHT! …
Natürlich wird er das. So funktioniert launchd.
Bei mir und vielen Anderen tut es das eben nicht.
lt. macobserver.com
ist im Update-System ein Bug.
Man muß einmal in den Systemeinstellungen das automatische Updaten aus- und wieder einschalten. Dann soll es wieder funktionieren.
Dort findet man auch ein kleines App um die Version der xprotect.plist abzufragen und bei bedarf zu aktualisieren.
Hilfreich?
0
sunni
05.06.11
09:27
Ich denke die allereinfachste Variante sich dagegen zu wehren ist wohl, dem Safari zu verbieten die "Sicheren" Dateien nach dem Laden automatisch zu öffnen.
Dann öffnet sich auch keine Image Datei und startet automatisch den Installer von MacDefender.
Man muss den doch immer noch per Hand bestätigen oder?
Hilfreich?
0
MacMark
05.06.11
09:37
Zauberlehrling
…
Bei mir und vielen Anderen tut es das eben nicht.
lt. macobserver.com
ist im Update-System ein Bug.
Man muß einmal in den Systemeinstellungen das automatische Updaten aus- und wieder einschalten. Dann soll es wieder funktionieren.
…
Ihr verwechselt da ein paar Details: Da wird anscheinend die Preferences-Einstellung nicht übernommen, die den Dämon generell ein- oder ausschaltet. Ist er jedoch eingeschaltet, dann läuft er zuverlässig dank launchd wie oben beschrieben. Als einfach nochmal nachsehen, ob der Haken bleibt.
„@macmark_de“
Hilfreich?
0
ts
05.06.11
09:45
MacMark
sierkb
MacMark
Wird ein Termin verschlafen, wird er beim Aufwachen nachgeholt.
Nein, wird er eben NICHT! …
Natürlich wird er das. So funktioniert launchd.
[/quote]Aha. Mein Rechner ist dauernd im Netz, läuft auch öfter über Nacht durch/ist nachts im Ruhezustand. Das System ist auch nicht wirklich modifiziert, nur einige Zusatzprogramme wurden nach /opt installiert. Der Haken beim automatischen Aktualisieren ist natürlich gesetzt.
Kleiner Ausschnitt aus XProtect.meta.plist auf meinem System:
<key>LastModification</key>
<string>Wed, 01 Jun 2011 21:19:15 GMT</string>
<key>Version</key>
<integer>2</integer>
Haben wir heute den 1. Juni? Gibt es da schon neuere Versionen?
Hilfreich?
0
ts
05.06.11
09:51
Kleiner Nachtrag: Nach „sudo /usr/libexec/XProtectUpdater” hat mein System nun die Version 5. Haken weg und neu setzen hatte keine Auswirkung.
Hilfreich?
0
Zauberlehrling
05.06.11
09:56
Der Haken ist gesetzt es wurde aber trotzdem nicht aktualisiert.
Es ist also für einen Laien nicht ersichtlich ob das jetzt funktioniert oder nicht.
Wenn Apple da was als Sicherheitsupdate installiert geht man in der Regel davon aus das es geht.
Tut es aber bei mir jedenfalls nicht.
Hier klaffen Theorie und Praxis weit auseinander.
Hilfreich?
0
MacMark
05.06.11
11:14
Es muß schon irgendwas bei Dir sein, denn sonst hätten alle das Problem, nicht wahr?
„@macmark_de“
Hilfreich?
0
MacMark
05.06.11
11:30
Was liefert bei Dir dies?
sudo launchctl list | grep protect
„@macmark_de“
Hilfreich?
0
camaso
05.06.11
11:45
Habe eben den Haken raus und wieder rein gemacht und schwups: MacDefender.E ist drin. Ob das Update auch von selbst gekommen wäre, weiss ich damit natürlich nicht. Gibt es irgendwo eine Log-Datei, in welcher steht, wann die Updates bisher liefen?
Hilfreich?
0
ts
05.06.11
11:52
MacMark
Es muß schon irgendwas bei Dir sein, denn sonst hätten alle das Problem, nicht wahr?
Was ist, wenn Probleme nur unter bestimmten Voraussetzungen auftreten?
sudo launchctl list | grep protect
bietet mir
- 255 com.apple.xprotectupdater
Hilfreich?
0
sierkb
05.06.11
12:12
MacMark
Natürlich wird er das. So funktioniert launchd.
Nein, so wie Du es darstellst, funktioniert launchd NICHT! Und in diesem Fall erst recht NICHT. Hör' endlich auf, den Leuten so einen Schafscheiß zu erzählen!
MacMark
Quark. Das automatische Nachholen ist ein implizites Feature von StartInterval, was dort enthalten ist.
Nein, ist es NICHT. Siehe zuvor Gesagtes. Nicht nur, dass ich überall im Netz bestätigt werde mit dem was ich sage, ich weiß in diesem Fall SEHR genau, was ich sage. Weil ich derzeit nämlich mit einem Surfstick unterwegs bin und das Ganze SEHR genau mitbekomme, ob und wann und wann nicht dieser launchd Job erledigt wird. Und mein Rechner ist auch lange genug online, um mitzubekommen, ob und wann was nachgeholt wird oder nicht!
Und wie gesagt: meine Beobachtungen werden im Netz haufenweise bestätigt!
MacMark
Wenn man den Akku rausnimmt, geht es auch nicht.
Du bist echt ein hirnverbrannter Idiot, weißt Du das?!
Da platzt einem aber echt langsam der Arsch bei Dir!
MacMark
Ich kläre nur Deine Nebel.
Nein, ich kläre DEINE Nebel. Du erzählst absoluten Blödsinn!
MacMark
Ja, über die hierfür von Apple verwendeten Signaturen vor drei Tagen mit einem, der AV-Software schreibt und damit seinen Lebensunterhalt verdient.
Ich ebenso. Gestern. Im Zweifel kann ich den betreffenden email-Verkehr sogar belegen. Mache ich sogar gerne öffentlich.
Hilfreich?
0
sunni
05.06.11
12:19
sierkb
MacMark
Auch wenns ein heikles Thema ist, könntet ihr euch bitte woanders batteln?
Macht den Thread sonst nicht besonder interessant.
Hilfreich?
0
MacMark
05.06.11
12:44
sierkb
MacMark
Natürlich wird er das. So funktioniert launchd.
Nein, so wie Du es darstellst, funktioniert launchd NICHT! Und in diesem Fall erst recht NICHT. …
MacMark
Quark. Das automatische Nachholen ist ein implizites Feature von StartInterval, was dort enthalten ist.
Nein, ist es NICHT. Siehe zuvor Gesagtes. …
Es ist so, wie ich es sage. So funktioniert es in meiner Praxis und so ist es auch von Apple dokumentiert.
„@macmark_de“
Hilfreich?
0
_mäuschen
05.06.11
12:47
ups…
Ich steh auch auf lauch…ehh gebe MacMark Recht
Hilfreich?
0
sierkb
05.06.11
12:48
Zauberlehrling
Man muß einmal in den Systemeinstellungen das automatische Updaten aus- und wieder einschalten. Dann soll es wieder funktionieren.
Der Schalter deaktiviert den XProtect daemon, wenn er abgehakt wird und aktiviert ihn sofort wieder, wenn er angehakt wird.
Beziehungsweise, so SOLL es eigentlich sein, Apple hat da aber derzeit einen Bug drin, das bleibt u.U. wirkungs- und folgenlos und ohne Änderungen in der betreffenden PList-Datei, wenn man nicht schnell genug ist und vor allem das Panel und das Schloss wieder rechtzeitig schließt. Entsprechende Berichte, die sich nachvollziehen lassen, gibt es z.B. hier
und hier
unter Apple Discussions und an vielen Stellen anderswo.
Will heißen, sofort, wenn der XProtect daemon von launchd via Plist geladen wird, legt er auch unmittelbar los und macht ggf. ein Update (wenn er denn in dem Moment eine Online-Verbindung vorfindet). Das steht auch so in der zugehörigen Plist-Datei (/System/Library/LaunchDaemons/com.apple.xprotectupdater.plist) drin, dass er sofort loslegen soll, wenn er gestartet wird: zugehöriger Eintrag in der PList-Datei: <key>RunAtLoad</key>
Ist eine Online-Verbindung gegeben, dann findet das Update statt. Ist sie nicht gegeben, findet nix statt, und ins Systemprotokoll wird der Fehlversuch mit entspr. Fehlermeldung entspr. reingeschrieben. Nachgeholt wird da nix. Leider nicht. Dazu müsste auch in der betreffenden PList-Datei eine entspr. Anweisung stehen. Der Job wird einmal ausgeführt sofort dann, wenn er von launchd geladen wird (beim Starten des Systems). Und dann wieder alle 86400 Sekunden (24 Stunden). Dafür sorgt der Eintrag bzw. das Schlüssel-/Wertepaar
<key>StartInterval</key>
<integer>86400</integer>
Neben einem normalen Text-Editor (die Plist-dateien sind alle XML-Dateien, manchmal binär komprimiert, manchmal auch unkomprimiert, dann kann man sie mit jedem beliebigen Text-Editor einsehen und ggf. bearbeiten) und dem Plist-Editor, der den Developer Tools beiliegt, gäbe es eine weitere Möglichkeit, um die betreffende launchd-Datei ggf. zu bearbeiten und ggf. nachhaltig zu beeinflussen: hat man Lingon
installiert, so kann man damit nicht nur launchd-Dateien (sind XML-Dateien) einsehen und ggf. editieren, sondern man kann sie auch aktivieren/deaktivieren (in Lingon oben rechts: [✓] Enabled). Zum Aktivieren/Deaktivieren sieht die Syntax von launchd folgenden Eintrag in der betreffenden PList vor:
<key>Disabled</key>
<true/>
Dieses Wertepaar wird geschrieben, wenn man in Lingon den Haken bei [✓] Enabled wegnimmt. Ein auf diese PList zugreifender launchd daemon kann auf diese Weise dauerhaft beeinflusst werden, diesen Job auszuführen oder nicht auszuführen, wenn man's abspeichert. Auch Benutzern, die sich von Googles Update-Mechanismus bevormundet fühlen, kann diese Methode helfen, Googles Auto-Updater dauerhaft zu deaktivieren. Zur Syntax und Funktionsweise einzelner launchd-Direktiven siehe dazu auch die entspr. Ausführungen in 'man launchd.plist'.
Hilfreich?
0
MacMark
05.06.11
12:50
ts
MacMark
Es muß schon irgendwas bei Dir sein, denn sonst hätten alle das Problem, nicht wahr?
Was ist, wenn Probleme nur unter bestimmten Voraussetzungen auftreten?
sudo launchctl list | grep protect
bietet mir
- 255 com.apple.xprotectupdater
Das bedeutet, daß der Update-Prozeß zuletzt mit Signal 255 abgeschossen wurde. Normalerweise müßte dort eine 0 stehen. Da ist also etwas nicht in Ordnung.
„@macmark_de“
Hilfreich?
0
MacMark
05.06.11
12:59
Du müßtest einen Hinweis für diesen Abschuß mit Details im Crashreport finden für den XProtectUpdater in Console.app.
„@macmark_de“
Hilfreich?
0
sierkb
05.06.11
13:02
MacMark
Da wird anscheinend die Preferences-Einstellung nicht übernommen, die den Dämon generell ein- oder ausschaltet.
Ach, sach an!
Ist er jedoch eingeschaltet, dann läuft er zuverlässig dank launchd wie oben beschrieben.
Er läuft nur dann erfolgreich ab, wenn er zum Zeitpunkt, wenn der Job von launchd abgearbeitet wird, eine Online-Verbindung besteht. Besteht sie nicht, gibt's eine entsprechende Fehlermeldung im Log. Der Job wird bei einem solchen Fehlversuch dann ein zweites oder drittes oder viertes Mal ein paar Minuten oder Stunden oder bei nächster Gelegenheit, wenn eine Online-Netzverbindung wieder besteht, NICHT nachgeholt. Er wird erst 86400 Sekunden (24 Stunden) später wiederholt. Oder beim nächsten Start des betreffenden launchd-Skriptes (RunAtLoad = True), im Allgemeinen also dem Hochfahren des Rechners oder wenn man das Skript in launchd manuell neu lädt z.B. mittels
launchctl unload com.apple.xprotectupdater
dem aktuell laufenden launchd entzieht und mittels
launchctl load com.apple.xprotectupdater
wieder reinlädt. Entsprechendes macht z.B. auch das letzte Sicherheits-Update von Apple in seinem Update-Installationsskript, wenn es den MRT-Agent (MalwareRemovingTool) für die Zeit des Installierens des Updates vorübergehend im System platziert, es ausführen und nach Malware suchen lässt und es dann wieder rückstandsfrei verschwinden lässt, so als sei es nie dagewesen.
Als einfach nochmal nachsehen, ob der Haken bleibt.
Und vor allem offenbar nicht zu lange dabei warten, sondern das Ganze schnell und innerhalb von 30 Sekunden tun inkl. Schloss auch wieder schließen, sonst scheint der dort vorhandene Bug zuzuschlagen, und ggf. Änderungen werden nicht übernommen bzw. bleiben wirkungslos.
Hilfreich?
0
sierkb
05.06.11
13:05
MacMark
Es muß schon irgendwas bei Dir sein, denn sonst hätten alle das Problem, nicht wahr?
Es HABEN genau alle diejenigen genau ein solches Problem, die zu dem Zeitpunkt, wo dieses Skript von launchd abgearbeitet werden soll,
nicht
gleichzeitig und zu genau diesem Zeitpunkt (und keine Sekunde später) online sind. Eben genau weil dieses Skript nur zwei Abarbeitungszeitpunkte kennt und zwischendurch nicht wiederholt aufgerufen wird, nämlich einmal sofort zu Beginn, wenn dieses Skript geladen wird (i.d.R. beim Hochfahren des Rechners) und ab dann alle 86400 Sekunden (24 Stunden) (in der Stillen Hoffnung und Voraussetzung, dass dann 24 Stunden später eine Online-Verbindung vorhanden ist). Zwischendurch ruht dieser Job.
Auch ich habe dieses Problem.
Hilfreich?
0
sierkb
05.06.11
13:13
Das bedeutet, daß der Update-Prozeß zuletzt mit Signal 255 abgeschossen wurde. Normalerweise müßte dort eine 0 stehen.
Da sind sich die Experten derzeit noch im Unklaren darüber, was dieser "Fehler 255" genau haißen soll, weil Apple das anscheinend nirgendwo dokumentiert hat und derzeit wohl nur Apple weiß, was diese 255 aussagen soll.
Abgesehen von dieser Fehlermeldung ist das Systemlog trotzdem ein wenig gesprächiger und schreibt ein paar mehr Informationen. U.a. auch, wenn's einen fehlversuch gegeben hat, der aufgrund fehlender OnlineVerbindung nicht hat stattfinden können.
Da ist also etwas nicht in Ordnung.
Ach, sach an!
Eine Feststellung wie: der Arzt sagt zum kranken Patienten (der sich auch krank fühlt und spürt und weiß, dass er krank ist): "Sie haben eine Krankheit."
Hilfreich?
0
sierkb
05.06.11
13:19
Beim Hochfahren:
Jun 5 11:57:40 XXXXX XProtectUpdater[33]: NSURLConnection error: Error Domain=NSURLErrorDomain Code=-1009 UserInfo=0x100500f90 "This computer’s Internet connection appears to be offline." Underlying Error=(Error Domain=kCFErrorDomainCFNetwork Code=-1009 UserInfo=0x10050fa70 "This computer’s Internet connection appears to be offline.")
Selbst Stunden später keine automatische Wiederholung. Erst 86400 Sekunden (24 Stunden) später. Die Angabe <key>StartInterval</key><integer>86400</integer> in der com.apple.xprotectupdater.plist wäre auch weitgehend unsinnig und überflüssig, wenn dieser Job von launchd vorher selbständig/automatisch nachgeholt würde, wenn er verpasst wird.
Hilfreich?
0
_mäuschen
05.06.11
13:39
…und gleich darunter steht:
XXX com.apple.launchd[1] (com.apple.xprotectupdater[37]): Exited with exit code:
255
Hilfreich?
0
ts
05.06.11
13:50
Nun im Log nachschauen hilft auch nicht wirklich..
Neo:~ admin$ more /private/var/log/system.log | grep xprotect
Jun 5 09:47:09 Neo System Preferences[1165]: *** xprotect: SMJobSetEnabled failed with: Error Domain=kSMErrorDomainLaunchd Code=2 UserInfo=0x200216b20 "Der Vorgang konnte nicht abgeschlossen werden. (kSMErrorDomainLaunchd-Fehler 2 - An operation failed in launchdadd for reasons that you probably can't do anything about. Maybe you should reboot.)"; {\n NSDescription = "An operation failed in launchdadd for reasons that you probably can't do anything about. Maybe you should reboot.";\n}
Jun 5 09:47:10 Neo System Preferences[1165]: *** xprotect: SMJobSetEnabled failed with: Error Domain=kSMErrorDomainLaunchd Code=2 UserInfo=0x200238b40 "Der Vorgang konnte nicht abgeschlossen werden. (kSMErrorDomainLaunchd-Fehler 2 - An operation failed in launchdadd for reasons that you probably can't do anything about. Maybe you should reboot.)"; {\n NSDescription = "An operation failed in launchdadd for reasons that you probably can't do anything about. Maybe you should reboot.";\n}
Immerhin, ein Ansatzpunkt ist da, gucke ich mir es mit vim genauer an, steht da das:
Jun 5 09:46:41 Neo ntpd[18]: time reset -0.135563s
Jun 5 09:47:09 Neo /usr/libexec/launchdadd[1177]: Could not copy right com.apple.ServiceManagement.daemons.modify. AuthorizationCopyRights() error -60007: (errAuthorizationInteractionNotAllowed) The authorization was denied since no user interaction was possible.
Jun 5 09:47:09 Neo System Preferences[1165]: *** xprotect: SMJobSetEnabled failed with: Error Domain=kSMErrorDomainLaunchd Code=2 UserInfo=0x200216b20 "Der Vorgang konnte nicht abgeschlossen werden. (kSMErrorDomainLaunchd-Fehler 2 - An operation failed in launchdadd for reasons that you probably can't do anything about. Maybe you should reboot.)"; {\n NSDescription = "An operation failed in launchdadd for reasons that you probably can't do anything about. Maybe you should reboot.";\n}
Jun 5 09:47:10 Neo /usr/libexec/launchdadd[1177]: Could not copy right com.apple.ServiceManagement.daemons.modify. AuthorizationCopyRights() error -60007: (errAuthorizationInteractionNotAllowed) The authorization was denied since no user interaction was possible.
Jun 5 09:47:10 Neo System Preferences[1165]: *** xprotect: SMJobSetEnabled failed with: Error Domain=kSMErrorDomainLaunchd Code=2 UserInfo=0x200238b40 "Der Vorgang konnte nicht abgeschlossen werden. (kSMErrorDomainLaunchd-Fehler 2 - An operation failed in launchdadd for reasons that you probably can't do anything about. Maybe you should reboot.)"; {\n NSDescription = "An operation failed in launchdadd for reasons that you probably can't do anything about. Maybe you should reboot.";\n}
Die xprotect-Meldung ist echt geil. Offenbar war dieser Eintrag zeitlich sehr nahe am Versuch den Haken zu entfernen und neu zu setzen. Ein Rechteproblem? Ich habe nicht an den Rechten herumgespielt.
_mäuschen:
Genau dann, wenn eine Sekunde keine Online-Verbindung besteht, dann besteht in den nächsten 24 Stunden auch keine Verbindung. Glaube ich jedenfalls nicht.
Hilfreich?
0
sierkb
05.06.11
13:53
Solche Workaround-Skripte drehen derzeit im Netz die Runde, teilweise auch als App compiliert und zum Anklicken (im Fall des AppleScript Skriptes), um die Aktualität der XProtect-Liste zu erfahren und dann ggf. ein manuelles Update anzuschieben:
#!/bin/sh
echo "Forcing XProtect to update its database."
echo "This operation requires an Administrator password."
sudo /usr/libexec/XProtectUpdater
echo ""
echo "XProtect last modified:" `defaults read /System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/XProtect.meta LastModification`
echo "Version:" `defaults read /System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/XProtect.meta Version`
set a to do shell script "defaults read /System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/XProtect.meta Version"
set b to do shell script "defaults read /System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/XProtect.meta LastModification"
display dialog "Safe Download definitions are at version " & a & "," & return & "last updated on " & b
Weil einige Benutzer zwar mehrfach lesen, dass es zwischendurch inzwischen mehrfache Updates der XProtect.plist gegeben hat, sie diese aber nicht bei sich auf dem Rechner in entsprechender Version vorfinden, obwohl sie sagen, dass sie die ganze Zeit online sind und diese Updates ja eigentlich hätten automatisch bekommen müssen.
Die Frage ist nur: ob sie auch zu
genau dem
Zeitpunkt online gewesen sind, als der betreffende launchd-Job gelaufen ist, und da er nur alle 24 Stunden wiederholt wird, kann es also auch mal dauern, bis einen das Update erreicht, und wenn man regelmäßig zu genau dem Zeitpunkt, wo dieser launchd-Job abgearbeitet wird, eben
keine
oder
noch keine
Internet-Verbindung vorfindet, dann kann dieser Job eben unglücklicherweise NICHT erfolgreich abgeschlossen werden. Egal ob beim Hochfahren des Rechners, wenn dieses launchd-Skript zum ersten Mal geladen wird oder 24 Stunden später. Wenn 24 Stunden später wieder keine Online-Verbindung steht, dann wird's halt wieder nicht abgearbeitet. Und wenn der Rechner zwischendurch mal runtergefahren wurde und wieder hochgefahren wird (bei Laptops, die durch die Gegend transportiert werden und mal hier onlinesind und mal da, ist das ja kein unübliches Szenario), dann geht das Spiel von vorne los.
Einzige Abhilfe: Apple (oder man selber) modifiziert com.apple.xprotectupdater.plist entweder dahingehend, dass der Job bei nächster sich bietender Gelegenheit und wenn eine Online-Verbindung steht, automatisch wiederholt bzw. nachgeholt wird (entweder durch kürzere und dadurch zahlenmäßig mehr Intervalle pro Tag oder z.B. durch Setzen des
KeepAlive
-Schlüssels mit einem passenden Wert oder
KeepAlive:NetworkState:true
oder whatever).
Oder Apple (oder man selber) stellt ein kürzeres Intervall als die vorgegebenen 24 Stunden ein, beispielsweise 6 Stunden oder 8 Stunden oder 3 Stunden oder 1 Stunde oder whatever. So dass sich über den Tag verteilt mehrere Zeitfenster ergeben, in denen com.apple.xprotectupdater.plist wiederholt abgearbeitet wird und dadurch die Chance erhöht ist, dass das Abarbeiten in einem dieser Zeitfenster dann erfolgreich abgeschlossen werden kann, während der Rechner zu dem Zeitpunkt grad' eine Internetverbindung hat.
Hilfreich?
0
Schnapper
05.06.11
15:05
Nur mal als Ergänzung: Aufgrund der Diskussion hier hab ich auch mal nachgesehen, wie's bei mir so aussieht.
sudo launchctl list | grep protect
lieferte ein
- 255 com.apple.xprotectupdater
Und ein
defaults read /System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/XProtect.meta Version
lieferte ein
2011-06-05 14:56:12.456 defaults[579:903]
The domain/default pair of (/System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/XProtect.meta, Version) does not exist
Scheinbar lief der Updater bei mir - trotz gesetzem Häkchen - also noch nie. Auch nicht, nachdem ich den Haken mehrfach an- und abgeklickt habe.
Nach einem
sudo /usr/libexec/XProtectUpdater
hab ich nun die Version 5 der Definitions auf dem Rechner. Und, interessanterweise, gibt mir launchctl keinen Fehler 255 mehr aus:
sudo launchctl list | grep protect:
- 0 com.apple.xprotectupdater
Es scheint also zumindest bei einigen Rechnern tatsächlich so zu sein, dass man das Update erstmalig manuell anstoßen muss. Ich behalt mal ein Auge drauf. Insgesamt ist das aber mehr als suboptimal, was Apple da gerade liefert...
Hilfreich?
0
ts
05.06.11
16:02
Ich habe meinen Rechner neu gestartet, in der Hoffnung, dass dann eventuell eine andere Meldung kommt. Meine Vermutung war, dass eine andere, zusätzliche, Fehlermeldung eventuell schon archiviert wurde.
Jun 5 15:40:27 localhost org.macports.mysql5[46]: .
Jun 5 15:40:28 localhost XProtectUpdater[19]: NSURLConnection error: Error Domain=NSURLErrorDomain Code=-1009 UserInfo=0x100110930 "This computer’s Internet connection appears to be offline." Underlying Error=(Error Domain=kCFErrorDomainCFNetwork Code=-1009 UserInfo=0x100113f90 "This computer’s Internet connection appears to be offline.")
Jun 5 15:40:28 localhost com.apple.launchd[1] (com.apple.xprotectupdater[19]): Exited with exit code: 255
Jun 5 15:40:28 localhost configd[13]: network configuration changed.
Jun 5 15:40:28 Neo configd[13]: setting hostname to "Neo.local"
Jun 5 15:40:28 Neo org.macports.mysql5[46]: SUCCESS!
Jun 5 15:40:31 Neo configd[13]: network configuration changed.
Jun 5 15:40:31 Neo ntpd[18]: bind() fd 25, family 30, port 123, scope 4, addr fe80::223:dfff:fede:375f, in6_is_addr_multicast=0 flags=0x11 fails: Can't assign requested address
Jun 5 15:40:31 Neo ntpd[18]: unable to create socket on en0 (5) for fe80::223:dfff:fede:375f#123
Jun 5 15:40:31 Neo /System/Library/CoreServices/coreservicesd[53]: Received requiest to reset fmod watch. Latest received id is 21018769622. Latest sent id is 21018769622
Jun 5 15:40:33 Neo loginwindow[30]: Login Window Started Security Agent
Jun 5 15:40:33 Neo loginwindow[30]: Login Window - Returned from Security Agent
Jun 5 15:40:33 Neo loginwindow[30]: USER_PROCESS: 30 console
Jun 5 15:40:33 Neo loginwindow[30]: MDS Error: unable to create user DBs in /var/folders/dE/dEpgUcGTF2WhBokFy50M0k+++TM/-Caches-//mds
Jun 5 15:40:34: --- last message repeated 2 times ---
Jun 5 15:40:34 Neo com.apple.launchd.peruser.502[184] (com.apple.ReportCrash): Falling back to default Mach exception handler. Could not find: com.apple.ReportCrash.Self
Jun 5 15:40:36 Neo com.apple.launchd.peruser.502[184] (com.apple.Kerberos.renew.plist[209]): Exited with exit code: 1
Jun 5 15:40:36 Neo com.apple.usbmuxd[21]: HandleUSBMuxDictionary client 0x102400010-iTunesHelper/com.apple.iTunesHelper using library usbmuxd-211 built on Jan 13 2011 at 04:19:31, running usbmuxd-211 built on Jan 13 2011 at 04:20:21
Jun 5 15:40:36 Neo /Library/PreferencePanes/Growl.prefPane/Contents/Resources/GrowlHelperApp.app/Contents/MacOS/GrowlHelperApp[217]: MDS Error: unable to create user DBs in /var/folders/dE/dEpgUcGTF2WhBokFy50M0k+++TM/-Caches-//mds
Jun 5 15:40:41: --- last message repeated 1 time ---
Jun 5 15:40:41 Neo [0x0-0xb00b].com.elgato.eyetvhelper[218]: EyeTV Helper version 3.5.2 build 306
Jun 5 15:40:50 Neo login[226]: USER_PROCESS: 226 ttys000
Jun 5 15:40:53 Neo WindowServer[137]: kCGErrorFailure: Set a breakpoint @ CGErrorBreakpoint() to catch errors as they are logged.
Jun 5 15:40:53 Neo com.apple.WindowServer[137]: Sun Jun 5 15:40:53 Neo.local WindowServer[137] <Error>: kCGErrorFailure: Set a breakpoint @ CGErrorBreakpoint() to catch errors as they are logged.
Also der Router war zu dem Zeitpunkt definitiv eingeschaltet (wurde vorher sicherheitshalber neu gestartet) und eine Verbindung ins Internet war vorhanden. IP-Vergabe mittels DHCP etc. Einmal sollte die Aktualisierung im Hintergrund gelaufen sein (eventuell Ruhezustand über Nacht? Ich hatte Version 2, nehme an es gab wohl auch eine Version 1).
Konkret heißt das nun, das ich jedes mal, nachdem ich den Rechner neu starte eigentlich die letzte Software-Aktualisierung bzgl. xprotect neu einspielen müsste.
Eine Sicherheitsaktualisierung, die keinen Neustart unbeschadet überlebt
fantastisch und sehr interessant.
Hilfreich?
0
MacMark
05.06.11
20:25
sierkb
…
Selbst Stunden später keine automatische Wiederholung. Erst 86400 Sekunden (24 Stunden) später. Die Angabe <key>StartInterval</key><integer>86400</integer> in der com.apple.xprotectupdater.plist wäre auch weitgehend unsinnig und überflüssig, wenn dieser Job von launchd vorher selbständig/automatisch nachgeholt würde, wenn er verpasst wird.
Dir sind die technischen Hintergründe immer noch nicht klar: Der Job ist nicht verpaßt worden, denn er lief und ist mit Signal 255 abgeschossen worden. Falls einer der mit "StartInterval" angegebenen Zeitpunkte verschlafen wird, wird er nachgeholt beim nächsten Aufwachen. Das Nachholen ist ein implizites Feature von "StartInterval".
„@macmark_de“
Hilfreich?
0
sierkb
05.06.11
21:06
MacMark
Dir sind die technischen Hintergründe immer noch nicht klar
Doch, sind sie. Hör' bitte auf, hier so einen Unsinn zu reden und die Leute für blöd' zu verkaufen.
Der Job ist nicht verpaßt worden, denn er lief und ist mit Signal 255 abgeschossen worden.
Ich habe nirgendwo geschrieben, dass der Job
verpasst
worden ist. Ich habe stets geschrieben, dass er
nicht erfolgreich abgeschlossen
werden konnte im Sinne dessen wozu er eigentlich da ist!
Falls einer der mit "StartInterval" angegebene Zeitpunkte verschlafen wird, wird er nachgeholt beim nächsten Aufwachen.
Alle 24 Stunden. Nur was nützt ein solches Intervall, wenn die Voraussetzungen, dass der Job erfolgreich abgeschlossen werden kann, nicht gegeben sind?
Das Nachholen ist ein implizites Feature von "StartInterval".
"man launchd.plist"
RunAtLoad <boolean>
This optional key is used to control whether your job is launched once at the time the job is loaded. The default is false.
[..]
StartInterval <integer>
This optional key causes the job to be started every N seconds. If the system is asleep, the job will be started the next time the computer wakes up. If multiple intervals transpire before the computer is woken, those events
will be coalesced into one event upon wake from sleep.
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Label</key>
<string>com.apple.xprotectupdater</string>
<key>ProgramArguments</key>
<array>
<string>/usr/libexec/XProtectUpdater</string>
</array>
<key>RunAtLoad</key>
<true/>
<key>StartInterval</key>
<integer>86400</integer>
</dict>
</plist>
und ist mit Signal 255 abgeschossen worden
Jun 5 11:57:40 XXXX XProtectUpdater[33]: NSURLConnection error: Error Domain=NSURLErrorDomain Code=-1009 UserInfo=0x100500f90 "This computer’s Internet connection appears to be offline." Underlying Error=(Error Domain=kCFErrorDomainCFNetwork Code=-1009 UserInfo=0x10050fa70 "This computer’s Internet connection appears to be offline.")
Jun 5 11:57:40 XXXX com.apple.launchd[1] (com.apple.xprotectupdater[33]): Exited with exit code: 255
Ohne gleichzeitige Internetverbindung beim Laden (RunAtLoad) des launchd-Skriptes kein Update der XProtect.plist (logisch). Nächste Möglichkeit/nächster Versuch: 24 Stunden später. Wenn dann zu genau dem Zeitpunkt wieder keine Internetverbindung besteht, dann wieder kein Update. Wer mit einem Surfstick unterwegs ist und deshalb beim Hochfahren des Rechners (und damit erstmaligem Abarbeiten des Skriptes) noch keine Internetverbindung hat, ist gekniffen. Entweder er wartet 24 Stunden und sorgt dafür dass in 24 Stunden zu exakt dem Zeitpunkt, wo dieses launchd-Skript automatisch nochmal aufgerufen und abgearbeitet wird, eine Online-Verbindung besteht. Oder er stößt das Update manuell an. Zwischen diesen beiden Zeitpunkten, also zwischem dem erstmaligen Durchlaufen des Skriptes und der Wiederholung nach 24 Stunden wird dieses Skript kein einziges Mal nochmal neu abgearbeitet, egal ob der Rechner in dieser Zeit online ist oder nicht. Der Rechner ist die ganze Zeit an also nicht im Schlafmodus.
Es kann ja sein, dass ein Nachholen via
StartInterval
dann stattfindet, wenn der Rechner sich zwischendurch im Ruhezustand befindet und er dann den Job nochmal versucht, doch das ist hier in dem Fall, wovon ich die ganze Zeit rede, nicht der Fall und steht hier in diesem Fall überhaupt nicht zur Debatte, wie launchd reagieren
würde
im Fall des Ruhezustands und Wiedererwachens: in diesem Fall ist der Rechner die ganze Zeit an und die ganze Zeit online. Bis auf den Zeitpunkt des Hochfahrens, wo er noch offline ist. Kein Ruhezustand zwischendurch. Und während der Rechner die ganze Zeit an ist und online ist, wird NIX nachgeholt. Erst nach Ablauf von 86400 Sekunden (24 Stunden) wird in diesem Fall der Job automatisch erneut ausgeführt.
Und wie man offenbar nachlesen kann, wurde der Job bei einigen Nutzern überhaupt noch gar
nie
automatisch bzw. erfolgreich ausgeführt oder in manchen Fällen sogar gar keine XProtect.plist angelegt, selbst bei Installation des Security Updates nicht, dessen preinstall- und post-install-Skripte sowas aber sogar vorsehen bzw. explizit ein Laden/Entladen (und damit Starten) der betreffenden Plist-Datei vornehmen.
Da ist also gleich in mehrfacher Hinsicht Nachbesserung seitens Apple angesagt, was das Ganze angeht.
Hilfreich?
0
ts
05.06.11
21:58
sierkb
Ohne gleichzeitige Internetverbindung beim Laden (RunAtLoad) des launchd-Skriptes kein Update der XProtect.plist (logisch).
So logisch ist's für mich nicht. Der Router stellt, in meinem Fall, eine Verbindung bereit. Das Problem ist auch, dass eine vorhandene Verbindung eventuell nicht benutzt wird…
Im Prinzip ist die nächste Sicherheitsaktualisierung schon überfällig.
Hilfreich?
0
sierkb
05.06.11
22:08
ts
So logisch ist's für mich nicht.
Ich meinte das im Sinne dessen, was dieses launchd-Skript machen soll. Für das, was es bewirken soll, braucht es eine Internetverbindung. Sonst kann kein Update runtergeladen werden. In diesem Sinne meinte ich das "logisch".
Dass der Zweck dieses launchd-Skriptes in der Praxis derzeit ganz offenbar nicht zuverlässig erfüllt wird, das steht auf einem anderen Blatt.
Der Router stellt, in meinem Fall, eine Verbindung bereit. Das Problem ist auch, dass eine vorhandene Verbindung eventuell nicht benutzt wird…
Eben. Das ist zu hinterfragen und von Apple ggf. nachzubessern, weshalb selbst das, also bei eigentlich optimalen Voraussetzungen was die Internetverbindung angeht, nicht wie vorgesehen zuverlässig klappt.
Im Prinzip ist die nächste Sicherheitsaktualisierung schon überfällig.
Das sowieso. Da stünden so einige Sachen in der Pipeline und wären notwendig und nicht nur XProtect betreffend. Inklusive u.a. eines Subversion-Updates (welches Upstream vor wenigen Tagen z.B. noch ein aus dringendem aktuellem Anlass zwischengeschobenes reines Sicherheits-Update auf Version 1.6.17 erfahren hat, obwohl Version 1.7.0 eigentlich schon längst draußen sein sollte).
Hilfreich?
0
Laurin
05.06.11
23:40
Auf Grund dieser Diskussion habe ich auch mal bei mir nachgeschaut. Ist auch bei mir vom 1. Juni Version 2. Der Rechner war online (auch 24 h nach Aktualisierung) und zwischendurch mehrfach auch im Ruhezustand. Von allein passiert da gar nix ... trotz Haken.
Haken raus und wieder rein brachte dann das Update. Ist also so, das es doch mehrere betrifft
Hilfreich?
0
MacMark
06.06.11
15:11
Laurin
… Haken raus und wieder rein brachte dann das Update. Ist also so, das es doch mehrere betrifft
Das Anhaken war beim ersten Mal schlicht unwirksam bei Dir. Nur wenn der Haken übernommen wurde, wird auch der Aktualisierungs-Zyklus überhaupt ins Leben gerufen.
sierkb
Ich habe nirgendwo geschrieben, dass der Job verpasst worden ist
*Hust*
sierkb
MacMark
Wird ein Termin verschlafen, wird er beim Aufwachen nachgeholt.
Nein, wird er eben NICHT! … eine entsprechende Einstellung in der betreffenden launchd Plist-Datei, die das bewirken könnte, fehlt.
Inzwischen hast Du ja endlich mal (05.06.11 21:06) in die manpages und die plist geschaut und Deinen Fehler hoffentlich erkannt.
„@macmark_de“
Hilfreich?
0
Zauberlehrling
06.06.11
17:35
Ihr könnt reden was ihr wollt. Punkt ist das es nicht zuverlässig geht.
Und die meisten wo es nicht geht wissen es warscheinlich nicht.
Ich mach es jetzt manuell. Auf der Seite die ich verlink hatte gibt es ein kleines App dass das übernimmt.
Hilfreich?
0
_mäuschen
06.06.11
17:43
Paranoide stellen
<key>StartInterval</key>
auf
<integer>
1
</integer>
und 'launchctl load -w'en das Ding neu
Hilfreich?
0
sierkb
06.06.11
18:47
MacMark
Inzwischen hast Du ja endlich mal (05.06.11 21:06) in die manpages und die plist geschaut und Deinen Fehler hoffentlich erkannt.
Mein einziger
Fehler
, wenn man das als
Fehler
überhaupt bezeichnen kann, war, mich mit Dir überhaupt auf eine Diskussion eingelassen zu haben, statt Dich geflissentlich zu ignorieren.
Hilfreich?
0
1
2
>|
Kommentieren
Diese Diskussion ist bereits mehr als 3 Monate alt und kann daher nicht mehr kommentiert werden.
Eskalationskurs: ARM kündigt Qualcomm die Desig...
Daten zum Mac mini M4: Aufpreise, Spezifikation...
iOS 18 und iPadOS 18 lassen sich ab sofort laden
iOS 18, iPadOS 18, macOS 15: Das Release-Datum ...
Vor 10 Jahren: Das iPhone 6 und "Bendgate"
Apples interne Einschätzung: Zwei Jahre Rücksta...
Vor 30 Jahren: Apple holt Sanierer – kann das s...
Mac mini M4: Reparaturhandbuch bestätigt austau...