Posts made by Joe Schmitt

Funny you should request this. I actually implemented this exact thing at my old work place. You could update the host location from the ipxe boot menu, and see their locations when editing the host.

The new clients will need to reboot to cycle their encryption keys, but other than that should shouldn’t be an issue.

Like a said in the PM, your logs are just off. Task Reboot is starting but not continuing. I would need to have remote access to the system to see what is wrong, as the legacy client is … unique. Or you can use the new client (still in beta, but for what you want it will work perfectly).

Check your PM inbox.

You tried scheduling an upload or deploy for this computer WHILE the client was running, correct? (You should also give it several minutes to check back in for the task reboot). And this log, it seems none of the modules are running except SnapinClient, are the others disabled?

Ya, as a general rule of thumb, don’t use Ubuntu. Older versions like 12.04 LTS work fine, but anything “bleeding-edge” for ubuntu means it screws with 90% of the linux standards.

Just to throw in my 2 cents:

We do plan on hashing and skipping existing kernels/inits.
However, in general you do not want to pre-hash files. Why? Because users can update the files themself. A more efficient way of doing it, is to hash the kernels/inits in the dir on install & then check with our server if that hash is up-to-date.

The client install will prompt you:

Install for just me
Install for everyone

Choose everyone. Secondly can you not deploy snapins manually before imaging, and then upload C:\fog.log for me?

I really must ask. Why did you try using snapins to reboot machines for tasks? The client will automatically reboot the machine if an imaging task is waiting. It can even be made to force the reboot even if a user is logged in.

If it wasn’t rebooting for you, PM me and I’ll try and get it sorted out for you.

We’re actually hoping to move away from sourceforge for hosting the kernels & inits, and host it our self. But I do agree that we should hash check them.

Use git.
[url]https://github.com/FOGProject/fogproject[/url]

I disagree. [Almost] anything can be done as system if you are creative enough. Fonts should be pretty simple with some registry-know-how. E.G. this should do it (in theory)

[CODE]@ECHO OFF
XCOPY <Source>.<ext> %systemroot%\fonts
REG ADD “HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Fonts” /v “<Fontname> (<Type>)” /t REG_SZ /d “<Filename>.<ext>” /f[/CODE]

Though I must ask, why can you not just install all of your fonts on the image itself?

As for your runas request that won’t help. SYSTEM is [B]STRICTLY[/B] prohibited from interacting with users accounts [B]IN ANY MANNER[/B]. The clients (legacy & new) use some named pipe hacks to bypass this restriction and form an IPC median (Inter-process-communication). Runas would not give the program a visible gui for the user.

One possible solution (though this would require user interaction) is to make a little [URL=‘https://www.autoitscript.com/site/autoit/’]AutoIt [/URL]script (compiled as an exe), which your users run. It gives them a gui & they can click on what device they want and it installs it.

Another possibility is to make a snapin that uses window’s task scheduler to try installing the driver as a specific user when they log in. <-- I would check out this idea

With that said, there IS a way of running tasks as users and still giving them a gui. The new client has the capability of doing that. However, it is not programmed to do user-level snapins yet. It was on our “Maybe let’s implement this later list”. Depending on the severity of your needs, I [B]could[/B] start working on it now.

ALL HAIL JUNKHACKER

Glad to see it worked. I re-wrote most of the files in v0.7.3 and ended up breaking everything…

What OS is the client running on? (I know its 32 bit)

We switched to using open-project after I did the majority of the new client. So there are not work packages for everything. But be assured, GreenFOG does exist, and the log files are still at c:\fog.log

What gives that error? The client? Which client (legacy or beta)? What version of the client? What version of FOG (Latest is relative)? If its the new client can you upload the log files?

Ah, glorious PEM errors. Since you deleted the public keys, the client is trying to use a blank public key. You’re going need have FOG re-generate its public keys. The reason Tom had you delete them is that the client was retrieving a public key that didn’t match your private key.

Or, you can use clonezilla to make a local ‘image’ of your FOG server depending on how big it is. It really all depends how you want to back up your FOG server, but you should [B]never[/B] upgrade your production server without some way of reverting it.

No. The new beta client will only work with the development version. Much has changed ‘underneath’ FOG.