Koozali.org: home of the SME Server

Upgrading to 3.1 from 2.6.1-3

Offline compsos

  • *
  • 472
  • +0/-0
Re: Upgrading to 3.1 from 2.6.1-3
« Reply #15 on: September 30, 2010, 11:51:48 PM »
Thanks Jeff
Glad it has helped.

I had deleted the SOS references from the web page and when that did not appear to work removed the entries manually (not in the copy you had) which still did not work. Just in case any one else has to remove them manually what should the outcome be in the modified file
  • Leave the pipes | with no space
  • Leave the pipes | with a space in between
  • remove the pipes and the data
(ie)
If we manually remove the "|openAH|NO|" should it be completely removed or left as "|||" or "| | |"?
Regards

Gordon............

Offline SARK devs

  • *****
  • 2,806
  • +1/-0
    • http://sarkpbx.com
Re: Upgrading to 3.1 from 2.6.1-3
« Reply #16 on: October 01, 2010, 03:00:20 PM »
It should be completely removed...

"|openAH|NO|"   =    ""

If you don't remove the pipes, smeserver DB will see it as a variable with a null keyname and null data (which messes it up).

Best

Jeff

Offline SARK devs

  • *****
  • 2,806
  • +1/-0
    • http://sarkpbx.com
Re: Upgrading to 3.1 from 2.6.1-3
« Reply #17 on: October 01, 2010, 11:41:34 PM »
Hi Gordon

The device update problem you reported has been fixed in 3.1.0-57.   You can get it from the download site.  Be aware that -57 and later releases need an additional environment rpm if you are installing them onto SME server.  The module is called smesailenv and it is also available for download.  Install it after you've installed sail.

Kind Regards

Jeff

   

Offline compsos

  • *
  • 472
  • +0/-0
Re: Upgrading to 3.1 from 2.6.1-3
« Reply #18 on: October 06, 2010, 11:09:02 AM »
Thanks Jeff

Pulled all the COS references out and the tail of the file had this strange line that caused it to choke
Code: [Select]
|active|YES|defaultclosed|YES|defaultopen|NO|dialplan||zzeor|EOR=.
Removed that and it all then ran as expected. As for the COS code should there be a procedure in a running 2.6 version to remove the entries? I removed the definitions but maybe the settings against an extension should be removed first and then the definitions? As for the last line it maybe the result of the evolution process to get here.

Looking at the working selintra-work file it has quite a few "||" entries. Not sure what generated them. Original thought was the blank lines etc.

I had made the mistake of leaving 3.1 running on the VM (just a private server on the LAN with no DHCP) and was surprised when I had phone troubles on the live system. It was tracked back to the VM had registered to the IST ahead of the real server. No problem just shut it down but was surprised at that it could even do that!!!

Next step to try it  on on a standalone system with no interference. I assume we just need to transfer the db files that have been created to the new system?

G

Regards

Gordon............

Offline SARK devs

  • *****
  • 2,806
  • +1/-0
    • http://sarkpbx.com
Re: Upgrading to 3.1 from 2.6.1-3
« Reply #19 on: October 06, 2010, 03:04:10 PM »
Quote
|active|YES|defaultclosed|YES|defaultopen|NO|dialplan||zzeor|EOR=

Yes - that looks wrong.  Best to remove methinks.

Re autoremoval of COS entries - I think we may have looked at this and put it in the "too hard drawer" :).   We can look at it again tho'

|| is OK if it is a data field but a nono if it is a variable name.

Quote
I assume we just need to transfer the db files

Yup - there is only one file - /opt/sark/db/sark.db.  That's one of the reasons we chose SQLite.  Aside from being very rapid on small datasets, it's extremely portable and easy to backup.

Kind Regards

Jeff

   

Offline compsos

  • *
  • 472
  • +0/-0
Re: Upgrading to 3.1 from 2.6.1-3
« Reply #20 on: October 07, 2010, 12:04:44 AM »
If it is going to be hard for the script to remove unwanted entries in the selintra-work file then we will need to be able to identify what is a variable position or data. How does the script know it is handling a pair (variable tag + data)? I do not see this as a problem on a small system provided the tech knows what to delete and what to leave. But larger systems would be painful to edit the file or rebuild the new system from scratch.

Quote
|| is OK if it is a data field but a nono if it is a variable name.

Is there anything we can do to help? Test run conversions?

Regards

Gordon............

Offline SARK devs

  • *****
  • 2,806
  • +1/-0
    • http://sarkpbx.com
