Posts made by Joe Schmitt

That would mean I gave you the unpatched version. I’ll pm you new ones when I get a chance.

I’m going to go out on a limb here and say the current SVN version fixes more bugs than it creates. However, I understand being reluctant. The fix you need itself is actually pretty simple to perform. Basically you’re going to want to extract & mount init.gz, and perform the change I proposed here: [url]http://fogproject.org/forum/threads/host-registration-broken.11270/[/url] . I forgot the exact commands you use to extract it, sorry.

As for the dll’s I’ll double check the ones I compiled, who knows maybe I screwed up and compiled the unpatched version.

That full host registration issues sounds familiar. I believe it this issue I reported a while back: [url]http://fogproject.org/forum/threads/host-registration-broken.11270/[/url]

Updating to the latest svn version would fix the issues if you don’t feel like manually implementing it yourself. The error
“[FONT=Consolas]Failed: Incomplete server response; got: 7; wanted: 6.” [/FONT]Suggests that the dll was never replaced with one that I compiled.

Sorry for not being clear, the way I suggested is automatic. You just need to update your image so the service “FOG-SERVICE” does not start automatically. Then edit your script where you install Kaspersky so it looks like:

[CODE]
#Install Kaspersky Code
sc config “FOG Service” start= delayed-auto
net start “FOG Service”
[/CODE]
(The space between = and delayed-auto is required)

Alright, well the way the old client is structured not much can be done. However, one possible solution is to disable the fog-service auto-start on the image. Then in your script where you install Kaspersky enable the auto-start of “FOG Service” after installation, and manually start it.

Is Kaspersky deployed via snapins?

You’re going to want to PM me. Trust me. I’ve dealt with compiling the old client and it is not pretty. It will take a bit of work to compile it on linux because of some dependency issues. The dll is a one-size-fits-all. It doesn’t matter if the host has a product key or not. I already have the infastructure and scripts required to build you a copy in a matter of seconds. What I need from you (in PM form) is an email address and what pass phrase you want (or if the default one will work).

Just a quick alteration to what Tom said. The link he posted as actually the initial proposal I made for adding such a feature and there are some issues with it. See this post: [url]http://fogproject.org/forum/threads/troubles-with-recompiling-the-hostname-module.11398/#post-36214[/url] for what you should actually do. The source file linked needs to be downloaded and compiled. If you have any issues at all with compiling the patched HostnameChanger, PM me with the details and I can build you a copy of it.

The legacy client should still work as before. Don’t count on the current in-development client to work though (it can only be obtained through the fogservice-rewrite branch on github)

You are correct, the client currently being distributed is set to start once a core windows service does. However, this is actually too soon on faster systems as not all programs are fully initialized yet. The delayed start is an acceptable solution, or you could link the service to start when a different windows services does. This issue should be resolved with the new client when it is released

Nope, but it is pretty close. Right now I’m implementing the new encryption system. Once that is done a usable beta should be ready, but a lot of polishing needs to be done before a final release (the small things that make the client more professional and easier to use).

The service compiles in mono already, that’s actually how we are letting users build the installer from the web ui. As for the linux version I’d advise against making anything relating to the client. We have new api for the client, and are working on reworking how the client and service communicate altogether. Anything that is made is more than likely going to break immediately due to the number of changes being made.

Here’s a quick overview of what’s going on / features added (it may give some insight as to why the rewrite is taking awhile).

Please note that everything below is subject to change.

1.) The SVN repository does not contain the new client. The client is developed on a separate branch on our git repository and will be merged with svn when it is ready for beta testing.

2.) While the program is still done in c# for Windows, it is done in a much more light weight, and open source IDE, Sharp Develop. With that said, I have been working on something special recently: the ability to compile a new installer for the client straight from the web portal. (You update the source files, go to the web portal and hit “Compile & Update” which gives you new binaries).

3.) The API is fairly documented as I have re-written everything to be completely modular. Writing custom modules is a cinch. For example, our AutoLogOut module is 67 lines long and our Directory Cleaner module is 39 lines long.

4.) Security has gone through the roof. Currently we have AES 256 encryption options for all traffic but are planning on adding asymmetrical encryption for both the client & server. We would perform client authentication to ensure nothing has been tampered with and if we detect anything the client is blacklisted until it is re authenticated.

5.) There is another experimental feature in the works: event-driven modules. Rather then checking in every X seconds for new tasks an encrypted concurrent connection is formed between the server and client, allowing the server to notify the client of a task immediately. This would allow for instant snapin deployment, cloning, e.t.c. Essentially it makes the client use less cpu on the computer and become more responsive.

6.) One of my favorites. In-place upgrades. If you upload an update file to FOG the clients will download and apply it without needing a reboot.

7.) User-level tasks. We actually run 2 services now. A system-level one for things like installing software and a user-level one for tasks that are user-specific.

Theses changes require a bit of work on both the server and client side. Once everything is finished for windows, porting over to different platforms should be fairly straight forward.

Gilou is correct.

The windows client is currently being rewritten from scratch. The majority of the modules are done but development has slowed due to the limited free time I have. We do plan on making a fully featured client for osx & linux though but we have no estimates when that would be.

The new FOG Service will not have built-in functionality to replace the old one due to the complexity. However, I should be able to create a snapin to do the upgrade processes for you. So all that would need to be done is deploy the Service-Upgrade snapin to all of your hosts.

Sure, the easiest way would be to just download the file from here:
[url]https://svn.code.sf.net/p/freeghost/code/trunk/FOGService/src/FOG_HostNameChanger/MOD_HostNameChanger.cs[/url]

(Either Right Click -> Save As, or use wget/curl)

Just replace that downloaded file with your local copy and recompile just the HostnameChanger module

This problem has come up multiple times on the forums. The issue isn’t the multiple macs but rather a compatibility issue with the client/server.

See the following thread for the explanation as to what is happening (the answer is my last post on the thread):
[URL=‘http://fogproject.org/forum/threads/troubles-with-recompiling-the-hostname-module.11398/#post-35093’]http://fogproject.org/forum/threads/troubles-with-recompiling-the-hostname-module.11398/#post-36214[/URL]

The URL linked in that thread is no longer active. You can get the patched HostnameChanger from the svn repository. Please note that you will need to compile the patched source code. If you need me to compile it please let me know.

This is often caused when
A.) You entered a product key for the host without compiling the new patched HostnameChanger.dll
B.) You compiled the un-patched new HostnameChanger.dll without giving the computer a product key.

The HostnameChanger source files in the svn repository will compile a version that fixes this issue as well.

Did you try disabling the snapin module?

2cool4me4 is correct; this is the design of the service and won’t cause any issues. The new service that is in development will most likely check if the computer is already joined to the domain first before attempting.