installation instructions for using couchbase

[ksully-execute]

I see instructions for mysql and pgsql, but can't seem to find the couchbase specifics.....trying to interpret the helm values is a little confusing too, am I missing a doc on couchbase?

[ksully-execute]

or maybe a helm chart with couchbase configured I could use as a guide?

[misba7]

Hello Ksully.

You will be:

• change global.cnPersistenceType: couchbase here
• Tweak couchbase values in config.configmap here

Also we will be adding these notes in the docs soon.

[ossdhaval]

Hi @misba7 Thank you for your response. Can you create a documentation issue to track this if it doesn't already exist? I think there are a couple of more points on this thread that can be documented to help future users. @ksully-execute If you wish to, you can also contribute this part to the documentation. We are all here to help and guide you if needed. 🤝

[ksully-execute]

Thanks! Will give it a try

[ksully-execute]

doesn't seem like the nginx instance is hooked up to the auth-server or any of the other endpoints.
When I try to hit the documented endpoints:

• Auth server https://FQDN/.well-known/openid-configuration
  -fido2 https://FQDN/.well-known/fido2-configuration
  -scim https://FQDN/.well-known/scim-configuration

and my ingress is exposed on a given ip, which i have dns set up on that ip as well....
When I hit that endpoint using the fdqn, I get a 404
curl -k https://<registered dns for nginx exposed endpoing>/.well-known/openid-configuration
I would think that this endpoint is coming from the auth-server service, which in my case is a ClusterIP running on 10.108.170.78:8080
so shouldn't this work against that IP?
curl http://10.108.170.78:8080/.well-known/openid-configuration
but I get a 404 there too.

Nginx log shows that it's missing an active endpoint:
W0724 18:05:14.123896 7 controller.go:1207] Service "jans/auth-server" does not have any active Endpoint. │ W0724 18:05:14.123998 7 controller.go:1207] Service "jans/config-api" does not have any active Endpoint. │
Nginx was running prior to the jans install.
I see messages earlier in the log atoub updating the Ingress status for the endpoints, and pointing to the right IP'
I0724 18:03:43.444129 7 status.go:300] "updating Ingress status" namespace="jans" ingress="janssen-nginx-ingress-openid-config" curren │ │ tValue=null newValue=[{"ip":"172.16.1.7"}] │ │ I0724 18:03:43.444128 7 status.go:300] "updating Ingress status" namespace="jans" ingress="janssen-nginx-ingress-device-code" currentV │ │ alue=null newValue=[{"ip":"172.16.1.7"}] │ │ I0724 18:03:43.444207 7 status.go:300] "updating Ingress status" namespace="jans" ingress="janssen-nginx-ingress-webfinger" currentVal │ │ ue=null newValue=[{"ip":"172.16.1.7"}] │ │ I0724 18:03:43.444435 7 status.go:300] "updating Ingress status" namespace="jans" ingress="janssen-nginx-ingress-uma2-config" currentV │ │ alue=null newValue=[{"ip":"172.16.1.7"}] │ │ I0724 18:03:43.444670 7 status.go:300] "updating Ingress status" namespace="jans" ingress="janssen-nginx-ingress-webdiscovery" current │ │ Value=null newValue=[{"ip":"172.16.1.7"}] │ │ I0724 18:03:43.445660 7 status.go:300] "updating Ingress status" namespace="jans" ingress="janssen-nginx-ingress-u2f-config" currentVa │ │ lue=null newValue=[{"ip":"172.16.1.7"}] │

I'm so close...thoughts?

[misba7]

make sure to add all the needed nginx config needed(for example fqdn, hosts..etc)
and surely the fqdn should be mapping to the nginx ip
Check the following doc
https://docs.jans.io/head/admin/install/helm-install/google-gke/#jans-installation-using-helm

[ksully-execute]

