Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

arm64 #55

Open
faust64 opened this issue Jan 9, 2021 · 4 comments
Open

arm64 #55

faust64 opened this issue Jan 9, 2021 · 4 comments
Labels
Milestone

Comments

@faust64
Copy link

faust64 commented Jan 9, 2021

Hi,

I'm trying to install ltb-openldap, on a Raspberry Pi -- Raspbian (arm64) -- and could not find any package.

# uname -a
Linux xxx 5.10.4-v8+ #1389 SMP PREEMPT Wed Jan 6 13:52:18 GMT 2021 aarch64 GNU/Linux

It would be nice to have ltb-openldap released on arm64. And maybe even 32b arm.
Same goes for rpm packages.
Might be able to work on this, if I can figure out how to build something similar to official packages ....

Thanks.

@coudot
Copy link
Member

coudot commented Jan 10, 2021

Hello,

some documentation here: https://github.com/ltb-project/openldap-deb/blob/master/debian/paquet-openldap-debian/packaging_debian.README

Would be indeed great to have packages for ARM, but this requires to have a build platfrom for every new release

@davidcoutadeur
Copy link
Contributor

Would be nice indeed.

For new fresh release 2.4.57 it will be complicated to have this. @faust64 if you have worked on this, we could assess if we can integrate it for future major release 2.5.

@faust64
Copy link
Author

faust64 commented Jan 21, 2021

Maybe building all archs from the same host would be preferable? Though it would require extra work, setting up multi-arch.
In cases you're amenable to build packages on arm machines directly (raspberry, rock64, odroid, ...), then there's nothing to change to the existing assets, really.

I used Tekton Pipelines (a Kubernetes operator automating CI/CD jobs).
First, you would create a Tasks, describing how to build your package, and what to do with it once built (eg: push to a nexus repository) :

apiVersion: tekton.dev/v1beta1
kind: Task
metadata:
  name: deb-build-ltb-openldap
  namespace: ci
spec:
  params:
  - default: https://my-nexus-server.example.com
    description: Nexus Repository Address
    name: nexusaddress
    type: string
  - default: default-nexus-artifacts-upload-user
    description: Nexus Repository Username
    name: nexususer
    type: string
  - default: default-nexus-artifact-pw
    description: Nexus Repository Password
    name: nexussecret
    type: string
  - default: apt-ltb
    description: OpenLDAP LTB Nexus Repository Name
    name: nexusrepo
    type: string
  - default: 2.4.56
    description: OpenLDAP Version to Build
    name: ldapversion
    type: string
  resources:
    inputs:
    - name: source
      type: git
  steps:
  - command:
    - /bin/sh
    - -c
    - |
        set -x; \
        export DEBIAN_FRONTEND=noninteractive; \
        MYARCH=`uname -m`; \
        test "$MYARCH" = aarch64 && MYARCH=arm64; \
        apt-get update \
        && apt-get install -y wget tar build-essential autoconf automake autotools-dev debhelper dh-make \
            devscripts fakeroot file gnupg git lintian patch patchutils pbuilder libsodium23 libsodium-dev \
            libltdl7 libltdl-dev libsasl2-2 libsasl2-dev zlib1g zlib1g-dev openssl libssl-dev mime-support \
            mawk libcrack2-dev libwrap0-dev curl \
        && cd debian/paquet-berkeleydb-debian \
        && tar -xvzf db-4.6.21.NC.tar.gz \
        && cp -r db-4.6.21.NC/* berkeleydb-ltb-4.6.21.NC \
        && tar -czf berkeleydb-ltb_4.6.21.NC-4.orig.tar.gz berkeleydb-ltb-4.6.21.NC \
        && cd berkeleydb-ltb-4.6.21.NC/ \
        && dpkg-buildpackage -us -uc \
        && dpkg -i ../berkeleydb-ltb_4.6.21.NC-4-patch4_$MYARCH.deb \
        && cd ../../paquet-openldap-debian \
        && wget ftp://ftp.openldap.org/pub/OpenLDAP/openldap-release/openldap-$(inputs.params.ldapversion).tgz \
        && tar -xvzf openldap-$(inputs.params.ldapversion).tgz \
        && cp -r openldap-$(inputs.params.ldapversion)/* openldap-ltb-$(inputs.params.ldapversion)/ \
        && tar -czf openldap-ltb-$(inputs.params.ldapversion).orig.tar.gz \
            openldap-ltb-$(inputs.params.ldapversion) \
        && cd openldap-ltb-$(inputs.params.ldapversion) \
        && dpkg-buildpackage -us -uc \
        && dpkg -i ../openldap-ltb_$(inputs.params.ldapversion).1_$MYARCH.deb \
        && dpkg -i ../openldap-ltb-explockout_$(inputs.params.ldapversion).1_$MYARCH.deb \
        && dpkg -i ../openldap-ltb-mdb-utils_$(inputs.params.ldapversion).1_$MYARCH.deb \
        && dpkg -i ../openldap-ltb-ppm_$(inputs.params.ldapversion).1_$MYARCH.deb \
        && dpkg -i ../openldap-ltb-check-password_$(inputs.params.ldapversion).1_$MYARCH.deb \
        && dpkg -i ../openldap-ltb-dbg_$(inputs.params.ldapversion).1_$MYARCH.deb \
        && dpkg -i ../openldap-ltb-contrib-overlays_$(inputs.params.ldapversion).1_$MYARCH.deb \
        && cd ../../ \
        && ls -l paquet-* \
        && for f in paquet-berkeleydb-debian/berkeleydb-ltb_4.6.21.NC-4-patch4_$MYARCH.deb \
                paquet-openldap-debian/openldap-ltb_$(inputs.params.ldapversion).1_$MYARCH.deb \
                paquet-openldap-debian/openldap-ltb-explockout_$(inputs.params.ldapversion).1_$MYARCH.deb \
                paquet-openldap-debian/openldap-ltb-mdb-utils_$(inputs.params.ldapversion).1_$MYARCH.deb \
                paquet-openldap-debian/openldap-ltb-ppm_$(inputs.params.ldapversion).1_$MYARCH.deb \
                paquet-openldap-debian/openldap-ltb-check-password_$(inputs.params.ldapversion).1_$MYARCH.deb \
                paquet-openldap-debian/openldap-ltb-dbg_$(inputs.params.ldapversion).1_$MYARCH.deb \
                paquet-openldap-debian/openldap-ltb-contrib-overlays_$(inputs.params.ldapversion).1_$MYARCH.deb; \
        do \
            curl -u "$(inputs.params.nexususer):$(inputs.params.nexussecret)" \
                -k -X POST -H "Content-Type: multipart/form-data" --data-binary "@$f" \
                "$(inputs.params.nexusaddress)/repository/$(inputs.params.nexusrepo)/"; \
        done
    image: docker.io/debian:buster
    name: build
    workingDir: /workspace/source

Next, describe a Git PipelineResource, serving as an input, pointing to this repository:

apiVersion: tekton.dev/v1alpha1
kind: PipelineResource
metadata:
  name: openldap-ltb-deb-2456
  namespace: ci
spec:
  params:
  - name: url
    value: https://github.com/ltb-project/openldap-deb
  - name: revision
    value: v2.4.56
  type: git

Then, a Pipeline, listing a sequence of tasks (we could also have added tasks scanning code, running tests, ...)

apiVersion: tekton.dev/v1beta1
kind: Pipeline
metadata:
  name: build-ltb-openldap
  namespace: ci
spec:
  params:
  - default: 2.4.56
    description: OpenLDAP Version to Build
    name: ldapversion
    type: string
  resources:
  - name: app-git
    type: git
  tasks:
  - name: build
    params:
    - name: ldapversion
      value: $(params.ldapversion)
    resources:
      inputs:
      - name: source
        resource: app-git
    taskRef:
      kind: Task
      name: deb-build-ltb-openldap

Finally, start the job by creating a PipelineRun, that would associate our Git PipelineResource to our Pipeline, as well as passing an OpenLDAP version param:

apiVersion: tekton.dev/v1beta1
kind: PipelineRun
metadata:
  name: ltb-openldap-2456-1
  namespace: ci
spec:
  params:
  - name: ldapversion
    value: 2.4.56
  pipelineRef:
    name: build-ltb-openldap
  resources:
  - name: app-git
    resourceRef:
      name: openldap-ltb-deb-2456

Tekton is definitely not mandatory. If you have some Kubernetes with both x86 and arm nodes, it could be interesting. Otherwise you'ld be better just proceeding as usual, on any ARM host you have available.

@faust64
Copy link
Author

faust64 commented May 11, 2021

as a follow-up, I'm now building ltb-openldap for debian 10 / aarch64, using GitLab CI:

https://gitlab.com/synacksynack/opsperator/docker-openldap/-/blob/master/Dockerfile.ltbsrc-deb10
https://gitlab.com/synacksynack/opsperator/docker-openldap/-/blob/master/.gitlab-ci.yml

In your case, there may be a way to use something like this, and instead of shipping a container image, just copy its packages to some volume, outside that container, once done building. Which would spare you from looking into RPI-lookalikes, or other gcc multiarch specifics, ...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants