Confirmed working at home.

@Joe-Schmitt What in the world could have done that? Also - kinda scary too.

Sorry to pop this bubble… Due to communication issues, I thought PortFast was turned off for this case. I’ve found out that PortFast was in fact turned on.

@Tom-Elliott I ended up just resetting the fogstorage password and replacing the $ with an s and ran a script to change this on all nodes.

I can continue to test escaping at home though.

Fixed for RC-9

@Wayne-Workman I’ve been kept busy by my studies and patching the auto updating bug that affected many users (more work is still required to prevent it from happening in the future. The hotfix simply bought us 2 years to fix it).

Just to help clarify, basically it was filtering the array out. Because there was only two tasks, and one of them was invalid, it was not defining the tasks as an array.

Tom worked on a patch quietly since I started this thread - and I’ve tested it - and it works.

My storage node at home that I tested on is an old Pentium 4 with an IDE drive in it - so it’s very slow.
Results at home:

I could open 12 pages and let them sit on the fog dashboard - CPU usage on the storage node stayed below 4, there weren’t uncontrollable httpd processes spawning, Open files by the apache user stayed below 4k - and the bandwidth chart not only reported - but it’s now reporting more smoothly than ever, is actually accurate now, and doesn’t have spells of mental disability anymore. It’s like butter.

The issue, as it was explained to me, is that the JS which renders the bandwidth chart and does the polling of bandwidth.php on all nodes enabled for bandwidth reporting - it wasn’t waiting for a response, it would just re-issue another poll before the response was received. The more dashboards open, the worse it got, until eventually apache was unable to do anything do to it’s tremendous load of ‘stacked’ processes that were back-logged. I didn’t tell anyone but Tom - but this (now solved) issue would break imaging at remote locations, too - because we use the location plugin and apache on the remote nodes is relied upon to get imaging done in this setup. That too is solved now.

These fixes will all be in RC-9.

Ok, cool.

@Tom-Elliott Ok then.

@MRCUR There should be - what the admin wants and is acceptable. Would I want a uniform password in every environment? No. I work in a public school, and very often I’m walking down the halls and someone comes out asking for help - and I don’t have my laptop with me. The less passwords I type in front of people, the better. Often, technicians fill in at other buildings - we don’t share AD credentials among technicians for our domains, but we do share local passwords with other techs so they can fill in where needed. LAPS would make that harder.

I would encourage people to use LAPS if they want the highest degree of local account security, but it would complicate my job further than I would like in my current position and slow my ability to solve problems.

@Tom-Elliott Actually, the issue just appeared on our big fog system, too. And after refreshing the page, that too disappeared.

0_1470939151452_upload-2973df0c-a05c-4a51-92e1-db1d1949078f

Just confirmed and sharing - FOG 1.3.0 RC-11 also works just fine on Fresh Ubuntu 16 Server without any special commands.

Both of the selector issues are fixed in RC-9.

Reworked validation for all pages and have confirmed, within reasonable certainty, that all is now validating properly. If a form using validation (Users, Hosts, Printers, Snapins, etc…) is invalid it will prompt near the box and will not allow the form to be submitted.

I now remember this being corrected for in a later RC, this was the line 23 issue.

I’ve deleted that massive log, and updated.

ALSO - many folks here I’ve seen their root partition fill up recently - this is most certainly the culprit.

I also foresee more posts about it. We need them to just delete that big log and update.