AutoPkg download recipe for downloading a .app

[John Lockwood]

For eminently sensible reasons most software updates are hosted on websites as either a .pkg, a .dmg, a .zip, or a .tar.gz, that is as a single file.

In this case I am hoping to create a recipe to download the PaperCut client from an internal PaperCut MF server and the client is stored on the server as a standard directory with the standard .app extension.

As it is a Linux server the full path is as follows.

/home/papercut/client/mac/PCClient.app/

This can be downloaded via scp, ftp, smb, etc. but not CURL as CURL does not support recursive downloads unlike WGET.

I had originally hoped to use CURL which is what AutoPkg uses before discovering this. I would much prefer not to use smb or ftp but would be ok with using scp and willing to listen to other suggestions. The preference is to minimise the amount of setup required on the Linux server, it does have Apache already installed and running.

As this is an internal server to which I have full access I am considering a fallback to creating a script to automate creating a zip archive or similar on the server and then would be able to download that.

For those unfamiliar with PaperCut it is a commercial printer management solution which can be run as a server on a Mac, Linux or Windows system. The way it is distributed is as a server installer and this when it installs the server auto creates the above referred to client directory with the expectation that admins would manually copy and distribute the clients. I am hoping to still manually upgrade the server as needed but then automate downloading and distributing the matching client.

I can easily manually add the PaperCut client to Munki but would like to automate this.

[Elliot Jordan]

Seems to me it would be wise to follow convention and compress the hosted app (as zip, dmg, or pkg) so it can be downloaded as a single file. This might avoid issues with file permissions, intentionally empty files/directories, and extended attributes like com.apple.quarantine. I've never heard of a compelling case to do otherwise.

Elliot

--
You received this message because you are subscribed to the Google Groups "autopkg-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to autopkg-discu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/autopkg-discuss/d32255ac-1224-4ce2-9f6e-f8eeb85fd982n%40googlegroups.com.

[Nick McSpadden]

I agree with Elliott, but barring that, you could write a custom processor that downloads it with a tool of your choice. This would likely be customized to your environment, but it would allow you to design the best solution for your needs.

This does require some light Python programming skills to create a processor, but AutoPkg itself doesn't have a better solution built-in for you.

To view this discussion on the web visit https://groups.google.com/d/msgid/autopkg-discuss/CADefdwg4uf0dfmazpZVPFik8%3DEXCTS2UVA2R_6Gp77FB2nDLBQ%40mail.gmail.com.

--

--
Nick McSpadden
nmcsp...@gmail.com

[John Lockwood]

I have created a cron job to automate creating a zip of the client on the Linux server.

I have also created download, pkg and munki recipes.

I have not yet tested the resulting pkg as I ran out of time today but it looks ok so far. I am also working on using the pkg recipe to build preinstall and postinstall scripts. Either the pkg recipe or the postinstall script also needs to generate a LaunchDaemon as this is not included in the app itself and I experimenting on this. As the LaunchDaemon plist is XML this is more complex to directly do inside a recipe.

[Elliot Jordan]

You could use FileCreator or PlistEditor to create a daemon. There's an example of that here.

Elliot

To view this discussion on the web visit https://groups.google.com/d/msgid/autopkg-discuss/0ee68759-f34d-4fe1-b241-3d503b975933n%40googlegroups.com.

[John Lockwood]

I had already tried FileCreator and I am using this for the preinstall and postinstall scripts, but because a launchdaemon is a plist itself this caused problems. I have not yet tried PlistEditor, I looked at the example you linked to and it does indeed look ideal for this.

Thanks for the tip!

[Graham Pugh (Gmail)]

PlistEditor is the right way to go here, but if you do ever find yourself needing to create files containing XML-type encoding, it's a lot easier with YAML-based AutoPkg recipes rather than PLIST-based recipes.

Best wishes, 

Graham

To view this discussion on the web visit https://groups.google.com/d/msgid/autopkg-discuss/c55e8658-36a1-4bce-b9a7-073a32010b4dn%40googlegroups.com.

[John Lockwood]

Thanks Elliot I have the PlistEditor processor working now. I have also successfully tested the resulting installer pkg.

I have one more thing I would like to try which is to have the recipe edit a text configuration file that is inside the Application at -

PCClient.app/Contents/Resources/config.properties

Note: As I am downloading a zip containing this app and expanding the zip in order to convert it to an installer package I have the app already available to my recipe and in fact already read the version from the app's Info.plist

I would like to be able to find and replace a string in this config file using recipe variables. This would be easy to do using a shell script and one option I am considering is to indeed add this to my postinstall script but I thought I would ask if there are any processors which allow editing text files as opposed to Plist files.

Sadly PaperCut do not use a plist format for this file.

[Elliot Jordan]

Assuming editing that file does not break code signature verification, you could either use FileCreator or FileCopier to put a fully-finished properties file into the app during packaging, or you could use a postinstall script to make the minimum modifications needed to the file after installation as you said.

Sounds like MDM configuration profile support might be a worthwhile feature request to the vendor, too.

Elliot

To view this discussion on the web visit https://groups.google.com/d/msgid/autopkg-discuss/202cdc66-f03c-4acb-867b-75a3ad33a8e6n%40googlegroups.com.

[Nick McSpadden]

Given that this is PaperCut we're talking about, we're more likely to experience the heat death of the universe than any reasonable configuration options.

A common pattern a lot of recipes adopt is putting in a finished version of the file already in the recipe folder, and then, as Elliott suggested, using FileCopier or incorporating it into the PkgCreator request. There's a lot of different ways to approach it with AutoPkg's flexibility, and simply pre-including a finished correct configuration is a very easy solution.

To view this discussion on the web visit https://groups.google.com/d/msgid/autopkg-discuss/CADefdwiYvMXHmr%2BxPkn2B6usqYAD1sw3Ufuue%2B4Gy8ii7sQPag%40mail.gmail.com.

[John Lockwood]

I totally agree with you Nick about the chances of PaperCut moving to a more sensible preference file format. :(

They still have not even done an Apple Silicon version of the Mac client! See - https://www.papercut.com/kb/Main/KnownIssues-macOS/

For anyone interested I have now finished and got my recipes working, thanks everyone for your help with this. If you are interested the recipes are on my repo at https://github.com/jelockwood/recipes/tree/master/PCClient

I have designed my download recipe so that it is not hardcoded to a specific URL and you can therefore adapt it to your own using the override recipe mechanism.

[Elliot Jordan]

I would recommend naming the files PaperCutClient.download.recipe (for example) instead of PCClient, for the benefit of those who search. 

Elliot

To view this discussion on the web visit https://groups.google.com/d/msgid/autopkg-discuss/4d951064-38cd-4923-af87-921e2a3cbe6fn%40googlegroups.com.