Last updated on: 2019-12-16
Authored by: Juan Perez
Applies to: RackConnect v2.0
This document outlines recommendations and cautions based on customer feedback with RackConnect.
We recommend the following best practices for using RackConnect.
When you need to open ports 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 might arise, and your rules will be removed when there are updates to the system.
Note: The term software firewall refers to iptables in Linux and to Windows Firewall in Windows.
To understand how RackConnect transfers data to your cloud server, read the following description of the process:
Traffic flow between dedicated and cloud servers: RackConnect Firewall
Traffic flow between dedicated and cloud servers: RackConnect Load Balancer
We recommend the following cautions when using RackConnect.
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 and implement updates to the server in the future. If the password is changed before the service account can be created, the automation fails. You may change the root/administrator password after your cloud server is deployed. You know it is deployed when the server’s status shows a green circle in the MyRackspace Portal under **Network
RackConnect > yourCloudAccount > yourCloudServer** (*not* under the **Cloud Server** tab).
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 fail. If this user is deleted, it must be re-created.
Linux users: If you modify the
/etc/sudoers file, keep all
references to the “rackconnect” user unchanged. If you change the login
authentication method from password authentication to key-based
authentication, still allow password authentication for the
Windows users: The user needs to be in the Administrators group. If you update your server to be a domain controller, create a ticket and inform the RackConnect team about this change. You must manually create a “rackconnect” user account on the domain and add the account to the Domain Admins global group. The RackConnect team will add the DOMAIN\rackconnect account to the RackConnect system instead of “rackconnect” to get RackConnect to work with your server.
RackConnect does not support key-based authentication, so password authentication must be allowed for the root user during the RackConnect Automation process.
The PermitRootLogin entry must be set to YES in the
sshd configuration file
during the initial process of connecting your Linux cloud servers
through RackConnect. After the “rackconnect” user has been added to the
server, and your server is properly deployed with RackConnect, SSH
access by the root user can be disabled because RackConnect uses the
“rackconnect” user from that point forward.
If you modify the port number, RackConnect Automation breaks. Rackspace does not have the ability to support non-standard SSH ports at this time.
The RackConnect initial process gives the cloud server access to the dedicated network, so mounting a network file share before the process is complete causes the process to fail.
Complex networking configurations, such as bridged interfaces, will likely break RackConnect Automation.
Rackspace does not currently support Security-Enhanced Linux (SELinux). If it is enabled, disable it or set it to Permissive mode.
Removing basic system utilities such as sed, awk, or ip, can break the RackConnect Automation process.
©2020 Rackspace US, Inc.
Except where otherwise noted, content on this site is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License