Run Munki on startup only

[karamoja]

Hello Everyone

I see that version 8 is now out and I will use the "force by date"
feature on our staff machines. I aim to start using it on our student
macs in open access areas and I wonder if this version can be set to
make Munki only run on bootup time and not during the day. Also, if
software is being installed, to display a message not allowing users
to logon.

I have searched the group and came across this:-

If you want a munki session to run at startup, I think the best
approach would be a script like:
#!/bin/sh
/usr/bin/touch /Users/
Shared/.com.googlecode.munki.checkandinstallatstartup
/usr/local/munki/managedsoftwareupdate --logoutinstall

This looks straightforward but where does the hidden
file .com.google.munki.check....... come from?

Thanks

[Greg Neagle]

It is created by the `/usr/bin/touch` command.

-Greg

[Andrew Rae]

You might want to take a read of this page:
http://code.google.com/p/munki/wiki/BootstrappingWithMunki

It sounds like you make this file yourself...
For example like this:
touch /Users/Shared/.com.googlecode.munki.checkandinstallatstartup

>
>Thanks

Hope that helps,
Andrew

[karamoja]

Have I got things right then :-

The script is called by a launchagent
If munki finds it, it runs
After running, and finding no more updates, it changes the
modification date of the file
It won't run again until the machine is re-started
It won't do its random checks during the day

Thanks





On Nov 7, 4:52 pm, Andrew Rae <A.M....@leeds.ac.uk> wrote:

[Nate]

Actually, it deletes that file rather than change modification date.  You must re-touch that file to have it run again at startup.

Nate

[Greg Neagle]

On Nov 8, 2011, at 1:00 AM, karamoja wrote:

> Have I got things right then :-
>
> The script is called by a launchagent
> If munki finds it, it runs

??? The scrip runs /usr/local/munki/managedsoftwware directly.

> After running, and finding no more updates, it changes the
> modification date of the file
> It won't run again until the machine is re-started
> It won't do its random checks during the day

Yes, it will, unless you remove or modify /Library/LaunchDaemons/com.googlecode.munki.managedsoftwareupdate-check.plist

Make sure you think through all the implications here. If you are managing a bunch of lab machines that all turn on at 7 am each day, you might overload your munki web server if all your machines are trying to download a bunch of large update simultaneously.

[karamoja]

OK I have got it working but will Munki still do its random update
checks during the day?
Also, is it possible to have it to run on bootup but only once in a
day. This would be useful as the Macs are started early before
students are around but if a student restarts a machine during the
day, they will have to wait for the software and Apple update check to
finish before they can logon. Also, the logon box appears long enough
for someone to begin logging in before it gets replaced by the Munki
update window.
I am not sure if this is the best method for Munki to maintain labs, I
am also considering having Munki only been run on demand by a command
sent out by ARD, perhaps say once a week or when I have prepared
software updates to be sent out.

Can I ask how other people use Munki in labs?

Thanks

[Ricky Chilcott]

I'd take a look at the launchd tasks in /Library/LaunchDaemons and /Library/LaunchAgents. Those are what is controlling the random checks.

[Timothy Sutton]

In terms of maintaining once-per-day Munki runs, I used to do this,
because I wanted to only have Munki perform update in the morning
before the labs and classes were open. I was concerned with something
like a large OS update running immediately before someone logs onto a
teacher station when a class begins.

I took the existing com.googlecode.munki.managedsoftwareupdate-
check.plist and modified StartCalendarInterval to a specific time of
day:

<key>StartCalendarInterval</key>
<dict>
<key>Hour</key>
<integer>6</integer>
<key>Minute</key>
<integer>10</integer>
</dict>

As long as I knew that the machines were on by 6:10 am, I'd know that
they would have done a check at some point by around 7:10, which left
enough time for any minor OS updates, etc. The downside to doing this
is that you need to keep this modified LaunchDaemon up to date with
newer versions of Munki's launchd package. It doesn't change too
often, but can with every major release.

I added this plist as a "file" type installs item, so that it would
use the checksum to determine whether this file was in its place and
with the exact contents, and make that pkginfo available to the group
manifest for labs. It seemed doable in a lab environment where I the
scheduling was very consistent, and I would know that munki would be
upgraded at once pretty much everywhere. Either way, keeping it in
sync with the correct munki version is very important but a hassle. I
only did this for about 6 months, when the munkitools_launchd package
wasn't undergoing any changes. I decided not to keep doing this, and
it's one less thing I need to maintain in my configurations.


-Tim

[MiqViq]

Hi all,

Yes, if you modify com.googlecode.munki.managedsoftwareupdate-check.plist then you should re-create your preferred version every time after you install a new version of munkitools, unless you create separate pkginfos for each munki subpkgs and update only those which are changed with new munki version. With this method you may accidentally miss something important as there may be a completely new way how munki is launched with LaunchDaemons.

You can do your own LaunchDaemon-installer with a modified /LaunchDaemons/com.googlecode.munki.managedsoftwareupdate-check.plist.
Just use your own /Library/LaunchDaemons/com.googlecode.munki.managedsoftwareupdate-check.plist for installs-array with a checksum, this way munki knows that this has to be updated when needed.
And use a preflight script inside your pkg for unloading com.googlecode.munki.managedsoftwareupdate-check.plist (launchctl unload).
And for postflight (or munki postinstall) use a script which reloads your version using "launchctl load /LaunchDaemons/com.googlecode.munki.managedsoftwareupdate-check.plist".

