RESOLVED: Fix client0 / c0 : assign sites to new client

I know this is a FAQ but I don't see a current solution. Since I manage my own sites I didn't create a client for my own sites. I saw sites going into client0 and initially thought that was elegant. Now I think that was a mistake. I'd like to fix it.

The Migration Tool info says we cannot move sites from one client to another on the same system. OK, is there a detailed list somewhere of steps to do this?

I have experimented with creating new clients and then assigning existing sites to them in the Site page. To my pleasant surprise this does change the /clients/clientN folder, but that clientN value is incorrect. I'll create a ticket for this if there isn't one.

I'm concerned about database names, email accounts, and anything else that might still be linked to the original client ID.

Since I'm just getting started, this isn't a high priority for me right now, but It's like to know how to quickly recover from issues like this when necessary, and document the process in the new docs.

Thanks!

 

@Th0m Thanks for looking into that and asking.

The anomaly I noticed is that in the /clients/clientN/webX structure, the clientN is not "client[client_id]" or "[client_id]", etc. The N is not the incremented index used for the client ID that we see. So for example, when I set the starting ID to 1001 and the current value to 1012, the next ID will be c1013 and one might expect a path /clients/c1013/ or /clients/client1013. The N is actually the sequential index of the clients created in this installation. So if the naming scheme changes from "client1234" to "cust1234", and we change numbering so that it restarts with cust1001234, but we have really only created 30 clients in this system, and monkeyed with the visible IDs, the next folder is /clients/client31. That leaves the awkward question : who does this file set actually belong to?

LOL - as I wrote that out it occurs to me that this might be by-design, and I'm fine with that. But I think the general expectation would be that the folder name corresponds to the client ID.

Personally I don't really care what the IDs are, as long as referential integrity is maintained. I'm just trying to identify where the RI might be broken in a client change - I didn't think about cron or log files - those tickets provide some good tips. That's my point here. I don't care what the specs or bugs are - I just want to know how it works now so that I can move forward with daily maintenance. If required, I'll be happy to start a doc on this topic and update it as I get new info. As we've discussed, that's my consistent theme here.

As a side note, while experimenting with the above, I noted that the terminology is inconsistent with regard to user_id, user_name, or what those fields are with and without a prefix, etc. I'm only being vague here for brevity. I can expand somewhere else. I only cite this because this condition slowed the process of understanding how all of this stuff is working.

HTH

 

Actually - I am going through this very carefully and documenting it as I go. I appreciate that someone might volunteer insight but I request that no one do so. I'm learning a lot and I now understand how this is working. I think it's doing exactly what I would hope/want. I will post this detail soon into the new docs.

Summary for now: The /clients/clientX/webY are not related to the C00000 IDs. Every client is created with a unique internal sequential primary key, independent of the naming or numbering scheme. The same applies for every website. These are the X and Y numbers that we see. When you see /clients/client12, to know which client that is, look in the client list, first column "ID".

 

I've marked this thread as Resolved. I have a ton of new notes on this topic for the doc .
I've only found one actual bug, though there are a couple other anomalies that I'll take up elsewhere.

For anyone who wants to move a site from one client to another, this is easy! Just change the client in the Website. No migration tool is required for this operation. Database users are assigned to the new client, though appropriately, database user names and database names are not changed, which means the prefixes will be misleading until changed. FTP and Shell users are also changed to the new website path but they are not renamed. Email services are different from Websites, so you need to change the client for domain for Mail separately.

HTH

 

Ha! Yeah, in my notes I call it the accounting ID or the public ID. I'd guess that was later linked into the billing module. But to the uninitiated (waves hand) it's lack of significance isn't evident. I'm glad it was written like this. I frequently say data should not be used as a primary key anywhere because it's subject to change, despite insistence in spec/planning that some field will never change. Examples include SS#, DriverID, name, phone, duh. So I appreciate that the clientX/webY IDs are independent of user data. The Website Path itself is user-specified : /var/www/clients/client[client_id]/web[website_id], so even if they change it to something like /var/www/accounts/acct[client_id]/site[website_id] the environment shouldn't break. I haven't actually tried that bold change but it looks like it would be OK.