Merge pull request #28 from cloud-gov/chore-knowledgebase-migration

added knowledge base from cg-site and configured permalinks

content/knowledge-base/articles/2021-05-17-troubleshooting-ssh-connections.md

@@ -0,0 +1,58 @@
+---
+layout: layouts/post
+title: "Troubleshooting SSH Connections"
+date: 2021-05-17 00:00:00 +00:00
+author:
+description: Some tips and tricks for logging into app instances using SSH
+excerpt: Some tips and tricks for logging into app instances using SSH
+tags:
+  - posts
+---
+
+**UPDATE: As of November 28, 2022, cloud.gov only supports connecting to applications using SSH over port 2222. It is no longer possible to use port 22 to connect to applications over SSH.**
+
+This post will help you troubleshoot issues when [connecting to your app using SSH](https://docs.cloudfoundry.org/devguide/deploy-apps/ssh-apps.html).
+
+Some things to check:
+
+* Check which version of the `cf` CLI tool you are using. The approaches listed below may vary based on whether you are using v6 or v7 od the CLI tool.
+* Make sure you have SSH access enabled. You can check to see if SSH is enabled by running `cf ssh-enabled APP_NAME`. Enable it by running `cf enable-ssh APP_NAME`.
+* If you recently enabled SSH access to your application using the approach above, ensure that you have also run `cf restart APP_NAME` so that the changes can take effect.
+* Make sure you are not in an environment that blocks outgoing traffic on port 2222 (the default port for `cf ssh` traffic). Some offices or corporate locations may block traffic on this port.
+
+### Working around port blocking
+
+`cf ssh` uses port 2222. If your network blocks port 2222, you may receive an error message such as `Error opening SSH connection` or `psql: could not connect to server: Connection refused`.
+
+It is possible your internet service provider or network provider will block traffic on port 2222. You can work around this by using a VPN (like the GSA VPN) or using a native ssh client and following the instructions below.
+
+1. Retrieve the APP_GUID for your app: `cf app APP_NAME --guid`.
+2. Retrieve a one-time ssh passcode using `cf ssh-code`. You will be prompted for this code below.
+3. Use `ssh` (not `cf ssh`) to connect to your app container. Substitute the value for your APP_GUID: `ssh -p 22 cf:APP_GUID/0@ssh.fr.cloud.gov`. You will be prompted to enter a password. Use the one-time ssh passcode you generated in step 2.
+
+This will open an ssh connection using port 22 to your app instance with index of 0. If you need to connect to a different instance, replace the `0` in the command above.
+
+Note - If this approach does not work for you, and you see an error that says **Permission denied, please try again.**, then you should review the section below on changes to your application in the CAPI.
+
+### Changes to your app in the CAPI
+
+If you are still experiencing trouble connecting to your app using SSH, it may be the result of some changes in a newer version of the Cloud Foundry API (CAPI). In prior versions of the CAPI, app instances used a single process. In version 3 of the CAPI, there can be more than 1 process that makes up an app. This may occasionally cause issues when trying to SSH to your app.
+
+If a modification or update was made to an app using a v3 command or process - even if that change was made by someone else (e.g., another member of a development team) - the app’s schema in the Cloud Controller might have changed to version 3, and a standard cf ssh may no longer work.
+
+#### Using v6 of the cf CLI
+
+If this occurs and you are using v6 of the `cf` CLI, you can try using `cf v3-ssh {app-name}`. By default a cf v3-ssh will select the `web` process. You can also select a different process if needed with v3-ssh using the `--process` flag.
+
+You may also want to upgrade your version of the CLI tool. [v7 of this tool](https://github.com/cloudfoundry/cli/wiki/V7-CLI-Installation-Guide) automatically connects to the `web` process.
+
+#### Using other utilities
+
+If you need to use a tool like `scp` or a native `ssh` utility to connect to your application instance, you may need to take a slightly different approach. You want to obtain the GUID for the **web** process for your application.
+
+1. Retrieve the PROCESS_GUID for the web process for your app: `cf curl /v3/apps/$(cf app APP_NAME --guid)/processes | jq --raw-output '.resources | .[] | select(.type == "web").guid'` (note - assumes that you have [jq installed](https://stedolan.github.io/jq/)).
+
+(The remaining steps are identical to those listed in the prior section, except instead of using the APP_GUID, you will use the PROCESS_GUID you just identified to connect to your application.)
+
+2. Retrieve a one-time ssh passcode using `cf ssh-code`. You will be prompted for this code below.
+3. Use `ssh` (not `cf ssh`) to connect to your app container. Substitute the value for your APP_GUID: `ssh -p 22 cf:PROCESS_GUID/0@ssh.fr.cloud.gov`. You will be prompted to enter a password. Use the one-time ssh passcode you generated in step 2.

content/knowledge-base/articles/2021-05-20-connecting-to-brokered-service-instances.md

@@ -0,0 +1,19 @@
+---
+layout: layouts/post
+title: "Connecting to brokered Elasticsearch service instances"
+date: 2021-05-20 00:00:00 +00:00
+excerpt: Some suggestions for connecting to brokered Elasticsearch instances
+tags:
+  - posts
+---
+
+For compliance purposes, brokered Elasticsearch service instances may only be accessed from within the cloud.gov environment. Additionally in order to connect to these instances, AWS requires the use of [signed HTTP headers](https://docs.aws.amazon.com/elasticsearch-service/latest/developerguide/es-request-signing.html). If you plan to connect to your Elasticsearch instance from your local environment frequently, this can present challenges.
+
+Some things to consider:
+
+* The brokered Elasticsearch instances are not well suited for running your own logging stack (if that's what you are trying to do), and are designed to be used for data storage in conjunction with an application running on cloud.gov.
+* If you need to capture or analyze log data from your application, some better options include using the [cloud.gov logging dashboard](https://cloud.gov/docs/deployment/logs/#web-based-logs-with-historic-log-data), or setting up a [log drain to offload platform logs](https://cloud.gov/docs/deployment/logs/#how-to-automatically-copy-your-logs-elsewhere) to an external logging tool or platform.
+
+If you do need to directly interact with your cloud.gov Elasticsearch instance you can configure and deploy a basic proxy application similar to the [example that can found here](https://github.com/cloud-gov/aws-elasticsearch-auth-proxy) - please note the documented security considerations.
+
+

content/knowledge-base/articles/2021-05-20-getting-rds-version-information.md

@@ -0,0 +1,18 @@
+---
+layout: layouts/post
+title: "Getting RDS version information"
+date: 2021-05-20 00:00:00 +00:00
+excerpt: Find out what version of AWS RDS version your app is using
+tags:
+  - posts
+---
+
+The dedicated plans listed in the [RDS Services page](https://cloud.gov/docs/services/relational-database/) (marked “AWS RDS Latest”) deploy the default version as advertised by AWS. 
+
+There is currently no way to verify ahead of time the version of an RDS service that will be deployed by the cloud.gov broker, but you can check the version once an instance has been created by connecting to that instance using the cf-service-connect plugin.  Once the database prompt appears, run the command that matches the database you're using:
+
+- PostgreSQL:  `SELECT version();`
+- MySQL:  `SELECT VERSION();`
+- Oracle:  `SELECT * FROM v$version;`
+
+Note that you can also look at the AWS RDS User Guides for [PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_PostgreSQL.html#PostgreSQL.Concepts.General.DBVersions), [MySQL](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_MySQL.html), and [Oracle](Oracle) for version information, but these documents sometimes lists versions that are not yet available on AWS GovCloud.

content/knowledge-base/articles/2021-05-20-managing-buildpack-changes.md

@@ -0,0 +1,24 @@
+---
+layout: layouts/post
+title: "Managing buildpack changes"
+date: 2021-05-20 00:00:00 +00:00
+excerpt: If your application's behavior changes unexpectedly without code changes, it might be related to a new buildpack release
+tags:
+  - posts
+---
+
+If you notice strange behavior in your application, or if builds / deployments are not working properly and no coding changes were made, one possible cause could be changes to the [buildpack](https://cloud.gov/docs/getting-started/concepts/#buildpacks) used by your application.
+
+Some things to check:
+
+* You can check which buildpack and version your app is using by running `cf app APP_NAME`
+* You can check the latest version of cloud.gov system buildpacks by running: `cf buildpacks`
+* You can check the latest buildpack release version by checking the releases page in the appropriate buildpack GitHub repository: `https://github.com/cloudfoundry/{BUILDPACK-TYPE}-buildpack/releases`
+
+New buildpack versions are released often to update components and address security vulnerabilities. When a new buildpack is available (either via a reference to a buildpack URL or a system buildpack), it will be picked up and used by your application when you do a `cf restage`.
+
+Buildpack changes can sometimes cause unexpected behavior because of changes in a runtime, component, or dependency. You should carefully read the release notes for new buildpack releases to ensure that changes don't adversely impact your application. If you suspect that a buildpack update may be causing issues with your application, you can validate it by using an earlier version of a buildpack to see if a new release includes a breaking change.
+
+To use a specific version of a buildpack, you can do a `cf push` with the `--buildpack` or `-b` option and reference a specific release. For example: `cf push APP_NAME -b https://github.com/cloudfoundry/java-buildpack.git#v3.3.0`. 
+
+It may help to experiment by doing `cf push` with a prior release to see if this resolves the issue. If it does, you can modify your application to ensure it works properly with the latest buildpack release.

content/knowledge-base/articles/2021-05-24-secureauth-issues.md

@@ -0,0 +1,39 @@
+---
+layout: layouts/post
+title: "Trouble Logging in to cloud.gov"
+#permalink: knowledge-base/2021-05-24-secureauth-issues/
+date: 2021-05-24 00:00:00 +00:00
+excerpt: If you see an error while logging into cloud.gov, these tips can help you troubleshoot
+tags:
+  - posts
+---
+
+## If you are using GSA's single sign on integration (SecureAuth)
+
+When logging in to cloud.gov, you may encounter an error message that includes reference to `InResponseToField`. For example, something like:
+
+```shell
+InResponseToField of the Response doesn’t correspond to sent message {code}
+```
+
+This is typically caused by SecureAuth having an old certificate or session cookie in your browser, and is not related to the cloud.gov platform. 
+
+Things you can check:
+
+* You can verify this issue is affecting your login by opening a private or incognito session in your browser and retry logging in. 
+
+* You can try clearing all cache and cookies, restart your browser, and retry logging in.
+
+If these steps don't work, [GSA also has a tool that can clear these items](https://secureauth.gsa.gov/secureauth2/cleancert.aspx). Note - if you are a Mac user, this site will only work in Safari.
+
+## If you are using the cloud.gov identity provider (IDP)
+
+For users that log in with the cloud.gov IDP, if a user hasn't logged in in 90 days their account will be deactivated for security purposes. You should receive an email notice when a deactivation is imminent, and you may experience receiving SAML errors when logging in (even after a password reset).
+
+Some things you can try:
+
+* Clear your browser cookies and cache, and try again.
+* If you think you have logged in during the previous 90 days, you can try a [password reset](https://cloud.gov/docs/getting-started/accounts/).
+* If you think your account may have been deactivated, you can check your spam folder in the event that the notice was inadvertently routed there.
+
+If your account was deactivated because of inactivity, your org manager must request a reactivation of your user account. Have your org manager send a request to [support@cloud.gov](mailto:support@cloud.gov) with the name and email address for the account that needs to be reactivated.

content/knowledge-base/articles/2021-07-26-app-restarts.md

@@ -0,0 +1,50 @@
+---
+layout: layouts/post
+title: "Questions About App Restarts"
+date: 2021-07-26 00:00:00 +00:00
+excerpt: When do application restarts happen and what do they mean
+tags:
+  - posts
+---
+
+Application restarts are a common occurrence on the cloud.gov platform, as our operators [regularly deploy updates to the various system components](https://cloud.gov/docs/deployment/app-maintenance/#operating-system-patching). This can sometimes cause confusion as application developers or system owners may interpret restarts as an issue with the way their application is built or functions.
+
+### What happens when an app crashes?
+
+When an app instance running on cloud.gov crashes for some reason (e.g., an unhandled exception occurs in your application code), the platform will automatically try to restart it. The platform automatically restarts your app by rescheduling the instance on another container 3 times. After 3 failed restarts, the platform [gradually increases the amount of time between restart attempts](https://docs.cloudfoundry.org/devguide/deploy-apps/app-lifecycle.html#crash-events).
+
+### What else causes app restarts?
+
+Certain maintenance activities undertaken by the cloud.gov team require restarting VMs with containers hosting app instances. For example, when we update stemcells or installs a new version of Cloud Foundry - the software that [underlies cloud.gov](https://cloud.gov/docs/overview/what-is-cloudgov/) - all the VMs in the deployment are restarted.
+
+Cloud Foundry automatically relocates the instances on VMs that are shutting down through a process called "evacuation." Cloud Foundry recreates the app instances on another VM, waits until they are healthy, and then shuts down the old instances. During this  process, apps running a single instance may become temporarily unavailable if the replacement instance does not become healthy within the platform’s operation timeout, which defaults to 10 minutes.
+
+This underscores the importance of running [multiple instances of your application](https://cloud.gov/docs/management/multiple-instances/) to ensure that app restarts do not result in downtime. 
+
+
+### How can I tell what is causing my app to restart?
+
+The easiest thing to check is the day of the week. Our operators perform platform maintenance that could result in your app restarting from **Tuesday through Thursday** each week. Application restarts that occur on these days are often related to platform maintenance and deployments.
+
+Additionally, if you are seeing app restarts in your application logs, you can usually discern if the cause is platform maintenance or if there is an issue causing your app to crash.
+
+During regular platform maintenance, you may see log entries that look like the following that indicate the evacuation process for restarting apps:
+
+```shell
+[CELL/0] OUT Cell fa1c44d16280de789416ecae0161d774 requesting replacement for instance 72aa902bd0e5852e8413002a9a6eb46c
+[CELL/0] OUT Cell fa1c44d16280de789416ecae0161d774 creating container for instance 72aa902bd0e5852e8413002a9a6eb46c
+[CELL/0] OUT Cell fa1c44d16280de789416ecae0161d774 successfully created container for instance 72aa902bd0e5852e8413002a9a6eb46c
+
+```
+
+When an app crashes for some reason, the log signature looks very different. For example, here are some logs generated when an app crashes due to an unhandled exception:
+
+```shell
+2021-07-27T10:49:02.95-0400 [API/1] OUT Process has crashed with type: "web"
+2021-07-27T10:49:03.02-0400 [PROXY/0] OUT Exit status 137
+2021-07-27T10:49:03.03-0400 [API/1] OUT App instance exited with guid 975f3c9543c5a8069ca04a1ee56d83a8 payload: {"instance"=>"0d8ecfd137c9de128e557c3f7d539b32", "index"=>0, "cell_id"=>"b701ee4f-885a-4c07-80c1-036e3d494e0a", "reason"=>"CRASHED", "exit_description"=>"APP/PROC/WEB: Exited with status 1", "crash_count"=>1, "crash_timestamp"=>1627397342782032276, "version"=>"6d3ba3a9-f72a-451c-a13a-f5033e1fa39a"}
+2021-07-27T10:49:03.26-0400 [CELL/0] OUT Cell 47c65d8bcaf81e837dff0037ea75e2a9  successfully destroyed container for instance 0d8ecfd137c9de128e557c3f7d539b32
+2021-07-27T10:49:03.48-0400 [CELL/0] OUT Cell bda99bfd4a206845400ffb0aa9806516  successfully created container for instance 6d4190c228fffa472fa13c200f43e404
+```
+
+If you are unsure what caused an app restart, check the day of the week and review the details of your application logs.

content/knowledge-base/articles/2021-09-15-creating-external-domain-service.md

@@ -0,0 +1,23 @@
+---
+layout: layouts/post
+title: "Issues setting up an external domain service"
+date: 2021-09-15 00:00:00 +00:00
+excerpt: Some tips on how to address issues when setting up a new external domain service
+tags:
+  - posts
+---
+
+If you are trying to set up an external domain service for your website or application, you may encounter specific error messages that indicate a problem setting up your new service. Specifically, one error message you might encounter when creating a new external domain service looks like this:
+
+```shell
+You are not authorized to perform the requested action
+```
+
+This error is a result of the wrong role being set for the user attempting to create the new service. Some user with the `SpaceManager` role may assume that they have sufficient privileges to create a new service. However, in order to create a new service within your org or space a user must have the `SpaceDeveloper` role.
+
+Some things you can do:
+
+* You can check the existing roles in an organization by executing `cf org-users ORGANIZATION-NAME`
+* If you do not currently have the `SpaceDeveloper` role, a space manager can add it by executing `cf set-org-role USERNAME ORGANIZATION-NAME SpaceDeveloper`.
+
+Users with a `SpaceDeveloper` role should be able to create an external domain service without issue. More information on roles [can be found here](https://docs.cloudfoundry.org/adminguide/cli-user-management.html).