Perhaps there are better ways to do this.Īfter several tests I found out you can't change the creation date to anything later than the already existing creation date, only earlier. With my limited experience in scripting I'm thinking that the time/date value EXIFtool finds (using a terminal command in a "Run shell script" action) could be passed on as a variable to whatever can write the creation date. Unfortunately EXIFtool doesn't have the ability to write system-related stuff like that, so I need to look into other tools for that specific job. ![]() I'll be using the command-line tool EXIFtool to read an image-file's time/date tag inside its EXIF header, then write that date back to the same file's creation date (because certain image software messes with the creation date, so fetching it back from the EXIF header will fix that). All of the heavy lifting is done by the softwareupdate service, which I very much prefer over processes that install the update packages directly.I should have mentioned this initially, but do you know if it could be used to create an Automator application where the actual date to be changed to is determined by the results of another tool? It seems to be limited to the following two options:ġ) change date created to: current date and time The script runs softwareupdate -l, sees what is needed from that list, downloads those updates, then prompts the user (so the install can begin immediately since the updates are cached already). I handle the updates themselves by having the script read in a text file which is a list of the updates we've tested and blessed. If so, a second script shows a countdown timer and forces the reboot at the delay we selected. The script will inform the user of how many updates are available and let them know if a reboot is required. We start our patch cycle the same day we patch Windows systems and provide a similar workflow: users are prompted daily to install updates we've blessed, and they are given until a certain date to install before it becomes mandatory and is forced. We did some custom scripting using CocoaDialog for a UI to allow for user interaction. Of course there's also community driven projects, like Patchoo. I would guess some would stand up a local SUS, enable whatever updates have been tested and qualified and then push them with something like "Install all updates" or softwareupdate -ia in a policy, say at logout. (yes, we still have a small number of clients on that version) We're going to be making a concerted effort to get users upgraded to 10.8 as a minimum OS from this point out to help reduce the fragmentation, although we'd prefer to have everyone on Mavericks or better really.Īs for how to actually do the patching, man, that's a very broad question that is likely to generate a thousand different responses. With the release of Yosemite, we've had to drop support on 10.6. its been a challenge to get everyone updated in a timely manner, especially when we're delayed in rolling out the new OS because we need to wait on laggard vendors to update their products to be compatible. Simple example of the latter is the Bash Update 1.0 patches.Īs for fragmentation of the OS, we're kind of in the same boat. ![]() Not everything you can download from their support site shows up in SUS. I'm not 100% certain, but I believe all patches that show up in SUS are available as direct downloads from Apple, but the reverse is not true.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |