+4Im looking to setup a dev environment for staging purposes. I'd like to have my primary JSS replicate its database to a dev JSS keeping that database "current" Here we could enroll clients, test policies, packages, ect before rolling it out globally.
I know we can script this out doing SQLdumps or a Master/Slave relationship but I was hoping someone else has tried this and could provide some insight.
+18why do you need to keep the databases in sync?
in my dev environment dev machines only talk to the dev server, production machines to the production server.
or we have created a dev group inside the production server in some of our customer sites and just done all dev on one server.
Whats the goal of the dev server, to test upgrades of JSS, or just to allow dev machines access to new packages for testing?
+4It’s more for testing updates to the JSS. We want to keep the dev database in line with production as we are making changes to the live database regularly, and want a representative server for testing updates to the JSS before rolling out to production.
+18see i would think if you have the same list of hosts, the server could try talking to the clients and get the clients talking to the wrong server, not sure if that could happen though. I keep my lab environment and the clients connected to it totally separate so that there is no confusion. test most of our policies and such in the new environment and then duplicate those actions over the production server, and i always keep the lab at the latest version of jss. so i can see if there are any problems. update production as needed.
I suppose to each their own. I would check with your support person about duplicating the database because i would think thats pretty much going to act like a server migration and take over clients, and then production would take over again and it would be a big mess in no time at all.
+13@nessts In what scenario does the server talk to the client? The system won't check in with the old JSS where it is no longer enrolled.
We don't have a great way of keeping things in sync here. We did restore the prod DB into a dev environment, and then go back and update the pertinent settings (like JSS URL, DP's, clustering, so on), but now we just create the policies and packages in both places manually. I don't know if there's a better way without some manual SQL wizardry for instance.
+18you are right @JPDyson in my lack of thinking yesterday i was thinking the new agent would get pushed to the client machines, but that only happens when the machine checks in.
But if the dev environment does not talk to any machines whats the point in it?
+38As far as syncing policies from a test environment to production, @brysontyrrell has a project he's been working on called Promoter:
http://bryson3gps.wordpress.com/2013/12/15/introducing-promoter-v0-9/
Promoter is supposed to allow the migration of a policy from a test environment to a production environment.
It may not help with syncing the databases, but it will once you have them synced.
+17We tried syncing to a backup database - more for hot spare disaster recovery - but it ended in frustration when replication just stopped randomly sometimes. JAMF pointed us in the right direction and one of our database admins helped with the mysql code to get it set up. When it didn't work right they said it had to do with us going from mysql on OSX server to mysql hosted on a windows VM (different versions). It might work fine for you if you had similar environments.
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.