Copy from dmg and folders

[Gary Bernstein]

I was playing with around with the copyfromdmg installer type and discovered that I can put a folder in a disk image and have munki copy the folder to the correct location.

I am little confused on the permissions and what happens to the permissions of the items in the folder.

What permissions does a file get if I don’t modify the permissions in the pkginfo?

What permissions does a folder get if I don’t modify the permissions in the pkginfo?

What permissions does a files in a folder get if I don’t modify the permissions in the pkginfo?

One thing that I tried to do is copy a folder called “Stuff” with two items in it. I can get it to copy the folder, but I also wanted the files to have different permissions from the folder.  So, I tried placing an items_to_copy key for each of the files as well as the folder. However, every time it ran, it gave me an error that the top level folder (Stuff) did not exist.

Is this not supported? Or am I thinking too hard about it.

Thanks
-Gary

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
 -- "The reward for work well done is the opportunity to do more."

 -- "I tried, but it didn't work" is a lot better than "I wish I'd tried."

        Gary R. Bernstein        Director of Computer Information & Access
        bern...@illinois.edu      Krannert Center for the Performing Arts
        217-244-1038                 College of Fine & Applied Arts - UIUC
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

[MiqViq]

On 12.10.2010, at 17.23, Gary Bernstein wrote:

> I was playing with around with the copyfromdmg installer type and
> discovered that I can put a folder in a disk image and have munki
> copy the folder to the correct location.
>
> I am little confused on the permissions and what happens to the
> permissions of the items in the folder.
>
> What permissions does a file get if I don’t modify the permissions
> in the pkginfo?
>
> What permissions does a folder get if I don’t modify the permissions
> in the pkginfo?
>
> What permissions does a files in a folder get if I don’t modify the
> permissions in the pkginfo?
>

Short answer to all above:

root:admin
u=rw,g=r,o=r
Execute permissions are not modified (I guess).
All permissions are applied recursively on target item.

And I guess as munki uses /bin/cp -R for copying items from dmg some
inherited permissions are applied also, depending on the target
directory?

Here is entry for my pkginfo of Firefox.app:

<key>items_to_copy</key>
<array>
<dict>
<key>destination_path</key>
<string>/Applications</string>
<key>source_item</key>
<string>Firefox.app</string>
<key>user</key>
<string>root</string>
<key>group</key>
<string>80</string>
<key>mode</key>
<string>ug+rwX,a+rX,o-w</string>
</dict>
</array>

In my case I like to give admin-group permissions to modify
Firefox.app (allowing manual updates for admins).
Big X tells chmod to set executable permissions only if items are
executable already.

copy_from_dmg does not care what source items are.
It applies default permissions for every item copied if is not
instructed otherwise.

If your source item is not an .app then you probably have to build
your pkginfo manually, makepkginfo probably cannot handle plain files
or directories. I am not sure about this as I generally use
makepkginfo only for clear cases like .pkg/.mpkg or single .app items.
Other than that I use a previously created pkginfo-templates for more
complicated stuff.

> One thing that I tried to do is copy a folder called “Stuff” with
> two items in it. I can get it to copy the folder, but I also wanted
> the files to have different permissions from the folder. So, I
> tried placing an items_to_copy key for each of the files as well as
> the folder. However, every time it ran, it gave me an error that the
> top level folder (Stuff) did not exist.
>
> Is this not supported? Or am I thinking too hard about it.
>
> Thanks
> -Gary

I am not sure if munki currently can handle two different entries with
separate permissions within a single pkginfo-file like this:

<key>items_to_copy</key>
<array>
<dict>
<key>destination_path</key>
<string>/Applications</string>
<key>source_item</key>
<string>FolderWithItems</string>
<key>user</key>
<string>root</string>
<key>group</key>
<string>80</string>
<key>mode</key>
<string>ug+rwX,a+rX,o-w</string>
</dict>
<dict>
<key>destination_path</key>
<string>/Applications/FolderWithItems</string>
<key>source_item</key>
<string>ItemIntoFolderWithItems</string>
<key>user</key>
<string>root</string>
<key>group</key>
<string>80</string>
<key>mode</key>
<string>a-rwX,u+rwX</string>
</dict>
</array>

This probably would work if you carefully set the order of your
entries within items_to_copy-array.

Not sure if munki-client handles them in alphabetical order though
which will ruin all...

-MiqViq

[Greg Neagle]

On Oct 12, 2010, at 7:23 AM, Gary Bernstein wrote:

I am little confused on the permissions and what happens to the permissions of the items in the folder.

What permissions does a file get if I don’t modify the permissions in the pkginfo?

What permissions does a folder get if I don’t modify the permissions in the pkginfo?

What permissions does a files in a folder get if I don’t modify the permissions in the pkginfo?

The same as whatever you'd get if you mounted the disk image as root and did a cp -R of the item as root.

One thing that I tried to do is copy a folder called “Stuff” with two items in it. I can get it to copy the folder, but I also wanted the files to have different permissions from the folder.  So, I tried placing an items_to_copy key for each of the files as well as the folder. However, every time it ran, it gave me an error that the top level folder (Stuff) did not exist.

copy_from_dmg won't create non-existent directories. If it did, then we'd probably also have to provide a mechanism to indicate what user/group/mode the created directories should have, and that the point, you're just re-inventing the pkg format.

For your particular case above, you could probably copy the folder, then copy each of the files afterwards. Yes, this would mean the files would get copied twice.

-Greg

[Gary Bernstein]

Are you saying to use two separate pkginfo files?

[Greg Neagle]

On Oct 12, 2010, at 8:59 AM, Gary Bernstein wrote:

On 10/12/10 10:19 AM, "Greg Neagle" <gregn...@mac.com> wrote:

On Oct 12, 2010, at 7:23 AM, Gary Bernstein wrote:

I am little confused on the permissions and what happens to the permissions of the items in the folder.

What permissions does a file get if I don’t modify the permissions in the pkginfo?

What permissions does a folder get if I don’t modify the permissions in the pkginfo?

What permissions does a files in a folder get if I don’t modify the permissions in the pkginfo?

The same as whatever you'd get if you mounted the disk image as root and did a cp -R of the item as root.

One thing that I tried to do is copy a folder called “Stuff” with two items in it. I can get it to copy the folder, but I also wanted the files to have different permissions from the folder.  So, I tried placing an items_to_copy key for each of the files as well as the folder. However, every time it ran, it gave me an error that the top level folder (Stuff) did not exist.

copy_from_dmg won't create non-existent directories. If it did, then we'd probably also have to provide a mechanism to indicate what user/group/mode the created directories should have, and that the point, you're just re-inventing the pkg format.

For your particular case above, you could probably copy the folder, then copy each of the files afterwards. Yes, this would mean the files would get copied twice.

-Greg

Are you saying to use two separate pkginfo files?

No.  Instead of flailing about with generalities, why don't you post what you've tried with your pkginfo file for this item?

-Greg

[Gary Bernstein]

On 10/12/10 12:01 PM, "Greg Neagle" <gregn...@mac.com> wrote:

No.  Instead of flailing about with generalities, why don't you post what you've tried with your pkginfo file for this item?

-Greg

The message that I get is that the directory /Users/Shared/Adobe-KCPA does not exist.

The dmg looks like this:
/Adobe-KCPA
/Adobe-KCPA/com.adobe.118.registration
/Adobe-KCPA/com.adobe.acrobat.90.sh.plist
/ KCPA-FixAdobeSelfHealRegLoginScript.sh

<?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>autoremove</key>
    <false/>
    <key>catalogs</key>
    <array>
        <string>testing</string>
    </array>
    <key>installer_item_hash</key>
    <string>e2c73894ee460eeb13d10a5e95fabed0118c7e4741e98bb6965696b8e91130ae</string>
    <key>installer_item_location</key>
    <string>KCPA/Apps/AdobeAcrobatPro/KCPA-FixAdobeSelfHealRegLoginScript-1.0.dmg</string>
    <key>installer_item_size</key>
    <integer>11</integer>
    <key>installer_type</key>
    <string>copy_from_dmg</string>
    <key>installs</key>
    <array>
        <dict>
            <key>md5checksum</key>
            <string>355e02a798b609e8a6de359fc4f43482</string>
            <key>path</key>
            <string>/Applications/Utilities/KCPAScripts/LoginItems/KCPA-FixAdobeSelfHealRegLoginScript.sh</string>
            <key>type</key>
            <string>file</string>
        </dict>
        <dict>
            <key>path</key>
            <string>/Users/Shared/Adobe-KCPA</string>
            <key>type</key>
            <string>file</string>
        </dict>
        <dict>
            <key>md5checksum</key>
            <string>a096070bf5e69ac42549780e01bb1de2</string>
            <key>path</key>
            <string>/Users/Shared/Adobe-KCPA/Adobe-KCPA/com.adobe.118.registration</string>
            <key>type</key>
            <string>file</string>
        </dict>
        <dict>
            <key>md5checksum</key>
            <string>97d20cbde03346ffdf8306a6f31f89d1</string>
            <key>path</key>
            <string>/Users/Shared/Adobe-KCPA/Adobe-KCPA/com.adobe.acrobat.90.sh.plist</string>
            <key>type</key>
            <string>file</string>
        </dict>
    </array>

    <key>items_to_copy</key>
    <array>
        <dict>
            <key>destination_path</key>

            <string>/Applications/Utilities/KCPAScripts/LoginItems</string>
            <key>group</key>
            <string>admin</string>
            <key>mode</key>
            <string>o-w</string>
            <key>source_item</key>
            <string>KCPA-FixAdobeSelfHealRegLoginScript.sh</string>
            <key>user</key>
            <string>501</string>

        </dict>
        <dict>
            <key>destination_path</key>

            <string>/Users/Shared</string>
            <key>group</key>
            <string>admin</string>
            <key>mode</key>
            <string>o-w</string>
            <key>source_item</key>
            <string>Adobe-KCPA</string>
            <key>user</key>
            <string>501</string>

        </dict>
        <dict>
            <key>destination_path</key>

            <string>/Users/Shared/Adobe-KCPA</string>
            <key>group</key>
            <string>admin</string>
            <key>mode</key>
            <string>o-w</string>
            <key>source_item</key>
            <string>Adobe-KCPA/com.adobe.118.registration</string>
            <key>user</key>
            <string>501</string>

        </dict>
        <dict>
            <key>destination_path</key>

            <string>/Users/Shared/Adobe-KCPA</string>
            <key>group</key>
            <string>admin</string>
            <key>mode</key>
            <string>o-w</string>
            <key>source_item</key>
            <string>Adobe-KCPA/com.adobe.acrobat.90.sh.plist</string>
            <key>user</key>
            <string>501</string>
        </dict>
    </array>
    <key>minimum_os_version</key>
    <string>10.4.0</string>
    <key>name</key>
    <string>KCPA-FixAdobeSelfHealRegLoginScript</string>
    <key>uninstall_method</key>
    <string>remove_copied_items</string>
    <key>uninstallable</key>
    <true/>
    <key>version</key>
    <string>1.0.0.0.0</string>
</dict>
</plist>

[Greg Neagle]

Change the order of the items in the array so that the Adobe-KCPA directory is created BEFORE you try to copy items into it, like so:

<key>items_to_copy</key>
    <array>

        <dict>
            <key>destination_path</key>

        <dict>
            <key>destination_path</key>
            <string>/Applications/Utilities/KCPAScripts/LoginItems</string>
            <key>group</key>
            <string>admin</string>
            <key>mode</key>
            <string>o-w</string>
            <key>source_item</key>
            <string>KCPA-FixAdobeSelfHealRegLoginScript.sh</string>
            <key>user</key>
            <string>501</string>
        </dict>

    </array>

And as for that last item, the directory /Applications/Utilities/KCPAScripts/LoginItems must already exist.

(I really think you should just package this up...)

-Greg

[Gary Bernstein]

Yeah, I may just repackage it. The CopyDmg is so easy though  :)

So, I guess the piece that I didn’t realize is that you copy items at the bottom of the list first. Correct?

I’ll give that a try.

[Greg Neagle]

On Oct 12, 2010, at 11:06 AM, Gary Bernstein wrote:

So, I guess the piece that I didn’t realize is that you copy items at the bottom of the list first. Correct?

No, top to bottom...

First, Adobe-KCPA to /Users/Shared

Second, Adobe-KCPA/com.adobe.118.registration to /Users/Shared/Adobe-KCPA/

Third, Adobe-KCPA/com.adobe.acrobat.90.sh.plist to /Users/Shared/Adobe-KCPA/

