cclloyd's questions

I'm using oauth2-proxy/oauth2-proxy with Keycloak-oidc provider for authentication for some pods in my Kubernetes cluster.

I can specify which groups are allowed to access a resource using the --allowed-group argument such as below

- --allowed-group="/vm-users/vm-editors/vm-admins"

Which restricts login to members of the vm-admins group.

But when I set it to /vm-users/vm-editors to login, I'm no longer allowed, as I have an indirect membership to vm-editors (It's set in FreeIPA, the user federation for keycloak, so that members of the vm-admins group are also members of the vm-editors group).

I've tried /vm-users/vm-editors, /vm-users/vm-editors*, /vm-users/vm-editors/*; none of which work.

Is there a way to handle implicit/indirect group membership in this instance?

When running kubectl, I get the error

Unable to connect to the server: x509: certificate has expired or is not yet valid: current time 2021-10-05T11:59:14-04:00 is after 2021-09-29T19:21:40Z

So clearly it says the cert is expired. Only problem is I'm not sure which cert it is.

I've checked

• HAProxy (Rancher sits behind L7 HAProxy with LE cert)
• Certs in the secrets shown from sudo k3s kubectl get secrets -n cattle-system
• Certs in /etc/kubernetes/ssl on the K8s node

All are fine (not expired), as this particular rancher/k8s instance was brought up in June, so all the certs are only a few months old, and expire either 1 year or 10 years later.

So what cert is expired that needs to be updated?

Some information about my setup:

• Rancher 2.5.9 HA (K3s v1.21.1+k3s1) (single-node, Ubuntu 20.04)
• Kubernetes 1.20.9-rancher1-1 (single-node, Control plane/Worker/etcd, Ubuntu 20.04)

I'm setting up Wireguard to tunnel from a cloud VM to our internal network. The local server is using the Wireguard plugin for OPNSense.

OPNSense acts as firewall, dhcp, etc.
The cloud VM is not behind any firewall or anything.

Server:

interface: wg0
  public key: redacted
  private key: (hidden)
  listening port: 42001

peer: redacted
  endpoint: CLOUD_VM_PUBLIC_IP:42001
  allowed ips: 10.0.1.42/32
  latest handshake: 48 seconds ago
  transfer: 184.23 KiB received, 186.37 KiB sent
  persistent keepalive: every 21 seconds

Client:

  public key: redacted
  private key: (hidden)
  listening port: 42001

peer: redacted
  endpoint: LOCAL_PUBLIC_IP:42001
  allowed ips: 10.0.0.0/16
  latest handshake: 2 minutes, 14 seconds ago
  transfer: 1.30 KiB received, 1.20 KiB sent
  persistent keepalive: every 21 seconds

Client config:

[Interface]
# set address to next address
Address = 10.0.1.42/16
ListenPort = 42001
PrivateKey = redacted
DNS = 1.1.1.1

[Peer]
PublicKey = redacted
Endpoint = LOCAL_PUBLIC_IP:42001
AllowedIPs = 10.0.0.0/16
PersistentKeepalive = 21

With this configuration, I can connect to the VM using the internal IP address 10.0.1.42 on OPNSense, but anything else shows 'Destination Host Unreachable'. And trying to ping any internal ip in 10.0.0.0/16 from the cloud VM times out.

I have GitLab installed in Kubernetes with their Helm chart.

I migrated my old Gitlab deployment from one cluster to another with the following steps:

• Scale down all pods in old cluster
• Apply values.yml with helm to new cluster (to create PVCs)
• Scale down all pods in new cluster
• Change DNS records, HAProxy, etc
• Manually rsync data from old PVCs to new PVCs (minio, gitaly, redis, postgres, prometheus)
• Run helm upgrade to bring deployments back online in new cluster

After all that the deployment for the most part works fine. Able to login and use git.

But the runner is failing to register, so I can't run any CI. Looking at the gitlab-gitlab-runner pod, I see the message below repeated over and over:

Registration attempt 30 of 30
Runtime platform                                    arch=amd64 os=linux pid=691 revision=3b6f852e version=14.0.0
WARNING: Running in user-mode.
WARNING: The user-mode requires you to manually start builds processing:
WARNING: $ gitlab-runner run
WARNING: Use sudo for system-mode:
WARNING: $ sudo gitlab-runner...
 
ERROR: Registering runner... failed                 runner=y6ixJoR1 status=500 Internal Server Error
PANIC: Failed to register the runner. You may be having network problems.

As you can see, it's failing to register the runner. Trying to go to /admin/runners gives me a 500 error.

Where can I see more information as to why I am getting this 500 error?

I'm trying to set up a rook Ceph cluster on my kubernetes cluster.

Topography:

• 3 kubernetes nodes (all are master/worker pods)
• Each node has /dev/vdX on it for ceph
• Each node is intended to work as part of the ceph cluster

I deployed Rook operator with the helm chart with the following values:

image:
  tag: v1.5.8
  pullPolicy: IfNotPresent

resources:
  limits:
    cpu: 500m
    memory: 256Mi
  requests:
    cpu: 100m
    memory: 256Mi
enableFlexDriver: false
enableDiscoveryDaemon: true

After that was fully initialized, I tried creating a cluster with the following manifest.

apiVersion: ceph.rook.io/v1
kind: CephCluster
metadata:
  name: maincluster
  namespace: rook
spec:
  cephVersion:
    image: ceph/ceph:v15.2.9
  dataDirHostPath: /var/lib/rook
  mon:
    count: 3
    allowMultiplePerNode: false
  mgr:
    modules:
    - name: pg_autoscaler
      enabled: false
  dashboard:
    enabled: true
    ssl: true
  monitoring:
    enabled: false
    rulesNamespace: rook
  cleanupPolicy:
    sanitizeDisks:
      method: quick
  storage: # cluster level storage configuration and selection
    useAllNodes: true
    useAllDevices: true 