Re: Upgrading to 3.1 from 2.6.1-3
« Reply #21 on: October 07, 2010, 02:00:23 PM »

Good questions...

We have tested on a lot of different inputs and yours is the first that gave us issues.  Our main tester is based upon a customer with about 300 phones and it whistles through without a murmer. 

In the latest update of the insert code, we've included a test for null variable names.  If they are found, we simply skip them (since there is probabaly nothiing to be done with them anyway). 

It would help if you could run your original data through it to see what it makes of it. - it's in the -59 release (make sure you install the new smesailenv rpm with -59).

Kind Regards

Jeff

 


 

Offline compsos

  • *
  • 472
  • +0/-0
Re: Upgrading to 3.1 from 2.6.1-3
« Reply #22 on: October 08, 2010, 12:01:42 AM »
Jeff

sail-3.1.0-59
smesailenv-1.0.0-8
current working selintra-work file from sail-2.6.1-4 with no COS defined or showing in extensions

The 1st run failed on that last line in the file

Code: [Select]
SQLiteGet is running SELECT pkey FROM  where pkey = '|active|YES|defaultclosed|YES|defaultopen|NO|dialplan||zzeor|EOR'
DBD::SQLite::db prepare failed: near "where": syntax error(1) at dbdimp.c line 271 at /opt/sark/perl/modules/sark/SarkSubs.pm line 1097.
DBD::SQLite::db prepare failed: near "where": syntax error(1) at dbdimp.c line 271 at /opt/sark/perl/modules/sark/SarkSubs.pm line 1097.
Issuing rollback() for database handle being DESTROY'd without explicit disconnect().

Removed the line and all appears to work

