Posts in Category "SSL"

SSL Configuration Checklist for Connect with AEM-based Events

This supplemental checklist alongside the  Adobe Connect installation guide and the SSL Configuration guide, will help expedite your SSL implementation of Connect with AEM-Events:

1. Always begin with a fully functional installation of Connect and AEM-based Events before adding SSL; Do not attempt to secure a server that is not fully tested to run all features without SSL: A server running all features in the clear with no problems manifested is the only place to begin.

2. Decide whether to use hardware-based or software-based SSL and obtain appropriate public certificates and FQDN’s. If needed, see Mohit’s excellent instructions to generate CSRs. If you are using software-based SSL, stunnel can either be installed locally or on a separate server. If you are using hardware-based SSL you will want to refer to the relevant third-party documentation along with that provided by Adobe. For F5 BIG-IP LTM, the following articles along with this blog article and the resources aforementioned will help:

For information about stunnel installation options with Connect 9, see Jim’s blog post on Adobe Connect 9.0.0.1 and 9.1 stunnel installation options. Within the 9.0.0.1 installation folder, under  \Adobe Connect 9.0.0.1\Adobe Connect\Merge_Modules, we provide the installer for  stunnel-4.53.  From there, you can install Stunnel 4.53 for your SSL deployment. Adobe QE has tested stunnel version 4.56 collocated with Connect – installed within the Connect installation directory. These days it is arguably prudent to use the latest security option tested. Depending on the version of Connect you are running, if you wish to use stunnel locally, then you would create and/or populate the stunnel directory under the root install directory: Connect\9.1.2\stunnel.

Click on this thumbnail diagram below to see what it would look like with a hardware-based SSL accelerator:

C9SSLAEMSingle

Click on this thumbnail diagram below to see what it would look like with stunnel collocated with Connect:

C9SSLAEMStunnel

The rest of this checklist & summary will assume stunnel is being used collocated with Connect, but the configuration variables will apply to hardware-based external SSL acceleration options as well and even a casual glance back at these diagrams will help you infer the differences.

The sample file editing offered herein will be based on the single server stunnel example depicted in the diagram above.

3. Four FQDN’s are required: This is how our working example FQDN list would appear in a host file.

  • 192.167.21.176  connectmtg.domain.com
  • 192.167.21.175 connect.domain.com
  • 192.167.21.174:443  cqauthor.domain.com
  • 192.167.21.173:443  cqpublisher.domain.com

4. Four certificates (or a wildcard certificate) is needed; here is the list of certificates for SSL following our example:

  • connectmtg.domain.com
  • connect.domain.com
  • cqauthor.domain.com
  • cqpublisher.domain.com

Note: These are depicted in our working example as a wildcard certificate: domain.com. If the certificates are not trusted public certificates, then meeting rooms will not open; self-signed certificates will not work with meeting unless they are installed on all clients. Place the certificates into the stunnel installation directory: \Connect\9.1.2\stunnel\

5. Backup and edit the stunnel.conf file: in the \Connect\9.1.2\stunnel\ directory to set up the four VIPs and pools:

stunnel.conf for four servers on one
; Protocol version (all, SSLv2, SSLv3, TLSv1)
sslVersion = all
; Some performance tunings
socket = l:TCP_NODELAY=1
socket = r:TCP_NODELAY=1
TIMEOUTclose=0
options = DONT_INSERT_EMPTY_FRAGMENTS
; Service-level configuration
[https-vip]
; incoming vip for https (to secure Connect Application Traffic)
; ip address of the server with stunnel on it
; listens on port 443
accept =192.167.21.175:443
; ip of the connect server
; send the unecrypted request to port 8443
connect =127.0.0.1:8443
; Certificate info for Connect cert key in stunnel root
cert = domain.com.cert.pem
key = domain.com.key.pem
[rtmps-vip]
; incoming vip for fms (to secure Connect Meeting Traffic)
accept = 192.167.21.176:443
; ip of the fms server
; Send unencrypted request to 1935
connect = 127.0.0.1:1935
; Certificate info for Connect meeting cert key in stunnel root
cert = domain.com.cert.pem
key = domain.com.key.pem
[CQ_Author-vip]
; incoming vip for CQ-Author (to secure AEM-based Events Authoring)
accept = 192.167.21.174:443
; ip of the CQ Author server
; Send unencrypted request to 4502
connect = 127.0.0.1:4502
; Certificate info for CQ Author cert key in stunnel root
cert = domain.com.cert.pem
key = domain.com.key.pem
[CQ_Publisher-vip]
; incoming vip for CQ-Publisher (to secure AEM-based Events Publishing)
accept = 192.167.21.173:443
; ip of the CQ Publisher server
; Send unencrypted request to 4503
connect = 127.0.0.1:4503
; Certificate info for CQ Publisher cert key in stunnel root
cert = domain.com.cert.pem
key = domain.com.key.pem