Most things seem to work after running just those. One pod show errors, but it doesn't seem to be related to the current issue I'm having; seems to rather be a symptom (it's the csi-rbdplugin pod).

I can load the dashboard just fine with an ingress I created. However, when, on the dashboard, I try to create an OSD or do much of anything, I get a popup saying

Orchestrator is not available. Please consult the documentation on how to configure and enable the functionality.

The documenation link it has there brings me to this 404 page, so that isn't much help.

I've tried searching elsewhere but there doesn't seem to be much info on that specific error message.

Anyone know what I'm doing wrong that the Orchestrator is not available and I cannot do much of anything?

Trying to host an app, specifically Foundry VTT, on my k8s cluster. It connects fine, but websockets (any url starting with /socket.io/ are giving me a 400 error.

Googling how to enable websocket support, it seems I just need to add the proxy send/read timeout and set it to a higher value, which I did.

I've tried adding nginx.org/websocket-service annotation, but that didn't work.

Nginx version: Helm chart ingress-nginx-3.20.1; app version 0.43.0

My ingress.yml:

---
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: foundry
  labels:
    app: foundry
  annotations:
    kubernetes.io/ingress.class: nginx
    cert-manager.io/cluster-issuer: "letsencrypt-prod"
    nginx.ingress.kubernetes.io/connection-proxy-header: "keep-alive"
    #nginx.ingress.kubernetes.io/enable-cors: "true"
    nginx.ingress.kubernetes.io/force-ssl-redirect: "true"
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
    nginx.ingress.kubernetes.io/proxy-connect-timeout: '30'
    nginx.ingress.kubernetes.io/proxy-send-timeout: '3600'
    nginx.ingress.kubernetes.io/proxy-read-timeout: '3600'
    nginx.ingress.kubernetes.io/client-max-body-size: 512M
    nginx.ingress.kubernetes.io/configuration-snippet: |
      proxy_set_header Upgrade $http_upgrade;
      proxy_set_header Connection "Upgrade";
      proxy_set_header Host $host;
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_set_header X-Forwarded-Proto $scheme;
spec:
  tls:
    - hosts:
        - rpg.example.com
      secretName: foundry-tls
  rules:
    - host: rpg.example.com
      http:
        paths:
          - path: /
            backend:
              serviceName: foundry
              servicePort: http

I use keycloak gatekeeper as a sidecar container for multiple pods on my cluster to enable SSO for those services.

But when I try to exec, view logs, etc; it asks what container I want to use instead of just going into it. Is there a way to define the default container that it will use for something like kubectl exec -it PODNAME when I don't pass the -c flag?

I have in my sudoers file

ALL            ALL = (ALL) NOPASSWD: ALL

Which allows anyone to use sudo without entering a password. And I confirmed that I can sudo without a password when I ssh into the machine.

Yet when I attempt to run a playbook on it, I get an error "missing sudo password".

The command I'm using to run is

ansible-playbook -i inventory.yaml common_install.yaml --limit vpn.lan.example.com -vvv

I've run the same command, limiting it to a different host, that has the same sudo rule, and are both running Ubuntu 20.04, and it works on that. But won't work on this host.

Why won't it work?

I'm trying to create a replica of my single FreeIPA server to aid in migration and move to a clustered environment.

I spun up a CentOS host, enrolled it as a client to the ipa server, and added it to the group ipaservers. I then ran ipa-replica-install after running kinit to login as admin.

Run connection check to master
Connection check OK
Disabled p11-kit-proxy
Configuring directory server (dirsrv). Estimated time: 30 seconds
  [1/41]: creating directory server instance
  [2/41]: configure autobind for root
  [3/41]: stopping directory server
  [4/41]: updating configuration in dse.ldif
  [5/41]: starting directory server
  [6/41]: adding default schema
  [7/41]: enabling memberof plugin
  [8/41]: enabling winsync plugin
  [9/41]: configure password logging
  [10/41]: configuring replication version plugin
  [11/41]: enabling IPA enrollment plugin
  [12/41]: configuring uniqueness plugin
  [13/41]: configuring uuid plugin
  [14/41]: configuring modrdn plugin
  [15/41]: configuring DNS plugin
  [16/41]: enabling entryUSN plugin
  [17/41]: configuring lockout plugin
  [18/41]: configuring topology plugin
  [19/41]: creating indices
  [20/41]: enabling referential integrity plugin
  [21/41]: configuring certmap.conf
  [22/41]: configure new location for managed entries
  [23/41]: configure dirsrv ccache and keytab
  [24/41]: enabling SASL mapping fallback
  [25/41]: restarting directory server
  [26/41]: creating DS keytab
  [error] CalledProcessError: CalledProcessError(Command ['/usr/sbin/ipa-getkeytab', '-k', '/etc/dirsrv/ds.keytab', '-p', 'ldap/[email protected]', '-H', 'ldaps://ipa.whitefamilyserver.com'] returned non-zero exit status 9: 'Failed to parse result: Failed to decode GetKeytab Control.\n\nRetrying with pre-4.0 keytab retrieval method...\nFailed to parse result: Insufficient access rights\n\nFailed to get keytab!\nFailed to get keytab\n')
Your system may be partly configured.
Run /usr/sbin/ipa-server-install --uninstall to clean up.

CalledProcessError(Command ['/usr/sbin/ipa-getkeytab', '-k', '/etc/dirsrv/ds.keytab', '-p', 'ldap/[email protected]', '-H', 'ldaps://ipa.whitefamilyserver.com'] returned non-zero exit status 9: 'Failed to parse result: Failed to decode GetKeytab Control.\n\nRetrying with pre-4.0 keytab retrieval method...\nFailed to parse result: Insufficient access rights\n\nFailed to get keytab!\nFailed to get keytab\n')
The ipa-replica-install command failed. See /var/log/ipareplica-install.log for more information

As you can see, the command fails. It says it has insufficient permissions, but I don't see which permission to add to allow this command to work properly.

Yet when I run the command that failed manually, it succeeds. So why does it fail during the install, but not when I run it manually?

[root@ipa-apollo mendicant]# ipa-getkeytab -k /etc/dirsrv/ds.keytab -p ldap/[email protected] -H ldaps://ipa.whitefamilyserver.com
Failed to parse result: Failed to decode GetKeytab Control.

Retrying with pre-4.0 keytab retrieval method...
Failed to retrieve encryption type AES-128 CTS mode with 128-bit SHA-256 HMAC (#19)
Failed to retrieve encryption type Camellia-128 CTS mode with CMAC (#25)
Keytab successfully retrieved and stored in: /etc/dirsrv/ds.keytab

Extended downtime will not be an issue to try and fix this.

I have an ingress that connects to Kubernetes Dashboard, but I'm getting a 400 error when trying to access it.

---
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: kubernetes-dashboard
  namespace: kubernetes-dashboard
  annotations:
    kubernetes.io/ingress.class: nginx
    cert-manager.io/cluster-issuer: "letsencrypt-prod"
    nginx.ingress.kubernetes.io/backend-protocol: "HTTPS"
    nginx.ingress.kubernetes.io/auth-tls-verify-client: "false"
    nginx.ingress.kubernetes.io/whitelist-source-range: "10.0.0.0/16"
spec:
  tls:
    - hosts:
        - kube.example.com
      secretName: dashboard-tls  # confirmed is valid LE cert
  rules:
    - host: kube.example.com
      http:
        paths:
          - backend:
              serviceName: kubernetes-dashboard
              servicePort: 443

That gives me a 400 error in the nginx pod.

2020/08/28 01:25:58 [error] 2609#2609: *795 readv() failed (104: Connection reset by peer) while reading upstream, client: 10.0.0.25, server: kube.example.com, request: "GET / HTTP/1.1", upstream: "http://10.42.0.2:8443/", host: "kube.example.com"

10.0.0.25 - - [28/Aug/2020:01:25:58 +0000] "GET / HTTP/1.1" 400 0 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:79.0) Gecko/20100101 Firefox/79.0" "-"

And in case it is relevant, my nginx configuration, deployed through the helm chart nginx-stable/nginx-ingress

  ## nginx configuration
  ## Ref: https://github.com/kubernetes/ingress/blob/master/controllers/nginx/configuration.md
  ##
  controller:
    config:
      entries:
        hsts-include-subdomains: "false"
        ssl-ciphers: "ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4"
        ssl-protocols: "TLSv1.1 TLSv1.2"
    ingressClass: nginx
    service:
      externalTrafficPolicy: Local
      annotations:
        metallb.universe.tf/address-pool: default
  defaultBackend:
    enabled: true
  tcp:
    22: "gitlab/gitlab-gitlab-shell:22"

I have an ingress that routes to a custom endpoint external to the kubernetes cluster. The service listens only on HTTPS on port 8006.

apiVersion: v1
kind: Service
metadata:
  name: pve
spec:
  ports:
    - protocol: TCP
      port: 8006
---
apiVersion: v1
kind: Endpoints
metadata:
  name: pve
subsets:
  - addresses:
      - ip: 10.0.1.2
    ports:
      - port: 8006
---
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: pve

  annotations:
    kubernetes.io/ingress.class: "nginx"
    cert-manager.io/cluster-issuer: "letsencrypt-prod"
    nginx.ingress.kubernetes.io/backend-protocol: "HTTPS"
    nginx.ingress.kubernetes.io/auth-tls-verify-client: "off"
    nginx.ingress.kubernetes.io/whitelist-source-range: "10.0.0.0/16"

spec:
  tls:
    - hosts:
        - pve.example.com
      secretName: pve-tls
  rules:
    - host: pve.example.com
      http:
        paths:
          - backend:
              serviceName: pve
              servicePort: 8006
            path: /

Gives the error in the nginx pod:

10.0.0.25 - - [28/Aug/2020:01:17:58 +0000] "GET / HTTP/1.1" 502 157 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:79.0) Gecko/20100101 Firefox/79.0" "-"

2020/08/28 01:17:58 [error] 2609#2609: *569 upstream prematurely closed connection while reading response header from upstream, client: 10.0.0.25, server: pve.example.com, request: "GET / HTTP/1.1", upstream: "http://10.0.1.2:8006/", host: "pve.example.com"

Edit

After removing the proxy protocol, I get the error

10.0.10.1 - - [28/Aug/2020:02:19:18 +0000] "GET / HTTP/1.1" 400 59 "-" "curl/7.58.0" "-"

2020/08/28 02:19:26 [error] 2504#2504: *521 upstream prematurely closed connection while reading response header from upstream, client: 10.0.10.1, server: pve.example.com, request: "GET / HTTP/1.1", upstream: "http://10.0.1.2:8006/", host: "pve.example.com"

10.0.10.1 - - [28/Aug/2020:02:19:26 +0000] "GET / HTTP/1.1" 502 157 "-" "curl/7.58.0" "-"

And in case it is relevant, my nginx configuration, deployed through the helm char nginx-stable/nginx-ingress

  ## nginx configuration
  ## Ref: https://github.com/kubernetes/ingress/blob/master/controllers/nginx/configuration.md
  ##
  controller:
    config:
      entries:
        hsts-include-subdomains: "false"
        ssl-ciphers: "ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4"
        ssl-protocols: "TLSv1.1 TLSv1.2"
    ingressClass: nginx
    service:
      externalTrafficPolicy: Local
      annotations:
        metallb.universe.tf/address-pool: default
  defaultBackend:
    enabled: true
  tcp:
    22: "gitlab/gitlab-gitlab-shell:22"

We have a kubernetes ingress on our cluster. We wanted to restrict access to it to only those accessing it from within our LAN (10.0.0.0/16). So in the ingress annotations, I have nginx.ingress.kubernetes.io/whitelist-source-range: "10.0.0.0/16".

But this allows traffic from anywhere still. Setting it to 10.0.0.0/24 (our DHCP range), it doesn't allow any traffic at all.

When I check the nginx-ingress-controller logs, I see

10.0.10.1 - - [15/Oct/2019:05:40:46 +0000] "GET / HTTP/2.0" 200 2073 "-" "curl/7.54.0" 38 0.019 [wfs-ipa-8443] [] 10.0.1.2:8443 2073 0.020 200 a2d2053149dd26a490251439629134ff

This shows that it sees the source IP as the node the ingress controller pod is currently running on. How can I make it so that it sees the source IP as either their LAN IP, or the single WAN IP we have?

Edit:

ingress.yml:

---
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: ipa
  namespace: wfs
  annotations:
    kubernetes.io/ingress.class: "nginx"
    certmanager.k8s.io/cluster-issuer: "letsencrypt-prod"
    ingress.kubernetes.io/secure-backends: "true"
    nginx.ingress.kubernetes.io/backend-protocol: "HTTPS"
    nginx.ingress.kubernetes.io/use-proxy-protocol: "true"
    nginx.ingress.kubernetes.io/auth-tls-verify-client: "off"
    nginx.ingress.kubernetes.io/whitelist-source-range: "10.0.0.0/16"

spec:
  tls:
    - hosts:
        - ipa.example.com
      secretName: ipa-tls
  rules:
    - host: ipa.example.com
      http:
        paths:
          - backend:
              serviceName: ipa
              servicePort: 8443
            path: /

I deployed the Nextcloud Helm chart to my cluster. Installation went fine and I can use it. But I can only upload small files (the default).

How can I configure the helm chart to allow larger files (5Gi) to be uploaded?

So I have a 4 node (VMs) Kubernetes cluster spun up with Kubespray. I have a Ceph cluster set up from Proxmox, and a pool is available to k8s. I can make deployments using Ceph just fine.

But when I want to resize the container, I run into a long list of issues.

When I tried to resize, instead of using the kube-system/rbd-provisioner pod, it tries to use kube-system/kube-controller-manager to resize it. This failed initially because the container doesn't have the rbd command installed. I fixed this by switching the image in /etc/kubernetes/manifests/kube-controller-manager.yaml from gcr.io/google-containers/kube-controller-manager:v1.15.1 to image: gcr.io/google_containers/hyperkube:v1.14.6, as this image includes the rbd binary.

Now it can attempt to resize volumes. But it still fails when it tries. The error it shows is:

'VolumeResizeFailed' error expanding volume "default/test-pvc" of plugin "kubernetes.io/rbd": rbd info failed, error: exit status 110

The StorageClass is as follows:

---
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: kubedata-rbd
provisioner: ceph.com/rbd
allowVolumeExpansion: true
parameters:
  monitors: 10.10.10.2:6789
  adminId: admin
  adminSecretName: ceph-secret
  adminSecretNamespace: kube-system
  pool: Kubedata
  userId: kube
  userSecretName: ceph-secret-kube
  userSecretNamespace: kube-system
  imageFormat: "2"
  imageFeatures: layering

How can I be able to resize PVCs created by Ceph? I've even tried manually resizing them on a ceph node then editing the claim size, but that doesn't update to reflect the new size.

Im trying to generate a letsencrypt wildcard cert to use on various websites (one FQDN, multiple subdomains). The plan is to save those certs on a NFS share I have to easily access them on various webservers.

But when I mount my NFS share to /etc/letsencrypt so it saves the certs to there, I get an error:

letsencrypt | IOError: [Errno 37] No locks available

I set the mode of the folder on the share to 777, so it should have write access.

My docker-compose.yml file:

version: '3.5'
services:
  letsencrypt:
    image: linuxserver/letsencrypt
    restart: unless-stopped
    network_mode: host
    cap_add:
      - NET_ADMIN
    environment:
    - OTHERSTUFF=blahblah
    - STAGING=true
    volumes:
    - ./config/letsencrypt:/config/dns-conf
    - Certs:/config/etc/letsencrypt

volumes:
  Certs:
    name: certs
    driver: local
    driver_opts:
      type: nfs
      o: addr=10.0.1.14,rw
      device: ":/media/NAS/Certs"

I have ESXI 6.7 installed on my r710. I have 1 2TB drive that's being used as the boot drive for ESXi and the VMs. I have 3 4TB drives that will be large storage. I want to send the 4TB disks directly to the VM so the raid can be handled with ZFS. How do I pass the drives directly to the VM?

If I have a number of virtual hosts in the sites-enabled folder, how can I have a common whitelist for all of them?

Aka each one has this block

    allow 127.0.0.1;
    allow 192.168.0.0/16;
    allow x.x.x.x;
    deny all;

How can I have that apply to all the virtual hosts by default, instead of having to write it for every subdomain?

So I have a custom module that just sets up a simple nginx server, to learn how to properly make puppet modules.

But it seems that my values when I declare the class aren't getting passed in. It just uses the default values instead.

Below is my bits of class code that matter, and the base.pp I'm using in my control repo.

Base class init.pp:

class ufprovisioning (

    $webserver_manage   = $ufprovisioning::params::webserver_manage,
    $site_name          = $ufprovisioning::params::site_name,


) inherits ufprovisioning::params {

    contain ufprovisioning::install
    contain ufprovisioning::config
    contain ufprovisioning::service

    Class['::ufprovisioning::install'] -> Class['::ufprovisioning::config'] ~> Class['::ufprovisioning::service']
    Class['::ufprovisioning::install'] ~> Class['::ufprovisioning::service']
}

Parameter Class params.pp:

class ufprovisioning::params {

    $site_name = "webserver.test"
    $webserver_manage = true

}

Config Class config.pp:

class ufprovisioning::config {

    assert_private()

    $webserver_manage   = $::ufprovisioning::params::webserver_manage
    $site_name          = $::ufprovisioning::params::site_name


    nginx::resource::server { 'cclloyd.com':
        ensure          =>  present,
        server_name     =>  [$site_name],
        www_root        =>  "/var/www/${site_name}",
        listen_port     =>  80,
        ssl             =>  false,
    }
}

Control class base.pp:

class profile::base {
    class { '::ntp': }
    class { 'ufprovisioning':
        site_name => "examplesite.test",
        webserver_manage => true,
    }
}

I was following this guide to set up a masterless puppet machine that could use puppet to manage itself (in a way that would let me add nodes and use this as the master later, but that's irrelevant now). And I have a basic module set up that should check to make sure nginx is installed and a site config file is there. But when I run the environment using sudo r10k deploy environment -p -v, it seems to update everything, yet the module doesn't seem to be executing properly.

My module can be found here, and my control repo can be found here.

Is my module structured wrong? Am I missing something here? Is it because when I check the status of the puppet service using sudo service puppet status it spits out a few errors with my heira.yaml file?

● puppet.service - Puppet agent
   Loaded: loaded (/lib/systemd/system/puppet.service; enabled; vendor preset: enabled)
   Active: active (running) since Thu 2018-02-22 23:07:06 UTC; 3min 0s ago
 Main PID: 19319 (puppet)
    Tasks: 2 (limit: 4915)
   CGroup: /system.slice/puppet.service
           └─19319 /opt/puppetlabs/puppet/bin/ruby /opt/puppetlabs/puppet/bin/puppet agent --no-daemonize

Feb 22 23:07:06 puppeteer systemd[1]: Started Puppet agent.
Feb 22 23:07:07 puppeteer puppet-agent[19319]: Starting Puppet client version 5.4.0
Feb 22 23:07:09 puppeteer puppet-agent[19327]: Could not retrieve catalog from remote server: Error 500 on SERVER: Server Error: Evaluation Error: Error while evaluating a Function Call, Lookup of key 'classes' failed:  The Lookup Configuration at '/etc/puppetlabs/puppet/hiera.yaml' has wrong type, entry 'hierarchy' index 0 expects a Struct value, got String
Feb 22 23:07:09 puppeteer puppet-agent[19327]:   The Lookup Configuration at '/etc/puppetlabs/puppet/hiera.yaml' has wrong type, entry 'hierarchy' index 1 expects a Struct value, got String
Feb 22 23:07:09 puppeteer puppet-agent[19327]:   The Lookup Configuration at '/etc/puppetlabs/puppet/hiera.yaml' has wrong type, entry 'hierarchy' index 2 expects a Struct value, got String
Feb 22 23:07:09 puppeteer puppet-agent[19327]:   The Lookup Configuration at '/etc/puppetlabs/puppet/hiera.yaml' has wrong type, unrecognized key 'backends'
Feb 22 23:07:09 puppeteer puppet-agent[19327]:   The Lookup Configuration at '/etc/puppetlabs/puppet/hiera.yaml' has wrong type, unrecognized key 'yaml' (file: /etc/puppetlabs/code/environments/production/site.pp, line: 1, column: 1) on node puppeteer.c.personal-server-193919.internal
Feb 22 23:07:09 puppeteer puppet-agent[19327]: Applied catalog in 0.03 seconds

Contents of heira.yaml:

---
# Hiera 5 Global configuration file

version: 5

# defaults:
#   data_hash: yaml_data
# hierarchy:
#  - name: Common
#    data_hash: yaml_data
#hierarchy: [] (tried with and without this commented out)
:backends:
  - yaml
:hierarchy:
  - "%{clientcert}"
  - "%{environment}"
  - global
:yaml:
  :datadir: '/etc/puppetlabs/puppet/environmets/%{environment}/hieradata'

For some reason I can't open port 443 on my google compute instance. I have HTTPS server enabled on the instance, and using gcloud compute firewall-rules list returns the rules below:

NAME                    NETWORK  DIRECTION  PRIORITY  ALLOW                         DENY
default-allow-http      default  INGRESS    1000      tcp:80
default-allow-https     default  INGRESS    1000      tcp:443
default-allow-icmp      default  INGRESS    65534     icmp
default-allow-internal  default  INGRESS    65534     tcp:0-65535,udp:0-65535,icmp
default-allow-rdp       default  INGRESS    65534     tcp:3389
default-allow-ssh       default  INGRESS    65534     tcp:22

Yet when I check to see if the port is open using something like nmap it says it's closed.

PORT     STATE  SERVICE
22/tcp   open   ssh
443/tcp  closed https

Edit: Here's my nginx conf file for that site. https://gist.github.com/cclloyd/e7f1183f3a018dbc32cd7c55e15375cf