@flipwalker Within your virtual environment can you make the FOG server span both network? I know if you have an air gapped network that may not be possible. If the air gap is the rule then you can just setup the fog server on the external network and we can work on changing the IP address afterwards. In the question about your subnet mask, fog itself doesn’t use a subnet mask parameter anywhere. It relies on the underlying linux OS to manage communications.
Posts made by george1421
-
RE: Changing server subnet when installing on Ubuntu
-
RE: Changing server subnet when installing on Ubuntu
Let me ask this. Is your fog server virtual and can you add a second network interface to your fog server? And/or on your isolated network do you have access to the internet via a proxy server?
-
RE: Upgraded an Existing Server to 1.4.4 and Now Interface is Very Slow and Chromium Images are not working
@rstockham23 I really dislike chasing two issues in the same thread, but back on the performance side.
Can you describe your fog server a bit?
- What OS is it running
- Is it virtual or physical
- Number of vCPUs/Cores
- What is your disk subsystem (raid, single hdd disk, ssd?)
-
RE: Upgraded an Existing Server to 1.4.4 and Now Interface is Very Slow and Chromium Images are not working
@rstockham23 OK so every 30 seconds all 500 systems “ping” the fog server looking for any new instructions. So wait 5 minutes and see what your load is like.
Now understand we’ve set the check in interval to 15 minutes. That means if you schedule a snapin deployment to these computers, It will take up to 15 minutes for the target computer to get the job.
-
RE: Upgraded an Existing Server to 1.4.4 and Now Interface is Very Slow and Chromium Images are not working
@rstockham23 Lets try this, go to: FOG Configuration->FOG Settings->FOG Client->FOG_CLIENT_CHECKIN_TIME note the value and then set the value to 900. Wait what ever your checkin interval was and see if response is better.
-
RE: Upgraded an Existing Server to 1.4.4 and Now Interface is Very Slow and Chromium Images are not working
@rstockham23 OK let me rephrase but I think I have my answer already.
How may computers do you have the fog client installed on? The reason why I ask is that the fog clients check-in to the fog server based on the check in interval. So if you have 500 clients checking in every 5 minutes, then you could have 100 check-ins per minute (in an ideal world). All of these check-ins take CPU time from the fog server.
from the linux console key in
top
then hit thep
and it should sort the processes by cpu usage. Take a screen shot of that screen and post it here. It may be easier to do this if you connect to the fog server using putty on a windows computer then you can use the screen shot tools in windows. -
RE: Upgraded an Existing Server to 1.4.4 and Now Interface is Very Slow and Chromium Images are not working
@rstockham23 How many client computers are hitting this FOG server? What is your check in interval?
-
RE: One StorageNode for multiple Masters
I think I might take a different approach here. I think what you are wanting since the FOG server is running in virtual box and you don’t have a lot of storage space, you want to utilize a storage node to house your data. This can be done without a lot of messing around. In this setup the FOG server is used for supervisory purposes with the storage node (maybe a NAS device) doing all of the heavy lifting. This can be done. But as Wayne said, we need to understand the logic behind your request.
-
RE: NFS mount options needed.
@wombathuffer said in NFS mount options needed.:
The only thing I am asking in this thread is - How do I specify NFS options when the PXE booted server is mounting the NFS-service?
I was replying to your question just as you posted. See below
But I can say many people (including myself) run FOG in a vm on vmware and I’ve never seen this issue.
-
RE: NFS mount options needed.
To answer your question, yes you can change how the FOS engine mounts the fog server. You will need to unpack the inits (init.xz) and then edit the file /bin/fog.mount In there you shall find the mount command you seek. Once you update the fog.mount script then just repack the inits and move them back to /var/www/html/fog/service/ipxe directory.
Here is how you edit the inits: https://wiki.fogproject.org/wiki/index.php?title=Modifying_the_Init_Image
-
RE: NFS mount options needed.
@wombathuffer In regards to the storage node, can we remove that from the equation? Power it off and you still have the same issue? I’ve seen some pretty creative uses of a NAS with fog. I just want to ensure you are not cross mounting the NAS onto the fog server and trying to reshare the mounted nfs share. Because that won’t work. As long as the NAS is a stand alone storage node then we are ok.
So now I wonder what is unique about your setup where the standard nfs connect is failing? If you say its the same with virtual box and vmware. Understand I’m not poking at your issue, I’m trying to understand what might be different in your setup.
-
RE: NFS mount options needed.
how does your storage node factor into the nfs issue with the fog server?
-
RE: Quick host registration is registering my computers with the Mac address as the hostname
@tom-elliott I looked at this a few years ago because I have the original code from the 0.3x days. I was quickly over my head in trying to sort it out.
How hard would it be for the developers to add another hook loop after the inventory has been committed during inventory process? Something like custom_host_name? Then I think the inits wouldn’t need to be touched since it would all be done in the fog backend. Then anyone with the motivation could write a host renaming plugin. The only thing the plugin would need access to outside of the host object would be the fog configuration infor for the auto naming field.
-
RE: Quick host registration is registering my computers with the Mac address as the hostname
@tom-elliott Is there a hook that we could use to add that feature back in? Ideally once FOG sets the host name we could hook in and rename what fog named by default. That way a plugin could be used? (asking without knowing much about what I’m saying).
-
RE: Quick host registration is registering my computers with the Mac address as the hostname
Your old version must have been a modified version of 0.29-0.30. That feature never made it into the mainstream code base. That feature is not currently available. (I also asked the same question so many years ago)
-
RE: Upgraded an Existing Server to 1.4.4 and Now Interface is Very Slow and Chromium Images are not working
@rstockham23 Just for clarity can you explain who these actors are?
10.23.8.50
10.23.8.45It would appear that .45 is the fog server and .50 is a storage node? If that is the case can you confirm that the images have been replicated to the storage node?
-
RE: Chromium Image Issues after Updating Server
@rstockham23 reverting to a previous build is not usually supported. Moving from 1.4.x to 1.3.0 wouldn’t be advised. What I’m speculating is that 1.4.4 is expecting something to be in that uuid file that is not currently there. The developers spent many hours improving disk imaging and resizing between 1.4.1 and 1.4.4. I think the fix is pretty easy we just need to identify what is missing. With 1.5.0 (stable) nearing release I don’t think moving backwards is the best choice right now.
-
RE: Configuring net0... slowly
@fradlo ok well that rules out stp then.
I guess the next round of testing should be this
-
Lets get a pcap (packet capture) of the pxe booting process. Since the fog server and the target computer are still connected to the same switch I want you to follow this process (I know you are wireshark capable, but lets follow this route): https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue Lets add to the filter sting port 80 too, so we can capture http requests to the FOG server. Run the pcap all the way through registration. Upload the pcap to a google drive or drop box. You can either post the link here or DM me the link so I can take a look at it.
-
We need to rule out anything in your environment that could be causing this issue. It may be worth setting up isc-dhcp server on your fog server for a test. Keep that unmanaged switch between your FOG server and your target computer and unplug the unmanaged switch from your business switch. and then with isc-dhcp server running see if pxe booting behaves any differently. I have 790s in our office and they pxe boot just fine. So unless the bios is the original release on the 990s pxe booting should just work.
-
-
RE: Multicast on multihomed server
@bongasicdn7 @Developers Please look at this patch and see if it can be integrated into 1.5.0 code base. We have had others request the ability to multicast on multihomed hosts.
-
RE: Chromium Image Issues after Updating Server
@rstockham23 Well I don’t 100% understand what I’m looking at, but I do see an anomaly in the data in the uuid file. Why is /dev/sda16 different than 15 and 17? Same with sda17 and sda23
That’s just an open question. I need to see now if your video gives me any more detail knowing now what we know.