It's a bit confusing, having to specify the lbIP whether the fqdn is registered or not....as per the docs.
And stranger, am used to the product creating the ingress itself, and that ingress being advertised through the ingress.
Q: Does the install create the ingress? If not, why not?
Q: Why, if the fqdn is dns registered, do you have to specify a lbIP?
Does the product install use the fqdn? Why is the ingress not just created, and leave the dns part to the user install process?
Am not sure how to proceed, guess I can create an ingress with a sample app first then assign the lbIP and update dns as I have been doing...

[ksully-execute]

do you think I should move this ingress question to a separate discussion item?

[misba7]

Yes this is totally different from couchbase

[ksully-execute]

Are there docs defining what the roles/privileges need to be on the couchbase user amd superuser?

[misba7]

Not yet.
Couchbase superuser is admin user.
Couchbase user need permissions to read and write document in buckets

[ksully-execute]

one question on this part:
# -- Couchbase certificate authority string. This must be encoded using base64. This can also be found in your couchbase UI Security > Root Certificate. In mTLS setups this is not required.
The UI Security->Certificates, there's the Couchbase Server, the Cluster CA, and the node certs.
The comment says 'Root Certificate', so which is it referring to?
And do you take the lines within the ----Begin Cert..... and -----End Certificate---- , remove the carriage returns and run base64 against that to get the string needed ?

[misba7]

"The cluster certificate is the root certificate issued for the cluster; and contains the public key of the corresponding Certificate Authority (CA). The certificate itself is often referred to as the Root CA"
https://docs.couchbase.com/server/current/learn/security/certificates.html

[ksully-execute]

This message, on the user and superuser, this is going to cause me to reinstall my couchbase, so just commenting and wondering why the restriction on the username composition?
`- config.configmap.cnCouchbaseUser: Does not match pattern '^[a-z]+$'

• config.configmap.cnCouchbaseSuperUser: Does not match pattern '^[a-z]+$'
  `
  versus

[ksully-execute]

sorry for my ignorance....still having trouble with the certificate....
On the UI, there's a server cert, a cluster cert and a node cert.
I'm using the cluster cert, which looks like:
`-----BEGIN CERTIFICATE-----
MIIDKTCCAhGgAwIBAgIQdpgtpssm2mIQr22WQEMXtjANBgkqhkiG9w0BAQsFADAf
MR0wGwYDVQQDExRjb3VjaGJhc2UtY2x1c3Rlci1jYTAeFw0yMzA3MjIxNDI0MDRa
Fw0yNDA3MjExNDI0MDRaMB8xHTAbBgNVBAMTFGNvdWNoYmFzZS1jbHVzdGVyLWNh
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA5JkXMcbDrPyJvCE4QfnU
ixGH1RLK1KJhFWJWOTLY64ujuDvSFrMgzqrAuLevAlSfsvsSUCqd3T1R0FrgySdc
VZ5kmJRAZjyjdemd6TCfVYZsiTdQnBvZLIh0535UgbqER+b+4I1hGqy6QoTY9Wrx
qdK/vE10vbgwjpcWF4l263LSftOJcOuEmeifkJALay8sXhXReyvNMvh6bbwXA5nv
E2BaJ28fIGEWh61ay8YavmcewbfttWg9h4deiWGauFImIHev+zKZQ7vGvTQeGvxq
TdCJdLM4QWNjOEuGRoqSxFqneD9mYlGiF1InJbAYNeyLojSszJsbWaCxrVQTUZrm
9wIDAQABo2EwXzAOBgNVHQ8BAf8EBAMCAqQwHQYDVR0lBBYwFAYIKwYBBQUHAwEG
CCsGAQUFBwMCMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFCKwDWdloOQcDuC9
XbGc78yV5VPjMA0GCSqGSIb3DQEBCwUAA4IBAQAdq3nEr39O4z8GUFU3BDGvL8/Y
Tp8he0T7TRsIDE+4qZh6lF1ShSv1aoXZJOfLkugN94cDXybLlibRJ05V+ibEBIJP
+nFCZXj84/6kbOeD85+1bdLJpqeBN9f9RQzh4DIhokHqo88G5q3Umd1EKi6LpZ9W
bI5yfUhaosRnfHf3EvUU1ibsML6U2GmmdYzzNNgDddMBmCs9NJz66ejUJRuVvzzA
tGq89p56ByujukF7bUBcV1NBhXgtXuhvBcbmkOX56LVsPr0jwJYv+vcGxlMqcX2/
NFZKgA1tzG+IDxd6jwk3UkuWvxRGCJpVw+AVEqUwg7HeJvJO2I39xDcjFO43s
-----END CERTIFICATE-----

`
then I'm taking just the value (without the ---BEGIN and end parts, and put that in a file, then
cat certstuff | base64 >crt.signature
which creates a file that looks just like the cert, with multiple lines of encoded text.
And I can't get the values file to like it....
Can I get a hint?

