Posts made by Foglalt

@Wayne-Workman snapins run from will-be-client?

Hi!

There are fine options for post download tasks for finetunes, etc. but I couldnt find any good way for post upload things. I was wondering how to do, for example only, the following: I take automatic notes if a new image is created. It would be nice. Is there any way for it, or I should post a feature request for it?

Finally, done. Solution: few switch was not ok, network config was changed in a way we was not aware (other device needed different setup and was not properly separated. Now is ok! And, as for full solution multicast tables needed manual clearing. (when we had solved testing, clients seemed stuck, now they dont.)

all ok now, mass tests will come soon for performance (as now multicast speed a bit low…

Ok, back again to testing a bit more. I read through the linked topic, but I think it is not that topic you wanted to show me. I am not sure, but I think I read one topic in which info was deleted from fog database tables, but not deleting and reinstalling what linked troubleshoot wiki page suggests.

If I do the deletion and reinstallation, will I lose the host/settings information I made? I have a working unicast fog setup, I dont want to redo all during debug Wayne, dont you remember the topic I mention? I was not too long ago, but I dont know good keywords for searching for it. Maybe you remember better.

i will be on vacation for a while and after it i will go back to test and debug it as we NEED multicast pretty soon

Well, with a full resetup storage node problem solved. BUT, as always there is a but, multicast still not working. We did all on debug list as was suggested, but debug worked and normal multicast is not working (i mean it is stuck at the point of starting imaging with partclone).

What if debug’s “log sendig” with udp sender/receiver pair works, but normal multicast is not working? What debug work to be done to find the bottleneck? Any more suggestion?

@pabloinza for me it is still no. but i am on a trail which may lead to goal. i have to do tests for it.

@pabloinza

No, not yet. We have some other issues what makes us delay it a bit, network staff has issues cos of powerfailures, things are not that happy I will make them continue tests.

Sorry about forgetting to write I did restarted every single bits, services, hardware, etc.

@Wayne-Workman

Er… during your post I was trying to find a better way to describe why was 2 different post, and tried to state better what I wanted. Sorry again for being a bit confusing. Pls read what I wrote now. Anyway, p4p1 thing you suggested is a bit more dangerous than you may wanted It is like killing a moskito with gunship, full power. It will kill, but… well, a bit more damage than wanted.

My problem maybe originated that some things can be configured on the web ui, but sometimes config information is kept in different location which is ok if I dont want to reconfigure “all things” after setup. It is hard to be done if I dont know where to make changes (ip addresses are located in many places, but in config files duplicated, cannot be modified from webui. This makes things harder for debugging.

Hi!

Well, I am sorry for confusing you, but last 2 topics i created was leading to totally different way, even if we have one in common, the fail of multicast. Let me be a bit more explanative.

I still have multicast issues, which we trying to clear a bit to let us be more on to solve the true problem. The setup is the same server:

• ubuntu 14.04 lts
• network interface, and on same interface virtual interface. first one is mantenance, other is for actual fogging.
• clean install, no previous life of it, only 1-2 images from old days, later converted to new format btw.

Before multicast try we noticed the “storagenode not found” thing, which indicated some problem (first topic). We have working unicasts.

As we tried to debug, we found a partially working stage in which we investigated with debug steps and found that upd-sender manual start on server and udp-receiver on client we can make working version, but we have a problem, server and client are “listening on different direction” or so. If we have set the optional parameter on receiver about udp address (–mcast-rdv-address fogserverIP) it works. But, as all time you can find a “but”, we have to set this address to the “maintenance address” of the server, not the address of the web interface, tftp ip, etc.

Then we moved on. Killed the “2 interface address setup” (here we found the changing the server ip is a lot harder than the 0.32 version; an update of the wiki is a must on this topic). Now we have only the p4p1 named network interface, have only one ip address, unicast working, multicast not working. Here I forked my post as possibly this is not same issue.

• question1: with working unicast what does “no storage node found” actully mean?
• question2: is it possible to set parameters for multicast? like i mentioned above, mcast-rdv-address, or others

So, I apologise for virtually repost, but if we find any solution it would be easier to find later by others. Or at least it was my intention by forking the question.

At boot process of the system it is named. System logs, ifconfig, ip command. All says it is so.

Hi!

We have and issue in which a partial problem of multicast is detected which can be solved if multicast can be configured somehow. In this setup we have an interface called p4p1 (in old days it would be eth0). During fog setup it asks if i want to change default network interfacename, and i answered yes, p4p1 will be the one. Some places it still used eth0 in web gui, so i changed them (i dont remember where, i found it when i wanted to find else).

The original case came to light cos I set up one physical interface with two ip address. One for maintenance, one for production. As we debugged the multicast problem it came to light that sender waits for fog one ip, receiver tries to get to the other one. On debug web page there is a place where upd-receiver is configured with rcv-address and if I write here the “maintenance ip” multicast debug successfully done.

So, I guess that if I can tell somehow the the udp-sender/udp-receiver duo those parameters which we used in debug sessions then it can work somehow.

What do you think?

No, this installation is from scratch, only 2-3 images (as file only) were from the old version. It is a lonely fog install, no other nodes at all. Where it stands as a lone image deploment tool no need for any other one. It is really strange that it cannot see the only node it actually uses for unicast deployment.

Hi!

I have an 1.2 version fog installation which cannot multicast, but steadily can unicast. In the multicast log, without having any task in queue I see a permanent error about no storage node, like in topic title. Where and what does it searches for as storage node if I have one working? I mean for unicast it uses the same (1 and only master node) node as it uses for multicast, right? Then why is that repeating log entry? As with 1.2 version this would have been the first multicast try (with 0.32 it worked fine) I checked log before I started a task and I saw error. Ofc I did try to do multicast, hopeing it is something buggy error in log (as I have storage node for unicast working, was not unnatural to hope), but I failed (after partclone starts it stucks there.

background info:
fog 1.2
ubuntu 14.04.0 LTS
interface name: p4p1 (when it asked interface name I entered this as this version of ubuntu already uses this method to name ethernet interfaces, not the old eth0 etc way.

I tried the following:

• testing nfs: mountable from other systems
• ftp: login with user fog uses possible
• mysql login test: login with fogstorage user possible (test from localhost via ssh)
• wireshark to see what and where it sends: strange error reply: nfs3err_noent, which says for me that “No such file or directory. The file or directory name specified does not exist.” extra strange.
• with fear in heart I did a reinstall of fog 1.2, no change
• shut down v1.2, boot up oldie 0.32 to see its logs: no error in multicast log. well, as I used that version for years, even from older versions of fog I was sure I would see no error, but worth a try.

Ofc I read through the forum entries regarding to multicast errors, found many entries about “storage node not found”, but I see it even without ever tried to multicast in error logs of multicast, so testing network with debugs maybe not relevant as first I should “solve the not found” situation before ever try to hope multicasting.

Any suggestion where to see what makes those entries into log?

Aha, thx! Surely i will do a try! Thx

Fully virtualized fog server in a failsafe HA environment, my final goal. My only problem is my boss, who wont accept the needs for a working version of this. Right now at least. But ofc it will be the final solution. Until that, I will do experiment to do things and maybe find a working solution. I will consider what you told, will do tests if I have any free time. If I manage to work a “bare minimum” version to do so, I will post it. Maybe others may profit of it, or at least have fun with my struggle and get new ideas which can be even better. ,)

You definitely want me to give up, dont you? As for second fog server. If it is blank, and only need to have modify dhcp next server info is is practically the same what I am trying to do (only difference is that if i can figure out what is the bare minimum).

My problem is this: If i have a server with 2 interface and 1 of them is configured to work only if needed (a.k.a. failover solution) then how should fog be configured? If it is fully configured with same network information, like ip, nfs, etc, I dont know what malfunction it can cause if it is “online”, but not active (I mean the other interface it can use for communication, I cant tell fog not to communicate till I dont say now you can. So what if it does anyithing i dont know it does. I mean if slave put infos to log on master, make it confusing, etc)

If non-active slave is not configured with ip of “fog-ip”, then after failover comes, it needs to be, but that is not 1 click).

All I want to do is a fully, seamlessly replacable dummy who tells: do nothing. I am not a master of 1.2 fog version boot process on client side, I need to learn a lot more to have a solution easily. But I still dont think it is abosulte unnatural and impossible. I maybe need to find the correct question for community, you, etc. I am sure this magnificent tool can have a minimal backup dummy for this kinda problem.

(ps. about minimum: I cant afford total backup of server at the moment. Not because of the server, but maily of image sizes. I am not sure, but as I am aware of the working procedures of fog I can add storage node, but not main server for task and boot purposes. Am I wrong?

Some part of the infrastructure is easily modified, but main parts I cannot alter too easily (like network setup, storage allocation, etc.). You know, “you have to make things work, but I dont care how you do it, just make it work” style from management side… And my colleagues got addicted to fog as we got a lot of goods from using your system, we dont want to give up easily.

I am aware that some have this issue, others dont, of course. As you pointed out all chain can have a fail. Yes, I know of it. I dont want to be pulletproof, for me it can be ok if I have an option to survive such cases till I can figure out there is a problem and I can have solution. Yes, it can be a solution if all problematice device must be set up to hd first boot (bios upgrade we tested, fail in almost all cases or other issue came up. just for fun ofc). Our main goal with network boot as first boot order is to be able to manage our computer rooms from remote location. Think of it a bit in our way: dozens of labs, with hundreds of computers. Do you really want to go to location to set network boot if new image come for those computers, boot up, image, then switch back all to hd boot? Or, as we plan and operate: Remote wake up for pc’s during off duty times, have them imaged, then power off if no fail log comes. If nothing problematic, it can be scheduled easily. But with “some fail bioses” we have to go and see how many, where, locate, replace/upgrade/etc, or totally disable the feature and back to stone age, all done manually

So, question still there. Is there a solution for a dummy system to work out, bare minimum, to tell pc’s to boot from harddrive? Am I the only one from space to imagine it possible somehow? I hope not.

I am sitting and thinkink even twisted solutions. Like a pxe version (e.g 0.32) where boot image is renamed to new mode (undionly things). That version was less complex, maybe the tftp boot server part should be installed where defaul menu option is only to make it chain to local hd boot. Come on, is it so unnatural thought?

Hi!

I have a working Fog server in production environment, one server, which is in most cases ok, but sometimes not accessible for pc’s to boot up from (all ok, but network is not reachable, or server offline cos of maintenance, etc). Almost all pc’s which we use fails in the ways if boot order is network->harddisk. It netboot fails, machines hangs there, with no option for the user only to wait (10-15 mins timeout, nonsene, but it is about that, depending on bios. old or new, no matter).

This is why is wanted a way to make a bypass like service on an other location, but strictly on for bypassing netboot if Fog is not reachable. The less problematic way to pass on, but can be enough for 99% of situations.

How can I manage this? I was thinking of a way to have a keepalived to check if master fog is reachable and if not, a virtual interface would come up to server as target for network boot clients for bypass. Until this it is not a big deal, but what should I have working on the bypass “server”? My first think was to install a “next-next-finish” dummy fog server, fully configred, but it can cause a lot of problem, so maybe a lot more sofisticated way is there for it to accomplish the goal.

Was I ever clear to tell what I want? If not, let me now what to tell in details. My only goal is to have the slave server to make a “boot from hard drive, nothing to do here” state and when master server comes back, keepalived would kill the virtual interface to let the master do its normal job. I hope it is clear enough to start finding solution, guessing, etc

I dont think I am the only one who noticed some bios cant move on when netboot server is not available, hope u guys tried to find solution before.