Failure after Desktp Edge Client upgrade

Sure thing! How did you install the controller that you're currently running? Upgrading essentially amounts to replacing the controller executable file, and restarting, but exactly how that's done will depend on which operating system and deployment method you're using.

It will look roughly like this:

  1. stop the current controller
  2. back up the database (.db) file
  3. replace the ziti controller binary with the new version, and
  4. restart the controller

The new controller will see that its database needs to be migrated and it will do that automatically. If you're unsure about any of the above then let me know and we'll take it one step at a time.

I used the QuickStart process. Can you send me a link to get the last release?

Thanks,

Eric LEJEUNE | |

| scareything OpenZiti Maintainer
May 9 |

  • | - |

Sure thing! How did you install the controller that you're currently running? Upgrading essentially amounts to replacing the controller executable file, and restarting, but exactly how that's done will depend on which operating system and deployment method you're using.

It will look roughly like this:

  1. stop the current controller
  2. back up the database (.db) file
  3. replace the ziti controller binary with the new version, and
  4. restart the controller

The new controller will see that its database needs to be migrated and it will do that automatically. If you're unsure about any of the above then let me know and we'll take it one step at a time.

Ok, I'll assume you ran the local, non-docker quickstart for the initial install, and also that you're running it on Linux. Based on these assumptions here's the process:

  1. stop the controller

    $ stopController 
    INFO: Controller stopped.
    
  2. back up the database

    $ cp "${ZITI_HOME}/db/ctrl.db" "${ZITI_HOME}/db/ctrl-0.32.2.db"
    
  3. replace the ziti binary

    mv "${ZITI_BIN_DIR-}/ziti" "${ZITI_BIN_DIR-}/ziti-0.32.2"
    
    curl -Lsk -O https://github.com/openziti/ziti/releases/download/v1.0.0/ziti-linux-amd64-1.0.0.tar.gz
    
    tar -xzf ziti-linux-amd64-1.0.0.tar.gz 
    
    mv ziti "${ZITI_BIN_DIR-}/ziti"
    
  4. start the controller

    $ startController
    ziti-controller started as process id: 1286. log located at: /home/scarey/.ziti/quickstart/bullseye/bullseye.log
    

Hi Shawn,

Thanks for the process. I confirm it works now. Here are the logs after update: https://www.eliptec.com/temp/2024-05-10_134410.zip in case it could be interesting.

Do you advise me to deactivate automatic updates? If such compatibility issues with the controller may occur, it's a big problem!

Best regards,

Eric LEJEUNE | |

| scareything OpenZiti Maintainer
May 9 |

  • | - |

Ok, I'll assume you ran the local, non-docker quickstart for the initial install, and also that you're running it on Linux. Based on these assumptions here's the process:

  1. stop the controller

    $ stopController 
    INFO: Controller stopped.
    
    
  2. back up the database

    $ cp "${ZITI_HOME}/db/ctrl.db" "${ZITI_HOME}/db/ctrl-0.32.2.db"
    
    
  3. replace the ziti binary

    mv "${ZITI_BIN_DIR-}/ziti" "${ZITI_BIN_DIR-}/ziti-0.32.2"
    
    curl -Lsk -O [https://github.com/openziti/ziti/releases/download/v1.0.0/ziti-linux-amd64-1.0.0.tar.gz](https://github.com/openziti/ziti/releases/download/v1.0.0/ziti-linux-amd64-1.0.0.tar.gz)
    
    tar -xzf ziti-linux-amd64-1.0.0.tar.gz 
    
    mv ziti "${ZITI_BIN_DIR-}/ziti"
    
    
  4. start the controller

    $ startController
    ziti-controller started as process id: 1286. log located at: /home/scarey/.ziti/quickstart/bullseye/bullseye.log
    
    

You're saying 2.3.1 works properly with an updated controller, correct? That's great news.

Yes it is indeed a big problem which is why that release was marked inactive and a warning was placed on the release notes for it. With the 2.3.1 releasse of the ZDEW, automatic updates were also moved over to use different release streams you can choose from. The readme Release 2.3.1 · openziti/desktop-edge-win · GitHub tries to explain that better.

In general, we always recommend people being on the latest. We keep finding and fixing bugs and adding new features to the tunnelers, it's generally always best to be on the latest.