This has now been fixed in the Kolab 16 repository. I have dropped the requirement for the elastic skin packages for the plugins libcalendaring and zipdownload, because they don't exist.
Posts made by timotheus
RE: Problem with update roundcubemail from Kolab_16 (09. Nov. 2018)
RE: CentOS7 on KVM new install - warning: /var/cache/yum/x86_64/7/Kolab_16/packages/pytz-2015.7-2.8.el7.kolab_16.noarch.rpm: Header V3 RSA/SHA1 Signature, key ID 446d5a45: NOKEY
That package is somehow still signed with the key email@example.com, and you can install it like this:
rpm --import "https://keyserver.ubuntu.com/pks/lookup?op=get&search=0x830C2BCF446D5A45"
I hope this helps,
RE: occupation of all users' mailboxes
you can run this command on the command line:
If you want a list of user accounts with quota information in the Kolab Webadmin, you could have a look at this patch:
You probably need to remove the references to tbitskolablastlogin and other tbits values, because those are not part of the default ldap schema.
RE: Cannot acces "Files" from WAN
You can try to modify (or add if it does not exist) this line in
$config['kolab_files_server_url'] = ...;
I have set it to
'http://localhost/chwala/'. That way Roundcube should communicate directly with Chwala on the localhost, not going through the network and getting confused.
RE: Kolab-Setup configuration file and supplying passwords from a scripted environment
I am looking forward to your docker files.
I never figured out how to use the --config parameter.
I added some parameters that make it possible to run the kolab setup without user interaction though.
I did some docker image a while ago, but it seems that was for Kolab 3.4:
see https://www.pokorra.de/2015/06/building-a-docker-container-for-kolab-3-4-on-jiffybox/ how I built it.
More recently (still a year ago) I did a script for deploying Kolab 16 on dply: https://www.pokorra.de/2016/12/installing-kolab-16-for-testing-on-dply-for-free-for-2-hours/
It comes down to this script: https://github.com/TBits/KolabScripts/blob/KolabWinterfell/dply/reinstallKolab.sh
and basically this call: setup-kolab --default --mysqlserver=new --timezone=Europe/Berlin --directory-manager-pwd=$pwd
I know I tried to create a docker image for Kolab 16 in 2016, but I cannot remember the issues I had. It was about privileges etc I think.
I hope you can get a docker image working again.
RE: Directory server 389 stuck
We have recently had similar issues.
To check your current values:
for i in $(pgrep ns-slapd); do echo -ne "pid: $i "; grep 'Max open files' /proc/$i/limits; done
As far as I understand, nsslapd-maxdescriptors will set the soft limit, and the configuration in /etc/sysconfig/dirsrv.systemd will set the hard limit.
Here is my Ansible script for CentOS7 that I use, and dirsrv has behaved since then:
- name: set LimitNOFILE lineinfile: path: /etc/sysconfig/dirsrv.systemd regexp: '^LimitNOFILE=.*' line: 'LimitNOFILE=10240' - name: restart dirsrv systemd: name: dirsrv.target daemon_reload: yes state: restarted - name: set nsslapd-idletimeout shell: | cd /root echo "dn: cn=config" > idletimeout.ldif echo "changeType: modify" >> idletimeout.ldif echo "replace: nsslapd-idletimeout" >> idletimeout.ldif echo "nsslapd-idletimeout: 300" >> idletimeout.ldif pwd=`cat /etc/kolab/kolab.conf | grep "^bind_pw" | cut -d " " -f 3` ldapmodify -x -h localhost -D "cn=Directory Manager" -w "$pwd" -f idletimeout.ldif rm idletimeout.ldif - name: set nsslapd-maxdescriptors shell: | systemctl stop dirsrv.target sleep 3 path=$(find /etc/dirsrv -type d -name slapd-*) sed -i "s/nsslapd-maxdescriptors:.*/nsslapd-maxdescriptors: 8192/g" $path/dse.ldif systemctl start dirsrv.target
RE: How is community version upgraded
For updates in the past, you can see the updates of for example Roundcube in the past months:
In my personal opinion, the more important question is: do you really want to run a mail server on your own?
If you know how to run a mail server and have the time to maintain it, then you are very much welcome to be part of the community and help with updating the community packages so that they are always uptodate with security fixes etc.
You pay either way: either with time (community version), or with money (subscription).
That is how it works for us at TBits.net: we use the community version, but we know how to fix the community packages, and we contribute to the community version.
RE: Kolab 16 Behind Apache Reverse Proxy
I run my development and test servers behind a proxy.
basically, do these things:
- in the file
[kolab_wap]add the line:
api_url = http://localhost/kolab-webadmin/api
- in the file
/etc/roundcubemail/config.inc.php, add the line:
$config['kolab_files_server_url'] = 'http://localhost/chwala/';
Does this solve your issues?
- in the file