Helpful Articles

• Do I need a staging server?

  Having separate servers for staging and production environments is a common practice in software development and deployment. Here's why it's beneficial:

  1. Isolation of Environments:

     • Staging Server: This is a replica of the production environment where developers and testers can safely test new features, updates, and configurations. It allows them to identify and fix any issues without affecting the live environment.
     • Production Server: This is the live environment where end-users interact with the application. Any downtime or issues here can have serious consequences, such as loss of revenue or user trust.

  2. Risk Mitigation: By testing in a staging environment, you reduce the risk of introducing bugs, performance issues, or security vulnerabilities into the production environment. This ensures that only stable and thoroughly tested code is deployed to production.

  3. Controlled Rollouts: With separate servers, you can perform controlled rollouts. New features can be gradually introduced in the staging environment, tested, and then deployed to production with confidence.

  4. Testing in a Production-like Environment: The staging server should closely mimic the production environment in terms of configuration, data, and usage patterns. This allows for more accurate testing, ensuring that the behavior of the application in staging will closely resemble its behavior in production.

  5. Data Integrity and Security: Production servers typically handle real user data, which needs to be protected. By keeping staging separate, you can avoid exposing sensitive data during testing. Staging environments often use anonymized or test data to maintain security and privacy.

  6. Continuous Integration/Continuous Deployment (CI/CD): In CI/CD pipelines, separate servers are crucial for automated testing and deployment. The pipeline can automatically deploy to staging for testing and then promote the tested code to production, streamlining the development process.

  7. Rollback and Recovery: If something goes wrong in production, having a separate staging environment allows you to quickly roll back to a previous stable version or diagnose and fix the issue without affecting the live system.

  In summary, separate staging and production servers help ensure that the live environment remains stable, secure, and performant while allowing for thorough testing and risk management in a controlled setting.

