@george1421 George hooked me up after sending him a screenshot. Turned out to be something incredibly simply on my part–search scope was set to “Base and Subtree” instead of “Subtree and below”. I seriously compared these side by side I don’t know how many times, but my brain was not seeing that difference for some reason.
Really appreciate the help!
@Tom-Elliott
Sure thing. Here’s the error message I’m getting when attempting to save the new path:
http://i.imgur.com/UEiMOQ3.png
Here you can see I’ve changed the folder name at the file system level:
http://i.imgur.com/yenv9eH.png
And here you can see that there are no other images in the database using that path:
http://i.imgur.com/L2kW3dk.png
@Tom-Elliott
Finally got a chance to give this a go. Upgraded to 1.4.4, but with no change–I’m still unable to save the image with the new image path.
On a perhaps related note, I never did get prompted to update the database when I navigated to http://<IPAddress>/fog/management as instructed by the installer. Not sure if this is expected behavior with this release, but that’s the first time I’ve seen that.
@Tom-Elliott Shouldn’t be a problem, I’ll update by end of the day today.
@Wayne-Workman
Let me clarify further. I’m aware of the process you’ve outlined here, but that’s not what I’m trying to do. We’re not moving our /images folder, I’m just trying to rename a folder for an image that’s in our /images folder. I’ll walk through exactly what I’m doing:
1.) Rename folder in /images in the OS. In this case I’m renaming “/images/Lenovo_T450” to “/images/Lenovo_T450_W10ENT” .
2.) Log into the FOG web GUI and browse to Image Management–>List All Images–>(Image indicated above).
3.) Change the Image Path field from “Lenovo_T450” to “Lenovo_T450_W10ENT”. Click Update.
4.) After clicking update, I get the error message “Please choose a different path, this one is already in use by another image.”
My point is that that image path is not in use by another image. I’ve verified that with the SQL query I mentioned in my original post. The web GUI seems to think that image path is already in use though.
@Wayne-Workman I’m sorry, I’m not sure I’m following. Which command? I’m trying to change the path via the GUI. The SQL query I ran to verify the path didn’t already exist was “Select imagePath from images”.
I’m trying to cleanup our image names and paths a bit. When trying to change the image path for a particular image I receive the error “Please choose a different path, this one is already in use by another image.” We only have seven images on this FOG server and I’ve verified with all other images that this path is not being used by any of the others. I’ve done this same process for several other images without any issues.
I thought perhaps there might be an image that got orphaned in the images table. Running the query “select imagePath from images;” returns a list of all image paths, none of which match the path I’m trying to change this image to. The number of returned rows also matches the number of images we currently have visible in the GUI as well, so no orphaned image definitions.
Any other ideas on what might be going on here and how I can get this image path changed? I supposed I could update directly in the database, but thought I’d check here before I went that route.
Thanks!
A few quick questions about actually adding the nodes:
1.) On the “Add Storage Node” page, is the “Interface” field asking for the interface of the storage node you are adding or the interface for the FOG server you are adding the node to?
2.) Similar question, but this one I think I already know the answer to, but want to clarify: Is the Management Username/Password asking for the node you are adding?
@Tom-Elliott
Fantastic, thanks!
We’re scheduled to make these changes this weekend, so we’ll see how it goes. Might be back Monday with more questions. 
@Tom-Elliott said in Replicating images to other FOG servers:
- Is it possible to set the frequency and start time of replication? Ideally we’d likely want it to only run once a week, preferably over the weekend.
There’s a couple of ways to handle this. The simplest method would be to set a cron job that starts the FOGImageReplicator and FOGSnapinRepicator services say on saturday morning, and another set that stops the services Sunday evening (or whenever you feel it should stop.) The next method requires a bit more involvement, but should work without needing to worry about a cron job that is handling things. Set the “Timeout” to: 604800 seconds for the Image and Snapin replication cycles. This method is bound to have some problems, but essentially will only make the images replicate once a week, dependent on when the service is first started. So if you start the services on Monday, next Monday will be the time they re-check. This is why I suggest using the cron cycle as you can ensure it only occurs on Saturday/Sunday as needed. Mind you, however, images and snapins check if they need to be updated, so while there is a little bit of network chatter during the checking phase, it’s much less bandwidth usage than full on replications.
Great, I think this mostly answers part of my follow-up question above actually. I see now after just looking at the output of a “top” command that these services are always running. The logic of starting/stopping them as needed via cron makes sense.
I am still curious about default behavior though just for reference. If we did absolutely nothing with regards to scheduling, how frequently does replication occur?
- How do you check the status of a running replication job?
Replication is tracked by the relevant service. You can look in the replication logs and it will show you if the replication is still working (when it started it last vs the next check cycle). It will tell you the PIDs of the replication being performed. It should not try replicating anything if the tasking is already running during its check.
Great info, thanks.
- If possible, how do you stop/pause/resume a running replication job?
There really isn’t a way, unless you stop a replication from the process that’s actually performing the work and even then this isn’t guaranteed to work as you might expect. The processes do attempt to “recover” on their own, but the way the replication elements work it’s simpler, often times, to actually remove the remote file and transfer the whole file from scratch.
As I mentioned above, pretty much what I expected, but figured it couldn’t hurt to ask.