AH00558: apache2: Could not reliably determine the server's fully qualified domain name

[steled]

Describe the bug After applying the helm chart I see the following error in the logs:

$ kubectl logs -n nextcloud nextcloud-7bd4647bbf-kc4wp -f
AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 10.244.0.125. Set the 'ServerN                                         ame' directive globally to suppress this message
AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 10.244.0.125. Set the 'ServerN                                         ame' directive globally to suppress this message

Version of Helm and Kubernetes:

$ kubectl version
Client Version: version.Info{Major:"1", Minor:"21", GitVersion:"v1.21.0", GitCommit:"cb303e613a121a29364f75cc67d3d580833a7479", GitTreeState:"clean", BuildDate:"2021-04-08T16:31:21Z", GoVersion:"go1.16.1", Compiler:"gc", Platform:"linux/arm64"}
Server Version: version.Info{Major:"1", Minor:"21", GitVersion:"v1.21.0", GitCommit:"cb303e613a121a29364f75cc67d3d580833a7479", GitTreeState:"clean", BuildDate:"2021-04-08T16:25:06Z", GoVersion:"go1.16.1", Compiler:"gc", Platform:"linux/arm64"}

$ helm version
version.BuildInfo{Version:"v3.5.3", GitCommit:"041ce5a2c17a58be0fcd5f5e16fb3e7e95fea622", GitTreeState:"dirty", GoVersion:"go1.15.8"}

Which chart: nextcloud:2.6.1

What happened: The error AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 10.244.0.125. occurs.

What you expected to happen: normal startup of nextcloud without an error message

How to reproduce it (as minimally and precisely as possible): apply the helm chart

Anything else we need to know: As a workaround I can add the following lines of code to my values.yaml file:

lifecycle:
  postStartCommand: ["/bin/sh", "-c", "echo \"ServerName 172.16.4.35\" | tee -a /etc/apache2/apache2.conf"]

But this is not how I expect that it should work like.

[magsol]

I have also encountered this error. I am using nextcloud:21.0.4-apache arm64 image on a k3s cluster running on 5x Raspberry Pis. kubectl version 1.21.5, helm version 3.6.3.

[magsol]

@steled What IP address are you putting in for ServerName (172.16.4.35)? Is that the IP of your load balancer? Or the external IP?

[steled]

This is the IP for nextcloud I configured at the loadbalancer.

[magsol]

@steled Sorry--I'm new to this--where did you configure this IP for the nextcloud loadbalancer?

[hannesknutsson]

Did you solve this? My Nextcloud on k8s deployed using the official Helm chart version 2.11.3 has failed and is displaying the above error in the logs.

AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 10.244.1.227. Set the 'ServerName' directive globally to suppress this message
AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 10.244.1.227. Set the 'ServerName' directive globally to suppress this message
[Mon Feb 21 20:51:55.205558 2022] [mpm_prefork:notice] [pid 1] AH00163: Apache/2.4.51 (Debian) PHP/8.0.14 configured -- resuming normal operations
[Mon Feb 21 20:51:55.205593 2022] [core:notice] [pid 1] AH00094: Command line: 'apache2 -D FOREGROUND'

I haven't changed anything in my values.yaml for weeks, so I have no idea why it is suddenly failing.

[magsol]

@hannesknutsson I have not, though in all fairness I haven't been able to come back to this since my last update; work has been overwhelming.

[steled]

@magsol sorry for my very late response...

See below a snippet for the service configuration in my values.yaml file:

service:
  type: LoadBalancer
  port: 8080
  loadBalancerIP: 172.16.4.35

[J0han3s]

I have same issue

[DreamingRaven]

I have the same issue too:

• Kubernetes components version v1.25.2
• CRI: CRI-O v1.25.0
• CNI: Calico
• Nextcloud: nextcloud helm 2.10.0
• Helm v3.10.0

with values:

startupProbe:
  enabled: true

hpa:
  enable: true
  minPods: 3
  maxPods: 5

image:
  repository: nextcloud
  tag: 22-apache
  pullPolicy: Always

nextcloud:
  host: nextcloud.<**MYDOMAIN**>
  existingSecret:
    enabled: true
    secretName: nextcloud-user
    usernameKey: username
    passwordKey: password

internalDatabase:
  enabled: false

externalDatabase:
  enabled: true
  host: "nextcloud-mariadb-helm:3306"
  existingSecret:
    secretName: mariadb-user
    usernameKey: mariadb-username
    passwordKey: mariadb-password

persistence:
  enabled: true
  size: 3T
  storageClass: nextcloud-main

AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 10.85.191.90. Set the 'ServerName' directive globally to suppress this message
AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 10.85.191.90. Set the 'ServerName' directive globally to suppress this message
[Thu Oct 06 11:40:31.646512 2022] [mpm_prefork:notice] [pid 1] AH00163: Apache/2.4.54 (Debian) PHP/8.0.22 configured -- resuming normal operations
[Thu Oct 06 11:40:31.646532 2022] [core:notice] [pid 1] AH00094: Command line: 'apache2 -D FOREGROUND'
192.168.1.134 - - [06/Oct/2022:11:41:08 +0000] "GET /status.php HTTP/1.1" 500 425 "-" "kube-probe/1.25"
192.168.1.134 - - [06/Oct/2022:11:41:18 +0000] "GET /status.php HTTP/1.1" 500 425 "-" "kube-probe/1.25"
...

