Meshcentral Server Installation Guide Installing a true web based management system Version 10
Download 86.72 Kb.
|
- Navigate this page:
- Microsoft Messaging Queuing
- 1.1Swarm Server Settings
- 1.2Swarm Server Agent Store
- 1.3Installing the Swarm Server Service
- 1.4Mesh AJAX Server Settings
- 1.5Installing the AJAX Server Service
- Load-Balancing SSL offload
- 1.6ASP.net load balancing
|
Meshcentral.com Meshcentral Server Installation Guide Installing a true web based management system Version 0.0.10 Monday, March 17, 2014 Ylian Saint Hilaire Legal Notices and Disclaimers Disclaimers INTEL CORPORATION MAKES NO WARRANTY OF ANY KIND WITH REGARD TO THIS MATERIAL, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. INTEL CORPORATION ASSUMES NO RESPONSIBILITY FOR ANY ERRORS THAT MAY APPEAR IN THIS DOCUMENT. INTEL CORPORATION MAKES NO COMMITMENT TO UPDATE NOR TO KEEP CURRENT THE INFORMATION CONTAINED IN THIS DOCUMENT. THIS SPECIFICATION IS COPYRIGHTED BY AND SHALL REMAIN THE PROPERTY OF INTEL CORPORATION. NO LICENSE, EXPRESS OR IMPLIED, BY ESTOPPEL OR OTHERWISE TO ANY INTELLECTUAL PROPERTY RIGHTS IS GRANTED HEREIN. INTEL DISCLAIMS ALL LIABILITY, INCLUDING LIABILITY FOR INFRINGEMENT OF ANY PROPRIETARY RIGHTS, RELATING TO IMPLEMENTATION OF INFORMATION IN THIS SPECIFICATION. INTEL DOES NOT WARRANT OR REPRESENT THAT SUCH IMPLEMENTATIONS WILL NOT INFRINGE SUCH RIGHTS. NO PART OF THIS DOCUMENT MAY BE COPIED OR REPRODUCED IN ANY FORM OR BY ANY MEANS WITHOUT PRIOR WRITTEN CONSENT OF INTEL CORPORATION. INTEL CORPORATION RETAINS THE RIGHT TO MAKE CHANGES TO THESE SPECIFICATIONS AT ANY TIME, WITHOUT NOTICE. Legal Notices Intel software products are copyrighted by and shall remain the property of Intel Corporation. Use, duplication or disclosure is subject to restrictions stated in Intel's Software License Agreement, or in the case of software delivered to the government, in accordance with the software license agreement as defined in FAR 52.227 7013. The Intel logo is a registered trademark of Intel Corporation. Other brands and names are the property of their respective owners. Table of Contents Abstract 1 Introduction 1 Software Inventory 1 Microsoft Messaging Queuing 2 Mesh Swarm Server 3 1.1 Swarm Server Settings 4 1.2 Swarm Server Agent Store 6 1.3 Installing the Swarm Server Service 7 Mesh AJAX Server 8 1.4 Mesh AJAX Server Settings 9 1.5 Installing the AJAX Server Service 11 Server Redundancy 14 Load-Balancing & SSL offload 16 Setting up agents 18 ASP.net Server Setup 24 1.6 ASP.net load balancing 28 2. Notes 29
Document Changes June 11, 2012 – 0.0.10 Grammatical corrections, netsh command-line tool details added and added some comments/suggestions. April 24, 2012 – 0.0.9 Updated setting.txt description with new values. January 3, 2012 – 0.0.8 Added ASP.net installation instructions. December 19. 2011 – 0.0.7 Added AJAX load-balancing settings. December 6. 2011 – 0.0.6 Added load-balancing and SSL offload section. Added “adminportlocal” settings when going load-balancing.
Added server redundancy section. December 2. 2011 – 0.0.4 Added section on setting a mesh agent for custom server & updated screen shots. November 30. 2011 – 0.0.3 Minor fixes to settings in both AJAX and swarm servers. November 29. 2011 – 0.0.2 Added swarm server and AJAX server details. November 17. 2011 – 0.0.1 Initial version AbstractThis document reviews how to install a Meshcentral server complete with all of the components needed to handle mesh agents, web users and other management tools. This document is only intended for someone that wants to set up the back-end server, which is not typical. Readers of this document should be fully familiar with Meshcentral’s architecture. Other overview and architecture document are available. IntroductionThe Meshcentral server is a set of multiple applications that are not all required to run on the same computer. Communication between the components is configured using a setup file and done using TCP sockets, Microsoft Message Queuing (MSMQ) or Microsoft SQL Server. To review, these are the major components. In general, the Social Server is completely optional but all other components are probably desirable. 
Let’s start by setting up the operating system required to host any or all of these components. Software InventoryFirst, let’s review a general inventory of what will be needed to setup a Meshcentral server.
In addition, we have a few incoming ports that are needed. Firewall rules must be set accordingly.
Microsoft Messaging QueuingFirst, get a Microsoft Server 2008r2 system ready and perform all updates. It’s recommended that you run it on mirrored drives for better reliability. Make sure the updates include .NET Framework 4.0. Then, go in the Windows Add/Remove features or Server Console and add support for IIS along with ASP.net. 
Also, add support for Microsoft Message Queuing. We recommand installing Multicasting Support as a sub-option to MSMQ since we may use this. 
At this point the server software installation is complete. We now need to install Microsoft SQL Server 2008r2 along with the SQL Server Management Studio console. This will allow us to set up the database. The database can be installed on a different computer; as long as we know the database connection string, we should be ok. Mesh Swarm ServerThe swarm server is the central and most critical piece of software in the entire system. It’s a server that listens on a few ports and speaks only binary. Both mesh agents and mesh consoles can connect to it and the swarm server performs book-keeping, message relay and traffic tunneling. The swarm server will often maintain 1000’s of idle TLS connections to mesh agents. It’s also possible to run multiple swarm servers with a central database, with Microsoft message queuing used for coordination. These are the executable files of the Swarm Server: Manageability Stack.dll ManageabilityControls.dll MeshCommon.dll MeshInterface.dll MeshSwarmServer.exe MeshSwarmService.exe The swarm server comes with two executables, the MeshSwarmServer.exe runs as an application with a regular Windows user interface. It’s used a lot for debugging and small deployments. The MeshSwarmService.exe is a Windows Service executable and is the one used for production environments. The MeshSwarmService.exe makes reference to the MeshSwarmServer.exe, so both executable are required for production use, even if only running as a Windows service. All four other DLL’s are dependencies. All executables and assemblies are written in C# for the .NET Framework 4.0. The following picture is the Mesh Swarm Server running in application mode. It lists current mesh agents on top and various events on the bottom. 
1.1Swarm Server SettingsWhen launching the swarm server (either application or service), the file “settings.txt” will be loaded and parsed. Here is an example of the settings.txt file: swarmid=1 certfile=sfr.cps.intel.com.pfx certpass=sfr.cps.intel.com port=8080 adminport=8088 adminportlocal=0 db= Initial Catalog=MeshCentral;Data Source=localhost;Async=true; httproutekey=11112222333344445555666677778888… msmq_queue=.\Private$\MeshSwarmServer01 msmq_queue_mcast=234.1.2.5:16970 msmq_send=FORMATNAME:MULTICAST=234.1.2.5:16970 agentwhitelist=LM-Keystore.txt agentdefaultban=1 agentdefaultbantime=86400 agenttrustedroot=1111222233334444…,OID:1.2.840.113741.1.5.1.101.1.6 swarmserver1=127.0.0.1:8088 swarmserver2=10.232.58.27:8088 logfilepath=D:\Logs The “swarmid” value is a swarm server unique number. If many swarmservers are running at the same time, this number must be unique for each server. The “certfile” and “certpass” values point to the certificate used by the swarm server. This is not the TLS certificate used by the web site; instead it’s generally a self-signed certificate. It will be used by the mesh agents and mesh consoles to authenticate the swarm server. The “port” value is the main TCP port the server will listen on. All connections will start with a TLS handshake. The “adminport” value is for a secondary administrator port. It’s similar to the main port except that there is no TLS and all connections are assumed to come from a trusted source. This port is used by the AJAX server to perform routing without the need for TLS. Also, traffic on this port has TCP delays removed and is intended for fast operations between private components. The firewall must prevent any un-authorized access to this port. This value can be set to 0 to disable the administrator port. The “adminportlocal” value must be set to “0” or “1” and indicates if the administrator port should be bound to the local loopback interface only. For simple servers where the AJAX server is running on the same computer as the Swarm Server, this value should be 1. If omitted, the default value is 1. The “db” value is the connection string to the database with the Meshcentral schema already loaded. In this example we use a database on the localhost, but having the database on a different computer works as well. The “httproutekey” is a pre-shared secret; it is used to authenticate users that request traffic routing. This value should be the same between swarm server, AJAX server and ASP.net application. The “msmq_queue” value indicates the name of the message queue that will be created for this Swarm Server instance. Generally this would be of the form “\Private$\MeshSwarmServer01” with the last number is the swarm server identifier. The “msmq_queue_mcast” value is optional and used if the message queue for this server should subscribe to a multicast address and port. For production environments it’s likely preferable to not use this option and to use unicast messages only. The “msmq_send” enumerates all of the other message queues that messages should be sent to. This may include other swarm servers, AJAX servers and a social server. We can send messages to many queues at once using a multicast: msmq_send=FORMATNAME:MULTICAST=234.1.2.5:16970 Or we can specify queues for unicast: msmq_send=FORMATNAME:DIRECT=TCP:localhost\\Private$\\MeshAjaxServer01 Or specify many queues using the pipe as separator: msmq_send=FORMATNAME:MULTICAST=234.1.1.2:16979|FORMATNAME:DIRECT=TCP:localhost\\Private$\\MeshAjaxServer01 The “debugmode” flag value indicates whether the application should run in debug mode or not? 1=debug mode, 0=release mode. The “agentwhitelist”, “agentdefaultban”, “agentdefaultbantime” and “agenttrustedroot” are settings that set what agents can connect to the server and which one can’t. The first setting is the “agentwhitelist” and specifies a text file with a list of known good node id’s. Each line of this text file must start with a SHA256 hash of the public key portion of the node’s certificate in hexadecimal. “agentdefaultban” must be set to 1 if default behavior is to ban a node that is not on the whitelist. “agentdefaultbantime” sets the amount of time a banned node should wait before attempting to re-connect, banned nodes may not always follow this. Lastly, “agenttrustedroot” specifies the hash of a trusted certificate along with a node OID that is acceptable for agent connections. The “swarmserver” followed by a number specifies the administrative IP address and port of another swarm server in the group. This setting allows a swarm server to communicate with other swarm servers that are part of a load-balanced group. Communication between the servers will be both TCP and UDP. Servers will ignore their own number and only consider the IP address and port of other servers. So a server with “swarmid=2” will ignore “swarmserver2=xxx”, will take into account “swarmserver1=xx” and “swarmserver3=xx”. The “logfilepath” setting specifies where the log files must be written. If not set, the server’s executable path is the default. 1.2Swarm Server Agent StoreThe swarm server will has one sub-directory called “AgentStore” that is used to keep all the mesh agents. When the swarm server first loads, it will go thru all of the mesh agents in the agent store sub-directory and check signatures. The swarm server keeps an internal list of all the mesh agents that are available in the store and will automatically update agents in the field if needed. The following picture is an example of the content of the “AgentStore” folder. It contains signed mesh agents for many different computer architectures (Windows, Linux, OS X, Android…). 
When a new mesh agent is detected in the wild, the server may automatically download it and check the signature. If it’s valid, it is stored in the agent store for future use. When first installing the swarm server, this folder can be left empty. Slowly, the swarm server will fill it up as needed. If a new agent is added to this folder, the swarm server will not pick it up until it re-scans the agent store folder. As a curiosity, here is a list of the currently assigned architecture numbers. Each mesh agent’s file name will have a version number and an architecture number. Only a new version of an agent with the same architecture number can update a previous one. 0 - Reserved (Can’t be updated) 1 - Win32-Console (Debug) 2 - Win64-Console (Debug) 3 - Win32-Service 4 - Win64-Service 5 - Linux/x86 6 - Linux/x86-64 7 - MIPS
8 - Linux-Xen-x86 9 - Android/ARM 10 - Linux/ARM 11 – Apple MAC OS X 12 - Android/x86
The swarm server service is installed using “InstallUtil.exe”. This is a Microsoft tool for installing C# Windows Services. To install the service, simply run: installutil meshswarmserver.exe To un-install, run: installutil /u meshswarmserver.exe After installation, start the service using the Windows service manager. It’s recommended that you start the application version of the swarm server first to see if the settings.txt file is ok and to confirm that there are not problems. Then, close the application and launch the service. Since both application and service will attempt to bind the same TCP ports and use the same message queues, they can’t both run at the same time. Mesh AJAX ServerThe AJAX server provides interactive HTTP services to Meshcentral, this is the server that makes web pages “real time” allowing two way communication between the web browser and the rest of the infrastructure. The AJAX server is built on top of Microsoft Internet Information Server (IIS); it uses the IIS HTTP handling capabilities. As a result, it’s important to first setup IIS correctly before setting up the AJAX server. These are the executable files of the AJAX Server: Manageability Stack.dll MeshInterface.dll MeshAjaxServer.exe MeshAjaxService.exe Just like the swarm server, the AJAX server comes with two executables and the service executable depends on the application executable, so both have to be present. The two other DLL’s are dependencies. The two DLL’s are currently the same as the Swarm Server DLL’s, but they should not be mixed so that the swarm server and AJAX server can be updated separately;mixing the DLL’s could cause version issues in the future. Consequently, keep the servers with their respective DLL’s separate.
When launching the AJAX server (either application or service), the file “settings.txt” will be loaded and parsed. Here is an example of the settings.txt file: serverid=1 certfile=Meshcert.p12 certpass=MeshcertPassword webcertfile=HttpsDomainCert.pfx webcertpass= HttpsDomainCertPass port=8088 ajaxport=8084 wsport=8085 wsportsec=1 db=Initial Catalog=MeshCentral;Data Source=localhost;Integrated Security=SSPI;Async=true; httproutekey=11112222333344445555666677778888 msmq_queue=.\Private$\MeshAjaxServer01 msmq_queue_mcast=234.1.2.5:16970 msmq_send=FORMATNAME:MULTICAST=234.1.2.5:16970 ajaxprefix=/ajax/ ajaxswapfile=ajaxswap.txt bind=https://+:8084/ bind=https://+/ajax/ httpheader_Access-Control-Allow-Headers=Content-Type swarmserver1=127.0.0.1:8088 ajaxserver2=http://192.168.1.105:8084 domainauth=1 logfilepath=D:\Logs
bind=https://+/ajax/ The “msmq_queue” value indicates the name of the message queue that will be created for this server instance. Generally this would be of the form “\Private$\MeshAjaxServer01” where the last number is the server identifier. The “msmq_queue_mcast” value is optional and used if the message queue for this server should subscribe to a multicast address and port. For production environments it’s likely preferable to not use this option and to use unicast messages only. The “msmq_send” enumerates all of the other message queues that messages should be sent to. This may include swarm servers, other AJAX servers and a social server. We can send message to many queues at once using a multicast: msmq_send=FORMATNAME:MULTICAST=234.1.2.5:16970 Or we can specify queues for unicast: msmq_send=FORMATNAME:DIRECT=TCP:localhost\\Private$\\MeshAjaxServer01 Or specify many queues using the pipe as separator: msmq_send=FORMATNAME:MULTICAST=234.1.1.2:16979|FORMATNAME:DIRECT=TCP:localhost\\Private$\\MeshAjaxServer01 The “httpheader_xxx” value can appear many times and specifies added headers to put in all AJAX HTTP replies. The “swarmserver1=127.0.0.1:8088” indicates the administrator IP address and port of the swarm server with identifier number 1. One or more of these lines can be in the settings files, one for each swarm server administrator port. The AJAX server will use this address to communicate directly with a swarm server without authentication or TLS. Traffic on this connection is without TCP delay and intended to be within a private network. The “ajaxserverX=http://192.168.1.105:8084” indicates the URL of the dedicated AJAX port of each peer AJAX server. This is used when load balancing is in use and an AJAX server receives a request it can’t handle. In this case, it will re-route the request to the correct AJAX server. The “domainauth=1” indicated that Microsoft Domain authentication should be used. Except for intranet servers, this value should be omitted. The “logfilepath” setting specifies where the log files must be written. If not set, the server’s executable path is the default. 1.5Installing the AJAX Server ServiceThe AJAX server service is a little trickier to install. It’s recommended that you run the application version of the AJAX server first to make sure the settings file is read correctly before installing and running the service. The application version of the AJAX server is easy to run, but the service version requires extra bindings. If you are running https, you need to bind the SSL certificate to the application identifier of the AJAX server. Run this line, with “xxx” being the MD5 hash of the HTTPS certificate, in a command window (run as administrator). netsh http add sslcert ipport=0.0.0.0:8084 certhash=xxx appid={8bf83834-1594-4051-b4a7-5693561b257a} clientcertnegotiation=enable This adds a new SSL server certificate binding and corresponding client certificate policies for an IP address and port. Syntax add sslcert [ ipport= ] IPAddress:port [ certhash= ] CertHash [ appid= ] GUID [ [ certstorename= ] CertStoreName [ verifyclientcertrevocation= ] enable | disable [ verifyrevocationwithcachedclientcertonly= ] enable | disable [ usagecheck= ] enable | disable [ revocationfreshnesstime= ] U-Int [ urlretrievaltimeout= ] U-Int [ sslctlidentifier= ] SSLCTIdentifier [ sslctlstorename= ] SSLCtStoreName [ dsmapperusage= ] enable | disable [ clientcertnegotiation= ] enable | disable ] ] Parameters ipport= Required. Specifies the IP address and port for the binding. A colon character (:) is used as a delimiter between the IP address and the port number. Instructs the tool to set the certificate to port specified on the computer. Optionally, the four zeroes that precede the number can also be replaced by the actual IP address of the computer. certhash= Required. Specifies the SHA hash of the certificate. This hash is 20 bytes long and is specified as a hexadecimal string. Specifies the thumbprint of the certificate. This hash code can be obtained by running the Mesh server application and selecting ‘File/Certificate Hashs..’ menu option and copying the ‘SHA256 Hash:’ value. appid= Required. Specifies the GUID to identify the owning application. It can be obtained by … ??? certstorename Optional. Specifies the store name for the certificate. Defaults to MY. Certificate must be stored in the local machine context. verifyclientcertrevocation Optional. Turns on/off verification of revocation of client certificates. verifyrevocationwithcachedclientcertonly Optional. Specifies whether the usage of only cached client certificate for revocation checking is enabled or disabled. usagecheck Optional. Specifies whether the usage check is enabled or disabled. Default is enabled. revocationfreshnesstime Optional. Specifies the time interval, in seconds, to check for an updated certificate revocation list (CRL). If this value is zero, then the new CRL is updated only if the previous one expires. urlretrievaltimeout Optional. Specifies the timeout interval (in milliseconds) after an attempt to retrieve the certificate revocation list for the remote URL. sslctlidentifier Optional. Specifies the list of the certificate issuers that can be trusted. This list can be a subset of the certificate issuers that are trusted by the computer. sslctlstorename Optional. Specifies the certificate store name under LOCAL_MACHINE where SslCtlIdentifier is stored. dsmapperusage Optional. Specifies whether DS mapper is enabled or disabled. Default is disabled. clientcertnegotiation= Optional. Specifies whether the negotiation of certificate is enabled or disabled. Default is disabled. To delete this binding do this:
Required. Specifies the fully qualified Uniform Resource Locator (URL). user=” Required. Specifies the user or user-group name listen Optional. Specifies one of the following values: yes: Allow the user to register URLs. This is the default value. no: Deny the user from registering URLs. delegate Optional. Specifies one of the following values: yes: Allow the user to delegate URLs no: Deny the user from delegating URLs. This is the default value. sddl Optional. Specifies an SDDL string that describes the DACL. To show the current bindings
Server RedundancyBoth the AJAX server and swarm server are designed to run with multiple instances. They can be run in a load-balancing fashion, or by having one or more active and one or more hot spares. Each instance of a server must have its own “settings.txt” file. 
In this first scenario, we will assume that an outside router performs the load balancing on both the agent-side and HTTP side. On the HTTP side, the router can also perform SSL-offload operations, but not on the swarm server side (the swarm server needs to authenticate the agents). Let’s look at the settings.txt file for each of the two swarm server. Swarm Server #1 swarmid=1 certfile=cert.p12 certpass=certpass port=8080 adminport=8088
db=Initial Catalog=MeshCentral;Data Source=localhost\SQLEXPRESS httproutekey=000000000000000000000000000000001
msmq_queue_mcast=234.1.2.5:16970 msmq_send=FORMATNAME:MULTICAST=234.1.2.5:16970 swarmserver1=192.168.0.100:8088 swarmserver2=192.168.0.101:8088 Swarm Server #2 swarmid=2 certfile=cert.p12 certpass=certpass port=8080 adminport=8088
db=Initial Catalog=MeshCentral;Data Source=localhost\SQLEXPRESS httproutekey=000000000000000000000000000000001
msmq_queue_mcast=234.1.2.5:16970 msmq_send=FORMATNAME:MULTICAST=234.1.2.5:16970
swarmserver2=192.168.0.101:8088 It’s very important that each swarm service instance have its own identifier, starting at number 1. In this example, the “msmq_queue” is different for each server, this change is optional. Most other values, like the http routing key must be identical. We have to make sure the administrator port for each swarm server is no longer bound to localhost, the line “adminportlocal=0” will allow all connections to be accepted. It’s important that the administrator port only be connected from the AJAX servers or trusted servers. External users MUST NOT have access to the swarm server administrator port. Also, we specify the administration IP address and port for other swarmservers in each configuration file using the “swarmserverX=” setting. Now let’s look at the AJAX server settings.exe files. AJAX Server #1 serverid=1 certfile=cert.p12 certpass=certpass port=8080 db=Initial Catalog=MeshCentral;Data Source=localhost\SQLEXPRESS httproutekey=000000000000000000000000000000001 ajaxprefix=/ajax/ ajaxswapfile=ajaxswap.txt ajaxport=8084 wsport=8085 bind=http://+:80/ajax/ bind=http://+:8084/ msmq_queue=.\Private$\MeshAjaxServer01 msmq_queue_mcast=234.1.2.5:16970 msmq_send=FORMATNAME:MULTICAST=234.1.2.5:16970 httpheader_Access-Control-Allow-Headers=Content-Type swarmserver1=192.168.0.100:8088 swarmserver2=192.168.0.101:8088 AJAX Server #1 serverid=2 certfile=cert.p12 certpass=certpass port=8080 db=Initial Catalog=MeshCentral;Data Source=localhost\SQLEXPRESS httproutekey=000000000000000000000000000000001 ajaxprefix=/ajax/ ajaxswapfile=ajaxswap.txt ajaxport=8084 wsport=8085 bind=http://+:80/ajax/ bind=http://+:8084/ msmq_queue=.\Private$\MeshAjaxServer02 msmq_queue_mcast=234.1.2.5:16970 msmq_send=FORMATNAME:MULTICAST=234.1.2.5:16970 httpheader_Access-Control-Allow-Headers=Content-Type swarmserver1=192.168.0.100:8088 swarmserver2=192.168.0.101:8088 Again, it’s very important that each server have its own identifier number starting at 1. In this example, each server has a different “msmq_queue” name, but this is not required. It’s important to correctly specify the swarm server address and administrator port: “swarmserver1” must be for swarm server #1 and “swarmserver2” for swarm server number 2. Values must be correct. Load-Balancing & SSL offloadThis section looks at situations where load balancers and/or SSL offloading hardware are expected to be installed on the server side. First, let’s look at what the servers look like in the minimal situation. 
Here, we have the AJAX server and swarm server handing incoming HTTPS and TLS connections. The servers perform all of the authentication and encryption. Now, let’s look at adding SSL offloading hardware. 
Here the SSL offloading is added to the picture. Note that only the HTTPS connections are offloaded, the resulting connection is passed along to the AJAX server on ports 80, 8084 and 8085. SSL offloading must support HTML5 web sockets on port 8085. The swarm server’s connections are not SSL offloaded because the swarm server performs mutual-authentication TLS and authentication happens in both directions. 
In this picture, the swarm service is load balanced. Here again, no SSL offload is performed between the agents and swarm server. The connections are simply routed to the least loaded server. 
In this last picture, we have SSL offload and load balancing in front of all servers. Again, the swarm servers don’t get SSL offload. Setting up agentsIf the Swarm Server is set up, it’s now time to set up mesh agents. Normally, users use the ASP.net application to create a policy file, download the agent and install it on a computer. In this section, we use a different approach leveraging the “Mesh Controller” tool. On a Windows client computer, download and install the latest “Mesh Manageability Tools” at: http://opentools.homeip.net/mesh Then, launch the Mesh Controller tool. It should look like this: 
Here, mesh agents were found on the local network and listed. However, if no local agents are running on the local network, nothing will show up. That’s ok. Open the file menu and select “Create New Mesh…” 
Type in a mesh name and a strong password. Next, select the server you want the agents to connect to. If you are using a custom server not on the list, select “(No Web Service)” for now. We will edit the policy later. 
Next, the mesh agent will be installed on the local computer with this new policy. You can use the next wizard steps to save mesh administrative state and save a mesh agent for installation on other comptuers. You can do this now if you want, or just exit out. Now, a computer should show up with your new mesh. 
Now we are going to edit the mesh policy. Right click on the computer and select “Show Trusted Policy…”, then click “Edit Policy…”. You are now in the policy editor. 
Under the first tab, you can change the policy name and change the mesh password, but we will leave these as-is- no need to type anything on this screen. Go to the “web service” tab. 
For a custom server, select “(Custom Web Service)”, then type in the server address, port and the SHA256 hash of the service certificate. You can get this value easily by going to the Swarm Server’s file menu, selecting “Certificate hashes…” and cutting & pasting the SHA256 hash. 
In the “Web Permissions” tab, you can set what actions the web service is allowed to perform on computers with this agent & policy. Select them all for now. 
Now, click ok. Within a few seconds, the local mesh agent will connect to the remote server. You should see computers connecting to the Swarm Server. 
That’s it. You have your first computer connected. Mesh agents will automatically update each other’s policies, so if you have many agents on a local network, you only need to update the policy once. At any time, you can open the Mesh Controller and use the “File” menu, “Create Mesh Installer…” to create an installer with the latest mesh policy. Also note that the “meshagent.msh” policy file is valid for all agent architectures, so it will work on Windows, Linux, OS X, Android, etc. ASP.net Server SetupOnce both AJAX server(s) and Swarm server(s) are setup, it’s time to focus on installing the ASP.net server. This is the user-facing user interface and so, often the portion most easily associated with the mesh technology. Since one of the most interesting aspects of this technology is that remote interactions are all web based, the ASP.net server is the portal to all of the interesting features. To get the server set up, create a web site in IIS and copy the ASP.net files into it. You may use the default IIS web site. 
Then, open the IIS control panel so that we can continue the configuration. At this point, you may want to add IIS bindings and configure TLS on the web site. 
The first task is to open the “Connection Strings” and setup the proper connection string for the database. This will be used by ASP.net for user memberships. In the case of a development machine, we use a simple “localhost” connection string. 
Then, go back and select “Application Settings”. This is where most of the configuration of the ASP.net application takes place. Here is an example of the settings on a development machine. 
Lets look at each setting individualy. AgentStorePath – The Path where the mesh agent executables are stored. Ideally, this is the same path that the SwarmServer uses to store mesh agents. Then, when the swarm server obtains a new version of an agent, it will be stored in this location and the ASP.net server can take advantage of it right away. This path is used to allow users to download the mesh agents from the web site for initial installation. The ASP.net server will always attempt to get the latest version of the agent at this location. AjaxServerHost – The host name of the AJAX server. If omitted, the AJAX server is assumed to be located on the same server as the ASP.net server. AjaxServerPort – The AJAX server dedicated port number. Often set to 8084. AjaxServerScheme – “http” or “https” values allowed. If omitted, “http” is used. This indicates if the AJAX dedicated port (often 8084) was set with or without TLS security. AjaxServerWSPort – The AJAX server dedicated web socket port. Often set to 8085. AjaxServerWSScheme – “ws” or “wss” values allowed, if omitted “ws” is used. This indicates if the deviated web socket port (often 8085) has TLS in use. ConnectionString – The database connection string for the mesh database. This is often the same as the ASP.net connection string configured earlier. msmq_send – This line indicates how to send a message on the Microsoft Message Queue for mesh. This is used by the ASP.net application to send messages to the AJAX & Swarm servers. A typical value is: FORMATNAME:MULTICAST=234.1.2.5:16970 This will multicast the message on a given IP address and port. An alternative is to send messages directly to MSMQ queues like this: FORMATNAME:DIRECT=TCP:myserver\\Private$\\MeshSwarmServer01 In the second case, we have to set all of the message targets separated by the “|” pipe character. SwarmServerCertHash – The MD5 hash of the swarm server certificate. This is used by the ASP.net server to create new mesh policies. This value can be found by running the Swarm Server in interactive mode and selecting “Certificate Hashes” in the file menu. SwarmServerHost – The host name of the swarm server. If omitted, the swarm service is assumed to be running on the same computer as the ASP.net server. SwarmServerLongHash – The SHA256 hash of the swarm server certificate. This is used by the ASP.net server to create new mesh policies. This value can be found by running the Swarm Server in interactive mode and selecting “Certificate Hashes” in the file menu. SwarmServerPort – The port of the swarm server. This is typically “8080”. TrafficRoutingKey – The routing cookie pre-shared secret. This is the same secret that is configured for the AJAX server and Swarm server; it’s a 96 character long hex string. 1.6ASP.net load balancingThe ASP.net application is easy to set up with a load balancer. Just configure one server and once it’s working, copy everything into an identical server. Since all the settings will be part of the “web.config” file, copying the file over to other servers will also copy the settings over. 2.NotesFor flexibility and ease of use, the HTTP Server API supports four different ways to specify hosts. The four host-specifier categories are listed below in order of precedence: Strong wildcard (Plus Sign) When the host element of a UrlPrefix consists of a single plus sign (+), the UrlPrefix matches all possible host names in the context of its scheme, port and relativeURI elements, and falls into the strong wildcard category. A strong wildcard is useful when an application needs to serve requests addressed to one or more relativeURIs, regardless of how those requests arrive at the machine or what site they specify in their Host headers. Use of a strong wildcard in this situation avoids the need to specify an exhaustive list of host and/or IP-addresses.
An explicit host name such as a fully qualified domain name in the host element places a UrlPrefix in the explicit category. This kind of host element is matched directly against the Host headers of incoming requests. Explicit host specifications are useful for multi-site applications such as Web servers that deliver different content depending on the site to which the request was directed.
When an IP address appears as the host element, then the UrlPrefix falls into the IP-bound Weak Wildcard category. This kind of UrlPrefix matches any host name for the specified IP interface with the specified scheme, port and relativeURI, and that has not already been matched by a strong-wildcard or explicit UrlPrefix. The IP address takes one of two forms in the host element: IPv4 Literal String An IPv4 literal consists of four dotted decimal numbers, each in the range 0-255, such as 192.168.0.0. IPv6 Literal String An IPv6 literal string is enclosed in square brackets and contains hex numbers separated by colons; for example: [::1] or [3ffe:ffff::6ECB:0101]. IP-bound weak-wildcard host specifiers are intended for applications that vary the content they serve based on the route taken by incoming requests. Do not rely on IP-bound weak-wildcard host specifiers to enforce security.
When an asterisk (*) appears as the host element, then the UrlPrefix falls into the weak wildcard category. This kind of UrlPrefix matches any host name associated with the specified scheme, port and relativeURI that has not already been matched by a strong-wildcard, explicit, or IP-bound weak-wildcard UrlPrefix. This host specification can be used as a default catch-all in some circumstances, or can be used to specify a large section of URL namespace without having to use many UrlPrefixes. © 2014 Intel Corporation. All Rights Reserved. Directory: documents documents -> Concept stage documents -> Concept stage documents -> The great global switch-off documents -> Nonprofit grant application documents -> The Truth about the Rwandan Genocide documents -> Annual InStructional unit plan documents -> Chaos equipment included Download 86.72 Kb. Share with your friends:
|
