Wednesday, December 20, 2023

Intellij IDEA adventures with Python

 I am a bit puzzled this morning.

Yesterday I built a simple python application and containerized it. It was all working in Intellij with the python plugin and I could run it with the Dockerfile. A good experience that made it easy to develop and test.

The only thing not working in IntelliJ was the AI assistant. The plugin was stuck in eap-preview and no matter than I re-installed it and restarted IntelliJ, he did not want to recognize my license. Frustrating.

I apply the update to 2023.3.1 and this morning...

I have a working AI assistant.

IntelliJ will not recognize that python is available and keeps telling me that it can't reach the Docker server. Complete Amnesia.

At the CLI, I can confirm that docker and python are available.

I have no clue what it lost in its configuration to not be able to recognize anything.

Wednesday, September 27, 2023

First python application using my GPU

 I simply wanted to make sure that some Python code could use my GPU and it took a little more effort than I taught.

The code I found simply makes sure you have some GPU available and fills in a matrix of 1000x1000. Very simple.

First rookie mistake was to call my file tensorflow.py which cause a circular reference that took me too long to figure out.

I also needed to install a few missing components on my fresh Ubuntu 22.04 installation.

pip install tensorflow

sudo apt install nvidia-cuda-toolkit

pip install tensorrt

Once all these components were present, the application ran without errors.


Tuesday, September 26, 2023

SDKMan needs curl from apt install

 I made a rookie mistake and installed the curl from the snap store and that is not compatible with SDKMan. I would get errors about curl failing:

curl: Failed to open /home/user/.sdkman/tmp/spark-3.4.0.headers.tmp

The solution was to remove the snap curl and get the apt one installed:

sudo snap remove curl

sudo apt install curl

Easy enough and I can now install all my java tools.

Friday, November 4, 2022

Keycloak Outage

 It is a strange behavior that I learned today.

We run keycloak in HA in K8S. Bitnami chart. Nothing fancy.

We have a volume for the custom theme.

If I remove the theme files and put new one in place... All pods will restart...

This was very unexpected.

Next time we replace the theme we will need to have a maintenance window.

Thursday, November 3, 2022

Security Headers

 A useful site to check your deployed application:

Security Headers Scanner

It easily shows you what you have set properly and what is missing.

Gives you a grade that is color coded.

It helps to get this done before a pen test.

Wednesday, July 13, 2022

Istio and proxy-protocol

 When you search for solutions on the internet it is sometimes very difficult to know if what is proposed is going to work in your environment. The challenge comes from the fact that not everyone identifies the version they were working with at the time they applied this solution.

I find this snippet of YAML to be applied to my istio deployment to allow some headers to be properly passed on with the requests to the destination service.

apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
  name: proxy-protocol
  namespace: istio-system
spec:
  configPatches:
    - applyTo: LISTENER
      patch:
        operation: MERGE
        value:
          listener_filters:
            - name: envoy.listener.proxy_protocol
            - name: envoy.listener.tls_inspector
  workloadSelector:
    labels:
      istio: ingressgateway

Once applied, I tested but nothing changed and I still get the errors:

ERR_TOO_MANY_REDIRECTS

I then decide to see if restarting the istio ingress pod would fix things.

Well…

The pod is not coming back so I pull the logs and rapidly reads to identify what is causing this issue. I finally spot a few lines:

2022-07-12T20:39:29.975846Z error envoy misc Using deprecated extension name 'envoy.listener.proxy_protocol' for 'envoy.filters.listener.proxy_protocol'. This name will be removed from Envoy soon. Please see https://www.envoyproxy.io/docs/envoy/latest/version_history/version_history for details. If continued use of this filter name is absolutely necessary, see https://www.envoyproxy.io/docs/envoy/latest/configuration/operations/runtime#using-runtime-overrides-for-deprecated-features for how to apply a temporary and highly discouraged override.
2022-07-12T20:39:30.421115Z error envoy misc Using deprecated extension name 'envoy.listener.proxy_protocol' for 'envoy.filters.listener.proxy_protocol'. This name will be removed from Envoy soon. Please see https://www.envoyproxy.io/docs/envoy/latest/version_history/version_history for details. If continued use of this filter name is absolutely necessary, see https://www.envoyproxy.io/docs/envoy/latest/configuration/operations/runtime#using-runtime-overrides-for-deprecated-features for how to apply a temporary and highly discouraged override.
2022-07-12T20:39:30.429091Z warning envoy config gRPC config for type.googleapis.com/envoy.config.listener.v3.Listener rejected: Error adding/updating listener(s) 0.0.0.0_8443: Didn't find a registered implementation for name: 'envoy.listener.proxy_protocol'
0.0.0.0_8080: Didn't find a registered implementation for name: 'envoy.listener.proxy_protocol'