6. Next backup and edit the custom.ini file: By default, the custom.ini will point to 4502 and 4502 for CQ Author and Publisher respectively; you must change the links to reflect https rather than http and also change the  names to the correct FQDNs and also enable SSL for Connect with these following entries:

CQ_AUTHOR_SERVER=https://author.adobeconnect.com
CQ_PUBLISH_SERVER=https://publisher.adobeconnect.com
DOMAIN_COOKIE=adobeconnect.com
ADMIN_PROTOCOL=https://
SSL_ONLY=yes
RTMP_SEQUENCE=rtmps://external-host:443/?rtmp://localhost:8506/

7. Next backup and edit the server.xml file; in the \appserv\conf\ directory; uncomment two sections depicted here to enable SSL:

<Executor name=”httpsThreadPool”
namePrefix=”https-8443-”
maxThreads=”350″
minSpareThreads=”25″/>

<Connector port=”8443″ protocol=”HTTP/1.1″
executor=”httpsThreadPool”
enableLookups=”false”
acceptCount=”250″
connectionTimeout=”20000″
SSLEnabled=”false”
scheme=”https”
secure=”true”
proxyPort=”443″
URIEncoding=”utf-8″/>

Note: Be sure to test the server.xml file for correct editing by opening it in a browser and viewing any syntax errors.

8. After configuring the stunnel.conf, the custom.ini and the server.xml file for all four server instances, stop all five the services in the following order:

  • Adobe Connect CQ Author
  • Adobe Connect CQ Publisher
  • Adobe Connect Server
  • Adobe Flash Media Server
  • stunnel

9. After all services are completely stopped, start all five services in reverse order; do not cheat and just restart each one successively.

  • stunnel
  • Adobe Flash Media Server
  • Adobe Connect Server
  • Adobe Connect CQ Publisher
  • Adobe Connect CQ Author

10. Open a browser on the Connect server; go to localhost:4502 and log into CQ5 Author as an administrator and edit the URL

  • Select CRXDE Lite on the menu list on the right side of the screen
  • Go to: content>connect>c1>jcr:content
  • Scroll to the serverURL line
    • Edit the URL for https
    • https://cqauthor.domain.com

11. Open a browser on the Connect server and go to localhost:4503 and log into CQ5 Publisher as an administrator and edit the URL

  • Select CRXDE Lite on the right menu list
  • Go to content>connect>c1>jcr content
  • Scroll to the serverURL line
    • Edit the URL for https
    • https://cqpublisher.domain.com

12. Open a browser on the Connect server and go to localhost:4502/system/console/configmgr and log in as an administrator and edit the author externalizer name and statistics URL

  • Scroll to and edit the Day CQ Link Externalizer and edit the hostname value to reflect the FQDN of the Author server
  • cqauthor.domain.com
  • Scroll to and edit the Day CQ WCM Page Statistics and edit the localhost:4502 URL to reflect the FQDN of the Author server and HTTPS
  • https://cqauthor.domain.com/libs/wcm/stats/tracker

13. Open a browser on the Connect server and go to localhost:4503/system/console/configmgr and log in as an administrator and edit the publisher externalizer name and statistics URL

  • Scroll to and edit the Day CQ Link Externalizer and edit the hostname value to reflect the FQDN of the Publisher server
  • cqpublisher.domain.com
  • Scroll to and edit the Day CQ WCM Page Statistics and edit the localhost:4503 URL to reflect the FQDN of the Author server and HTTPS
  • https://cqpublisher.domain.com/libs/wcm/stats/tracker

14. Stop all services and and restart as shown in steps 8 & 9 or reboot the server

15. Log into Connect and test all features including the Events module.

Troubleshooting appendix:

  • Check to make sure all five  services are running and start any that are not running.
  • Once all the services are up, click on the stunnel.exe icon in the stunnel directory and insure that stunnel runs without errors
    • If stunnel.exe throws an error then examine the stunnel.conf for syntax problems
    • If stunnel.exe starts successfully then look elsewhere for problems
  • If  Firefox browsers Fail to Connect when stunnel is used to secure Adobe Connect, then double check to be sure that the
    • sslVersion = all
    • fips = no
  • To make certain the help files are served via SSL, follow the instructions in Jim’s blog article: Changing the Help Links to use HTTPS://
  • Make sure there is not a passphrase on stunnel: see Jim’s blog article Adobe Connect Stunnel prompting for passphrase when server/services restarts
  • If stunnel does not start with Connect upon reboot, this technique will help: Stunnel does not Startup with Connect
  • Depending on the version of Connect you are running, you may need to add the certificate to the java CA certificates in Connect in order to allow images in the AEM-based Events module to appear in Connect. Ignore this step unless you are running Connect 9.0.0.1 and even then, if at all possible, simply use a later version of Connect instead as this issue has been fixed and this workaround is made superfluous for later versions:
    • For 9.0.0.1, export and then import the SSL certificate: Log into Connect and click on the lock in the URL line to the left of HTTPS and click the button in the pop-up: More Information>View Certificates>Details>Export to export the SSL certificate. Save the certificate in the jre\bin directory in the root install directory for Connect: Connect\9.1.2\jre\bin
    • Use the command prompt to complete the importation: F:\Connect\9.1.2\jre\bin> keytool -import -trustcacerts -alias connect -file certificate-name -keystore cacerts
      • The default password is changeit.
      • Overwrite any existing certificate.
      • The italicized alias connect is a variable
      • The italicized certificate-name must match the name of the certificate

Stunnel Support with Adobe Connect 9.x

Up until Adobe Connect 9.0.0.1 (full installer) for on-premise (licensed) deployments, Adobe packaged Stunnel with the Connect application to handle the software SSL.  With the release of 9.0.0.1 of Adobe Connect, we included Stunnel 4.53 but do not unpack and install it with the installer (as we previously had done with Connect 8.x).  If you install (or are running) 9.0.0.1 and are looking for the Stunnel package, you need to navigate into the unpacked Adobe Connect 9.0.0.1 installer folder ({unpacked folder}\Adobe Connect 9.0.0.1\Adobe Connect\Merge_Modules) and look for the stunnel-4.53.zip file.  From there, you can install Stunnel 4.53 for your SSL deployment.

With the release of Adobe Connect 9.1.1, we no longer even ship the Connect installer with the Stunnel bits.  So you will need to obtain the Stunnel installer from either Stunnel’s website or from a 9.0.0.1 installer of Adobe Connect.  The last shipped version of Stunnel (with Connect 9.0.0.1) was 4.53, but again it was not ‘unpacked and installed’ as of 9.0.0.1.

The latest build of Stunnel that Adobe QE has tested with is version 4.56, which at the time of this article, is the latest production Stunnel build.

 

 

 

Connect on VMWare – some deployment tips

Issue: VMWare is ubiquitous in the enterprise and while it opens up huge potential for management of the Connect infrastructure, it must be planned and executed with an eye toward robustness.

This advice is gleaned from conversations with senior persons on our operations team as well as from support cases generated by various customers with on-premise VMWare deployments of Connect.

One of the most important and often overlooked variables about virtualization is to make certain that  VMware is compatible with all the underlying components of the server and network architecture. The infrastructure supporting VMWare must be verified by VMware under their Hardware Certification Program or Partner Verified and Supported Products (PSVP) program; be sure to use certified hardware.

Here is the link to the compatibility reference:  http://www.vmware.com/resources/compatibility

With Connect you must consider both Tomcat and  FMS; the former can run on most anything, while the latter is a bit more demanding; RTMP can be acutely;y affected by latency and packet transmissions. If you notice unpredicted latency or a surprise crash of FMS with Connect 9.1, a good test would be to check the network components; sniff for packet transmission issues – have the vNIC of the guest VMs configured to use VMXNET3; this is a good place to start.

With reference to recommendations and best practices, it really depends on the VMware infrastructure adopted. The following references serve as a guide for an enhanced environment:

