This document outlines recommendations and cautions based on customer feedback with RackConnect.

Recommendations

Use RackConnect Network Policies to make changes to network access for your Cloud Servers

When you need to open port(s) to or from your Cloud Server, or you need to make changes to the software firewall, you MUST use the RackConnect Network Policies section of the MyRackspace Portal to make the changes.  If you use the Firewall Control Panel, the RackConnect automation that services your installation could fail, a conflict in your Network Policies may arise, and your rules will be removed when there are updates to the system.  A note on terminology: "software firewall" refers to IPTables in Linux and Windows Firewall in Windows.

Monitor your Cloud Server status during a rebuild

If you perform a server rebuild, you may monitor its automation status in the RackConnect Management Interface in the MyRackspace Portal.

Understand how your servers use RackConnect

• The traffic flow is between the eth0 / public interfaces (Private IP) on your Dedicated servers to the eth1 / private interfaces (Private IP) on your Cloud Servers.
• The gateway for the Cloud Servers is configured on your Dedicated Firewall or Load Balancer.
• The eth0 / public interface is disabled on your Cloud Servers and ALL traffic must flow from the eth1 / private interface through your Dedicated Firewall or Load Balancer.

[Traffic Flow Between Dedicated & Cloud Servers: RackConnect Firewall]

[Traffic Flow Between Dedicated & Cloud Servers: RackConnect Load Balancer]

Cautions

Do not change your root/administrator password before your Cloud Server is deployed

For several minutes after your Cloud Server is built, automation scripts use the root/administrator password to establish a service account.  The service account is used to configure the server for RackConnect as well as implement updates to the server in the future.  If the password is changed before the service account can be created, the automation will fail.  You may change the root/administrator password once your Cloud Server is deployed.  You will know it is deployed when the Server's status shows a green circle in the MyRackspace Portal under "Network" -> "RackConnect" -> "<Your Cloud Account>" -> "<Your Cloud Server>" (*not* under the "Cloud Server" tab).

Do not delete or modify the "rackconnect" user

When RackConnect is implemented on your Cloud Servers, a user account named "rackconnect" is created with administrator rights.  Automation scripts depend on this user and without it, the scripts will fail.  If this user is deleted, it will need to be recreated.

Linux users: If you modify the /etc/sudoers file, please make sure to keep all references to the "rackconnect" user unchanged.  If you change the login authentication method from password authentication to key based authentication, please make sure to still allow password authentication for the "rackconnect" user.

Windows users: The user needs to be in the Administrators group.  If you update your server to be a Domain Controller, please make sure to create a ticket and inform the RackConnect team about this change.  You will need to manually create a “rackconnect” user account on the Domain and add the account to the “Domain Admins” Global Group.  We will add “DOMAIN\rackconnect” account to the RackConnect system instead of “rackconnect” to get RackConnect to work with your cloud server.

Do not prevent the root user from logging in using Password Authentication via SSH prior to the completion of the initial RackConnect process

RackConnect does not support key-based authentication, so password authentication will need to be allowed for the root user during the RackConnect automation process.

The PermitRootLogin entry needs to be "YES" in the sshd config file during the initial process of RackConnecting your Linux Cloud Servers.  Once the "rackconnect" user has been added to the cloud server, and your Cloud Server is properly "Deployed" with RackConnect, SSH access by the root user can be disabled as RackConnect will use the "rackconnect" user from that point forward.

Do not modify the standard port used by SSH (Port 22)

If modified, RackConnect automation will break, as we do not have the ability to support non-standard SSH ports at this time.

Do not mount a network file share on a dedicated hosted system prior to completion of the initial RackConnect process

The RackConnect initial process gives the cloud server access to the dedicated network, so mounting a NFS prior to completion will fail.

Do not use overly-complicated network configurations with RackConnected Cloud Servers

Complex networking configurations, such as bridged interfaces, will likely break RackConnect automation

Do not Enable SELinux on RackConnected Cloud Servers

We do not currently support SELinux.  If Enabled, please disable it or set it to Permissive mode.

Do not remove any basic system utilities like sed/awk/ip from Linux Cloud Servers

As this can break the RackConnect Automation process