Did you ever get your answer?
Of course, I can run the
vicibox-install --debug on each server I want to move - but - as you stated, if I can just manually add the server record to the new cluster, delete it from the old one and edit the astguiclient.conf file on the server being moved - that seems like it would take a lot less time. Of course, there are concerns outside of this - like ensuring that each server allows the others to talk to it - "yast firewall" or iptables stuff - which - some of that editing will be avoided by NOT using the vicibox-install method (since it always re-asserts the TCP/UDP ports it wants to allow) - but - other than what you already mentioned - I would love a "definitive" answer as to how to do the move. After doing a little research, here is my best guess - which is almost entirely based on the Multi-Server Installation manual that poundteam (thank you, Mr. Conley, et al) has available for download from their website [url](
http://www.poundteam.com/downloads/Vici ... Latest.pdf)[/url] - it appears that it may have been written prior to vicibox-install existing...it gives you a method to (manually) take pre-existing / previously installed servers, and create a cluster out of them - and there ARE additional steps required to fully integrate a server into a cluster. In addition to just adding it to the servers table and editing the astguiclient.conf file, I think you need to check / perform the following additional items (not necessarily in order - but - I think the firewall should probably be first):
> Make sure the server being moved and the cluster it's moving to like each other's IP addresses.
> NTP - make sure the server is syncing with the "master" time server in it's new cluster.
> Check / edit the keepalives - make sure to check that you have the minimum on the server you are moving - AND - that you're not stepping on any "one server only" keep alive tasks.
> Confirm / create necessary conferences and phones for the server you are moving into the cluster.
> Confirm that the "cron" user on the DB/mysql server in the cluster you are moving the server to will work for new server's IP (unless you're allowing cron to login from ANYWHERE - which I don't recommend, since someone from a white-listed location could use a MySQL workbench to login as cron/1234 and SELECT * from your vicidial_list and other tables. For this reason, the only IP addresses I allow cron to login from are those of any vicidial server in that cluster - I don't do the "%" thing).
> carrier entries for the moved servers (this isn't handled by vicibox-install - but - still needs to be done for telephony servers)
I think that might do it - so - considering the above - I think that the
vicibox-install method of moving a server is easier - certainly less risky - especially if you're moving it from a cluster based on a different SVN/db schema...but - I would love to hear anyone else's opinion, what I missed / forgot, etc...thanks!
David