Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Trym

Pages: [1] 2 3 ... 8
1
I did something stupid the other day, ran apt-get autoremove. Didn't seem to harm anything at first, but users have identified an issue where they can't edit the zarafa rule-list anymore, it stops at "Loading...".

I've tried uninstalling and re-installing Groupware (leads to the webinterface not being able to connect to zarafa, after reboot as well), tried re-installing fckeditor (which is the only item I specifically can remember being uninstalled by apt-get autoremove), didn't help.

Does anybody know which packages I need to install to get rule-editing working again?

::Trym

2
Thanks a lot, that seems to have done the trick!

For anyone else interested, the file is
Code: [Select]
/etc/default/zarafa-dagent
and the line
Code: [Select]
DAGENT_ENABLED=no
must be changed to
Code: [Select]
DAGENT_ENABLED=yes

Why this is not done by default by the installation or migration script is beyond me, but there it is. Thanks again!

3
No I hadn't, will try this tonight and report back, thanks.

4
Hi guys. For the third time this year I tried migrating from 2.0 to 2.2. This leads to mail failing.

The components are running, but queue-management/status shows

"connect to 127.0.0.1[127.0.0.1]:2003:Connection refused." for all mails.

I figured this would be fixed in time, so I've waited a few months between each attempt.

Does anybody know what I can do before/after migration to get this fixed? (I've searched for similar questions, and all I find are single-post questions with no answers or follow-ups.)

5
Installation and Upgrades / Re: Seeking advice for TRIM on Zentyal
« on: February 15, 2012, 04:32:46 pm »
c:  ubuntu 12.04 lts is due aprill,  and though you make it sound like thats a verry long time infact it itsn't  as there are already preview versions of the new software out there  including from zentyal  2.3 (witch wil eventually become zentyal 3.0)...  we should not rush or put in harms way the zentyal software so that 1 or two early adopters can have a nice play with software that other people rely heavily on... ubuntu is open enought to provide you with tools to install your custom kernals  as you see fit...
Dude, look at the date again. The post was written one year ago.

6
As you can see the above post is very old.

I did manage to create a complete restore-solution which worked well for a while, but due to constant changes in Zentyal I abandoned it. You may still find some useful pointers in it, especially the part about backup and restore of Zarafa.

It is here: http://how-to.solheimsvollen.net/HOW-TO_Zentyal_2_Backup_and_Disaster_Recovery.html

7
Marking this as [SOLVED] since no further responses were given although I supplied the requested information, I've made a ticket in trac instead.

8
The error message is just the standard "An internal error has occurred. This is most probably a bug, relevant information can be found in the logs. Please look for the details in the /var/log/zentyal/zentyal.log file and take a minute to submit a bug report so we can fix the issue as soon as possible."

I examined the logs in zentyal-usercorner, and zentyal-usercorner/zentyal.log shows this:
Code: [Select]
2011/11/29 17:58:30 ERROR> ExternalAccounts.pm:259 EBox::Mail::Model::ExternalAccounts::row - Unknown mail protocol: xxxxxxxx

where "xxxxxxxx" is the password for one of the user's external pop-accounts, so it seems to be a parsing-error. ('m guessing that the migration script does not convert the data for external accounts to the new format that the new usercorner expects.)

(Attaching all 4 logs in log/zentyal-usercorner, edited to remove password revealed in log. This is immediately after the migration, installing usercorner and trying to access external e-mail page for one user.)


9
I've in vain tried to get external e-mail in usercorner to work after migrating to 2.2.

