Time Sync Error after External IP change

[kjburto]

Single server installed with vicibox express, with the following versions. Dialer worked great no problems then I had to get a new static ip addresses.

So I changed the IP address info in yast lan (External Ip, Gateway, and subnet) then ran the script "/usr/share/astguiclient/ADMIN_update_server_ip.pl" and changed the extrernip to the new static IP in /etc/asterisk/sip.conf. Rebooted the server and when I try to log into the agent screen locally with same local IP address (haven't tried testing externally yet) I get the message "There is a time synchronization problem with your system, please tell your system administrator" AND THE X-LITE phone doesn't ring like it should. Just not sure what I am missing on this. I had this problem before and had to pay to get it resolved but I'd like to figure this out on my own.

The x-lite phone is connected to the server and works if I dial directly from there not using vicidial.


Version: 2.14b0.5
SVN Version: 2893
DB Schema Version: 1532
DB Schema Update Date: 2018-01-24 19:51:33

 

[kjburto]

Also when I log into the agent page nothing happens in the asterisk CLI

 

[kjburto]

Here is my screen readout

VICI-GAJE:~ # screen -ls
There are screens on:
3343.ASTemail (Detached)
3335.ASTVDadFILL (Detached)
3333.ASTfastlog (Detached)
3331.ASTVDadapt (Detached)
2496.asterisk (Detached)
5 Sockets in /var/run/screens/S-root.

 

[williamconley]

1) You didn't post your installer with version. Often hand information.

2) Don't post responses to your own post if nobody has responded yet. Just edit the original until after you've had your first response. You answering removes your post from the "unanswered posts" listing, and some of us watch that list to try to get everyone at least one response when possible. When you "answer" your own post ... lol

3) Is your server on a private network (IP like "192.168.x.x" or "10.x.x.x") or a Public IP, or are there two network connections so it's on both?

4) Which IP was shown previously in admin->Servers and in /etc/astguiclient.conf's "this server's IP" value? And what values are shown in those two places now? If the IP shown in either of those two places is NOT the IP actually assigned to the server's network, run the ip update script again using that IP in the "old" and the server's present IP in "new". You can also run the ip update script once for any and all old IPs just for fun. As long as the "new" IP is always correct, it won't hurt anything (assuming single server, not a cluster).

5) Verify your externip change didn't violate the sip.conf file in some way (funky line break?).

 

[kjburto]

Sorry about that lol my bad

I installed off vicibox disk version 7.0.3

I am running two nic cards one external connected directly to internet modem and one internal connect to my internal network. So both connections.

admin->Servers showed my external IP address and now shows my internal address 192.168.1.8

/etc/astguiclient.conf showed my external before and still does now but now the new IP.

I just corrected a possible line break in sip.conf it moved half the description to the line below

 

[williamconley]

admin->Servers showed my external IP address and now shows my internal address 192.168.1.8

/etc/astguiclient.conf showed my external before and still does now but now the new IP.

If you ran the ip update script properly, admin->servers and astguiclient.conf would show the same IP address. Run it again with all possible "bad" IPs including your new external one and make sure the "new" ip is always your NEW Internal IP. That's the safest possible value moving forward, primarily because even if your external IP ever changes again, there's no need to modify your internal IP. So next time your public IP changes, all you'll need to change is the sip.conf valule for externip. But before worrying about "next time": All of the places that contain your IP must be changed to the same value, preferably the internal IP. This is best done with the ip update script and all possible prior IPs as "old" and the present local IP as "new". And then reboot when you've run all possible.

Note that this script shows you many of the changes it makes. You can check all those locations after and verify that they all have the present local IP, just to be sure, if the system doesn't come back online after the reboot.

 

[kjburto]

That did it!!! Thank you very much

So the only place you need to change the external IP in in yast lan and sip.conf?

 

[williamconley]

So the only place you need to change the external IP in in yast lan and sip.conf?

There is also a place in admin->servers for external web links if you access the server's admin from the public IP and listen to recordings.

There is also the recording links for audio files that have been pushed to an FTP location. A special script exists for updating those links if the URL changes. However, if you set that to a Domain name instead, then the DNS entry can change instead and you no longer need to update the URL since it has the domain name in it.

 

[kjburto]

Okay good to know. Thanks again you are a life saver. I had a feeling it would be something simple like that just couldn't figure it out.

 

[williamconley]

Now: Learn to use the backup script. Set it to run automatically at 11:45PM each night (so you are overwriting last week's until Midnight, in case of a sudden need to run the backup in the middle of the day on a dying server ... instead of overwriting the backup you ran a few hours earlier today, that way if the emergency backup fails, it won't have deleted the one that worked earlier, it'll be overwriting one from seven days ago so "borked" doesn't matter! lol) Be sure you include the FTP Transfer option so the backup set is automatically pushed to an FTP location OFF the server. Even if it's just the DB instead of "everything", that can be a life (er ... job) saver.

Also run "screen -list" and remember that this is a good thing to get used to running. Knowing if there are screens "missing" is an immediate "health of the server" thing. Knowing *which* screens are missing is even better. So having a look at those screens when the system is healthy will give you a good feel for "something's amiss" later.

 

[kjburto]

Yes absolutely I already do that type of backup on all my servers. I learned that from the Poundteam multi server pdf which I believe you had a hand in writing or wrote yourself. Great work it has taught me a lot. I have become familiar with the "screen -list" today while trying to figure out what was going wrong.