Tasks do not start

[A Former User]

Hi

I had been running fog 1.2.0 for a whilst mostly ok but came to a problem with a vista machine and apparently this was a bug in that version after posting here, i tried updating to svn 2996 on Tom’s recommendation but had a bunch of other unrelated issues issues so instead I decided to start from scratch and installed Xubuntu LTS 14.04b and svm 2996 again everything seems to be behaving, i can boot to pxe menu and register my host just fine

Created image on the web gui, assigned to host and queued instant upload task. But my client just boots to the pxe menu, quick image tells me host already has active task (which it does).

Bit stumped as to where I have gone wrong here. I am not seeing any obvious errors, checked the /var/log/fog folder but no errors. Similarly apache logs shows my client booting pxe fine.

Any pointers for where to look next?

Thanks

[Sebastian Roth]

AFAIK you don’t need anything special. Just option 66 and 67. No dot at the end of the IP! Are you familiar with wireshark/tcpdump. If not maybe it’s time to dive into that part of network debugging. Capture the DHCP traffic and compare working against non-working setup. Probably best to use a hub to be able to capture that traffic. On your FOG server you can just use tcpdump straight away:
[CODE]sudo tcpdump -i eth0 -w /tmp/packet_capture.pcap[/CODE]
You can then transfer this file to your PC and open it up using wireshark… Try display filters to find DHCP (filter: bootp) and TFTP (filter: tftp) traffic.

[A Former User]

will have a read of that now, so i tried my theory of configure fog with dhcp then kill the service and it behaves much the same.
started again and removed from my production network and it seems to work, so whatever it is its not handling what the dhcp server on my draytek is handing out, though also doesn’t explain why a tftp test from a client machine got rejected as well. Will play around a bit more and try and try and pin down cause. Im not wrong in thinking its just 66/67 i need? Also presume i dont need anything silly like a . at end of the ip for tftp server like DNS on a domain name ?

[Sebastian Roth]