[misba7]

Looks to me it's accessing a node and showing its summary, where this node has only 13MB i.e. "perNodeMegs":13.

[ksully-execute]

yep, hadn't set the memory quotas up. And I lowered the default for buckets since it looks like jans is looking for smaller than 100MB....
Can you tell me what the default configuration is looking for? Memory size for data, index, eventing, query and search service?

[ksully-execute]

adjusted the values so that the buckets are now created, and I see couchbase indexes......
The config-api and auth-server pods have restarted twice, so that's not good.
I see warnings about no events happening, but that doesn't seem awful. And don't see any glaring errors.....
Attaching the logs from config-api and auth-server logs if anyone could take a look, and thanks again!
config-api.txt
auth-server.txt

[misba7]

I see timeout exception when it's trying to connect to couchbase

[ksully-execute]

i see, so that's an error not a warning that there's no activity?
We know the superuser is working, cause the buckets and indexes and user is there.
And I can connect using the specified cnCouchbaseUser ok on the UI and the couchbase cli (and it has full admin rights just to get it working)......
Ah, it was the URL, I didn't point to the clusterIP for couchbase.
Pods are running now, let me test the UI, etc.
Thanks!

[ksully-execute]

Will close the discussion, thanks very much for your help Amro 😊

[misba7]

My pleasure

[ksully-execute]

wondering if I can open this again, I'm having the same problem with the latest install on a new cluster.....
│ │ WARNING - jans.pycloudlib.lock - 2024-04-05 20:28:09,018 - Backing off LockManager.check_connection(<LockRecord(adapter=CouchbaseLock)>) for 10.0 seconds; error='requests.exceptions.HTTPError: 401 C │ │ lient Error: Unauthorized for url: https://couchbasedev-0000.couchbase.svc.cluster.local:18091/pools/default/buckets'

The bucket call is likely associated with the superuser I've provided, and I've verified, from inside the config container, that I can make that call given the parameters I've provided in the config. I've been round and round on this given my earlier experience, but it's eluding me, and I'm hoping for help.
I also updated appLoggers for the authserver to try to get more info, but I'm not seeing anything different. Not sure whether I should change everything to FILE or STDOUT (tried both it seems with no diff and with everything else at DEBUG level).
I've attached the yaml override file, based on the current github file with needed alterations. Note that I changed the couchbase credential values, so don't worry if those are not valid, they do work from inside that auth-server container.
I'm also using the cluster certificate for couchbase, converted correctly to base64 (which I believe is the right one).
Thanks in advance for any hints!

[ksully-execute]

am seeing this (i.e. in the casa pod)
│ INFO - jans.pycloudlib.wait - 2024-04-30 15:18:45,036 - Config is ready │ INFO - jans.pycloudlib.wait - 2024-04-30 15:18:45,075 - Secret is ready │ INFO - jans.pycloudlib.wait - 2024-04-30 15:18:45,208 - Couchbase is ready

but the auth server pods moves along but then hits the same error that all the other pods are hitting.
autserver.log.txt

