Cisco SPA2102-AU Provisioning Guide - Page 39

post, alias, openssl, ascii-key, hex-key - access

Page 39 highlights

Chapter 2 Creating Provisioning Scripts Proprietary Plain-Text Configuration File Some usage examples: [--key VerySecretValue] [--key "my secret phrase"] [--key a37d2fb9055c1d04883a0745eb0917a4] The bracketed optional arguments are macro expanded. In particular, note that the special purpose parameters GPP_SA through GPP_SD are only macro expanded into their macro variables $SA through $SD when used as arguments of the key option, as in the following examples: [--key $SC] [--key "$SD"] In the case of XML-style profiles, the argument to --key must be the same as the argument to the -k option given to openssl. In the case of SPC compiled profiles, the argument to --key must be the same as the argument to either the --ascii-key or the --hex-key options, as given to SPC. post The post option provides an alternative access method for the http and https schemes. If left unspecified, the SPA performs an HTTP GET operation, when contacting the provisioning server. If specified, on the other hand, the SPA performs an HTTP POST operation. The body of the POST is generated from the contents of one of the general purpose parameters, GPP_A through GPP_P, with macro expansion applied. The GPP_* parameter to use is indicated by a single lowercase letter (a through p) given as argument to the term --post. Using POST provides a convenient alternative to the GET method when arbitrary state or identifying information needs to be supplied from the SPA to the server, as part of periodic resyncs. For example, GPP_F could contain the following POST body template: Product = "$PN"; MAC_Addr = "$MA"; Ser_Num = "$SN"; SW_Ver = "$SWVER"; Then, a URL option such as the following would use the POST method to convey the information to the server in the body of the profile request message (shown here with an accompanying URL): [--post f ] http://ps.one.com/cpe/resyncs? alias The alias option provides a flexible means of recognizing alternative parameter names in XML-based configuration profiles. This is useful in cases where part of the configuration profile is obtained from a customer database form that uses different terminology than expected by the SPA. For example, a customer XML profile specifies the SIP registration parameters: name, number, auth-secret, enclosed in an XML element hierarchy as follows: J. Smith 14085551234 732091751563sfd Version 3.0 Linksys SPA Provisioning Guide 2-13

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  • 32
  • 33
  • 34
  • 35
  • 36
  • 37
  • 38
  • 39
  • 40
  • 41
  • 42
  • 43
  • 44
  • 45
  • 46
  • 47
  • 48
  • 49
  • 50
  • 51
  • 52
  • 53
  • 54
  • 55
  • 56
  • 57
  • 58
  • 59
  • 60
  • 61
  • 62
  • 63
  • 64
  • 65
  • 66
  • 67
  • 68
  • 69
  • 70
  • 71
  • 72
  • 73
  • 74
  • 75
  • 76
  • 77
  • 78
  • 79
  • 80
  • 81
  • 82
  • 83
  • 84
  • 85
  • 86
  • 87
  • 88
  • 89
  • 90
  • 91
  • 92
  • 93
  • 94

2-13
Linksys SPA Provisioning Guide
Version 3.0
Chapter 2
Creating Provisioning Scripts
Proprietary Plain-Text Configuration File
Some usage examples:
[--key VerySecretValue]
[--key “my secret phrase”]
[--key a37d2fb9055c1d04883a0745eb0917a4]
The bracketed optional arguments are macro expanded. In particular, note that the special purpose
parameters GPP_SA through GPP_SD are only macro expanded into their macro variables $SA through
$SD when used as arguments of the key option, as in the following examples:
[--key $SC]
[--key “$SD”]
In the case of XML-style profiles, the argument to
--key
must be the same as the argument to the
-k
option given to
openssl
.
In the case of SPC compiled profiles, the argument to
--key
must be the same as the argument to either
the
--ascii-key
or the
--hex-key
options, as given to SPC.
post
The
post
option provides an alternative access method for the http and https schemes. If left unspecified,
the SPA performs an HTTP GET operation, when contacting the provisioning server. If specified, on the
other hand, the SPA performs an HTTP POST operation.
The body of the POST is generated from the contents of one of the general purpose parameters, GPP_A
through GPP_P, with macro expansion applied. The GPP_* parameter to use is indicated by a single
lowercase letter (a through p) given as argument to the term
--post
.
Using POST provides a convenient alternative to the GET method when arbitrary state or identifying
information needs to be supplied from the SPA to the server, as part of periodic resyncs.
For example, GPP_F could contain the following POST body template:
Product = “$PN”; MAC_Addr = “$MA”; Ser_Num = “$SN”; SW_Ver = “$SWVER”;
Then, a URL option such as the following would use the POST method to convey the information to the
server in the body of the profile request message (shown here with an accompanying URL):
alias
The
alias
option provides a flexible means of recognizing alternative parameter names in XML-based
configuration profiles. This is useful in cases where part of the configuration profile is obtained from a
customer database form that uses different terminology than expected by the SPA.
For example, a customer XML profile specifies the SIP registration parameters: name, number,
auth-secret, enclosed in an XML element hierarchy as follows:
<CPE>
<SIP-Credentials>
<name>J. Smith</name>
<number>14085551234</number>
<auth-secret>732091751563sfd</auth-secret>
<SIP-Credentials>
</CPE>