Announcement

**Martin Heiland** · 02-05-2008, 09:33 PM

Hi Bruce,

the Open-Xchange Admindaemon is based on the OSGi Framework (http://www.osgi.org/). One pro of this framework is, that it's possible to remove single bundles or restart single bundles. The SW Update modules is such a bundle, you can see the list of bundles loaded at this file:

/opt/open-xchange/etc/admindaemon/osgi/config.ini

if you remove the part relating the sw-update bundle and restart the admindaemon the sw-update bundle should not longer be used. I just tried it and modified the osgi.bundles parameter to:

osgi.bundles=reference\:file\:/opt/open-xchange/lib/ox_admindaemon.jar@1\:start,reference\:file\:/opt/open-xchange/lib/ox_admin_plugin_backup.jar@2\:start,reference\:fil e\:/opt/open-xchange/lib/ox_admin_plugin_ca_mgmt_simple.jar@2\:start,refere nce\:file\:/opt/open-xchange/lib/ox_admin_plugin_context_light.jar@2\:start,referen ce\:file\:/opt/open-xchange/lib/ox_admin_plugin_imap.jar@2\:start,reference\:file\ :/opt/open-xchange/lib/ox_admin_plugin_mail.jar@2\:start,reference\:file\ :/opt/open-xchange/lib/ox_admin_plugin_mailfilter.jar@2\:start,reference\ :file\:/opt/open-xchange/lib/ox_admin_plugin_osconfig.jar@2\:start,reference\:f ile\:/opt/open-xchange/lib/ox_admin_plugin_services.jar@2\:start

After that im moved the apt-get binary to another place and restarted the admindaemon -> no errors.

**RBruce** · 02-05-2008, 11:22 PM

Thanks so much, Martin! We're past that one now. My groupware and admin logs are now running clean on startup, but user logins are still failing (which is no surprise). The admin login halts as before...

"Please wait while you are being redirected to the start page ..."

and for the user login...

"Rebuild Tree... Please wait..." (progress bar at 40%)

Firebug shows the latter stopped with a JS error "split has no properties."

No need to fuss with this one yet unless you see something obvious. I'll shake it down to something more specific, because I know I still have oxinstaller script issues, probably now limited to the "createuser" part. Shortly, I will have another question regarding the whole, modular arrangement...

**RBruce** · 02-05-2008, 11:48 PM

A little background for my next question...

My initial goal is groupware and database functionality without regard to (or any need for) the IMAP component - more specifically, calendar and contact data storage and interaction, and Funambol synchronization. I am currently mired in IMAP user creation issues (without the equivalent trouble on the MySQL side). Initially, my only need to get beyond the IMAP issues is just to get everything "working" so I can get on with Calendar and Contact data management experiments. I currently manage IMAP servers using Courier-IMAP, and would probably want to plumb to external servers eventually anyway (although I am studying the merits of this Cyrus installation). The installation process seems heavily dependent on the local Cyrus installation (which I do not need), and it seems impossible to create a new database user unless you also succeed with the local IMAP user. Having said that, I have done OK with createuser --dbonly. However, I suspect that one of my issues with the stalled user logins is an effort to populate the first page with something IMAP related.

Is it possible to cleanly separate the IMAP side from the SQL data-related side so that user logins (including admin) can succeed without dependencies on IMAP connections at the time of the login?

Again, thanks!
Bruce

**Martin Heiland** · 02-06-2008, 12:36 AM

Hi,

the Admin Part is taken 1:1 from OX:EE which requires a local cyrus installation to do all the fancy user management stuff via an easy Admin GUI. So i think you'll have to use the dbonly workaround to not run into trouble.
The groupware part is completely seperated from the admin part. You can define any IMAP server you like (local or remote), courier, cyrus and dovecot work right out of the box. If the IMAP subsystem is unreachable, the login will take some time and the GUI will disable the E-Mail module - but it will not stall nor throw JS errors. I guess these two issues are not related, which version of the GUI do you use? Greetings.

**RBruce** · 02-06-2008, 12:51 AM

Thanks again, Martin, for the exceptionally prompt replies. I am compiling everything at bf_6_4 except the admin-gui-ee, which is at 12/15/2007 as suggested in your recent workaround for that. It seems that my oxadmin user is being respected at login (OK in MySQL), both in /ox and in /admin, with the stalls that I reported earlier after that. Would some log output be useful or can you suggest other experiments to help track down the cause? Thanks...

**Martin Heiland** · 02-06-2008, 01:00 AM

Well, thats strange - if the user gui stalls with a JS error it would imply that the groupware gui is broken in bf_6_4 which is not the cause, i've just compiled one today - did you clear your browsers cache? maybe there is something left of a former installation. mod_expires can be very evil in such cases.
To track down the issue - just tail -f all ox logfiles and try to login, maybe a exception flows by which can tell more about whats going on.

**RBruce** · 02-06-2008, 01:57 AM

Thanks Martin. Browser cache - yes. However, I have beaten this installation to death over the last couple of weeks to get past other issues - mod_jk compatibility and others. I have also "settled" for a known broken IMAP user creation process, and have not yet touched the Postfix config. Perhaps I have presumed too much in my haste to get logged into groupware to proceed with "only" Calendar and Contact data. I will clean up and rework the entire process from the start in case it is tainted by past experiments. I tweaked a few things along the way to get everything compiling successfully and to start without errors. One in particular may be of interest: I have disabled LTCP caching by commenting some source code (your suggestion found in another thread), because my Fedora server was refusing to bind one of two ports that it wanted (causing groupware startups to fail). I anticipate only a standalone server (no need for the caching). Since then, I have been tolerating this...

SEVERE: Could not instantiate auxFactory named "LTCP".

...assuming this to be unimportant, since there seemed to be no cascading consequences.
The logs are pretty clean otherwise. Could this be an issue?

The user login remains as before (same JS error at 40% progress), and I am now finding this one (from firebug) during the /admin login problem:

GET http://<testsite>/oxadmin/license?action=restore 404
<p>The requested URL /oxadmin/account was not found on this server.</p>

Others which are similar then follow. If you don't see anything obvious here, I will proceed as mentioned above and let you know where that takes me
(after a clean installation). Thank you very much!

**RBruce** · 02-07-2008, 11:37 PM

I am happy to report that my total rebuild worked. I now have a functioning server on Fedora 7 with oxadmin getting around OK in the groupware GUI. The admin GUI seems to compile and install OK, but I still cannot get a login there. The response in the browser at login time is "404/Not Found." Firebug reports "The requested URL /oxadmin/login was not found on this server." HTTPD error log shows "File does not exist: /var/www/ox6/oxadmin." Is it likely that I missed something which is causing the files not to be there? Or more likely a configuration issue causing a misdirected translation or referral?

I noticed in the installation instructions...

cd open-xchange-admin-gui-ee
ant -Dlib.dir=/opt/open-xchange/lib/ -Dhtdoc=/var/www/ox6/admin install
cd open-xchange-admin-gui-ee-ajax
ant -Dlib.dir=/opt/open-xchange/lib/ -Dhtdoc=/var/www/ox6/admin install
cd open-xchange-admin-gui-ee-templates
ant -Dlib.dir=/opt/open-xchange/lib/ -Dhtdoc=/var/www/ox6/admin -Doxguidir=/var/www/ox/admin install

...that oxguidir = /var/www/ox/admin
whereas all others are .../ox6/admin

Is this correct? I fear it is unrelated to my problem, because I have tried it both ways.

Thank you!

**RBruce** · 02-07-2008, 11:55 PM

So sorry, I just found the answer. I found the missing JKMount lines for /oxadmin in ox.conf for the admin GUI! The admin GUI is now working!

I would still appreciate an answer regarding the "www/ox" vs. "www/ox6" location for "oxguidir" as mentioned above.

Thanks! Bruce

**Martin Heiland** · 02-08-2008, 01:45 AM

Hi Bruce,

those paths are just not correct at the wiki, i am currently rewriting the installation wiki where this has already been fixed. You'll find the correct parameter names inside the build.xml file.

Greetings

**RBruce** · 02-09-2008, 08:09 PM

Hi all, and thanks Martin for the replies. Everything is pretty much working now. I am trying to sort out some issues with the create mailbox process that are plaguing my installation and system usage in a few different ways. I will start with this and try to keep it specific...

Why does [com.openexchange.admin.rmi.impl.OXUser] create a /home/username directory, and how will it be used? Does Cyrus require this? This may or may not be redhat-specific, but after this homedir is created, the CHOWN process fails. This is because "username" does not exist on the system (in /etc/passwd).

I can work around this to make the groupware functional, but I hope to make more progress now with the IMAP side of things. I was thinking of an experimental source code change which would alter the CHOWN process from...

{ CHOWN, usr.getName() + ":", homedir }, to something like...
{ CHOWN, "cyrus:", homedir } -or- { CHOWN, "mail:", homedir }

I believe this would prevent some errors, but would first like to understand the need for /home/username in the first place.

Thank you...
Bruce

**Martin Heiland** · 02-10-2008, 01:52 AM

Hi,

this directory is required for mail filter/fetchmail configuration on a per-user basis.

**RBruce** · 02-10-2008, 02:39 AM

Ah, very good - thank you. I am getting cleaner results now by modifying the chown process as mentioned above. Createuser no longer throws me out at the chown attempt. It does, however, continue to fail while attempting to create the Cyrus mailbox. If I use --dbonly and then follow up manually with cyradm, everything seems to work: (1) /home/username* is created, (2) MySQL succeeds, and (3) Cyrus mailbox is OK. This clears up errors in the user GUI when selecting e-mail folders, and in the admin GUI when selecting a user. Since I have been unable to trace the Cyrus mailbox creation process into source code, I will operate in this "workaround" mode for now. Thank you...

* must not pre-exist if same user attempted before (remove manually)

Announcement

issues on Fedora (getting close)

issues on Fedora (getting close)

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment