Re: [Kolab-devel] devel Digest, Vol 122, Issue 18

On Thursday, October 10, 2013 02:00:49 PM de Raad, Hans wrote:
> Hi Jeroen,
> 
> i've performed the following steps, and i've encountered some issues,
> perhaps these might be of use to you:
> 
> - Installed a clean CentOS 6.4 on a virtualbox machine
> 
> - Installed kolab from the regular repos, as specified in
> http://docs.kolab.org/en-US/Kolab_Groupware/3.0/html/Community_Install
> ation_Guide/chap-Community_Installation_Guide-Installation.html#sect-C
> ommunity_Installation_Guide-Installation_with_RPM_Packages-Red_Hat_Ent
> erprise_Linux [3]
> 
> - Performed setup-kolab, which presented a running installation in
> which i have added a user and with this user i could log into
> roundcube and send mail (or at least, fill the queue, since this is a
> confined environment).
> 
> I then performed the following steps with their respective
> results/remarks:
> 
> 1. Upgrade all packages to the 3.1 version
> 
> Install new OBS repository:
> Wget the http://obs.kolabsys.com:82/Kolab:/3.1/CentOS_6/Kolab:3.1.repo
> file to /etc/yum.repos.d/
> 

Meanwhile, we also have 
http://obs.kolabsys.com:82/Kolab:/3.1:/Updates/CentOS_6/Kolab:3.1:Updates.repo

> yum update
> 
> During the installation, a lot of notices/errors/warnings occurred in
> specifically the php based packages:
> 
> Installation php problems during installation of
> php-pear-DB-1.7.13-3.el6.noarch & roundcubemail-1.0-7.1.1.noarch:
> PHP Warning: function registration failed, duplicate name
> new_vectorevent / vectorevent_set / vectorevent_size /
> vectorevent_capacity / vectorevent_clear / vectorevent_push / etc
> PHP Warning: module kolabformat already loaded in Unknown on line 0
> PHP Notice: constant swig_runtime_data_type_pointer already defined
> 

I'm curious whether this could be solved by making php-kolab depend on 
php-kolabformat (and/or vice-versa), since while the extensions loaded 
in /etc/php.d/kolab.ini depend on the one loaded in 
/etc/php.d/kolabformat.ini...

IIRC, they need to be loaded in the correct sequence, which is why we 
prepended the 'kolabformat.so' extension to the 'kolab.ini' in addition 
to keeping it around in 'kolabformat.ini'.

That said, I don't want to overload dependencies just because of some 
configuration gotchas.

Also, IIRC, we're seeking to make these functions belong to the 
appropriate namespace.

> SQLConnect error in roundcubemail installation
> 

This is likely the %post script from roundcubemail attempting to 
automatically update the database schema, but having the old settings 
(i.e. $rcmail_config['dsnw'] where it might need $config['dsnw']).

