Upgrading

98 views
Skip to first unread message

Shane Pinnell

unread,
May 13, 2013, 3:28:36 PM5/13/13
to simian-...@googlegroups.com
What are the steps for upgrading? I followed the available instructions for installing which installed 0.8.3.1663 but it looks like an SVN checkout gets me 0.8.4.1770.

Now I have some clients reporting as 0.8.4.1770 and some as 0.8.3.1663. Do I need to update the server and the clients? Is the client update as simple as using Simian to push the updated client installer?

Thank you in advance for any information.

Justin McWilliams

unread,
May 13, 2013, 3:38:36 PM5/13/13
to simian-...@googlegroups.com
Shane,

In general, it's always safer to update the server first, and clients second.  We make sure that newer server releases are compatible with older clients, as some clients may be offline for months at a time.  However, the reverse is not true; occasionally client changes are incompatible with older server releases.

As far as upgrading clients, yes.  Just build a new Simian client dmg, and deploy it to clients you wish to update (using Simian).

- Justin


--
You received this message because you are subscribed to the Google Groups "Simian Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to simian-discus...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

Shane Pinnell

unread,
May 13, 2013, 3:43:45 PM5/13/13
to simian-...@googlegroups.com
Thanks for the quick reply... Is the server upgrade as simple as SVN checkout, copy PWD/etc/simian/settings.cfg and then make release?

Justin McWilliams

unread,
May 13, 2013, 3:49:15 PM5/13/13
to simian-...@googlegroups.com
On Mon, May 13, 2013 at 12:43 PM, Shane Pinnell <shane....@puhsd.org> wrote:
Thanks for the quick reply... Is the server upgrade as simple as SVN checkout, copy PWD/etc/simian/settings.cfg and then make release?

Yep, that should do it. 

Optionally, to be on the safe side, you can modify the "version" in app.yaml:


Then push a release and visit http://<version>-dot-<appid>.appspot.com  to test the new release before making it default for all of your clients. In the App Engine Admin Console -> Versions you can choose which version is default for clients, and by default Simian is always set to "1".

Using this, you can use the Version UI to switch the default version your clients hit.  So you can test in the background, with the above URL (version-dot-appid), switch the default to that version once tested, and change the default back to the previous release if you find any issues in production.

Make sense?

Shane Pinnell

unread,
May 13, 2013, 4:29:34 PM5/13/13
to simian-...@googlegroups.com
Server upgrade seems to have gone well, is there anywhere on the Simian server where the running version is listed?

As for the client upgrade, when I run "make dmg" it is generating:

simian-2.1-and-munkitools-0.8.3.1663.0.dmg

instead of what I expected which would be:

simian-2.1-and-munkitools-0.8.4.1770

Am I missing a step? Do I need to update munki first?

Again, thanks for the help!

Justin McWilliams

unread,
May 13, 2013, 4:42:43 PM5/13/13
to simian-...@googlegroups.com
The Simian server does not list the version running anywhere; perhaps we should add this to the Configuration page.

To build a Simian client with a newer version of Munki, type the version you desire in the Makefile here: https://code.google.com/p/simian/source/browse/trunk/Makefile#11

We tend to only update this when we release new Simian source.

Shane Pinnell

unread,
May 13, 2013, 5:11:43 PM5/13/13
to simian-...@googlegroups.com
Having that on the configuration page would be great, maybe the Simian and Munki versions separately?

I must have installed and upgraded Munki on the 2 clients that are reporting a newer version, maybe I will just leave it be until a new Simian release.

Thanks so much for the help, so far I really like Simian and I think it will really help us out. We are rolling out new Macs to our teachers over the summer and being able to manage them easily is a key hurdle for us.

Shane Pinnell

unread,
May 13, 2013, 7:05:27 PM5/13/13
to simian-...@googlegroups.com
The following is mostly for posterity's sake...

I succesfully updated the server and modifed the makefile to use an updated version of Munki. Now when I run makepkginfo for the package using:

simian-0.8.4.1770/trunk/simian-2.1-and-munkitools-0.8.4.1770.0.dmg

Resulted in a plist with the following key:

<key>installer_item_location</key>
<string>simian-2.1-and-munkitools-0.8.4.1770.0.dmg</string>

This fails with an error when attempting to upload the package file to the Simian server:

PackageInfo not found

Changing the above string to simple "Simian" and uploading a new package works. I guess the PackageInfo Plist (XML) doesn't like all the special characters?

Again, thanks for all the help!

Justin McWilliams

unread,
May 14, 2013, 4:36:25 PM5/14/13
to simian-...@googlegroups.com
Shane,

The "installer_item_location" in the uploaded plist, and the file uploaded must match, but there shouldn't be any  issues with alphanumeric characters, dashes, or periods in filenames.  We have many packages with names like this.

Are you sure the pkginfo you originally uploaded included the same name?  Did you rename file in the plist and the DMG on disk which you uploaded to get this to work?

- Justin
Message has been deleted

Shane Pinnell

unread,
May 14, 2013, 5:51:49 PM5/14/13
to simian-...@googlegroups.com
I just confirmed the steps I followed:

1. make dmg
2. makepkginfo
3. create "New Package"
4. Paste contents of makepkginfo
5. Attempt upload of dmg

And I get the error:

PackageInfo not found

Justin McWilliams

unread,
May 17, 2013, 1:13:10 PM5/17/13
to simian-...@googlegroups.com
Would you mind sharing the pkginfo, after removing any potentially
sensitive data within? Feel free to send directly to me if you wish.

I haven't tried this from source head, but I can't reproduce on my dev
instance that's running a few revisions behind head. No recent
revisions seem related.

- Justin
Message has been deleted

Shane Pinnell

unread,
May 17, 2013, 3:29:11 PM5/17/13
to simian-...@googlegroups.com
So sorry, I can't recreate the problem now either. Maybe this was related to quotas on the free instance? After switching to a billable instance things seem to run a little more smoothly.

nbalonso

unread,
Jul 10, 2013, 5:25:35 AM7/10/13
to simian-...@googlegroups.com
Is there a plan to embed the version number in each build and use that when generating the app.yaml? I see this as a benefit for testing newer Simian versions without interrupting the production version.

Noel

Justin McWilliams

unread,
Jul 10, 2013, 8:53:47 AM7/10/13
to simian-...@googlegroups.com
Yes!

https://code.google.com/p/simian/source/browse/trunk/src/simian/mac/app.yaml#2

"version" can be any arbitrary string. You can access that version by
visiting ("-dot-" is an actual string):
http://<versionstring>-dot-<appid>.appspot.com:
https://developers.google.com/appengine/docs/python/#Requests_and_Domains

Then, in the App Engine Admin Console you select a version and click
"Make Default" for all traffic to hit that version, or you can split
across multiple versions for canarying:
https://developers.google.com/appengine/docs/adminconsole/trafficsplitting#Adding_and_Configuring_Traffic_Splitting

Let us know if this works!

- Justin
Reply all
Reply to author
Forward
0 new messages