Hi @fbartels

Thank you for your great work! This is definitely on a good path

Some few things I noticed:

• Saving a config throws a Error saving config: IOError. I also checked with a reboot and it seems it really can't be saved right now. (also smtp wouldn't be possible without this fixed)
• When accessing the admin panel when not logged into cloudron, you get a password prompt. A 403 HTTP would probably be more suitable and secure

And as a small Bonus: As the app is getting in a pretty good shape, it is time for a logo =D
here you go: https://github.com/bitwarden/brand/blob/master/icons/256x256.png

You're welcome

I hope this pr is going to be merged into bitwarden_rs soon: https://github.com/dani-garcia/bitwarden_rs/pull/396

It would make it a lot easier for the user management. Currently registration is open to the world until you set ENV SIGNUPS_ALLOWED=false, which only makes sense after you created a first account. After setting it you could work with invites, but the invitation model sucks (you can just invite when having an Organisation or you can do it in the admin panel, but you have to set another env variable to access it and you can't save stuff there).

So currently not really usable for the normal user. As far as I understood, with the ldap integration accounts / invites will be synced for all ldap users, which is exactly what we want. I also hope the admin panel gets some love, as in my eyes the token system to log in there isn't really easy to handle. And there seems to be a problem saving the settings you set there, but that's probably a problem in the cloudron integration.

@fbartels It works now with the fix from my colleague m4rg4sh (he submitted a pull request). Also there is a new version 1.8.0 - I just updated to it and everything looks great so far

Hi @fbartels

Build and install worked without problems, but i'm facing the same issue as @necrevistonnezr

Couln't really find something on the first view, but i'm not that familiar with containers. Would be great to see it running, thank you for your efforts you already made!

I'm having the same issue. I think at least since 3.5.1.

In my eyes all DNS checks out of the PTR are broken. When I check it manually with dig everything looks fine.

I'm using manual DNS entries and never changed anything there (but suddenly the checks went to red).

Hi @girish

Thx for your answer!

Yes, it's 3.5.2 on the 16.04 and 18.04 VM

I see the size as I made a bucket for tar and a bucket for rsync and i can see the size of each at the page of my provider. This behavior is something I could reproduce. Even tough there is some compression a compression rate of 1:10 made me wonder..

What do you think about the mails that weren't synced? Could it be in relationship to one of the errors?

Hi guys

General information
I'm trying to migrate from 16.04 to 18.04 and set up the new server parallel to the old one.

Details
Here are my experiences so far:

At the first attempts, when using the restore functionality at the setup process I get two results:
When I try to restore from my rsync backup, after some time I just get redirected to the setup startpage and nothing happens This behaviour I could reproduce twice already, but this time I was also prepared with a .tar backup:

When I tried to restore from my tarball backup, I got the following error:

EPERM: operation not permitted, utime '/home/yellowtent/boxdata/mail/haraka-config'

I thought maybe it was that the time in the just finished backup was ahead of the server time, so i checked and the server was still on UTC instead of CET. After changing it to the correct timezone and verification with date I did have the correct time. However, the error persisted.

I tried then again with rsync, which gave me following output:

unable to create path: EACCES: permission denied, mkdir '/home/yellowtent/boxdata/mail/vmail/<user>@<domain>.<tld>'

So I went into the vmail directory, which had the permissions set to builder:builder. I changed it to yellowtent:yellowtent and tried again. And then actually things started to happen, as I saw it in the box.log.

The whole process took some time, while not seeing any progress over web - also after it finished it was still at the restoring screen. So I just knew because of my tail -f on the log that everything seems to be up and running and manually changed from restore page to main page.

Verification

After logging in, everything looked good, all apps were installed. I checked some apps, Sogo, Nextcloud etc seem to have all the data. However, e-mail didn't. All mails were gone on that account I checked. And it doesn't seem to be possible to get them back by restoring the rainloop app (as mails are probably not stored in the webmail apps).

This lead me to the decision, to rollback to the old installation and find out via the forum how to continue. This way I won't have a split situation for emails and mixed backups.

Problem statement
How can I restore all my data without any loss?

Further debugging
I can offer the possibility to trash the new VM and setup a new one, so if nebulon or girish want to have a closer look at the restore topic this would absolutely be possible.

Before shutting the Ubuntu 18.04 VM I backed up all Cloudron logs as well as the logs in /var/log/*. So these are at hand.

Additional questions

1. One thing that confused me additionally: The size of the tar backup is 16G compared to 150G in rsync. To me rsync looks like a full disk backup while tar just backups userdata and the cloudron specific data. Is this correct or is my tar backup broken?

2. Are the TLS keys and certificates restored from the backup as well or are all certificates new? Didn't have time to check, but it could break DNSSEC TLSA if the keys are new.

Thx in advance for your support!

Looking forward to this. Need to track all my IP addresses & subnets somehow and it would be great to have it in cloudron!