As part of a process I'm doing anyway I've virtualised the physical machines, re-configured the network and then tried to migrate. The migration itself is succesful, but after installing user-corner and enabling it (since it's now a separate module) it gives an error message when trying to access the "External e-mail retreival" page. No external mail gets fetched either. I've gone back to the original 2.0-image and tried various combinations of ticking and unticking options in different modules before the migration, always with the same outcome.

The logs give no info I can relate to this error, the usercorner module is not reporting any errors I can find.

Does anybody have any clue? Purging existing data for usercorner is not an option.

10
Sorry for the delay.

So, I've done some testing.

First, I tried to restore a backup of my real home-server to a virtual machine. This procedure has worked countless times before. Now it doesn't. I didn't bother to even examine logs, cause the next logical step was to install a fresh virtual server and make a backup to restore.

Whaddayaknow, from a fresh 2.0.3 install to complete updated version, Zarafa now does not work at all.

Maybe I'm in a bad mood, but for me this is the final drop. I'm not even going to bother to try to make it work. I've had it with the endless string of bugs and modifications. I deeply regret (and have for a long time) ever deploying it. I can't count the man-hours it has cost constantly adjusting to a moving target.

(I wrote a page with detailed frustrations here, but decided to remove them, as they didn't add anything constructive.)

So basically what this means it that I will remove the how-to from the front-page, add a warning that it cannot longer be used, but still let people who want to read it (if they want to try additional adjustments themselves.)

This is not meant as a criticism of Zentyal per se, I'm sure it is useful for the majority of people/businesses out there, but for me personally I feel it does not suit my needs nor the needs of the people I do some work for.

I'm sorry for being unable to help, I'm sorry for withdrawing the how-to, but I cannot justify spending even more time trying to fix stuff.

Again, deeply sorry, and best of luck with Zentyal. Perhaps they have an updated backup and restore guide for you.

::Trym, over and out.

11
Yes, that certainly seems like the problem. And no, I have no clue why that happens.

It seems I have to run some tests, Zentyal may have made some recent changes which introduce this error.

Right now I'm on holiday, so I can't promise I'll get it done anytime soon, but I will do it. Sit tight.

Thanks for reporting this.

::Trym

12
I really don't know, I've never seen this before.

The only thing I can think of is that there is a problem with the restoration of the zarafa-database.

Are you able to restore only the file /backup/zarafa.dump.gz?

If yes, does it appear to be the right size?

..and what happens when you run

/scripts/rebuildzarafa

(Restore the user-module again after you do the above.)

I'm sorry, this is uncharted territory for me as well.

Quote
I did notice the password sourced in the scripts was different on the original server to the backup. Could that be it?

Not sure which password you're talking about here. The scripts read the mysql zarafa-password from the current system (and they are supposed to be different from system to system), any other passwords shouldn't matter at all.

::Trym

13
I assume you have restarted the webserver already, and if that didn't work that you have rebooted.

You can safely uninstall the groupware-module and reinstall it, that doesn't delete the mail-database. That is the first thing I would try.

If you're running zarafa on a virtual domain, you could also try setting it to a different domain (no domain), save changes, and then setting it back and save.

::Trym

14
Yes, by "fresh backup" I mean first remove *all* of the existing files in the backup-destination, then create a new backup (manually or scheduled, doesn't matter.)

If you've been using the same ebackup-version all the time, then this error is serious, it means the checksum of the remote backup is different from what duplicity expects, in other words a corrupt backup.

From your ticket I see you can get it to work by using --file-to-restore, which is another indication the *some* of the files in the complete set are corrupt. It could also, of course, be an indication of a duplicity bug ;-)

Another quick thought: You say you're transferring the files to a USB-stick, then try to restore from that. Which file-system do you use on the stick? Tried changing it? Doubt it will help, but worth a shot.

Sorry to be of little help.

::Trym

15
Yes, I've seen it before. It appears when:

o The backup module has been upgraded

AND

o The upgraded backup module has appended backups to an already existing backup set.

The strange thing is that if you run the command again, it will not display the error. (If it does then your backups are probably corrupt.)

I never did find out if this is indeed an indication of a corrupt backup, or just versioning differences. Personally I archived old backups and started with a fresh backup set, haven't seen the error since then.

To be on the safe side, I advise to create a fresh backup set (if possible.)

I *think* you can restore the backup without incident, but it was pretty hard to recreate the circumstances leading up to the error (the ebackup-versions which cause this are no longer available (somewhere between versions 2.0.5 and 2.0.9), so I never did get a chance to test this thoroughly.)

::Trym

Pages: [1] 2 3 ... 8