1

Topic: sogo issue after re-install and upgrade to admin pro

================ Required information ====
- iRedMail version (check /etc/iredmail-release): 0.9.2
- Store mail accounts in which backend (LDAP/MySQL/PGSQL): MySQL
- Web server (Apache or Nginx): Apache
- Linux/BSD distribution name and version: Red Hat Enterprise Linux Server release 6.6 (Santiago)
- Related log if you're reporting an issue: email notice from 2 sogo cron jobs
====

Todd Lane - Securimate, Inc. paid for upgrade to Admin Pro on Jun 22.  Please add me, ghaecker@securimate.com, to any notices about bug fixes and new releases.
--------------------------------------------------------------------

Things you should probably know about our installation:

1. I removed every package I could to get back as nearly to a "clean" server as possible.
2. Modified php* package references ./functions/packages.sh to php54* before re-installation.
3. Installed iRedMail - no pre-existing databases.  Removed as many previous directories and config files as I could find before installation.
4. Activated iRedAdmin-Pro 2.1.2
5. Replaced self-signed cert with commercial cert.
6. Set up SPF and DKIM records for virtual host.
7. Created one additional (test) user, in addition to the required postemaster admin user.
8. Successfully tested send and receive from both users.
9. Found and eliminated duplicate entries in root and sogo crontabs.
10. Commented out the two sogo cron jobs that run every minute, because they were generating emails to postmaster due to errors.  (more on this below)

The primary reason for the re-install was related to possible overlap in hostname, domain name, and first (only) virtual domain.  hostname on the server is 703672-ma.securimate.com.  Original domain name was ma.securimate.com and so was the virtual host in iRedMail.  Domain name is now same as server hostname to eliminate any possibility of conflict with virtual host, ma.securimate.com

I see two issues with SOGo


ISSUE 1:  Missing sogo tables

Two sogo cron jobs are reporting missing tables in the sojo database.  Here are the messages

Message 1:

2015-06-24 08:01:01.680 sogo-tool[55409] Table 'sogo.sogo_sessions_folder' doesn't exist
/usr/sbin/sogo-tool: Uncaught exception ExecutionFailed, reason: Table 'sogo.sogo_sessions_folder' doesn't exist

Message 2:

<0x0x23c8d58[GCSAlarmsFolder]> -[GCSAlarmsFolder recordsForEntriesFromDate:toDate:]: cannot execute fetch: <MySQL4Exception: 0x242a2c8> NAME:ExecutionFailed REASON:Table 'sogo.sogo_alarms_folder' doesn't exist
<0x0x2410fd8[GCSAlarmsFolder]> -[GCSAlarmsFolder deleteRecordsForEntriesUntilDate:]: cannot delete record: <MySQL4Exception: 0x22bab28> NAME:ExecutionFailed REASON:Table 'sogo.sogo_alarms_folder' doesn't exist

The sogo database has only 1 table: sogo.users    This table has the 2 user records I expect to be in it.
There are no other tables in sogo database.

Question:  how do I initialize the 2 missing tables?  Are any other tables missing from this database?

Once the missing tables are in place, I should be able to re-activate the sogo cron jobs.  Is that correct?


ISSUE 2:  Web access to SOGo  (link from tips file generated during installation)

703672-ma.securimate.com/SOGo/

Server displays the following message:
-------------------------------------------------
Service Temporarily Unavailable

The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later.
Apache Server at 703672-ma.securimate.com Port 443
-------------------------------------------------

I attempted to remedy by adding a more specific alias in /etc/httpd/conf.d/SOGo.conf

Alias /SOGo/ \
      /usr/lib64/GNUstep/SOGo/WebServerResources/

above the two Alias directives that were already there.
Same error - no change.


In addition to these 2 SOGo errors, the SMTP password command errors reported previously in
forum post:  iredmail.org/forum/post40349.html#p40349

still persists.  Behavior is identical to previously posted details, except after re-installation, I'm testing only one (new) user.  Any idea what's going on there?


Thank you.

-- Glenn

----

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

2

Re: sogo issue after re-install and upgrade to admin pro

ghaecker wrote:

paid for upgrade to Admin Pro on Jun 22.  Please add me, ghaecker@..., to any notices about bug fixes and new releases.

Added. Thanks for your purchase.

ghaecker wrote:

ISSUE 1:  Missing sogo tables

Please start 'sogod' service, it will create required SQL tables automatically.

ghaecker wrote:

ISSUE 2:  Web access to SOGo  (link from tips file generated during installation)

Caused by sogod service is not running.

3

Re: sogo issue after re-install and upgrade to admin pro

ZhangHuangbin wrote:
ghaecker wrote:

paid for upgrade to Admin Pro on Jun 22.  Please add me, ghaecker@..., to any notices about bug fixes and new releases.

Added. Thanks for your purchase.

ghaecker wrote:

ISSUE 1:  Missing sogo tables

Please start 'sogod' service, it will create required SQL tables automatically.

ghaecker wrote:

ISSUE 2:  Web access to SOGo  (link from tips file generated during installation)

Caused by sogod service is not running.

Sorry to report, it doesn't stay running.

[root@703672-ma ~]
# /etc/init.d/sogod status
sogod dead but pid file exists
[root@703672-ma ~]
# /etc/init.d/sogod start
Starting SOGo: 
  sogo (stale pid file removed)                            [  OK  ]
[root@703672-ma ~]
# /etc/init.d/sogod status
sogod dead but pid file exists

No tables are added to sogo database, web access still fails.  Re-enabled sogo cron jobs still fail with missing tables.

4

Re: sogo issue after re-install and upgrade to admin pro

Any error in /var/log/sogo/sogo.log?

5

Re: sogo issue after re-install and upgrade to admin pro

No, it's an empty file.

6 (edited by ghaecker 2015-06-25 12:18:24)

Re: sogo issue after re-install and upgrade to admin pro

sogod is running now.  The problem was /var/log/sogo/sogo.log was owned by a non-existent user (uid 496, gid, 496) instead of uid 493, gid 493.  I set proper owner:group.

/var/log/sogo/sogo.log is reporting activity now.
Now it runs, and it created the missing tables.
Web access works, too.

sogo crontab re-enabled; no cron error messages.

Looks like the log file ownership was the issue.

Thank you.