FAQs

This page answers some of the most frequently asked questions (FAQs) about Magnolia PaaS. It is split into the following high-level sections:

CDN and Site access

Is there a way to manage site traffic spikes?

Expand for answer

Yes. With our premium Fastly Waiting Room feature.

For more, see Fastly Waiting Room.

Can I cache backend responses?

Expand for answer

Yes, you can cache responses from the backend server with some slight tweaks to your Magnolia configuration.

For more on how to do this, see the article here.

How do I set Fastly as my CDN provider for an ingress?

Expand for answer

To set your CDN provider to Fastly in the ingress:

  1. First, Connect to Fastly.

  2. Then, set magnolia.info/cdn-provider to fastly.

    magnolia.info/cdn-provider: fastly (1)
    1 In this example, fastly is set as the CDN provider.

With this setup, you’ll be able to whitelist the IPs necessary for Fastly to retreive pages from the ingress.

For more on whitelisting, see Secure ingresses.

Can I configure a wildcard ingress?

Expand for answer

Yes.

For more on how to do this, check out the dedicated section here.

Do I need extra configuration for CDN caching?

Expand for answer

Only if you are using a headless approach with a frontend server, in this case, you will have to make sure you set the Cache-Control headers with the values you want the CDN to use.

Can I customize the CDN cache configuration?

Expand for answer

For setups that aren’t exclusively headless, yes.

For more on this, see here.

Can I add additional headers to the CDN?

Expand for answer

Yes. However, this is done with an incubator module.

For more on this, see here.

Are 404 errors cached? Can I exclude them?

Expand for answer

Yes the following are cached by default.

  • 200 OK

  • 203 Non-Authoritative Information

  • 300 Multiple Choices

  • 301 Moved Permanently

  • 302 Moved Temporarily

  • 404 Not Found

  • 410 Gone

You can exclude 404 errors. If you want to do this, please contact the HELPDESK.

Doing this could allow bots to hammer your site with requests. By not caching 404 errors, there will be more requests to your backend.

Is the CDN cache flushed automatically after publishing?

Expand for answer

Option 1 You can manually purge the CDN in the Cockpit.

For more details, see the Purge CDN section.

By default, CSS, JavaScript, and images are cached. Pages are not cached by default. However, you can configure your policy to cache Pages.

See Server cache policy for help with that.

Option 2 You can configure a REST Client to trigger CDN cache flushing.

For more details, see Automate flushing of CDN cache.

Development

Can I deploy a frontend with Magnolia PaaS?

Expand for answer

Yes, you can. You can deploy as many frontend applications as you need. In fact, we have a few frontend templates to get you started.

Check them out here.

How do I handle redirects?

Expand for answer

To use redirects in Magnolia PaaS, you’ll create them directly via the Cockpit if you are dealing with more than 10 redirects. If you have fewer than 10, you can manage them directly in a redirects ingress.

We recommend you use the Cockpit redirects option, especially if you have greater than 10 redirects.
For more details, see Redirects.

Can I have a dedicated custom error page per site?

Expand for answer

Yes, you can have a dedicated custom error page per site by using Virtual URI mapping. However, you should always proceed with extra caution when using Virtual URI mapping.

For more details, see Virtual URI mapping.

  1. In your configuration at server/filters/cms/bypasses/, remove the docroot bypass.

  2. In your configuration at server/webContainerResources/mappings/, change /docroot/ to /modules/.

    faq virtualUri mapping valueChange

  3. Now, configure your Virtual URI mapping.

    Example configuration
    class: info.magnolia.virtualuri.mapping.DefaultVirtualUriMapping
fromUri: /docroot/404.html (1)
toUri: forward:/404.html (2)
    1 Routes from the root 404 page (which happens by default).
    2 Routes to the 404 page found in the site tree.

Domains and Certificates

Can I use a wildcard when adding a certificate?

Expand for answer

Yes, you can use the wildcard option for adding a certificate to top-level domains only. This is only applicable for standard certificates, not custom certificates.

For more, see adding certificates from the Cockpit.

General

Is it okay to use ingress-nginx snippets?

Expand for answer

Generally, no. You should only use configuration and/or server snippets exactly as instructed by documentation or the Magnolia PaaS team. Making changes to these snippets without consultation or approval could lead to unintended consequences for your PaaS project.

I want to add snippets for redirect rules. Is this okay?

Expand for answer

No. As stated in Is it okay to use ingress-nginx snippets?, we generally advise against using nginx-ingress configuration and server snippets and you should only use it exactly as instructed by the documentation or the Magnolia PaaS team.

For redirects, use our Redirects feature in the Cockpit.

Are Magnolia PaaS users automatically logged out after a period of inactivity?

Expand for answer

Yes. After 15 minutes of inactivity, the user is automatically logged out of the Cockpit.

Can you send mails with Magnolia PaaS?

Expand for answer

In short, no. This is not currently in scope for Magnolia PaaS.

At the moment, we recommend that you use some of the available external services such as Mailgun, Mailchimp, etc.

The above statement is not an endorsement of any particular service, but is solely intended to provide a starting point for your mail service search.

Helm

How do I find the latest Helm chart version?

Expand for answer

The latest helm chart version is 1.10.0.

Check out the Magnolia helm repo for more details.

I’m upgrading my helm chart, what do I do now?

Expand for answer

When you upgrade your Helm chart because of a major release, like moving from 1.9.0 to 1.10.0, you need to delete the workloads before your next deployment. You also need to recreate the indexes folder from your Author environment.

For more information, see Delete indexes and workloads after Helm upgrade.

How can I access a specific Public?

Expand for answer

You need to create an ingress for each public.

See Creating an ingress for steps on how to do that.

How do I update the helm chart version?

Expand for answer

You need to do it in the .gitlab-ci.yaml file.

...
helm upgrade prod mironet magnolia-helm --version 1.10.0 -f values_new.yml -n prod
...

You need to modify the version, the values file, and the namespace.

Managing PaaS

What is a sticky session?

Expand for answer

Sticky sessions, or session persistence, is when you instruct the load balancer to remain linked to a specific node (server) to avoid losing the session data if the request goes to the other server. Essentially, you send the request from a given IP to the delivery server, but continue to send follow-up requests to the same server until the session expires. Session persistence is needed when the project has transactions or required data in the session.

Sticky sessions are typically used in situations where you have some data in the session and the sessions are not replicated between servers, but you also need to ensure that the data doesn’t get lost.

For more on sticky sessions, see here.
sticky sessions majorTom

How do I configure sticky sessions?

Expand for answer

To enable sticky sessions:

  1. Go to your values.yml file in your Magnolia PaaS project.

  2. Set the following ingress annotations:

    ingress:
  enabled: true
  annotations:
    kubernetes.io/ingress.class: "nginx"
    nginx.ingress.kubernetes.io/proxy-body-size: 512m
    cert-manager.io/cluster-issuer: "letsencrypt-prod"
    nginx.ingress.kubernetes.io/affinity: "cookie" (1)
    nginx.ingress.kubernetes.io/affinity-mode: "persistent" (2)
    nginx.ingress.kubernetes.io/session-cookie-name: "INGRESSCOOKIE" (3)
    nginx.ingress.kubernetes.io/session-cookie-max-age: "10" (4)
    nginx.ingress.kubernetes.io/default-backend: {{ .Env.DEPLOYMENT }}-magnolia-error-page-svc
    nginx.ingress.kubernetes.io/custom-http-errors: "503"
  hosts:
    - host: {{ .Env.DEPLOYMENT }}.eu-playground.magnolia-platform.com
      paths:
          - path: /
            instance: public
          - path: /author
            instance: author
.....
    1 Set nginx.ingress.kubernetes.io/affinity to cookie.
    2 Set nginx.ingress.kubernetes.io/affinity-mode to persistent.
    3 Put the INGRESSCOOKIE at nginx.ingress.kubernetes.io/session-cookie-name.
    4 Set nginx.ingress.kubernetes.io/session-cookie-max-age to the time (in seconds) you want the cookie to persist. After this configured time, the cookie is deleted.

How do I define custom environment variables?

Expand for answer

You can define custom environment variables in the Helm Values file in your project.

To define a varible for the OS

Define the name and value of the variable like so:

...
magnoliaAuthor:
    - name: VARIABLE
      value: "VALUE"
...
To define a varible for the Java Virtual Machine (JVM)

Set the value for the specified object like so:

...
magnoliaAuthor:
  catalinaExtraEnv:
    variable: "VALUE"
...

Can I delete environment indexes?

Expand for answer

Yes you can.

  • Cockpit

  • k8s

To delete the index folders:

  1. Go to Environments > Manage.

  2. Click Delete indexes for the desired environment.

To delete the index folders:

  1. In Rancher, click on the Execute shell navigation item on the desired Author environment.

    rancher execute shell screenshot

  2. Run the following commands:

    cd /mgnl-home/repositories/magnolia/workspaces/ (1)
find . -name index -exec rm -rf {} \; (2)
    1 Changes to your workspaces directory.
    2 Finds and removes the index folders.

Is there a difference between custom error pages and the Fastly maintenance page?