So I delete the EnvoyFilter and everything comes back.

So envoy.listener.proxy_protocol does not work with istio 1.13.x? I will have to read more to figure that part out.


Thursday, June 9, 2022

Spring Beans not Instantiating

I had not seen this error before:

No qualifying bean of type 'org.springframework.security.oauth2.client.registration.ClientRegistrationRepository' available

It took a little bit of research to find that if you do not have your application.yaml with the Spring Security section for this bean, it will not be able to instatiate one and you get the error.

To make it more difficult, I was specifying this module in gradle and I was expecting things to work. Asuming…

Once I added:

spring:
  security:
    oauth2:
      client:
        registration:
          nameItSomething:
            authorization-grant-type: client_credentials
            client-id: clientNameYouHave
            client-secret: DontShareYourSecretOnTheInternet
        provider:
          nameItSomething:
            token-uri: https://oidcServer/protocol/openid-connect/token

That ClientRegistrationRepository bean started to have a life.

Next bean… Same… I need to add a section for the caching in my application.yaml.

Tuesday, April 12, 2022

Dear Checkstyle

 I am not a big fan of forced styles and all these errors that comes with it.

I know, I know… If you are on a team of more people, you don’t have much of a choice otherwise you end up with style chaos and naming convention that are closer to a standup comedian number than logic.

I am just not a big fan…

We have a style for the member name in our classes that only allows for letters and number but I did a class to match the json returned from Azure OIDC so it is all lowercase name with underscore. Checkstyle would not let this through so I learned quickly how to turn that off for my class

This is the module in Checkstyle:

<module name="SuppressionCommentFilter">
    <property name="offCommentFormat" value="CHECKSTYLE.OFF\: ([\w\|]+)"/>
    <property name="onCommentFormat" value="CHECKSTYLE.ON\: ([\w\|]+)"/>
    <property name="checkFormat" value="$1"/>
</module>

All you have to do is a comment:

// CHECKSTYLE.OFF: MemberName

and after my class definition I can simply turn it back on:

// CHECKSTYLE.ON: MemberName

Then I could discuss with a team mate and disagree about having an annotation (@jsonproperty(“name_with_underscore”)) for each member name to respect the checkstyle and work with the json. What is the simplest will always win in my mind and not following made up rules for the sake of the rule.

Dear Checkstyle

 I am not a big fan of forced styles and all these errors that comes with it.

I know, I know… If you are on a team of more people, you don’t have much of a choice otherwise you end up with style chaos and naming convention that are closer to a standup comedian number than logic.

I am just not a big fan…

We have a style for the member name in our classes that only allows for letters and number but I did a class to match the json returned from Azure OIDC so it is all lowercase name with underscore. Checkstyle would not let this through so I learned quickly how to turn that off for my class

This is the module in Checkstyle:

<module name="SuppressionCommentFilter">
    <property name="offCommentFormat" value="CHECKSTYLE.OFF\: ([\w\|]+)"/>
    <property name="onCommentFormat" value="CHECKSTYLE.ON\: ([\w\|]+)"/>
    <property name="checkFormat" value="$1"/>
</module>

All you have to do is a comment:

// CHECKSTYLE.OFF: MemberName

and after my class definition I can simply turn it back on:

// CHECKSTYLE.ON: MemberName

Then I could discuss with a team mate and disagree about having an annotation (@jsonproperty(“name_with_underscore”)) for each member name to respect the checkstyle and work with the json. What is the simplest will always win in my mind and not following made up rules for the sake of the rule.