OTRS 5 phone home (and how to disable it, and more)

[denydias]

Things are getting worst and worst at OTRS front.

Since xxx have started its move towards a closed ecosystem, version upon version they are becoming more avid for the metadata of their user base. Now, with OTRS 5 and its new 'Daemon', there are routines crafted for this metadata harvesting that an admin can't disable anymore via the web UI.

These settings are in Admin > SysConfig > Daemon > Daemon::SchedulerCronTaskManager. They are:

Code: Select all

Daemon::SchedulerCronTaskManager::Task###RegistrationUpdateSend
Daemon::SchedulerCronTaskManager::Task###SupportDataCollectAsynchronous
Daemon::SchedulerCronTaskManager::Task###OTRSBusinessEntitlementCheck
Daemon::SchedulerCronTaskManager::Task###OTRSBusinessAvailabilityCheck

Note that these tasks comes in grey with a little locker beside them. You can't change their settings nor turn them off like the other daemon tasks.

To disable them, open Kernel/Config/Files/ZZZAuto.pm and add the lines bellow to the end:

Code: Select all

delete $Self->{'Daemon::SchedulerCronTaskManager::Task'}->{'RegistrationUpdateSend'};
delete $Self->{'Daemon::SchedulerCronTaskManager::Task'}->{'SupportDataCollectAsynchronous'};
delete $Self->{'Daemon::SchedulerCronTaskManager::Task'}->{'OTRSBusinessEntitlementCheck'};
delete $Self->{'Daemon::SchedulerCronTaskManager::Task'}->{'OTRSBusinessAvailabilityCheck'};

Save and your OTRS 5 is going to stop phoning home and spying your metadata. This is the only way I've found to disable it.

I'm most than sure that even this method is not going to work for a long time. xxx may well just remove a configuration option for that at all. Of course, you can remove the underlying routines if you know where to lock and how to code, but they are going to come back upon every upgrade. The average, not code savvy user will have no idea that this is even happening. I predict a much worst situation in the upcoming OTRS 6.

My advice to all of you: it's the time to design a plan to move away from xxx at all.

Mine is 'en route'. xxx doesn't deserve my commitment or respect anymore as a user and/or developer. I'm going to fulfill their wish and let them live only with the paying customers of their BusinessSolution. That's what you wanted xxx, isn't it?

[eandrex]

Code: Select all

My advice to all of you: it's the time to design a plan to move away from OTRS at all.

Someone already started it viewtopic.php?f=64&t=30980

Edit: nvm, I didnt see you already replied there.

[denydias]

Someone already started it viewtopic.php?f=64&t=30980

Edit: nvm, I didnt see you already replied there.

Yeah! I stand corrected in the OP. To make my advice more clear, I mean to move away from xxx, not from OTRS itself. See what MariaDB folks are doing to MySQL... that's the kind of move I'm talking about.

One thing that I don't know (and wish to know) is that: being the OTRS code AGPLv3 licensed, is that ok for a third partner to fork and redistribute it under a new brand?

[jnelson]

This is a very bad thing. I tried this (like an idiot didn't backup my config first) and now I cannot update the sysconfig at all.

[reneeb]

You have to set the correct file permissions. The webserver user needs the permission to write the ZZZAuto file...

[jnelson]

It needs to be apache/apache and not otrs/apache?

[reneeb]

If otrs is the user for that OTRS is installed otrs/apache seems to be correct. But check if the apache user has write permissions...