gluufederation / cloud-native-edition Goto Github PK

missing

          volumeMounts:
            - name: cb-pass
              mountPath: "/etc/gluu/conf/couchbase_password"
              subPath: couchbase_password
            - name: cb-crt
              mountPath: "/etc/certs/couchbase.crt"
              subPath: couchbase.crt
      volumes:
      - name: cb-pass
        secret:
          secretName: cb-pass
      - name: cb-crt
        secret:
          secretName: cb-crt

There are:

• Enable oxTrust Api
• Enable oxTrust Test Mode.

I am not sure what 'oxTrust Test Mode' is, talked to Gasmyr and he suggested it's wrong. Please talk to Gasmyr and remove which is not necessary.

So it seems to be there is no actual Helm chart for Gluu yet. This project only shows off some example manifests which are not dynamic and only work for minikube.

There is this project as well. However there really isn't anything suggesting it uses Helm. I also posted a similar issue on that project as well.

Over the last few weeks, I have built a proper chart for Gluu. The company I work for is Akirix, and they allowed me to share my work with ya'll. Hoping our Helm chart could help with Gluu getting out an official Gluu Helm Chart. Please check this project out and fork if you need.

Akirix/Gluu

I basically used the Gluu minikube example and the stable helm charts as the pattern to follow.

Our project is not done nor documented enough and therefore may not be the easiest Chart to use. We are definitely hoping ya'll can finish what we started using your master knowledge of Gluu. Then the community would be complete with an up to date Helm chart.

Akirix/Gluu

Prepare the images and/or recipes/docs to integrate with Istio.

https://github.com/GluuFederation/enterprise-edition/blob/54023d1b6fb4d85e75b1f10d1de6365cda8f8e95/pygluu/kubernetes/create.py#L750

No namespace parameter specified, it's using the default of namespace=default.

Add AWS ECS support

We should clearly state in the docs thats the command to generate a keystore is :

    keytool -genkey -noprompt \
      -alias oxd-server \
      -dname "CN=oxd-server, OU=ID, O=Gluu, L=Gluu, S=TX, C=US" \
      -keystore oxd-server.keystore \
      -storepass <pass>\
      -keypass <pass>\
      -deststoretype pkcs12 \
      -keysize 2048

Also we need to add how to put that back to be used by oxd-server with helm after encoding it using openssl base64 -A -in oxd-server.keystore.

The current health check url /passport results in a 404 response code. This causes the liveness and readiness probes to fail resulting in unwanted restarts of oxpassport containers.

2019-09-02T12:36:29.216Z [INFO]     Server listening on https://demoexample.gluu.org:8090
Server listening on https://demoexample.gluu.org:8090
2019-09-02T12:37:06.552Z [INFO]     ::ffff:172.17.0.1 - GET /passport HTTP/1.1 404 147 - 5.172 ms
2019-09-02T12:37:07.280Z [INFO]     ::ffff:172.17.0.1 - GET /passport HTTP/1.1 404 147 - 1.116 ms

This should be updated to match the new health check URL /passport/token

2019-09-02T12:43:28.973Z [INFO]     Server listening on https://demoexample.gluu.org:8090
Server listening on https://demoexample.gluu.org:8090
2019-09-02T12:44:03.780Z [INFO]     ::ffff:172.17.0.1 - GET /passport/token HTTP/1.1 200 201 - 5.375 ms
2019-09-02T12:44:05.731Z [INFO]     ::ffff:172.17.0.1 - GET /passport/token HTTP/1.1 200 201 - 0.742 ms

At the production level the use of volumes for minor files in our services is costly. Most of the volumes listed in the helm charts are associated with log files which should be shipped any way using other tools and not particularly using volumes.
#9

Continue with the above settings

May be we can show the 'list' of settings ( the way CE showing ) after user is done with password? And after that... prompt with Continue with the above settings message.

https://github.com/GluuFederation/enterprise-edition/blob/0ac4c942145897e28949b5a77929ae70d2c4b35a/pygluu/kubernetes/create.py#L1040

The first failure here will drop to the catch and the rest of the commands will not run.

In address to the new sentinel update GluuFederation/oxCore#144 (comment)

https://github.com/GluuFederation/casa/wiki/Notes-for-4.0-linux-package

The target is to fully automate the gluu installation from CI pipeline. I think its also worth the while to add options to enable and disable casa related scripts, passport, and radius upon installation disregarding the fact that it can be done from oxtrust API. This would ease the installation process to make it clean without intervention from user.

Our objective is to track our containers/pods use and report them in some form. This can be done by an external running container/pod that will always be a requirement running back-end container/pod. Since we will be enforcing license very soon, this actually might come in handy simply as reporting the use of Gluu.

Use the Kustomize convention in our repos

We need to detect all areas of change and migrate connections to CN.

@nynymike
IP addresses: in chroot, oxauth connects to LDAP via localhost, so bootstrap LDAP connection properties will need to be updated when migrating to kubernetes. Also, the IP Address is in the chroot httpd.conf Listen directive

Cache Refresh… which uses the file system to store snapshots

Private key access

Is the chroot one instance, or a clustered deployment (using Cluster Manager)?

https://github.com/GluuFederation/enterprise-edition/wiki/chroot-to-kubernetes-migration

https://github.com/GluuFederation/enterprise-edition/blob/edd39282a2265a98323e3af7a4248dc67baf613e/pygluu/kubernetes/templates/helm/charts/oxshibboleth/templates/statefulset.yaml#L79

source ./venv/bin/activate should be source .venv/bin/activate

./pygluu-kuberenets.pyz upgrade should be supported

Move create.sh from Kubernetes installation example and run_all.sh from docker compose to python3 scripts.

To meet same structure as Gluu CE.
https://gluu.org/docs/ce/4.0/admin-guide/radius-server/gluu-radius/

Currently the following are being used as the RADIUS server :

• http://tinyradius.sourceforge.net/
• https://www.open.com.au/radiator/

Add to run_all.sh logic to detect any conflicting containers and closed ports. We will require the VM to be in a clean state.

Add image and manifests for Gluu OXD

https://gluu.org/docs/oxd/

Add License enforcement in our EE edition. This needs to be in our GUI , ask for a license file and have a back end server approve this license.

Current oxAuth/oxTrust images don't have scim-rp.jks or any SCIM-related files inside the container.

This includes the need to add the manifests to our tempaltes

With the nginx-ingress required to be installed before the rest of the chart and it operating on a different namespace we should just switch to two helm installs instead of having the user minipulate the main values.yaml helm install then manipulate again and helm upgrade.

https://github.com/GluuFederation/enterprise-edition/tree/4.0/helm/charts/nginx-ingress

Create image and manifests to use Gluu Gatway.
https://gluu.org/docs/gg/

As Macs have Python2 installed (and it's recommended not to uninstall Python2), the instructions for mac should specify Python3:

python3 -m venv .venv
pip3 install shiv

etc.

Currently to use casa the user must move /etc/gluu/conf/casa.json to the backend manually. This step has to be automated to load at:

dn: ou=casa,ou=configuration,o=gluu
objectClass: top
objectClass: oxApplicationConfiguration
ou: casa
oxConfApplication: < ... contents of casa.json ... >

Current Swarm example requires users to modify manifests to choose which services deployed to swarm cluster. The ease the operation, the examples should adhere to Compose and/or Kubernetes examples that are modular.

@shmorri @mogluu

We have to be able to integrate with a locally deployed Kubernetes that is setup using any method such as using rke , kubeadm ..etc.
Issues that are at hand with a fully local deployment are:

• The Couchbase layers volumes that cannot be provisioned and thus need specific definitions for each PV and PVC.
• Nginx layer needs attention on the load balancer address or ip.

Create RHEL UBI-based image that conforms to the following rules:

In alignment with Red Hat’s container repo policy it is recommended to
explicitly indicate the RHEL version in repo names (like so: -ubi7, -ubi8, rhel7, rhel8).

Certified partner images with “UBI” only content: Eligible for distribution through External Registries

Example: Namespace/Repository MYCOMPANY/MYPRODUCT-UBI7

testing

We need to add instructions to the user on how to reinstall Gluu with currently available information in the backend without overwriting any info. This might also be addressed in the installer.

Though I selected N for Shibboleth but setup script ( create.sh ) asked for "Shared Shibboleth Volume" input.

It will be good if this "Shared Shibboleth Volume" appear only if deployer select 'Y' for Shibboleth.

https://github.com/GluuFederation/enterprise-edition/blob/edd39282a2265a98323e3af7a4248dc67baf613e/pygluu/kubernetes/prompt.py#L519

Should be ca_crt_content to match the next line.