Michael Thomas last edited by
Hello fog featurists(?)
Currently i can’t see anywhere, if the fog script at the client fails, or?
The “report page” only shows: “Script was run then and took xxx seconds”
Debugging and ~ reporting is very complicate or impossible.
If this is not my ridiculous newbee fault i would like to ask:
Would it make sense the setup a remote syslogd so the fog-script could sent persistent log file entries
to the fog-server (eg).
IIRC this are only some few lines of configuration in /etc and installing (see below)
As the clients fog script/kernel already knows where to pull the images he could sent UPD-packages in this direction.
What is my error there? I can’t imagine why this is not already done instead of “blind filying”.
The webpages and set up must be expanded, some day. But in the first step only the PXEied kernels have to be patched, or?
it should be mentioned that in the latest fog kernels pauses have been added that require interaction when in debug mode. this allows you to read the messages that come up during the process.
Why would the PXE kernels have to be patched?
You must remember that we’re using a lot of networking just for the imaging process. Setting up a remote syslog server will use more of those resources, not to mention the resource load of the Client and FOG Server to send, receive, and process the messages being sent on TOP of the network transfer of the image and processing to place the image.
This is actually why, I think, the system has Upload/Download - Debug task creation methods inserted. To allow you to find and troubleshoot an error from the client. Seeing as the only time you, typically, have problems is during the “testing” and “upload” phases, scheduling them to run in Debug isn’t any more or less difficult than trying to have the developers learn another new software package. If you want to include it, by all means I’m not going to stop you. Feel free to post your results. Just remember, we’ve already got TONS of packages that we’re installing and troubleshooting across the forums. Now imagine trying to have us learn another new software package and incorporating a perspective to view and scan.
Add to all of that and imagine the “scanning” of syslog messages of potentially hundreds (if not thousands) of other clients imaging and writing to this log.