@Tom-Elliott everything seems to be working fine now using the working-branch, both inventory and the image task, thanks.

@sudburr Of course, but you can change where these are written to (in console).

Each of the services have a default tty (and they should all be different, though it wouldn’t hurt anything to have them on the same).

The idea, I think, is so make users more aware of the services and that they are running and any issues that might be happening. I don’t know how any information printed out by the services would be “sensitive” unless your file names are in such a way it might give out PII or confidential/sensitive information. In that case, though, you can just change the TTY for the services within FOG Configuration -> FOG Settings -> FOG Linux Service TTY Output (I think).

@Tom-Elliott Thanks for the very fast assistance! Awesome work as usual.

My magic is fixing it now.

Will be in for RC-27.

@Tom-Elliott Haven’t had it happen again yet.

@Tom-Elliott I upgraded to RC25 yesterday and have not been able to reproduce the issue again.

I think the issue is solved. At home, I just shutdown one of the nodes I have without adjusting any configuration and the web interface stayed operational.

While I’m super glad to have pushed up RC-25, I just wanted others to understand the idea.

The original issue is I switched over to a much less SQL tasking request system. Basically, the way things where (while much progress had been made originally anyway) very sql taxing. For a host, you might have had 12 separate SQL queries per each host to get the data.

I figured out a nicer mechanism around this, but missed two steps. While I was testing things, I was very minimally doing so just ensuring things were operational, not necessary “working” if that makes sense.

To fix this particular issue I basically had to have the class load itself again which doesn’t do much to get away from sql queries.

I’ve since fixed this issue, tested, and validated it’s operational and functional as well without the excess SQL queries which will be available for RC-26.

Just thought it’d be good to give everyone a heads up on it.

Thanks.

@Tom-Elliott worked like a charm sir

This is the same issue described here:
https://forums.fogproject.org/topic/8406/fog-client-printer-not-displaying

There isn’t a fix yet. The best you can do is deal with the FOG Client’s printer sensitivities.

I’ve also found that a FOGService restart helps a lot (reboot). For whatever reason, sometimes the fog client in my building just stops working for the duration of said computer being on, until the next reboot.

@Tom-Elliott Great! 🙂 Thank you!

Confirmed both and both are now fixed for the working branch.

@Tom-Elliott Thanks!

@Tom-Elliott said in Installation script error phpfpm:

@Claude-Girard And now? (Yes repull and try again.)

Yes it’s ok now.
Thank you

I agree.

@Duncan yes.

Is it possible to solve this thread yet?

I ask because I worked on a few systems last week, and they all seemed to have been getting their information and things appeared to be setting properly.

The noted items was if I manually stopped/started the FOG Service on the machines, the default printer setting would not happen, which is (as I recall it) expected as the default setter happens via the FOGUserService, not the FOGService element. When you manually stop the FOGService, the FOGUserService is closed to, but on FOGService start (manually) the FOGUserService is not automatically restarted.

Aha, that’s why I didn’t find that post in a search. Can’t keyword search attached pictures.

Changing mine to

FOG_URL_AVAILABLE_TIMEOUT = 3000

… fixed it for me. Thank you.

Ok, so the interface name wasn’t showing because somehow it was wrong in the storage node’s settings.

I never changed that… so that’s probably something broken with the auto-registering auto-correcting stuff @Tom-Elliott