-
Beiträge
-
-
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.
-
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.
-
Additional information :
Otobo 10.0.9
followed https://doc.otobo.org/manual/installation/stable/en/content/migration-from-otrs-6.html
-
-
-
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/otobo.Console.pl Admin::Config::Update --setting-name SMIME::CertPath --resetif nothing helps, you could also temporarily add
$Self->{'SecureMode'} = 0;to Kernel/Config.pm, 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
-
-
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.
Sven
-
This wasn´t successful :
bin/otobo.Console.pl Admin::Config::Update --setting-name SMIME::CertPath --reset
Resetting setting value...ERROR: OTOBO-otobo.Console.pl-Admin::Config::Update-38 Perl: 5.32.0 OS: linux Time: Thu Mar 18 23:39:32 2021Message: 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/otobo.Console.pl Line: 35Error: Deployment failed!To solve this I pushed these two settings without deploying it :
bin/otobo.Console.pl Admin::Config::Update --setting-name SMIME::CertPath --value '/opt/otobo/var/certs' --no-deploy
Updating setting value...Done.bin/otobo.Console.pl Admin::Config::Update --setting-name SMIME::PrivatePath --value '/opt/otobo/var/certs' --no-deploy
Updating setting value...Done.After that I was able deploy all settings.
-
- Du musst angemeldet sein, um auf dieses Thema antworten zu können.