I noticed this issue yesterday on my 1.2.0 test server. After digging through several unresolved bug reports for Ubuntu and Debian, I found that tftpd-hpa no longer likes being bound to 0.0.0.0:69. It now prefers :69 without the IP. Apparently, it can’t resolve 0.0.0.0 (which is ridiculous).

The quick fix is to edit the /etc/default/tftpd-hpa file. Change the value of TFTP_ADDRESS to equal “:69” instead of “0.0.0.0:69”.

This was resolved in SVN 3539/Commit eadae1b.

Try that out and see if it fixes your problem.

@Wayne-Workman Thanks! It’s been a while since I have checked out the forums. I’ve been mostly playing around with FOG on git quietly.

I’m pretty sure I can get this fixed. I just need to get some example output.

Can you get the contents of d1.original.partitions for me?

Also, it might help to check the last few log entries in /var/log/apache2/error.log. Perhaps running this might help provide everyone a better idea about what’s going on: tail -20 /var/log/apache2/error.log

To get that version number, run: grep FOG_VERSION /var/www/fog/lib/fog/System.class.php

[quote=“Tom Elliott, post: 43684, member: 7271”]inventory.php doesn’t do the registering, only auto.register.php handles this. 3102 should work, but I don’t have multiple macs to test against either.[/quote]

Still figuring out where everything is going.

I was looking at fog.register, not fog.auto.reg. That would make sense! I’ll see if I can figure out what it is doing for you.

I just gave SVN 3102 a shot. The new code does what it should, but only the first MAC is registered (no additional MACs are registered). I lucked out and had it register eth1 instead of eth0. That’s good for me, but maybe not for someone else.

I don’t fully understand the inventory.php execution yet, but it must be only grabbing the first MAC and discards the rest.

[quote=“Tom Elliott, post: 43634, member: 7271”]Uncle Frank, cspence’s means no loops either![/quote]

Moments like these are why I love collaborating with others on code. Just a few suggestions and the code collapses to nothing.

How low can we go?

[CODE]# Get All Active MAC Addresses
getMACAddresses()
{
lomac=00:00:00:00:00:00
cat /sys/class/net/*/address | grep -v $lomac | tr ‘\n’ ‘|’ | sed s/.$//g
}[/CODE]

[quote=“Uncle Frank, post: 43627, member: 28116”]I don’t think so…
[CODE]# Get All Active MAC Addresses
getMACAddresses()
{
IFS=$‘\n’
# Create a pipe-separated MAC List
for macline in $(cat /sys/class/net/*/address); do
# Add a pipe before adding more MACs
if [ -n “$mac” ]; then
mac=$mac|
fi
mac=${mac}${macline};
done
IFS=
echo $mac
}[/CODE]
No ip, no awk, no grep…[/quote]

It grabs lo’s MAC. But I like where this is going…

[code]# Get All Active MAC Addresses
getMACAddresses()
{
IFS=$‘\n’
# Create a pipe-separated MAC List
for macline in $(ip addr | grep link/ether | awk ‘{print $2}’); do
# Add a pipe before adding more MACs
if [ -n “$mac” ]; then
mac=$mac|
fi
mac=${mac}${macline};
done
IFS=
echo $mac
}[/code]

Caught a bug with your final mac= statement. Also, “ip addr” is fine by itself.

[quote=“Tom Elliott, post: 43618, member: 7271”]Oh, i do have a thought though.

Using the generate our interfaces file on the fly method, I can add the e-polling capabilities of the kernel to use more proper methods of device management. This means not all devices will automatically have eth* names, but rather whatever the device is. Is there a simpler way without designating the specific devices to search for?[/quote]

[CODE]# Set for loop delimiters to just newline
IFS=$‘\n’

Create a pipe-separated MAC list

for macline in $(ip addr | grep link/ether)
do
# Add a pipe before adding more MACs
if [ -n “$mac” ]; then
mac=$mac|
fi
mac=$macecho $macline | xargs | cut -d ' ' -f 2
done