Last, KCPA-FixAdobeSelfHealRegLoginScript.sh to /Applications/Utilities/KCPAScripts/LoginItems/

And now that I re-examine your original list, you were doing:

First, KCPA-FixAdobeSelfHealRegLoginScript.sh to /Applications/Utilities/KCPAScripts/LoginItems/

Second, Adobe-KCPA to /Users/Shared

Third, Adobe-KCPA/com.adobe.118.registration to /Users/Shared/Adobe-KCPA/

Fourth, Adobe-KCPA/com.adobe.acrobat.90.sh.plist to /Users/Shared/Adobe-KCPA/

which should have been functionally equivalent.

I guess I need to see a log...

-Greg

[MiqViq]

Here is an example how I got copy_from_dmg working so that all items
have separate permissions even if files are still to be located within
the same directory.

1st item is a directory which contains an .app.

2nd item is "pretending to be some sort of fix" for that MyApp.app,
root:wheel and no permissions for anybody else (just for the sake of
proving it works).
Munki sets the permissions correctly even if that item was within the
item that was copied during the same munki-run.
This means that munki really copies items (and sets their permissions)
in the exact order they are presented from top to bottom within
copied_items-array.

3rd item is just a text file with rw-perms for all users.

<key>items_to_copy</key>
<array>
<dict>
<key>destination_path</key>

<string>/Applications</string>
<key>source_item</key>
<string>MyApp</string>
<key>user</key>
<string>root</string>
<key>group</key>
<string>80</string>
<key>mode</key>
<string>ug+rwX,a+rX,o-w</string>

</dict>
<dict>
<key>destination_path</key>

<string>/Applications/MyApp/MyApp.app/Contents/Resources</string>
<key>source_item</key>
<string>FixForMyApp.txt</string>
<key>user</key>
<string>root</string>
<key>group</key>
<string>0</string>
<key>mode</key>
<string>a-rw,u+rwX</string>

</dict>
<dict>
<key>destination_path</key>

<string>/Applications/MyApp</string>
<key>source_item</key>
<string>Testfile.txt</string>
<key>user</key>
<string>root</string>
<key>group</key>
<string>20</string>
<key>mode</key>
<string>a+rwX</string>
</dict>
</array>

But when things get complicated enough then it may be better just
build a package for it, then you have item which can be deployed using
ARD and other pkg-compatible methods.
As far as I know this copy_from_dmg-functionality is quite unique and
probably exists and works only in munki.

-MiqViq

> --
> You received this message because you are subscribed to the Google
> Groups "munki-dev" group.
> To post to this group, send email to munk...@googlegroups.com.
> To unsubscribe from this group, send email to munki-dev+...@googlegroups.com
> .
> For more options, visit this group at http://groups.google.com/group/munki-dev?hl=en
> .

[Greg Neagle]

Yes - the intent behind appdmg and now copy_from_dmg is to be able to use existing disk images from vendors that expect a drag-n-drop install.

If you are creating something from scratch, and it is more complex than "drag a single item from here to there", you are probably better off building a package rather than trying to get copy_from_dmg to do what you want.

-Greg

>>>> <string>/Applications/Utilities/KCPAScripts/LoginItems</string>

>>>> <string>Adobe-KCPA/com.adobe.acrobat.90.sh.plist</string>

>>>> <key>user</key>
>>>> <string>501</string>
>>>> </dict>
>>>> </array>
>>>

>>> <string>/Applications/Utilities/KCPAScripts/LoginItems</string>

>>> <key>group</key>
>>> <string>admin</string>
>>> <key>mode</key>
>>> <string>o-w</string>
>>> <key>source_item</key>
>>> <string>KCPA-FixAdobeSelfHealRegLoginScript.sh</string>
>>> <key>user</key>
>>> <string>501</string>
>>> </dict>

>>> </array>
>>>
>>> And as for that last item, the directory /Applications/Utilities/KCPAScripts/LoginItems must already exist.

[Nate]

I ran into this same issue setting up the Adobe Update Server Override file.  I originally was going to use copy_from_DMG, but some machines didn't have the full path that the override needed to go in, so I ended up using a .pkg instead and it solved that problem for me.  I use copy_from_dmg for various other things, but if the folders don't already exist, I am going to just use a .pkg to make my life easier.

Nate