No problem. I’ll just paste a bit of the documentation on that function here:

[COLOR=#0000ff][B]fread()[/B] reads up to length bytes from the file pointer referenced by handle. Reading stops as soon as one of the following conditions is met: [/COLOR]
[LIST]
[][COLOR=#0000ff] length bytes have been read [/COLOR]
[][COLOR=#0000ff] EOF (end of file) is reached [/COLOR]
[][COLOR=#0000ff] a packet becomes available or the [URL=‘http://php.net/manual/en/function.socket-set-timeout.php’][COLOR=#0000ff] socket timeout[/COLOR][/URL] occurs (for network streams) [/COLOR]
[][COLOR=#0000ff] if the stream is read buffered and it does not represent a plain file, at most one read of up to a number of bytes equal to the chunk size (usually 8192) is made; depending on the previously buffered data, the size of the returned data may be larger than the chunk size. [/COLOR]
[/LIST]
So let’s walk through the bullets:

1. If the file descriptor is waiting for input, it will definitely not reach the length.
2. There is no EOF because the socket is still waiting for input.
3. The socket will ultimately fail out because it can’t contact the server. In the meantime, the command still waits.
4. I’m not exactly sure how this behaves with a network socket, but it is still waiting for buffered data to arrive.

One more thing to think about when trying to handle this process: If you were able to make fread() non-blocking (or multi-threaded), what affect does that have? Instant failure to grab any input. Additionally, since the function getting the data is not reading from readily available source (like a database entry), it has to wait or fail. This is why you need to have something like a service that does this outside of the server. The service can update the database or a file that the webserver could check. Instead of waiting for something that is not there at the instant it checks, it will always be there or not be there (EOF).

The fopen() function can be non-blocking because it can be redirected somewhere like a log or database entry. But be careful, this doesn’t mean you should redirect this to a database each time there is a call to fetchURL(). You will get data before it is overwritten by the latest fetchURL() call. In other words, stuff will wack out. If a lock is placed on that database entry while trying to write to it, you’ll have another source of I/O blocking. This is yet another reason to just set up a service that will only update periodically and not every time you visit pages.

If I made a mistake somewhere, feel free to point it out.

[quote=“Wayne Workman, post: 43330, member: 28155”]On a serious note, how likely is a DoS to happen from within your own network? Nobody is going to build a FOG server inside a de-militarized zone, with a public IP address…

FOG is for internal use. ;-)[/quote]

Unless you’re running an air-gapped hacking proving ground for Information Assurance (Cyber Security) students at a University where you need to deploy fresh machine images in short amounts of time. Then it’s definitely a threat.

In that case, FOG is not for internal use. It’s for anyone who needs a copy of a machine image deployed.

[quote=“Wayne Workman, post: 43326, member: 28155”]Perhaps we can be given the option to change the timeout length?

Is there a PHP edit we can do to change it? Maybe the FOG web GUI can pull this value from a file, instead of it being hard-coded into the PHP ?[/quote]

You can change the socket timeout, but it is still going to eat performance with more users. Like I said before, it’s easy to cause a DoS by requesting that Ajax call repeatedly. This could also happen if you have three people on the website at the same time. Any time a user visits the login or views other pages that leverage fetchURL() like the configuration settings page, there is going to be a server freeze.

Considering that the only usage of fetchURL is for getting latest version or server count data, that could be handled outside of the web server. I’ll even write a service script to help with this.

Registration registers eth0 regardless of connection state.

Version: SVN 3080
Server OS: Debian
NIC Not Used: eth0
NIC Used: eth1

PXE works fine on eth1 for me. Once the quick registration option is selected, it registers eth0 and carries on. Of course, it won’t recognize the machine on boot for imaging tasks until the MAC address is manually changed. Upon changing the MAC address to the eth1 adapter, the imaging process works fine.

This may be related to the [URL=‘http://fogproject.org/forum/threads/multiple-nic-hosts.12511/’]other bug I reported earlier[/URL] regarding multiple NIC hosts having trouble with any tasks.

…work load was a bit high the last two days.

I just installed 3080. I see what you tried, but it still relies on a blocking operation: [URL=‘http://php.net/manual/en/function.fread.php’]fread/URL.

The fopen() function followed by stream_set_blocking($fp,0) is great for sending stream data to a non-blocking receiver. The fopen() function is blocking by nature. It sits and waits for any of the four conditions that causes the function to fail or complete (in our case, it waits for the socket timeout which is the same problem again).

If you want to do local testing for this problem, you can temporarily put the following line into your /etc/hosts file:

0.0.0.0 fogproject.org

Be sure to remove it when you want to end testing and see this site again.

This is not a problem you can solve using server calls (whether or not they come from client-side code or internal functions). You’ll need to set up a service that can update your database or provide a file to check locally.

[quote=“Tom Elliott, post: 43130, member: 7271”]It’s all good, you should see the issues I forget about, like using my mac address implicitly in the inventory and wondering why everybody else is getting repeated inventory errors.[/quote]

Now that’s a good one.

[quote=“Tom Elliott, post: 43128, member: 7271”]There’s one more issue

Shouldn’t the cat be reading a file, not the directory?[/quote]

Yes. Fixed again. I really should have slept more last night.

Now that we got the NIC issue figured out, I got a chance to test this problem out with SVN 3053.

Unfortunately at this point, it appears I need to do some more troubleshooting because the multicast session fails to start at all. Currently, I tried using Multiple Partition - Single Disk Imaging. I’ll pick this up again a bit later (hopefully this week). This week has proven to be busier than usual.

[quote=“Tom Elliott, post: 43117, member: 7271”]Also, shouldn’t the tr -d be tr -d ‘@’ not tr -d ‘0’?[/quote]

Sorry, I was copying off code from my cellphone and wasn’t thinking about what I was typing. Also caught another typo on the udhcpc_opt statement.

Fixed the typos in the original post.

[CODE]# Enable all interfaces
ifaces=$(ls -1 /sys/class/net | tr -d ‘@’)
for iface in $ifaces; do
/sbin/ip link set $iface up
done

Provide time for interfaces to detect their state

sleep 5

echo “auto lo” > /etc/network/interfaces
echo “iface lo inet loopback” >> /etc/network/interfaces

for iface in $ifaces; do
linkstate=$(/bin/cat /sys/class/net/$iface/carrier)
if [[ “x$linkstate” = “x1” -a “x$iface” != “xlo” ]]; then
echo “auto $iface” >> /etc/network/interfaces
echo “iface $iface inet dhcp” >> /etc/network/interfaces
echo -e “\tudhcpc_opts -t 100 -T 20\n” >> /etc/network/interfaces
fi
/sbin/ip link set $iface down
done[/CODE]

This solution only requires one sleep rather than five-seconds of sleep time per interface.

Edit: Fixed typos.

Finally got a chance to play with it, and I have a solution.

Insert a 5-second sleep between setting the interface up and checking the link status (we can’t just check before it gets a chance to find out if it is connected to a cable). Here’s the snippet as modified.

[CODE]…
/sbin/ip link set $iface up

Provide time for the interface to update linkstate

sleep 5
linkstate=$(/bin/cat /sys/class/net/$iface/carrier)
…[/CODE]

Works on my end.

…and if you wait just a second, I’ll have an optimized version…

[quote=“Tom Elliott, post: 43023, member: 7271”]What’s weird, though, is the /etc/network/interfaces appears to get the proper values set (without the -a) but even without eth0 should still be found with little issue, and without these tweaks (reverting back to only having iface eth0) everything functions properly.[/quote]

Actually, I was trying to go off memory. The flag is [B]-i $iface[/B]. You don’t want to use -a. Sorry about that.

Good to hear. I’ll be able to test it tomorrow.

By default, udhcpc uses eth0. You will probably need to add -a $iface to udhcpc_opts. I was unsure if that would be taken care of by /etc/network/interfaces.

I just confirmed that my guess was correct. The site uses PHP’s blocking function file_get_contents(). If you are like the original poster and have a slow connection or you are like me and have no Internet access at all, you will see the PHP server waiting for the website to resolve since the command is blocking. This is also why I noticed that the site became unresponsive temporarily upon visiting the configuration settings page.

This is much more serious for users like me that provide an imaging service in an isolated/air-gapped network. An attacker could initiate a denial of service attack by sending requests to http(s)://foginstallation.tld/fog/management/index.php?node=client&sub=loginInfo. This type of attack wouldn’t set off normal load balancing equipment either since you could send these requests once in a while (with those timeouts, you could do a request every 10 seconds to really hurt performance).

If you want to continue pulling data from a foreign website (fogproject.org) for tracking purposes, you’ll need to look into creating a service for checking the data that’s causing this trouble. The data pulled can either be placed directly on the database, or it could be placed on a static page.

If you don’t care about tracking data, you can look into a few tricks to get around cross-domain request restrictions. One such way is by including a javascript file with the version and server data hard-coded in. But again, you lose all your tracking data if that’s why you do it (you would get client GET requests, not server ones).

Finally, I would highly suggest replacing any fetchURL() invocations (which appear to be associated with fetching version information) with the service solution I suggested.

Additionally, I would highly suggest providing the ability to turn off version checking for people who are running in isolated environments.

That’s something I wanted to look at. It’s something that happens when you run blocking system commands on a single-threaded server. It halts all other requests until the command completes. The same thing happens if you allow host listings to ping hosts on your network (I’m glad that’s disabled by default on the Post-1.2.0 builds.).

That’s just my guess as to what is happening since I’ve seen similar problems before that fit my assumption. I haven’t dug into the code yet since I’m still working on other objectives for deploying FOG into my network.

[U]Possible solution[/U]
[LIST=1]
[]Have a background service that checks periodically and edits a static element of the website (asynchronous process method).
[]Handle the server check with client-side code. Client-side checks won’t halt the entire server waiting for them to complete.
[/LIST]

[quote=“Tom Elliott, post: 42949, member: 7271”]From what I’m seeing, we don’t need the -l on the ls.

Why? Because the link is back to the /sys/devices/<location> and the separation in that folder contains multiple delimiters we need to break from. Will correct, but the for loop, from what I can see only needs to be ls /sys/class/net | tr -d ‘@’[/quote]

Careful, that’s not an “L”, that’s a “One.” He set it up to do one file/directory per line.

Good to hear! Thanks everyone.

Added full paths. Replaced the ifconfig with the iproute2 replacement (it’s best to move away from a legacy tool). Redirected output to /etc/network/interfaces. If we slap this into /etc/init.d/S40network before the case statement, that should be a fix. I’ll be able to test it on Monday.

[CODE]for iface in $(ls -1 /sys/class/net | tr -d ‘@’)
do

all interface need to be up or you will get an invalid

argument error when checking the link state

/sbin/ip link set $iface up
linkstate=$(/bin/cat /sys/class/net/$iface/carrier)
if [[ “x$linkstate” = “x1” ]]
then
if [[ “x$iface” = “xlo” ]]
then
echo “auto lo” > /etc/network/interfaces
echo “iface lo inet loopback” >> /etc/network/interfaces
else
echo “auto $iface” >> /etc/network/interfaces
echo “iface $iface inet dhcp” >> /etc/network/interfaces
echo -e “\tudhcpc_opts -t 100 -T 20\n” >> /etc/network/interfaces
fi
fi
done[/CODE]

[quote=“Wayne Workman, post: 42928, member: 28155”]^ this guy needs to be a regular here.

Clearly a power user, if I ever saw one.[/quote]

Well, it’s my first week playing with FOG finally. As I slowly familiarize myself with the structure of FOG, you should expect better diagnoses. You’ll probably see me hunting down more issues as we go.

As someone who is a system administrator for a cyber security program’s air-gapped hacking proving ground at a University, you could say power user. I’m looking forward to getting this deployed in the next few weeks in my network. I have been dying for a decent solution for deploying Linux and Windows images multiple times in a day within small windows of time.