Upgrade from 12.04 to 14.04 fails....

Submitted by virtualmin3123 on Wed, 07/16/2014 - 07:25

Dear support,

I just upgraded from 12.04 to 14.04. And... it fails. I used the advised manual from: https://www.virtualmin.com/documentation/system/os/ubuntu-precise-to-trusty

My mail users can now no longer receive their mail. I got the following error: Jul 16 13:54:43 SYSNAME dovecot: imap(user.domain.tld): Error: user user.domain.tld: Initialization failed: namespace configuration error: inbox=yes namespace missing Jul 16 13:54:43 SYSNAME dovecot: imap(user.domain.tld): Error: Invalid user settings. Refer to server log for more information.

Please help.

Thanks

Status: 
Active

Comments

Submitted by virtualmin3123 on Wed, 07/16/2014 - 09:05

I now added the following manually to my dovecot.conf in the /etc/dovecot folder:

namespace inbox { inbox = yes }

Should I do this? It seems to work. I have had an original Virtualmin setup (4 month old!) and upgraded tot 14.04 and this happens. You should add this to the upgrade document as this actually causes a serious issue for the continuity of our clients.

Please respond AND please advise.

Submitted by andreychek on Wed, 07/16/2014 - 09:17

Howdy -- after adding namespace inbox { inbox = yes }, did that correct the problem you were seeing? And you're able to receive email now?

Submitted by virtualmin3123 on Wed, 07/16/2014 - 09:41

Yes, this solved the problem but is not a charming solution.

Submitted by andreychek on Wed, 07/16/2014 - 10:03

Googling for the error you received, it looks like you're not the only one to get that error upon upgrading Dovecot, and your solution is the best one.

I'll do some research to see if that line you added needs to be put in there every upgrade, or only in some cases; once I figure that out we'll update the Ubuntu upgrade documentation.

Submitted by virtualmin3123 on Wed, 07/16/2014 - 14:37

Don't forget I'm running the default Virtualmin configuration. This should not happen at all.

Is there new a namespace inbox programming code (statement) which did not existed in the ubuntu 12.04 version of Dovecot? On all questions a for Keeping or replacing the configuration I answered to KEEP (default) it. Then you probably should advise UPDATERS to replace these "aged" configurations is it?

I'm now unsure if it was wise to keep the advise for KEEPING these configuations for Dovecot. please advise.

Submitted by andreychek on Wed, 07/16/2014 - 15:17

Overwriting the configs is usually bad, and will wipe out any changes that have been made by both the sysadmin, as well as by the Virtualmin installer. That's much harder to fix than adding the line that you added :-)

If we're able to reproduce the issue you saw in our testing, what we'll do is just update the upgrade documentation, and have sysadmins add that line.

Any time you see that issue, that's the best fix -- just add in the line it was asking for.

Submitted by virtualmin3123 on Wed, 08/06/2014 - 07:50

I noticed that after the upgrade from 12.04 tot 14.04 my PHP is not working. I tried to reinstall PHP using APT but this does not work. What should I do? Please help.

Submitted by andreychek on Wed, 08/06/2014 - 10:01

What happens when trying to execute a PHP script? Do you receive an error of some sort?

Also, what is the PHP execution mode set to for domains experiencing this problem?

Submitted by virtualmin3123 on Thu, 08/07/2014 - 03:54

If I run a PHP script the browser will display the sourcecode/script of the PHP page.

Submitted by andreychek on Thu, 08/07/2014 - 09:52

That problem can be caused by a "SetHandler" line in Apache's PHP config.

If you go into System Settings -> Re-Check Config, does it detect any problems? If it's a SetHandler issue it should be able to detect that.

Submitted by virtualmin3123 on Mon, 08/11/2014 - 16:35

Thanks but I do not get this warning (except the all time warning from a not running antivirus deamon).

It seems that PHP (roundcube) is working for all other domains except but one specific domain. I replaced the php.ini in the /home/domain.tld/etc/php/ with the one from a working domain but this does not make any difference. Any other suggestions?

Thanks in advance.

Submitted by andreychek on Mon, 08/11/2014 - 17:08

What is the PHP execution mode set to for domain(s) experiencing this problem?

Submitted by virtualmin3123 on Mon, 08/11/2014 - 17:24

Okay guys. I did it the long way.... I replaced my domain.tld.conf in /etc/apache2/sites-available/ with a backup of this config file from a year ago. As my IP changed and SuexecUserGroup setting I updated these with the old settings for the 80 and 443 virtualhost in the file. This seems to work. I think a inconsistent config file (with too many old and no longer operational) statements in the config file caused this issue. This is not an error of Virtualmin.

Would it not be possible/feasible to create a "regenerate config file" option in virtualmin to make it possible to restore a default config file for a selected domain? Looking forward to your answer.

[Solved]

Submitted by andreychek on Mon, 08/11/2014 - 17:32

One way to do that would be to go into Edit Virtual Server -> Enabled Features, and then disable the "Apache website enabled" option. Save that, then go back in and re-enable it.

After disabling, then re-enabling, that particular option, it would regenerate the Apache config for that domain.

Would that do what you're after?

Submitted by virtualmin3123 on Mon, 08/11/2014 - 18:08

Yep, but without you telling me this now, I could not easily know this. The only way is to do this is on trail en error and that is time consuming.....

Now you told me I know.

Reason for my answer is that by default the config file on ubuntu will not be deleted unless you explicitly tell ubuntu to do so......

Submitted by techforce on Fri, 08/15/2014 - 13:32

Im having the same kind of problems. The upgrade for Ubuntu prompted many times to overwrite or keep existing config files....and since the problems mostly seem config files, I guess in hindsight we were suppose to overwrite them....not keep them by default.

After I rebooted, somehow Webmin /Vmin defaulted to an older version. There were upgrade options, and options to detect the new Ubuntu version, which I did, but apparently this was unwise.