Some other usefule directories and files that you may check as well: /home/user-data/owncloud-backup /home/user-data/owncloud /home/user-data/owncloud/owncloud.db /home/deploy/mailinabox/setup/owncloud.sh /home/deploy/mailinabox/tools/owncloud-restore.sh /home/deploy/mailinabox/tools/owncloud-unlockadmin.sh /usr/local/lib/owncloud
So simple really, just needed to be in the right place
Thanks for the other pointers. I’ll have a dig around and see what else can be killed off from this completely unwanted (by us) ownCloud. I’m guessing but any MIAB upgrade is going to undo any changes (which is always a fallback should I blunderbus the whole system.
I found NextCloud really beneficial, and I’m not just talking about provisioning of “calendar” and “contacts” to your current e-mail users but also when I’m sending larger files I use it to upload the file/folder and create a share link ( could set password and expiration dates as well), so I only send the shared link to my e-mails.
I was thinking just the opposite, next cloud has an app for e-mail integration when this app matures enough I would ditch roundcube altogether and move to use only /cloud. Me and most of my users are using e-mail clients and they rarely use the WebMail interface.
But If you want to disable it then you head on to the right direction this is option one - to disable it on app level.
Option two - I would look into Nginx config in /etc/nginx/conf.d/local.conf under # Nextcloud configuration.
Make a copy and do some testing:
I’m not very familiar with Mail-in-a-Box structure and at that stage, if you disable it may cripple mail-in-a-box and may produce unwanted results.
Yes, rerunning “mailbox” or an upgrade will overwrite the changes.
I understand your perspective and it is likely to be the same as most of those who turn to MAIB as a mail solution.
Our corporate mail requires all those sort of assets and is not my responsibility or concern.
To give you, and possibly others, some idea of my perspective/involvement:
I am working on a client’s project.
They have no interest in Roundcube, ownCloud, or any fancy user interface with their mail server. All they want is an owned, core, secure, simple to maintain, lightweight, backend to very small, multiple mail accounts. They will only be dealing with small emails, mostly in plain text, with no attachments. They require spam filtering and are expecting, who doesn’t, to get a fair amount of that. They require no backup of email. but do require system backup and updates. They expect a ratio of about 15:1 of genuine traffic in:out.
MIAB appeared to be the easy option for me and them. All their interaction with the backend will be through their web site and their own interface.
MIAB has been a very simple install from my perspective and literally only a few hours from install to working system (LOTS of praise to the team for that!) I now need to just clip its wings and fix some inter-operability issues.
Okay, now I understand your objective.
Yes, MiaB really saves time in the deployment of the efull mail server, it’s a great also becausee it has simple API interface. I’m still learning how all bits are connected under the hood but agree MiaB it’s great mail-server.
Are you going to use NS functionality of MIAB? Will this company host it on its own infrastructure or in the public VM?
I was thinking of doing something similar as a stripped down MiaB on a secondary server in another geo-location running only some of the services as a relay / live backup /redundancy, but I’m still chewing it.
Once you’d figure all bits would be probably good to make a branch of MiaB git and apply your changes then pull the update from your GitHub and update from there. Testing it on a VM before applying it to production would be a fit. I sow somewhere pointing out to a script that can do an actual test of the services if they function fine, that can be adopted and aid your testing.
Would be glad to hear your solution whenever you are ready.
Setup is main site on a separate domain on its own dedicated server, Mail (and little else) on its own DO droplet with static page redirecting (for now, 'cause that is simple) and works, back to the main site.
Current issues are:
getting PHP to work inside /home/user-data/www/default
getting the MIAB API to function remotely
Actually those issues are other way around. As I am doing 1 to work-around 2 whereby a PHP script returns the result of a PHP curl from the main server.
Just posted a separate topic on (1) and already have one on (2)
Yes that REVERTING is a real pain! Especially as it effectively removes the option of using even one static site with PHP using the MAIB server! I don’t quite see why this is done. The static pages “should” be outside the mail server as they have little if anything to do with it. Hey, but I guess there must be some reason
The simplest solution
Well that is just what was originally planned. Now having solved the other problem of access to the mail API from the webserver on another box, I hopefully no longer need to run PHP on the MAIB server. Now to get IMAP working on the webserver box…
Thanks all for your help and advice, your time appreciated.