The other possible way would be to use a munki preflight which compares current time to some list of allowed times for auto-runs.
And if current time is within the allowed time range then munki can run, otherwise autorun will be cancelled.
However, it may be much easier to modify just the LaunchDaemon itself.

And if I have understood launchd StartCalendarInterval correctly this could also be possible:

<key>StartCalendarInterval</key>
<array>

<dict>
<key>Hour</key>
<integer>6</integer>
<key>Minute</key>
<integer>10</integer>
</dict>
<dict>
<key>Hour</key>

<integer>23</integer>
<key>Minute</key>
<integer>5</integer>
</dict>
</array>

This will run twice a day on the specified times (morning 06:10 and evening 23:05)

- MiqViq

[Rob Middleton]

On 9/11/2011 6:14 AM, MiqViq wrote:
> Hi all,
>
> Yes, if you modify com.googlecode.munki.managedsoftwareupdate-check.plist then you should re-create your preferred version every time after you install a new version of munkitools, unless you create separate pkginfos for each munki subpkgs and update only those which are changed with new munki version. With this method you may accidentally miss something important as there may be a completely new way how munki is launched with LaunchDaemons.

The prefered way to "modify" a launch daemon for almost all software is
to disable the launch daemon you don't like & create your own with a new
name/identifier. This ensures your changes persist and you don't have a
file ownership collision between the main munki package and your
package. As munki won't touch your file, you can use the pre-packaged
munki installer in more cases.

(as root)
launchctl unload -w /Library/LaunchDaemons/com.googlecode.munki...plist

This disabling of a launch daemon persists across reinstalls of munki.
The disabled key is not stored in the plist, but in an override location
(somewhere in /var/db from memory).

Rob.

[MiqViq]

And yet another, much simpler way pointed out by Rob.

If your OS X version is 10.5 then launchctl unload -w writes unloaded status to the launchdaemon/agent file itself.
In 10.6 and later unloaded status is stored in database.

- MiqViq

[karamoja]

I am coming round to the idea of using a timed run of Munki, at say
07:00, for labs, hopefully, our xserve should be able to cope.

We also have several clusters of machines in the library which are
open access. For these I am thinking of setting ManagedInstalls
preference SuppressUserNotification to true. I understand with this
setting, Munki will only install updates at the logon prompt. May I
ask however, what happens if Munki is installing an update and then
someone logs on or is the logon box not available until the update is
finished?

Thanks.

[Greg Neagle]

On Nov 9, 2011, at 6:53 AM, karamoja <hub...@yahoo.co.uk> wrote:

> We also have several clusters of machines in the library which are
> open access. For these I am thinking of setting ManagedInstalls
> preference SuppressUserNotification to true. I understand with this
> setting, Munki will only install updates at the logon prompt.

Or when manually invoking Managed Software Update.

> May I
> ask however, what happens if Munki is installing an update and then
> someone logs on or is the logon box not available until the update is
> finished?

An install progress window hides the login window, so login is effectively prevented while Munki is installing items.

[karamoja]

I am trying to get Munki to start at a specific time but nothing
happens. The machine's system log doesn't show any launchdaemon
errors and the Munki logs don't show any activity for the time in
question.

Here is my modified com.googlecode.munki.managedsoftwareupdate-
check.plist file. For testing, I set the random interval to 100 and
the time to 16:30 and the machine was not sleeping at that time. If I
get this working, will it make a difference if the machines are
sleeping?


<key>Label</key>
<string>com.googlecode.munki.managedsoftwareupdate-check</string>
<key>ProgramArguments</key>
<array>
<string>/usr/local/munki/supervisor</string>
<string>--delayrandom</string>
<string>100</string>
<string>--timeout</string>
<string>43200</string>
<string>--</string>
<string>/usr/local/munki/managedsoftwareupdate</string>
<string>--auto</string>
</array>

<key>StartCalendarInterval</key>
<dict>
<key>Hour</key>

<integer>16</integer>
<key>Minute</key>
<integer>30</integer>
</dict>

I would be grateful for any pointers to get this working.

Thanks.

[Greg Neagle]

On Nov 17, 2011, at 8:54 AM, karamoja wrote:

>
> I am trying to get Munki to start at a specific time but nothing
> happens. The machine's system log doesn't show any launchdaemon
> errors and the Munki logs don't show any activity for the time in
> question.
>
> Here is my modified com.googlecode.munki.managedsoftwareupdate-
> check.plist file. For testing, I set the random interval to 100 and
> the time to 16:30 and the machine was not sleeping at that time.

Did you restart after making this change or otherwise signal launchd to pay attention to your changed plist?

> If I
> get this working, will it make a difference if the machines are
> sleeping?

Yes, if the machine is sleeping, it won't run!

[Hugh Burt]

It is working now.  Don't know why now because earlier I made sure the machine has been re-started.  Mac was set to do it at 10:45 but actually did at 10:47, must be due to the random time element.  Lastly, using the plist with a specified calendar hour, the machines won't check during the day will they? I think this is the way I will roll munki out to our student machines. Thanks. ----------------------------------------------------------------------- “Weaseling out of things is important to learn. It’s what separates us from the animals.....except the weasel” ~ Homer Simpson --- On Thu, 17/11/11, Greg Neagle <gregn...@mac.com> wrote:

[Jason Content]

Quick question how do you get this script.

#!/bin/sh 
/usr/bin/touch /Users/ 
Shared/.com.googlecode.munki.checkandinstallatstartup 
/usr/local/munki/managedsoftwareupdate --logoutinstall 

to run at startup where would I have to put it for the Machine to run it at startup. Im new to all this scripting world. I know how to create a script and make executable but I don't know how to make them run at startup.