Enterprise Java Applications on VMware – Best Practices Guide: http://www.vmware.com/resources/techresources/1087

Best Practices for Performance Tuning of Latency-Sensitive Workloads in vSphere VMs: https://www.vmware.com/resources/techresources/10220

Performance Best Practices for VMware vSphere 5.1: https://www.vmware.com/resources/techresources/10329

The key with Network Storage is speed. If you lose connectivity to the shared storage then only what is cached on the origins will be available.

Shared storage requirements

  • Disk specs: 10,000–15,000 RPM — Fibre Channel preferred
  • Network link: TCP/IP — 1GB I/O throughput or better
  • Controller: Dual controllers with Active/Active multipatch capability
  • Protocol: CIFS or equivalent

Avoid, virtualizing the Connect database if possible.

I have seen that in some customer-based VMWare environments that are overtaxed, that latency among the servers on 8507 (and 8506), can cause problems. Intra-cluster latency (server to server communication) should never exceed 2-3ms. When it does we see intermittent crashes. I had one customer who had a particularly weak infrastructure and for whom I could predict his crashes; he was doing back-ups and running other tasks at a certain time weekly that would tax and hamper network connectivity for about an hour; these tasks were so all-consuming on the network, they turned every cluster resource into an individual asset on its own island. The log traces bore this out and we knew with precision what was going on. He knew he needed to upgrade his infrastructure and in the meantime we worked out a reaction plan to deal with the issue; it included:

  1. Place a higher than normal percentage of cache on each server to limit invoking shared storage
  2. Set the JDBC driver reconnection string for Database connectivity
  3. Plan Connect usage around these maintenance activities and when possible, do Connect maintenance activities at the same time as well – not very difficult as these were after hours, but being a  global operation, still not a given.

Tunneling with RTMP encapsulated in HTTP (RTMPT) should be avoided as it causes latency

Tunneling with RTMP encapsulated in HTTP or RTMPT should be avoided as it causes latency that can have a negative impact on user experience in a Connect meeting. In rare circumstances,the latency commensurate with tunneling RTMP encapsulated in HTTP, can become so acute that it renders Connect unusable for affected clients. The performance hit commensurate with tunneling is one of the primary reasons we continue to deploy Connect Edge servers as they often can replace third-party proxy servers that are often the cause of tunneling latency..

While the amount of acceptable latency depends on what one is doing in the room; RTMPT tunneling affects most activities. Some activities, such as screen-sharing are more bandwidth intensive than other activities such as presenting an uploaded PowerPoint from within a meeting room; The high latency commensurate with RTMPT tunneling would affect the former more than the latter. VoIP is often the first thing to make the effects of high latency felt. Here is some feedback from a test I did while on site with a client dealing with tunneling because of their refusal to pipe RTMP around a third-party proxy:.

External user tunneling during test:
Spike at 3.10/3.02 sec
Latency 403/405 ms up to 3.53/3.52 sec up .064 down 118
When latency peaks to 2.6/2.4 sec I get a mild interruption to the audio V
Video pauses momentarily when the latency spikes

Internal user with direct connection:
2 msec / 1 msec Up 0.08 kbits down 127 kbits
No pauses, delays or spikes

Tunneling should only be considered as a fallback mechanism or safety net to allow connections when RTMP is blocked due to something unplanned or for a few remote clients who must negotiate specific network obstacles. When RTMPT is the default by network design, you will need to limit your activities within Connect to those feature that use the least bandwidth.

The picture below shows a direct connection over RTMPS on 443 is being blocked somewhere on the client’s network and the fallback mechanism built into Connect of tunneling RTMP encapsulated in HTTPS is the fallback path. This is usually caused by either proxy servers or firewalls or both – any application-aware appliance on one’s network that sees the RTMPS traffic on 443 and recognizes that it is not HTTPS is a potential obstacle; RTMPS traffic is on port 443 and while it is disguised as HTTPS, it still may be blocked. The result is tunneling, indicated by the “T” in the output:

.tunneljpgOctagon

Compare with a connection without tunneling:

no-tunnel

The recommended steps for anyone experiencing persistent tunneling, is for their network engineers to trust the source IP addresses of the Adobe hosted, ACMS, managed ISP or on-premise Connect/FMS server VIPs in order to prevent the blocking of RTMPS traffic. RTMPS is not supported by any third-party proxy server. Static bypass works well to solve this issue. The problem stems from network policies that require all traffic to go through a proxy. The result is tunneling with commensurate high latency and drops. RTMPS must be allowed to stream around a proxy to avoid the overhead and latency of tunneling encapsulated within HTTPS. Attempts to cache the stream add no value.

Other options will depend on the capabilities of the third-party proxy servers in the affected client infrastructure. Blue Coat ProxySG is one of the popular proxy server options in our niche. In cases of latency invoked by tunneling RTMP encapsulated in HTTP on a network that employs Blue Coat ProxySG servers, sniff tests done by support representatives have indicated that when an affected client attempts to connect to an Adobe Connect meeting, those clients would establish both explicit HTTP connections based on PAC file settings in the system registry to the Blue Coat ProxySG pool through a hardware-based load balancing device (HLD) and transparent HTTP and SSL connections through Blue Coat ProxySG via WCCP GRE redirect to several Adobe Connect servers. The problem manifests with RTMPS when the clients attempt to establish an SSL connection directly to the destination host without going through PAC file proxy settings. Since a Blue Coat ProxySG is commonly configured to perform an SSL intercept on both explicit and transparent HTTPS traffic, upon examining the content after decrypting the SSL payload from the clients, the Blue Coat ProxySG will return an exception and close the connection because the request doesn’t contain an HTTP component and cannot be parsed for policy evaluation. As a workaround, other than using static bypass, it is possible to create a proxy service with the destination set to the Adobe Connect server IP range on port 443 and to set the proxy setting to TCP-Tunnel with Early Intercept enabled. This will allows Blue Coat ProxySG to intercept and tunnel the traffic without considering whether it is RTMPS or HTTPS.

Watch for a more comprehensive article on this topic forthcoming.

Stunnel does not Startup with Connect

Problem: stunnel does not start up with Connect

Although stunnel can be installed as a service, it doesn’t load the stunnel.conf file(!) one workaround is to not setup the services to run automatically but to auto-run these batch files at startup:

Note: This tech-note assumes stunnel is installed in c:\Connect\9.0.0.1\; be sure to adapt the scripts accordingly.

Origin server startup.bat:

@ECHO ON
net start FMS
net start FMSAdmin
net start ConnectPro
net start CPTelephonyService
c:\Connect\9.0.0.1\stunnel\stunnel.exe stunnel.conf
@ECHO OFF Origins stop.bat:

@ECHO ON
net stop ConnectPro
net stop CPTelephonyService
net stop FMSAdmin
net stop FMS /y
@ECHO OFF

If you have remote Edge servers, use these; they includes cache clearing maintenance.

Edges start.bat:

@ECHO ON
net start fms
ping 1.1.1.1 -n 1 -w 10000>nul
net start fmsadmin
c:\breeze\edgeserver\stunnel\stunnel.exe stunnel.conf
@ECHO OFF

Edges stop.bat:

@ECHO ON
net stop fmsadmin
ping 1.1.1.1 -n 1 -w 10000>nul
net stop fms
ping 1.1.1.1 -n 1 -w 20000>nul
del /Q /S c:\breeze\edgeserver\win32\cache\http\*.*
ping 1.1.1.1 -n 1 -w 10000>nul
@ECHO OFF

Run > gpedit.msc
Local Computer Policy > Computer Configuration > Windows Settings > Scripts (Startup/Shutdown)
Batch files are assigned as startup & shutdown scripts. This is in addition to being available to be run manually.

The Adobe Connect Deployment Guide on the F5 Website needs Updating

Issue: Be careful when following the Adobe Connect Deployment Guide posted on the F5 Website. While the article is be helpful, there are some ambiguities that can lead to trouble. I have tried to update their deployment guide but have not succeeded; the LTM is the most popular load-balancing device and SSL accelerator in the Connect niche and when it is set up properly it works splendidly. Here are corrections, updates and things to watch out for when deploying Connect behind an LTM:

1. Do not use an HTTP profile for an RTMP VIP. An HTTP profile for RTMP VIPs may affect playback of video as well as break remote Edge connectivity. Remember that you have two servers running on each box, a Tomcat application server and an FMS server. Do not treat the FMS server as though it were an application server; RTMP is a streaming protocol that requires a TCP profile at the HLD VIP.

2. Use the health monitor documented here for LTM.

