@tian Thank you for reporting back! Posts like these make all the difference to future readers!

Great that you worked it out. I think this is pretty normal and actually expected behavior. If you configure wget to use a proxy server it will do so whatever URL you are trying to request!! To exclude some URL (like local ones) is a pretty common configuration. That’s fine!

@technokami Great to hear that you got it working again! Thanks for reporting back and for letting us know about this issue.

@Wayne-Workman no fog. I saw the issue and fixed it already.

@cml said:

All should be fixed accurately now.

@Tom-Elliott said:

@Scott-B You will have to update the information so the values get properly updated.

I’m adding proper code to check for these things now and what you’re seeing is the old double addslashes methodology.

I assure you it will work. There will be some work on your part, but once it’s done I assure you it will work.

Thanks for your help. Any idea why when the printers are assigned to a host they end up reverting back to the extra \\\ ?

@Tom-Elliott Biggest Necro-Post ever.

Looks to be solved, thanks Tom!

@Wayne-Workman, @sudburr you both realize you can use relative paths in the location parameter? This removes the hardcoding and is safer than trying get a good Apache configuration using a series of sed statements.

I have added better backup code that now stores a backup of the database. With that it seems there was a problem with Debian based systems in some cases where the link between /var/www/fog/ and /var/www/html/fog.

I’m fairly sure I’ve traced that down as well but I don’t feel it’s a significant enough issue to keep this open.

@Tom-Elliott I’ll solve it. I wanted to report so that there was some sort of record of this in the forums, because it’s possible that someone in the future could run into this.

I’ve fixed this in the code so fresh installs should no longer have this issue. That said this would not have caused any issues.

I’m solving this thread as the issue should be fixed. I imagine there may be issues in the future but only from a reporting standpoint. I have moved all of the states to use the task state class elements. Older data used to close tasks with a state is of 2. Task state is 2 is in-line so some of the reports may say this.

As far as I understand it, the printer management issues describes have been addressed. The problem being described is a bit vague but it seems there may be a configuration issue of one of the printers.

I’ve solved the thread for now but please feel free to post/unsolved with any more details.

I’m solving this thread for now. I would love to ensure there isn’t a problem with just the legacy client so if we can get more details I can probably squish this real quick.

I’m solving this as I have remoted in with @johnomaz and we verified things were finally working as expected. There was some issues but it was purely a configuration thing, not a fog bug issue. And I will state it’s a rarity that it isn’t something I caused.

At any rate I just hope it’s working properly for everybody now.

Service settings are now functioning again. Thanks for reporting.

@Tom-Elliott said:

I saw a portion of the problem and I believe this is now fully fixed too. While memory issues are not something I can fix for you, I did make the methods called a bit more efficient.

Tom is a bug murdering ace lately…

GUEST_6457171134_1266362531.gif

Yes they can be ignored. I am more interested in figuring out why they did not exist but that’s all that schema did.

@Tom-Elliott Thanks - git5135 fixed the snapin log:

“active snapins” are added/removed correctly -> OK snapins are running ok on the client -> OK the snapin log displays the database content correctly again (it added the new snapin tasks additionally to the ones from yesterday)** -> OK** the snapin status still is reported as “4” in snapinJobs and snapinTasks -> OK? no “sjHostID 0” entries in snapinJobs are created from hosts only started up/running -> OK