Code: [Select]
SQLiteGet is running SELECT pkey FROM lineIO where pkey = ''
SQLiteGet is running SELECT pkey FROM Queue where pkey = ''
SQLiteGet is running SELECT pkey FROM ivrmenu where pkey = ''
SQLiteGet is running SELECT pkey FROM Appl where pkey = ''
SQLiteGet is running SELECT pkey FROM lineIO where pkey = ''
SQLiteGet is running SELECT pkey FROM Queue where pkey = ''
SQLiteGet is running SELECT pkey FROM ivrmenu where pkey = ''
SQLiteGet is running SELECT pkey FROM Appl where pkey = ''
SQLiteGet is running SELECT pkey FROM Carrier where pkey = 'DAHDIGroup'
SQLiteGet is running SELECT pkey FROM lineIO where pkey = 'DAHDIGroup0'
SQLiteGet is running SELECT pkey FROM Route where pkey = 'inter1'
KEY inter1 ALREADY EXISTS - SKIPPED
SQLiteGet is running SELECT pkey FROM Greeting where pkey = 'usergreeting3002'
KEY usergreeting3002 ALREADY EXISTS - SKIPPED
SQLiteGet is running SELECT pkey FROM IPphone where pkey = '5002'
SQLiteGet is running SELECT pkey FROM Route where pkey = 'wdp1'
KEY wdp1 ALREADY EXISTS - SKIPPED
SQLiteGet is running SELECT pkey FROM Carrier where pkey = 'WDP'
translated carrier WDP to GeneralSIP
SQLiteGet is running SELECT pkey FROM lineIO where pkey = '61740840650'
KEY 61740840650 ALREADY EXISTS - SKIPPED
SQLiteGet is running SELECT pkey FROM Carrier where pkey = 'AnalogFXO'
SQLiteGet is running SELECT pkey FROM lineIO where pkey = 'DAHDI1-1'
SQLiteGet is running SELECT pkey FROM Greeting where pkey = 'usergreeting3005'
KEY usergreeting3005 ALREADY EXISTS - SKIPPED
SQLiteGet is running SELECT pkey FROM Carrier where pkey = 'WDP'
translated carrier WDP to GeneralSIP
SQLiteGet is running SELECT pkey FROM lineIO where pkey = '61731236912'
KEY 61731236912 ALREADY EXISTS - SKIPPED
SQLiteGet is running SELECT pkey FROM lineIO where pkey = ''
SQLiteGet is running SELECT pkey FROM Queue where pkey = ''
SQLiteGet is running SELECT pkey FROM ivrmenu where pkey = ''
SQLiteGet is running SELECT pkey FROM Appl where pkey = ''
SQLiteGet is running SELECT pkey FROM lineIO where pkey = ''
SQLiteGet is running SELECT pkey FROM Queue where pkey = ''
SQLiteGet is running SELECT pkey FROM ivrmenu where pkey = ''
SQLiteGet is running SELECT pkey FROM Appl where pkey = ''
SQLiteGet is running SELECT pkey FROM Carrier where pkey = 'DAHDIGroup'
SQLiteGet is running SELECT pkey FROM lineIO where pkey = 'DAHDIGroup5'
SQLiteGet is running SELECT pkey FROM IPphone where pkey = '2000'
KEY 2000 ALREADY EXISTS - SKIPPED
SQLiteGet is running SELECT pkey FROM speed where pkey = '04'
KEY 04 ALREADY EXISTS - SKIPPED
SQLiteGet is running SELECT pkey FROM lineIO where pkey = 'SOS'
SQLiteGet is running SELECT pkey FROM Queue where pkey = 'SOS'
SQLiteGet is running SELECT pkey FROM ivrmenu where pkey = 'SOS'
SQLiteGet is running SELECT pkey FROM ivrmenu where pkey = 'Home'
KEY Home ALREADY EXISTS - SKIPPED
SQLiteGet is running SELECT pkey FROM dateSeg where pkey = 'dateSeg360407'
KEY dateSeg360407 ALREADY EXISTS - SKIPPED
SQLiteGet is running SELECT pkey FROM Appl where pkey = 'hotdesk'
KEY hotdesk ALREADY EXISTS - SKIPPED
SQLiteGet is running SELECT pkey FROM Carrier where pkey = 'AnalogFXO'
SQLiteGet is running SELECT pkey FROM lineIO where pkey = 'DAHDI2-1'
SQLiteGet is running SELECT pkey FROM dateSeg where pkey = 'dateSeg930072'
KEY dateSeg930072 ALREADY EXISTS - SKIPPED
SQLiteGet is running SELECT pkey FROM IPphone where pkey = '5000'
KEY 5000 ALREADY EXISTS - SKIPPED
SQLiteGet is running SELECT pkey FROM Greeting where pkey = 'usergreeting3010'
KEY usergreeting3010 ALREADY EXISTS - SKIPPED
SQLiteGet is running SELECT pkey FROM Queue where pkey = 'office'
KEY office ALREADY EXISTS - SKIPPED
SQLiteGet is running SELECT pkey FROM Appl where pkey = 'enter_extension'
KEY enter_extension ALREADY EXISTS - SKIPPED
SQLiteGet is running SELECT pkey FROM dateSeg where pkey = 'dateSeg410315'
KEY dateSeg410315 ALREADY EXISTS - SKIPPED
SQLiteGet is running SELECT pkey FROM speed where pkey = '03'
KEY 03 ALREADY EXISTS - SKIPPED
SQLiteGet is running SELECT pkey FROM Route where pkey = 'faxes'
KEY faxes ALREADY EXISTS - SKIPPED
SQLiteGet is running SELECT pkey FROM lineIO where pkey = 'Repeat Message'
SQLiteGet is running SELECT pkey FROM Queue where pkey = 'Repeat Message'
SQLiteGet is running SELECT pkey FROM ivrmenu where pkey = 'Repeat Message'
SQLiteGet is running SELECT pkey FROM Appl where pkey = 'Repeat Message'
SQLiteGet is running SELECT pkey FROM ivrmenu where pkey = 'Fwd_calls'
KEY Fwd_calls ALREADY EXISTS - SKIPPED
SQLiteGet is running SELECT pkey FROM Agent where pkey = '1001'
KEY 1001 ALREADY EXISTS - SKIPPED
SQLiteGet is running SELECT pkey FROM Greeting where pkey = 'usergreeting3001'
KEY usergreeting3001 ALREADY EXISTS - SKIPPED
SQLiteGet is running SELECT pkey FROM speed where pkey = '00'
KEY 00 ALREADY EXISTS - SKIPPED
SQLiteGet is running SELECT pkey FROM lineIO where pkey = 'enter_extension'
SQLiteGet is running SELECT pkey FROM Queue where pkey = 'enter_extension'
SQLiteGet is running SELECT pkey FROM ivrmenu where pkey = 'enter_extension'
SQLiteGet is running SELECT pkey FROM Appl where pkey = 'enter_extension'
SQLiteGet is running SELECT pkey FROM ivrmenu where pkey = 'SOS'
KEY SOS ALREADY EXISTS - SKIPPED
SQLiteGet is running SELECT pkey FROM Carrier where pkey = 'PTT_DiD_Group'
SQLiteGet is running SELECT pkey FROM lineIO where pkey = '0740840650'
KEY 0740840650 ALREADY EXISTS - SKIPPED
SQLiteGet is running SELECT pkey FROM IPphone where pkey = '5003'
SQLiteGet is running SELECT pkey FROM IPphone where pkey = '5001'
KEY 5001 ALREADY EXISTS - SKIPPED
SQLiteGet is running SELECT pkey FROM Carrier where pkey = 'ATP'
translated carrier ATP to GeneralIAX2
SQLiteGet is running SELECT pkey FROM lineIO where pkey = 'atp'
KEY atp ALREADY EXISTS - SKIPPED

