Posts made by aparker

@Tom-Elliott
That did the trick, thanks!

@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”.

Server

• FOG Version: 1.4.3
• OS: Ubuntu Server 16.10

Client

• Service Version: N/A
• OS: N/A

Description

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:

@aparker

1. 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?

2. 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.

3. 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.

What you need to do is have a cron job to manage the start and stop of the FOGImageReplicator service. Start and stop it at your command.

Understood, I’ll explore this option. Any good references for creating/managing cron jobs in Ubuntu? While I’m aware of what cron is, I’ve never used it.

But just so I understand this process better conceptually, what is the default behavior? Does FOG call this FOGImageReplicator service on it’s own at a predefined interval? Is there anything I need to do to keep that from happening?

2.) How do you check the status of a running replication job?

Via the replicator log files in /opt/fog/log

Perfect, thanks.

3.) If possible, how do you stop/pause/resume a running replication job?
This is a problem. Yes you can stop a replication session. The replicator will exit, but you could have a partial replicated (damaged) image since the replication happens on a file by file basis. You won’t really know its broken until you try to deploy. No you can’t pause/resume. Its replicated on a file by file basis. If the whole file didn’t get there last time it will resend the file.

This is about what I expected honestly, but figured it was worth asking.

I finally got a chance to put some more thought into this last week and consult with a few others involved. We’ve ultimately decided to go with the multi-master model. We’re basically going to just add the two “child” sites to the existing storage group of the “master” FOG server and handle the image definition import/export manually. If I’m absorbing all the previous info correctly, I think this will accomplish what we’re looking to do. I suspect this will be the easiest to implement without making major changes to our current FOG environment and this option most closely aligns with what our Helpdesk team is looking to accomplish with images.

That being the case, I’ve got a few questions specifically about replication:
1.) 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.
2.) How do you check the status of a running replication job?
3.) If possible, how do you stop/pause/resume a running replication job?

Thanks again for all the help. Everyone’s responses and guidance have been extremely helpful!

Thanks Wayne and George, both extremely helpful responses. I’m largely following both of you, but I may still be a bit confused by the ramifications of captures based on each scenario, as the information about captures seems to contradict (or I’m missing a key point/distinction). I’ll come back to that in a minute, but let me see if I can summarize my options based on what you’ve both suggested:

Option 1
Add each FOG server to it’s own storage group, each becoming a master of it’s own storage group. Images would be shared with other groups as needed. Captures would not cross the WAN since captures are always uploaded to the master in the storage group

Questions:
1.) Isn’t this essentially what you end up with when you have three independent FOG installs? By default a FOG server is added as a node to it’s own storage group, correct? I could see needing to modify the names, but isn’t the infrastructure essentially already in place?
2.) Via what mechanism is an image shared ? You mentioned it was done per-image inside image management on the master, but I honestly don’t recall seeing any verbiage related to image sharing.
3.) Does the act of sharing an image to a storage group cause that image to be replicated to that/those group(s)?
4.) In this scenario, would replication be happening in multiple directions, depending on where (or what storage group) the image was shared from?
5.) This method would not require manually creating image definitions, correct?
6.) Is the location plug-in even required for this particular setup? If I’m understanding correctly, since FOG always looks to the master node for both capturing and imaging, no FOG traffic should traverse the WAN.

Option 2
Add the two slave FOG servers as storage nodes to a single storage group (the existing storage group on the master FOG server). This would result in a single storage group containing all three FOG servers. Image definitions would need to be exported from the master server and imported to the slave servers manually (and whenever a new image is added to the master FOG server). The location plug-in would be required to ensure capturing and imaging occur from the correct FOG server.

Questions:
1.) What does the image definition export/import process look like? How is that done?
2.) How does FOG know which server is the “master” since these are all normal installs and all FOG servers are in the same storage group?
3.) Wayne, you mentioned that the location-plugin doesn’t alter the behavior of captures. George indicated that the location plug-in would help determine which FOG server would be used. Am I missing something? I will say the location plug-in documentation does seem to indicate that it does change the behavior of captures. Under the Catpures–>With Location Plugin section it indicates that it fill find the locations group master, then use it to perform the capture (but maybe not store in the right location?). I have a feeling this isn’t actually contradictory and I’m missing some important distinction.

All told, I think I’m leaning towards Option 1. I like that it doesn’t appear to require manually updating image definitions. The flexibility also seems nice.

Lastly, I’ll throw out one other possible option–I could probably swing building my environment again from scratch if that is truly the best option. Would there be any advantage to truly starting over and moving to a model with one true master FOG server with two storage FOG servers?

Our organization is currently running three completely independent, normal FOG servers in three geographically separate locations. They have operated independently for several months, but we’d like to unify the images across all FOG servers. We’re looking to designate one FOG server as the “master” FOG server. Users of FOG in this location will perform all image capture tasks. These captured images will then be replicated on a schedule to to the two other FOG servers, where users of FOG in these locations will image computers with these images.

From my research, it appears this is possible via storage nodes and the location plug-in (summarized very well here). What is described in that wiki article is essentially what I’m looking to accomplish. I’d like a few points of clarifications though:

1.) All three existing FOG servers are “normal” installs as opposed to “storage” installs. Can I make this work as-is? Or do they need to be converted in some way to a storage install?
2.) What’s the storage node setup look like? I haven’t been able to find much documentation on what exactly needs to be done here. It appears that each FOG server has a “default” storage group and a “DefaultMember” storage node. Would I just add the two downstream FOG servers as storage nodes?
3.) We want to make sure that no capture or image traffic goes across the WAN. This is indeed possible with the location plug-in, correct?

We’re currently running FOG 1.3.4. on all FOG servers (and I’m not opposed to upgrading if there is a compelling reason to do so). Any guidance would be appreciated!

@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!

@george1421 No non-ascii characters in the DN or user account. I just tested a known good LDAP server, but still no dice. I even went so far as to change one of the working FOG servers from the domain FQDN to the IP of a local DC and confirmed it worked. I then used that same DC in the non-working FOG LDAP config, but authentication still fails.

@george1421 You are correct, I did obfuscate the DN. The actual DN does match that of the OU containing the group we are searching on.

I’ve compared the configs side by side via the GUI, but was curious where these settings actually get written to compare what is actually being saved. Where are these settings saved?

Great idea on the LDAP server, I haven’t tried that. I had been pointing it to the FQDN of the domain and letting DNS pick the closest DC. I’ll try pointing it a DC that I know works and see how that goes.

@Tom-Elliott It is, yes. It’s the same domain across all sites and FOG servers, so samaccountname will match across all sites and domain controllers. Authentication via that same account works on the other two servers, but not this one.

[Wed Mar 15 11:01:20.401092 2017] [php7:notice] [pid 1887] [client 10.2.20.21:53857] , referer: http://fogurl/fog/management/index.php

[Wed Mar 15 11:01:20.401032 2017] [php7:warn] [pid 1887] [client 10.2.20.21:53857] PHP Warning:  sprintf(): Too few arguments in /var/www/fog/lib/plugins/ldap/class/ldap.class.php on line 829, referer: http://fogurl/fog/management/index.php