So we just discussed why we need to synchronize our monkey servers if we have multiple monkey servers
in different locations, so now we need to talk about how do we actually synchronize the servers?
Well, as we've discussed, a monkey server really is just a Web server.
So there's going to be a lot of ways that we can do this.
And so if you're on windows, you might be running iOS and you can run a program called Robocopy to
then synchronize the data from one monkey server to another.
And you could use scheduled tasks so you could schedule when this synchronization happens.
Now, in my demonstration, I'm going to be running a Web server on Linux using Apache.
And what we're going to do is we're going to use ECES H to access the remote monkey servers.
We're going to use our sync to synchronize them, and we're going to set up a cron job to schedule the
synchronization.
So in this section, I'm going to explain what SFH is and I'm going to go ahead and use our Max instead
of our Linux servers.
So you can see over here, I have remote log available now, remote login on a Mac refers to as his
age so he can even see over here, it says, to log into this computer remotely type as age.
All right.
So to log in remotely, not only do you have to have remote logging on, but you need to know the IP
address or the hostname of the machine.
So let's go ahead and log in with the hostname.
So I'm going to type in SFH administrator at and then 10 dot two to four point fifty two, one, two,
three.
And it's going to want my password, which I'm going to go ahead and enter.
And now you can see that my prompt in the shell change from administrators Mac to the hostname of my
remote computer to further demonstrate that I'm walking to machine.
What I'm going to do is I'm going to go ahead and I'm going to go and remove the DLC application.
And so you look at the VLCC icon, you will see that it disappears.
So you know that I'm actually logged into that machine.
If we're going to run a script, then how is the script going to enter the username and password?
Well, to get around that problem, we're going to use what are known as keys.
So I'm going to go ahead and log out and you can see I'm back on the administrators Mac Pro Computer.
And what I'm going to do is I'm going to type in SS HQ.
And what that is going to do is it's going to generate a private and public key for my computer and
myself as a user.
Go ahead and hit the enter for the default path and then do not enter a passphrase and now it's generated
a public and private key.
All right, so what we need to do is we need to get our public key on the computer that we want to log
in remotely to.
So to do that, you are going to run SS copy ID and then the same send text to log in to the machine
remotely as SSA.
So administrator at 10 dot two to four fifty two, one, two, three.
And so now it's going to try to copy your public key to that computer and it's going to want to know
the password so it can actually copy it.
I'm going to go ahead and type in my password and now it's copied my key.
So as you can see, I am still logged in as to my computer and now if I type in SS age administrator.
At ten point two to four, fifty two, one or three, I get logged in instantly.
All right, so how does this work exactly?
So if I go to.
My SS folder, and this is on the remote machine, you can see that I have something called authorized
keys, so if I go ahead and look at that file.
You can see that that's a copy of the public key from the administrators machine.
So if this public key matches the public key on the machine from which I'm logging in from, then it's
going to let me in.
Now, if I delete this public key or if my public key changes, I will no longer be able to log in remotely
without a username and password.
So if I go ahead and then let's say Irem, I remove this authorized keys and then I log out and then
I go ahead and try to log in again.
It's asking me for a password.
If I log out and I go through the copied process again.
Then I get in without being asked for credentials and I can keep on doing it and I will get in every
single time, so that's how it works and that's how SS works with keys.
And what we're going to want to do is since New York is our master server, where we're going to be
connecting our monkey admin tools to, we want the New York server to be able to log into the server.
And since we're going to be running scripts, we're going to want the New York server to copy its public
key to the server.
So the New York server can log into the server without credentials.
So next, we're going to go ahead and talk about how our sync works over S.H..
All right, so to help learn what our sink is, we're going to go ahead and do a little demonstration.
So as you can see, I've created two folders, one New York, one L.A. to illustrate how we can synchronize
between the two computers.
So I'm going to go ahead and create a directory path in New York and we'll call it folder one folder
to folder three.
And so what that does is that gives us a few sub folders.
All right.
So if we want to make L.A. exactly the same, then we're going to do in our sync between New York and
L.A. And if we go ahead, we can see that now they match completely.
Now, let's go ahead and in L.A., let's go ahead and delete.
Folder two in below.
And now we're going to go ahead and run the exact same arcing command.
And everything comes back, so we're keeping the two sides in sync.
OK, so let's go ahead and let's remove in New York.
Let's go ahead and remove folder three.
All right, so folder three is gone, and let's do a link between the two sites and as you can see,
that Folder three is still in L.A. So what happened?
Well, in our sync, there are many, many, many options.
And one of those options is a delete flag.
And so what that means is if something.
Gets deleted on your master machine, which is our first location, then go ahead and replicate that
to our target machine, which in this case is L.A. So if I go ahead and do this now, then folder three
gets removed.
OK, so now that you understand how our sync works, what we're going to do next is log into our Web
servers and run our sync over S.H..
All right, so now we're logged into our New York monkey server, which, again, is our master server.
And before we go ahead and look at the code to sync with L.A. over s h, let's go ahead and take a look
at the folder layout of our Web server.
So if I do an Excel, it's bar of U h html and then monkey repo and you can see that this takes us to
our catalogs manifest in package folder.
All right.
So we're going to need this path and our script because this is where we're going to copy from.
All right.
So we're going to go into a Shell script called Pacific Dot S.H. and that'll make more sense when we
start talking about Chron.
All right.
So in this code, we've got a couple of our sync lines that should look familiar.
So we have our sync with a options which we had before, and we're adding E, which is going to execute
in each session.
And we're going to use this as our source file.
We're going to use our monkey repo, but our package is subfolder and that's going to be our source.
And we're going to copy that, too, by logging in to root at L.A. Monkey one.
And we're going to go to that machine's path of their monkey repo.
So what we're doing basically is we're taking the packages folder from Monkey Repo in New York and we're
basically synching it to the root folder of the monkey repo.
So basically, you're getting the packages folder in all of its contents and you're synching it to the
root of monkey repo, which is where we would want the packages folder to be.
And then I have progress, which just basically gives you output of the files copying.
So if you run it interactively, you'll see the progress and then exclude the store.
I just basically don't have it sink all the little hidden files that the Mac OS creates on the file
system.
And so if you notice, we're doing the packages folder first and then we're sinking the entire repo
after.
Now, the reason for that is simple is that if you change a manifest and you want it to now install
something and that package hasn't yet synchronize to your target monkey server, then when your monkey
clients run, it's going to be looking for software that it can't download.
So if we copy the packages first, then when it copies the manifests, then all the packages will be
there and that won't happen.
All right.
So what we're going to do now is we're going to go ahead and quit and we're going to go ahead and run
this.
And you can see that nothing has happened.
So what I'm going to do now is I'm going to go ahead and assess into Monkey in L.A. and I'm going to
go into the.
The packages folder, and I'm just going to go ahead and let's get rid of the VLCC press package file,
and now I'm going to log out of L.A. Now I'm in New York and I'm going to go ahead and run the script
again.
And you can see that the only file that it copied is the DLC press.
So now that we know that our Shell script works, let's go ahead and use Chron to schedule it at a specific
time.
All right, so to schedule our scripts to run Vacheron, what we need to do is we need to type crosstab
E to get to our crosstab editor.
And so how this works is basically you set up the hour in minute that you want your script to run.
So in other words, the twentieth hour, zero minutes, so eight o'clock PM and then this is a variable
meeting every and so what we want to do is we want to run this every day, every month, every day of
the week.
And this is the path to our script.
So at eight pm and then nine p.m., 10 p.m. on 11 pm, we're going to run the respective scripts, which,
as you saw earlier, are scripts to synchronize our New York server with our servers in those respective
time zones.
And so the last thing that I want to point out when it comes to replication is during this class, we've
basically been using monkey admin to manage our New York server.
And every time we save something on that New York server, we have clients attached to that New York
server.
So in a production environment, you're probably not going to want to work in this way.
So what you can do is, is you can have a master monkey server where no clients check into it, or you
could have that master server just have test clients check into it.
So if you're monkey admin tools are pointed to a parent server and there are only test clients and you're
working with your test clients and you know you're ready for replication, then your monkey master server
will then replicate when it has its current job scheduled for.
And if you do things that way, then, you know, your monkey master server set up correctly because
your test machines work and then it's going to replicate out at the time you specify to your locations
and then your monkey clients that attach to those locations are only going to install new packages after
your specified time.