issues on Fedora (getting close)
I am new, but have been reading for a while - not a developer, but have been intense with sysadmin effort on a Fedora installation. I am carefully documenting the process (what works) in hopes of being helpful to others who wish to run on Fedora. I think I am getting close. Compiling is OK and logins look promising. The first issue I could use some "developer" help with is...
How can I stop the admin daemon from attempting
to run "apt-get" on startup to check for updates?
I can see the calls in the source code (open-xchange-admin-plugin-sw-update is in play), but I have no idea how to shut them down. When I start the admin daemon, my log output stops shortly after a SEVERE error related to the "apt-get" call, so I can't tell what other issues are going to follow. From the browser, I see "Please wait while you are being redirected to the start page ..." (forever) while attempting to login as "oxadmin" at <site>/admin after the admin-daemon and groupware startup (which does seem to succeed).
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:
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.
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...
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?
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.
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...
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.
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!
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...
ant -Dlib.dir=/opt/open-xchange/lib/ -Dhtdoc=/var/www/ox6/admin install
ant -Dlib.dir=/opt/open-xchange/lib/ -Dhtdoc=/var/www/ox6/admin install
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.
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.