Posts made by Foglalt

Well, if no other way is possible i would have to do this way, but it is the worst case for me (location is far, isolated, time is short as always, etc). Actually i was wondering if i can use something like live clonezilla or so, putting fog created image files under its reach and use it somehow. That is a lot less problematic atm as i dont have to be there to oevrsee it etc.

Hello!

Is there a method I can use to use the image we have in daily usage to image few computers in a far site where building a fog environment is not an option in short time? I mean I have the populated /image dir with images, i have the database in fog about the images and can have a relatively easy method to use them to image those far computers (ofc image transition is possible, like on a usb disk or something)

Guys, during the struggle to reproduce the issue somehow i found something strange. Let me describe it.

Starting point: host has a valid mac, up to date. i want to change mac. It can cause 2 different output, and i think it can cause the result somehow (i will do more tests to see if it really happens, but the difference made me curious).

mac update method1: host primary mac field is the only field, no additional field. i select the full field, then overwrite mac. result is a new mac on primary and an additional mac field appears with the previous mac address (which is wrong, as it has no another, but a new mac actually)

mac update method2: same starting point, but i only use mouse click to the end of the field, without selection of any char i use backspace, for like 1 char, and type another char instead of the deleted one. here NO additional mac field comes to existence. why? if i change the mac any method i want to change it, not add a new one (i will make test with it, maybe this way it will disappear somehow)

EDIT: sorry, somehow i did not notice what you wrote before me.

Normally the issue happens when a host mac is updated (primary mac field is selected with ctrl+a, then entered the new mac). we never use intentionaly more mac on a host (and they dont have any more interface, not like laptops with wifi, eth, whatever simultaneously). How can a host have secondary mac in database? When i first saw such i asked colleagues how they did, and some faint memory i have about it whuch tells when updated, the previouly overwritten mac becames secondary. But it is far from intentional, those are pc-s, with 1 mac only.

Can it be a clue to the investigation…?

like this:

MariaDB [fog]> select * from hostMAC where hmHostID=37;
+------+----------+-------------------+--------+-----------+-----------+----------------+-----------------+
| hmID | hmHostID | hmMAC             | hmDesc | hmPrimary | hmPending | hmIgnoreClient | hmIgnoreImaging |
+------+----------+-------------------+--------+-----------+-----------+----------------+-----------------+
|  170 |       37 | 8c:89:a5:53:1b:f5 |        | 0         | 0         | 0              | 0               |
|  298 |       37 | 6c:4b:90:4e:53:9e |        | 1         |           | 0              | 0               |
+------+----------+-------------------+--------+-----------+-----------+----------------+-----------------+

As you may see, the primary mac has a strange difference from additional (298 is the primary, 170 is the additional mac id). why it has no zero at pending and why has the other a zero? That field is not manually edited, so the software logic updates that field. But why differently? I still have a feeling that this issue is connected with “pending mac”…

The plan is that i will make some extra scripts for my colleague and for some logging, and if all the goes to database as stored procs, maybe script to detect ajd delete disabled ones go there too. But deleting is what i like to have more control, dont want make fixing with deletion with script.

But… As a second thought, what if we check if missing ones have actual mac address but flag is missing only for primary mac. If i set primary mac back to 1 nstead of simply deleting the host as before, will they come back “online” maybe?

@Tom-Elliott nothing special i would do, just like looking up missig primary mac host and killing the orphans so practically i would move my garbadge collection scripts to database. Maybe i put some authentication before it and let others use it, colleaguea i mean. So nothing new at all.

As i am a regular user for detecting and killing hosts with missing primary mac, unfortunatelly, may i use stored procedures for this? does it have any problem with fog database? will it be wiped with fog upgrade? i am trying to find a proper way for colleague to kill issue without me if i am out of office, and for this i am thinking about using stored procedures (well, same for other database commands we may use to maintenance in fog maybe nice)

is it a source of problem or i may use them?

@wayne-workman but how? Anyway it doesnt change the mysterious disappearing sadly

@wayne-workman what do you mean by this? we do this cos of easily possible mass actions (multicast is done with registered hosts, etc or did i miss something?)

One more thing about yesterdays instance of the problem: during the host update the new mac was registered on the host (this time laci2, to name it as in log you may see) and when the task start was prepared (those hosts are in a group for mass deploy) colleague ralised that group has less member than needed. voila, missing host. so it was disappeared after host update (or during)

@wayne-workman It is simply the following:

• pc1 comes in for reinstallation/installation, its mac is registered in a “dummylikehost” (for example “laci1”).
• image selected, task set to deploy, pc1 finishes, turned off
• pc2 comes in for same purpose, host “laci1” got a mac overwrite (mac gui field selected, typed in the new mac, update button).

the missing host is detected by your script, or previously it was detected when pc3 comes in for processing.

this is why i asked before how others do massive cloning. colleagues do this method cos with it you dont need to remake cloning groups (no image update? so you dont need to change image name). it is like another 5 pc came, you put them on the table, put cables in, register new macs and launch process of cloning. we normally never keep hosts in database, as you may saw in our database before. we only have a few in them. few dedicated ones (like image creators machine and some other).

Tomorrow or later tonight i send you another. Yes, again it happened. Maybe it van be same pattern at least. Btw host is not renamed. But mac is changed. All time!

er, mine active is not 1.3, since it was first happening, it was about 1.2 or so. then as time passed, we tried in many ways, upgrades, etc. not too long ago mine was most uptodate one (1.4.4), then ofc as developing is going (happily see that btw), ofc it “grew older”. but this happened to me on every single uptodate versions so i think the true reason is far more deep than it is at first glance. i have hope in your script

@Wayne-Workman the issue happened again preparing the log that the script generated and i send it to you in mail again for analysis.

@junkhacker oh, there you got the score! Totally forgot this btw, it writes to a host data using host id or uses mac for lookups? If later, it may cause issue, am i right?

@junkhacker you mean there are updates even if nothing changed? As if refreshment?

Oh, one more thing. We use fog version 1.4.4 at the moment. It was a fully clean install (os, fog, database, only the existing images very moved from storage to /images of new machine). Does it have a relevance? We actually installed a new server for far site usage (low and unstable connection prevent replicating, so only images are uploaded to that server if prepared). This remote site has 1.5.0 as it was finally out to be stable (gz and thanks from comminuty anyway, we are happy to see it).

Should we do upgrade before going on with debug? (actually i dont like the word upgrade at this point, as we have this issue since a long time now and even fully clean installation gave same, so maybe behind methods of things done, not in-fog thing only). The difference between 1.5.0 and 1.4.4 is huge visually, but can it be upgraded with donwloading the new tgz and running install between two version? wont it corrupt database if i do upgrade in between these two? (the far site of us is a sideproject for me to experiment with upgrades of fog, and test new versions more often )

thank you guys for cooperating with killing this bug-or-what

@Wayne-Workman i will try to do frequent host updates randomly (actually i think during “non-tasking time” it is not replicatable, maybe is about load on server).

@Sebastian-Roth I dont think the key is the “during image mac is changed” as far as I know about fog database updates are done upon things finish and starting point. I mean if i change mac during deployment, database is updated on change and upon task finish (btw my guess is that task finish doesnt do a thing with mac address, as host data is update upon end of a task, but why would it be caring with mac of the same host? I mean host is looked up for update with host id, not with mac lookup. but ofc it is a guess, you guys know more details

@Tom-Elliott I think same, it is surely not a full scale, everybody does it kind of bug as i see no other posts about it. I think it is related more on our methods of managing host deloying. I asked it before on forum that how ppl do this. this was the reason. to see what is different and how, to find the difference of our methods.

I have a guess of these:

• maybe load on server may cause this timing issu
• maybe data update of host details are done one by one and something can interfer with it making it “broken a way”.

The strange part of it is that we are not a huuuuge company with tons of ppl using fog. We have many hosts (like 2k) what we only clone with fog. We do not manage them with fog client, no printer management, etc. We involve fog only in the host deployment. And it is done only very few “on-site” (computer labs) and all other are depliyed or even uploaded in 1 office actually, where our 2 guys use fog for daily deplying. Meaning very few concurrent database updates. We sometimes do more, and sometimes very few (actually we does a full company pc upgrade in waves of timed deployment; as we are not many, we have to do it in a long row of deplying, not 1-2 huge waves of full company). I told it cos only to see behind curtains. 1 month of running script is not a big thing. Some part of the year it means 100 deploying in 2 week, sometimes 100 during few months.

Anyway about this actual issue. If i take seriously what my colleague said (why would i guess they lie? this screws their work, not mine, so they are in need of solution, not disguise ), so if i take it seriously, this time the disappearance was “unique” as normally they did not do it before (“we have never did it this way ever”).

Btw, script is freed to catch next instance of it (i will make another tune maybe, to send a message to me if it happens at once, as it took 1-2 days before i was even informed that it happened). So, waiting for next issue

@wayne-workman

I realised that only ip could have been sensitive, so i altered it, rest is unmodified. I am curious if log helps this time (as i mentioned it has now an extra step over normal daily work (mac was changed during selected host was being deployed).

(as logs cannot be inserted here this long as i have, and uploaded files are only pictures, i send to your email.)

@wayne-workman hehe, sanitize i will, well, i already started reading it but work came in the office in waves, so i postponed it to tomorrow. I will send or post it here from work. btw i kept your address from last db transaction we did together.