@george1421
OK that was clear to me. Just wanted to see if FOG can benefit somehow through this tough work with my tablet 
A
Best posts made by AndrewG78
-
RE: Tablet with WINDOWS 10 and USB-LAN SMC 7500 adapterposted in Hardware Compatibility
-
RE: Can I use some kind of script to create image and ghost my lab machinesposted in FOG Problems
Hi @wayne-workman
When I use your example to Get task status of host ID 1,
I always receive status of all hosts, but not the particular one.
Could you help here?
I’m on 1.4.4
regards -
RE: APIposted in General
@wayne-workman
Thx. I figured out where was the issue. Maybe this info will help somebody.
I use curl under Windows, but command line doesn’t support single quotes '.
I used " and had to escape inner ones
–data “{\“hostID\”:13}”
Latest posts made by AndrewG78
-
RE: vsftpdposted in FOG Problems
@Sebastian-Roth
I think I found the reason(s).
There are 3 things I would like to clarify.
1.
Although replication services are disabled, there is still some replication done between storage groups.
In my case, I have two storage groups, every group has one storage node.
Both Nodes were master ones.
The image from the new group(2) was replicated to the old default group(1).
I have unchecked replicate checkbox in the image, and also disabled Master Node for the old default group. So there is only one master node. The old group has no master node at all.
After this, all seems to be fine now.
a)
The question is, was this a proper behaviour?
I thought replication is done only within the storage group members(nodes).
b)
Are there any other services that could do this replication?
2.
The high cpu load(kworker and vsftpd) was related to replication and lack of disk space. Replication processes did not stop even if there was 0% of free space.
I think this is a bug.
3.
I can see a bunch of multicast log files.
a)
Should there be some smarter log rotation ?
b)
"No new tasks found "is logged every 10s - Can we change this time somehow ?
-
RE: vsftpdposted in FOG Problems
@Sebastian-Roth
So after disabling replication services, FOG UI became super responsive.
No more kworkers and vsftps deamons.
Perhaps an issue in the newest version?
Does anyone have similar setup and can confirm this bad behaviour ? -
RE: vsftpdposted in FOG Problems
@Sebastian-Roth
Thx for the update. Yes I have read this before I started.
I have updated my node to the FOG server version at the same time, but I did not stop the replication.
I’m not sure if this scenario is realted to my setup.
I have two separate starge groups with only one master node in each of these groups.
So there are no nodes in the groups in which Master would replicate.
I will disable FOGImageReplicator and FOGSnapinReplicator on the server, but Im not sure if this is the right way to solve the issue. -
vsftpdposted in FOG Problems
Hi,
I recently added server master node(as a new storage group) to the fog server and upgraded FOG from 1.5.4 to 1.5.7. I have high CPU load 80% of the time, even if there are no any tasks to do. There are two vsftpd daemons consuming 20% of the CPU + kworker from time to time. How can I debug this ?
-
RE: Multiple FOG servers in one networkposted in General
@Sebastian-Roth @george1421
Hi.
After quite a long time, I found free time to test filtering through the mac table configuration file.
It is working!!! Thx for the tips here.
However, I’d like to understand strange dnsmasq logs I noticed in the messages.- There are several identical broadcast responses.
- There is tftpd error - Error code 8: User aborted the transfer
Beside of above, it works
available DHCP subnet: <IP>/255.255.255.0 vendor class: PXEClient:Arch:00007:UNDI:003016 PXE(ens160) <MAC> proxy tags: team1, ens160 next server: <IP> broadcast response sent size: 1 option: 53 message-type 2 sent size: 4 option: 54 server-identifier <IP> sent size: 9 option: 60 vendor-class 50:58:45:43:6c:69:65:6e:74 sent size: 17 option: 97 client-machine-id available DHCP subnet: <IP>/255.255.255.0 vendor class: PXEClient:Arch:00007:UNDI:003016 PXE(ens160) <MAC> proxy tags: team1, ens160 next server: <IP> broadcast response sent size: 1 option: 53 message-type 2 sent size: 4 option: 54 server-identifier <IP> sent size: 9 option: 60 vendor-class 50:58:45:43:6c:69:65:6e:74 sent size: 17 option: 97 client-machine-id available DHCP subnet: <IP>/255.255.255.0 vendor class: PXEClient:Arch:00007:UNDI:003016 PXE(ens160) <MAC> proxy tags: team1, ens160 next server: <IP> broadcast response sent size: 1 option: 53 message-type 2 sent size: 4 option: 54 server-identifier <IP> sent size: 9 option: 60 vendor-class 50:58:45:43:6c:69:65:6e:74 sent size: 17 option: 97 client-machine-id available DHCP subnet: <IP>/255.255.255.0 vendor class: PXEClient:Arch:00007:UNDI:003016 PXE(ens160) <MAC> proxy tags: team1, ens160 next server: <IP> broadcast response sent size: 1 option: 53 message-type 2 sent size: 4 option: 54 server-identifier <IP> sent size: 9 option: 60 vendor-class 50:58:45:43:6c:69:65:6e:74 sent size: 17 option: 97 client-machine-id available DHCP subnet: <IP>/255.255.255.0 vendor class: PXEClient:Arch:00007:UNDI:003016 available DHCP subnet: <IP>/255.255.255.0 vendor class: PXEClient:Arch:00007:UNDI:003016 available DHCP subnet: <IP>/255.255.255.0 vendor class: PXEClient:Arch:00007:UNDI:003016 available DHCP subnet: <IP>/255.255.255.0 vendor class: PXEClient:Arch:00007:UNDI:003016 available DHCP subnet: <IP>/255.255.255.0 vendor class: PXEClient:Arch:00007:UNDI:003016 PXE(ens160) <MAC> proxy tags: team1, ens160 bootfile name: ipxe.efi server name: <IP> next server: <IP> sent size: 1 option: 53 message-type 5 sent size: 4 option: 54 server-identifier <IP> sent size: 9 option: 60 vendor-class 50:58:45:43:6c:69:65:6e:74 sent size: 17 option: 97 client-machine-id in.tftpd[27886]: Error code 8: User aborted the transfer in.tftpd[27887]: Client <machine_IP>finished ipxe.efi available DHCP subnet: <IP>/255.255.255.0 vendor class: PXEClient:Arch:00007:UNDI:003010 user class: iPXE PXE(ens160) <MAC> proxy tags: ipxe, team1, ens160 bootfile name: filenotneeded next server: <IP> broadcast response sent size: 1 option: 53 message-type 2 sent size: 4 option: 54 server-identifier <IP> sent size: 9 option: 60 vendor-class 50:58:45:43:6c:69:65:6e:74 sent size: 17 option: 97 client-machine-id available DHCP subnet: <IP>/255.255.255.0 vendor class: PXEClient:Arch:00007:UNDI:003010 user class: iPXE PXE(ens160) <MAC> proxy tags: ipxe, team1, ens160 bootfile name: filenotneeded next server: <IP> broadcast response sent size: 1 option: 53 message-type 2 sent size: 4 option: 54 server-identifier <IP> sent size: 9 option: 60 vendor-class 50:58:45:43:6c:69:65:6e:74 sent size: 17 option: 97 client-machine-id available DHCP subnet: <IP>/255.255.255.0 vendor class: PXEClient:Arch:00007:UNDI:003010 user class: iPXE PXE(ens160) <MAC> proxy tags: ipxe, team1, ens160 bootfile name: filenotneeded next server: <IP> broadcast response sent size: 1 option: 53 message-type 2 sent size: 4 option: 54 server-identifier <IP> sent size: 9 option: 60 vendor-class 50:58:45:43:6c:69:65:6e:74 sent size: 17 option: 97 client-machine-id available DHCP subnet: <IP>/255.255.255.0 vendor class: PXEClient:Arch:00007:UNDI:003010 user class: iPXE PXE(ens160) <MAC> proxy tags: ipxe, team1, ens160 bootfile name: filenotneeded next server: <IP> broadcast response sent size: 1 option: 53 message-type 2 sent size: 4 option: 54 server-identifier <IP> sent size: 9 option: 60 vendor-class 50:58:45:43:6c:69:65:6e:74 sent size: 17 option: 97 client-machine-id available DHCP subnet: <IP>/255.255.255.0 vendor class: PXEClient:Arch:00007:UNDI:003010 user class: iPXE available DHCP subnet: <IP>/255.255.255.0 vendor class: PXEClient:Arch:00007:UNDI:003010 user class: iPXE available DHCP subnet: <IP>/255.255.255.0 vendor class: PXEClient:Arch:00007:UNDI:003010 user class: iPXE available DHCP subnet: <IP>/255.255.255.0 vendor class: PXEClient:Arch:00007:UNDI:003010 user class: iPXE localhost in.tftpd[27997]: Client <machine_IP>finished default.ipxe -
RE: Multiple FOG servers in one networkposted in General
@george1421 @Sebastian-Roth
Thank you for your valuable input. My idea is to separate not only the hosts but also snapins/images/literally everything. What I want to achieve is to have dedicated Fog server per team. The process of MAC address separation must be fully automatic.
I will develop the script that will:- Query database for hosts in the 60s loop
- Write MAC list to temp_mac file.
- If there is no amac_table.conf file, write temp_mac file as amac_table.conf
- If amac_table.conf exists, do diff on these files
- If files are same, do nothing
- If files differ, copy temp_mac over the amac_table.conf and restart dnsmasq service.
My only concern is, how to tell dnsmasq to read this particular file and how data should be formatted inside this MAC conf file?
May you shed some light on it ?
Obviously I will share my work here.
-
RE: Multiple FOG servers in one networkposted in General
@Sebastian-Roth
HI. Thanks for this.
Looks very promising. Will tests this method soon. -
RE: Multiple FOG servers in one networkposted in General
@Sebastian-Roth said in Multiple FOG servers in one network:
Why using dnsmasq anyway? What DHCP server do you have right now that cannot be modified to do PXE boot?
I have no access to DHCP server. Company’s policy.
-
RE: Multiple FOG servers in one networkposted in General
@Wayne-Workman
@george1421
Would this be possible to use dnsmasq as a MAC address filter?
I imagine this kind of setup:- Existing dhcp server in the network
- Fog server 1 with dnsmasq
- Fog server X with dnsmasq
dnsmasq will respond with dhcp offer as it does right now, but only to the machines included on MAC address list.
Simple query to FOG’s mysql will get registered hosts from DB and update the list automatically.
If this is not possible with dnsmasq I thought iptables could be used instead?
Obviously, we will lost the ability to register new machines from the FOG boot menu.