Still no idea where that line is coming from but it does not appear to affect 2.6.1-4. The output is from line 1096 of the SarkSubs.pm, maybe it might be worthwhile sending this output to a log in case of issues?
Regards

Gordon............

Offline SARK devs

  • *****
  • 2,806
  • +1/-0
    • http://sarkpbx.com
Re: Upgrading to 3.1 from 2.6.1-3
« Reply #23 on: October 08, 2010, 04:50:29 PM »
That looks a lot better than it did.

I'll take a look at what we can log and how we can bypass that failure so we at least complete what we can.   I don't want to put in permanent logging but we may be able to make it switchable.

thanks for your help Gordon.

Jeff

Offline compsos

  • *
  • 472
  • +0/-0
Re: Upgrading to 3.1 from 2.6.1-3
« Reply #24 on: October 17, 2010, 09:45:55 AM »
Hi Jeff
Have loaded the dbs file on a system with a TDM422 card. Just a couple of points that I have found so far
  • The new system appears top have a restriction to 3 digit extension numbers. I would imaging older sail systems would be on the original default of 4. In the "Global Settings" the setting is locked. No worries just kill the defined extension and recreate with 3. After fixing other points below on a Yealink TP26p the phone on *50* goes to "Commelin Mail". But if you wait 13secs it then just asks for the password and works. The console shows the system looking for the 4 digit number.
Code: [Select]
EXEC VoiceMailMain 5001
    The cfg files are all 3 digit references. *51* behaves as expected.[/li]
       
  • The descriptor file for Yealink General needs to have the name of "y000000000004.cfg" for a TP26p phone. Note the number of zeros is important for it to work.
  • References in the descriptor file to $ext, $password or $localip do not translate to the y000000000004.cfg file. I will try recombining the descriptor file into the device SIP definition page 2 and see if that allows what we had in ver 2.6. In the combined definition all variables work through to the tftpboot files. But now the  extension screen says the new defined extension is registered , which can not be true as the phone has the previous password and has not been rebooted. the combined file duplicates the "y000000000004.cfg" data into the $mac.cfg and also builds a "y000000000004.cfg" file.
  • Clicking on the connection status in the Extensions screen works to the 1st tab of a phone with a tabbed interface. All other tabs show "The requested URL /cgi-bin/ConfigManApp.com was not found on this server." Aastra web page is OK.
  • In the extensions panel no listing of Dahdi FXS ports, So incoming calls to analogue phones do not get switched. Out going work fine.
  • Trunks panel shows sip registrations as not registered (End-point is off line) but console show registrations active and do work.
It is looking good. Is it planned to have the CDR database and the FOP back in the web Console?

Unfortunately I am going to have to reset this system back to ver 2.6, but I hope these observations help.

Your thoughts?
Regards

Gordon............

Offline SARK devs

  • *****
  • 2,806
  • +1/-0
    • http://sarkpbx.com
Re: Upgrading to 3.1 from 2.6.1-3
« Reply #25 on: October 17, 2010, 09:42:35 PM »
HI Gordon

Thanks for the input - it is very much appreciated.

Quote
The new system appears top have a restriction to 3 digit extension numbers.

It doesn't, but I think I know what has happened.  You can only change the extension length when there are no extensions defined (this is to prevent mixed length extensions).   However, it initially sets the database to extension length 3.  So if you then import a database with extension length 4 you end up with a problem (as you did).  The trick is, I think, to set extension length before you do the import and before you create any extensions.  I will make a note in the Wiki.

I'm not sure I fully understand what you are telling me with the mailbox.  *51* will always work the way you describe...  i.e. it will give you the opportunity to enter a mailbox(extension) but then, if you enter nothing, it will default to asking for a password for the CLID you called on.  Do you have a log I can see?

Re the Yealinks...  We've only ever published a descriptor with the name y000000000000.cfg.   This seems to work for the Yealinks we have here.  I am unsure what the significance of a y000000000004.cfg file might be, but you can of course add one in yourself (or have I missed something here?).

Proxy to Yealink.  The Yealink HTTP code uses odd relative referencing which won't work through the proxy (never has).  It is the only popular phone type we can't proxy to.

