1

Topic: Problem upgrading to 1.4.1 from 1.1.1

==== Required information ====
- iRedMail version: 0.8.1 (Iredadmin pro 1.1.1)
- Store mail accounts in which backend (LDAP/MySQL/PGSQL): PGSQL
- Linux/BSD distribution name and version: RHEL6/64
- Related log if you're reporting an issue:
====

As the subjet says, I am attempting to upgrade my iRedAdmin Pro from 1.1.1 to 1.4.1.

So, I uncompressed the new Pro in /var/www
copied old settings.ini into new Pro dir
ran in the 1.4.1 folder:

[root@package iredadmin]# bash tools/convert_ini_to_py.sh settings.ini
* Backend: pgsql
* Copy sample config file: tools/../settings.py.pgsql.sample
* New config file: tools/../settings.py
  + Sync [general] section
  + Sync [iredadmin] section
  + Sync [vmaildb] section
  + Sync [policyd] section
   o Enable Cluebringer integration
  + Sync [amavisd] section
* Checking addition custom settings: ./libs/settings_local.py
  + [SKIP] No such file.
* DONE. New config file: tools/../settings.py

Moved the iredadmin symlink.

Set the permissions as described and restarted httpd

Went to the iredadmin page on my server, and the first thing I saw was the dashboard page, missing most of its data, but also telling me that an upgrade was available to 1.4.1. Which is strange as I just upgraded.

Clicked the details page and got a page showing my domains, most of the license info not there, and a red box with "Permission denied" but not telling me on WHAT the permission was denied.

So, something (maybe multiple somethings) isn't set correctly someplace with the upgrade, I'm guessing.

Thoughts?

thanks!

----

Spider Email Archiver: On-Premises, lightweight email archiving software developed by iRedMail team. Supports Amazon S3 compatible storage and custom branding.

2

Re: Problem upgrading to 1.4.1 from 1.1.1

Could you please show us output of below command:

# ls -l /var/www/

3

Re: Problem upgrading to 1.4.1 from 1.1.1

Note that I've set the "iredadmin" symlink back to 1.1.1 for the time being, since I need a working admin panel smile

drwxr-xr-x.  9 root      root      4096 Jun 27  2012 awstats
drwxr-xr-x.  2 root      root      4096 Aug  2 08:02 cgi-bin
drwxr-xr-x.  3 root      root      4096 Aug 14 03:46 error
drwxr-xr-x.  2 root      root      4096 Aug  2 08:02 html
drwxr-xr-x.  3 root      root      4096 Jan 12 03:36 icons
lrwxrwxrwx.  1 root      root        25 Jan 14 10:19 iredadmin -> iRedAdmin-Pro-PGSQL-1.1.1
dr-xr-xr-x.  8 iredadmin iredadmin 4096 Jun 27  2012 iRedAdmin-0.1.8
drwxr-xr-x.  8 iredadmin iredadmin 4096 Aug  6  2012 iRedAdmin-Pro-PGSQL-1.0
drwxr-xr-x.  9 iredadmin iredadmin 4096 Jan 17  2013 iRedAdmin-Pro-PGSQL-1.1.1
dr-xr-xr-x.  9 iredadmin iredadmin 4096 Jan 14 10:18 iRedAdmin-Pro-PGSQL-1.4.1
drwxr-xr-x.  3 root      root      4096 Jun 27  2012 manual
lrwxrwxrwx.  1 root      root        25 Jun 26  2012 phppgadmin -> /var/www/phpPgAdmin-5.0.4
drwxr-xr-x. 12 root      root      4096 Mar 22  2012 phpPgAdmin-5.0.4-orig
lrwxrwxrwx.  1 root      root        19 May 28  2013 roundcubemail -> roundcubemail-0.8.6
drwxr-xr-x. 11 root      root      4096 Jun 27  2012 roundcubemail-0.7.2
drwxr-xr-x. 11 vmail            80 4096 Nov 14  2012 roundcubemail-0.8.4
drwxr-xr-x. 11 apache    apache    4096 Jun 11  2013 roundcubemail-0.8.6
drwxr-xr-x.  2 webalizer root      4096 Jun 27  2012 usage

4

Re: Problem upgrading to 1.4.1 from 1.1.1

*) Does iRedAdmin-Pro shows version '1.4.1' on Dashboard page?
*) Does deleting all records in SQL table "iredadmin.updatelog" and re-login solve this issue?

5

Re: Problem upgrading to 1.4.1 from 1.1.1

ZhangHuangbin wrote:

*) Does iRedAdmin-Pro shows version '1.4.1' on Dashboard page?
*) Does deleting all records in SQL table "iredadmin.updatelog" and re-login solve this issue?

I moved the symlink back to 1.4.1 to capture a screenshot or two, and if it isn't working beautifully, now! Went ahead and did the switchover on my backup node, and also working beautifully. Don't know what could have changed between yesterday and today other than either something in the web browser's cache expiring or something getting cleaned out / unconfused in the backend database due to the date changeover.