Posts made by Joe Schmitt

The notification GUI your are referring to was not ready for the initial public beta. See [url]http://portal.fogproject.org/work_packages/24[/url] for the workpackage.

The shutdown will occur even when a user is logged in if you set the “force” setting on your FOG server. (I’m not sure where it is off the top of my head)

[B]Please[/B] post bug reports in a new thread. If you post them in threads about something else there’s a high chance I’ll overlook them.

Work package created for log files:
[url]http://portal.fogproject.org/work_packages/29[/url]

Bill,
That option is pretty simple to build, but it would be something Tom would build if we add it, as I’m pretty busy with prepping the new client for a public beta.

Wayne, the way FOG handles renaming is that it first unjoins the domain, renames the computer, and then joins. It should prevent the AD issue you describe.

You could use NSIS to make the installer
[url]http://nsis.sourceforge.net/Main_Page[/url]

For the most part, I never used Install rite. Most installers have silent or passive modes. Those that don’t you can usually find an ‘enterprise’ version of it online which has those switched.

If you can’t use svn, you can get a zip file of our current work from github

Via web:
[url]https://github.com/FOGProject/fogproject[/url] and click Download Zip

Via cli:
[CODE]wget https://github.com/FOGProject/fogproject/archive/dev-branch.zip[/CODE]

The idea of the hostname changer is to make the client reflect the server, preventing techs from tampering with host names when they shouldn’t be. What you suggest is plausible, but I would need to see a larger ‘backing’ of this feature before implementing it. Now that’s not to say you can’t. A beta of the new client is coming out soon and it would be more than possible for someone to implement this concept if they wanted it.

There’s also a security concern. With the client in current circulation, anyone could ‘pretend’ to be the host and change the hostname to whatever they want with 0 privileges. The next problem is that how do you distinguish between a tech changing the hostname locally and changing it on the server? From the client’s perspective if someone changes it on the server, then with the suggested model in this thread, the change would be undone by the client, as it would think that a tech changed the hostname locally.

I can sympathize with people having this issue, but in my personal opinion new techs simply need to learn the system their company uses, if thats FOG, then learn to change the hostname on the FOG web portal.

Correct, the old system didn’t always check null vaues.
The server will need to be upgraded to handle the new client. After that though, the clients can perform in-place upgrades.

The data array contains all of the info returned by the server. The version included in v1.2.0 is broken, as you have discovered. Please note that this client is old and is about to be replaced by a new one. (A beta of the new version can be expected in the coming week(s) )

I’m just going to throw my 2 cents in here. I think what you guys are doing is fantastic. It may be best to outline what debugging information is vital for us, and build the scripts off that. What you’ve posted is great, but I’d like to see a ‘standard’ for the scripts, a list of what information and in what format. That way you/we can build scripts for all platforms that output the same information in the same format.

If these scripts gain some ground, we could even include them in the repository.

Could you upload the log file that Wayne was talking about? Usually we can tell what is wrong just by looking at that.

That page was intended for getting a FOG server to run on Mac OS, is this still the goal, or rather cloning a Mac computer?

Exactly like that

Node service is my “baby”, along with the new client. In essence it runs on the server as a “router” for the client. To stick with the networking analogy, the FOG server is the modem, and the clients are the in LAN hosts.

The new client is purely event-driven, both by local system events and server events. In order to achieve this we must maintain an constant concurrent connection between all hosts and the server.

The default nature of PHP prevents it from being efficient at maintaining thousands of concurrent connections, not to mention it would flood port 80. The node service is the middle man in-between the FOG server and the client. As it runs on NodeJS, it can maintain millions of concurrent socketIO connections with little ram and cpu usage, due to the non-blocking asynchronous nature of NodeJS.

That’s just a basic synopsis of the node-service. Theres’ a lot more going on underneath, and more reasons why we have it.

(Little preview: we also need this style of connection for a future feature. Remote CMD for a client from the FOG web portal. But no promises. We are capable of doing this because of our security-system that Tom & I designed, which is capable of forming a secure connection across unsecured medians, and is immune to session hijacking.)

Correct, Chuck maintains the server we use to host the forums, our project management software, and so on.

What are the error messages? An exact error message, or even better a copy of the install log ( Should be located in [SIZE=12px][FONT=Consolas][COLOR=#333333]/var/log/foginstall.log[/COLOR][/FONT][/SIZE] ), would help us out tremendously.

Please use this patched dll instead

[url]https://dl.dropboxusercontent.com/u/18664328/HostNameChanger.dll[/url]

It allows for either a product key or no product key

Cysperski, or Chuck Syperski is the project founder.

The legacy service was removed in recent versions. Use this link instead:
[url]https://github.com/FOGProject/fogproject/blob/b17cbe8fa277ef32f4ec04d80c1526ab9de9586c/FOGService/src/FOG_HostNameChanger/MOD_HostNameChanger.cs[/url]