Certain CPU-intensive applications (trading applications in particular) will cause "clock drift" on Windows systems. Severe enough clock drift will cause Windows to re-sync with the system's hardware clock (also know as RTC, or Real Time Clock). This can cause Windows to change the clock to UTC or GMT in virtualized environments.

"Clock Drift" in this context is defined as the clock going out of sync. This is caused by Windows using SNTP (Simplified Network Time Protocol) rather than a full NTP service; as well as Windows having a too-infrequent clock update cycle by default. There are two ways to alleviate this issue.

Correcting clock drift by installing a third-party NTP service

The most reliable manner to correct this issue is to use a third-party implementation of the NTP service to update the system's clock. We have been succesful at using the Meinberg NTP daemon port for Windows, which includes an easy-to-use installer. You can download it at the following link:

http://www.meinberg.de/english/sw/ntp.htm

1. After downloading and running the installer, step through the default for each option, until you reach the "Configuration File Settings" screen. Here, choose the following:
   • Location of configuration file: Leave at default.
   • Create an initial configuration file with the following settings: Leave checked
   • Want to use predefined public NTP servers (see www.pool.ntp.org)? Choose Choose "United States of America"
   • You can specify up to 9 NTP servers (comma separated) you want to use: Leave blank.
   • Use fast initial sync mode (iburst) Leave checked.
   • Add local clock as a last resort reference Leave unchecked.
2. When prompted to review settings, click "No".
3. At the "Setting up NTP Service" screen, click "Next >"
4. At the "Enter the User ID and password used for running the service" screen, enter a secure password for an NTP account, and click "Next >"
5. Click Finish

This will replace the Windows W32Time service with the Meinberg NTP daemon. You can get up-to-date time statsitics by clicking Start > All Programs > Meinberg > Network Time Protocol > Quick NTP Status.

This will also automatically set the clock to update on a more frequent, and more accurate, basis.

Correcting clock drift by altering the W32Time service parameters in the Windows Registry

This will possibly help, but is not a recommended solution. Microsoft acknowledges that the Windows W32Time service is insufficient for any high-accuracy applications:

"We do not guarantee and we do not support the accuracy of the W32Time service between nodes on a network. The W32Time service is not a full-featured NTP solution that meets time-sensitive application needs. The W32Time service is primarily designed to do the following:

• Make the Kerberos version 5 authentication protocol work.
• Provide loose sync time for client computers.

The W32Time service cannot reliably maintain sync time to the range of 1 to 2 seconds. Such tolerances are outside the design specification of the W32Time service."

-- Source: Microsoft Support Article ID 939322: "Support boundary to configure the Windows Time service for high accuracy environments"

If you would like to make adjustments to the Windows Time Service regardless, follow the below steps:

1. Click "Start", then "Run...", and enter "gpedit.msc"
2. Navigate through the Local Group Policy Editor tree as follows: Local Computer Policy > Computer Configuration > Administrative Templates > System > Windows Time Service
3. Double-click on "Global Configuration Settings"
4. In the Global Configuration Settings window, click "Enabled" to enable the options pane.
5. Adjust the MinPollInterval and MaxPollInterval parameters to suit your needs. Note that this parameter is defined in log base-2; meaning that it will update according to the following formula: 2 ^ MinPollInterval. By default, this is 6, or 2 ^ 6 = 64 seconds. By default, Windows will update the clock somewhere between 64 and 1024 seconds.
6. Click Apply, then OK, and close the Local Group Policy Editor window.

If you have any questions, or experience further issues with clock drift on Windows systems, please contact support

These instructions explain how to define a nameserver that you will host on your own server if your domain is registered through eNom. This document is not an endorsement of eNom's services, it merely provides instructions to a frequently asked question.

You must be running nameserver software on your server in order for this procedure to be useful. If you have a control panel on your server, this should already be the case.

For this example, we will use the following nameserver:

ns1.example.com (10.0.0.1)

1. Log into eNom through the domain management interface.
2. Hover over the "Domains" menu along the top of the page, then move down to "Advanced Tools" and click "Register a Name Server."
3. Locate the "Register a NameServer Name" section and enter "ns1.example.com" in the box for "NameServer" and "10.0.0.1" in the "IP Address" box.
4. Click the "submit" button to create the nameserver record. If you need to create more nameservers, simply repeat these steps for each nameserver.

If you want this domain to use your newly created nameservers, simply return to the "My Domains" page, click on the domain and set ns1.example.com (and any additional nameservers) as the nameserver your domain will use under the "DNS Server" section.

You should allow 24-48 hours for propagation of these changes on the Internet, however most of the time everything should begin working within 4 hours.

We are providing this tutorial not as official support or recommendation to use GoDaddy as your registrar, but rather because we have had many people asking about how to do this.

We will use the following nameservers for this tutorial:

1. Log into your GoDaddy.com Account
2. Go to "Domains" > "My Domain Names" from the menu at the top of the page.
3. Click on the domain name you wish to manage.
4. On the summary page, scroll down until you find a "Host Summary" box on the left side.
5. Click the link that says "View/Modify Detail" in the Host Summary box.
6. Enter the subdomain for the first nameserver ("ns1") and the IP (10.0.0.1) into the "Host Name 1" and "Host IP 1" fields.
7. Enter the subdomain for the first nameserver ("ns2") and the IP (10.0.0.2) into the "Host Name 2" and "Host IP 2" fields.
8. Repeat step 7 for as many nameservers as you want to create.
9. Click "OK" when you have finished entering your information.
10. You will then need to proceed with changing the nameservers in the usual manner, as described in our video tutorial.

These instructions explain how to define a nameserver that you will host on your own server if your domain is registered through OpenSRS.

You must be running nameserver software on your server in order for this procedure to be useful. If you have a control panel on your server, this should already be the case.

For this example, we will use the following nameserver:

1. Log into OpenSRS through the domain management interface.
2. Click on the "Manage Name Servers" link on the main index page.
3. Scroll all the way to the bottom of this page, and locate the text "If you want to create or modify a nameserver which is based on example.com click here." and follow the link.
4. Locate the "Create Name Server" section and enter "ns1" in the box for "Server Hostname" and "10.0.0.1" in the "Server IP Address" box.
5. Click the "Create Name Server" button to create the nameserver record. If you need to create more nameservers, simply repeat steps 4 and 5 for each nameserver.

If you want this domain to use your newly created nameservers, simply return to the "Manage Name Servers" page and set ns1.example.com (and any additional nameservers) as the nameserver your domain will use.

You should allow 24-48 hours for propagation of these changes on the Internet, however most of the time everything should begin working within 4 hours.

Steadfast places a high value on security and the compliance needs of our customers. This is why even though we do not operate or process data in the EU, we have chosen to voluntarily comply with the GDPR standards. To assure compliance with the EU requirements for adequate security and privacy standards, we comply with the EU-U.S. Privacy Shield Framework and the Swiss-U.S. Privacy Shield Framework, as set forth by the U.S. Department of Commerce. Our continued participation in this program can be confirmed at (https://www.privacyshield.gov/) with the details available in our Privacy Policy (https://www.steadfast.net/legal-information#privacy_policy). Additionally, we complete an annual 3rd party audit of our security policies and procedures as a part of our SSAE18 and SOC 2 audits. These are extensive audits that don't just look at our actual policies, but verify through records and documentation over a 6 month period that those practices and policies are being followed. In meeting these standards, we are confident that Steadfast provides an environment in which you can be completely compliant with GDPR. If you have any other specific concerns or questions regarding GDPR compliance, just ask and we'll be happy to help.

This article is intended to help you understand what to do when you receive an email abuse report forwarded to you from Steadfast.

If you have recently received an abuse report regarding an Open SNMP, NTP, DNS, LDAP, or memcached server used for an attack, please see below for further information on dealing with these problems.

Controlling Who Receives Abuse Reports

Abuse reports will always be forwarded to the primary contact on your account, unless you have set a contact's title to include the word "Abuse."  Only one contact will be used for abuse report forwarding for technical reasons.  You should create a distribution list if you require multiple users to be able to view the reports.  Please disable auto-responding for abuse contact email addresses for the source address "abuse@steadfast.net" to prevent ticket system responder loops.  You should also ensure that the receiving mailbox has spam and content filtering disabled.  Much of what we forward will be spam or links to malware, and if you use a filtering system, you may never see our reports.  If the reports are ignored, you might risk having your services suspended without ever realizing we are trying to contact you.  We recommend, but do not require, that you ensure your abuse contact is an email address hosted outside our network, in case the abuse issue or a related suspension takes your email service offline.

Basic Handling Guidelines

When you receive an abuse report that's been forwarded to you, it indicates that someone believes that your service is doing something unwanted, malicious, or dangerous, or that your service is at risk of doing so in the near future.  You should carefully review the message to determine the proper course of action.  There are a number of common types of abuse reports which may need to be handled differently.

In any case, you can always reply directly to the forwarded email for advice and help.  To ensure your reply is properly matched to the original report, please be sure to keep the subject line intact.  It's okay if you don't understand what a report means.  Our support team can explain the report and suggest ways to try to resolve it.  If you have managed services with Steadfast, we can often provide assistance in identifying the problem and fixing it for you.

If you choose to disregard abuse reports we forward to you, you may put your server at risk of suspension.  We review all reports a second time and will check to verify that the problem is resolved.  If you have not responded and we find the problem still exists, or if we continue to receive additional abuse reports, we will give you an additional warning and a deadline to resolve it.  If the problem is not dealt with by the deadline, we will take whatever action is necessary to stop the abusive behavior until it can be properly addressed.

In rare situations where the abuse activity is harming our network or placing other customers or users in danger, we may need to suspend your server right away.  You will still receive a notification and we will work with you to resolve the problem to allow you to bring the server back online in a clean state as soon as possible.

Handling Specific Reports

Spam and Unsolicited Email

When you receive a report of spam or unsolicited email, this doesn't mean that your email was actually spam.  It means that someone felt that the email they received was not something they wanted.  In some cases, if you're running a simple newsletter for your site, marketing to a list you collected on your own site or emailing transactional emails to your own customers, the best course of action is to contact the user or unsubscribe them from the email messages or close the account.  If you are a bulk emailer, email service provider, you have purchased a mailing list, or you are mailing people you have no direct relationship with, you may be in violation of our terms of service unless you require subscribers to confirm their opt-in status before being subscribed.  You should hold your own customers to the same high standards whenever possible, if they send email.

If you have received a spam report for email that you don't think should have originated from your server, it is possible that your server may have been compromised in some way.  Inspecting the headers of the email message may identify the script(s) or users that were used to send the message, which could help to determine if a web site or the full server has been compromised.  Please see the section below regarding compromised web sites.

SpamCop Reports

SpamCop has a strict policy regarding how reports can be used, including a requirement that they may not be directly forwarded to customers.  This restriction is in place to prevent possible spam operations from identifying and unsubscribing users as a way to reduce complaint volume.

We are unable to provide the full text or headers of the message to you, so you should probably use this report for collecting abuse volume statistics for the noted IP address.  If your abuse report volume for an IP address is high, you should plan to evaluate the mailing practices of the server or user to better prevent abuse.

If this report is regarding a "spamvertized" URL, the URL has been truncated to the domain name only.  In that case, if the URL appears not to contain any uniquely identifiable information, we will be happy to pass the full URL on to you if you reply requesting that information.

Any headers we supply to you will have message IDs and uniquely identifiable headers and content stripped, so please note that you will not be able to gather this information for this report, even if you follow up.

Violation of SpamCop policies would jeopardize our continued access to these reports for statistical reasons and we are not able to make exceptions.

Phishing Scams and Malware

Reports of malware and phishing usually indicate that a server has been compromised in some way.  If the link you have been sent is not a normal page from the web site it references or a domain that is unfamiliar, you should find the content on your server, back it up and remove it.  If the content has been added to an existing file on the site, you should remove the added content or restore the page from a clean backup.

After resolving the immediate problem, you must also deal with the compromise.  Please see the section below for details on solving this problem.

Network Security, Denial of Service, Botnets

Network security and denial of service issues are usually the result of compromised sites, as above.  You should terminate any programs that are performing abusive behavior, but you should also note which user account they belong to.  If the user account is root or Administrator, your server may be fully compromised and should probably be re-installed.  Please see the section below for information on dealing with compromised systems.

Open DNS, NTP, SNMP, LDAP, or Memcached Servers Used for Attacks

Services of these types (UDP protocols) can allow someone to trick your server into sending unwanted traffic to the wrong IP address which can be part of a distributed attack.  If you received a report regarding an open DNS, NTP, SNMP, LDAP, Memcached server being used for an attack on an IP assigned to you, please see one of the following articles for details on how to resolve the problem:

• DNS
• NTP
• SNMP
• LDAP
• Memcached

Digital Millenium Copyright Act (DMCA)

A DMCA takedown notice is a special case.  You must review it carefully to determine which content is identified in the notice and then disable access to that content, regardless of whether there is indeed infringement of a copyright.  If you feel infringement is not occurring, you may submit a DMCA counter-notification back to Steadfast, which allows you to restore the content after 10 days.

Compliance with the DMCA is required by US law.  Even if you do not live or operate your business in the US, you must comply if you host content on a server that operates within the US, as in this case.  To comply with this notification you must do the following:

• Immediately disable access to the content indicated in the notification.
• Review the content to determine if it is infringing.
• If you believe the content is not infringing or this notice is not valid, you may file a counter-notification in reply to our message.
• If you file the counter-notification, you must wait 10 days before restoring the content.
• If the content has been uploaded by an offending account that has received multiple complaints, you should suspend the user account.

If we determine that the content has not been removed and that no counter-notification has been received within 5 business days of this message, Steadfast will be required to take corrective action directly, which may involve disabling the IP address that is hosting the content.

You should weigh the risks before deciding whether to send a counter-notification.  You may be liable for any related damages.

Remember, if you do not respond and take no action, Steadfast will be compelled by law to disable access to the referenced content regardless of the apparent validity of the claim.

If you have any technical or procedural concerns, please let us know and we will be happy to help explain your options or provide further details.  Steadfast is not qualified to provide legal advice and recommends you contact an attorney if you are considering actions other than immediate removal of content.

Handling a Compromised Account or Server

If your site or server has been exploited, you must evaluate the method that allowed the malicious activity to be put in place.  In many cases a PHP web site exploit or FTP password exposure may have been used to allow a malicious user to modify the site.  It's recommended that after an exploit all site passwords be changed, and any site administrators scan their personal computers for malware.  Any applications used on the site should be upgraded to the latest versions.  If an exploit occurs again, you should consider re-installing the entire site and restoring content from backups to hopefully close any backdoor code that may have gone unnoticed.

If you have found malicious processes running as root or Administrator on your server, it is fully compromised and you should not try to clean the exploit.  Instead, you should contact our support team for assistance with re-installing your system and restoring content from backups.  It is not recommended to try to operate a server on which any malicious person has had administrative access and the opportunity to hide backdoors and additional exploits.

You can reply to the abuse report we have forwarded you at any time for assistance in identifying the cause and possible solutions to a compromise.

What is IPv6?

IPv6 (Internet Protocol version 6) is a replacement for IPv4 (Internet Protocol version 4). IPv4 is the widely deployed protocol that provides your computer with a familiar 4-segment dotted IP address and allows you to reach everything on the Internet. Due to the limited amount of address space IPv4 provides, IPv6 was standardized in 1998 to provide a much larger address pool and to deal with other limitations and faults of IPv4. IPv4 addresses are 32 bits in length, which provides 2^32 (about 4.3 billion) possible addresses. IPv6 addresses are 128 bits in length, which means 2^128 (about 340 undecillion) possible addresses, or the entire size of the IPv4 address pool to the fourth power. While the standard has existed for over a decade, the prospect of running out of IPv4 space seemed to be far into the future, so very little had been done to adopt IPv6 until recently. Since IPv6 is not compatible with IPv4, all network-capable software and hardware needs to be re-engineered in order to make use of IPv6.

Now, as the IPv4 pool is almost completely depleted, some providers, engineers and developers are beginning to realize the urgency of making a change to support IPv6 and adoption is beginning to pick up. IPv4 will need to continue to exist while IPv6 is being adopted, but eventually when it becomes impossible to obtain IPv4 addresses any longer, some content may be available via only IPv6 and getting started on IPv6 before that day comes is the best way to avoid becoming cut off and needing to scramble to adjust. All Steadfast Networks customers are eligible for IPv6 connectivity for no additional charge as part of all standard service offerings.

Anatomy of an IPv6 Address

An IPv6 address is 128 bits, which means that representing it in 8-bit segments as an IPv4 address is would result in unwieldy numbers. To allow for shorter addresses that are easier to read and remember, the numbers are instead represented in hexadecimal, with eight 16-bit segments separated by colons, and there are rules that allow collapsing an address down to essential information by removing implied zeros. For example, here's a full-length IPv6 address:

There are several places we can reduce this address. First, we can collapse consecutive segments that are entirely zeros into "::" This can only be done one time in the address because if "::" appeared more than once, it would not be possible to tell how many segments were removed from each instance. With one instance, you can count the number of segments on the left and right of "::" to know how many missing segments it represents. For this rule, the above address becomes:

We can also remove the leading zeros in any segment, because they can be assumed. We can't remove other zeros because we wouldn't be able to tell where they belong. The result is:

IPv6 Subnets: CIDR ("slash notation")

Many people still refer to IPv4 addresses using the "class system" in which a class C is a block of 256 IP addresses. This system was deprecated in 1993 and replaced with the CIDR (Classless Inter-Domain Routing) system, because it more concisely represents all possible subnet sizes. IPv6 uses CIDR as well. CIDR is notated by a slash "/" after an IP address, followed by a number. It represents the "prefix length" or number of invariable bits in the address allocation for the given subnet. A class C in IPv4 is now known as a /24 (32 bits minus the 24-bit prefix length is 8 variable bits; 2^8 = 256). The standard allocation for an IPv6 subnet is a /64. Since an IPv6 address is 128 bits, and the prefix is 64 bits long, the number of remaining bits used for the network address (128 bits minus the 64-bit prefix length) is 64, and thus 2^64 addresses exist in the subnet.

Using IPv6

IPv6 resources cannot be directly accessed using IPv4 resources, nor vice versa. In order to access both, you need addresses and connections to a network with both protocols enabled. The preferred method, known as "dual stacking," is an implementation in which a system has both a public IPv4 and IPv6 address and connects through a provider that makes both protocols available from the system all the way to the Internet. Alternative methods include use of tunnels, which permit you to request IPv6 content by routing your request through a special server that has access to both protocols. The server converts the requests for you, then relays the responses back to you. This is not an optimal solution because it adds the delay and overhead of relaying all of your communications through a third party, but it permits IPv6 access when IPv4 is the only option at your end. Tunnels that allow IPv6 users to reach IPv4 exist as well and will become more popular when it becomes difficult to obtain IPv4 addresses in the future.

Steadfast Networks provides customers with native, dual stacked networking. This means you are able to access IPv6 and IPv4 content from your server without any special routing, as long as your server has both protocols enabled. This also means that, with some work, you can serve content to both IPv6 and IPv4 end-users. The subsequent sections of this article will explain some basic principles for accessing and serving IPv6 content.

If your home ISP does not yet support IPv6, which is still most likely, you can use a tunnel like those described above to access IPv6 content to try out some of these concepts. If you have an Apple home networking device, it may have come pre-configured with an IPv6 tunnel system to allow you to do this already.

Enabling IPv6 on your server

If you have a colocation account or custom VLAN configuration, you need to contact our IP allocations department to request an allocation. This is available at no charge. If you have a dedicated server with a standard network configuration, IPv6 connectivity is available already and there are two steps to the process:

1. Visit our IPv6 address page and input your server ID number in the form. You will be issued an IPv6 address that will work with your server, assuming it has a standard network configuration.
2. To activate the IP information from that page, visit "Adding IPv6 Addresses to Dedicated Servers".

This process gives you a single IPv6 address useful for allowing your server to reach IPv6 content, but we discourage using this address for serving content because it is not "yours" and does not stay with your account if you change servers or service types. If for any reason you need help configuring your server for IPv6 connectivity, you can contact our IP allocation or support departments and we can help you get basic IPv6 access working.

Hosting via IPv6

As we've noted in the previous section, you should not use your primary IPv6 address for hosting. This means that the first step in setting up your server to host content available via IPv6 is to get a secondary allocation for your server. This allocation will give you 2^64 addresses you can use however you like and the allocation is yours as long as you are a customer, so it can be moved around to other servers or service offerings later at any time. To obtain your secondary allocation, please open a ticket with our IP allocations department and let us know you want to start hosting content over IPv6.

Hosting via IPv6 requires support in the underlying hosting software. At this time, Apache, LiteSpeed and IIS web servers do support IPv6, as does the BIND DNS server. However, without patches and adjustments from vendors and software developers, supporting software such as your email server may not be able to provide IPv6 functionality. Additionally, many domain registrars do not yet allow registration of name servers that run on IPv6 addresses. Due to the fact that the DNS system uses multiple tiers of caching and end users rarely directly contact your server for information, this limitation can be worked around easily at the ISP level and most likely will not be a problem for many years.

If you're ready to begin serving web content to IPv6 clients right now, the following control panel versions can provide you with IPv6 management:

• Parallels Plesk Panel 10.2 or later (Press Release)
• DirectAdmin 1.37.1 or later (IPv6 How-To)
• InterWorx Beta 4.11.0 or later (Release Announcement)

cPanel has promised complete IPv6 support for version 11.36. Until then, setting up sites to work via IPv6 in cPanel requires manual modification of configuration files.

Our support staff can assist you in making small system configuration changes to activate your web and DNS servers on IPv6 addresses to let IPv6 clients see your content over the IPv6 protocol, even if your control panel does not support it. However, to avoid problems as IPv6 support is implemented in the future, we recommend avoiding this approach right now. There is not much harm in giving software a bit more time to catch up and implement IPv6. Our staff will of course remain available down to the wire to help bring sites online via IPv6 if the vendors don't make it by the time your users expect it. We'll also keep watching the implementation of IPv6 on your behalf across the Internet and revise our recommendations if things change to ensure you're prepared.

Making a site point to an IPv6 address

The Domain Name System (DNS) helps a computer find out what IP address to go to when attempting to access content for a domain. The IPv4 address is stored in a record called an "A" record. This provides a direct mapping from something like "steadfast.net" to our IPv4 address 67.202.100.2. For IPv6, a new record type called an "AAAA" record was created in order to allow IPv6 users to find IPv6 addresses instead. The name is a play on the fact that an IPv6 address is four times the length of an IPv4 address. You can publish both an "A" and"AAAA" for a domain name and systems with IPv6 connectivity will automatically check first for an IPv6 AAAA record and try to connect, then fall back to an IPv4 A record if IPv4 connectivity is available, but IPv6 is not. Please note that publishing an AAAA record before ensuring the web server and other services are functioning on the IPv6 address will either cause an IPv6-enabled user to have to wait for the IPv6 attempt to fail or may be unable to access the content at all. Publishing an AAAA record is the last step once all other software is ready to serve content via IPv6.

References and Help

There are a number of useful resources that explain more about what IPv6 is and how it works. From Wikipedia:

• http://en.wikipedia.org/wiki/IPv6
• http://en.wikipedia.org/wiki/CIDR
• http://en.wikipedia.org/wiki/AAAA_record#IPv6_in_the_Domain_Name_System

As always, our support staff will be happy to help you get started with IPv6 and answer any questions you have!

This article explains the differences between versions of PHP, which ones are available to you and how to select a version to use.

Supported Versions

The supported versions of PHP vary depending on your control panel and operating system.  This table was last revised 03/14/2014.

PHP versions prior to 5.3, except 5.1.6 on CentOS 5, are unsupported and considered End of Life.  This includes all versions of PHP 4.x.  CentOS 5's PHP 5.1.6 receives bug and security fixes through the CentOS project, and will remain supported as long as CentOS 5 is supported, through 2017.  CentOS and Debian-specific PHP releases are always maintained in this way, and are supported through the end of the OS lifecycle.

Choosing a Version of PHP

For the most part, we recommend that you do not change the version of PHP away from the default for your system configuration.  This is especially true if you are operating a shared hosting environment.  It's best to ensure a common, stable PHP version is in use to maximize compatibility with customer software.

We do not recommend ever running PHP 4.x in a production environment, as it has been end of life for several years.

If you are running your server in an environment where you are able to manage all the applications and you have one or more that require or strongly recommend a specific version of PHP, or if you are developing your own application and would like to use features from a specific version of PHP, it makes sense to adjust accordingly.

For technical reasons, official support for PHP from Steadfast is the same as what appears in the above table.  Limited "best effort" assistance is often available for increasing the PHP version to something newer than the table indicates.  We currently recommend against PHP 5.5 unless it is provided by your system, because it is a relatively new PHP release.  Many applications do not yet support the differences from PHP 5.4 properly.

When you choose to add LiteSpeed Web Server to an existing Linux server configuration, our recommendation is to match the OS version of PHP so that scheduled tasks and command-line scripts run using the same version of PHP as the web server uses.  However, as long as your applications do not experience trouble using a newer version of PHP, there is no problem with doing this, and it is a supported configuration.

Also noted in the table above is that some configurations include multiple versions of PHP by default.  If your system is configured in this way, you can configure each site or application to use a different version of PHP as you like.  This is a feature available for Microsoft Windows IIS Web Server, and for Plesk servers.

Differences between PHP Versions

The differences between each version of PHP are too extensive to list here, but mostly involve new or deprecated functionality for PHP scripts.  Most scripts will support a minimum PHP version and then deal with the differences in newer versions automatically, or gain extra features in newer versions as appropriate.

If you are not familiar with writing PHP scripts, it is best to follow the system requirement guidelines of your applications and reasonably safe to disregard the specific differences between any two PHP versions.

If you are interested in technical differences, the PHP 5 Change Log describes all modifications made in each version of PHP.

Getting Help

If you have any questions about supported versions of PHP for your environment or changing between them, our support team will be happy to help you determine your options and configure your server to support the version you need.  Feel free to contact us for help.

In March 2013, the Open DNS Resolver Project identified many IP addresses on our network that were of moderate to severe risk of participating in a DNS amplification attack.  This attack queries name servers for large results using a fake source address.  This request causes the response to go back to the faked address, resulting in a large amount of data being sent to a computer that did not request it.  This effect, when used with thousands of DNS servers, directs a very large amount of traffic to a single IP to form an efficient distributed attack.  The anti-spam organization Spamhaus was recently the victim of an attack that may have been as large as 300 Gbps using this technique.

This attack can be performed easily using a server you control without compromising its security, and could result in heavy outbound bandwidth usage.  This may impact performance of your services and cause unexpected bandwidth overage bills.

The most common environment we have found with a problem is a CentOS 5.x server running BIND with default settings.  The default BIND version for CentOS 5.x causes a moderate risk.  A severe risk occurs if any DNS server is configured to act as a public DNS resolver.  A public resolver is a server that allows anyone to query it for the DNS records of a domain it does not directly host.

You can confirm your server is affected by querying the server from a Linux or Mac command line on a separate computer:

dig steadfast.net @<server ip>

A version of the "dig" command for Windows can be downloaded from here.

If the resulting status is NOERROR, your server allows queries that it should not.  If the information contains AUTHORITY results but does not containANSWER results, it is a moderate risk.  If it contains any ANSWER results, then the risk is severe.  Other statuses, such as REFUSED, NXDOMAIN, SERVFAIL, or a timeout error message, do not indicate an issue.

To mitigate a moderate risk, the best option is to install the CentOS 5.x bind97 package.  In a cPanel/WHM environment, upgrading to bind97 can be accomplished with the following commands:

cp -Rf /var/named/ /var/named.bak
/scripts/update_local_rpm_versions --edit target_settings.named uninstalled
/scripts/update_local_rpm_versions --edit target_settings.bind uninstalled
yum -y remove bind bind-utils bind-devel bind-libs caching-nameserver
yum -y install bind97 bind97-libs bind97-utils bind97-devel
/usr/local/cpanel/scripts/rebuilddnsconfig

In a non-cPanel environment, you can perform similar steps, but you will likely need to rebuild the /etc/named.conf file from the /etc/named.conf.rpmsave.

Another option that can be used to mitigate the moderate risk level is to upgrade your server from CentOS 5.x to CentOS 6.x.  This upgrade enables you to access other new and improved software and may improve server performance.  However, doing this usually requires reinstalling your operating system and restoring data from backups.

To mitigate a severe risk, you must reconfigure your name server manually.  Recursive resolver behavior is not the default, which means that a configuration change was made to enable recursion on your server.

For advice on how to adjust a server to prevent public recursion or limit the IP ranges that can use recursion, or any other questions about the topics discussed in this article, please visit our Help Desk or email us.  BIND consulting is covered under managed services.

In 2018 we saw a significant increase in reports of amplification attacks that take advantage of the LDAP protocol over UDP (CLDAP).  This attack queries LDAP servers for large results using a fake source address. This request causes the response to go back to the faked address, resulting in a large amount of data being sent to a computer that did not request it. This effect, when used with thousands of LDAP servers, directs a very large amount of traffic to a single IP to form an efficient distributed attack.

Most LDAP servers and clients use the TCP protocol, which prevents amplification because of a connection handshake that verifies the source and destination can communicate with one another.  UDP does not perform this verification, so the LDAP server can be convinced to send traffic to a destination that is unverified.

The easiest way to solve this issue is to enable a firewall on your server that blocks the LDAP port 389 from being accessed via UDP.  LDAP is most commonly used on Windows servers running Active Directory services.  If you have a program that is using LDAP via UDP from another server, you should add a firewall exception to allow that application to continue to work, or change that application to use LDAP over TCP.  LDAP may also be running with encryption (LDAPS) on port 636, but this protocol only supports TCP.

To disable access to LDAP over UDP if you do not have any servers that access it, follow these steps:

1. Right click on Start, then click Run and type "wf.msc" click "OK"
2. Click on the "Inbound Rules" option on the left side of the window.
3. Locate the rule called "Active Directory Domain Controller - LDAP (UDP-In)"
4. Right click on the rule and select "Disable Rule"

If you need to allow access to LDAP from other servers, follow these steps:

1. Right click on Start, then click Run and type "wf.msc" click "OK"
2. Click on the "Inbound Rules" option on the left side of the window.
3. Locate the rule called "Active Directory Domain Controller - LDAP (UDP-In)"
4. Right click on the rule and select "Properties"
5. Click on the "Scope" tab
6. Under the "Remote IP address" section, select the option "These IP addresses:"
7. For each IP address or range that should have access, click "Add..." and enter the correct ranges.
8. Once you have entered all the ranges that should have access, click "OK" to save the rule.

If you wish to restrict the LDAP over TCP or the Secure LDAP service for security reasons, you may also wish to modify these rules using the same steps above:

• Active Directory Domain Controller - LDAP (TCP-In)
• Active Directory Domain Controller - Secure LDAP (TCP-In)

If you are running an LDAP server on Linux, you should modify your LDAP server configuration in accordance with its documentation to disable or restrict LDAP over UDP, or configure your system firewall accordingly.  Steadfast does not currently support any standalone LDAP servers or any products with an exposed LDAP server.

For advice on how to adjust a server to prevent LDAP amplification or limit the IP ranges that can make LDAP queries, or any other questions about the topics discussed in this article, please visit our Help Desk or email us. LDAP configuration on Windows servers is covered under managed services.

In 2018 we have seen a large number of DDoS attacks making use of unsecured memcached services running on the internet.  On some Linux distributions memcached servers default to listening on all network interfaces, including those facing the internet.  Exposing the service puts servers at risk of participating in an amplification attack and may expose some sensitive information stored by the application using memcached. This attack queries memcached servers for large results using a fake source address. This request causes the response to go back to the faked address, resulting in a large amount of data being sent to a computer that did not request it. This effect, when used with thousands of memcached servers, directs a very large amount of traffic to a single IP to form an efficient distributed attack.

If you are using memcached only with an application running on the same server, you should configure the service to listen only on the local interface so that it can never be exposed on the internet.  To do this:

On CentOS:

1. Edit the file /etc/sysconfig/memcached
2. Find the line that begins with OPTIONS= and add -l 127.0.0.1 between the quotation marks.
3. If there is no such line, add one that says OPTIONS="-l 127.0.0.1"
4. Restart the service by running the command

   service memcached restart

On Debian or Ubuntu:

1. Edit the file /etc/memcached.conf
2. Find the line that begins with -l and make sure it reads -l 127.0.0.1 
3. If there is no such line, add one at the end of the file that says -l 127.0.0.1
4. Restart the service by running the command

   service memcached restart

If you are running an application on another server that needs to connect to memcached, you should configure the server firewall to only accept connections on port 11211 from IP address ranges of application servers that need to connect to this server.

If you aren't using memcached, you should remove or disable the software. To remove it:

On CentOS:

yum remove memcached

On Debian or Ubuntu:

apt-get remove memcached

For advice on how to adjust a server to prevent memcached amplification, or any other questions about the topics discussed in this article, please visit our Help Desk or email us.  memcached is not supported software, but our support team can assist with firewall and package management to disable or restrict access to it.

Spamhaus provides a set of managed block lists to assist with identifying and blocking IP addresses and domain names that are likely to send out spam or cause malware infections.  These lists are available via the spamhaus.org web site as well as via the DNS-based Block List (DNSBL) standard.  To limit the load on their infrastructure, Spamhaus only permits users to query the service for non-commercial purposes and sets a cap on the number of daily queries allowed.

As of August 2016, due to the fact that Steadfast is a commercial business and has a high volume of DNS traffic, Spamhaus has requested that we reject all queries to the DNS block lists via our public resolvers.  This means that instead of fetching a usual DNSBL response code, the resolver will return NXDOMAIN, which indicates no result is available.  This response should not cause any issues for mail servers using Spamhaus services, except that they will no longer be able to use the block lists for filtering email.

We cannot grant exceptions to the query restrictions on our public DNS resolvers.  It is not possible for Steadfast to meet the usage terms of the free DNS feed and we cannot reasonably meter the usage of the paid feed to provide a bundled version to our customers.

If you need the data from Spamhaus as part of an anti-spam effort or product, you have two options.  You may either run a DNS resolver locally on your server to query the DNS block lists directly if you meet the free feed criteria, or you may contact an authorized Spamhaus reseller to gain access to the paid version of the data feed intended for commercial use and high-volume consumption.

For more information on the data feed and its restrictions, please see the following web site:

• https://www.spamhaus.org/organization/dnsblusage/

If you have questions about how to run a local DNS resolver, please feel free to contact us.

For the security of everyone's data, we have decided not to allow plain (unencrypted) rsync connections to our backup server. Instead, we encourage users to use rsync over SSH. This is relatively easy to set up, and it ensures that users are logged in as themselves when they upload data, preventing any possibility of corruption of other users' data. Since SSH is encrypted, all data transferred has the added benefit of being secure.

On your server, you will want to set up a command such as the following to be run on a schedule, such as with cron. You can run multiple commands on different sets of files (rather than backing up your entire system), though we recommend that you space apart the timing on each run, so that you do not bog down your server or our backup server too much.

You can customize the parameters however you prefer to properly sync your data. The ones we have given are the ones we use for our own backup processes. For more information about the options you can use with rsync, run "man rsync" from your server. The last parameter "--rsh=ssh" is required. It directs your server to connect via SSH.

You should replace the text "ftpuser" with the FTP username contained in the welcome email you received when you signed up for a backup account.

The "subdir/" part is optional, and will place the synced files in that subdirectory of your home directory, which is ideal if you are backing up sets of data from various places. The ending ":" is required even if you leave out the subdirectory part.

When you connect with rsync via SSH, you are prompted for your password. To work around this "problem" for a scheduled task, you need to create and upload an SSH key owned by the user that will run rsync. As that user on your server, run:

Make sure this creates .ssh/id_dsa and .ssh/id_dsa.pub in the user's home directory.

Do not set a password for the key, or you'll still have to enter a password each time you sync. Now, use FTP or SFTP to connect to the backup server using the details you received in your welcome email. Upload the "id_dsa.pub" file you created earlier as a file named "authorized_keys2" inside the .ssh directory on the backup server. You may need to tell your FTP client to show hidden files, or run "ls -a" via SSH to see the .ssh directory, or create it as follows via SSH if it does not exist.

You should now be able to run the rsync command successfully. If you have any problems completing these steps, please contact support for assistance.

Below is the shipping information for Steadfast's three datacenters.

Customers shipping hardware to Steadfast should always include their Customer ID# on the shipping label, if at all possible.

350 E Cermak Datacenter

Steadfast
350 E Cermak Rd
Suite 240 West
Chicago, IL 60616

725 S Wells Datacenter

Steadfast
725 S Wells St
8th Floor
Chicago, IL 60607

Edison, NJ Datacenter

Steadfast/NoZone c/o IO Data Center
3003 Woodbridge Ave
Edison, NJ 08837

The Steadfast Guest wireless network ("wireless network") is intended exclusively for customers, vendors, and other guests ("users") of Steadfast Networks, LLC ("Steadfast"). Users may use the wireless network to perform activities related to Steadfast while actively working in Steadfast data center or office spaces ("facilities") on mobile devices and laptop computers ("devices"). No service reliability, capacity, security, or availability guarantees are made with respect to the wireless network, and maintenance and service interruptions may not be announced.

All use of the wireless network is governed by the Steadfast Acceptable Use Policy and Privacy Policy. Any abuse may result in the blocking or limiting of access to the offending device. Steadfast further reserves the right to restrict access to, limit, discontinue, or modify the wireless network at any time, for any reason.

The following additional terms apply to the wireless network:

• Devices other than mobile phones, tablets and laptop computers may not be used without the approval of Steadfast management.
• Devices may not be left connected to the wireless network unless directly attended by a user inside the facility.
• Devices may not conduct activity that produces sustained transfers for extended periods of time.
• Devices may not block, redirect, intercept, modify or audit traffic not intended expressly for the device.
• Devices may not broadcast unsolicited traffic to any system on the network or Internet, except where such traffic is authorized by Steadfast management.
• Devices may not act as a web server, game server, or directly offer any other public services to remote users.
• Devices may not operate any MTA or other daemon intended for transmission of email.
• Devices may not publicly expose any remote control protocol including but not limited to VNC, RDP, Telnet, or SSH, without the approval of management.
• Users may not advertise the existence of any services or devices hosted on the wireless network.
• Users are responsible for their own security and encryption when using the wireless network.

Users must accept these terms on each device once every seven days prior to being granted access to the network.

To assure fastest response and avoid tickets becoming stalled or delayed, always provide as much detail as you can about an issue, including any changes you may have recently made to your services or even your local computer (in case of access issues), even if they don't seem relevant. Provide any necessary special directions to access your account. For dedicated server customers, make sure you have updated access information stored in our management system. We generally recommend you do not send password information in tickets, especially via email, unless it is absolutely necessary.

Where possible, we prefer that customers submit one ticket per issue and keep one issue per ticket. This allows us to easily tell what specific matter is being handled in a ticket, to correctly close issues once they are completed, and to move tickets to other departments without stalling the progress of other unrelated matters in the same ticket. Duplicate tickets, especially from multiple account contacts can cause confusion as to the progress of an issue and can result in slower or inconsistent responses. Duplicate tickets may be merged or closed to consolidate requests and mitigate confusing situations.

Please do not send ticket emails addressed to more than one department or CC'ed to other individuals that should not be given private information. These tickets may not be routed properly and may end up in the wrong department, or all in the same department, and any replies will go to anyone that was CC'ed on your messages. If you need to address multiple departments, send emails to each department separately with only the information for issues relevant to that department. Cross posting duplicate tickets will not result in faster responses, and may cause confusion between departments as to whether an issue has already been handled.

If you feel a ticket is not being handled promptly, a reply to the ticket is a valid way to request attention. If you prefer to call our support staff, please have a ticket number ready, as well as any IP address or account details so we can identify you and your issue quickly. When calling, please be aware that we will not always be able to completely resolve a request with a single phone call and some matters simply cannot be handled via telephone for security or policy reasons. A phone call does not necessarily guarantee that any issue will be able to be solved more quickly than an equivalent ticket about the same issue.

Use of the ticket system is generally more efficient than verbal troubleshooting due to the type of information that often must be relayed. Tickets also allow us to maintain a history of the progress on your issue (so you do not have to explain your issue several times to different people), and permit us to handle more issues at a time, so we often will ask you submit a ticket if your issue is complex or is expected to take a while to address completely.

While you may notice that you are able to choose from two different priority levels for your tickets, you should note that we treat all support tickets as high priority and will always consider outage conditions to be of the highest priority. Tickets are triaged by our staff to ensure focus on issues affecting the most customers most quickly, but all tickets will always be handled as quickly as possible.

Any reply to any ticket in any status will return it to the "Open" state and it will immediately be seen by our support staff. Please note that non-support departments, such as IP Allocation, Sales, Billing, and others may have specific hours of operation and will be considered to be relatively low priority. If you have an issue that is affecting your service, it should always be filed to the support department, but be advised that Sales and Billing related issues cannot always be resolved by technical support staff.

Ticket statuses indicate what type of ticket you have submitted as well as its progress. The definitions below explain what each status indicates and what you may expect to happen to your ticket while in this state.

Routine Statuses

• Open: Your ticket is in the active queue. It will be looked at soon, if it is not already being reviewed. We will reply if we need more information or once we believe we have resolved the matter. Unless the solution is expected to take a while to complete, you may not receive any staff response until we have addressed the issue.
• In Progress: Your ticket is being worked on by a staff member and an update will be provided as soon as it is completed, or if more information is required. If the ticket will take a long time, a staff member will update you with progress when possible.
• On Hold: Your ticket is stalled. We are awaiting a staff action, an external request completion, or a customer action to confirm the ticket is resolved. We will follow up with this ticket periodically until it is completed.
• Pending: Your ticket is inactive. A staff member will have responded to indicate that we either believe we have resolved your ticket, or that we need more information from you to resolve it. If we do not receive a response, we will send a reminder in three days, and close the ticket after the fourth. We will not revisit this ticket unless you respond to it.
• Closed: Your ticket is completed. A staff member has received confirmation from you that your issue is resolved or we have not heard from you within four days regarding a ticket that was previously pending action from you. If you need to reactivate a closed issue, simply create a new reply to your ticket.

Special Statuses

• Setup: You have an active installation request or order that is in some stage of provisioning. The ticket will be kept in this status until it is actively being completed, then it will be moved to the "In Progress" status. After completion, you will be notified and the ticket will be closed.
• Upgrade: You have an active hardware or service modification which is scheduled, or awaiting parts, or confirmation of scheduling. This status may also be used for tickets involving equipment repairs. Once the request is completed, you will be notified and the ticket will be closed.
• Inbound Ship: Your ticket specifies you have sent a package and that it is en route to the data center. If appropriate, we will update your ticket when the package is received requesting further directions or, if they have been provided, it will be moved to another status as appropriate. Once a package arrives, if we have no handling directions yet, the ticket will be moved to "Pending" and the package will be placed in storage. This status is also used if you have scheduled an in-person work visit until that visit is completed.
• Outbound Ship: Your ticket specifies that a piece of equipment belonging to you should be shipped out of the data center. The ticket will remain in this state while shipping and packing details are confirmed. Once the package shipment is completed, a tracking number will be provided and the ticket will be moved to "Pending."

Non-Support Statuses

• Credited: Most electronic payment methods will result in tickets being created. If your ticket is listed as "Credited" your payment has been acknowledged and credited toward your hosting account. It will remain in this status indefinitely. If there is an issue, you may reply to the ticket to reopen it.
• Forwarded: If your ticket was submitted to our abuse department, it was not able to be handled directly and has been passed downstream or upstream to an appropriate party. Please note that your ticket may not receive any response unless further information is needed and will be closed once we believe the issue has been settled. If in doubt, please reply to provide further details.
• Awaiting Resolution: For tickets from the abuse department, we are monitoring this ticket with high priority awaiting an immediate resolution. Tickets in this state are fast-tracked to the suspended state if the issues mentioned within are not handled quickly and satisfactorily.
• Suspended: If your ticket was submitted to or sent from our abuse department, the resources reported for abuse have been taken offline pending customer action. Please note that your ticket may not receive any response unless further information is needed and will be closed once we believe the issue has been settled or the account is terminated permanently. If your ticket is in the billing department, this status indicates that services will be or have been suspended due to a billing issue.
• DMCA Review: If your ticket was submitted to our abuse department, we are monitoring the resources named in a DMCA notification for removal. The ticket is closed when the resources are removed or upon suspension of the customer systems involved. If the customer files a counter-notification, it will be sent back to the reporter and the ticket closed.

If there is ever an issue with how a ticket is being handled, reply to reopen the ticket. If you require escalation to management, you may request this in the ticket. It will be flagged, kept "open" or "in progress" and reviewed during the same business day.

Newly set up Windows servers can be connected using Remote Desktop Connection. This transmits your desktop across the Internet, allowing connection from a remote location.

Connecting from Windows XP

If you are not running the most recent version (7.0) of the Remote Desktop Client, you can download it from the following link: http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=20609 Note that using an out-of-date version of the Remote Desktop Client will cause issues when connecting to a Windows Server 2008 R2 or 2012 R2 system.

If you get the following message:

"The remote computer requires Network Level Authentication, which your computer does not support. For assistance, contact your system administrator or technical support."

you will need to both upgrade to the newest release of the Remote Desktop Client, and either:

• follow the steps outlined in the following knowledge base article: http://support.microsoft.com/kb/951608/
• Turn off Network Level Authentication in the Remote Desktop settings on your server. (If you need assistance with this, please contact Support)

To connect:

1. Click Start, then All Programs, then Accessories, and finally Remote Desktop Connection.
2. In the Remote Desktop Connection dialog box, enter your server's Main IP address in the Computer: field
3. Click Connect
4. When prompted, enter your Username ("Administrator" by default) and password.

You are now connected to the remote server.

To disconnect:

1. Click Start, and then Log Off

Connecting from Windows Vista or Windows 7

Both Windows Vista and Windows 7 should already have an up-to-date Remote Desktop client installed that can connect to Windows 2008 R2 or 2012 R2 systems.

To connect:

1. Click the Windows logo in the lower left corner of your screen, then All Programs, then Accessories, and finally Remote Desktop Connection.
2. In the Remote Desktop Connection dialog box, enter your server's Main IP address in the Computer: field
3. Click Connect
4. When prompted, enter your Username ("Administrator" by default) and password.
5. If you get a warning that says "The identity of the remote computer cannot be verified", check the "Don't ask me again for this computer" box, and click Yes

You are now connected to the remote server.

To disconnect:

1. Click Start, and then Log Off

Connecting from Windows 8.1

Both Windows 8.1 should already have an up-to-date Remote Desktop client installed that can connect to Windows 2008 R2 or 2012 R2 systems.

To connect:

1. Click the Windows logo in the lower left corner of your screen, type in Remote and click on Remote Desktop Connection. You can also right-click on the icon and pin it to either your start menu or taskbar for easier access moving forward
2. In the Remote Desktop Connection dialog box, enter your server's Main IP address in the Computer: field
3. Click Connect
4. When prompted, enter your Username ("Administrator" by default) and password.
5. If you get a warning that says "The identity of the remote computer cannot be verified", check the "Don't ask me again for this computer" box, and click Yes

You are now connected to the remote server.

To disconnect:

1. Click Start, and then Log Off

Connecting from Mac OS X

Install the Remote Desktop Client for OS X

To connect:

1. Click the Finder icon in the dock, open Applications, and then double-click on Remote Desktop Connection
2. In the Remote Desktop Connection dialog box, enter your server's Main IP address in the Computer: field
3. Click Connect
4. When prompted, enter your Username ("Administrator" by default) and password.

You are now connected to the remote server.

To disconnect:

1. Click Start, and then Log Off

What follows are our welcome messages for both of our backup services

• Jump to rsync backup welcome email
• Jump to R1Soft CDP backup welcome email

rsync Backup Service Welcome Email

Hello,

NOTE: Please read this email message completely, as it contains important information about your new service with Steadfast Networks.

== Account Details ==

Your shell-based backup account is set up and accessible with the following details:

Server: shell01.backup.steadfast.net
User:
Password:

This login information may be used for FTP and SSH access. Rsync instructions are also posted here: http://steadfast.net/support/kb/29

== Account Details ==

You can access our billing and account management interface at the following URL (or you can log in from the login box at the top of any page of our main site) using the information previously sent to you. Your client ID is your login.

URL: https://manage.steadfast.net
Client ID:

== Announcements and Maintenance ==

As many of our customers have expressed that they do not want to receive service notices to the primary contacts within their accounts, we do not notify customers of most routine maintenance and service changes via email. If you would like to be notified when we post an announcement, please visit the following link and enter your email address in the "Subscribe" box on the right side of the page:

https://support.steadfast.net/?_m=news&_a=view

You can also click on the "XML" link in the "Subscribe" box to access an RSS feed of announcements which you can subscribe to in your favorite RSS reader. We also provide links to recent announcements and company blog posts at the bottom of our front page if you prefer to check manually.

== Requesting Technical Support ==

For someone to request support on one of your systems, the email address, name, and phone number MUST be listed as one of the contacts on your account. Additional authorized contacts can be added by accessing our management system and clicking "Client Profile," then "View Profile," and then clicking edit at the top of the "Authorized Contacts" section. This is required for security purposes.

If you have any further support questions, please visit our help desk at https://support.steadfast.net, or email support@steadfast.net. Please be sure to list your backup account username and the server name and as much detail as possible about your problem when requesting support to ensure faster service.

Thank you for your business!

R1Soft CDP Backup Service Welcome Email

Hello,

NOTE: Please read this email message completely, as it contains important information about your new service with Steadfast Networks.

== Account Details ==

Your Idera Server Backup (formerly R1Soft CDP) account has been set up.  You can access the service with the following information:\

URL: https://cdp01.steadfast.net/

Username:

Password:

A volume has been added with the same name as your username.  You can add new hosts for each server with which you want to establish backups up to the limit requested during signup.  See the bottom of this message if you would like to add additional CDP services to your account.

== Documentation ==

Full documentation for getting started and configuration of your backups is provided here:

http://wiki.r1soft.com/display/R1D/Content

== Configuring Your Server ==

You will need to install the agent software on your server and establish a trust relationship in order to configure it within the Idera user interface.

For Linux, most agent setups may be handled through the package manager native to your OS. Use the following guide:

http://wiki.r1soft.com/display/ServerBackup/Installing+Backup+Agent+on+Linux

If you install a new version of the Linux kernel on your system during OS updates, you will need to update the driver by running:

r1soft-setup --get-module --no-binary

service cdp-agent restart

 

For Windows servers, use the following guide:

http://wiki.r1soft.com/display/ServerBackup/Installing+Backup+Agent+on+Windows

 

When prompted during your configuration, you will need to provide the following Public Key and authorize the IP 208.100.0.155 (or 10.1.255.2 if accessing your server via internal network IP address) to create backups of your server:

 

-----BEGIN PUBLIC KEY-----

MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCSljkpVCbfj7iW3+5Ju/WDO+JyO47fV0Mb0TfZ

kvK73pwh795f8VXBa5LtpEVUdflG9IJ2JRhD17nS/S11Meee3QP7goJFLtpqUeFPsrpJsyBVzbBH

5dXPojFp5+DUHHTH6kjeRLX/Hb7BiWQQYOAH2e+itmtPmuS21Mp6nK24kwIDAQAB

-----END PUBLIC KEY-----

 

This key must be placed in a file named simply 208.100.0.155 or 10.2.255.11 in the directory /usr/sbin/r1soft/conf/server.allow

 

== E-mail Reporting ==

IMPORTANT: Backup E-mail Reporting (monitoring) must be set up to inform you of backup failures. Please see http://wiki.r1soft.com/display/ServerBackup/Reporting  for information on how to set up E-Mail Reporting.

 

== Sales and Support ==

If you would like to add additional hosts beyond your current limit, they can be ordered for an additional $10 per month. Additional space may be purchased at any level you require. Please open a ticket with our sales department by emailing sales@steadfast.net to request upgrades.

If you have any further support questions, please visit our help desk at https://support.steadfast.net, or email support@steadfast.net.  Please be sure to list your backup account's username and mention you are using Idera Server Backup.  Include as much detail as possible about your problem when requesting support to ensure faster service.

As per the SLA, any maintenance affecting this backup service will be announced at https://support.steadfast.net/?_m=news&_a=view where you can sign up for the RSS feed or to receive emails when announcements are made.

Thank you for your business!