> 2. Run setup-kolab imap
> 
> Done without problems
> 
> 2.1 Remove squatter:
> http://hosted.kolabsys.com/~vanmeeuwen/build/html/administrator-guide/
> upgrading-from-kolab-3.0.html#the-use-of-squatter
> 
> 
> Ran the provided snippet as a .sh script, works.
> 
> 3. Run setup-kolab mta
> 
> Done without problems
> 
> 4. Run setup-kolab roundcube
> 4.1 Dont be scared of errors about already existing databases
> (improvement might be possible here?)
> 
> There were a lot of notices/errors, but otherwise it ran.
> 
> 4.2 Manually check schema updates (improvement might be possible
> here?) rpm -ql roundcubemail roundcubemail-plugins-kolab | grep sql
> 
> Checked that output, as far as i can see, last updates were from
> may/june, so i left them alone.
> 
> I did run the bin/installto.sh script, as specified in:
> http://trac.roundcube.net/wiki/Howto_Upgrade [4]
> 
> Seems the installation/upgrade works. But i got a lot of
> errors/warnings, are these possible related to my setup or are these
> still an issue with the updateprocedure?
> 
> Best regards,
> 
> Hans de Raad
> 
> ---
> 
> DevHdR
> onderdeel van HaLeNaS v.o.f.
> 
> Van Sevenbergestraat 49
> 2274 PK Voorburg
> 
> KvK: 53493753
> 
> Tel: +316-83578847
> 
> www.hcderaad.nl
> 
> On 2013-09-16 12:00, [email protected] wrote:
> > Send devel mailing list submissions to
> > [email protected]
> > 
> > To subscribe or unsubscribe via the World Wide Web, visit
> > https://lists.kolab.org/mailman/listinfo/devel [2]
> > or, via email, send a message with subject or body 'help' to
> > [email protected]
> > 
> > You can reach the person managing the list at
> > [email protected]
> > 
> > When replying, please edit your Subject line so it is more specific
> > than "Re: Contents of devel digest..."
> > 
> > Today's Topics:
> > 
> > 1. Re: Upgradepath towards 3.1 (Jeroen van Meeuwen (Kolab Systems))
> > 
> > List-Post: <mailto:[email protected]>
> > Content-Transfer-Encoding: 7bit
> > From: "Jeroen van Meeuwen (Kolab Systems)" <[email protected]>
> > Precedence: list
> > MIME-Version: 1.0
> > To: [email protected]
> > References: <[email protected]>
> > <[email protected]>
> > In-Reply-To: <[email protected]>
> > Date: Sun, 15 Sep 2013 11:17:26 +0100
> > Reply-To: Kolab development coordination <[email protected]>
> > Message-ID: <[email protected]>
> > Content-Type: text/plain; charset=UTF-8;
> > format=flowed
> > Subject: Re: [Kolab-devel] Upgradepath towards 3.1
> > Message: 1
> > 
> > On 2013-09-14 20:58, de Raad, Hans wrote:
> >> Hi Jeroen, thanks again for the clarifications, might i try a quick
> >> summary? This to try and find the cleanest possible upgrade path.
> >> 1. Upgrade all packages to the devel version 2. Run setup-kolab
> >> imap 2.1 Remove squatter:
> >> http://hosted.kolabsys.com/~vanmeeuwen/build/html/administrator-gu
> >> ide/upgrading-from-kolab-3.0.html#the-use-of-squatter [1] 3. Run
> >> setup-kolab mta 4. Run setup-kolab roundcube 4.1 Dont be scared of
> >> errors about already existing databases (improvement might be
> >> possible here?) 4.2 Manually check schema updates (improvement
> >> might be possible here?) rpm -ql roundcubemail
> >> roundcubemail-plugins-kolab | grep sql And by now one would run
> >> 3.1? If this is the case, i'd like to offer to create an update
> >> script performing these steps.> 
> > That would be great, I would appreciate notes and feedback on what
> > else may need to happen for an upgrade process.
> > 
> > That said, if we start to iterate over the things we might look at
> > doing;
> > 
> > - check and optionally prepare various aspects of the system, and
> > - setup components (all of them or part of them), and
> > - update / upgrade components,
> > 
> > we might want to start looking at how useful the current
> > setup-kolab.py is exactly. Additionally I can add to this list;
> > 
> > - a functioning '--yes' that just walks through the preparations and
> > setup with default values,
> > - a functioning '--demo' that seeds some sample data in to the
> > environment,
> > - a variety of options along the lines of: --with-ldap=openldap,
> > --with-imap=dovecot, --with-sql=postgres.
> > 
> > So perhaps it is time to design all of that properly.
> > 
> > Kind regards,
> > 
> > Jeroen van Meeuwen
> > 
> > _______________________________________________
> > devel mailing list
> > [email protected]
> > https://lists.kolab.org/mailman/listinfo/devel [2]
> 
> Links:
> ------
> [1]
> http://hosted.kolabsys.com/~vanmeeuwen/build/html/administrator-guide/
> upgrading-from-kolab-3.0.html#the-use-of-squatter [2]
> https://lists.kolab.org/mailman/listinfo/devel
> [3]
> http://docs.kolab.org/en-US/Kolab_Groupware/3.0/html/Community_Install
> ation_Guide/chap-Community_Installation_Guide-Installation.html#sect-C
> ommunity_Installation_Guide-Installation_with_RPM_Packages-Red_Hat_Ent
> erprise_Linux [4] http://trac.roundcube.net/wiki/Howto_Upgrade

Kind regards,

Jeroen van Meeuwen

-- 
Systems Architect, Kolab Systems AG

e: vanmeeuwen at kolabsys.com
m: +44 74 2516 3817
w: http://www.kolabsys.com

pgp: 9342 BF08