3. Do not use session-awareness or stick-sessions even if you use SSL. The Round Robin algorithm should float freely to the Tomcat application pool.

4. Do not use Nagle’s Algorithm with SSL; it will have a negative effect on performance.

Review this general Connect pool/cluster configuration tutorial before configuring BIG-IP LTM with Connect: Adobe® Connect™ server pools/clusters and hardware-based load-balancing devices with SSL acceleration

Preparing Connect Servers for SSL 2048 Certificates

Problem: When a Connect server is running with untrusted, expired or private SSL certificates, Connect Meeting rooms will not launch. Preparing for the transition from 1024 to 2048 SSL certificates is very important for your Connect on-premise SSL-enabled servers.

When you click on a Connect Meeting URL, the initial browser that opens spawns a second browser (the Connect meeting addin):

connecting1.fw

It is this hand-off between browsers that requires a fully trusted public certificate to complete; the Meeting will hang upon loading if the certificate is untrusted:

connecting.fw

During this hand-off between browser sessions, there is not any opportunity to click your way through an untrusted connection. The Meeting will simply hang.

Preparing your on-premise, SSL-enabled Connect servers for the transition from 1024 certificates to 2048 certificates is very important. Failure to upgrade your certificates as required will result in Meeting rooms hanging. There is s great FAQ page on the subject here on the Symantec website: 1024-bit Migration FAQs  Adobe’s SSL configuration documents and tutorials show where and how the SSL certificates are installed for both hardware-based load-balancing devices/SSL-accelerators or in stunnel:

If you are running on stunnel and are running stunnel on the Connect server directly, the transition to 2048 certificates will produce a greater CPU signature: The comparison between software-based vs. hardware-based offloaded and accelerated solutions like LTM is worth considering. The new 2048 certificates will have 70% penalty on CPU load as compared to current utilization stats. Check to see how much CPU stunnel is currently using with 1024 certificates and plan according for 70% more CPU than the current utilized.

If you are not sure whether you are currently running 1024 or 2048 certificates, use this handy tool from Symantec to check: Check your certificate installation

If your account is hosted by Adobe, then you are all set. When I plug in the domain name of an Adobe Connect hosted account for one of our training partners, Rexi Media, I get the following output:

reximedia.adobeconnect.com
Certificate information
Common name: *.adobeconnect.com
SAN: *.adobeconnect.com
Valid from: 2013-Feb-27 00:00:00
Valid to: 2014-Feb-28 23:59:59
Organization: Adobe Systems Incorporated
Organizational unit: DMBU Systems Engineering
City/locality: San Francisco
State/province: California
Country: US
Serial number: 7b8f272555087f6102773df671c95c3c
Algorithm type: SHA1withRSA
Key size: 2048

Firefox Browsers Fail to Connect when stunnel is used to Secure Connect

Problem:  Firefox Browsers Fail to Connect when stunnel is used to secure Adobe Connect

Solution: Double check to be sure that this setting is in place in the stunnel.conf:

; Protocol version (all, SSLv2, SSLv3, TLSv1)
sslVersion = all
fips = no

  • The original file version will have this commented out.
  • Enforcing TLSv1 with Firefox will be problematic.

Adobe Connect server pools/clusters and hardware-based load-balancing devices with SSL acceleration

The most robust means of implementing secure socket layer (SSL) with Adobe Connect servers is through a hardware-based SSL accelerator and similarly, the most robust means of clustering Connect servers is with a hardware-based load-balancing device (HLD). Since all enterprise-class HLDs are also SSL accelerators (any that are not both are either legacy or low-end by definition), this example-based article offers a best-practice configuration of a Connect Server pool or cluster running Connect Meetings, Adobe Presenter on-demand content, Adobe Connect Training, Curriculum and Virtual Classrooms securely behind a high-end, application-aware HLD and SSL acceleration device such as F5 BIG-IP LTM. This article does not exhaust the possible configurations, but offers a general working example.

The full tech-note is published here:  http://www.connectusers.com/tutorials/2011/09/connect_servers_ssl_acceleration/index.php

 

Adobe Connect Edge Server Deployment Options: part 2

This article focuses on Enterprise Proxy Connect Edge deployments and troubleshooting: http://www.connectusers.com/tutorials/2011/06/edge_server_deploy2/index.php