• Using jrctl To Perform Privileged Actions

  About

  The JetRails jrctl tool provides access to unprivileged (non root) users to make changes to the firewall and grants ability to restart system services. With access to jrctl, your team has access to commonly needed tools without escalating to server admins.

  Interacting with the firewall

  You can use jrctl to interact with a server’s firewall. This is helpful when reviewing existing firewall entries and whitelisting/blocking IPs. 

  Listing firewall entries

  Run the following command to list current firewall entries for all configured servers (standalone servers and clusters) in your deployment:

  $ jrctl firewall list
  
  SERVER RESPONSE
  127.0.0.1 Found 0 whitelist entries.
  
  No firewall entries found.

  Allowing new IP

  To whitelist a developer or admin user’s IP address 1.1.1.1 to your server/cluster on web ports 80 and 443:

  $ jrctl firewall allow -a 1.1.1.1 -p 80,443
  
  Executed only on "localhost" server(s):
  
  SERVER RESPONSE
  127.0.0.1 Successfully added allow entry for 1.1.1.1 on ports [80 443].

  Notice that the SERVER field lists 127.0.0.1 which means that jrctl is interacting with the local server. If you were managing a cluster, it would display the IP addresses of the systems which are being modified.

  After making changes, you should also check to make sure the changes made are in place. We will do so by listing the current firewall entries again:

  $ jrctl firewall list
  
  SERVER RESPONSE
  127.0.0.1 Found 2 whitelist entries.
  
  SERVER ACTION IPV4/CIDR PORT(S) PROTOCOL(S) COMMENT
  127.0.0.1 ALLOW 1.1.1.1 80 tcp "None"
  127.0.0.1 ALLOW 1.1.1.1 443 tcp "None"

  Note: Notice that there are two entries created, one for every port.

  Disallowing existing IP

  You may find that you need to remove a previously allowed user’s access to your deployment. This might happen if a developer no longer works on your site, or an admin user is no longer working for the company. Below is an example that will unallow1.1.1.1 on www ports 80 and 443.

  $ jrctl firewall unallow -a 1.1.1.1 -p 80
  
  Executed only on "localhost" server(s):
  
  SERVER RESPONSE
  127.0.0.1 Successfully removed allow entry for 1.1.1.1 on ports 80.
  
  $ jrctl firewall unallow -a 1.1.1.1 -p 443
  
  Executed only on "localhost" server(s):
  
  SERVER RESPONSE
  127.0.0.1 Successfully removed allow entry for 1.1.1.1 on ports 443.

  Again, when making changes to the firewall, we recommend to list the current rules before and after making changes. Following the aforementioned advice, you can see that there are no more entries in place.

  $ jrctl firewall list
  
  SERVER RESPONSE
  127.0.0.1 Found 0 whitelist entries.
  
  No firewall entries found.

  Additional abilities: Deny and Undeny

  We just showed how you use the allow and unallow commands. You may also use the deny and undeny commands in a similar way. Since most servers are setup with the firewall being deny-all-first, these commands will be used rarely.

  Allowing Cloudflare IP blocks

  Finally, if your site is behind Cloudflare, you need to give server access to Cloudflare’s IP addresses. You can manually download the list of IP addresses that Cloudflare provides, or you can do it with jrctl. You can simply allow all of Cloudflare’s IPs by running the following:

  $ jrctl firewall allow cloudflare
  
  Executed only on "localhost" server(s):
  
  SERVER RESPONSE
  127.0.0.1 Allowed 30 new Cloudflare IP(s).

  Just as easily, you can remove those entries with the following command:

  $ jrctl firewall unallow cloudflare
  
  Executed only on "localhost" server(s):
  
  SERVER RESPONSE
  127.0.0.1 Un-Allowed 30 Cloudflare IP(s).

  Restarting services

  Once configured, jrctl has the ability to restart services on the local server as well as on an entire Tier of service such as Web Tier, Caching Tier, SQL Tier, etc. This is an advanced configuration which needs to be configured by the JetRails support team.

  When pushing site changes, occasionally some services may need to be restarted in order to view the change on your live or dev site. You can run the following command to show what services are available to be restarted on your server or cluster:

  $ jrctl service list
  
  Filtering servers that match the following type(s): localhost
  
  HOSTNAME SERVER TYPE(S) RESPONSE
  foo.jetrails.com 127.0.0.1 localhost found 4 service(s)
  bar.jetrails.com 127.0.0.2 db found 4 service(s)
  
  HOSTNAME SERVICE STATUS RESTART RELOAD ENABLE DISABLE
  foo.jetrails.com nginx enabled ✔ ✔ ✔ ✔
  foo.jetrails.com php-fpm-7.1 enabled ✔ ✔ ✔ ✔
  foo.jetrails.com php-fpm-7.2 disabled ✔ ✔ ✔ ✔
  bar.jetrails.com mysql disabled ✔ ✔ ✔ ✔

  Restarting services is common practice for when changes need to be made, not only to the environment but also to your website. Below is an example of how to restart php-fpm-7.2 and nginx.

  You are allowed to restart more than one service at a time. Services will be restarted in the order in which they are listed. In this example, php-fpm-7.2 will be restarted first, followed by nginx.

  $ jrctl service restart php-fpm-7.2 nginx
  
  Filtering servers that match the following type(s): localhost
  
  SERVER SERVICE RESPONSE
  127.0.0.1 php-fpm-7.2 successfully restarted "php-fpm-7.2"
  127.0.0.1 nginx successfully restarted "nginx"

  Note: Specifying duplicate arguments to the restart command will restart those services again and execution will occur in the order that said arguments appear in.

  Running security audit

  This functionality gives you the ability to view all SSH activity that occurs on your servers. In addition, the report returns a list of firewall rules that are active on your servers. This report captures information on who, when, where, and how the server(s) were accessed. As a way to keep your servers and sites compliant and secure, it is recommended to regularly review users and connections on your servers. You can access this report by running the following command:

  $ jrctl report audit

  One-Time Secret

  Share sensitive information such as passwords and keys securely via our One-Time Secret service. This service allows users to (optionally) password protect sensitive information and encrypt it during transfer. A unique link is generated to distribute the secret. Once the secret is opened once, it is “burned” and no longer available to view again. If the secret is never viewed, it expires by itself.

  The JetRails team does not have a way to view, or recover, or decrypt your secret payload! Be sure you have a copy of whatever you are sending.

  Additional information

  The jrctl CLI tool is available and accessible through your jump host server. If you have any questions, please reach out to a member of our support team. Also see Using jrctl In Clustered Environments