Can't restore configuration from backup made today
OZOi:
That's a good idea and it makes sense to look closer on provisioning service. It's based on XML file, perhaps similar to what we can create with backup facility on OBi. Unfortunately I can't find info about how to use it. I guess, @CustomATA knows how to do it, but he is not an active member here...
QBZappy:
OZOi,
Well if you look in the OBi, we can see that it may be provisioned using tftp.
ITSP Provisioning->ConfigURL = tftp://$DHCPOPT66/$DM.xml
Anyone who has flashed a router with 3rd party firmware or upgraded an ATA firmware may be familiar with this tool. I suspect that http can also be used to upload config file. I think the idea is to point the OBi to a tftp server located on your machine if you are doing it over the local lan. Encryption is not necessary doing this local. I can see this being done over wan as well simply by port forwarding to your tftp/http server. Without going into specifics, the provisioning could be accomplished via the phone touch tones or rebooting the unit if the auto provisioning is setup properly.
Quote from: CustomATA on January 06, 2012, 08:25:56 pm
It's trivially easy to figure out how. I may write up some instructions when/if I find the time.
Quote from: CustomATA on January 06, 2012, 08:25:56 pm
Quote from: RJDB on January 06, 2012, 07:15:31 pm
I interpretted "provisioning it yourself" as local provisioning via 192.168.xxx.xxx, as opposed to OBiTalk.com.
I'm referring to auto-provisioning via "System Management -> Auto Provisioning -> ITSP Provisioning -> ConfigURL".
CustomATA gives us some clues of where to start. He also mentions that it is easy. Self provisioning, once perfected and documented properly can help those that are managing far away units.
How to auto-provision IP phones with DHCP ‘option 66:
http://www.3cx.com/sip-phones/DHCP-option-66/
The sub links are intersting
You will need this:
TFTP Server:
http://tftpd32.jounin.net/
Step 1 prepare your XML file (including passwords)
Step 2 follow the guide instructions. (The guide is better than anything that I could ever write)
If you try, let us know the results. You realize that others will be following this thread.
OZOi:
Well, I've set up local TFTP server and put into its folder backup file, made earlier from current configuration. Then I've set System Management | Auto Provisioning | ITSP Provisioning | ConfigURL value, pointing to that file: (here is example) tftp://host.tld/OBi.xml.
Result of the test is - manually putting passwords into configuration file works well, if file is downloaded from TFTP server, and it doesn't work at all, if the same file is uploaded with web browser...
Again, it's possible to use ITSP Provisioning feature, but it adds extra hassle. First, you have to set op TFTP server. Then you have to move backup files into its folder. Then, if you want to keep some configuration, you have not to forget and manually edit that file, and particularly, its internal ConfigURL value to point to itself. If you don't do that carefully, you may get the old configuration back, when you don't need it anymore...
I think we have to ask OBi developers for a help here. We need an option (presumably in Backup Configuration section), that will allow users to save/keep/restore AuthPassword values in backup configuration files, in case if we need it. That would really help to avoid unnecessary reboots of OBi device, when we change / restore its configuration from local XML files. A warning box, telling that passwords will be saved inside backup file, could benefit the backup process too... Current implementation of this feature in OBi devices creates unnecessary problems for uses who don't need them.
QBZappy:
OZOi,
Glad to hear that it worked.
Quote from: OZOi on March 01, 2013, 02:32:51 pm
I think we have to ask OBi developers for a help here. We need an option (presumably in Backup Configuration section), that will allow users to save/keep/restore AuthPassword values in backup configuration files, in case if we need it. That would really help to avoid unnecessary reboots of OBi device, when we change / restore its configuration from local XML files. A warning box, telling that passwords will be saved inside backup file, could benefit the backup process too... Current implementation of this feature in OBi devices creates unnecessary problems for uses who don't need them.
I don't see any problem with this request if the exercise is to be performed on the lan or over the wan if you understand the consequences if you don't use some form of encryption. However I can see the problem from obihai's point of view as well. Consider that their OBiTALK 'provisioning' portal will be used to upload configs, including passwords. I'm certain their lawyers would prefer not to touch that issue with a ten foot pole. That could make them guilty by association, by providing the tools which permit cracking the OBi passwords while connected to their servers. As useful as it may be for users, they probably have no interest in making their servers available for this.
I can think of at least two examples which show us that they prefer to err on the side of safety/security. The first is the approach in addressing passwords in the XML bkup file which we are currently discussing, the other which come to mind is the wan port lock they have installed. We can not view the local unit web page using wan port without punching in some numbers on the attached phone to unlock the web browser.
The real value of this discussion is to document a way to push configs to OBi units local and even remotely. This method is more efficient, and under admin control without any of the limitations of the OBiTALK portal.
OZOi:
1. I'd not worry about any layer. Period. They will never be "guilty by association", ever. I'm talking from my experience... And BTW, they don't waste their own time, waiting for double reboots and entering passwords. I do.
2. As I mentioned earlier, when user submits password to OBi device using web browser, the password is sent in plain text. Why I can not to do the same (send passwords) when I'm uploading configuration file? What is the difference?
3. TFTP provisioning allows uploading XML configuration files with passwords. Why I can't do the same with uploading the very same XML configuration file using web browser? What it the difference?
4. I know what I'm doing. I know why I'm doing it. And I need to do it this way. It's because it makes my work faster and easier. I don't want to double the number of OBi reboots, while entering passwords in the middle every time I change configuration. How should I express my desire more clearly than that?
5. And finally, if developers don't want to see passwords in plain text in XML configuration file (I personally don't mind it at all, but let's assume that they don't), they can hash them. And BTW, they should hash them the same way when user sends submit request too. That will make Obi a bit more secure. Not a speculation about some fictitious layer's liability.
Navigation
[0] Message Index
[#] Next page
[*] Previous page