Hello Tony, Thanks for the detail, I'll try it out later today. I think your idea as to the ISO install / NTP is right on. Is there a change of procedure in the works that would make this issue go away? I can see how it may be a little cyclical problem to fix this. It seems to be a bit of a usability issue to ask the user to input in a time value that will always show a differential when compared to a more accurate source. Is it possible somehow to ask for the date and timezone when the installer has specified NTP server and then show a short sentence later in the interface indicating that the installer has specified NTP and SipX will take care of certificate generation based upon the values coming back from the time source?
The good thing I see in SipX is that the team seems to be more than a little concerned about usability than many packages out there. Josh Tony Graziano wrote: > Use DNS local to the server "just" to keep the server happy. Once you > have done that, go into GENERAL>DOMAIN and add the IP address of the > system as an alias. If preferred phones/ua's can register via the IP > instead of DNS. Gateways would not necessarily care, but lots of > gateways are "picky" sometimes. > > You may want to wait for others to provide feedback or guidance on > what I would suggest here as it could (doubtful) have a negative impact: > > As for certificates, just get your time working the way you want > it. The issue that you were referred to with time was simply a > "cosmetic" issue when sythetic time was issued by the system before > writing the config and certificate. To get around this you can make > sure your time is correct and re-issue the certificate with: > > /usr/bin/ssl-cert/gen-ssl-keys.sh > > Quoted from Scott lawrence: "the script will generate new keys - it > will prompt you for all the information that's needed. There are more > detailed instructions on your system in /usr/share/doc/sipx/INSTALL.ssl" > > At the end of the script it displays the command to "install' the > keys. Once you do that, it migth be wise to restart services so that > the system uses the keys. > I had the opportunity to do an install of 3.10.2 from the Centos 5 > ISO, and I noticed the certificate started 4 or 5 hours "later" then > the system time. Probably because timesync was not really active prior > to running the install script which generated and installed the keys. > > Tony > > >>> Online Systems <[EMAIL PROTECTED]> 7/28/2008 12:27:43 PM >>> > Hello, > > Thanks everyone for your help. I have a few followup questions. > > So the recommended setup in my case is to enable the DNS service on the > SipX server at install and then use the format sipx.myfqdn.com to avoid > issues that may crop up in the future? Since SipX isn't designed to work > in a pure IP scenario implementing this is the insurance policy? > > Is it also advisable to enable NTP server at install but when it asks > you for the time simply back off the time a bit (ex. when its really > 9:00AM set the time manually on install to 8:55 AM) so the certificate > is valid timewise when the server reboots and synchronizes with the time > source? > > > Josh > _______________________________________________ > sipx-users mailing list > [email protected] > List Archive: http://list.sipfoundry.org/archive/sipx-users > Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users _______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users
