Ben Chambers wrote:

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

https://wiki.z-hub.io/display/ZP/Installation

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.

B.

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.

/Fred

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.
https://github.com/owncloud/core/issues/23765

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?

Cheers,

B.

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

Ben Chambers wrote:

Hi,

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.

B.

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 8.5.8.2

Ben Chambers wrote:

Marcel,

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

https://www.clearos.com/resources/documentation/clearos/content:en_us:kb_kopano_upgrade_8.5.8

B

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

Tyler Randolph wrote:

Patrick,

Where on the settings page are you getting that error? Which section on that page are you in (general, storage, security, or additional)?

Hi Tyler,

i've made some screenshots for you.
It appears when you login as "admin"

Tyler Randolph wrote:


Glad to hear it! Thanks for being willing to help test it out!

Your welcome. !

I've found the following error in the settings page:



the third error is as follows