Topic Resolution: Resolved
Viewing 6 reply threads
  • Author
    • #11050

      Everything was migrated successfully, I logged in with old admin user and facing loop problem.

      Secure Mode Needs to be Enabled!

      Secure mode will (normally) be set after the initial installation is completed.

      If secure mode is not activated, activate it via SysConfig because your application is already running.


    • #11051

      Arrgh, I lost half of the post …

      There is problem with SMIME::CertPath, which is on host file system /etc/ssl/otrs/certs , I looked on vanilla Otobo installation and this settings is disabled.

      During migration of OTRS settings is this migrated and enabled.





      • This reply was modified 10 months, 1 week ago by hilocz.
    • #11078

      Should I open an Issue on Github ?

    • #11083
      Sven Oesterling

      Hi hilocz,

      firstly, I assume that the SecureMode problem arises from the SMIME::CertPath setting which likely is invalid on the new server. In general if settings are invalid one has to fiddle around by hand a bit. I don’t know if there is „the“ best way to handle this, in your case I would probably use

      bin/ Admin::Config::Update --setting-name SMIME::CertPath --reset

      if nothing helps, you could also temporarily add

      $Self->{'SecureMode'} = 0;

      to Kernel/, to be able to use the SysConfig in the WebInterface if you prefer that to the console.


      Regarding SMIME::CertPath – I shortly discussed this with the others. In principle for settings like this, we have the choice of trying to migrate it, or reset it to the OTOBO default. For SMIME certificates it is quite clear, that you will want to use them from OTOBO, too, so I would rather not just deactivate this setting. As we cannot create arbitrary directories in the file system, however (e.g. „/etc/ssl/otrs/certs“) this in my opinion has to be prepared prior to the migration. We will include it in the migration manual.


      Could you resolve the problem by now?

      Best regards, Sven

    • #11087

      Hi Sven,

      because I lost half of one post during editing, there is one important information missing. I have Docker install, do I need to map that folder to be „visible“ inside of the containers ?




    • #11095
      Sven Oesterling

      Hi David,

      just quickly to not let it unanswered: For Docker there is the possibility to mount directories into the Docker environment somehow. But I’m no expert there, it’s definitely something we have to think about, I guess. Stefan earlier suggested to store those variables in /opt/otobo/var/certs or similar, but that doesn’t help you with the migration, now, of course. (For the moment I would reset the setting as described above, and then reconfigure it.) If he finds time, Stefan will probably write a suggestion, too.


    • #11111

      This wasn´t successful :

      bin/ Admin::Config::Update --setting-name SMIME::CertPath --reset
      Resetting setting value...

      ERROR: Perl: 5.32.0 OS: linux Time: Thu Mar 18 23:39:32 2021

      Message: Setting SMIME::PrivatePath Effective value is not correct: /etc/ssl/otrs/private not exists!

      Traceback (35):
      Module: Kernel::System::SysConfig::ConfigurationDeploy Line: 3511
      Module: Kernel::System::Console::Command::Admin::Config::Update::Run Line: 241
      Module: (eval) Line: 468
      Module: Kernel::System::Console::BaseCommand::Execute Line: 462
      Module: Kernel::System::Console::InterfaceConsole::Run Line: 88
      Module: bin/ Line: 35

      Error: Deployment failed!

      To solve this I pushed these two settings without deploying it :

      bin/ Admin::Config::Update --setting-name SMIME::CertPath --value '/opt/otobo/var/certs' --no-deploy
      Updating setting value...


      bin/ Admin::Config::Update --setting-name SMIME::PrivatePath --value '/opt/otobo/var/certs' --no-deploy
      Updating setting value...


      After that I was able deploy all settings.

      • This reply was modified 10 months ago by hilocz.
Viewing 6 reply threads
  • You must be logged in to reply to this topic.