Remove the Legacy Client - and Legacy Client functionality - from FOG Trunk.


  • Moderator

    Please and thanks.


  • Moderator

    Then let’s get rid of the FogCrypt download link also.


  • Senior Developer

    @Wayne-Workman The most I am comfortable doing is removing the legacy client download link and make it very clear that we highly recommenced upgrading to the new one.


  • Moderator

    @Jbob With the old client not working on Windows 10, and probably not working on future Windows releases, they won’t have such a choice.

    Besides that, really, my main concern is how the legacy style AD joining password is handled. Who here has actually recompiled the encryption module so that their legacy password is safely stored? I know I haven’t. It’s not something you just “know” to do. And while it’s not good practice to use your AD administrator credentials, people do. I have before.

    At the very least, let’s disallow “administrator” to be used as a username for the AD Joining credentials for both legacy and new? A warning can be displayed saying the administrator user is not allowed, and to use another account and give that account domain-joining permissions only. This will mitigate most of the potential disaster.


  • Senior Developer

    @Wayne-Workman the 10 polls per minute come from the client’s 1-minute polling cycle. It does about 10 GET requests per cycle. Its far from efficient, and our fog-too client does away with that altogether. The new client for 1.3.0 was modeled against the legacy client for best compatibility with the existing back end.

    Even then, the main point isn’t the complications of auto upgrading, but rather the fact that we will not force a user’s entire system to automatically upgrade. It should ultimately be their choice if they wish to upgrade to the new version.


  • Moderator

    @Jbob said:

    The increased network stress alone for an un-configured service

    What do you mean by un-configured? And 10 polls per minute is absolutely not necessary, no offense intended. Something like 1 poll per 5 minutes would be better.


  • Senior Developer

    @Wayne-Workman, while I can see where you are coming from I would be highly opposed to what you suggest. As the lead developer of the new client, I more than maybe anyone else, would want to see people using the new client. However, imagine this scenario:

    A company has 2k hosts. Let’s assume each one has the legacy client installed. The legacy client polls at around 6 times every 10 minutes, for a total of 36 polls every hour. A singlenew client will poll approximately 10 times every minute, for a sum of 600 polls per hour. Now multiply that by the 2k hosts and you’re server is recieving around 1,200,000 requests per hour. In addition to the increased polls, the overhead (cost) of sending a message to the new client is significantly higher. Each transmission undergoes AES 256 encryption. The increased network stress alone for an un-configured service would have the effect of a DDOS attack on the server.

    This rough aproximation does not even take into account the cost of having 2k clients perform their initial server pinning and handshake, which would make the server perform over 2,000 rounds of RSA 4096 encryption in a matter of minutes, followed by several rounds of AES 256 per host. In addition, each host communication would require 2 databases fields to be updated on first handshake. This means the upgrade will effectively create over 4000 database write requests in a short period of time.

    With that said, even if we were to ignore the operational overhead caused by such a system-wide upgrade, I am strongly opposed to forcing the clients to update. Many people have a working 1.2.0 setup and are used to the legacy client. When they upgrade the server, it should be, and is, their responsibility to slowly migrate their system over to the new client. Now I am doing my best to make an easy upgrade path to the new client, but for such system-wide change, it should be up to them to do.


  • Moderator

    Then we need to figure out a way for any old client that reports in - to just be told to execute such-n-such to install the new client automatically. This is really important.


  • Senior Developer

    Removing the client installer sure, removing functionality no. Too many people are using the legacy client. Removing from dev means removing from the next release. I am not of the mind to tell everybody that they have to recreate their images because of the client. While I do recommend such things, I’m thinking it’s not a good idea to do enforce such extreme things.


Log in to reply
 

372
Online

39.3k
Users

11.0k
Topics

104.6k
Posts

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