Profile Details

Toggle Sidebar
Loading cover... Drag cover to reposition
Recent updates
  • Patrick de Brabander

    Update Webapp and Z-push


    For those who are interested you can update Webapp and Z-push with the Kopano repositories.



    Not sure how this will effect the update coming through COS, but don't think it will have any influence.

    I think the main Kopano packages could also be updated, but not yet tried....

    name=Builds of final releases (RHEL_7)

  • I'll look into it and post my findings.

    You can easily install z-push through the z-push repositories, but the ClearOS dependency can be an issue with update.

    I've removed z-push by :

    The followed the instruction accoridng the wiki page and add a repo.


    in /usr/share/z-push/config.php, setting the full email option to false:

  • Ben Chambers wrote:

    The z-push project now builds binaries compatible with ClearOS (CentOS);

    So, there's no need for us to push source through the build system as we've done in the past. We can add binaries to our mirrors quite easily now. If anyone wants to spend some time adding the z-push repo and upgrading and doing some testing, we can certainly make things easier in the future and add binaries to the ClearOS mirrors.


    I'll look into it and post my findings.

  • Ben,

    Are there any plans for an upgrade of z-push ?
    Still working on 2.39, but 2.45 is the latest version currently.

  • Hi everyone,
    If you for instance use Domoticz Home Automation on your ClearOS server, the chance is high that you also have connected one or several USB-dongles for 433MHz communication, Z-wave etc.

    Those USD-dongles that in fact enumerates a traditional serial interface will get an address like

    /dev/ttyACM0 for the first unit and
    /dev/ttyACM1 for the second unit and so on

    Now, by design there will be a race condition at boot time so you can not be 100% sure which physical USB dongle will end up at a specific address. This causes problem in a home automation program such as Domoticz since you need to specify the address for each USB-dongle, and you certainly want your application to continue to work after a server reboot. Similar problem occurs also if you unplug and insert your USB-dongle again. Linux will give it a new address at the insertion if there was an ongoing communication when you unplugged it, why your application will not find it anymore.

    Luckily there is at least one way to bind a USB dongle to a static address (name):
    1. Make sure your USB-dongle is connected to the server
    2. Open a command window and enter:
    3. Note what address the USB-dongle has now (for instance /dev/ttyACM0 )
    4. Find unique identifiers for your USB-dongle (like Manufacturer ID and Product ID) by entering this command (use the address from step 3) The output can look somethings like this:The output above is a "USB tree, starting with the lowest level and works its way inwards to the USB host in the server. You therefore want to focus on the first couple of paragraphs for your USB-dongle so you do not look at the info for the USB-hub...In our case we can see that ATTRS{idVendor}=="0658" and ATTRS{idProduct}=="0200" (which says it is a Z-wave+ UZB USB-dongle from Sigma).
    5. Open/Create a file where we will give this USB-dongle an alias:Enter the following text (using our example):Press Ctrl-o to save and Ctrl-x to exit nano. Note that in this example we used the alias "ttyUSB50", but you could have used "MySigmaUZB" or something. However, I suggest you stick to a "ttyUSBxx" naming convention since that is a "valid" serial port name in Linux so that will save you from some other problems. I also used a "high" number (50) to avoid any potential naming conflict by anything else created in the system.
    6. After reboot of the server our USB-dongle will in addition to its random /dev/ttyACM address now also ALWAYS be found at /dev/ttyUSB50. If you do not want to reboot your server you can enable the new alias by entering the following command: and then unplug/insert your USB-dongle.


  • Hi Ben,

    I've removed the cpomplete directory " /usr/share/owncloud/3rdparty/* "
    It looks like an old directory (2016) form a previous install (??)
    I found the same directory in " /usr/share/owncloud/apps/files_external/3rdparty ", so this must replaced in the new versions.

    still 1 error :

    But found out that is a know error.

    Solution not yet found, but looks like this is an upgrade thing.

  • Ben Chambers wrote:

    The package is from the Kopano repo, but if there's no dependency, should be safe to remove it. Like I mentioned, I do not have that package installed on my Kopano installations, so I'm guessing it's a remnant of something that was once installed, but no longer is. Zarafa perhaps?



    Ok. I've removed the package.
    i'll keep monitoring

  • Ben Chambers wrote:


    Can you remove the offending package without removing a bunch of dependencies?

    My Kopano 8.2.4 instance doesn't have that package installed, so it's not a dependency unless you have some Kopano add on that I don't have.


    Hi Ben,

    As you can see is this package for the kopano-basic repository, so must coming from COS
    The packages can be removed with out dependencies.

    Removing gperftools-libs will not work, since this is not installed

    It looks like the packages has some simularity in version number.(2.5-34.5)

    Before i remove a package, please check where the package are coming from or needed for.
    The are linked in the repositories some how

  • Ben

    I’m running Kopano-basic

    Ben Chambers wrote:


    I can't duplicate the issue in my test environment, but I'm running Kopano 8.5.8...are you? You should be.


  • Nick Howitt wrote:

    That will be one for the devs, I think. Unfortunately I won't be speaking to them until Tuesday. I'll try to ping a message to one.

    Hi Nick,

    any luck with the devs ?

    I've updated an other server and this issue does not appear