Reset delimiters

IFS=[/CODE]

I just realized I was doing a grep on link/ether so that doesn’t include lo. Enjoy!

[quote=“Tom Elliott, post: 43616, member: 7271”]I’ll build a function rather than code this into the individually requested files.

I’ll have to adjust the service scripts so they no longer look for HWAddr in the fields, but I think it better to scan only for the mac addresses.[/quote]

Sounds better to me.

[quote=“Tom Elliott, post: 43613, member: 7271”]And I can see you already thought of that…[/quote]

I was about to say…

After looking over the code and testing a few things, I have a snippet of code that could replace the mac= statements. It also ditches the use of the legacy net tools command. Another thing to note, it just grabs all MAC addresses, but it makes it usable for imaging. This could be improved to make the primary (or first MAC) the active connection.

[CODE]# Set for loop delimiters to just newline
IFS=$‘\n’

Create a pipe-separated MAC list

for macline in $(ip addr show label eth* | grep link/ether)
do
# Add a pipe before adding more MACs
if [ -n “$mac” ]; then
mac=$mac|
fi
mac=$macecho $macline | xargs | cut -d ' ' -f 2
done

Reset delimiters

IFS=[/CODE]

This should be used for any registration functions for fog scripts. Hopefully I didn’t add in any typos this time.

[quote=“Wayne Workman, post: 43506, member: 28155”]Our district runs under just a hand-full of public IP addresses. The router handles NAT. Our clients have internally issued private IP addresses, and our FOG server has a static private IP address. They communicate fine.

I suppose you were saying that the systems you look after all have public IPs ? Now that’s interesting…[/quote]

The University I work at runs all public IPs with minor exceptions.

I would just stick with the interfaces that are currently up (just like with the client image issue we had the other week). I would assume that if a machine had used PXE to take inventory, the connected interfaces would be more useful. We could detect what interfaces are up. After that, I would have to take a look at the source to give better insight. If I get the chance this week, I’ll look at the source and see what might work.

In the meantime, we can code for the future and use:

[CODE]
ip link show dev $iface | grep link/ether | xargs | cut -d ’ ’ -f 2
[/CODE]

[quote=“Tom Elliott, post: 43343, member: 7271”]There’s only two calls to fogproject.org during the login phase. They’re both, now, and even before, using the fetchURL method.[/quote]

That’s even more interesting. Any ideas why if I comment out the contents of fetchURL() in FOGCore.class.php why it still attempts to visit URLs then? I have to be missing something…

Before you try to code around an issue we don’t quite understand (I would hate to see you waste time on the wrong chunk of code.), I have some more test results.

I tried commenting out the fetchURL() function contents, but it still froze up on the ajax call. So that was unexpected from what I know so far from analyzing the code. So I made sure that the apache server had been restarted and that you guys didn’t do something crazy with PHP (I had to make sure you weren’t running something like HipHop or some other compiled PHP project).

Next I installed Wireshark to see how it was potentially doing on the network. FOG was sending DNS requests like crazy to my internal DNS (which of course is also isolated in my network). The requests would fail out naturally.

By this point, I realized that this was a good time to follow my advice from earlier. I added 0.0.0.0 fogproject.org to my /etc/hosts. Instant page loads!

This leaves us with two+ questions:
[LIST=1]
[]Where in execution outside of fetchURL() does the server attempt to resolve fogproject.org when http(s)://foginstallation.tld/fog/management/index.php?node=client&sub=loginInfo?
[]Are those other queries being run non-blocking? (probably not)
[*]If everything is running non-blocking (if, remember), does that mean that the way PHP does DNS is still blocking? (Unlikely from what I would expect so far.)
[/LIST]

It’s definitely the server-side though. You can lock up the server by just visiting the URL the Ajax call uses. After all, client-side scripts should not lock up the server.