So I guess we can mark this solved for now!?

Don’t know if you fixed another issue yet or not but,

During the full registration process while network booting, on svn 4338 cloud 5323,

We had two locations created but only one option showed up for us to choose in the ? listing.

May or may not be relevant, we noticed as of a few revisions ago that imaging things based on location would try to pull the image from the wrong location. Uninstalling the plugin sort of worked, but left behind the Location column in the hosts view which listed them all as a location variable. Trying to re-install it gave similar results as trying to install it on a fresh install. (failed oddly)

I can’t be more specific on what SVN this started with, sorry. We jumped up 2-300 on the Cloud counter last week, and I’ve pulled down SVN more than once in the last few days as commits have been made (i watch the activity log like a hawk). I apologize for my lack of concrete data to report here.

@Tom-Elliott said:

I’ve removed the dirname function from the stuff, if you can update and let me know if things are good?

Yes it’s ok now

Thank you

@Jbob said:

@Claude-Girard v0.9.6 is released, and this includes the snapin fix for the problem you originally posted on. (https://news.fogproject.org/client-v0-9-6/ )

Thank you.
I just tested and for me it’s ok.
You can mark this thread solved, but I will open a new one for the others problems, discussed with Tom, they are’nt solved.
And I found a snapin bug again, but not due to client.

Thanks again

That’s a great line @Wayne-Workman !
Installed without a hitch.

Both time I have installed FOG though, the password given at the end of the install doesn’t work.
Last time I looked up how to change it, after that I could log into the web interface.

Those are nothing more than the source files to what/how our inits work. They’re not installed anywhere and nothing is done with them during installation.

@Tom-Elliott said:

@technokami It uses the Storage Node queuesize as it’s the node side of it.

Ah ok, now it works. Thanks again.

That fixed it.

We have a LOT of login history here. I bumped it to 512

@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.