[ksully-execute]

@misba7 Am using the default helm chart (1.1.2_dev) with only changes specific to my environment; scim and auth-server are starting ok, but casa and fido2 don't. There are no errors shown in the logs that I can find though.
And then I tried TUI, authorized it using admin and password (successfully in the browser for device authorization), but TUI then says 'Unable to get user info'. I don't see any logs for TUI, are they written somewhere?
This is all pretty tough to do, even understanding the user/password for the initial login is hard to find/figure out....
Any thoughts would be appreciated.

[misba7]

@ksully-execute you can find the TUI instructions to login documented here.

For the TUI logs, please check the config-api logs and attach it if you can't figure out the problem.

[misba7]

Also you can check the log file cli_cmd.log https://docs.jans.io/v1.1.1/admin/config-guide/config-tools/jans-tui/#command-line-logs

[ksully-execute]

i don't see any activity in the config-api logs when I do the device authorization (successful, in the browser), and get the 'Unable to get user info' in the TUI window, I see only successful health api checks in the config api logs....

[ksully-execute]

I do see a couple of errors in the auth-server logs though:

│ jans-auth - 2024-05-09 18:30:56,795 ERROR [qtp1746570062-20] [io.jans.as.model.crypto.AuthCryptoProvider] (AuthCryptoProvider.java:255) - Failed to find private key by kid: null, signatureAlgorithm: RS256(check whether web keys  │
│ jans-auth - 2024-05-09 18:30:56,795 ERROR [qtp1746570062-20] [as.server.userinfo.ws.rs.UserInfoRestWebServiceImpl] (UserInfoRestWebServiceImpl.java:216) - Failed to find private key by kid: null, signatureAlgorithm: RS256(check  │
│ java.lang.IllegalStateException: Failed to find private key by kid: null, signatureAlgorithm: RS256(check whether web keys JSON in persistence corresponds to keystore file), keySelectionStrategy: OLDER                            │
│

jans-auth - 2024-05-09 18:32:20,767 WARN [cb-events] [com.couchbase.client.core.cnc.LoggingEventConsumer$Slf4JLogger] (LoggingEventConsumer.java:462) - [com.couchbase.core][InitGlobalConfigFailedEvent][313ms] Initializing the g │ │ com.couchbase.client.core.error.ConfigException: Could not locate a single global configuration │ │ at com.couchbase.client.core.config.DefaultConfigurationProvider.lambda$loadAndRefreshGlobalConfig$8(DefaultConfigurationProvider.java:336) ~[core-io-2.4.4.jar:?] │ │

[misba7]

auth-key-rotation issue is fixed in 1.1.2-dev. Are you sure you deployed the suggested helm version?
It's enabled in the override.yaml I provided you firstly(and tested too).

[ksully-execute]

I'm using --version 1.1.2-dev on the helm install command, that's correct, right?
helm install janssen janssen/janssen --version 1.1.2-dev -n jans -f override.amro.yaml
I don't see any reference to 1.1.2 etc. in the file you provided (that's working otherwise)....am I missing it?

[ksully-execute]

here's my override based on yours (deleted nothing, just changed couchbase/LBIP/hostname and enabled scim and fido
override.amro.yaml.gz

[ksully-execute]

@misba7 Thanks for sticking with me, consolidating questions:

1. is the default login for the device validation (TUI) admin/password (if so, that doesn't work using that yaml that I posted in the prior post based on yours)
2. is helm --version 1.1.2-dev the correct way to run that version? If so, the auth-key-rotation is failing though it should be fixed, right? Thoughts?
3. any thoughts on the ingress (using cilium) not working (see post above installation instructions for using couchbase #5589 (reply in thread))

[misba7]

1. The default is defined at config.configmap.adminPassword here unless it's overridden by you.

2. Probably your image might be cached.

3. Regarding ingress/LB, we officially support istio, nginx and alb.