Expand for answer

Yes. The custom error pages are configured at the cluster level. The page won’t work if the cluster is unavailable.

The Fastly maintenance page is at the CDN level. To use this approach, reach out to the Helpdesk for assistance.

How I regenerate a new activation key pair?

Expand for answer

The re-creation of the key pair must be done on the author instance.

  1. Go to AdminCentral.

  2. Open the Publishing Tools app.

    click publishing tools app

  3. Click on Generate new key.

    publishing tools app click generate new key

    The system will create both keys and store them in the magnolia-activation-keypair.properties file. In addition, the system will store the public key in the author system’s JCR.

When using Magnolia PaaS, the keys are automatically distributed to the public instance with the help of a dedicated sidecar.

Setup

What is the minimum Java version needed for PaaS?

Expand for answer

Currently, the minimum supported Java version for Magnolia PaaS is Java 11 (LTS).

For more details, see Set up Magnolia PaaS.

What is the base image used for Magnolia as part of PaaS?

Expand for answer

The recommended base image is:

Key Type Default Description

image.tomcat.tag

string

"9.0-jre11-temurin"

Tomcat repo tag.

This is defined in the image.tomcat.tag helm value. For more, see Helm Values reference.

Can I have standby clusters?

Expand for answer

Yes, you can.

For more on this topic, see Multiregion clusters.

Can I have clusters in different regions?

Expand for answer

Yes, you can.

For more on this topic, see Multiregion clusters.

What is the latest Maven archetype version?

Expand for answer

The latest maven archetype version for the cloud bundle is 1.8.

For more, see Create a project using the Maven archetype.

Security

How do you prevent DDoS attacks?

Expand for answer

To prevent and mitigate DDoS attacks, Magnolia PaaS grants all customers (using Fastly as their CDN):

  • Access to origin shielding

  • Automatic resistance to availability attacks

  • Access to Fastly cache IP space

  • Custom DDoS filter creation abilities

Learn more at Fastly’s Always-on DDos Mitigation page.

What if I’m not using Fastly?

  1. Go to https://ipinfo.io/www.xxx.yyy.zzz (where www.xxx.yyy.zzz is the suspicious IP).

    ipinfo report abuse

  2. Update your values.yml file with the following snippet:

    kind: Ingress (1)
metadata:
  annotations:
    nginx.ingress.kubernetes.io/server-snippet: deny www.xxx.yyy.zzz; (2)
    1 Specifies the kind Ingress.
    2 Denies the specific IP address.
    Only use the `server-snippet` exactly as instructed. Otherwise, you may cause issues with your PaaS deployment.
For more details, see Preventing DDoS attacks.

What happens if the WAF detects attacks?

Expand for answer

WAF Intro

Web Application Firewalls, or WAFs, protect web applications from common malicious attacks such as cross-site-scripting (XSS) and SQL injections. Essentially, they act as a type of wall or shield between your web application and the internet. If you have your own CDN for your project, you’ll likely have your own WAF.

If you choose to go with the default CDN for Magnolia PaaS, you’ll be protected with the Fastly WAF.

The Fastly WAF inspects the web traffic at the HTTP application layer by looking at all HTTP and HTTPS requests (both header and body included). This can be configured specifically for your deployment.

What happens if attacks are detected?

If the WAF detects any of the owasp or application-multi attacks, it automatically blocks the request. If they detect there is an increased volume of requests, Fastly notifies us at Magnolia, and we perform a security review.

If needed, we send the logs to you to check if the requests have come form the same IP and if the requests are legitimate or not. If you need to block the IP, you can do it through the cockpit.

We encourage you to use the cockpit. However, if you feel you need to, you can request our help directly with the issue.

See Web Application Firewall (WAF) for more details.

What type of security do we have for REST requests?

Expand for answer

There are three levels of control when REST requests are issued:

  • Web access

  • JCR access

  • Command-level access

Permissions to issue REST requests are controlled using Magnolia’s standard role-based security mechanism.

The rest-anonymous role is handled differently in Magnolia PaaS than in on-prem Magnolia.

Table 1. Web access
Permission Path

Requests within PaaS all require a valid JSON Web Token (JWT) which is only available to the Magnolia Bootstrap sidecar.

Get & Post

/.rest/configuration/*

Get & Post

/.rest/cloud/*

Get

/.rest/status

For more details on rest security generally for Magnolia, see REST security.

Feedback

PaaS

×

Location

This widget lets you know where you are on the docs site.

You are currently perusing through the Magnolia PaaS docs.

Main doc sections

DX Core Headless PaaS Legacy Cloud Incubator modules