New Client Progress


  • Senior Developer

    As I’m sure many of you have heard by now a new client is in development. This isn’t an update to the old client; this is a complete re-write from ground up. The code is far enough that I feel comfortable posting the progress of it, and answering any questions you may have, and taking feature requests.
    Status
    Please see http://portal.fogproject.org/projects/fog-client/roadmap for an always up-to-date status report.

    Some common questions

    • Why the rewrite?

      • It’s sorely needed. The legacy client is extremely difficult to recompile, and as such no updates have been done since its official release.
      • The ability to make custom modules is insanely hard. It is not moduler, and as such much of the same code is repeated multiple times.
      • Cross-platform support. The legacy client relied on windows-only security methods to handle the security of active directory passwords. The new one uses cross-platform alternatives that are more secure.
      • It allows us to easily make new modules. A single module can be as short as 35 lines of code instead of several hundred.
      • Windows 8 compatibility. Many of the modules have been broken since the introduction of Windows 7/8.
    • What are some of the new features (subject to change)?

      • Increased security
      • 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.
      • In-place upgrades. If you upload an update file to FOG the clients will download and apply it without needing a reboot.
      • 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.
      • Cross platform support. We are actually waiting on Microsoft for this one. The .NET framework has gone open source (MIT license), and is being ported to OSX and Linux by Microsoft. This will allow us to use the same core libraries across all platforms.
      • Logs. I consider this a new feature because of how radically they have changed. The fog.log is more organized, split up, and contains more useful debugging information.
      • Notifications! This one is small yet huge. Our goal is to make this service as professional as possible. We support users providing their own logos, banners, and company names to modify the tray & notifications as needed.

  • Senior Developer

    @Wayne-Workman , I do not believe so. I think there is no way of making the client unjoin AD. Unless you were to rename the host and then uncheck that box before it reboots.


  • Moderator

    @Jbob said:

    1. I hate that checkbox’s naming. If the checkbox is unchecked, the client won’t manage AD.

    So - the checkbox tells the client to manage the AD stuff or not… so… if the checkbox were checked but the domain field were left blank, the new client would un-join the computer from the domain?


  • Senior Developer

    @Wayne-Workman

    1. The client activates windows using the product key given during registration
    2. The client auto registers machines
    3. I hate that checkbox’s naming. If the checkbox is unchecked, the client won’t manage AD.

  • Moderator

    @Jbob Does the new client supposed to un-join a machine from the domain when the “Join Domain” checkbox is unchecked? Because it did not during testing.


  • Moderator

    @Jbob Does the new client auto-register a machine that is not registered?


  • Moderator

    @Jbob Does the new client activate windows using the product key supplied during full-registration?


  • Moderator

    Biting at the bit here in Missouri…

    Screenshot from 2015-10-22 18:36:04.png


  • Testers

    That could work, but in a setup such as I have it wouldn’t be the most ideal. I have a separate vlan for imaging, that is only in the tech office not out in the rest of the building. I use FOG to push snapins and track user logins though. So it would be nice to have it be able to do the inventory in the client. I was thinking that WMI queries could do the job. I know this is something that is small, even in my scheme of things. Because I would rather @Jbob continue to focus on refining the client as is. He is doing a great job and it works very well. I love the new advances and the fact that it registers hosts in the first place is great, I have been hoping to get that feature back for a long time. So maybe a thought for 2.0 trail. I guess this should probably be added as a feature request.


  • Testers

    Since inventory collection is handled via pxe boot maybe just a fog option to default to the inventory task when the data is not present for an existing record.


  • Testers

    is it on the road map to add in inventory collection to the client registration? So that if the host gets registered through the client it will do a full inventory of the machine so that we wouldn’t need to do an inventory task on the machine?


  • Senior Developer

    @Uncle-Frank The *nix client is not released yet.


  • Developer

    I am really looking forward to have the new client running on Linux too. Yesterday a had a look at the scripts in https://github.com/FOGProject/fog-client/tree/dev/NixInstaller but couldn’t actually get to make it work as FOGservice.zip on my fog server (trunk 4722) only has the MSI installer in it.
    Has anyone got the new client up on Linux and could step me through the installation? I am possibly just missing one little thing (how to extract the client binaries from the MSI?).


  • Moderator

    @Jbob said:

    v0.9.5 is released!

    See https://news.fogproject.org/fog-client-v0-9-5/ for more details

    Hi, I’m trying the debugger, the help page is bugged.

    We have that :

    configue server ____ <-- Sets the server address
    configue mac ____ <-- Sets the mac address
    configue default <-- Sets the default testing mac and server address
    

    instead that :

    configuRe server ____ <-- Sets the server address (ADDRESS/WEBROOT)
    configuRe mac ____ <-- Sets the mac address
    configuRe default <-- Sets the default testing mac and server address
    

  • Senior Developer

    I was in contact with Brian David and this is a server issue. A fix has been pushed.



  • @Jbob

    Just updated to the new client, and I’m loving it. I’ve only had one big issue so far: I cannot got the auto log out module to work. I have it enabled globally on my FOG server, as well as locally for the client, but nothing is happening. When I check the logs on the client, it seems like the client isn’t even bothering to check the auto log out module. I’m not sure where to start in troubleshooting this, and I’ve searched through the forums to no avail, so any help would be appreciated.

    Thanks!


  • Senior Developer

    v0.9.5 is released!

    See https://news.fogproject.org/fog-client-v0-9-5/ for more details


  • Senior Developer

    @Matthieu-Jacquart There is little use of doing a repair as that is technically a “smart installation”, which will not repin the client. As for your request, v0.10.0 (still in progress) fixes this.



  • @JBob : When I re-install the client on a computer, and I choose to repair installation, it removes IP of the server and replace it with “fog-server”. Of course after client, client can’t find fog server.
    Only solution is to remove client and reinstall it properly with modifying IP of the server.
    Is it possible that the client “remember” IP entered on the first installation ?

    Thanks


  • Senior Developer

    Looks good to me.


Log in to reply
 

442
Online

38955
Users

10706
Topics

101580
Posts

Looks like your connection to FOG Project was lost, please wait while we try to reconnect.