$localip not substituted in Descriptors - traced to a bug in the generator.  Fixed in -r1449 (3.1.0-60). - Good spot! However, $password and $ext won't work in Descriptors because they don't make grammatical sense in a descriptor, which is by its very nature global.
 

DAHDI FXS Ports.  What hardware are you using and which SAIL release is it?   FXS looks to work on the reference system here and generates the correct entries for a standard Digium TDM400 with FXS ports.  It parses the generated Digium code in dahdi_channels.   I'll run some more tests on it.


Kind regards and thanks

Jeff

Offline compsos

  • *
  • 472
  • +0/-0
Re: Upgrading to 3.1 from 2.6.1-3
« Reply #26 on: October 18, 2010, 12:30:22 AM »
Hi Jeff

Mailbox:
I was dialling *50* and got the prompt for which mailbox. (ie) the same as if I dialled *51*. The code snippet shows what was requested was 5001 and not 501. Maybe this is related to the ext length confusion with an converted/imported DB. Some part of the system still new the phone as 5001 even though I had trashed it and recreated a few times. So maybe the trash operation left something behind?
Quote
EXEC VoiceMailMain 5001

Name of y file:
According to Yealink different model phones use slightly different "y" files in name only. From yealink pdf file http://www.yealink.com/download/manual/How%20to%20Config%20Yealink%20Phones%20for%203CX%20System.pdf
Quote
For T28, name the CFG file by y000000000000.cfg and put it to TFTP server
For T26, name the CFG file by y000000000004.cfg and put it to TFTP server
For T22, name the CFG file by y000000000005.cfg and put it to TFTP server
For T20, name the CFG file by y000000000007.cfg and put it to TFTP server
It is the name the phone asks for during provisioning. I have not seen any documentation if or how it could be changed in the phone. But as you said we can all create our own. As long as it is known.

Variables:
$ext might be helpfull in a descriptor (ie) to set a behaviour that is phone specific but to applied to all phones the same way. I used it in the past to set the users password to the phones web page for adjustments that are not critical. $password would not make sense.

Dahdi:
This is an interesting one as it works perfectly in 2.6-7 as expected. In 3.1.59 FXO listed fine in Trunks but no FXS ports in Extensions. In the PCI devices all ports were listed. Note no change was made on this system in versions of dahdi or asterisk only sail to sark.
system messages log
Code: [Select]
Oct 17 14:32:46 server-sos kernel: Module 0: Installed -- AUTO FXO (FCC mode)
Oct 17 14:32:46 server kernel: Module 1: Installed -- AUTO FXO (FCC mode)
Oct 17 14:32:47 server kernel: Module 2: Installed -- AUTO FXS/DPO
Oct 17 14:32:48 server kernel: Module 3: Installed -- AUTO FXS/DPO
Oct 17 14:32:48 server kernel: Found a Wildcard TDM: Wildcard TDM400P REV I (4 modules)
Oct 17 14:32:48 server kernel: dahdi_transcode: Loaded.
Oct 17 14:32:48 server kernel: INFO-xpp: revision Unknown MAX_XPDS=64 (8*
Oct 17 14:32:48 server kernel: INFO-xpp: FEATURE: without BRISTUFF support
Oct 17 14:32:48 server kernel: INFO-xpp: FEATURE: with PROTOCOL_DEBUG
Oct 17 14:32:48 server kernel: INFO-xpp: FEATURE: with sync_tick() from DAHDI
Oct 17 14:32:48 server kernel: INFO-xpp_usb: revision Unknown
Oct 17 14:32:48 server kernel: usbcore: registered new driver xpp_usb
Oct 17 14:32:48 server kernel: dahdi: Registered tone zone 0 (United States / North America)
Oct 17 14:32:48 server kernel: dahdi_echocan_mg2: Registered echo canceler 'MG2'
Oct 17 14:32:48 server kernel: dahdi: Registered tone zone 1 (Australia)
As this is the only TDM422 card that I have available the system has had to go back to 2.6-7. So no more details other than what I can find in the logs. the asterisk messages log file is empty, so no help there. The only change in the system was from sail to sark and any extension tweeks to test it. Regenerating the Card made no difference. The DB was built on a system (sandpit) without a TDM card. The extension add routine had no listing of Dahdi channel devices only VOIP. Still curious about the Extensions screen showing extensions as being registered when not and not when the console said they were. Refresh lag issue?

Jeff do you have a test routine? When I next get a chance to test sark might be able to get more helpful data.
G
Regards

Gordon............