Shouldn’t make the difference! DHCP and TFTP don’t need to be on the same machine. Have you tried to follow this step by step: [URL=‘http://fogproject.org/wiki/index.php/Tftp_timeout…’]http://fogproject.org/wiki/index.php/Tftp_timeout[/URL]…

[A Former User]

Yep, still broken but I have one last idea. Going to reinstall with fog as dhcp and then disable the dhcp service plug back into my meyeork and see if it makes a difference but seems each time using fog as own dhcp seems to allow connections

[Sebastian Roth]

And you still can’t ‘tftp’ from your clients to the server?!

[A Former User]

First command doesn’t return anything, however this is centos install now as I started from scratch again due to earlier problems, however xinetd I believe handles tftp which does run if I grep xinetd.

But returns same as you with the 0.0.0.0:69

Similarly up tables lists fine again no rules and accept as you say, I would paste my console but only got access via ssh client on my iphone at the moment which doesn’t want to let me

[Sebastian Roth]

Yes, those two options should suite you. Really wired, why should tftp(-client) need sudo??

See if your TFTP server ist running an listening on the correct address:
[CODE]# netstat -antup | grep tftp
udp 0 0 0.0.0.0:69 0.0.0.0:* 10149/in.tftpd[/CODE]
Check iptables firewall rules:
[CODE]# iptables -L -n -v
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination[/CODE]
Here you see three chains. Pay close attention to INPUT and OUTPUT. ‘policy’ should be ‘ACCEPT’ and no rules defined (as you see in the output here) unless you really know how to configure linux firewall.

[A Former User]

Options 66/67 eg the tftp server and then the boot file name are set, I was under impression these were the two settings needed? The clients get an IP fine but when they attempt to connect to what they are given it times out.

Testing tftp I’m using (off top of head, at home now)

Tftp -v localhost -c get undionly.kpxe , appears to work when using sudo but not without

[Sebastian Roth]

AFAIK it’s …mac=12:34:56:78:90:ab (colons and lowercase letters). Please correct me if I am wrong!

I am not sure if I get your setup right. Is the draytek router also setup to offer TFTP or just DHCP pointing to FOG as next-server? Which commands do you use to test TFTP???

[Junkhacker]

[quote=“bengillam, post: 42692, member: 28624”]thanks I will try that to check it out, presume i write mac as is without colons or dashes?[/quote]

with colons

[A Former User]

[quote=“Junkhacker, post: 42675, member: 21583”]in order to see the different output of boot.php for the host with a scheduled task, you need to make the url [URL=‘http://%3Cfog-server-ip%3E/fog/service/ipxe/boot.php’]http://<fog-server-ip>/fog/service/ipxe/boot.php[/URL]?mac=<host-mac-address>[/quote]

thanks I will try that to check it out, presume i write mac as is without colons or dashes?

[A Former User]

ok centos installed, fog installed and getting tftp timeout error, testing from any remote machine for tftp just does not seem to respond.

Its very strange, ive tested and queried my dhcp server on draytek router, it is definitely handing out the tftp server ip and the undionly.kpxe fine, but any attempt to connect to the tftp server outside of the machine itself fails. Also even locally now when i try the test command I get a permissions fail unless i use sudo.

But strangely if i delete my .fogsettings and re-set up with fogserver as dhcp it works fine. Any ideas?

This is on 3036 now but had exact same issue with ubuntu 14.

my local user on machine at the moment (which is an admin) is ccsadmin

os at the moment is centos 7

Ideally would be nice to have fog on main network rather than separated to its own switch hence using dhcp of the router.

tried from other posts setting recursive 777 permissions on tftpboot folder
and chown -R ccsadmin:root
and restorecon -Rv /tftpboot

selinux is definitely disabled, as it iptables etc

Possibly one small thing im missing here, just seem to his this same point then his problems. Any help would be much appreciated.

[Junkhacker]

in order to see the different output of boot.php for the host with a scheduled task, you need to make the url [URL=‘http://%3Cfog-server-ip%3E/fog/service/ipxe/boot.php’]http://<fog-server-ip>/fog/service/ipxe/boot.php[/URL]?mac=<host-mac-address>

[A Former User]

thanks guys will give a different build a try.

uncle frank, in both cases the boot.php was quite long. But the machines were definitely registered and MAC addresses all checked out as well as bios/system time etc both ends which has tripped me up before now.

Think i might also bite bullet and put on something like centos in place of xubuntu as I read a few places ubuntu had its issues , eg image size

Will let you know how I get on

[Tom Elliott]

You could try 3036. I’ve reverted most of the speed improvements while leaving the code available for me to fiddle with. I’ve seen much better success with this at work and in testing so hopefully it’ll work better for your needs as well? If earlier is what you’re after you could definitely use 2948 as a fairly rock solid build as well.

[Sebastian Roth]

You’d see the difference, I am sure! The output from boot.php is only 4-5 lines if that particular client is scheduled with a task BUT is much longer if there is no task (and therefore shows the menu).

Are you sure that you are scheduling that task for the same machine that you try to access the URL from?? Maybe MAC address was changed or something like that. Please double check the clients MAC address and compare it with the one being configured for that particular client in the webinterface…

Tom reverted the whole repository back to 2996 just a few days ago as he couldn’t get to a satisfying end tracking down the performace issue. I think you’re pretty alright with 2996 at the moment!

[A Former User]

hard to tell how much different, lots of code displayed, FWIW booting machine post registration lists machine at top of boot screen as registered as <machinename> - Starting to wonder if build is buggy? this is 2996, is there a relatively stable earlier rev? i understand later ones are possibly broken whilst Tom is working on speed improvements?

[A Former User]

I will heck that out tomorrow morning don’t have vpn access to test network - thanks

[Sebastian Roth]

AFAIK that client gets to see a different iPXE file depending on a task being scheduled for it or not. The file your are looking for is being generated output by the following PHP script: [url]http://<fog-server-ip>/fog/service/ipxe/boot.php[/url]

Type this URL into your browser. It should look different when you request it from your normal PC than when you send the request from that Client that is supposed to run a task (should be way shorter then!). Does it look different??