Deploying method you guys use vs disappearing hosts
I want to make a "survey like question’ about the how-to of deploying. Let me tell why i mean by that. We at the company have thousands of computers but we use only a few working images for them. When a computer comes in to deploy we use “imaging or so called mule hosts”. It means in host database we dont register all computers 1by1 for all future usage. We use like dummy1, dummy2, etc and use them for cloning. Only the description, mac and image is changing for the process.
As some pcs are coming some are going out from our pc pools (going out here means forever) it would be hard to followup with all computers status, soon host would be crowded table (like when it comes to mass going out). This is why only some of the computers are in the host list for ever (servers, special pcs, stb).
This method was used for ages, since like 0.2x version of fog but for a time after 1.1 (maybe 1.2) it began to fail us in a strange way. During the process of mac update (old dummy go out, new dummy in, so mac needed to change for the process) the host lost the primary mac. it HAS mac registered, but in the database primary was lost. As a result, the host was not visible anymore, but still there, cannot be deleted, update, etc. It needed manual db garbage collection. (as for now i am making semi automatic garbage collecting scripts for the crew to use).
Any of you use same method? If so, do you have the same “disappearing host” issue? Or, even better, any of you maybe know the clue of this thing? I maybe called stupid, but i dont even know or understand the “pending mac” thing, can anyone explain it? Maybe that is the clue, idk.
So, how you guys do it?
(secretly i ask here the developers about how many host registerion --a.k.a. number of host in db-- can be a bottleneck for the usability at all )
@Foglalt Thanks for the thumbs up! You are welcome and I am sure we can figure out what’s wrong in case this is still happening with 1.4.4! Please keep us posted.
@sebastian-roth I have absolutely no problem about what you said and agree on upgrade. I only did the post to see if we may have a “bad habit situation” on updating the host informations. So, I will move onto stable (well, i dont like to risk productivity, so in production environment i will stick to stable release).
About pending macs. We dont use fog client at all but sometimes on fog pages i see we have pending macs and it wants me to decide about it. I somehow linked this to the issue in thoughts this is why i asked. ( will do upgrade as soon as possible with a junk-removed state of db then see what happens)
And the most important thing, BIG thanks for you folks who volutarily do such a huge and very very good job! We cant be grateful enough for your work!
@Foglalt While I totally understand you situation I can’t really help you with FOG version 1.3.4. Our dev team is all volunteers and it’s hard enough to support the latest release (which is 1.4.4) and keep things going for a new release as well. Please look into upgrading to 1.4.4 at least (even better if you are keen enough to head for the bleeding edge RC version from our git repo which is in use by many people in production) or we won’t be able to help. Sorry to say this but we just can’t fiddle with the old stuff.
The method you describe sounds reasonable to me on first sight. So I guess there is a bug in 1.3.4…
Pending MACs are created when one client reports “alternative” MAC addresses. For example this happens when you run the fog-client software on that machine. It will call out to the FOG server and also tells it the MAC addresses it has. Quite often you have WIFI or other adapters in PCs that have a MAC and those will then show up as pending MACs for this host. Nothing serious really.
atm we use fog 1.3.4. the problem when we noticed first was more than 1 updates ago, however i dont know how many patch it survived.
The update method for mac address is that:
- open dummy host from host listing
- select mac on the data page of the host
- overwrite the mac with the one copied from a document elsewhere (a.k.a. copy-paste).
- press buttor for updating host data
It is nothing special I guess, that is why i dont get the point in the increasing number of “broken hosts” in db. Atm I see a host missing what was only used once for some testing purpose only (that would mean to me that mac was not even updated at all, but mac MAYBE used for a short time maybe). I dont know if it can help, but I do hope.
Btw, I am trying to clear all obstacles from the path of upgrade to up-to-date version. At a previous try to eliminate the issue I was suggested to do update. Unfortunatelly at that point it was not solution.
Does it seem to have connection to the method of updateing mac addresss or is it connected to pending host thing? (which i still dont understand the meaning of, sry)
While I don’t have an answer for the list hosts. I can tell you some people that use FOG are computer rebuilders. The take systems reload an image on them and then resell the computer never to see them again. For them they do not register computers, they just pxe boot the computer and select deploy image from the FOG iPXE menu, this will automatically push an image to the target computer with no registration. They do have fog setup to tell the computer to shutdown after the image has been pushed. That way when they are deploying to a bench of computers, the ones that are shutdown have finished imaging. You may be able to use parts of this process for your company. If not, know the FOG iPXE menu has the Deploy Image command.
@Foglalt To be able to give a proper answer we need to know which version of FOG you use right now? Have you seen the same issue in 1.2.0 all the way through to whatever version you use right now?
How exactly do you do the MAC update? Please explain the steps in detail and I am sure we can figure out what’s wrong…