Is there a nicer way to pass in the server name rather than a postStartCommand hook? Also why was this only the case recently? Has something changed in source?

EDIT: although I realize now that this issue was reported ages ago now, so maybe not so recent after all hmm.

[DreamingRaven]

Whoops never mind ignore me. It was actually MariaDB. That ServerName was a red herring. I sorted mariadb which was a version bitnami dropped, now that its upgraded everything works fine.

[jessebot]

This issue can be a lot of things, and there's a few different people needing help, so if anyone is still having trouble, if you could please post as much of your values.yaml as possible as well as the current helm chart version you're using? It would help a lot in troubleshooting this.

Regardless, I'll leave this open for a good while to allow @steled, @magsol, @hannesknutsson, and @gkchim to follow up.

[steled]

@jessebot I'm using the helm chart version 3.1.2, see below my values.yaml file:

ingress:
  enabled: true
  annotations:
    kubernetes.io/ingress.class: nginx
    cert-manager.io/cluster-issuer: duckdns-webhook-cert-manager-webhook-duckdns-${environment}
    nginx.ingress.kubernetes.io/proxy-body-size: 32M
    nginx.ingress.kubernetes.io/server-snippet: |-
      location = /.well-known/carddav {
        return 301 $scheme://$host/remote.php/dav;
      }
      location = /.well-known/caldav {
        return 301 $scheme://$host/remote.php/dav;
      }      
  tls:
    - secretName: nextcloud-tls
      hosts:
        - ${nextcloud_domain}

#securityContext:
#  runAsGroup: 1000
#  runAsNonRoot: true
#  runAsUser: 1000

lifecycle:
  postStartCommand: ["/bin/sh", "-c", "echo \"ServerName ${ip_address}\" | tee -a /etc/apache2/apache2.conf"]

nextcloud:
  host: ${nextcloud_domain}

  existingSecret:
    enabled: true
    secretName: nextcloud-secret

  configs:
    custom.config.php: |-
      <?php
      $CONFIG = array (
        'encryption.legacy_format_support' => false,
        'default_phone_region' => 'DE',
      );      

  extraEnv:
    - name: OVERWRITEHOST
      value: ${nextcloud_domain}
    - name: OVERWRITEPROTOCOL
      value: https
    - name: TRUSTED_PROXIES
      value: ${nextcloud_proxies}

  mail:
    enabled: true
    fromAddress: ${mail_fromaddress}
    domain: ${mail_domain}
    smtp:
      host: ${smtp_host}
      secure: ${smtp_secure}
      port: ${smtp_port}
      authtype: ${smtp_authtype}

cronjob:
  enabled: true

internalDatabase:
  enabled: false

externalDatabase:
  enabled: true
  type: postgresql
  host: nextcloud-postgresql.nextcloud.svc.cluster.local:5432
  user: ${externaldatabase_user}
  password: ${externaldatabase_password}
  database: ${externaldatabase_database}

postgresql:
  auth:
    postgresPassword: ${postgresql_postgresqladminpassword}
    username: ${postgresql_postgresqlusername}
    password: ${postgresql_postgresqlpassword}
    database: ${postgresql_postgresqldatabase}
  image:
    repository: postgres
    # check version here: 
    # - https://github.com/nextcloud/helm/blob/master/charts/nextcloud/Chart.yaml
    # - https://github.com/bitnami/charts/blob/master/bitnami/postgresql/Chart.yaml
    # - https://hub.docker.com/_/postgres?tab=tags
    tag: 11.6
    pullPolicy: IfNotPresent
  enabled: true
  primary:
    persistence:
      enabled: true
      existingClaim: nextcloud-postgresql-pvc
    extraVolumes:
      - name: backup
        persistentVolumeClaim:
          claimName: nextcloud-backup-pvc
    extraVolumeMounts:
      - name: backup
        mountPath: /backup

service:
  type: LoadBalancer
  port: 8080
  loadBalancerIP: ${ip_address}

persistence:
  enabled: true
  storageClass: "-"
  existingClaim: nextcloud-server-pvc
  accessMode: ReadWriteOnce
  size: 8Gi

livenessProbe:
  initialDelaySeconds: 240

readinessProbe:
  initialDelaySeconds: 240

[jessebot]

@steled, at first glance, everything seems okay. Could you clarify:

• is ${nextcloud_domain} an IP or FQDN?
• is ${ip_address} the 172.16.x or 10.x IP?
• which load balancer are you using? which k8s distro is this?

For my service config, I'm using this, and I'm using the nginx-ingress-controller, but I'm using metallb for actually getting IPs from a configured pool:

  service:
    type: ClusterIP
    port: 8080

There is a bit of info in the readme about preserving source IP, but I'm unsure if this is related. Off the top of my head, it looks like it wants to use the k8s internal IPs rather than the node IPs, but I'd need to look more into this and test it to be sure.

@provokateurin or @tvories have either of you seen this with apache? I am using nginx for my setup, so my experience is more geered towards that web server.

[steled]

@jessebot:

• ${nextcloud_domain} is the FQDN *.duckdns.org
• ${ip_address} is the 172.16.x.y address

I'm also using metallb.

[MohammedNoureldin]

Just as documentation, I had the exact same issue unexpectedly. Manipulating the configs of Nextcloud did not help. I just removed the whole helm with PVCs and redeployed and it works again.

Of course, deleting everything is not an option in production, just maybe something went wrong during my development in the data in the database. That is why redeploying helped.

[kahirokunn]

I got the same error.