Is it possible to change client/owner on mailboxes, aliases, catchall, etc. ? When I change the client for the mail domain, it only changes the owner of the domain. (Mailboxes, aliases, catchall, etc. is still owned and can be managed by the previously client.) Do I really have to delete the mailbox and create it again, from the new client?
you could change it in sql (eg. phpmyadmin), likely with a few simple updates once you figure out exactly what table.column name to update and the correct value (limit your query to match only that domain)
Sorry for my late reply!! I had totally forgotten all about your post. I mean, giving/moving existing mailboxes, etc. to another ISPConfig client. I have all my own domains on individual users and now just want one main user, since I actually don't use my domains, other than having a couple of mailboxes and catchalls. Thanks for your suggestion. But is it really enough just to chance it in SQL? Wouldn't it also be necessary to chance some permissions somewhere?
Cool! I'll give it a try later, then. Oh, sorry that I forgot to inform that in first post. I'm running 3.1.1p1.
In that case you should first try to set the owner of the mail domain back to the original owner, then update to 3.1.6 and then try to change the owner again. I don't remembre that there are issues with owner changes in ISPConfig currently, so there might be just an issue in your old version.
So it should actually have changed the owner for the mailboxes as well? Okay.. I just thought the function wasn't possible in ISPConfig, even that I quite couldn't understand why. Thanks... I'll give it a try and get back with a result! ## UPDATE: While looking at my clients, web/mail domains, etc., I think something is (really) messed up. A couple of web domains is owned by my own reseller account (userid 2), but can still be managed by the previously clients. (ie. userid 5 & 7) So I think I will do a fresh server (VM) setup one of the upcoming weekends. But I will of course try to update ISPConfig tonight, to see if an update will fix something!
I have now updated to 3.1.6, which didn't seem to help. Still same scenario, where the mailboxes belongs to the previously clients and the web domains still can be managed by previously clients as well. After looking in PHPMyAdmin, I can see under the "web_domain" table that the "sys_userid" is 7 (not 2) for one of the domains, but the "document_root" have been changed to "../client_1/.." Same under "mail_user" (mailboxes), where "sys_userid" is 7. So I will try to change the userid's manually and se if that works out.
The sys_userid describes the creator of a record and not the client that owns the record. The owning client is the sys group id field.
That makes sense, actually.. Couldn't understand why the admin (id 1) owned a couple of mail_domains. But then... All the domains (web_domain) have the "sys_groupid" 2, though with different "sys_perm_groupd" (some "ru" other "riud") The ones with "ru" can be managed by previously clients.
But we probably have to add some code to change the creator e.g. to the admin or to the default user of the new client as well. The ru and riud difference does not matter for this. Records owned by admin with sys_perm_group 'ru' are locked records so that the client cannot alter settings on the first website tab on its own.
Sorry, but I don't understand anymore? First it was mentioned that it should be enough just to change it in SQL, but now some code are needed? - What code? (o: It sounds like that it would be putting too much work into this, just for a couple of domains and mailboxes? Wouldn't it just be enough to change the "sys_groupid" to 2 (my reseller) and maybe also the "sys_userid", now when the clients will be removed, or would that maybe also remove the domains and boxes? Haven't mentioned it (sorry), but it's only a home/personal server, so I (thankfully) ain't running anything important. I'm just curious and likes to see if, and how, things can be fixed.. (And help, when and where I can. - Thinking on future updates, functions, etc.) ## UPDATE: After updating, I guess... (Haven't changed anything in SQL yet.) I now can't login on any of my mail-accounts. (Not even newly created) So I think I _have_ to setup a new server tomorrow... (o: ## UPDATE: Fixed... It was just dovecot & postfix that needed to know where my SSL certificates where located... (o:
Correct, you have to just change it in sql. I did not say that you shall change code, I said that I will have to look into the code to do some changes in ISPConfig to ensure that the creator gets changed together with the owner of a record when a new owner is set. Just a guess, you probably placed them in wrong paths then. Never change the cert path, just exchange the certs! See e.g. here: https://www.howtoforge.com/securing...h-a-free-class1-ssl-certificate-from-startssl (works for any ssl authority, not just startssl) or here: https://www.howtoforge.com/communit...l-port-8080-with-lets-encrypt-free-ssl.75554/ on how to install ssl certs correctly in an update safe way.
Oh, then I misunderstood you. Sorry. Is there anything I can help with, before I switch server and removes the old one? Thanks man!! I am using Let's Encrypt, so my certs are, of course, placed in "/etc/letsencrypt/live/". Have never thought about searching for simpler solutions or creating symlinks for that, since I know where they are located. (Even that I do - from time to time - forget it and especially when updating...... (o: ) So I will definitely go through ahrasis guide, to get it automatised.
Finally! - One reseller account, and all my clients have now been removed. First, I gave everything in ISPConfig I could, to my reseller account. Then changed all the "sys_userid" "sys_groupid", "added_by" & "sys_perm_ground" for the "missing" domains, mailboxes, etc. to the right ID, username and "riud" instead of "ru". I checked if mail, ftp, etc. still worked, which it did, and then removed the clients. No problems so far! So thank you so much for the help! ## UPDATE: Okay, now after I tested some more, it didn't worked like I hoped... Some (haven't tested all) aliases/catchalls didn't work. But after reactivating it, it seems to work again.