Posts made by Frank

Thanks Tom. I guess you fix it in last builds. I am going to try it.

Goog morning,
any answers please?

Hi,
we are using fog 1.2 on ubuntu. It’s working quite good but we don’t get any bandwidth/transmit info in main page. The graph is empty. Is that because that feature is not ready yet?

Thanks and regards.

Frank
UPC - Terrassa(Barcelona)

OK, that makes sense. Probably snapins began too soon.
I will check that, thanks.

Hi,
not happened again. So sure it was related to something occasional.
Thanks anyway.

I don’t think so because guy who told me is serious, but it is also true that I was rebooting fog servers and perhaps the client get wrong parameters.
Sorry, we are going to make more tests to discard it.

Hi,

your right we are using a modified SnapinClient.dll and config.ini file to increment check interval.

In config.ini we have checkingtime=307 in snapinclient section.
In SnapinClient.dll we changed the line “int intSleep = r.Next(50,80)” as suggested in an old post

But in any case, I thought snapin execution was postponed after changename and domainjoin, so that times didn’t affect.
Was I wrong?

Hi Tom,
here is an image of what I mean.

[url=“/_imported_xf_attachments/1/1199_fog_text.jpg?:”]fog_text.jpg[/url]

Hi,
it has been a change in the client text display when doing a task. Now text font is white and background red. Excuse me to say it’s not a comfortable view to some users eyes, so is there an easy way to change it to the previous colors?

Thanks.

Frank

Hi people,

our environment is Fog 1.2.0 with one central Fog and three storage repositories, all of them with ubuntu 12.
We realized that some tasks (upload,download) launched to clients are started on them, but it’s like central fog loose their control and they are not showed in GUI. These tasks ended and we see errors related to no nonexistence of such tank and for instance, in upload case, files are not moved from /images/dev to /images.

Have you notice something like this?
We have tried to remove task info from db because we thought it would be a data corruption, but it is still happening.

Regards.

Frank

Hi people,
our environment is Fog 1.2.0 with one central Fog and three storage repositories, all of them with ubuntu 12.
We have noticed the in multicast deployments (not seen it unicast at the moment) snapin download and execution begins just after domain join but before machine reboot.
That causes the reboot happens while snapin execution so snapin is sometimes applied, sometimes not.
Have you notice that? A possible bug?
Here follows a log trace:

22/07/2014 15:24 FOG::HostnameChanger [B]Domain Join was successful![/B]
22/07/2014 15:24 FOG::HostnameChanger Computer is about to restart.
22/07/2014 15:24 FOG::GUIWatcher Message found, attempting to notify GUI!
22/07/2014 15:24 FOG::GUIWatcher Dispatch Failed!
22/07/2014 15:24 FOG::MODDebug Reading config settings…
22/07/2014 15:24 FOG::MODDebug Reading of config settings passed.
22/07/2014 15:24 FOG::MODDebug Starting Core processing…
22/07/2014 15:24 FOG::MODDebug Operating System ID: 6
22/07/2014 15:24 FOG::MODDebug Operating System Minor: 1
22/07/2014 15:24 FOG::MODDebug MAC ID 0 10:60:4B:74:CE:86
22/07/2014 15:24 FOG::MODDebug MAC POST String: 10:60:4B:74:CE:86
22/07/2014 15:24 FOG::MODDebug No user is currently logged in
22/07/2014 15:24 FOG::MODDebug Hostname: ETSEIAT-PC34-11
22/07/2014 15:24 FOG::MODDebug Attempting to open connect to: [url]http://172.16.1.10/fog/service/debug.php[/url]
22/07/2014 15:24 FOG::MODDebug Server responded with: Hello FOG Client
22/07/2014 15:24 FOG::MODDebug Module has finished work and will now exit.
22/07/2014 15:24 FOG::GUIWatcher Message found, attempting to notify GUI!
22/07/2014 15:24 FOG::GUIWatcher Dispatch Failed!
22/07/2014 15:24 FOG::SnapinClient Snapin Found:
22/07/2014 15:24 FOG::SnapinClient ID: 729
22/07/2014 15:24 FOG::SnapinClient RunWith: c:\windows\system32\cmd
22/07/2014 15:24 FOG::SnapinClient RunWithArgs: /c
22/07/2014 15:24 FOG::SnapinClient Name: ETSEIAT_ACTIVAR_OFFICE2013KMS
22/07/2014 15:24 FOG::SnapinClient Created: 2014-07-22 10:03:56
22/07/2014 15:24 FOG::SnapinClient Args:
22/07/2014 15:24 FOG::SnapinClient Reboot: No
22/07/2014 15:24 FOG::SnapinClient [B]Starting FOG Snapin Download[/B]
22/07/2014 15:24 FOG::GUIWatcher Message found, attempting to notify GUI!

Regards,

Frank

Wow! Congratulations to all Fog developers!
Thanks for your excellent job!

Thanks Tom. I didn’t pretend to criticized Fog in any way because I think it is a great tool and there is an excellent work behind it.
We think that multicast is a very good way to get the best from network bandwidth if you are sending the same image to multiple clients, so we think that a product like fog could take profit of this.
From you answer I guess that multicast is not a priority so I will follow your advise and I will try to modify code to allow multiple multicast transfers. The only thing I wanted to know it was if that was in your roadmap.

Thanks a lot anyway.

Frank

What I can tell you it’s that we have been fighting with multicast transfers for log time ago with several deployment systems as rembo an Tivoli later, so we have some experience on that. I’m not an expert with network, but we have a network team group here with great experience and we have been working closely with them.

It’s true that for multicast as for unicast there is an IP and a port, but what makes possible different multicast transfers is what is called a multicast group, and that depends only on IP as I said. If you monitor multicast info in switches you can notice that. Also note that neither udp-sender manual page nor the wiki page you told me don’t talk about multicast port settings but only IP settings. So one multicast address mean only one multicast group and that’s why I posted my question.

Check that if you want to in a test environment and you will see that only one multicast group is created for all the multicasts transfers, which of course makes that all hosts in the group receive packets from all multicasts transfers.

Frank

Hi Tom,
I’m not a guru of multicast, but I am quite sure that multicast groups depend only on multicas IP not port. In fact, in udp-sender there is no option for multicast port, only for unicast.

So I don’t see that different multicasts deployment perform well if you don’t change multicast IP. Of course you can launch several multicast deployments, but all of them will be on the same multicast group, which leads to a poor network performance.

Frank

Hi,
we know that in order to make multicast deployments Fog uses udp-sender which in default uses a multicast address based on host IP. As you sure know that makes only one multicast deployment possible at once.
Is there an easy way to change that and allow multiple multicast deployments in a single storage repository or do you have plans to change that in future versions?

Thanks and regards.

Frank

Hi again Tom,
I’ve updated to 1.1.1 and the behaviour is the same. Launching a mullticast deploy the associated snap-ins are not launched.
By the way, what is the deployment button that appears in host list for? It seems to launch a deploy of one host using multicast, but that doesn’t have much sense.
Regards.

Frank

Tom,
I know that if the host don’t have any snap-in associate no snap-in will be done. That’s logical and that’s the way it worked before.

But I swear you that we lauched a group with hosts that had snap-ins associated, and the snap-ins were not queued. Right now I have created a group with only one host and one snap-in associated, I have launched a multicast deployment, and the snap-in is not on snap-in queued tasks.

My fog version is 1.1.0. I downloaded it before you make it official. Can it be that the cause of this problem?

Frank

HI,
any developer who can answer this please?
Thanks.

Hi,
I have it, of course. Snap-ins are done in unicast deployment but not in a multicast one.